set as other things may trigger off of this.
Also forgot firmware size report:
AVR KAZZO:
avr-size build_avr/avr_kazzo.elf
text data bss dec hex filename
6952 6 674 7632 1dd0 build_avr/avr_kazzo.elf
INL6:
arm-none-eabi-size -t build_stm/inlretro_stm.elf
text data bss dec hex filename
8408 0 684 9092 2384 build_stm/inlretro_stm.elf
STM adapter:
arm-none-eabi-size -t build_stm/inlretro_stm.elf
text data bss dec hex filename
9212 0 684 9896 26a8 build_stm/inlretro_stm.elf
Also the more I get into these flashing routines, maybe the original kazzo
wasn't so bad.. It just takes awhile to flash these chips... I'm not
sure it makes much sense to offer/support stm32 adapter. While it is less
work to cut it out, it's brought out bugs in my code just due to having
different platforms with their quirks manifest bugs.
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..
tested and verified on purple, green, and yellow/orange avr kazzos and
stm32 inlretro6 proto, and stm32 adapter with yellow kazzo board
AVR takes ~17.5sec to dump 256KB -> 1:10 for 1MByte = 14.6KBps
STM takes ~8.5sec to dump 1MByte = 120KBps
STM32 usb driver is far from optimal as it's setup to be minimal with only
8byte endpoint0 to make an effort to align avr and stm. Larger endpoints
and bulk transfers should greatly speed up stm usb transfers
refactored firmware buffer.c and implemented most of the required opcodes
added check that should cover if device isn't ready for a IN/OUT
transfer. Does this by usbFunctionSetup returning zero which causes the
device to ignore the host. Don't think I've got the stm32 usb driver
setup properly to handle this not sure I fully understand Vusb driver
either. Anyway, hopefully it works well enough for now and keep this in
mind if issues crop up in future.
Still haven't implemented usbFunctionWrite, not sure stm usb driver is
setup properly yet either..
build sizes:
avr yellow/orange: avr-size build_avr/avr_kazzo.elf
text data bss dec hex filename
5602 6 674 6282 188a build_avr/avr_kazzo.elf
previous builds of avr code size was ~6.4KB when flashing and dumping was working.
AVR bootloader is 1.7KB taking up majority of 2KB boot sector.
So AVR has 16KB - 2KB boot = 14KB available, using ~44% of non-boot sector
available flash Have 4 buffers defined, and 512B of raw buffer defined so using
~65% SRAM Making pretty good use of the chip just for basic framework.
Not a ton of room for board/mapper specific routines, so will have to keep this
in mind. Creating more generic routines to save flash will come with a speed
hit, but perhaps we shouldn't worry too much about that as devices below
really boost speed without even trying. There is some sizable amount of
SRAM available could perhaps load temporary routines into SRAM and execute
Also have ability to decrease buffer sizes/allocation. Perhaps routines
could actually be store *IN* the raw buffers.. ;)
stm adapter: arm-none-eabi-size -t build_stm/inlretro_stm.elf
text data bss dec hex filename
7324 0 680 8004 1f44 build_stm/inlretro_stm.elf
Currently targetting STM32F070C6 which has 32KB flash, 6KB SRAM
Could upgrade to STM32F070CB in same LQFP-48 package w/ 128KB/16KB
Don't think that'll be of much value though especially with limitation
on connectors for adapter.
So currently don't have user bootloader, only built in ones.
8KB of 32KB avaiable flash = 25% utilization
680B of 6KB available sram = 11% utilization
32KB device doubles amount of available flash compared to AVR, although
stm32 code isn't quite a condensed compared to AVR.
stm inlretro6: arm-none-eabi-size -t build_stm/inlretro_stm.elf
text data bss dec hex filename
6932 0 680 7612 1dbc build_stm/inlretro_stm.elf
Mostly limited to STM32F070RB as choosing device requiring XTAL, and
desire large number of i/o. This device provides 128KB flash, 16KB SRAM
Currently using 7.6KB/128KB flash = 6% utilization
Currently using 680B/16KB SRAM = 4.1% utilization
LOTS of room for growth in this device!! Part of why I choose it over
crystalless 072 version, as it came with more flash for less cost.
Also hardly making use of 1KB of USB dedicated SRAM:
32B buffer table entries
16B endpoint0 IN/OUT
48B of 1024B available = 4.6% utilization
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
Had to add check to get cur_buff status and wait to send payload until
it's empty. Still need to add timeout check as it'll spin forever if
there is a problem and it's never empty...
device should be able to handle buffer sizes smaller than usb transfer
but this probably isn't true if the first two bytes are stuffed into setup
packet. Currently relies on end of (upto) 8 byte transfer to fill buffer.
MAKECHECKS would verify we don't overflow buffer.. Still kind of a half
thought out idea unfortunately.
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
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.
Detecting mirroring code working and tested
Started working on buffer operations from host
Current code compiles but not yet at point where can start testing
Adding cpu page read to nes.c to have faster dumping operations.
moving enums to shared as gets used quite a bit communicating between device and host.
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 Molloy