Adding tape storage

[cskordis]

Hi,

I have built one of Grant Searle's 7-chip 6502 computer based on his modified OSI Rom with Load and Save "nulled"

Is there an easy way to implement Load and Save and add the required circuitry to use a tape recorder to save and load code.

If so can anyone help me with the schematic and code.

Thank you.

[BigEd]

Welcome! My first machine was a Compukit, some kind of clone of an OSI Superboard. Load and save at the software level is "just" redirection of the I/O to/from the UART. So, add a UART. Then, on the far side of the UART, you need the modulation and demodulation - you could take that from page 20 of the manual, here:
http://www.compukit.org/images/8/8e/Compukit-manual.pdf

(These machines used a fairly standard and reliable modulation scheme called CUTS - I expect you can do the job with less hardware if you use a scheme like Woz' for the Apple I, or like the one Commodore used.)

[BigEd]

For reference, here's the Apple I interface:
http://www.applefritter.com/?q=node/6889
via
http://www.applefritter.com/?q=node/6886#comment-16748
but note fixes in
http://www.willegal.net/appleii/aci.htm
and see also
http://www.pagetable.com/?p=32

[GARTHWILSON]

We had a tape modem topic at viewtopic.php?f=4&t=82&p=463#p463 14 years ago.  I can probably find the schematic of the tape modem I designed for work in the 80's which used kind of a lot of parts but all of them together came to a dollar or less.  I'll need some time to find it and clean it up and make it presentable.  It looks like I was using the Kansas City standard that Ed referenced, although I didn't know it at the time.  Experimentation led me to come up with it, not knowing I was re-inventing the same thing.

I've frequently read that tape playback level was pretty critical on many systems.  On mine, it didn't matter, because I used a huge amount of gain to get it up to clipping anyway to turn it into a square wave.  It was very reliable, and I never had an error at 300bps.  Gong twice as fast, 600bps, there would be a wrong bit every few K.  If you can modify your tape transport to move the tape faster, you could safely get the data rate much higher, two, four, or maybe even eight times as fast (subject to head limitations and tape handling ability).

At this point though, if you can implement I²C for serial EEPROMs or SPI for flash (basically by adding a 65c22 VIA to your board, you can get away with

• lower cost
• faster speeds
• smaller size
• better reliability
• essentially random access (compared to tape which has to be wound)

all at once.  The 65c22 VIA will give you a lot of I/O bits left over for other things too since the I²C or SPI won't need nearly all of them, and you'll get timers and other benefits as well.

As much as I like tape recorders, I have to say they're no longer a viable data storage method, especially when you consider the fact that they use rubber belts that rot over time and replacements are no longer available.  [Edit, years later:  I find that there are places that still sell them online.  I don't know if they're being made, or if it's old stock.  One place is here.]  When I worked at TEAC, we would always replace the rubber parts (belts, idlers, pinch roller) when a tape recorder came in for repair, regardless of what it was there for, to extend the life concerning those parts, since we'd have the machine open anyway.

I and Daryl (8BIT) have used I²C EEPROM modules made to the I2C-6 connector standard.  Mine look like this:

EEPROMmodule.jpg (10.59 KiB) Viewed 1035 times

You can see the 8-pin DIP under the translucent heat-shrink.  These top out at 32KB for simple addressing, and, I believe, 128KB for addressing them as four 32K's in one IC.

More recently, I've used our SPI-10 hobbyist-friendly connector standard and I have the tiny PCBs for these flash modules shown on the front page of my site available to supply to others.  If you just want a few, the cost is hardly more than just the postage.  They're about half the area of an SD card, but the flash memory that goes on them (I'm using 4MB ones in SO-8) is much simpler to interface to in terms of your software.  Here's a picture, comparing them to the size of SD card and Compact Flash:

The one slight drawback about the flash modules though, unlike the I²C ones, is that they require 3.3V, so you'll probably have to do voltage translation, which is easy to do since there are only four signal lines and none of them are bi-directional.  (You'll need a fleapower 3.3 power supply of some sort too.  I've use an LM317LZ in a TO-92 case.)

[whartung]

Also, most folks simply "capture" the listings using their terminal software, and then upload (or just paste them in to the terminal window) them back in later on for "save" and "load" functionality.

If you're looking for a practical method to save and load programs.

[Martin_H]

Neat looking perf board SBC. You should include a picture of the underside so we can marvel at the wires going every which way!

[cskordis]

And the underside of wire wrapping nest!

[jim30109]

The "load" and "save" functionality that was originally there was pretty basic. (I had an OSI back then and lived with the limitations.)

The original Kansas City standard circuit used by OSI was pretty straight forward and is in the schematics for the C1P. But, like others have pointed out, it doesn't add much real functionality beyond what you can do with most terminal programs.

I have tinkered with Grant's source code a bit and one thing I would suggest is taking a look at that. The commands are nulled out, but there is also only a fairly limited space left in the ROM.

Originally the OSI had a ROM with support for a monitor, bootstrap, and basic I/O. Then there was a separate 8K BASIC ROM (actually 4 ROMs with 2K each).

Grant was able to fit the basic I/O functions into the 8K space so it only requires a single ROM. If you start tinkering much with I/O you will run out of space pretty fast. It isn't hard to move to a 16K ROM or something similar, but in addition to another ACIA for a tape interface you would need to map in more space for ROM if you wanted something that mirrored the functionality that was originally there.

Having tinkered a bit, I would say that I would lean towards and enhanced monitor and EhBASIC in a 16K ROM instead of trying to cram everything into a single 8K ROM. Grant did it for good reasons, but his goal was a minimalist approach. If your goal is to enhance the system with some new features, some of the design assumptions he made won't hold for you.

If you haven't, you might want to look at his Multicomp FPGA project also. I was amazed at how smooth that went and it makes a second ACIA (or using the first ACIA for tape and having a composite video output and PS/2 keyboard input for the main user interface) fairly easy. But I did run into the same 8K ROM limitation when I started trying to add some features and have ended up moving to an FPGA platform that can handle a larger ROM size onboard.

Thanks,
Jim

[mkl0815]

cskordis wrote:

Hi,
I have built one of Grant Searle's 7-chip 6502 computer based on his modified OSI Rom with Load and Save "nulled"

How did you connect the both ATMega for video and keyboard to the rest of the system? Are they connected to the 6850 ACIA?
If so, how do you distinguish between RS232 and Keyboard data over the same serial line?

Mario.