Firmware application version #3 release
-------------------------------------------
N64 updates:
Some extra timing delays were necessary for consistent dumping.
Includes fixes for N64 dumping that proved working for me on 10+ carts I
dumped successfully. There is now a .csv in docs folder with cart size
in bytes, divide that number by 131,072 to get size in mbits for -z
flag. Includes CRC32 checksum that can be verified using HxD hex
editor. N64 file output is big-endian so it reads as it should in hex
editor which is .z64 file format. lua script updated to print out the
game name from the in rom header.
NES updates:
flashing support for quite a few different mappers including GTROM,
MMC2, MMC4, action53, easyNSF, and other tweaks to rd/wr timings.
FIRMWARE UPDATES:
inlretro2.lua script now tries to poll the firmware "application
version" and suggest updating your firmware if you're not running the
version in this release. You can always update your firmware using the
bootloader method in the readme. But there is an easier method if you
have an stm32 based device (translated: you purchased your device in
2018 or later). AND you're already running firmware version v2.3.x
simply run the new scripts which were added in this commit:
PCB version 2.0 or 2.1 (large square PCB with option for 6 connectors)
>inlretro.exe -s scripts\inlretro_inl6fwupdate.lua
PCB version 2.0N (smaller PCB with NES connector only:
>inlretro.exe -s scripts\inlretro_inlNESfwupdate.lua
Now that it's easier for the host software to detect the firmware
application version can work towards having the scripts automatically
update the device firmware for you.. But still need to implement this..
included. Not making an offical firmware release, will have to upload to
INLretro6 with fwupdate call.
The colordream firmware updates are also included. But not the host
scripts, need to clean them up a bit.
this is the verion getting flashed on all v2.0N NESmaker kits
v2.3.0 worked for basic functions, but was never shipped
Majority of effort revolved around testing mapper30 boards with the
smaller v2.0N INLretro with the NES connector alone for NESmaker kits.
added linear feedback shift register for test stream data generated
locally on the device. I'm not 100% sure if this is any faster than
pushing the actual data via USB though.. :/ It's plenty fast on the
stm32 nearly instantaneous for 32KByte. But the AVR takes a couple
sec..
Created "stuff" dictionary for things like that were I just want to add
small things and don't want to bother with a whole new dictionary.
Added file verification to the host with files.lua
Have some nes flash algos return post-written data so calling function
can decide if want to retry, fail, etc.
Changed host dictionary calls to assert instead of error because it
really shouldn't continue. I didn't see an error when sending opcode to
wrong dict and caused head banging..
fwupdate permits bytes to be skipped, or force the update. Found that
the fwupdater got assigned different addresses of ram depending on what
all other ram gets allocated to the main application
Some clean up of inlretro.lua
TODO:
host learn and keep track of the connected device.
Needed for ciccom right now, or knowing whether ciccom connection
is even present..
In the end maybe ciccom is better placed in firmware, but for small
transfers of only a few bytes it kinda makes sense to keep on the host.
Pinport gets quite messy with these made up pin names when really all I
want to do is toggle a specific pin on the NES connector. So maybe some
double mappings would actually be okay, need to rethink that..
create different flash modes that either keep going, retry, or error
depending on the goal of the flash operation. Fanout the return value
from flash algos to all of them.
have fwupdate assigned a specific area of ram so the ram pointer doesn't
change between builds. Okay to ignore for now.
Realized can have STM32F070C6 devices execute bootloader by erasing all
the flash or perhaps even just the first word of flash according at
AN2606. This wouldn't work for RB devices though. This could be done
through the bootloader dict
definitions. Still work left on the expansion port though..
Created *_CONN definitions so code doesn't get included for connectors
that aren't present.
Added a NES CPU write that doesn't toggle M2 but not sure if this will
really be needed for MMC2 or not..
NES scripts to use new dump/flash methodology that MMC3 started.
Includes BNROM, UNROM, MMC1, and new scripts for FME7 & MMC4 (SOP flash).
Adding more general support to SNES with v2proto_hirom that script is
actually becoming more of a master script supporting both LoROM and
HiROM including flash, dump, and save backups.
SNES Rd/Wr now designate the state of /ROMSEL so have to manually
determine if access should be in /ROMSEL space of the SNES memory map or
not. (ie all SNES cart memories are /ROMSEL space except HiROM SRAM).
I made a commit earlier this week but messed things up by not pulling
from the master and things weren't updated... Here's the notes from
that commit:
Author: Paul XPS <paul@infiniteneslives.com>
Date: Tue Nov 6 22:45:52 2018 -0600
Large commit biggest feature add is NES MMC3 support including Save RAM
(aka WRAM/PRGRAM) support including dumping and writing save files.
The MMC3 script & method of dumping/flashing is the most forward
thinking script/firmware so far. Finally starting to form a clear
vision of how I want to handle flashing/dumping variations with mappers.
Biggest thing is having the host handle the mapper init & banking
control. In the view of the firmware, it's only responsible for knowing
how to flash a bank. And dumping is even more generic with the host
just telling what address range to read. Things will get more complex
with support of mappers with bus conflicts. But ready to start
converting these old hacked methods to be more like the MMC3 means.
Have some early support for dumping gameboy using the snes script as the
pinouts are nearly identical. Along with testing of toggling between 3v
GBA and 5v DMG.
Have some early support for INLretro NES only version which uses a
smaller mcu because it doesn't need to support large 16bit carts. Still
have to get this completed.
Added support for CNROM, but I'm not sure if it's actually working. Going
to restart with NROM and start updating the currently supported
mappers to be more like MMC3.
But this also includes some new updates from the second half of the week:
Started updating existing NES scripts to use new MMC3 methodology. Got
NROM, CNROM, BNROM, & Color Dreams working. On the host side only
needed to add nes.c functions for specific flash algos. Able to delete
significant amounts of mapper specific code from flash.c
Got some basic SNES script support with new methodology for Catskull
elect 5v PLCC SNES LoROM board. And INL SNES HI/LO-ROM 3v board as
well. These don't yet use buffer writes, just single byte writes.
Also having issues with Mirroring test/sensing again. Driving me crazy,
but don't really care about it at the moment and not sure what's wrong..
So just committing that broken for now. Looking to remove this
functionality from the firmware side as the host should be controlling
most of this.
Looking to add SNES RAM & buffered writes. Also need to test some of
the HIROM code as I just added it in there while I did the LOROM stuff..
Added windows driver package, just have to run InstallDriver.exe to
get drivers installed on windows 10 (and others I believe)
Created dictionaries for all remaining cart connectors.
Nothing useful there yet, just wanted to get the files created
and dictionaries working.
Added bunch of notes to shared_dictionaries to explain how to go
about creating new dictionaries and some opcode details.
Have STM8 cic communications working "CICCOM" to change between H/V
mirroring on new discrete boards. Currently these operations are handled
entirely from the host scripts and opcode/operands are mostly hard coded.
Need to move these to more generic functions in the ciccom dictionary
which will also speed things up moving to the firmware which will speed
things up.
Some changes to mapper 30 script to eat the ines header, and test CHR-RAM
banking.
Some updates to snes flashing operations, still a work in progress to
fully support prior SNES board designs.
Mostly adding support for mappers as I needed it for my own hardware
builds:
-MMC1
-mapper 30
-easy NSF (still need to update for mapper verilog fix)
-action53 (still need to update for mapper verilog fix)
-dual port board flashing
-colordreams, not sure if I actually got this working
-color ninja, just a special CPLD version of colordreams for ninja boards
Just started working on SNES code. slowly getting things up and working
outside of main inlretro.lua script similar to how NES has been handling
everything with it's own script. Able to flash v3 boards fine. v1 boards
flash without errors, but still having some mapping problems where it
verifies but won't boot. v2 prototype flashes most bytes but not all,
seems v2 boards are much slower to output valid data.. But that may just
be the manufacturer ID codes..?
TODO next:
-bootloader dictionary that jumps to bootloader so don't have to manually
close jumper on the board.
-turn on the watchdog timer for stm32
-create some sort of host timeout so reset button on programmer isn't as
useful
-allow firmware programing algos to be uploaded and executed from SRAM for
faster code that also doesn't require specific firmware builds to support
new mapers.
-Finish JTAG to simplify programing NES & SNES CPLDs
-Sort out swim issue with stm8s001 CICs
-add SWIM support for avr
Dumped/flashed MMX on SNES v3 boards.
created discrete_exp0_mapper_wr to try and write to mapper but not flash
for discrete boards but doesn't seem to work for some reason so commented
out for now.
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
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.
logic 1 if relying on it. Seems to work fine on NES discrete and
INLXO-ROM boards where planning to utilize it. SNES can't pull up due to
pulldown and original famicom cart can't either perhaps because of
EXP6 EXP FF output being too much of a load..?
cleaned up firmware pinport.h used PURPLE/GREEN KAZZO for all #ifdef's
AVR Memory Usage
----------------
Device: atmega164a
Program: 3404 bytes (20.8% Full)
(.text + .data + .bootloader)
Data: 53 bytes (5.2% Full)
(.data + .bss + .noinit)
final kazzo design hex commited as comparable build to the past two commits of green/purple.
So this .hex commit is apples to apples with recently commited purple/green .hex commits.
Able to read PRG-ROM flash chip's manf and device ID from commandline.
New dictionaries io and nes along with firmware files to support.
now have io_reset, nes_init, and snes_init io.c functions
nes.c functions including discrete_exp0_prgrom_wr and emulate_nes_cpu_rd.
New dictionary.c/.h for host to make dictionary calls easier including
setting proper return data lengths based on opcode.
adding nop command to pinport.h
AVR Memory Usage
----------------
Device: atmega164a
Program: 2960 bytes (18.1% Full)
(.text + .data + .bootloader)
Data: 53 bytes (5.2% Full)
(.data + .bss + .noinit)
Paul Desktop ASUS-C7H