Commit Graph

14 Commits

Author SHA1 Message Date
Paul XPS e3d0ec434e Have the USB code effectively separated from the main application code!
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)..?
2018-11-27 23:26:26 -06:00
Paul XPS d0c8ab82fe Moved usbMsgPtr to usb_buff ram successfully.
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.
2018-11-27 02:00:47 -06:00
Paul XPS 86e8d3d215 Big old first major commit since publicly releasing..
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..
2018-11-09 21:52:33 -06:00
Paul Win10 shuttle PC 25c159c27f Final commit for firmware version 2.01 first public release
Host does not require v2.01 over v2.00
2018-09-07 09:13:39 -05:00
Paul Win10 shuttle PC 88a2d30858 Massive commit with bunch of random junk..
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.
2018-09-06 23:01:59 -05:00
Paul Black ASUS win7 9c57f1bdb3 Massively overdue commit of several months worth of random work.
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
2018-07-08 20:23:44 -05:00
Paul blue asus fafe706481 Another late commit from bunch of updates I made over a month ago..
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.
2018-02-13 14:36:43 -06:00
Paul blue asus 535b45be27 Committing working build that was used for flashing STM8 SNES v3.1
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...
2017-12-20 09:28:01 -06:00
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 dfeaf960ef commiting files as they were left a couple weeks ago..
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!
2017-08-20 16:38:12 -05:00
Paul Molloy ea5f1d9842 Creation of pinport abstraction layer to make firmware more generic to the
underlying hardware/mcu.  Created avr_gpio.h to define AVR pin registers
in a struct fashion similar to what's common with ARM code.  Doing that
makes things much easier to abstract in pin macro 'functions'.

Added define to Makefiles that flags pinport_al.h which board is targetted
for build.

Tested and able to turn on/off and pull-up LED on all 3 builds.
2017-07-22 23:58:16 -05:00
Paul Molloy 750ab2f082 Creating one Makefile that calls the other makefiles as shortcut 2017-07-22 17:26:44 -05:00
Paul Molloy 3779afe88d Successfully building avr & stm core with one set of files.
Two different Makefiles, specify which with -f file flag:
make -f Make_avr clean program
make -f Make_stm clean program

made release dir to put released .hex firmware files
Need to make separate avr build folder
Need to make one master Makefile that calls one of the other makefiles as
instructed.

Currently device is recognized by PC but does nothing else other than
being recognized by app during connection process:

arm-none-eabi-size -t build_stm/inlretro_stm.elf
text    data     bss     dec     hex filename
1332       0      20    1352     548 build_stm/inlretro_stm.elf
1332       0      20    1352     548 (TOTALS)

avr-size avr_kazzo.elf
text    data     bss     dec     hex filename
1496       2      43    1541     605 avr_kazzo.elf
2017-07-22 17:03:23 -05:00