battery ram save dumping, and flash board programming.
-MMC5 updates fixed battery ram dumping
-genesis_v2.lua script supports dumping battery ram, and flashing ROM
only prototype flash board. The firmware isn't very clean, but working
for now.
-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..
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..
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.
Deleted shared_usb.h because it was a copy of shared_dict_usb.h
This build_stm .hex does include some NROM flash updates to allow
checking if the last byte programmed successfully because was having
weird problems with that. But not ready to commit all those changes and
they're highly unrelated to this commit.
Now that usb code doesn't use any .data nor .bss need to fully separate
the USB firmware code from the application. Main way to do this will be
to have usb code be effectively entirely interrupt driven.
Thinking the best way to initialize usb will to have the application
code jump to the USB ISR and maybe use some messaging system with the 2
unused usb_buff indexes (4Bytes).
The USB code will include the vector table, so it will point to the
reset handler, but that will point to the application code's reset
handler, just need to make sure that's at a fixed location.
The USB code is just over 1KByte last I checked, so dedicating 2KByte
should be good. Erase granularity is 1 page (1KB on C6, 2KB on RB). So
that will work well. Write protection granularity is 4KByte, but really
we shouldn't need to use write protection as there will always be the
built in bootloader to save a bricked device.
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.
Most progress was on jtag lua statemachine code. From what I recall I
tested and verified most state change possibilities with logic analyzer.
So they should be fairly good. Possible I didn't test all later ones,
or things are partly unfinished, but my best guess is they're good.
Appears was able to erase MachXO CPLD. Added time delay for run test.
Did some basic testing for gameboy power switching circuit.
Also just got STM8S001 CIC programming working for discrete boards via
A0. Pretty sure I broke EXP0 in the process for SNES boards.. So need
to go back and fix that I think due to new means of changing swim pin.
Various changes to STM8 SWIM code to make more versatile allowing SWIM
pin to be located effectively on any STM32 GPIO pin. Still haven't
touched an AVR implementation, but made place holders so it can compile
for AVR at least. These SWIM changes aren't heavily tested, mostly just
made sure could flash SOIC-8 STM8 CIC via CIC CLK.
Beginings of JTAG code to configure CPLDs. Currently only tested state
change and scan out reading MachXO-256, 4032/64v, & XC9572/36XL CPLDs
Tested and working on inlretro6 v1.0p, stm adapter, & avr kazzos.
Older devices with flipflops will apply 5v signals to JTAG pins but time
is mostly minimized by keeping signals defaulted low unless actively
changing states or scanning data.
Still need to verify scan in working, probably move TDI/TDO long strings
to buffers instead of 32byte PBJE data array. Also need smarter PBJE
host code to keep track of current state and come up with PBJE register
values without hard coding them..
But things are working fairly well so far with SWIM & JTAG
implementations. Had some issues where I thought jtag pin toggling was
getting optimized out, but I must have simply had the logic analyzer
speed set too low and was missing pin changes that can be as quick as
40nsec with space optimized code. Current inl6 code is ~4400Bytes,
without optimization it's nearly 50% larger at ~6550Bytes..!
Optimizations seem fine in testing and with logic analyzer running at
50Mhz which is good because the GPIO registers are set as volatile so
they better not be getting optimized away!
-Updated STM devices to always run @ 48MHz
Doesn't seem to cause any problems with SNES flashing couple thousand SF2
boards have been flashed with this build without issues
-Added note to usb_operations.c as manf/prod ID can't be read if drivers
aren't installed. Caused issues for Todd as he hadn't installed drivers
for new hardware.
-STM swim operations are working pretty well for SNES v2 and v3 boards
Haven't even touched SWIM on AVR core yet...
SWIM is pretty pin independent but only implemented on EXP0 so far
Reads "ROTF" aren't bullet proof but they're pretty good. Biggest
room for improvement aside from adding a legit pullup would be to have
an interrupt trigger the device header bit falling edge instead of the
current polling method which has decent amount of jitter.
Implementing interrupts would also probably allow for more easily
supporing reads longer than a single byte...
Only reads one byte, but good enough.. to get things done.
Code should actually work for low and high speed, but have only tested
high speed on writes so far.
Having issue where reads can fail at times. Esp with long strings of
'0'.. Perhaps operating at high speed would improve matters..
Although I'm also realizing maybe I'm not waiting for the device to reset
and reload HSI trim factory value, need to check that..
The new assembly file/function does everything needed so can start cutting
out inline assembly from swim_out function.
Swim code needs to run at 48Mhz. Realizing this is pretty vital to having
enough time to handle high speed. And timing of artificial pull-up
requires high trimmability..
Able to enter active mode and Write on the fly.
Simple test to toggle LED on STM8 GPIO works!
Still quite far from ideal setup. Some things needed:
-defines for ACK/NAK/NO_RESP in dictionary to report inteligbly to lua
-move test SWIM code into separate lua script
-define STM8-CIC registers for easier calling from lua
-entering active mode is too board dependent, need to use swim_base
-Need to make better use of device timers for entering active mode
-arm assembly is quite a mess, unaware of calling convention when writting
-stopping more than just r0-4, r5+ need to be restored if used
-thinking I'd like a full out assmebly file that gets compiled separately
-nothing is done to support SWIM with AVR
-hacking lack of powerful enough pullup on SWIM pin
not much that can be done to get around this...
don't want to add resistors to programmer for every pin I 'might' use
don't want to add resistors to each board that's made
-seems to work well enough, but reads will prob prove challenging
-currently only running at slow speed with ton of NOPs
AVR not yet working, performing low level SWIM operations will require
decent amount of core specific code due to differences in pin driver
styles, timers, cycles per instruction, etc. The fact that SWIM pin
changes based on the board ADDR0, DATA0, EXP0, etc multiplies this low
level code... Thinking about executing SWIM low level drivers from SRAM.
Initialization could include loading these routines to SRAM.
For now just focusing on supporting SWIM on STM cores for SNES boards.
works on both inl6 and original kazzo just fine. Dumping v3 prototype has
a few byte corruptions on inl6, but is fine on original kazzo. The same
bytes often fail, but not consistently. Tinkered with adding delay, but
that didn't help. Also have issue with adapter not dumping properly.
Prob bug with HIGH ADDR on that board need to sort out still. Going to
focus on erasing and dumping next then come back to some of these issues.
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
Have separate lua modules now in scripts/app folder
Dictionary calls are now their own lua module
firmware now capable of calling multiple different dictionaries
have firmware & lua io and nes dictionaries, able to detect
NES and famicom carts. Created expansion port abstraction so most kazzo
versions behave identically.
Created separate make file for stm adapter and inl6
added PURPLE_KAZZO and GREEN_KAZZO defines back in. They work well enough
for sensing NES vs famicom carts so far. GREEN_KAZZO requires
PURPLE_KAZZO to also be defined. GREEN_KAZZO is also only compatible with
AVR_CORE due to software_AHL/AXL functions specifically written for AVR.
I think things will work if a STM_ADAPTER is placed on a PURPLE_KAZZO and
both those defines are made as only real difference is software tying of
AXL and X_OE. But haven't tested this aside from ensuring it compiles.
Have correction to pinport_al.h that will commit immediately after this.
Effectively deleted old dictionary call function/files.
Created lua_usb_vend_xfr function so lua can directly send and receive
vendor setup transfers.
Dictionary calls are more like function calls now, and all args aren't
required so the LED can be turned on for example in lua like so:
dict_pinport("LED_ON")
general format is:
dict_name( opcode, operand, misc, datastring )
Also added ability to store opcode's return length in shared dict library
files with RL=number in the comments following the opcode.
Negative numbers designate OUT transfers, positive for IN.
Default value can be determined by each dictionary's calling function.
Decided pinport is 1 for SUCCESS/ERROR CODE.
Also have default return data means with second byte giving length of
return data in bytes that follows.
dictionary call function reports any errors reported by the device and
returns any return data from the device excluding error code / data len
Now time to start implementing some of these dictionaries on the device.
packet arrives. Had issue with return data on STM32 not being properly
aligned when the rv array was only 8bit. So defining it as a 16bit array
and then pointing a 8bit pointer to it seems to be an easy fix for now.
Ready to start working on pinport dictionary. Need to get lua code
working on a lower level handling the dictionary calls. Need it do do
things like fill out the wLength and everything for me so one doesn't have
to remember every detail about an opcode/dictionary before calling it.
Realizing code was heavily segmented based on how big/many operands there
were and how big the return data was. This is hard to maintain, need lua
to resolve this issue, and make everything easier to script. Thinking
opcode/dictionary calls need to be more like a function call. Passing in
necessary args only, and returning data instead of succeed/fail.
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.
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.
now able to accept LIBUSB_LOG_LEVEL from commandline to turn on/off error
messges at runtime. Also setting level > 0 will print messages during
device discovery and connection. Still need to permit kazzo firmware
version to be provided on commandline to support K flag.
fixing dictionary call typo with semicolon and setting buffer length
to always be provided with function call instead of dictionary call
deciding what it should be based on the opcode.
Adding some speed notes and other speed related discussions to buffer
dictionary.
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.
Trying to prevent transfer from exceeding buffer size.
Also verifying buffer's status is properly set to enforce upholding of the status.
Giving usbFunctionWrite a means to communicate it's error/success back to host with USB 'dictionary'.
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)
Zorchenhimer
Paul XPS
Peter Piwowarski