6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sun Nov 24, 2024 9:28 am

All times are UTC




Post new topic Reply to topic  [ 30 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: External Storage Options
PostPosted: Wed Feb 02, 2022 1:10 pm 
Offline

Joined: Sat Oct 09, 2021 11:21 am
Posts: 718
Location: Texas
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


Last edited by sburrow on Wed Feb 02, 2022 2:41 pm, edited 1 time in total.

Top
 Profile  
Reply with quote  
PostPosted: Wed Feb 02, 2022 2:40 pm 
Offline
User avatar

Joined: Wed Feb 14, 2018 2:33 pm
Posts: 1488
Location: Scotland
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

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


Top
 Profile  
Reply with quote  
PostPosted: Wed Feb 02, 2022 2:49 pm 
Offline

Joined: Sat Oct 09, 2021 11:21 am
Posts: 718
Location: Texas
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


Top
 Profile  
Reply with quote  
PostPosted: Wed Feb 02, 2022 3:24 pm 
Offline

Joined: Fri Dec 21, 2018 1:05 am
Posts: 1120
Location: Albuquerque NM USA
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


Top
 Profile  
Reply with quote  
PostPosted: Wed Feb 02, 2022 4:24 pm 
Offline

Joined: Sat Oct 09, 2021 11:21 am
Posts: 718
Location: Texas
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


Top
 Profile  
Reply with quote  
PostPosted: Wed Feb 02, 2022 5:20 pm 
Offline

Joined: Thu Mar 03, 2011 5:56 pm
Posts: 284
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


Top
 Profile  
Reply with quote  
PostPosted: Wed Feb 02, 2022 6:47 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8514
Location: Midwestern USA
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.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Wed Feb 02, 2022 6:58 pm 
Offline
User avatar

Joined: Tue Jul 17, 2018 9:58 am
Posts: 107
Location: Long Island, NY
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.


Top
 Profile  
Reply with quote  
PostPosted: Wed Feb 02, 2022 7:41 pm 
Offline

Joined: Sat Oct 09, 2021 11:21 am
Posts: 718
Location: Texas
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


Top
 Profile  
Reply with quote  
PostPosted: Wed Feb 02, 2022 9:18 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10986
Location: England
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.


Top
 Profile  
Reply with quote  
PostPosted: Wed Feb 02, 2022 10:32 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8546
Location: Southern California
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.]

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
PostPosted: Wed Feb 02, 2022 10:59 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10986
Location: England
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.)


Top
 Profile  
Reply with quote  
PostPosted: Thu Feb 03, 2022 2:56 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8514
Location: Midwestern USA
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.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Sat Feb 05, 2022 2:20 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8546
Location: Southern California
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.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
PostPosted: Mon Feb 21, 2022 6:35 pm 
Offline

Joined: Mon Nov 15, 2021 10:17 pm
Posts: 2
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.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 30 posts ]  Go to page 1, 2  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 69 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: