SD-Cart JR: An MMC/SD card reader cartridge

[raphnet]

Hello!

For some reason, I can't seem leave the PCjr cartridge slots alone! I don't have a jrIDE, and somehow, I decided that I wanted an MMC/SD card reader cartridge to use as a hard disk replacement and as a way to move files easily from another system... so I made one! Just as I suspected, it was a very satisfying experience. Not always easy, especially getting the boot ROM to work correctly without the machine randomly hanging... (I spent a whole week looking for this bug and it was caused by a mismatched register push/pop.. duh!). After that, making the DOS device driver was almost easy!

The performance is not very impressive (only 33 kB/s reading) but at least it is faster than floppies which I timed (using the same tool) at 10kB/S. Being faster than floppies was all I was aiming for, but there are still a few optimizations I plan to try which may yet improve performance.

I posted pictures and schematics, as well as a bit of design information on my website:
https://www.raphnet.net/electronique/sd ... dex_en.php

And the source code is available here:
https://github.com/raphnet/sdcartJR

[Hargle]

Wow! This looks incredible (just placed my order for one) and is a great addition to the peanut.
We can/should roll your BIOS code into the IDEjr BIOS so that they play well together by default and all the int13 handlers are under 1 roof.

[Trixter]

Okay, I'm really impressed :-) Really great write-up, that's almost as much work as making the cart itself. This project must have taken you months!

A quick look at the source shows it can be sped up. I see a CALL spi_receive_byte inside loops; you can turn that into a macro instead. You're also using a CX=16 LOOP in spi_rxbytes, if you unroll that that will also get faster. Also, inside spi_rxbytes, you are using dx=2 so that you can add di,dx. inc di; inc di is the same speed (technically 1 cycle more, but not really, since both forms are the same size in bytes) so if you do that you free up dx and don't need to push/pop it.

Why did you fix the disk geometry to 16 heads, 63 sectors per track, 142 cylinders in the boot code?

[Brutman]

That put a smile on my face. Excellent work!

[raphnet]

Well I'm glad to see I'm not the only one who think a card reader cartridge is useful! Thanks for your comments everyone!

Okay, I'm really impressed Really great write-up, that's almost as much work as making the cart itself. This project must have taken you months!

Yes, that it did. I began working on it in March 2020. The hard part really was the software.

A quick look at the source shows it can be sped up. I see a CALL spi_receive_byte inside loops; you can turn that into a macro instead. You're also using a CX=16 LOOP in spi_rxbytes, if you unroll that that will also get faster. Also, inside spi_rxbytes, you are using dx=2 so that you can add di,dx. inc di; inc di is the same speed (technically 1 cycle more, but not really, since both forms are the same size in bytes) so if you do that you free up dx and don't need to push/pop it.

Thanks!! Actually I hoped someone would look at the code and suggest improvements. I just made a special spi_rxbytes unrolled for 512-bytes, and I now measure 40 kB/s reads instead of 33 kB/s. This also frees CX, as the transfer length is implied. Later I'll make a spi_receive_byte macro later and unroll spi_txbytes as well. But I'm still using the "read/write single block" card commands. I need to try the "read/write multiple block" commands, as it could reduce the time spent waiting for the card to return the requested data.

Why did you fix the disk geometry to 16 heads, 63 sectors per track, 142 cylinders in the boot code?

For arbitrary/historic reasons. At some point I needed to test something with DOSbox to compare with what I was getting on real hardware. The dosbox wiki had an example using this exact geometry... There is no longer a reason to use it. I plan to update the boot ROM to report a geometry that more or less matches the card size.

[raphnet]

Hello!

Has anyone received and used their SD-Cart JR yet? I would like to know how you use it (with the boot ROM, or with the device driver?) and what you think may need improvement.

I spent some time last week and this weekend working on the code, and I just made a new release. On my fastest card (a 64MB MMC card) I get 44 kB/s reading and 35 kB/s writing.
Unrolling the most critical loops and using the read/write multiple blocks card commands really made a difference. I tried other things (using macros, etc) but it increased the code size
without measurable speed improvements.

Another big change is that the disk geometry is no longer hardcoded in the boot ROM. A suitable CHS triplet is found based on the size reported by the card, and this is what gets used.
I also tested the project with DOS 5 for the first time and did not run into any problems.

The new release can be downloaded from the project page.
https://www.raphnet.net/electronique/sd ... dex_en.php

[Trixter]

I received mine two days ago, but it will be several days before I have the free time to give it a test, sorry. I'll be using it with the device driver only (I don't have proper experience and tools to program and solder on a boot rom), so I'll be grabbing the new code before I test.

Someone on the PCjr facebook group asked if there was a particular size limit to the SD card; is there?

By the way, your "Preparing a DOS 5 card" section is great, as it gives people a way (if they have the boot rom on your device) to bare-metal create floppy disks using only the cart and a modern machine.

[Fenyx4]

Hello!

Has anyone received and used their SD-Cart JR yet? I would like to know how you use it (with the boot ROM, or with the device driver?) and what you think may need improvement.

Waiting eagerly on mine. Any recommendations on what SD cards I should pick up for it?

[raphnet]

I don't have particular recommendations for cards, although my favorite is a 64MB MMC card. Writes appear to be marginally faster on MMC cards, but those can be more difficult/expensive to find it seems.

At the moment the limit is 2GB. Larger cards use block addressing (instead of byte addressing) so it should be a simple matter of multiplying the sector number by 512 (as is always done today) or not based on the type of card. I assumed everyone would have old cards, but as someone pointed out in the Facebook group, smaller cards can cost more. So now I understand that all supportable cards should be supported and I'll take care of that in the next release.

Speaking bootstraping a PCjr using the cartridge, one thing I would like to offer is a bootable cartridge supplied with a memory card pre-loaded with a version of DOS... But I would need a version of DOS that is 1. OK to distribute and 2. Works on the PCjr..

[Fenyx4]

I don't have particular recommendations for cards, although my favorite is a 64MB MMC card. Writes appear to be marginally faster on MMC cards, but those can be more difficult/expensive to find it seems.

At the moment the limit is 2GB. Larger cards use block addressing (instead of byte addressing) so it should be a simple matter of multiplying the sector number by 512 (as is always done today) or not based on the type of card. I assumed everyone would have old cards, but as someone pointed out in the Facebook group, smaller cards can cost more. So now I understand that all supportable cards should be supported and I'll take care of that in the next release.

I dug around in old boxed and even raided my old phones but the smallest one I could find was 8gb. (Although I did find many, many microSD to SD adapters. ) I seem to have jumped from Smartmedia cards straight to 8gb SD cards.

I've ordered a few smaller ones. I'll let you know what they are and if they work when I can.

Speaking bootstraping a PCjr using the cartridge, one thing I would like to offer is a bootable cartridge supplied with a memory card pre-loaded with a version of DOS... But I would need a version of DOS that is 1. OK to distribute and 2. Works on the PCjr..

That'd be awesome. 1. would be covered nicely by FreeDos. But some Googling revealed that it has been talked about a lot on these forums but no one appears to have dived in to get it working so it doesn't cover 2.