Commit Graph

3 Commits

Author SHA1 Message Date
Paul Molloy 0dd8828744 Long over due commit...
-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...
2017-10-22 17:09:21 -05:00
Paul Molloy 5ceb148c85 Have SNES flashing and dumping working for all 3 kazzos on SNES v3.0p
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!
2017-08-24 13:41:08 -05:00
Paul Molloy 4b3c822a24 Have basic SNES cart detection and dumping working. Dumping mario paint
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.
2017-08-21 12:30:39 -05:00