I'm building a home-brew system based on the OSI Superboard II that I started with long ago (HW details in this thread: http://forum.6502.org/viewtopic.php?f=10&t=5559 ) and one of the things I'd like to improve is the process of saving and loading programs. The original OSI approach was that SAVE just piped text output to the ACIA and thence to the FSK modulator for tape output. The user would then LIST which would spew the code (with some NULLs added after every carriage return to allow BASIC some time to parse the line) and when the listing was over you'd hit the space bar to stop the pipe to serial. LOAD worked similarly, redirecting serial input from tape, with a tap on the space bar to bring the focus back to the keyboard after the stored text was complete.

For my new system I'm going to use a large SPI flash memory instead of serial tape. BigEd pointed out that storing code as untokenized text is most portable and I agree, but that presents a bit of a challenge in getting the human-readable code out automatically. The original MS BASIC code doesn't treat the LIST command as a callable function so I can't easily hijack it.

What I've done is to copy most of the code for LIST and wrap my new SAVE code around it. SAVE now has an argument that lets me specify a "slot" in flash memory that can save up to 32kB. This is bounds checked and then converted to a starting address in flash. Then I hijack the BASIC text output vector and redirect all output to my flash write routine. I generate a listing which is then saved to flash. When the listing is complete I restore the normal output vector.

For LOAD I also take a slot argument, convert it to a memory address and set up to read the flash. Then redirect the input vector to my flash reader and return. When BASIC next asks for a key it gets the stored text from flash until the end of the code is detected (the natural $FF that blank flash contains). At that point I restore the input vector and the LOAD process is over.

This is basically working now, but it's been an interesting bit of research to safely hook in to the ancient BASIC. I've made a lot of use of the "unofficially released" source code that's out there and studying Paul Allen & Bill Gates' code has been enlightening. Now I just need to poke at it some more and see if it's reliable.

Anyone else tried this sort of thing?

This sounds good to me! I'm not sure how EhBasic handles loads and saves, but it might be similar (in using LIST, not in having a flash interface!)

From what I know, ehBasic has built-in SAVE & LOAD commands, but they're effectively dummy commands - there are some ways to leverage them to e.g. parse a filename and you can then get the tokenised program start and end address fairly easy.

I've not tried what you're doing, but be content in the knowledge that what you're doing has already been done, tried and tested and used for a long time by ... Apple. So you're doing the right/best thing by all accounts...


What Apple DOS did was to intercept the character in & out vectors and peek the command-line when you hit 'Return', scan that line (fixed input buffer at $200), looking for a command and if it saw a command (e.g. LOAD filename), then it would take over, do the disk thing, load the file into memory, initialise the Applesoft program start and end pointers, then return a blank line to Applesoft, so Applesoft didn't know any different. Same for SAVE. EXEC was the command to read in a text file - that just fetched lines from a file and put them into the text input buffer and let whatever had called the input routine handle it.

From inside a program it was slightly different - Ctrl-D was the magic character, so DOS was watching the output stream, looking for CR + Ctrl-D then it would suck up the next line of text, try to interpret it and off it went. You'll see almost all Apple programs that did file handling have: D$ = CHR$(4) ... then PRINT D$;"OPEN FILENAME" ... and so on.

Intercepting the character IO hooks can let you do all manner of clever things - it's a great technique.

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

OK, thanks for the insight - nice to know I'm not totally out to lunch here.

Studying the MS BASIC source has given me all kinds of other ideas now. Although the original OSI version of BASIC was one of the least feature-full flavors of the language, my hardware supports additional gee-whiz features like bitmapped graphics and sound. I was always jealous of more up-scale systems that had graphics and sound functions in the language and now I'm starting to think about how to add those. There's always the USR() function which could be overloaded to handle a whole raft of additional features, but the sweetest deal would be to put in actual DRAW and SOUND functions. Looking into the way that keywords are handled it doesn't seem like it would be too tough to hack new ones into the language at the lowest levels.

Of course the cleanest way to revise the language would entail converting the ancient source file to a more modern assembler. Sounds like a lot of work - maybe when I've checked off a lot more of the existing things on my to-do list.

You might find that conversion has already been done:
https://github.com/mist64/msbasic#micro ... c-for-6502

ROFL - of course it has. Nice of them to put it up on github too.

Interesting thing is that this appears to have been converted many years before the M6502.MAC source file was widely available and a lot of the labels etc are different. That suggests someone did this by reverse engineering the ROMs of all the target systems. Wow.

And they kindly put it under a BSD 2 Clause license! Share and enjoy!

My MS BASIC interfaces are up on the github repo now:

https://github.com/emeb/up5k_basic/blob/master/cc65/basic.s

This includes the modified LIST function, as well as the LOAD/SAVE routines which interface to SPI Flash.

One of the annoying things about the OSI version of 6502 MS BASIC is that the backspace function used the underline character. I've studied the MS source and made a fairly simple patch to allow it to use the actual backspace (Control-H) character. Since I load the code from flash at boot time and store it in protected RAM before running BASIC, I also apply the patch. It seems to work - with my serial I/O alternative the BS char is echoed and my terminal application handles it correctly. The OSI video driver code doesn't handle backspace correctly so a graphics glyph appears, but at least key used is normal.

Patch info is here:

https://github.com/emeb/up5k_basic/blob/master/cc65/basic.s#L423