Things appear to be working with some early testing. Assumption that oper_info elements
are aligned in SRAM linearly appears to hold true. Researching this I found it probably
was true, but can't be certain esp if gets changed in the future to not be purely 8byte
sized elements.
Still need to provide means to decode function numbers info function pointers.
Found bug with setting map_n_part due to >/< instead of >=/<= for setting called_buff...
Was also setting mem_type and part backwards in dump.c
The had issues with usb timing out for more than 1 buffer read back
Problem was due to lack of usbPoll while dumping during double buffering
Adding usbPoll to page read to correct issue
Appears to be issue with dumping first byte of this choplifter cart I'm testing with.
Not so certain it's my bug though.. No matter what I do the first byte reads
back 0x78 and copy I downloaded has 0x00. Setting my first byte to 0x00 also
creates proper CRC32 according to bootgod's database. So need to look into this more
to figure out what's going on.
Prepended DICT_ to dictionary names to prevent using those defines for something else accidentally
"NES/SNES" etc could be used in a lot of places, don't want to use wrong enum/define in wrong place.
created enums.h to list out all enums/defines for cartridge and memory elements in one location.
separate file.c/h file for getting data in/out of a files, and opening/closing them.
adding test roms to roms folder so they can be used for various testing.
buffer opcode updates to transfer payloads
including stuffing two bytes of write transfers in setup packet.
Calling specific buffers with miscdata or opcode.
new dump and flash modules for firmware.
new buffer function update_buffers called during main to monitor and
manage buffer objects when not being loaded/unloaded from USB.
Had a good lesson on what static means... :/
everything working now as previously designed
speed testing on windows10 PC yeilded ~21KBps when transferring 128-512KB
payloads and 128Byte transfer size. Going to bump to 256 and see how that
does after 128KB speed tests on linux machine.
created host test.c/.h file for general testing of new features.
that way I can start working on erase/write.h files and just use test.c as
scratch code space for tinkering and still call with -t flag on command
line.
modified dictionary calls to include pointers to data and lengths.
moved all buffer operations out of usb.c with new bridge function between
the two files. Lots of pointing going on and lessons learned..
Thankfully everything seems to be working if you actually call the
functions as I designed them.. Gotta love trouble shooting bugs that
don't exist.. Helped updating allocate output to get returned as error
back to the host.
Moved typedef structs to firmware type.h file as seemed to cause
compilation issues being contained in the files .h file when other .c
files needed those types.
Fixed casting warnings with usbMsgPtr ended up looking at usbdrv.c figured
out how close I got, just shouldn't have been putting the * in there..
complete. should be able to allocate buffers from host, but haven't got
to testing it yet. Compiling on firmware though..
Currently have 256 bytes of raw_buffer, and 8 buffer objects/structs
each with ~16 bytes per object. So could trim things down, but still have
decent amount of SRAM left. Could have another 256 byte buffer at this
rate.. but might not leave enough SRAM for temporary routines.
Possible that raw buffer space could be dynamically allocated
as either buffer space or temporary routine space...
AVR Memory Usage
----------------
Device: atmega164a
Program: 4094 bytes (25.0% Full)
(.text + .data + .bootloader)
Data: 573 bytes (56.0% Full)
(.data + .bss + .noinit)
paul eeepc