• Please review our updated Terms and Rules here

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

Eudimorphodon said:
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...
Click to expand...

I've still got a couple bugs to work out. I saw something in a similar vein, but more professional looking (probably cost a pretty penny with all the status LEDs), in an EEVBlog mailbag segment, and it was made for ISA, so I figured it ought to be possible. Realistically, I ought to have a buffer card at the bus rather than just sending it straight through a long ribbon. If you're thinking of making your own, here's the breakout strip I got from Digi-Key: https://www.digikey.ca/product-detail/en/twin-industries/OB1-LF/438-1171-ND/7423017
The breadboard's solder tabs don't come soldered, so you can easily stick them onto your own PCB.

My advice is to either fit a resistor inline with the oscillator signal (pin B30), or omit it entirely if you don't need it, because if it picks up even the slightest whiffle of bounceback or noise over that ribbon, the computer locks up, since the oscillator basically runs everything.
 
dJOS said:
Oh Interesting - I though most had the AMD chip as iirc Intel had major issues making an 8Mhz 8088 back in the day.
Click to expand...

My HX has an Intel 8088-2 as well. I think at the time AMD was licensing the rights from Intel because Intel didn't have enough production lines to meet demand, or something (don't quote me on that, I'm probably missing something). Eventually, AMD started making their own CPUs. My 1000RSX has an AMD branded CPU with an Intel copyright on it, so they were doing that at least through the 386's.
 
Eudimorphodon said:
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.
Click to expand...

It looks like a 30 year old mistake, I zoomed in on a pic I took when I had it on the test bench at my place and that last leg is smashed in, I never noticed it. It looks like a factory mistake during assembly, I figure if it survived 30 years let sleeping dogs alone....
 
blackepyon said:
My HX has an Intel 8088-2 as well. I think at the time AMD was licensing the rights from Intel because Intel didn't have enough production lines to meet demand, or something (don't quote me on that, I'm probably missing something). Eventually, AMD started making their own CPUs. My 1000RSX has an AMD branded CPU with an Intel copyright on it, so they were doing that at least through the 386's.
Click to expand...

Im fairly sure the story is that IBM demanded Intel licence their x86 design to other Chip makers so they had second supply should Intel have problems making enough to supply them for their PC's.
 
So... back on the topic of memory cards. ;)

One of the things I realized after getting the HX board is a comment *long* ago in this thread that I kind of glossed over may be important now, one about the height of the header connectors. Could someone who has the original board measure it out and verify that the daughter boards when plugged in should sit approximately .7 and 1.4 inches above the parent board respectively? (I assume that's the measure because the slot covers are .7 inches wide.)

I hadn't gotten a good look at my EX's header connector because it's all surrounded by that RF tinfoil, and I usually only see it from a top down perspective, but now I realize that the shrouded connector Radio Shack used sits a lot higher than a standard male header pin set. I sort of subliminally knew this wasn't right already, because in some experiments with the Modem card it didn't really feel snugged down quite right when I tried to put it in the "low" connector of my board, but now it's obvious; I measured and the lower card only sits a half inch above the RAM card. (The "upper" card is, by contrast, almost in the right place because the extra-tall Raspberry Pi stacking headers I use plugged into a second short header on the card are about tall enough to be correct.) That explains why the clearance over the batter holder is so tight...

The parts list for the original connectors lists them as .687" and 1.370" respectively. Based on how my Modem card sits when I plug it into the HX board the shroud actually touches the next card up when it's properly seated, and it looks like the pins are about 0.1" shorter than the shroud? (That's an eyeballed guess, I don't have a precision ruler handy.)

On one hand I'm not sure if I care if the spacing is off for the lower board if all it's always going to be occupied by the parasite CF connector, which in its current form is happy to sit back from the slot covers and just be held up by the header. But the equation gets more complicated if something with I/O were to go into the lower slot. Still might not be fatal if it was another matching board like, say, a combo CF/serial card. But it would be nice to get it "right" if I can find a connector that's close enough for cheap enough. My initial thought was that they sell a "double-ended" male header that has the standard 0.235" pins on both sides of it, perhaps I could set that into a spacer (or a 3D printed box shroud?) to lift it off the board by around .15" of an inch while I solder it, but I think that ends up just a *little* short.
 
Eudimorphodon said:
So... back on the topic of memory cards. ;)

One of the things I realized after getting the HX board is a comment *long* ago in this thread that I kind of glossed over may be important now, one about the height of the header connectors. Could someone who has the original board measure it out and verify that the daughter boards when plugged in should sit approximately .7 and 1.4 inches above the parent board respectively? (I assume that's the measure because the slot covers are .7 inches wide.
Click to expand...

I can measure mine, to be clear you are asking for the measurement from the motherboard to the memory card, and from the motherboard to the next card plugged into the memory card?
 
Yeah, the new 3M 62-pin sockets https://www.digikey.ca/product-detail/en/3m/929975-01-31-RK/929975E-01-31-ND/1094320 are pretty tight. My original was https://www.digikey.ca/product-detail/en/sullins-connector-solutions/PPPC312LFBN-RC/S7134-ND/810270 , and had a more reasonable fit, but it's only available now in minimum quantity of 1000.

You don't need to worry about the clearance from the motherboard to the memory card. The important thing is the length of the male headers from the memory card to the daughterboards. From my notes, the shorter header pins rise .58" above the memory board PCB, and the taller header pins 1.27", difference of .69" (close enough to .7"). This measurement includes the .1" insulator that rests on the PCB. This is not the total length, just the part that rises above the PCB.
https://www.digikey.ca/product-deta...32-09-L-D-480/HMTSW-132-09-L-D-480-ND/8462938
https://www.digikey.ca/product-detail/en/samtec-inc/HTSW-132-21-T-D/HTSW-132-21-T-D-ND/8082014
Both are minimum quantity of one, but are out of stock and have a few week lead time. I ended up trimming them to .54" and 1.24" (slight overshoot from my measurements, but I was trimming them by hand and had to file them a bit), because the original ones I bought were a hair too long. Better to give them a little tolerance, so you can align the cards properly with the screw holes.

To keep the taller pins aligned (and avoid mangling them while installing a daughtercard), I ended up cutting a 2x62 section of protoboard and just soldered it onto the top end of the header leaving .25" exposed contacts. A 3D printed shroud would be ideal, but I don't have such a printer at this time (been looking at the Creality Ender as a potential purchase when funds allow).
 
Last edited:
dJOS said:
Im fairly sure the story is that IBM demanded Intel licence their x86 design to other Chip makers so they had second supply should Intel have problems making enough to supply them for their PC's.
Click to expand...

That more than makes sense. IBM was big money (as evidenced by the absurdly large price tag compared to the Tandys and later clones).
 
RetroGaming Roundup said:
I can measure mine, to be clear you are asking for the measurement from the motherboard to the memory card, and from the motherboard to the next card plugged into the memory card?
Click to expand...

Just the distance between the cards plugged into the memory board. (I have the HX board to measure for that spacing, I just want to confirm that it's that exact connector that's used for the lower height one on the RAM board as well.)
 
Joining the fray here -- I had been working on my own SRAM board without knowing you guys were already doing this. LOL! I wired a 512k SRAM right up to my EX's bus and used A19 as chip select. It works perfectly without any issue. (See pics on the Imgur link)

https://imgur.com/a/F3AanPR

On my HX though, no beuno. It fails at BIOS memory check -- and the same way every time. If I disable the boot memory check (possible on the HX) I do get into DOS ... but the system is pretty unstable. I can't run checkit but the Tecmar MEMTEST app from the PCjr does work and it shows things mostly looking OK other than some bit errors in the 40000h page.

What I'm seeing on the HX are there 40ns pulses on the address lines, even when my board is not there .... and since I'm using A19 as CS for the SRAM, it's likely causing it to send these 40ns pulses of data onto the bus, probably on top of other things. The EX has no such pulses and the address bus and data bus both look nice and free of pulses. I wonder if this is due to the way the HX is latching the address lines? (Only a few of them come right off the CPU as most address lines are multiplexed on the 8088.)

There was the question if mapping 512k right into the memory space is OK since the EXplus memory card only maps in 384k then the other 256k comes from the onboard Video memory. (Which will map after the 384k making a total of 640k.) It seems the Tandy has zero issue with the 512k SRAM being mapped right into 00000h and it just ends up wasting the extra motherboard 128k. I was hoping maybe it would make the extra 128k map above 640k but checking debug, that isn't the case. It just goes nowhere. You still loose the top of 640k to video pages and the other 128k just seems to be gone.

I originally was using a 74LS151 to select the SRAM banks of 128k (that's the extra wiring and socket on my test board) but it seemed mapping the extra top 128k or not made no difference. Seems the Tandy can just handle it.

Anyway, anyone have any ideas on what's going on with those pulses? It's gotta be what's keeping my SRAM board from working.
 
Here are the possible memory maps and you can see the one that allows for 512k continuous and then the systems uses 128 of the video memory above that.

nHGv0V7.png
 
Welcome aboard!

misterblack said:
Here are the possible memory maps and you can see the one that allows for 512k continuous and then the systems uses 128 of the video memory above that.
Click to expand...

Yeah, that's the thing we're not sure of here, is whether the BIOS in the HX and EX actually *look* at 60000 and see if RAM is there or not. This same table appears with fewer or more entries in the technical manuals for all the machines from the 1000 up through the TX, and the one thing we were never able to find was an instance where Tandy documented a mode where the 256k Big Blue would start mapping RAM at 80000h. If you reference the TX manual you'll find this same chart with two additional possibilities, which is confining the Big Blue memory entirely to the B800 space; this is what happens on a TX that has the "768k" upgrade. That is one of two situations in which a Tandy 1000 family computer doesn't steal at least 16k from the end of the 640k base allotment for Video. (The other is if you have a VGA card plugged in, on the machines compatible with that.) This is why I was speculating if there was any way we could read the contents of these registers to see what the BIOS is actually writing into them, to determine if there's an undocumented "256k Big Blue starting at 80000h" mode that's actually getting set, or if we're actually just overloading the bus putting 512k in it but it's working anyway because, within the margins of error, the conflicting parts are returning the same values. I guess another way to put it: we don't know if that register that selects 128k or 256k of Big Blue memory is affected by the expansion memory test. I'd assume it gets set early in the initialization process because it does a basic RAM check on the built in-memory before it goes looking for expansions, does it ever touch it after that?

We noted that it still steals that 16k off the end of the base allotment when you have it wired like this; one of the hopes we had for there being a secret undocumented mode was that maybe it'd use half the Big Blue memory to do the 640k backfill and *not* steal anymore, IE, behave essentially like a TX, but that's not happening. That's why my money is *kind* of on it being conflicting. Since there's no gain in *not* decoding the 384k I'd suggest it's worthwhile to do it.

*Edit: Perhaps an important data point is that I believe people *have* tried backfilling normally slotted 8088 Tandy 1000s up to the 640k mark and that doesn't seem to stop the RAM stealing behavior, despite the fact that intuitively that configuration should trigger the machine to configure Big Blue like it is in the TX. This is why I'm kind of skeptical that even if technically the Big Blue could do something "useful" in a 512k+256k configuration the BIOS would necessarily do it. I guess the interesting question might be is you put *640k* in an HX, would *that* make it configure like the 640k+256k configuration that's implied as a possibility in the TX manual, or is that configuration just in there because for some crazy reason they were considering making TXes with 256k of video memory for... reasons?

*Edit 2, last I promise: Just to verify, if you run Checkit's memory map is it still showing 16k "missing" at the end of the 90000h page?
 
Last edited:
misterblack said:
What I'm seeing on the HX are there 40ns pulses on the address lines, even when my board is not there .... and since I'm using A19 as CS for the SRAM, it's likely causing it to send these 40ns pulses of data onto the bus, probably on top of other things. The EX has no such pulses and the address bus and data bus both look nice and free of pulses. I wonder if this is due to the way the HX is latching the address lines? (Only a few of them come right off the CPU as most address lines are multiplexed on the 8088.)

....

Anyway, anyone have any ideas on what's going on with those pulses? It's gotta be what's keeping my SRAM board from working.
Click to expand...

Was so busy thinking about the decoding thing I sort of glossed over the real question here...

So that is *really* weird. Which address lines are you seeing these on, all of them? My oscilloscope is older than dirt but maybe I can try digging it out and see if I see them on my scruffy HX test rig. There's no good reason that should be going on I can think of. Does the machine work with the Tandy expansion board despite that?
 
Eudimorphodon said:
Welcome aboard!



Yeah, that's the thing we're not sure of here, is whether the BIOS in the HX and EX actually *look* at 60000 and see if RAM is there or not. This same table appears with fewer or more entries in the technical manuals for all the machines from the 1000 up through the TX, and the one thing we were never able to find was an instance where Tandy documented a mode where the 256k Big Blue would start mapping RAM at 80000h. If you reference the TX manual you'll find this same chart with two additional possibilities, which is confining the Big Blue memory entirely to the B800 space; this is what happens on a TX that has the "768k" upgrade. That is one of two situations in which a Tandy 1000 family computer doesn't steal at least 16k from the end of the 640k base allotment for Video. (The other is if you have a VGA card plugged in, on the machines compatible with that.) This is why I was speculating if there was any way we could read the contents of these registers to see what the BIOS is actually writing into them, to determine if there's an undocumented "256k Big Blue starting at 80000h" mode that's actually getting set, or if we're actually just overloading the bus putting 512k in it but it's working anyway because, within the margins of error, the conflicting parts are returning the same values. I guess another way to put it: we don't know if that register that selects 128k or 256k of Big Blue memory is affected by the expansion memory test. I'd assume it gets set early in the initialization process because it does a basic RAM check on the built in-memory before it goes looking for expansions, does it ever touch it after that?

We noted that it still steals that 16k off the end of the base allotment when you have it wired like this; one of the hopes we had for there being a secret undocumented mode was that maybe it'd use half the Big Blue memory to do the 640k backfill and *not* steal anymore, IE, behave essentially like a TX, but that's not happening. That's why my money is *kind* of on it being conflicting. Since there's no gain in *not* decoding the 384k I'd suggest it's worthwhile to do it.

*Edit: Perhaps an important data point is that I believe people *have* tried backfilling normally slotted 8088 Tandy 1000s up to the 640k mark and that doesn't seem to stop the RAM stealing behavior, despite the fact that intuitively that configuration should trigger the machine to configure Big Blue like it is in the TX. This is why I'm kind of skeptical that even if technically the Big Blue could do something "useful" in a 512k+256k configuration the BIOS would necessarily do it. I guess the interesting question might be is you put *640k* in an HX, would *that* make it configure like the 640k+256k configuration that's implied as a possibility in the TX manual, or is that configuration just in there because for some crazy reason they were considering making TXes with 256k of video memory for... reasons?

*Edit 2, last I promise: Just to verify, if you run Checkit's memory map is it still showing 16k "missing" at the end of the 90000h page?
Click to expand...

Yep showing the missing chunk in Checkit.... I am positive that the system would not be operating correctly if both the 448-512k were mapped to the SRAM and the internal memory through Big-Blue. Bus conflict city. Looking at the scope during the memory check of that bank with Checkit shows totally normal operation. So at least on the EX I can confirm all is well and no conflicts are happening.

But what's going on with the HX and those pulses has me utterly confused. Checking over the schematics carefully, both the HX and EX are basically identical. I think it boils down to 3 possibilities:

- I'm running a V20 on the EX and the stock 8088-2 on the HX. Perhaps there is a subtle difference?
- The Light Blue is what generates the ALE/AEN signals which drive the latches and buffers for the address lines -- (it does this via some 244 chips) It could be a variation of Light Blue that is causing this issue.
- The HCT373 latch chips may be the issue but I need to check as A12-A15 are not multiplexed so just go through a HCT244. Need to check for the spikes there. OE on that 244 is still driven from AEN which comes from the light blue via HCT244 .... but yeah something is very odd and the spikes are likely causing my issues on my HX as the SRAM will be pulsing the databus when it shouldn't be. (If A19 pulses low for 40ns while MEMR is also low)

Some scoping of address bus on the HX would be fun to see if the pulses are there too. :)
 
misterblack said:
Joining the fray here -- I had been working on my own SRAM board without knowing you guys were already doing this. LOL! I wired a 512k SRAM right up to my EX's bus and used A19 as chip select. It works perfectly without any issue. (See pics on the Imgur link)

https://imgur.com/a/F3AanPR

On my HX though, no beuno. It fails at BIOS memory check -- and the same way every time. If I disable the boot memory check (possible on the HX) I do get into DOS ... but the system is pretty unstable. I can't run checkit but the Tecmar MEMTEST app from the PCjr does work and it shows things mostly looking OK other than some bit errors in the 40000h page.

What I'm seeing on the HX are there 40ns pulses on the address lines, even when my board is not there .... and since I'm using A19 as CS for the SRAM, it's likely causing it to send these 40ns pulses of data onto the bus, probably on top of other things. The EX has no such pulses and the address bus and data bus both look nice and free of pulses. I wonder if this is due to the way the HX is latching the address lines? (Only a few of them come right off the CPU as most address lines are multiplexed on the 8088.)

There was the question if mapping 512k right into the memory space is OK since the EXplus memory card only maps in 384k then the other 256k comes from the onboard Video memory. (Which will map after the 384k making a total of 640k.) It seems the Tandy has zero issue with the 512k SRAM being mapped right into 00000h and it just ends up wasting the extra motherboard 128k. I was hoping maybe it would make the extra 128k map above 640k but checking debug, that isn't the case. It just goes nowhere. You still loose the top of 640k to video pages and the other 128k just seems to be gone.

I originally was using a 74LS151 to select the SRAM banks of 128k (that's the extra wiring and socket on my test board) but it seemed mapping the extra top 128k or not made no difference. Seems the Tandy can just handle it.

Anyway, anyone have any ideas on what's going on with those pulses? It's gotta be what's keeping my SRAM board from working.
Click to expand...

I was wondering when you'd pop back in to the VCF forums! Welcome back mate. 8)

These RAM expansions are about to become even more critical to the community as I can no longer get any usable size Right-Angle headers for my riser cards and will be retiring them when I sell the last 4.

I may pull my finger out and have another go at making a ram expansion/CF-IDE card with an optional riser board using an ISA slot instead of pin-headers for connectivity.
 
misterblack said:
Yep showing the missing chunk in Checkit.... I am positive that the system would not be operating correctly if both the 448-512k were mapped to the SRAM and the internal memory through Big-Blue. Bus conflict city. Looking at the scope during the memory check of that bank with Checkit shows totally normal operation. So at least on the EX I can confirm all is well and no conflicts are happening.
Click to expand...

I know it's crazy to think so, but I'm not *entirely* sure it'd be a deal breaker if the SRAM and the Big Blue were wired up in parallel. A while back I contributed some ideas to a board that did some pretty aggressive bus snooping and would at least *write* every word to both the "real" hardware and an SRAM that was shadowing it, and it got away with it.

One way to know for sure would be to try to set up more than 4 32k graphics pages and see what happens. When you set up a graphics page in a Tandy 1000 the RAM assigned to it shows up in the B8000h space, but it's also accessible in the lower memory. (Except in the case of the TX.) If it let you set up a fifth page of VRAM and you found a shadow of what you wrote to the screen at 7B000h that would clinch conflict. Now I need to check and see if you can do that in BASIC... ;)
 
dJOS said:
I was wondering when you'd pop back in to the VCF forums! Welcome back mate. 8)

These RAM expansions are about to become even more critical to the community as I can no longer get any usable size Right-Angle headers for my riser cards and will be retiring them when I sell the last 4.

I may pull my finger out and have another go at making a ram expansion/CF-IDE card with an optional riser board using an ISA slot instead of pin-headers for connectivity.
Click to expand...

Yeah hi! I just have been so busy haven't had time to read here much. And yeah I wondered how you even got those connectors in the first place! I just made my connector out of a random 40 pin header and a single strip of 11 more pins ..... It's janky but it seems to work fine. Just need to make sure you align it correctly before you push it onto the connector. Ideally we would want to make a board with the SRAM, a ROM and the 8-bit CF support all on one. Way above my abilities LOL!
 
You must log in or register to reply here.
Back
Top