• Please review our updated Terms and Rules here

I wish to create a new DMA/RAM expansion card for the Tandy 1000 line.

The majority of my Cisco cards identify as "STI Flash" with a version number that follows. Based on that, I believe them to be rebranded Simpletech cards. There are a couple that identify as something else, but I do not recall off the top of my head what those were.

If you can find the Seagate ST1 MicroDrives I highly recommend them - they are almost as fast as flash due to a huge ram cache and should live longer than flash.

IMG_0288_2.jpg
 
The majority of my Cisco cards identify as "STI Flash" with a version number that follows. Based on that, I believe them to be rebranded Simpletech cards. There are a couple that identify as something else, but I do not recall off the top of my head what those were.

I just dumped out the handy stash-O-Cisco-CFs and ran them through the USB converter setup. (Faster than sticking them in the Tandys and I might as well DD the boot sectors clean anyway.) The breakdown is:

2x 2GB "UNIGEN FLASH"
3x 512MB "UNIGEN FLASH"
1x 512MB "STI Flash 7.4"
1x 256MB "STI Flash 7.2"
1x 128MB "SMART CF Media"
4x 128MB "STI Flash 8.0

So far I've only tried "STI FLASH" cards, which have seemed to be fine, and those two 2GB Unigens, which definitely were not fine. I guess I'm going to have to give the 512MB ones a spin and see if they act badly.

Odd observation: the "SMART CF MEDIA" and UNIGEN cards have *much* higher write speed than the STI Flash cards while running on my oddball USB adapter setup. (It's a CF->44 pin PATA->Universal PATA/SATA to USB adapter stack; my direct CF->USB multi-reader evaporated from my computer bag at some point and is still pending replacement.) DD reports the other cards writing at 2.5MB/second while the STI Flash cards only run at around 140Kps. I don't think they run that slow in the Tandy so... CF weirdness extends beyond the XT-CF realm, apparently.

As noted this particular PATA->SD adapter seems to be trouble free as well in my 8-bit XT-CF. It's running an old rotgut MicroCenter-branded SD card and performs the same as the CFs. I need to get around to trying some different SDs in it; in particular I want to try some of those constant-use rated high-durability SD cards they sell for video surveillance and Raspberry Pis. If they really deliver on their ratings I don't think there's any way you could realistically burn one up in an XT.
 
I have 5 x STEC 128Mb CF cards which identify as "STI Flash 8.0" and have had zero problems with them in my ISA - CF or XTIDE cards in my IBM's, I also have SD adapters with 4Gb Transcend SD cards and have had zero problems with them in my XTIDE cards but none of them work when connected to my ISA - CF adapter.
 
If you can find the Seagate ST1 MicroDrives I highly recommend them - they are almost as fast as flash due to a huge ram cache and should live longer than flash.

I think I have an old 340mb IBM Microdrive somewhere.. I will have to dig it out and give it a try. Luckily the CF-IDE adapters that I have are Type II.
 
Something I discovered in the box with the CFs is I also have four PCMCIA ATA flash cards. Part of me is curious if they'd work, but whether they do or not is probably such a singularly useless thing to know that it's not worth spending the money on the adapter
 
Something I discovered in the box with the CFs is I also have four PCMCIA ATA flash cards. Part of me is curious if they'd work, but whether they do or not is probably such a singularly useless thing to know that it's not worth spending the money on the adapter

Those are great for Amiga 600 and 1200 models and frequently sell for silly money on eBay.
 
So far I've only tried "STI FLASH" cards, which have seemed to be fine, and those two 2GB Unigens, which definitely were not fine. I guess I'm going to have to give the 512MB ones a spin and see if they act badly.

This evening I had a few spare minutes to take one of the 512MB Unigen Flash cards and install it in the 1000 SUX. To give it the fairest chance the card was DD'ed entirely with zeros before starting. I booted the DOS 5 install set, partitioned the drive, and did a clean full install. No errors cropped up during the installation, but, as a harbinger of things to come, the machine hung on the first boot from the install. It *did* boot after a power cycle, but the very simple test of trying to run "NIBBLES.BAS" repeatedly fails, with QBASIC hanging on startup or the program bombing out with bogus errors.

These cards aren't just a little incompatible, they're *very* incompatible, in the worst way possible. Sheesh.
 
Okay guys, I don't mind if the conversation wanders a bit, especially if it pertains to combo cards and potential design options, but 1) the CF card discussion is off topic, and 2) said topic of CF compatibility REALLY is deserving of it's own thread, and I'm surprised there wasn't one already.

So I created a dedicated thread here: XTIDE Device Compatibility List

If you could copy those posts over to that thread and delete them from here (or move, if there's an option for that), that'd be much appreciated. I've been meaning to get a list going for a while, and I think we've got a the start of a good dataset going here.
 
Last edited:
So, I'll probably go ahead and update the device compatibility thread after I'm more 100% sure of the relevance of my data. I spent a couple hours this Saturday playing Mr. QA and double-checking results, and my worst fears came true; the Venn diagrams illustrating "apparently compatible" and "troublesome" cards are not identical when I tested them in my original prototype XT-CF board and the newer combo XT-CF and serial board. (TL;DR: The Unigen flash cards were obviously bad in both, but while the older board seems to work fine with all the "STI Flash" cards the newer board seems rock solid *only* with the 8.0.0 128MB cards; the STI 256MB and 512MB cards basically didn't work at all. This is with the respective boards hosted in the same computer and same parent memory card) I'm going to try finding some formal media testing software to make sure the cards that *seem* error free actually are, and maybe give in and try to see if the oscilloscope can tell me if there's a difference in how noisy the bus is on the two boards.

(A confounding factor, of course, is the two cards have different form-factor interfaces so I can't easily swap adapters between them. So differences in quality between the adapters *could* be a factor, although a brief test of the 44 pin adapter in the 40 pin board via a short cable/adapter lashup didn't replicate the error seen with the 44 pin board.)

I've never seen an error when running Checkit's hard disk diagnostics, but since it only seems to do reads of sequential and random sectors without caring what the contents read are "supposed" to be it may be useless if communication/compatibility issues are bus/adapter related. (IE, it's probably just reporting if the controller throws an error.)
 
Last edited:
It is very much the case in today's world that within a "standard" like SD cards for example, that there are manufacturers who publish compatibility guides for one brand/model because some work in the device and some don't. As much as it is interesting why this is so, if there is a selection of working and compatible hardware the fact that there are incompatible ones can be dismissed in a hobby product like this if a manufacturer like GoPro is doing the same.
 
if there is a selection of working and compatible hardware the fact that there are incompatible ones can be dismissed in a hobby product like this if a manufacturer like GoPro is doing the same.

Man, after doing *far* more QA testing in odd moments over the last week than I want to do again for a while I am definitely coming around to the idea that the default assumption at least with 8-bit XT-CF is you should *not* trust a card until proven otherwise, rather than the reverse. I'll update that XTIDE compatibility thread after I collate all the data I recorded on the smartphone camera, but the TL;DR is at least when it comes to CF-lite knockoffs there's a lot of room for incompatibility. Adding disktest.exe's mediatest function to the arsenal helped a lot in finding subtle problems compared to the ad-hoc "just load a big program like qbasic a few times and see what happens" test.

On the bright side, outside of one asterisk it did turn out the two revs of my particular hardware design do agree about which cards are "bad" and which aren't, although how un-subtle the badness was did vary some between different host adapters and IDE_XT firmware versions and type. (TL;DR, at least with my particular setup it seems like the non-186 "IDE_XT.BIN" firmware is more likely to let a bad card appear to work than "IDE_XTP.BIN" is, although in no tested instance did it make a card that fails with XTP completely error-free.)
 
...the TL;DR is at least when it comes to CF-lite knockoffs there's a lot of room for incompatibility.

That's why I said to note if the card was an "off brand." Sometimes people will skimp on something as basic as bypass caps, and I've learned my own lessons hand-wiring my other card what noise can do, even on an 8-bit board. Doesn't mean every home-brew will be problematic, but it's a data point I figured might be worth collecting.
 
That's why I said to note if the card was an "off brand."

Ultimately, though, that's the trick here, really. If some failures are because of "analog" problems then really any compatibility list can only apply reliably to one particular *card*, or at least one particular exact schematic and PCB layout.

In testing across two different host adapters I found my batch of cards fell into three pretty clear categories:

1: Consistently reliable.
2: Consistently and reliably unreliable. IE, cards in this category behaved exactly and predictably the same degree of bad regardless of host. (This doesn't mean they were *obviously* bad, necessarily. All the cards in this category will take a format and boot.)
3: Crazy as ****. The cards in this category don't work, but how they behave in detail covers the spread from "seemingly almost okay, just throwing the occasional error" to "not even recognized by the BIOS". There wasn't a clear pattern between my two host adapters which one worked better with these problem children, and I would even go so far to say that some of these cards would behave differently between power cycles.

Cards in category 3 are what lead me to believe that my newer host adapter prototype might be "noisier" than my first one, but now I'm not so sure because after testing all the C-A-* cards I saw some examples behave "worse" in what I though was the "cleaner" adapter. Without a "genuine" according-to-Hoyle XT-CF-Lite to test against I guess I have no way to tell if there's something particularly and uniquely pathological in play; these cards might all work perfectly fine in another board.
 
The connectors arrived yesterday, and while I have not inspected every single one.. they seem to be perfect. They have a snug fit right out of the package, which I am very pleased with.
View attachment 57684
View attachment 57685

The company I used is called Shenzhen RealRun Electronic Co. They typically have a MOQ of 1000, so I did end up paying a bit more per piece than normal for "only" ordering 250. They have a contact link on their Alibaba page here: https://realrun.en.alibaba.com/?spm=a2700.icbuShop.88.21.621118397jvQ2r

The part number is: "FH2.54*8.5-2*31P 0.64*0.4 Gold 1U PA6T"

Otherwise, if anyone wants some small quantities, feel free to PM me here or since some of you know me on facebook, you can contact me there.

Btw, Rob sent me a few to test and they are indeed excellent - I'll be switching to these when my current stocks of 62 connectors run out.
 
So, back to the original point of this thread... I was able to borrow one of the ATD T512CLK-A1 boards, and I stripped it and took high resolution scans of the PCB. I am going to first, make a duplicate PCB that is 1:1 of the existing design, likely in Sprint.. and second, map out the schematic in KiCAD for an updated version.

I should have some progress quite soon.
 
Screen Shot 2020-04-21 at 9.25.59 PM.png

My first pass is complete. I sent it off to be fabricated for my initial tests.
 
The first draft boards have arrived. My 1000A and the logic chips needed to build this board will arrive tomorrow, so I will have initial testing done sometime tomorrow afternoon.
20200428_202028233_iOS.jpg
 
I made a couple of bonehead errors, and there were a couple of sneaky traces that I missed on the first pass. I bodged on some fixes, and the system detects the memory correctly now, but I get some memory errors on the second bank. I think either the bodge wires or a possibly bad RAM chip are to blame for the errors.. but progress has been made.

I fixed the design in sprint and sent them off for manufacturing again. I received an email this morning that they have shipped, so I should have an update by the end of the week.
 
Fun stuff. I assume the intention in a later version is to ditch the DRAM multiplexing hardware and use a SRAM chip in place of all those 41256s?

I did spend some time a while back puzzling over how the DMA section of the schematic of Sergey's XT matches up with what's implemented on the Tandy 1000's motherboard verses what was left hanging to be implemented in the card, and the impression I got was it wouldn't take *much* more than the 8237 and the 74573 and 74670 latches and a decoder for the I/O addresses if DMA was really a thing you wanted on its own. What's kind of interesting is I *did* find the schematic for Tandy's original board in the back of a PDF of 1000 technical information and its part count looks substantially higher; Tandy used a bunch of '244 buffers in front of the bus connector and otherwise seems like they were a bit more cautious. (Here's the PDF I found the schematic in. Maybe it might help you with troubleshooting if you don't have it.) Tandy's board uses a PAL as part of the RAM control logic as well, it looks like the one you're working with is all generic logic.
 
Back
Top