Not 100% sure what all happened with this update.. :/
Tested and have all 3 recent kazzos flashing and dumping PRG-ROM and
CHR-ROM on NROM NES board. Pretty sure I tested purple and green kazzos
too as I had left those on in pinport and seem to recall having them all
working when I tweeted 2 weeks ago..
Created new status_wait for buffers so can wait for them to finish
dumping/flashing before starting/ending operations. That cleaned up
dump/flash code a fair amount.
On first tests today I had issues where setting flash operation would hang
and fail with both stm kazzos. As I started to debug the issue it
disappeared, so IDK what that was all about.. I think there might be an
issue with my stm32 usb drivers.. Those were updated in this commit to
properly allow write "OUT" packets to be supported.
Planning to start tinkering with SNES in prep for the no save boards
arriving tomorrow!
Need to get stm32 up and working, currently the usbFunctionWrite causes
device descriptor request to fail on stm32 devices. So need to do some
debugging there which I was expecting..
enumeration with host, no vendor/class requests handled.
move avr builds into avr_release dir
move original source files into source/old for future reference.
avr-size avr_kazzo.elf
text data bss dec hex filename
1496 2 43 1541 605 avr_kazzo.elf
Not sure how I thought flash operations were previously working as there
were many bugs I had to correct to support flash operations properly.
Operations module appears to be working so far, still need to pass
functions to operation module.
Flash operations verify PRG-ROM 32KB writes working with file comparison.
Currently dependent on extra buffer status reads to delay next buffer.
I think the write operation is taking longer than the usb load operation.
Potentially due to slow code of operation module, but also possible I
had only been testing with slow eeepc linux machine previously. Perhaps
combination of both.
Still need to correct issue so added buff status delays aren't needed.
buffer manager should be able to key off of status==USB_FULL but that
doesn't seem to work. When trying I don't always get the same number of
buffers to get flashed so appear to have a race condition or something
not properly intialized..?
Need sort out sending of USB STALL if buffer isn't ready to be loaded yet.
This commit is mainly for documentation/reference purposes as things are
kind of working, but buggy/unstable.
AVR Memory Usage
----------------
Device: atmega164a
Program: 6486 bytes (39.6% Full)
(.text + .data + .bootloader)
Data: 679 bytes (66.3% Full)
(.data + .bss + .noinit)
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.
Need to verify page programmed successfully as it currently just continues even if unable to
flash proper data. Need to make write page utilize variables for bank address based on mapper
and/or memory as currently doesn't flash CHR-ROM due to $5555 $2AAA being above address space
of CHR-ROM
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.
Paul Molloy