Continuing the discussion from Z80 Retro Musings:
I thought a new thread might help.
SD Cards are a well-used option in the land of 8 bit Acorn, and I’m sure elsewhere too.
Disk-on-module (DOM) adaptors seem like they might be a suitable modern alternative to Compact Flash, if that’s now more difficult than it used to be. See for example IDE 40pin to 44pin DOM adapter
Yes: SD interfacing is quite simple, and here’s a Canadian supplier for that ubiquitous cheap 5V-safe µSD to SPI interface: Micro-SD Memory Card Adapter for Arduino with 3.3V-5V converter ($1.59! And they use inexpensive couriers while Canada Post is on strike).
Finding specific obscure storage can be a thankless task. Once storage gets to a certain age and rarity, a certain group of industrial users will dedicate time and expense to securing their media for their valuable older machinery. For example, PCMCIA SRAM cards (as used on my Amstrad NC100 Z80 tablet) are also used by some very expensive multi-axis machining centres. Guess who has hoovered up most of the remaining modules?
Yes: SD interfacing is quite simple, and here’s a Canadian supplier for that ubiquitous cheap 5V- safe µSD to SPI interface
I have something like that on order. Finding the bit banging code, might be harder
as all that stuff is hidden in developers libaries for uControlers.
Finding specific obscure storage can be a thankless task.
I notice on Amazon there are a lot of floppy emulators and fair number of real drives and media.
Little use for me, as I have 9 bit i/o. With CF I can use 9 out 16 bits giving 256 bytes rather than 512
bytes per sector.
I am thinking that the main reason the CF flash interface may not work with new cards is I am using 5 volts rather than 3.3 volts. I have found a wintec 128 CF that was said to work, but that will not be until mid week.
SD is relatively easy for microcontrollers or retro computer systems. e.g. I use one on my 6502 and 65816 systems.
The trick for them is to stick to SPI mode, but that’s more than fast enough for a retro system. 1MByte/sec is trivial to achieve with an ATmega running at 16MHz. (The limit there is the max. speed of the SPI clock; F_CPU/2).
Also, the code is all in the public domain. There are no hidden libraries.
-Gordon
But what works?
Do you leave the clock high or low after you shift 8 bits?
You ought to look at the Arduino code for driving the SPI interface and read/writing an SD card. That’s what I started with then wrong my own.
There is a tonne of documentation out there on driving SD cards in SPI mode.
-Gordon
I have http://elm-chan.org/ bookmarked from years ago.
It is just I don’t want to be bitten by hidden got ya in the serial read,
write routines. Arduino code I have seen, I can’t seem to find
where the low level read/write routine are. The 6502 code
leaves the clock high on the last shift, Elm-Chan has it low.
The hardware I am designing, will also leave the clock in a low state.
state 0 wait for write_byte_sd_card
if write set busy,load shift register, go to state 1
else say in state 0
state 1, set clock high.
state 2,hold clock
state 3.set clock low
state 4, shift data in, shift data out, clock counter.
if counter == 7 clear busy flag. go to state 0
else state 1
My CF seems not reading data at all now. Back to the drawing board.
I have implemented a SD card interface and that needs testing,
after I finish populating a new mother board. This has a remote front panel.
Thank you all for the help, and replies
Random question … is the hardware required to make an SD card interface for a typical 8-bit home computer possible to do really cheap? It sounds like you don’t need a microcontroller.
I ask because in the Commodore 64 scene, there’s various neat cartridges that offer interesting functionality, but they are mostly somewhat expensive and they are also available only for a limited time because inevitably the microcontroller used goes away. It’s frustrating.
The C64 cartridge bus is mostly just the system bus … 8 data lines, 16 address lines, and so on. I guess you’d need some sort of “bridge” between that and the SD card, but I have no idea what could be suitable.
There’s also a user port, but I don’t know how much speed you could squeeze out of that.
The popular SD2IEC is relatively affordable and it allows loading files through the standard floppy drive cable. However, this is slow.
A 6502 SD card reader
The problem with all media today, it is too big. You will have a hard time
fining small SD cards.
Thanks so much! It’s mostly way above my head. But if I understand correctly, the C64 has a couple 6526 CIA which can serve the same purpose as the 6522. One of these is connected to the “user port” via 8 lines. This is good, because the user port is often not used at all.
Obviously, the built in C64 ROM doesn’t know how to load stuff from the user port (the way it can auto-run software on a cartridge), but the point is the device should be cheap and people can use some other method to initially load and run software that can utilize the device.
As for the “size” … what’s wrong with being too big? Is there some problem with reading/writing the partition or file system if the SD card is too large?
This is where AliExpress comes in: there are whole rafts of vendors who sell small uSD cards. Here’s one I’ve used, but there are likely many as good: Cloudisk Office Store Store. Every last one of the 2 GB uSDs I bought from them checked out as full capacity with no errors.
They might even do smaller Compact Flash that will still have the 8-bit command interface
Ah: the C64 and its problematic disk drives. Cheap doesn’t apply here.
The drives are expected to have a 6502 plus all sorts of other control logic. So you need more than an SD card, and quite often some level of 6502 emulation. Even then, you’re going to make all the fast-loaders fail.
I don’t think anyone’s done the needful yet with a Raspberry Pi Pico handling the emulation, but maybe it’ll happen. Then again, there’s someone selling as many 1581 replica floppy drives as they can make, so the C64 market is weird.
64 or 128 meg is just about right for CP/M.
Any one care to write a paper or mag tape emulator?
I can build a vintage CPU, but the 70’s surplus is long gone,
My goal isn’t to replicate drive functionality - the relatively affordable and extremely popular SD2IEC already does that. There are other solutions which offer better 1541 floppy emulation and speed also.
One of them is indeed pi1541, a Raspberry Pi based cycle exact 1541 emulator. It’ll work with fastload solutions, but obviously it’s still limited to the slow speed of the IEC bus.
In contrast, something in a cartridge or maybe user port could be one or two orders of magnitude faster. This wouldn’t be “compatible” with normal floppy drive loading/saving of data. It would be some sort of special addition that new software could take advantage of. Or old software could be modified to take advantage of it.
The point is - if it’s cheap enough than many users would buy it even if it doesn’t initially have much software support.
You don’t have to use it all!
The first iteration of my own filing system for my 6502 project partitioned an 8GB SD card into 4 x 32MB partitions to resemble ProDOS volumes.
And left the rest alone.
It worked very well.
-Gordon
I like smaller for the simple reason I only need to worry about standard cards,
not high density for programming. On the other hand I have a old camera,
that only takes standard SD cards, not the micro SD cards.
I gather there are technical differences between SD and SDHC: for example whether addresses are (or can be) sectors or bytes. See perhaps How to Use MMC/SDC (via here)
A pull-up on the DO cannot be omited, or some cards will fail initialization process.
I added a 10K pull up, to the SD card pcb. After fixing some logic bugs like not gating with VMA,
I got it to initialize the card. Since it works so far I am leaving it in.
