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
Also added swim reading of stack bottom for CICOp signature.
Starting to add scripts for different mappers.
Need to clean things up quite a bit as everything was a bit of a hack just
so I could start building lizards and A53.
Need to add back NROM, and add UNROM as well.
Need to have program find bank table for itself both in the program and in
a cartridge.
Having problems with SWIM on new discrete NES boards for some reason.
Some boards are flakey and I march right in and start writting to config
bytes which will brick the device if communications are failing (and
there's no reset pin...) as is with the stm8s001
Modified flash/dump scripts to be more generic accepting mapper/memory
args and file names. Then they only handle the buffer and file
operations.
Created scripts/nes folder for holding all mapper scripts. Currently only
nrom.lua is working and verified with inlretro6. Found issue where the
very first byte read from PRG-ROM was garbage. Narrowed it down to lower
address byte not settling in time, added NOP and resolved issue.
Still need to test on original kazzo and stm adapter, planning to do that
after this commit.
Next task is to get BNROM working so I can start getting to work on lizard
builds while taking advantage of speed boost!
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!
boards for SF2 builds. Not necessarily the most clean, but it was
stable and worked well.
Need to get swim comms working on other board designs.
Need to come up with better swim activation with more exact timing.
Still need to implement swim comms on avr, hopefully that doesn't prove
to be too much of a PITA... Not looking forward to that. Can probably
only handle low speed, and faking pullup may not work as well without
time on it's side @ 16Mhz...
-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..
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.
prototype which has STM8 CIC driving flash /OE with inversion of SYS /RST.
STM8 CIC is running at 16Mhz, and doesn't actually function as CIC. Still
need to come up with special way to signal to CIC that it's plugged into a
programmer and not a console.
Things aren't as fast as they could be, but they're good for now and
proved working on all kazzo versions. Expecting decent speedup could be
aquired by optimizing the flash routine, not changing address unless
needed, or only changing low byte of address, etc. Could also let the
host put the flash chip in unlock bypass mode and keep it there until done
with flashing.
Current speeds:
INL6: 42.2 KBps flashing, 92KBps dumping
stm adapter: 25.3 KBps flashing, 96KBps dumping
AVR kazzo: 18.0KBps flashing, 14.3KBps dumping
Was able to get the inl6 up to 59KBps flashing. Which was 35sec total
flash time for 16mbit chip which has typical flash time of 22s plus
overhead. This got slowed down when supporting stm adapter as checks for
buffer status were required from what I recall. Also fixing flash polling
routine AVR found slowed things down.
Was able to get 140KBps dump time on inl6 with 16mbit SNES flash. This
was slowed when supporting stm adapter which brought out issue with stm32
usb driver. Locks up the device if the buffer isn't fully dumped prior to
calling. Need to get driver to support sending NAKs until data is dumped.
Current fix for checking buffer status slows things down for all devices.
AVR brought out issue with SNES v3 design where we can't rely on flash
poll data to toggle between reads as /OE and /CE are stuck low. Have to
toggle /RESET slowly to toggle /OE and ensure we don't move on to next
byte until previous is fully flashed.
STM32 found initial issue where /WR should be set low first to set
direction of data level shifter, then set /ROMSEL low to enable level
shifter output. Not doing this caused bus conflicts between the two
causing flakey writes where not all bits were getting cleared.
lua scripts currently force SNES, need to add smart check that identifies
SNES flash board if vector data is 0xFFFF. Also funky order where it
always erases after flashing as this was more convient for testing.
While this commit is far from ideal, it's stable and I've done my best to
not commit junk that will cause problems later. Just make sure to always
verify dumping algo before assuming something is wrong with writes!
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.
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..
Learned lesson yet again to stop putting logic inside ADDR/DATA port
macros. The expansion of putting logic inside those is hard to predict,
it ends up varing based on mcu hardware.. Just don't do it!!
Have some cleaning up on buffer.c that's needed. Currently have to give
the device some time to dump buffer prior to calling payload. The buffer
manager should be able to handle this itself! Also don't think I should
have to reset raw buffers and reallocate from scratch between PRG/CHR
dumping! But that's currently the case. It works for now on AVR kazzo
and STM adapter & inlretro6.
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.
Paul XPS