Micro SD card module using shift registers

[Mark T]

After getting RomWBW running on my Z80 single board cpm proto I soon realised how limiting it was to only have a 256K Rom drive and 128K Ram drive, so I started looking at the possibility of adding an SD card module. I saw a recent design by Jay Cotton for a bit banged spi module and also in April 2017 a shift register design by Mitch Lalovie.

Link to Jay's thread:-

https://groups.google.com/forum/#!msg/rc2014-z80/NgsdIwBh-MM/6li3Qip6BAAJ;context-place=forum/rc2014-z80

Link to Mitch's thread:-

https://groups.google.com/forum/#!msg/rc2014-z80/5rH8f9fQKoY/fLuAeq5XBgAJ;context-place=forum/rc2014-z80

I've based my design on Mitch's design, copying his use of two shift registers for output and input, but modified the clock generation and trigger for the exchange.

The trigger for exchange is by the end of the output cycle of the data to write. Then the instructions for the interface would be:-

    OUT   (SDDATA),A

    IN      A,(SDDATA)

Which is only 4 bytes, so I'd plan to modify RomWBW to use a macro for these two instructions in place of the call to a subroutine to reduce overhead.

The IN instruction takes 11 clock cycles so I prefer the SPI clock to run at the same speed as the Z80 cpu. Mitch accomplished this by running a local clock at 16MHz, using a 74193 to divide by two anf generate 8 clock pulses. My design uses a 74HCT163 counter with synchronous preset and overriding clear as a simple state machine and gating the clock input via 74AHC02 to avoid shortening the clock pulses to the sdcard and level shift to 3.3v.

I've included two micro SD card sockets as RomWBW supports two sdcards, and also a pin head for one of these cards to use a simple breakout board that doesn't include level shifters. The pin header might also allow connection to other SPI devices. The micro SD card sockets are surface mount, but at 1.1mm pitch should not be too difficult to solder and I think makes for a cleaner appearance than breakout boards.

Level shifting uses the 74AHC02, powered at 3.3v, which should then be compatible with TTL inputs and outputs. The 74AHC02 is tolerant of 5v inputs.

It might not be good practice to use diodes from the output of 74HCT175 as open collector drive to CS signals, but this will hopefully allow CS to be used as card detect with the 50K pull up internal to the sdcards.

SD card socket detect switches are also available to read via a status input using the 74HCT125 and also connected to user pins for possible interupt interface via CTC module.

I'd be interested in any thoughts on hot swapping sd cards or anything that might be improved before I send the design to JLCPCB. I'll probably not build a prototype of this card and just go to a pcb for the first attempt.

This might be a good candidate for a CPLD project, but I think I'll stay with the challenge of using basic ttl and avoid getting a programmer for a little bit longer.

Mark

[Alan Cox]

Nice.

I like the fact that one of the SD cards can be external not soldered to the board - that's handy for case fitting and also much easier to solder (you mount one of those SD -> microsd adapters everyone has bucketloads of as a fitting and just solder wires to the adapter).

If I read the circuit right there are effectively two other chip select values that could have meaning - it would be nice to have those exposed (and you can always flip back and forth between devices to fake no cs...). That would allow for ethernet and other cool SPI stuff.

MMC/SD cards are supposed to initially be read at a low speed, then switched to high speed but while the spec says that I have not met a modern card that objects to just being hit at high speed. In theory you could have an option for SCLK to come from a CTC

channel direct but I'm not sure it matters. Not even sure having its own clock is that useful. If you have a CTC you can take it from the CTC, if you have a dual clock card then all the dividers are present on the dual clock so you can just run a flying lead to the right pin on the dual clock if you needed CLK2 for something different.

From a software perspective for block transfers while reading (the usual hot path case) that works quite nicely as it becomes

ld a,0xff

out (xx),a

ini

out (xx),a

ini

(unrolled a bit)

or

ld b,255

out (c),b

in e,(c)

ld a,(de)

ld (hl),a

inc hl

for byteswapping I think get the same byteswapped data rate with a way lower clock by interleaving the loop which might be a win for noise etc ?) ie a setup iteration then loops of

out (c),b                ; trigger the I/O

ld a,(de)                ; reverse the previous byte

ld (hl),a                 ; store it

inc hl                     ; move on

in e,(c)                  ; next

The SD interface like this is not competitive with a CF card on speed but should be about 200K/second which is already about twice as fast as a real hard period hard disk interface. Rather less if you have to bitswap, but that's only a matter of interoperability for the data bytes.

Alan

[Mark T]

Hi Alan,

I tried to match the pinout of P4 to match one of these breakout boards that seems common on ebay, but as you suggested it could also be wired to a micro SD card to SD card adapter.

I had originally included two headers, one was under the sdcard sockets, but the tracking was getting a bit messy and I was concerned about the shield cover of the sockets shorting to the pads for the via.

There are a couple of outputs available from the latch that could be used for additional chip selects. I was short on space for diodes and pull up resistors and card detection inputs, but perhaps thats not needed for general spi use. I may try and connect them to unused connections on the P4 header which should be too difficult, although it would mean taking care when using a breakout board not to wire those connections.

I saw the spec for sd cards about running them initially at 400kHz, but there was no mention of that causing issues with Mitch's design so thought I'd probably give it a go. CTC via clk2 was the plan B.

On board clock was in case I had to drop the frequency, but that would also cause some timing issues and require adding NOPs. Also it was easy to fill the space below the sdcard sockets. X3 allows for sourcing clock from CLK2 on the bus, although that is commonly used for a second serial baud rate. I could maybe include option to take it from one of the user pins but didn't really want to trace it across the board when the ideal option is to run at the processor clock frequency.

I might drop the local clock if I can see a way to make better use of the space, move U3 or U7 into the space and increase the options for card detect or chip select to spi.

Option for full size sd card socket would also be nice but the ones I've seen are smt with the pads under the socket and not easy to solder by hand.

Not sure I fully understood your comments on bit swapping or byte swapping. If you mean swapping the bits within a byte, as required using the z180 clocked serial interface then I don't think thats going to be needed. If you mean byte swapping due to endianness of data from blocks on an sdcard then I need to study the interface software a bit more to make sure its worth the effort to run at the higher clock speed.

Mark

Mark

[Alan Cox]

On Wed, 3 Oct 2018 at 22:17, Mark T <mark...@gmail.com> wrote:

Hi Alan,

I tried to match the pinout of P4 to match one of these breakout boards that seems common on ebay, but as you suggested it could also be wired to a micro SD card to SD card adapter.

The only reason for wiring them to an adapter is that it lets you put it on wires somewhere nice in the case so you can have a card slot in the case.

There are a couple of outputs available from the latch that could be used for additional chip selects. I was short on space for diodes and pull up resistors and card detection inputs, but perhaps thats not needed for general spi use. I may try and connect them to unused connections on the P4 header which should be too difficult, although it would mean taking care when using a breakout board not to wire those connections.

General SPI you need the chip select, and the SPI lines. A few devices need a reset or other sideband signal which could come off a PIO and level shifter or something else. The chip select being software controlled as you have it is also very useful because some devices need a delay after the last bit before they de-select otherwise they fail in weird and wonderful ways.

MISO, MOSI, CLK and a \CS are all you need for things like the WIznet ethernet modules in SPI mode.  A lot of the chips would also like an interrupt line in (eg serial chips, some ethernet and stuff like the MAX3421E for USB) but they can probably steal the card removal signal just fine ?

For me the Wiznet 5100/5300 is probably the most interesting. It does TCP/IP on the device and has all the needed logic to accept connections from outside or make them. That makes it great with stuff like CP/M for networking.

 

I saw the spec for sd cards about running them initially at 400kHz, but there was no mention of that causing issues with Mitch's design so thought I'd probably give it a go. CTC via clk2 was the plan B.

I've seen multiple designs that do not bother with the 400Khz (and just clock it fast). I've used several of them - never had a problem with a modern card. I've also never met one that isn't 5v tolerant 8)

On board clock was in case I had to drop the frequency, but that would also cause some timing issues and require adding NOPs. Also it was easy to fill the space below the sdcard sockets. X3 allows for sourcing clock from CLK2 on the bus, although that is commonly used for a second serial baud rate. I could maybe include option to take it from one of the user pins but didn't really want to trace it across the board when the ideal option is to run at the processor clock frequency.

If the pins are arranged right then you can also just run a wire from one end of the jumper wherever you want (eg direct to the dividers on the clock card.  Not pretty but works fine for my SIO !

I might drop the local clock if I can see a way to make better use of the space, move U3 or U7 into the space and increase the options for card detect or chip select to spi.

Option for full size sd card socket would also be nice but the ones I've seen are smt with the pads under the socket and not easy to solder by hand.

I think a full size socket has to be off board anyway. Also from the N8VEM board I built I remember there being a long list of instructions about exactly which adapter and which wiring because the full size sockets do not apparently have a standard connection to the PCB 8(

The only reason I can see for the full socket is a hack to make a nice case fitting.

Not sure I fully understood your comments on bit swapping or byte swapping. If you mean swapping the bits within a byte, as required using the z180 clocked serial interface then I don't think thats going to be needed. If you mean byte swapping due to endianness of data from blocks on an sdcard then I need to study the interface software a bit more to make sure its worth the effort to run at the higher clock speed.

It was bit swapping I was concerned about. If you can just do the out / ini /out / ini sequence it's going to be plenty fast enough (about half CF speed - or way faster than an early retro  HD was). SD is byte wide so there are no byte swapping issues unliike ATA.

Alan

[Mark T]

This might be an option for panel mounting the sdcard, would need an adapter to get back to microsd card again.

https://www.ebay.ca/itm/TF-Card-To-SD-Card-Extension-Cable-Adapter-Flexible-Extender-SDHC-SDXC/332679509885?hash=item4d753e777d:g:4-sAAOSwhEVbGh9p

[Mark T]

I think I spotted an error in the logic of my schematic. ENT on the 74HCT163 must be logic high to allow counting.

It could just be tied high, but I'm thinking it might be connected to /SER_WR then U7A could just be an inverter instead of NAND. This gives me a greater choice for U7 to be Inverter, NAND or NOR.

I'll update schematic when I finalise a few revisions.

Mark

[Mark T]

I have some other changes to attempt to improve the speed for reading blocks from the sdcard, I'll post schematic in my sdcard module thread when I finish trying to reduce the chip count. What I'm adding is a second address for reading data, this second read address will also trigger another transfer, so it should be possible to use INIR.

Something like:-

    LD    HL,BUF

    LD    BC, 00xx      ; xx = read + transfer address

    INIR

    DEC    B

    INIR

    DEC    C               ; point to read only address

    INI

I'm still trying to find a way to reduce the glue logic to avoid adding an additional 74HCT08 just for one gate, attached schematic is what I have so far.

[Mark T]

I took a look through Steve Cousin's module address list.

Jay Cotton's bit banged SPI interface seems to use IO port address 0x40 and 0x41, although not included in Steve's list, perhaps not at the required level of documentation or maybe Steve just missed it.

As I think I need two data read ports to allow optional read and trigger transfer, and a status read port, I'd propose default Base address at 0x44 for this shift register spi card.

Input:-

0x44 - Read data - does not trigger transfer

0x45 - Read data - and start new transfer

0x46 - Read status

0x47 - not used

Output:-

0x44 - Write data and start transfer

0x45 - not used

0x46 - Write control register

0x47 - not used

If anyone knows of any conflicts with this please let me know.

Mark

[Mark T]

I just remembered Steve Cousin's Monitor supports modified ACIA module using address 0x40 and due to limited decoding occupies 0x40 to 0x7F.

It seems best to change base address for shift register spi sd card module to 0x1C

Input:-

0x1C - Read data - does not trigger transfer

0x1D - Read data - and start new transfer

0x1E - Read status

0x1F - not used

Output:-

0x1C - Write data and start transfer

0x1D - not used

0x1E - Write control register

0x1F - not used

[Steve Cousins]

Mark

I've attached the very latest version of my module address spreadsheet.

You raise a good point about the ACIA with the address modified to 0x40. I really need to add that to the spreadsheet.

SCM looks for the ACIA at addresses 0x40 and 0x41, so although the ACIA module decoding is from 0x40 to 0x7F the monitor will not get upset if you do not have the modified ACIA present and instead have something else from 0x42 to 0x7F. Any other device at 0x40 and/or 0x41 might confuse SCM. However if you have the modified ACIA present you will of course get conflicts with any other device in the range 0x40 to 0x7F. 

What I'm am trying to say is that using address 0x42 to 0x7F will not be a major problem as very few people will have an ACIA modified for this range. I added the second ACIA feature mainly for those wanting to have a known working serial module in the system while developing serial, or other, modules at 0x80. 

Steve

[Scott Lawrence]

Perhaps I missed a reference in this thread, but has anyone here bit-banged SD card access?  I've been messing around with just using the standard original RC2014 IO module, connected to an SD card (via level shifter), as a super low-cost SD card bootloading system, and just curious if anyone else has already done this.. (I surely expect it to be slow, but on a Z80, that's acceptable.)

--
You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.
To post to this group, send email to rc201...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/a7a586ab-0ee3-4148-b676-77c13dc15ec3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Scott Lawrence
yor...@gmail.com

[Alan Cox]

Yes you can do so. It is indeed really slow but no worse than a commodore floppy drive.

Alan

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/CAKD5ztYgYNYLSRsKKX%3DSuh2Tb3%3DesXb2Ou8NjaM1O_UOFO%2BmJA%40mail.gmail.com.

[Mark T]

Hi Scott,

My first post in this thread includes a link to Jay Cotton's thread for a bit banged interface, which also has a link to his sourceforge page.

Most of the z80 platforms in RomWBW support bit banged sd card interfaces and some of the z180 platforms use the clocked serial port of the z80 with alookup table to reverse the order of the bits. It probably won't take much effort to port your hardware interface into RomWBW and take advantage of the existing protocol software in RomWBW.

Mark

[Mark T]

Schematic I posted on the 7th October may have a problem with stopping the count of the 74HCT163 too early when the read enable is activated. I'll post an updated schematic when I figure out how to avoid that.

Mark

[Mark T]

Updated to v2. I generated a timing diagram to check propagation times and identified a few issues.

Added feedback from IC2B to IC2A to prevent changing from state 15 back to 12 if the setup time for CLR is not met.

Flattened the logic to select the next state to optimise the maximum clock frequency.

Using the INH input of 74LS165 to reduce the chip count. This does increase the number of inputs that load the CLK input from the bus.

In order to run with 12MHz clock, 74LS series will be needed. I think 20MHz is possible if 74ALS138 and 74ALS165 are used. It might be possible to use HCT with the standard 7.392MHz clock but I haven't looke in detail at that yet.

Now I need to update the layout, might even be better to start again.

Mark

[Mark T]

I think I finally have a version that is ready to send to manufacture PCBs.

I decided to use the Pmod type 2A pinout for the additional SPI connector, although it doesn't provide full support for the GPIO pins and only supports SPI mode 0 so will be limited as to which Pmod modules can be used.

Included links to user pins for additional support of interupts or GPIO via CTC or PIO modules.

It might have been possible to give better support for Pmod modules if I remove the uSD card sockets but those were the main reason I started to create this module.

Maybe a CPLD version could give better support but I want to avoid programmable parts for now and also try and get this to work with basic TTL devices.

I'm a bit concerned about using diodes on HCTTL outputs instead of open collector drivers but didn't really have the space for additional packages.

Also the feedback from U5B-6 to U5C-9 would be best to use an additional inverter from RCO to prevent the state changing from 15 back to 12, C13 is to try and slow down the transition of U5C-8 to work around this.

Mark

[Mark T]

After wasting time trying to run my SBCPM card at higher clock frequency I got around to building and testing my sdcard module. I considered trying to test the circuit operation with basic output and input operations but decided to jump in and make the minimum changes to RomWBW that would work with the shift register circuit. Luckily after just one mistake reading my own schematic to set the CS control bit and then a little messing about with fdisk80 to set up a cpm partition on the sdcard it seems to be working.

Only running the z80 and sdcard at 8MHz for now, and quite a lot of opportunity to optimise the software.

Are there any benchmarks I could use to compare the speed with what everyone gets from the compact flash module?

[Alan Cox]

CP/M tends to bury you in overhead at high speeds (to be fair it was
*not* designed for flash storage!). Raw you should be seeing about
400K/second at 7.3MHz.

For a direct comparison bitbanging an SD card over a Z80 PIO I get
14Kbyte/second raw transfer speed.

In general the SD and IDE performance of my 8bit systems which have
both or are comparable is the same. The storage hardware is vastly
faster than the CPU and the only thing that matters is the rate at
which you can get bytes through the CPU (that being 16 clocks per byte
at best).

An 8MHz Z80 can at peak ini 500Kbytes/second (16 clocks per ini)
A 4MHz SD will deliver a 500Kbytes/second (8 clocks per byte)

By 4MHz SD you ought to get data arriving every 32 clocks, which is
faster than a 7.3MHz Z80 can put it away. At 8Mhz you should be well
clear - which also means you don't need to poll for bytes received or
busy just let rip.

Both have a spot of per sector overhead but that's not dissimilar.

Alan

[Phillip Stevens]

On Friday, 11 January 2019 06:41:10 UTC+11, Mark T wrote:

Are there any benchmarks I could use to compare the speed with what everyone gets from the compact flash module?

When Ed and I were writing the z88dk assembly drivers for the 82C55 PIO for the RC2014 for CP/M-IDE we were seeing about 300kB / throughput at both C and CP/M level. This didn't change appreciably for either SD or IDE Drives.

The 82C55 uses 16 bit native mode to access the drives, and uses the I/O latch in the 82C55 to capture both bytes for transmit. Working under the assumption that the IDE interface was going to be mostly correct, and issues were easily recovered by rebooting, there is very little error protection to slow things down.

This code uses the standard 512 Byte CP/M deblocking mechanism, and a fairly efficient mechanism for determining the IDE LBA from the CP/M 128 block (head / track / sector). This specific mapping means that the "CP/M disk" data resides contiguously on the drive, and can therefore be easily be stored within a file on a FATFS formatted drive.

The IDE code for read and write exist within z88dk, and can be used either directly (as it is by CP/M) or from C by a FATFS file system such as that from ChaN.

TL;DR: approx 300kB/s from C is my top score score.

Phillip

[Bill Shen]

Z80SBC64 has a 8-bit CF interface very similar to the official RC2014 CF card.  I created a 1004KByte file, Z, and pip it from drive C to drive D

PIP D:=C:Z

It takes 34 seconds to complete the copy at 22MHz so that's 1004K read and 1004K write in 34 seconds or 59KB/sec

It takes 57 seconds to complete at 7.37MHz => 35KB/sec

Perhaps this is not a good benchmark because write is slower than read and PIP has high overhead, all these variables are mixed together here.

  Bill

[Mark T]

I created at 1028K file using MBASIC on the sdcard, then copied it to another file on the same drive using PIP Y=Z.

With the simple mod to RomWBW, using IN and OUT in SD_GET and SD_PUT subroutines it takes 80 seconds.

Replaced calls to SD_GET and SD_PUT with the IN and OUT instructions, and modified SD_GETDATA and SD_PUTDATA to use INIR and OTIR, it then takes 60 seconds.

Z80 is running at 8MHz so this is very similar to Bill's numbers.

Mark

[Alan Cox]

On Fri, 11 Jan 2019 at 20:56, Mark T <mark...@gmail.com> wrote:
>
>
> I created at 1028K file using MBASIC on the sdcard, then copied it to another file on the same drive using PIP Y=Z.
>
> With the simple mod to RomWBW, using IN and OUT in SD_GET and SD_PUT subroutines it takes 80 seconds.
>
> Replaced calls to SD_GET and SD_PUT with the IN and OUT instructions, and modified SD_GETDATA and SD_PUTDATA to use INIR and OTIR, it then takes 60 seconds.

If you are desperate for maximum speed swap the inir with

loop:
.repeat 32
INI
.end
JR NZ, loop

or however your assembler likes to see 32 INI instructions.

That takes you down from 10752 cycles to 8379 for a 512 byte sector
if my math is right.

Alan

[Mark T]

I think there are higher overheads in other parts of RomWBW and pip that are slowing it down more than the extra clock cycles used by inir and otir. Also some calls to sd_getdata only receive 8 or 16 bytes, so unless using separate subroutine it would be best to unroll only 8 ini instructions. This might be worth doing just to avoid passing 16 bit size parameter, and also allow a simpler loop count.

I'll probably try running at 12mhz first. Not so much for the speed but to check if my timing estimate was correct in showing that the circuit should run at 12mhz with 74ls series parts although cheating a bit here as I only have 74als10 or 7410 available to test.

Mark

[Jay Cotton]

I have code for that in my sourceforge space.  It is slow, but works.

To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+unsubscribe@googlegroups.com.

To post to this group, send email to rc201...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/a7a586ab-0ee3-4148-b676-77c13dc15ec3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Scott Lawrence
yor...@gmail.com

[Mark T]

I still haven't tried running the sd card spi at 12MHz, but I have it working with RomWBW with dual micro sd cards and also detecting the presence of the cards using the SPI CS card detect.

I didn't try using the card detect switches in the connectors.

Attached source, sd.asm. I 've mostly just changed the hardware interface and keep the original RomWBW code for command level interface to the card. I did find it necessary to add a retry for SD_EXECACMD to avoid it failing to detect sdcard and falling back on mmc.

It seems to tolerate inserting and removing cards without power cycling, although I do take care not to pull the cards while CS is active.

Mark

[Mark T]

Updated schematic attached.

I've used mostly 74LS series that I had in stock. Components in the schematic are as tested at 12MHz clock.

C13 is not fitted, this was included as option as there was possibility of glitch on the output of U5C, but I havent seen any issues at 8 or 12 MHz.

U1 should be OK with any low drop out SOT-223 regulator, 10uF decoupling caps required for some of these regulators, while others only need 1uF. I soldered 1206 SMD 10uF across the through hole pads rather than use electrolytic.

U2 should be 74HCT365, high input impedance required to detect sd card present.

U3 prefered 74HCT175, using BAT85 schottky diode as "open collector" to drive chip selects, HCT typically has lower output low voltage.

U4 I used 74LS682 from stock, but should be OK to use 74HCT688 but requires Fit X1 and RN1.

U5 I used 74ALS10 from stock, should be OK to use LS or HCT. May need ALS at higher clock frequencies if using sequence of IN or OUT instructions.

U6 should be 74AHC02, Vcc is 3.3v but needs to tolerate 5v logic inputs.

U7 I used 74LS165. Setup and hold time is slightly better than HCT. 74HCT165 should be OK at 8MHz but not tested. 74ALS165 may be required at higher clock frequencies.

U8 I used 74LS138 from stock, should be OK to use HCT. May need LS or ALS at higher clock frequencies if using sequence of IN or OUT instructions.

U9 I used 74LS163 from stock, may be OK to use HCT at 8MHz.

U10 I used 74LS595 from stock, may be OK to use HCT at 8MHz.

Mark