External Storage Options

[sburrow]

Hello everyone!

Most if not all of the 6502 computers from the 80's had tape, floppy, and/or carts. What are today's replacements for those?

I've been researching a little bit, and searching the forum, and I'm going to make a small list of possible ways to store data externally. This would be for things like BASIC programs the user types up, games, and other things that need to be used at a later date. Some of these ideas are better than others:

1) Old school tape or floppy drives.
Pros: It's retro!
Cons: Because most computers today do not use those, you are kind of creating a bubble environment.

2) Serial port through UART. This could be RS-232 or variants using USB.
Pros: All computers have USB, and some have an actual serial port.
Cons: There is overhead with required chips, either being MAX232's, 6551's, or daughter/breakout boards.

3) Writing to an EEPROM or Flash ROM.
Pros: Since EEPROM's like the 28C256 can just be written to, very little modification is need to store data.
Cons: It's not designed for that, it won't last forever, and it's not really 'external'.

4) Cartridges. This is basically like the EEPROM but with the idea that you can plug/unplug it.
Pros: Same as the EEPROM, you can just write to it as if it were RAM or something, simple to do.
Cons: Again same cons as EEPROM, and you won't be reading data off of that cart to another computer. One way street.

5) SD cards. Typically using SPI interface (as far as I've seen).
Pros: All computers can read/write to SD cards somehow, sometimes through USB adapters.
Cons: Similar to serial port, and file type overhead is something to look out for.

Honestly, that's all I could come up with right now. I'm thinking here about generally available ways to doing this today. And I'm sure there's a way to send/grab data from a USB thumbdrive, but I wouldn't know where to start.

Thoughts? Additions? Corrections?

Thanks everyone!

Chad

[drogon]

sburrow wrote:

Hello everyone!

Most if not all of the 6502 computers from the 80's had tape, floppy, and/or carts. What are today's replacements for those?

I've been researching a little bit, and searching the forum, and I'm going to make a small list of possible ways to store data externally. This would be for things like BASIC programs the user types up, games, and other things that need to be used at a later date. Some of these ideas are better than others:

1) Old school tape or floppy drives.
Pros: It's retro!
Cons: Because most computers today do not use those, you are kind of creating a bubble environment.

There is the issue of the actual hardware - both on the CPU side and the actual physical floppy drive (and media). The latter - drive + media can be solved by a "GoTek" or similar unit though...

Quote:

2) Serial port through UART. This could be RS-232 or variants using USB.
Pros: All computers have USB, and some have an actual serial port.
Cons: There is overhead with required chips, either being MAX232's, 6551's, or daughter/breakout boards.

Easier to get hold of and program than the old FDC controller ICs though - the flip side is writing a filing system that uses a serial protocol - actually not that hard but still needs to be done.

Quote:

3) Writing to an EEPROM.
Pros: Since EEPROM's like the 28C256 can just be written to, very little modification is need to store data.
Cons: It's not designed for that, it won't last forever, and it's not really 'external'.

Floppys weren't designed to last forever either - however, SPI EEPROM (and lets face it, an SD card is just a fancy SPI eeprom!) are not hard to setup and use - but - see above - you still need to serialise access to it to create a filing system - and arguably if you can use a serial port then you can apply the same style of interface to an SPI interface.

(And yes, there are some parallel flash devices - some even look like a classic IDE drive...)

Quote:

4) Cartridges. This is basically like the EEPROM but with the idea that you can plug/unplug it.
Pros: Same as the EEPROM, you can just write to it as if it were RAM or something, simple to do.
Cons: Again same cons as EEPROM, and you won't be reading data off of that cart to another computer. One way street.

Not a lot I can add here...

Quote:

5) SD cards. Typically using SPI interface (as far as I've seen).
Pros: All computers can read/write to SD cards somehow, sometimes through USB adapters.
Cons: Similar to serial port, and file type overhead is something to look out for.

See above - although now I re-read this, I suspect you meant parallel EEPROM devices above. Realistically it'll never wear out in the lifetime of your retro computer.

Quote:

Honestly, that's all I could come up with right now. I'm thinking here about generally available ways to doing this today. And I'm sure there's a way to send/grab data from a USB thumbdrive, but I wouldn't know where to start.

Personally, I think that writing a USB driver, then USB Mass-Storage module on-top of that and interfacing it to a retro PC is just too much.

However there are some devices like this: https://www.hobbytronics.co.uk/usb-host-board-v24 that may help...

Quote:

Thoughts? Additions? Corrections?

I don't know what the "holy grail" might be although one thing I might suggest if using some sort of removable media (like SD card) might be to use a simple FAT filing system - much as it hates me to say it. At least that way you get the ability to easily remove it, plug it into a "PC" for easy file transfer... I sort of regret designing my own filing system for my Ruby project, but at the same time it gave me more flexibility. I'm looking at the Minix filing system for my next project as that can still be read under Linux... (and will retro-port it to Ruby in time)

Hope you find something that works for you.

-Gordon

[sburrow]

drogon wrote:

See above - although now I re-read this, I suspect you meant parallel EEPROM devices above. Realistically it'll never wear out in the lifetime of your retro computer.

Ah, good point. And like you said, SD cards are basically serial EEPROM's. I like "realistically", that a hopeful word!

Quote:

I don't know what the "holy grail" might be although one thing I might suggest if using some sort of removable media (like SD card) might be to use a simple FAT filing system - much as it hates me to say it. At least that way you get the ability to easily remove it, plug it into a "PC" for easy file transfer... I sort of regret designing my own filing system for my Ruby project, but at the same time it gave me more flexibility. I'm looking at the Minix filing system for my next project as that can still be read under Linux... (and will retro-port it to Ruby in time)

Gotcha. I was reading up about the FAT file system some. I saw someone use literal 'raw' data somewhere on reddit as well.

Quote:

Hope you find something that works for you.

Just a general discussion here! Nothing specific for any particular project.

Good info, thanks Gordon!

Chad

[plasmo]

Well, don't forget the traditional parallel (PATA) hard disk and compact flash (CF) disk.

I myself use CF disk extensively for mass storage. It is 8-bit (actually 16, but can work as 8-bit) data port, 3 addresses plus 3 control signals (read/write/select). Disregarding the filing system, a raw CF disk is just many 512-byte blocks addressable by setting 3 registers, a command register, and a data register. It is easy to interface with 8-bit or 16-bit processors. Now you are comfortable with CPLD, you probably can envision a scheme to boot from CF disk without EPROM.
Bill

[sburrow]

plasmo wrote:

Well, don't forget the traditional parallel (PATA) hard disk and compact flash (CF) disk.

I myself use CF disk extensively for mass storage. It is 8-bit (actually 16, but can work as 8-bit) data port, 3 addresses plus 3 control signals (read/write/select). Disregarding the filing system, a raw CF disk is just many 512-byte blocks addressable by setting 3 registers, a command register, and a data register. It is easy to interface with 8-bit or 16-bit processors. Now you are comfortable with CPLD, you probably can envision a scheme to boot from CF disk without EPROM.
Bill

Hm!

The CF Disk seems easy to remove and then transfer files between computers, if you use a little USB adapter on the PC end. That's a good idea!

The PATA is also an excellent answer. Though a bit large and clunky it would definitely allow transfer to/from a PC.

Excellent ideas Bill, thanks for this input.

Chad

[rwiker]

For PATA, there are also solid-state modules. I got one of those for my C256Foenix as an alternative to a somewhat noisy laptop drive.

This may also be of interest: https://github.com/FujiNetWIFI/fujinet-platformio/wiki

[BigDumbDinosaur]

sburrow wrote:

Most if not all of the 6502 computers from the 80's had tape, floppy, and/or carts. What are today's replacements for those?...

One thing I didn't see mentioned in your “shopping list” was level of performance. How important is that to you? If it is of any importance then using EEPROM as a storage solution is going to disappoint you to some extent.

I implemented SCSI with my POC units, which gave me access to the world of high-capacity, high-speed hard drives. The driver I have running in POC V1.3 implements 32-bit logical block addresses. Translated to what a disk can store, that means a maximum of 2 terrabytes is addressable. To date, I've gotten the interface running at 660 KB/second on hard disk reads, and nearly 800 KB on writes.

[Agumander]

sburrow wrote:

4) Cartridges. This is basically like the EEPROM but with the idea that you can plug/unplug it.
Pros: Same as the EEPROM, you can just write to it as if it were RAM or something, simple to do.
Cons: Again same cons as EEPROM, and you won't be reading data off of that cart to another computer. One way street.

Another pro for cartridges is that you can change your storage method/hardware without having to rebuild or redesign your base system. My project started out using just 8K EEPROM cartridges but later I was able to design a compatible 2MB Flash cartridge. You can also put a battery-backed SRAM for storage that can be easily re-written.

[sburrow]

BigDumbDinosaur wrote:

One thing I didn't see mentioned in your “shopping list” was level of performance. How important is that to you?

Just a general discussion BDD, tossing ideas out there, thinking things through. I didn't see a good one-stop-shop for this type of 'problem', so I figured I strike up a conversation about it!

As for everyone else, good input, and thanks!

Chad

[BigEd]

There are two three approaches for what we might call connected storage.

- serial cable to a PC, running a fileserving protocol (e.g. HostFS)
- serial cable to a PC, accessing a disk image (e.g. UPURS)
- serial connection to a small wifi-enabled machine, running fileservice over http (e.g. WiDFS)

I think these are a bit different from, say, using a serial connection to download srecords, or poke into memory using a monitor, or using zmodem or similar.

[GARTHWILSON]

sburrow wrote:

3) Writing to an EEPROM or Flash ROM.
Pros: Since EEPROM's like the 28C256 can just be written to, very little modification is need to store data.
Cons: It's not designed for that, it won't last forever, and it's not really 'external'.

The question of speed has been brought up. How about data size? A few KB? A few hundred KB? Tens of MB? A GB or more? [Edit: In re-reading, I see you said, "This would be for things like BASIC programs the user types up, games, and other things that need to be used at a later date," which probably means less than the "a few hundred KB" category, probably a few tens of KB max.]

I don't do much of this with my workbench computer, but I have used my tiny I2C-6 EEPROM plug-in modules (meaning they can be external), not with any file structure so far, just keeping a separate log of what's on each one and what addresses those things start at. Since they're much too small to write what's on them with a pen or pencil (like we used to on floppy-discs' labels), I only write a serial number on each, which so far has not gotten out of the single digits (#1, #2, #3, etc.). I²C is much slower than SPI, so I²C EEPROMs are not very dense (topping out at 128KB last I checked), because it would take much too long to store a photo on a digital camera for example if it had to use I²C. These serial EEPROMs supposedly offer 200-year data retention and a million erase/write cycles (although I suspect the data-retention time drops as you increase the number of erase/write cycles). I think, but am not sure, that the number of cycles is for particular bytes or sectors, not the whole thing; meaning the number of total writes would be much, much higher as long as any given byte or sector is not written more than a million times. viewtopic.php?p=19043#p19043 as a full description of the hobbyist-friendly I2C-6 connector and a picture of my earliest 24C256 tiny EEPROM module. I believe Daryl (forum name 8BIT) offers bare tiny PCBs for these. I have a couple of his that measure 1/2" x 5/8".

I also show my tiny SPI-10 flash or FRAM memory module, again very hobbyist-friendly, at about the middle of the front page of my site. The ones I've built up for myself are 4MB (32Mb). That doesn't sound like much by today's standards, but it's still something like 24 Commodore 64 floppy discs' worth, and denser ones can be put on the same tiny boards. I have exercised these to make sure I understood their operation, but have not put them to serious use yet. viewtopic.php?p=48167#p48167 has a full description of the hobbyist-friendly SPI-10 connector.

I started a topic on super-simple file systems for flash memory which has seven posts at https://bradsprojects.com/forum/viewtop ... 233&p=6739 on the Brad's projects forum. I probably should have done it here on 6502.org instead, but didn't because it wasn't particularly related to 65xx. The Brad's projects forum has software problems now and Brad seems to have been AWOL since he is no longer pushing the forum for his electronics students' use. I have not been able to get hold of him. [Edit, a couple of months later: I got hold of Brad. He says he doesn't know how to fix it.]

[BigEd]

Worth copy-pasting that thread here, Garth, before that forum disintegrates. You have my permission to copy my contribution. The other contributor is Brad himself, fortunately his posts could be omitted without losing the sense of the thread. (So no need to wait for him to give permission - if he gives it later you can paste in his posts too.)

[BigDumbDinosaur]

GARTHWILSON wrote:

sburrow wrote:

3) Writing to an EEPROM or Flash ROM.
Pros: Since EEPROM's like the 28C256 can just be written to, very little modification is need to store data.
Cons: It's not designed for that, it won't last forever, and it's not really 'external'.

The question of speed has been brought up. How about data size? A few KB? A few hundred KB? Tens of MB? A GB or more?

Although not immediately obvious, speed and data size tend to not be mutually-exclusive considerations.

As the capacity of the storage medium increases, the rate in which the storage device can access a give block of data (I'm cheerfully assuming the storage device is capable of random access) will tend to limit usability. This especially will be true if the storage medium is organized into a filesystem.

In processing a filesystem, disparate areas on the medium must be accessed to find a place to store the data and actually write it. Later on, disparate medium locations must be accessed to figure out where the desired data was stored and then read and deliver it to the host. Taken individually, those steps may not consume much wall-clock time. However, the effect of scale will get into the picture with repeated accesses and the practicality of being able to address capacious storage may be subverted by long access times.

It's wise to consider mass storage performance as related to storage size if the performance of the resulting system is to be tolerable.

[GARTHWILSON]

BigEd wrote:

GARTHWILSON wrote:

I started a topic on super-simple file systems for flash memory which has seven posts at https://bradsprojects.com/forum/viewtop ... 233&p=6739 on the Brad's projects forum. I probably should have done it here on 6502.org instead, but didn't because it wasn't particularly related to 65xx. The Brad's projects forum has software problems now and Brad seems to have been AWOL since he is no longer pushing the forum for his electronics students' use. I have not been able to get hold of him.

Worth copy-pasting that thread here, Garth, before that forum disintegrates. You have my permission to copy my contribution. The other contributor is Brad himself, fortunately his posts could be omitted without losing the sense of the thread. (So no need to wait for him to give permission - if he gives it later you can paste in his posts too.)

I agree. I put it at viewtopic.php?f=1&t=7009 . I left Brad's posts, because it was a public forum and not a PM or email.

[thegoat]

Hello, been lurking around for quite some time and never really post anything!

I've built a couple 65c02 based single board computers with 65c22's for I/O. My storage solution was to use a Commodore disk drive, which also means I can use an SD2IEC drive that uses SD cards. Going this route seemed the easiest, since the DOS is built into the Commodore drives. The Commodore serial bus was built with a 6522 on the VIC20 (and a 6526 on the C64, both controllers are quite similar), and I only needed a 7406, and IEC plug and some 1k pullup resistors to make the hardware. I use the Kernal I/O code from a C64 ROM disassembly to communicate over the IEC bus. It's pretty cool to use your own home made computer with 5.25" floppies! I mostly use the SD2IEC for coding, since I can write my code on a Windows laptop and easily copy the binaries to an SD card that I just insert into the SD2IEC and read with my 65c02 computer. I have a fondness for the C64, since the OS on my computer's EEPROM is a port of Supermon64 by Jim Butterfield! I re wrote the load and save commands and added commands for disk directory and sending commands to the Commodore drive. Pretty fun, just a matter of using what hardware you have available.