So... as I'm planning my next C02 Pocket SBC (version 3 most likely), I'm looking to provide a single 2.5" x 3.8" PCB that has a full working system that can also run Richard Leary's DOS/65 OS. My current setup is on two PCBs (same 2.5" x 3.8" size) connected via a ribbon cable. The second PCB containing a Compact Flash card and RTC.

Version 3 is planned to have everything on one PCB. So to fit it all, I'm planning to use SMT devices almost exclusively and at the same time, move to a 3.3-volt design (and the CPU clock at 8MHz). Needless to say, space is going to be tight and assembly will be a bit of a challenge, but that's also part of the charm of making it pocket size.

While I like using the CF Card in True IDE mode, the socket adds to the overall footprint, which is a significant part of the PCB space. Looking at other storage options, the obvious one is the Micro-SD format... but I don't want to implement that... having written a nice compact BIOS for IDE devices. Looking around in the older storage options, the older Microdrive offerings, there are two additional ones which can still be found at reasonable prices.

First, a microdrive with a modified 50-pin connector, which was used in the older Apple iPod Mini. Most of the drives available in this format are likely micro-coded for the iPod Mini, so they could be problematic. The second option I found is a 1-inch Microdrive in a smaller 40mm x 30mm size with a 35-pin 0.3mm pitch ZIF connector which has standard IDE PATA signals, just on a smaller pinout. These drives were made by Hitachi (IBM sold the disk division off years ago), Seagate and I think SONY as well. Transcend also made a SSD in the same size and connector.

I've found the details from Seagate and Hitachi on the connector and the software commands (standard IDE). I'm planning to get a few of these and cobble together a board to try them out. The size is small enough and I'm pretty sure I can get everything to fit.

_________________
Regards, KM
https://github.com/floobydust

I know you said you didn't want to go with microSD, I'm intrigued though - is it just a matter of code size? How large is your existing code? I don't feel like SD takes a lot of code to support, the filesystem support is the complex bit for me.

The BIOS code is pretty small overall. It has a 32-function JMP table, hardware config and vectors tables and sense and init routines to include the RTC and IDE devices. Total code size is 1563 bytes... but the code that supports the CF Card IDE mode is 537 bytes. This include the IRQ handler, sense and configure routines, 8- JMP table calls for access and some text messages for IDE Found and No LBA Support. Overall, I think it's fairly compact code for what it does. Note that some Page Zero locations are used along with some RAM usage for showing LBA count.

I looked at some SD card code and it was larger overall and didn't include sensing the card, configuring it, etc. My current BIOS 3.04 does a sense to test for the CF Card, which is on an adapter, so it may or may not be present. When found, it inserts the IRQ handler and configures the card for usage and xfers the LBA count to a RAM location.

https://github.com/floobydust/CF-Card-R ... d/Software

For the filesystem, I'm using DOS/65 in ROM (a CMOS version I did from his original ROM version). It can support up to 8 drive letters up to 8MB each... or 64MB total. It uses the older CP/M format.

_________________
Regards, KM
https://github.com/floobydust

That's nice. I haven't measured the size of my SD implementation but I think it's similar - so I wouldn't discount microSD on grounds of code size, it's not bad really. One of my implementations of it is here if you're interested: https://github.com/gfoot/sdcard6502/blo ... rc/libsd.s

I have another one that's faster, but the hardware hookup is more complex for that one, so I don't use it.

Have you got SPI?

If so, then a small 8-pin SPI EEPROM device?

Implementing a block read/write code on-top of that ought to be relatively easy - possibly even less code than IDE/CF ...

(I do like the microSD on my Ruby boards though, but every time I look at that 8GB device I do cringe a little thinking there is more CPU on the SD card than the rest of the board - more so when my filing system only support 32MB partitions too!)

-Gordon

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

No SPI on my current designs... but I've seen a SD-Card interface that uses 2 or 3 logic chips to connect to a 6522. I think that's a fair amount of hardware (including the 6522). Just as long as you have at least one chip select and separate Read and Write signals, you can directly connect to an IDE interface in 8-bit mode... but you will need something to invert the IRQ output for the 65C02, if you want to use interrupt driven support.

Of course, there's always other options on interfacing the SD-Card, which could be less hardware. With my current desire to keep things really small, I'm thinking the ZIF socketed Microdrive might be a good option... just ordered a pair... and some cables and an interface breakout PCB. Initial goal is to simply get it attached to my existing setup (which is 5V... but might be able to get it working at 3.3V) and see if my existing BIOS works (as it technically should). I'll go from there of course, but should probably look at the SD-Card stuff at some future point.

_________________
Regards, KM
https://github.com/floobydust

Your new project sounds great.

Not sure this idea would be of any help, but, speaking of "space saving"... I designed a little 0.8-mm thick PCB that is soldered onto the shoulder of the pins on the bottom of a 40-pin machined pin socket which provides space for a 64-kB RAM chip within the socket (and underneath the 65x02 when inserted into the socket). Writes to RAM are qualified by Φ2 and the chip select pin on the RAM is connected to the otherwise unused pin 35 on the CPU socket.

floobydust,
Have you look into disk-on-module? It has the same 2x22 2mm connectors, except it is mirrored. The disk is more compact than CF and without the need of an adapter. This is a side-by-side picture of CRC65 with CF interface and CRC65 with DOM. There are no difference in software.
Bill

A pocket-size enclosure I like is the Arduino mega acrylic enclosure. It is inexpensive, about $3, and the transparent acrylic allows LEDs or OLED display to be embedded. The dimension of pc board in the photo is 2.1"x3.7". CRC65's board dimension is 2"x4", so with a little bit of shuffling, it should fit in the Arduino Mega enclosure and have an OLED display embedded.

Another interesting possibility is there are a number of TFT LCD shield designed to fit the Arduino Mega board.
Bill

Thanks all for replies, insight, etc.

So, Mike, I've seen your integrated SRAM under the CPU... very clever idea, I like it! My extent on hiding parts under parts has been limited to hiding bypass caps under the DIP chips, which are socketed. For my next project, I'm planning on mostly SMT parts, which would include the W65C02, SC28L92 and ATF1504 all in QFP-44 packages and a TSOP package for a 128KB SRAM, PLCC-32 for EEPROM and other SMT parts for additional circuit functions.

Bill (Plasmo), yes, I've seen the DOM drives... used one of the earlier 40-pin IDE versions when building a NAS server many years ago. Note, I also soldered a 44-pin IDC connector on my CRC65, so I can easily plug in the CF Card adapter and have some additional flexibility. I'm looking to contain everything on the ExpressPCB Miniboard format of 2.5" x 3.8". I still travel a bit and like to bring one of these with me for spare time programming. I just plug into a USB port on my MacBook and I'm up and running.

I'm not quite sure how the ZIF PATA Microdrive will work out... but I want to give it a shot. I like the (tiny) size, as it's also only 5mm thick, plus the (board mounted) connector is very tiny and also in SMT. Granted, it's going to be a difficult build with mostly SMT parts and close proximity, but I just like the concept of such a small SBC.

_________________
Regards, KM
https://github.com/floobydust

I ordered some NOS Hitachi Microdrives, which are in 35-pin ZIF PATA interface. As seen in the image, these are yet smaller than Compact Flash (which includes the initial IBM Microdrive in CF Type II format). So far I like the size and it certainly makes for a smaller footprint when you factor in the Compact Flash socket. The drive is 40mm x 30mm x 5mm in height. For comparison, CF format is 42.75mm x 36.25mm.

Of course, you need a tiny 0.3mm pitch 35-pin mating connector to attach it, but those are the same connector that's on the Microdrive.

I'm waiting for some FPC cables and a breakout board. Once these are in, I'll be able to try powering them up. Note that these are 3.3V only!

_________________
Regards, KM
https://github.com/floobydust

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

Apparently, according to the attached datasheet, they're not that fragile and were designed for Mobile Phones of all things. They have an operating shock rating of 400Gs and that increased in 1Q06 to 2000Gs with their ESP technology. Regardless, I will certainly find out over time. Just based on my original IBM 340MB Microdrive (CF Type II and is the one in the pic above), which I've had for over 20 years, it's been rock solid. It was used heavily in a Canon Powershot camera and survived over a million FF Miles and went around the globe a few times with me. I also found an article where the Microdrive was used on two NASA Shuttle missions to store images.

https://www.dpreview.com/articles/69620 ... microdrive



As for mounting, I've already found a source for very thin sorbothane sheet. I'll likely just do a 3D print for some ends to hold things in place. There's also the simplest option of using a double-back foam tape, but only use two narrow strips to hold it in place. Note that there is the vent hole on the bottom, which should never be covered.

_________________
Regards, KM
https://github.com/floobydust

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

This looks promising: https://web.archive.org/web/20161009182 ... ata10a.pdf

Though it looks like a complicated protocol, almost verging on USB complexity!