-SNES support for 32Byte page writes, but host lua scripts are a bit of
a mess and still need committed. Firmware isn't very clean either but
it's working..
-SEGA stuff is early and non-working. Got it working in a separate
branch which will commit shortly.
-SWIM updates for better erasing, flashing, and dumping routines
-FILES updates for jtag and some other niceties
-JTAG is working now for LC4032V & Mach-XO 256
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..
on provided prg/chr rom input args for dumping. Mirroring is sensed &
entered for fixed mirror mappers. So this is basic iNES file format.
Still don't have automatic banktable locating, nor mapper detection.
But this provides a basic header that should work with most currently
supported NES mappers. If the headers need tweaked, I recommend opening
in Mesen and using it's header modifcation tool.
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.
cartridge reading!
have some cleanup to do:
clean up sega dumping so don't need a page0/1
implement sega single reads
Add GBA to some of the common opcodes
dumping Don't think need addrH |= of mapper, but maybe this is key to
cleaning up first note..
gba, sega, n64 has extra NOPs, remove and test.
create pinport renames for sega pins, move mask defines to pinport.h
clean up comments for genesis page reads..
haven't done anything with save ram/flash yet, but should be able to
dump rom for any/all GBA carts now! Tested with 8Mbyte Metroid Fusion.
Took ~75sec at 107KBps
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
Had to fix io_reset, was trying to modify GB POWER pin before turning on
GPIO blocks..
Will be putting nightly builds for "INL6" pcb v2.0 in the build_stm
folder. This is the primary device most people have. Not going to
bother versioning it. But it can easily be flashed onto devices running
v2.3 firmware which includes the fwupdater now. There is a call
commented out in inlretro.lua which performs the firmware update to the
nightly build:
fwupdate.update_firmware("../firmware/build_stm/inlretro_stm.bin")
the binary isn't versioned so there will be a warning, when flashing
over the top of it but it can be ignored.
Only really created the gameboy page dump function so far. Next need to
implement the read/write functions so we can start interfacing with MBC
gameboy mappers.
Put bunch of notes in Readme.txt on how to update device firmware to
v2.3 using dfusedemo. Anyone with a device currently in their hands
will want to update to this latest version using the dfusedemo
instructions there. Or the AVR instructions if you have an old kazzo.
For devices shipping after Dec 1st 2018 I will be flashing this latest
v2.3 firmware which has it's own firmware updater so the INLretro host
software can easily and seamlessly update the firmware for you without
any external software, switch or jumper operation on the PCB.
This update also includes some power functions in the bootloader
dictionary. Can now make direct read/write access to the entire ARM
memory space. Maybe I'll add this to the AVR someday..?
Having this previously would have actually allowed me to bootstrap
a switchless bootloader without dfuse.. ahh well...
Also turned the watchdog timer on for the STM32 build finally.
Requires refreshing every ~1sec, currently only done in the main.
Added application versioning to address 0x08000800 in the binary.
Couldn't get the linker script to do this for me for some reason.
So for now I just manually put it in the binary file.
The fwupdate.lua script has a lot more checks now. Uses the new
bootloader dict functions to dump device firmware and make sure
all looks good before it starts erasing firmware.
Haven't done much testing with the current AVR build. Got a report
there was a problem with UNROM flashing, will have to check that out.
Done with the firmware for awhile now hopefully. Need to clean up some
things with the main program & inlretro.lua script. Start making better
use of some recent contributions by several gracious people.
Maybe I'll get going on gameboy, GBA, & sega soon.. Got a ton of
NESmaker devices to push out the door now with this latest build. So
might be slow for a bit..
on it's own!!!
It flashes pretty quickly too. The STlink takes about 8sec to erase and
write. I'm guessing it's erasing the whole 128KByte though. My own
fwupdater takes ~3sec to flash, ~1.5sec to erase. So there might not
even be that much room for speed up. 3sec is hard to beat signficantly
anyway and it comes at the cost of bytes. Perhaps even complexity and
risk of OUT packet errors/loss on the device side. So kinda like
leaving it as is.
Have basic testing complete of erasing application/main code, flashing
data, and reading it back for verification.
This ended up being pretty big task to get working. Some previous
efforts helped out quite a bit though. The first thing needed was a
path out of the main application and this was done in bootload.c by
calling PREP_FWUPDATE. That jumps to the fwupdate area (first 2KByte)
of flash.
There the 'fwupate main' takes over. It updates the usbFunction
Setup/Write ram function pointers to fwupdate's own setup function.
Then it must hijack the processor's execution so once the PREP_UPDATE
exception is complete the processor returns to the fwupdater instead of
the main. This is done by snooping back through the stack and finding
the stack frame keying off of xPSR and valid PC address. It then stomps
the PC & LR in the stack frame to steal execution from the main thread.
After that, all usb transfers are handled by the fwupdater.
Able to get buy without the write so far since setup packets provide
data but are also IN transfers to give path for sending data back to
host. So to keep things small and simple this is all that's handled so
far. Once I get tired of it being so slow I can implement the
usbFunctionWrite and speed things up quite a bit. Haven't actually
timed it yet, but for only 20KByte of data it and not being very
frequent it shouldn't be a big deal. The more I say this the more I'm
thinking I'll add that next because I'll be using it myself so much for
development.. Less time in that state is less likely for ppl to
'semi-brick' their device.
There is of course always the stmicro dfuse demo that can always unbrick
the device. I tried really hard to jump to their bootloader but no
matter what I did I couldn't get it working. It was never recognized by
USB. I half way wonder now if I needed to disable the bootpin which I
never would want to do anyway..
Created separate build_stm folders for INL6 & INL_NES which is what all
the NESmaker kits use. Also update the make files to be more accurate
about what chip their using since fwupdate tries to prevent a hardfault
from flash access beyond what's available.
This update doesn't include a means of updating the first 2KByte of
firmware updater space itself. But the application code should be able
to take care of that for us in a future update. It's only 2KByte so
just temporarily storing the fresh build in SRAM will probably work.
Although will have to be careful about any calls from application code
to fwupdater. Plus there's always dfuse..
Other problem I ran into was erasing the application code. It worked
fine early on for all 30KByte. But as my fwupdater function grew it
crashed when page 18 was erased. Realized my bigger switch/case
statement was calling a gcc library function that resided in the
application code. It was only 50Bytes, so moved it to fwupdate section.
Brought 2 of similar library functions over as well, but one of them
disappeared with update to latest version of arm-none-eabi-gcc.
Not a commit really, but this is the release where I updated gcc. Was
previously:
gcc version 6.2.1 20161205 (release)
[ARM/embedded-6-branch revision 243739]
is now:
gcc version 7.3.1 20180622 (release) [ARM/embedded-7-branch revision
261907] (GNU Tools for Arm Embedded Processors 7-2018-q2-update)
Updating gcc provided a smaller build size of ~250 Bytes from the tail
end. But it also freed up ~50Bytes in fwupdate space as well.
Need to physically separate them now. Then can focus on erasing &
flashing ourselves.
Added some speed checks to bnrom.lua script that I was testing usb code
with. Was able to verify read/write speeds were no affected by changes
in this commit. Did some testing against older firmware v2.2 though
there does seem to have been a slight slow down on write speeds.
Although, perhaps that's because of the nrom flash verifications that
are also included in this build (but not commited)..?
Paul XPS
Joel Smith
beyondcoast
Sylvain Gadrat