Raven can now do in-system ROM flashing.
And now that I have that, I'm questioning how on earth I managed to cope without it for so long :)
For me, this will drastically reduce swapping of the rom simm between Raven and the programmer.
https://github.com/agranlund/raven/rele ... .A1.latest
Flashing a rom image from TOS:
1) run
c:\raven\flash.ttp <filename>
(or just drag-and-drop a rom image onto that program)
You should see the power LED blink at a steady pace while programming is in progress.
Once finished, the computer will automatically restart itself.
Note that flash.ttp depends on already running at least the version which is currently latest. Thus you're going to need to flash that one with the simm-programmer as usual and the benefit of having in-system flashing will be next time you update.
I've only had a chance to test with the 2xSMD simm so far. Let me know if there are any issues with the 4xPLCC model.
The following stuff is probably mostly interesting for programmers who work on rom related code (?)
Flashing a rom image from monitor:
1) Run the monitor 'flash' command.
2) Initate a raw file transfer of the rom image from your connected serial terminal.
Flashing a rom srec from monitor:
1) No command necessary, just send the .s19 file from a connected terminal same as you would for an srec ram program.
It will automatically detect if the srec was built for rom or ram and act accordingly.
You'll get to the monitor from anywhere by pressing the NMI button. All interactions with it are then over serial connection.
Alternatively, one can run
c:\raven\mon.tos to interact with the monitor through TOS rather than from a serial terminal.
Raven boots with the serialport configured for 115200 baud as default.
Since this is quite slow I recommend for now to locally change in "sw/rom/mon/_boot.S" to something faster if you're working in rom code and flash over serial.
Ideally this should end up being some kind of setting that is somehow accessible at very early boot stage. NVRAM isn't, so possibly flashed to a section in rom. Next board revision is getting a few cpu-readable config jumpers which could be useful for situations like this.
Or perhaps the default should just be bumped up to something faster?