• Please review our updated Terms and Rules here

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

You don't have to rely on the CF card to do such things. JR-IDE maps the ATA/IDE register map into PC memory space just above the option BIOS and aliases the data register at 512 consecutive address locations in PC memory space. It's so rep movsw can be used to transfer an entire disk block on an 8088 without intermediate instruction fetches slowing it down in a traditional loop.

JR-IDE would need its CPLD do that to enable that function with plain IDE devices, certainly. (I assume it implements some auto-increment logic that tells the IDE drive to pull another data word every time one is read off the aliased space.) Section 4.3 of this datasheet briefly outlines the similar capability built directly into CF cards. I think it's actually closer to how JR-IDE works than I recalled; I thought it was actually mapping the 512 bytes of the block to a random access buffer but, no, a read to *anywhere* inside the address space it maps out for reading/writing increments the data register. Totally just faking it so those block move instructions can work, it actually doesn't care about the contents of address lines A4-A9.

Using the capability built into the CF card would be useful if you want to get it for "free", but it does of course limit you to CF, not general IDE.
 
Yeah, it does have CGA (with inverted colors), but I recommend playing games in monochrome if you're epileptic. It changes, either the AC frequency or the voltage (I don't remember which), of the pixel to get the two intermediate shades of the CGA pallet, and the flicker is noticeable.

Anyways, it would make sense if that extra 16K is for a 32K video page, the display can do 640x200. Question is what the 32K page at A800 is for.

Standard CGA only needs 16k for its standard resolutions (640x200)/8=16,000, so I'm not sure why the 1100 would need any more RAM than that. Have you tried poking around with BASIC to see if it's actually a writable store, or to see if it looks like it's an alias of something else? (One possibility is they really brutally skimped on address decoding logic, so the same 16k is phantom-ed across a smear of different locations. That wasn't uncommon in cheap computers back then; early Macintoshes in particular are notorious for having multiple phantom copies of RAM and I/O smeared across vast swathes of address space.)

I just checked something, and you can actually confirm that BC00 block you see on a Tandy 1000 is a shadow of B800 within Checkit. If you view that area of "Hi RAM" you'll get a hex dump, and the contents have "17" for every even byte, and "C9 CD 20 42..." for the odd bytes. Looking at a chart of the PC character set "C9" is the "upper right corner" box symbol, CD is the "=" line symbol, etc. In other words, it's filled with Checkit's own output. ;) Maybe Checkit on the 1100 will show the same?

(The "17s" are the attribute code for blue background, white foreground.)
 
Back to memory card matters, I have discovered something interesting. Prior to this week the one diagnostic that was regularly giving me pause was Checkit3's extended RAM test kept blowing "parity errors"; never consistent about where, sometimes in the built-in RAM. Anyway, just for laughs I decided to try again, since I'd made the major changes of adding the CF board and enabling UMBs. And... so far it's run three extended cycles with no errors.

The things that have changed:

1: I added the CF card
2: Running under DOS 5 instead of Tandy DOS 3.2, and
3. When I put in the CF card I removed the memory card, observed that the chips in the thrashed sockets seemed a little loose *again*, and really bore down on them to reseat them before attaching the CF card. (It's still on my to-do list to desolder them and either replace with new sockets or just attach the chips directly to the board.)

Putting aside some possible incompatibility with DOS 3.2 either adding the CF card magically stabilized something or I still had a loose connection. I'm guessing it's the latter but it's "interesting", and possibly very encouraging, that it *can* pass that test.

Machine totally flunks the DMA controller test on the "System Board" menu item, though. ;)
 
JR-IDE would need its CPLD do that to enable that function with plain IDE devices, certainly. (I assume it implements some auto-increment logic that tells the IDE drive to pull another data word every time one is read off the aliased space.) Section 4.3 of this datasheet briefly outlines the similar capability built directly into CF cards. I think it's actually closer to how JR-IDE works than I recalled;

I don't know where you are coming from. Every time you read a word from the IDE data register at CS0/A=0, you get the next word in the sector. You read 256 times from the same IO address to transfer a sector. All I did was alias the data register at 512 consecutive memory locations by not qualifying the lower 9 address bits. It's the 8088 that auto-increments during a rep mov, so every time the CPU increments and reads or writes the next word of the string copy, it still gets the single IDE data register.

The CPLD on the card is just for chip reduction because of the limited space of the side-car. Everything the CPLD does can be easily done in discrete logic; maybe 8 chips max.
 
JR-IDE would need its CPLD do that to enable that function with plain IDE devices, certainly. (I assume it implements some auto-increment logic that tells the IDE drive to pull another data word every time one is read off the aliased space.) Section 4.3 of this datasheet briefly outlines the similar capability built directly into CF cards. I think it's actually closer to how JR-IDE works than I recalled;

I don't know where you are coming from. Every time you read a word from the IDE data register at CS0/A=0, you get the next word in the sector. You read 256 times from the same IO address to transfer a sector. All I did was alias the data register at 512 consecutive memory locations by not qualifying the lower 9 address bits. It's the 8088 that auto-increments during a rep mov, so every time the CPU increments and reads or writes the next word of the string copy, it still gets the single IDE data register.

The CPLD on the card is just for chip reduction because of the limited space of the side-car. Everything the CPLD does can be easily done in discrete logic; maybe 8 chips max.

The result is a pretty staggering performance rate for an 8-bit machine. The 4.77 MHz 8088 performs DOS transfers at more than 300 KByte/s.
 
I don't know where you are coming from. Every time you read a word from the IDE data register at CS0/A=0, you get the next word in the sector. You read 256 times from the same I/O address to transfer a sector. All I did was alias the data register at 512 consecutive memory locations by not qualifying the lower 9 address bits. It's the 8088 that auto-increments during a rep mov, so every time the CPU increments and reads or writes the next word of the string copy, it still gets the single IDE data register.

Where I'm coming from is I just didn't think very deeply about how you'd do it with discrete components; thinking about it just a hair longer you're absolutely right, you could just wire it up so the same 512 bytes would trigger the same port and it'd do exactly what's described in the CompactFlash documentation. The reason I was thinking there must be more to it is because the CF connector actually has pin assignments for A00-A10 inclusive, while an IDE port only has A0-3. (See page 3.1 of that PDF I linked to, the 11 address pins are 8, 10-13, and 13-20.) Frankly I don't understand why they're even there going through section 4-6 again because there *are* no circumstances in which A4-A9 seem to matter; A10 looks like the selector between the control/status registers and the page where they define that block moves should happen in? (???, because they also seem to show it overlaying the first page in section 4.3...)

Seriously, I apologize for whatever offense, I didn't mean to dismiss anything about what the JR-IDE does. I was just pointing out that a technique for doing memory-mapped I/O that allows block moves is built into the specification for CF, IE, in the docs. If you invented it all on your own for the JR-IDE I'm genuinely sorry if you thought I was disparaging you somehow. I mean, it's there in the PDF, I'm not making it up, and the last thing I said was, huh, I bet that does work like how you did it on your device, because I'd initially misremembered and thought the whole point of it having A0-A10 lines on the CF connector was it actually did present a buffer that could be randomly accessed. (And that you had to hit some register to save changes to that buffer.)

Really, I'm just trying to learn here, because I don't know all this stuff off the top of my head, and share what little I do know. Looking again at the design in the link Blackepyon threw out I see that the difference between how they describe it in the CF documentation and how they did it is they wired the "high" address line to a lower one on the CPU side so they *can't* use a block-move instruction, the data register is just a single location. (I have zero experience with 68HC912 assembly language but looking at the code it looks to me like the driver source is grabbing/writing a byte at a time and only incrementing a buffer-in-RAM location, not using a block move command that increments both source and destination.) So, basically, memory-mapped I/O that treats it like a port addressed device.

Whatever is rubbing you the wrong way, I'm sorry. If you only want to see 100% fully baked and accurate information I'll look for another forum to bounce stuff around in.
 
Last edited:
It's just the way I'm wired to find it useful to talk a problem through while figuring the answer. (Helps to mix some swearing in from time to time.) You'll wind up in some dead ends, but having forensic evidence to retrace where the logic went pear-shaped helps weed out the wrong paths further down. Whee.

Anyway, I think the TL;DR from all that is theoretically at least if you're suck with a bus connector that only has memory support signals on it there's almost certainly some kind of solution for hanging a mass storage device off it. The question would be how hard it'd be to patch the XT-IDE bios. If it already supports configurations *like* that there's at least a path. (The worst-case scenario would probably be if you had a connector that was specifically designed to support a DRAM card and was set up for RAS/CAS multiplexed address signals, etc behind a memory controller. An example for that, assuming if I'm recalling correctly, which I may not, is the memory slot in an Apple IIgs. My recollection is it's basically wired like a SIMM socket.)

In other new, left Checkit3's extended test loop several more times through lunch today and my RAM board is passing consistently now. (Also updated the firmware to the latest for the CF yesterday and it's still apparently working fine, although Checkit's disk test says it's running 5k a second slower. Guess it doesn't matter when it's 293 vs 298Kps.) So for an EX at least I'm almost optimistic that I managed to keep the "major deal-breaker design boners" count down to one this prototype round. Still wondering WTF is the deal with the HX, though... :p
 
Last edited:
Been a while since this thread has been cluttered up, so might as well get back at it.

I also want to know what the heck is going on. Sorry, I haven't gotten back to it, I've been busy the last few days. I'm also working on building a better breadboard rig (I'll post pics when I'm done that, and you'll see why) which will also include soldered 40-pin headers for my logic analyzer pods so I can more easily figure out what the bus is doing at any given time.

Setting up an HX motherboard to play with would rule out for sure whether this is the HX that's doing it, and not just something on my end. At one point, over a decade ago, I saw an EX at one of my local thrift stores. I didn't pick it up, because I already had my HX and didn't see any point - a decision that I'm still kicking myself in the butt over, because it would be useful not just for testing, but because there are actually layout differences (as I was discussing with dJOS in his SmartWatch thread) between the EX and HX, and I've never had the opportunity to do a proper comparison between them.

I finally just couldn't wait any longer, so right after work was over for the day I set up the HX board RetroGaming Roundup sent me, yanked the cards out of my EX, removed the E000-enable jumper, and stacked them up:

boardstack-sml.jpg

Before pulling them out of the EX I set up an old version of PC Anywhere to run out of autoexec.bat, and... to cut to the chase, the HX board fired right up with the stack installed. Here's a shot of the whole mess (in my cramped and messy tinkering corner) running Check-It:

corner_of_doom-sml.jpg

(My client laptop is an oooold Dell running PC Anywhere's ATerm under DosBox.)

The long and short of it is the card seems to work in an HX, so I remain completely mystified why the copy I sent to you didn't work. The only anomaly I've found so far is that for some reason the machine hangs if the mouse driver loads and finds a mouse attached. The serial port card isn't the problem, PC Anywhere is obviously working fine through it. (And the mouse driver hangs if I try it on either port.) DOS seems to be loading high fine, I wonder if it could be some kind of initialization issue caused by cutemouse trying to load itself high into the relatively tiny amount of RAM that's left over with only 64k of available UMBs, if there's some other compatibility issue with ctmouse on an HX instead of an EX... or a thought just occurred to me that maybe ctmouse likes the V-20 in my EX more than the 8088 in the HX board? Sussing that out might need to wait until I improvise some kind of native keyboard for the HX board because, well, as well as this works it still doesn't work WELL...

And I just checked, the extended Checkit memory test I kicked off just passed:

checkit-mem-sml.jpg

I'm actually kind of surprised, because I noticed while I was plugging stuff in this board actually has a nasty cracked RAM socket on it.

mangled_chip-sml.jpg

(I think it may also need some love in the capacitor department, or something, the sound off the headphone jack is full of audio interference.)

I need to figure out if the ctmouse thing could somehow be related to my board or loading high or is... something else unrelated (I have another V-20, maybe I'll try that), and then I'm thinking of doing a couple *serious* bodges on another copy of the board to try out some mods I have in mind for upping the UMBs to 96k instead of 64k on an HX, but... seriously, color me badly stumped what the deal is with your copy.
 
I ran that board through the battery of tests before sending it, and it was my grungy one ;) I have every confidence you are getting nominal HX behavior from it.

Great idea on the KB, you don't even need every key, just a subset of them to get through test, so you are on to a pretty good HX testbed there.

Just thinking outloud on your back burner overclock project...... years ago I used a programmable clock generator for another unrelated project that needed multiple synced functions, it might be a daughter card type solution to replace the timing chip on the EX/HX.
 
Niiiice!

The scratchy audio is usually caused by the onboard volume pot contacts oxidizing - I sprayed a bunch of WD-40 electrical contact cleaner in mine and after some exercise, it came good.

CTMouse uses about 2kb iirc so loading it high isn't going to make much difference IMO. Are you running v2.1?
 
That's not a capacitor, it's a design flaw, and the sound on the HX always was a bit noisy because of it. I've always got fans going in my room, so I never notice. Supposedly the EX doesn't have that issue, but I don't have one to compare with.

Yeah, whatever is going on is definitely on my end. On the other hand, congratulations! You've got yourself a working setup! And unlike me, you stayed focused long enough to complete it (sorry about that) :p

I've never used cutemouse. I always used the basic Microsoft mouse drivers, so I don't know what's going on there.

Here's that prototyping rig I was working on. Makerfaire was last month, and my local retro computer club had a table. I wanted to get this working for that, and completely forgot about the memory board afterwards.

IMG_20190908_173151861.jpgIMG_20191001_205122853.jpgIMG_20191001_205141910.jpg

My idea was to get some kind of a breakout system from the bus that would allow me to work on the breadboard without worrying about accidentally pulling wires out if I needed to move it. It also has those 40-pin headers to go to my logic analyzer. The small breadboard strips have solder tabs on the bottom (what I needed), and they came with the THP protobards, so I figured I'd make use of them. The way I built it ended up being nosier than I'd like (notice the terminating resistor packs), and I'll have to do up a proper PCB for this at some point. It works though.
 
I ran that board through the battery of tests before sending it, and it was my grungy one ;) I have every confidence you are getting nominal HX behavior from it.

I was going to ask if you'd noticed the dinged RAM chip before you sent it, because I was wondering if it's possible the power supply crashed into it in shipping, but looking at the damage more closely I'm actually wondering if it's been that way since it was brand new. The socket is cracked because one of the RAM chip's legs is bent under instead of cleanly into the socket, (the bent leg is still making contact with the metal), I'm almost wondering if the chip-stuffer on the assembly line wiffed it but the board passed automatic testing anyway. On one hand I want to fix it, but the other I'm worried I'll break the leg off the RAM chip if I try to straighten it, so... maybe I should order a spare chip first.

It's also kind of remarkable how many bodge wires there are on the board. The silkscreen says it's a "Rev A.", I wonder if the first release HXes all had a really buggy board, or if this one needed special attention. But... in any case, it being an ugly board is probably a bonus for what its intended use is. It works, so it's awesome. Definitely don't get the impression I'm looking a gift horse in the mouth here. ;)

Just thinking outloud on your back burner overclock project...... years ago I used a programmable clock generator for another unrelated project that needed multiple synced functions, it might be a daughter card type solution to replace the timing chip on the EX/HX.

The hard part isn't really going to be the clocks (I don't think), it's the circuitry to generate the various duty cycles for the 8088. A standard XT used the Intel 8284, and it looks like the Tandy chip *essentially* has one of those buried inside of it, so in principle I think a daughterboard using one of those is a possibility. (The devil's in the details, though, since I just have the block diagram in the manual to go on.)
 
CTMouse uses about 2kb iirc so loading it high isn't going to make much difference IMO. Are you running v2.1?

I was just tossing out the load-high thing because it's something it tries to do automatically if it detects UMBs. (You don't have to explicitly "loadhigh" it.) I don't think that's the problem, though, because it happily loaded high on the EX when I put the board back with only 64k of UMB space available. (I had to modify the config.sys line for USE!UMBS.SYS between the two configurations; I noticed when I first loaded the HX that the driver believed me that it still had UMBs from D0000-EFFFF available because that's what config.sys said even though I'd removed the enable jumper for that page on the expansion board. I'm guessing it would have gotten entertaining if it had tried to load something into the space occupied by the built-in ROM disk...) It was a Hail Mary pass because I do know there are some drivers that use more RAM when they're initializing than running.

I am using the latest 2.1b4. Do you have a V-20 in your machine? That's my best theory at the moment, because it seems like a lot of real-mode software made since the mid-90's just sort of forgets that the 8088/8086 don't have quite the same instruction repertoire as everything later. I'd swapped CPUs in my EX before I got the serial board working so I don't have that data point. Next time I'm poking I'll try a suitably ancient Microsoft or Logitech driver.
 
That's not a capacitor, it's a design flaw, and the sound on the HX always was a bit noisy because of it. I've always got fans going in my room, so I never notice. Supposedly the EX doesn't have that issue, but I don't have one to compare with.

You know, I realized that I don't think I've ever actually had the headphones plugged into my EX, so I just tried it. And, man, it's actually almost exactly as bad. :p It don't really hear it through the speaker, but maybe it just gets drowned out in the fan noise. (Or they used a nice, cheap speaker that doesn't have sufficient frequency response to render the little chirps and whistles as well as my headphones do.) So I guess that's also not a thing to worry about. But seriously, Radio Shack, man, let's have a little talk about ground loop isolation... :)

Here's that prototyping rig I was working on. Makerfaire was last month, and my local retro computer club had a table.

That looks really useful. Part of the reason why I've been boldly (stupidly) going straight to prototype PCBs is because I haven't had the wherewithal around to do a proper prototyping setup. (I've done virtual prototyping with simulators and a few chip-level decoding scheme checks using pushbuttons wired to a 7404 to simulate the bus connections, but not full system tests.)

Now I'm envisioning building that HX board into a box with proto-board covering the top of it...
 
I was just tossing out the load-high thing because it's something it tries to do automatically if it detects UMBs. (You don't have to explicitly "loadhigh" it.) I don't think that's the problem, though, because it happily loaded high on the EX when I put the board back with only 64k of UMB space available. (I had to modify the config.sys line for USE!UMBS.SYS between the two configurations; I noticed when I first loaded the HX that the driver believed me that it still had UMBs from D0000-EFFFF available because that's what config.sys said even though I'd removed the enable jumper for that page on the expansion board. I'm guessing it would have gotten entertaining if it had tried to load something into the space occupied by the built-in ROM disk...) It was a Hail Mary pass because I do know there are some drivers that use more RAM when they're initializing than running.

I am using the latest 2.1b4. Do you have a V-20 in your machine? That's my best theory at the moment, because it seems like a lot of real-mode software made since the mid-90's just sort of forgets that the 8088/8086 don't have quite the same instruction repertoire as everything later. I'd swapped CPUs in my EX before I got the serial board working so I don't have that data point. Next time I'm poking I'll try a suitably ancient Microsoft or Logitech driver.

No worries.

Yep i'm also using a V20 in my EX - the minor speed bump was most noticable with my CF-IDE controller as I could use the XTP edition and gained an extra 150KB/s transfer speed (iirc it went from ~300 to ~500KB/s).
 
Yep i'm also using a V20 in my EX - the minor speed bump was most noticable with my CF-IDE controller as I could use the XTP edition and gained an extra 150KB/s transfer speed (iirc it went from ~300 to ~500KB/s).

Yeah, I've heard it's can be a big boost. The only thing holding me back from trying the XTP version is I wanted the prototype card to stay compatible with the original 8088 as long as I might potentially be swapping it between the EX and the HX testbed. (I do have a second V-20, but I'm thinking maybe it behooves me to keep the HX an 8088 until I've done a full round of testing of the software stack to load things high.) Of course, my flash chip *is* in-circuit programmable, so maybe I should just go ahead and give it a spin. Can always put it back.
 
Yeah, I've heard it's can be a big boost. The only thing holding me back from trying the XTP version is I wanted the prototype card to stay compatible with the original 8088 as long as I might potentially be swapping it between the EX and the HX testbed. (I do have a second V-20, but I'm thinking maybe it behooves me to keep the HX an 8088 until I've done a full round of testing of the software stack to load things high.) Of course, my flash chip *is* in-circuit programmable, so maybe I should just go ahead and give it a spin. Can always put it back.

I reckon that a good portion of EX/HX owners have a V20 installed, so it would be well worth validating against both the AMD 8088-2 and the V20.
 
Back
Top