Brewed this one up on and off from November 2023 to about August 2024, but never got around to putting it up on GitHub until just now. Not as "optimized" as I'd like, but the prototype ended up working on the first try, so I haven't quite gotten around to updating it further.
On the other hand, it's hard to argue with the approximately $50/unit cost, even with the expensive Mill-Max IC sockets that I used...
Feel free to build your own! I am putting this design out there so that we can all have compatible Trump Card alternatives at a lower price than their current going rate.
Wow, well done! And I like the name joke
Out of curiosity, does the voltage regulator get hot? On my original Trump Card, it does get quite hot. And with the cover (heatsink) removed it gets blazing hot!
I guess the modern SRAM is much lower in power. I'm probably going to make one.
Thanks for sharing!
It does get fairly warm but it is not too hot to keep your finger on. There's a copper fill underneath the 7805 to help reduce the heat- I've found it does a great job of keeping the warmth confined to that single corner.
As far as power reduction, here's some quick "back of the envelope" math: original Trump Card 1 uses 24 41256 DRAMs. A quick check of the NEC uPD41256 datasheet reveals a maximum average current draw of about 65mA per chip, yielding a figure of 1.56A. Checking the AS6C4008 datasheet, I see 30mA per chip.
Since we have two, that'd be 60mA... less than 4% of the 41256 figures.
Here's a rough datasheet-based estimate of the Biden Card's power budget, I suspect the actual reality may be even better...
Using these figures, we arrive at approx. 251mA in terms of current draw on the +5 supply- given the properties of 7805s, that'll give you ~260mA draw on the QL's 9VDC supply.
Thanks for the info! I have already ordered the components. And I have two spare WD1772 at hand.
I assume these work just as well as the WD1770?
Instead of the GAL I will try to make it work with an ATF16V8B. Those are still being made and sold.
I might redraw the board so the card fits in the QL.
Ah, I just realised I missed part of your reply. You are already using an ATF16V8B! Good to know that is working too. Schematic shows a GAL16V8.
(Marcel, put on your ...)
Marcel_X wrote: Wed Mar 19, 2025 7:23 pm
Hi Techfury,
Thanks for the info! I have already ordered the components. And I have two spare WD1772 at hand.
I assume these work just as well as the WD1770?
Instead of the GAL I will try to make it work with an ATF16V8B. Those are still being made and sold.
I might redraw the board so the card fits in the QL.
Anyway, great work!
I have not actually tried a 1772, but I don't know why it wouldn't work, the only difference between 1770/1772 is the step rate/settle time tables, and the TC firmware is set up to work with either. I think the PCB is even marked "WD1770/1772"...
And yes, GAL16V8B or ATF16V8B will work equally fine. Not sure what the needed minimum speed is, but empirically, 15ns ATF and 20ns Lattice GAL worked fine for me.
Since static RAM is used, no need for address multiplexing or refresh. That being said, I have looked at the GAL sources and there still is a MUX input which really should not be there. And yes, it does use the ROM relocation trick like the original. There is also a bit of missed opportunity as there is actually a full 1M on board, which means there is enough replace the top 64k of the internal RAM and shadow the bottom 64k where the screen areas are, making it quite a bit faster, just by adding some code to the GAL.
BTW the actual current from the power supply will be much lower as the chips use the rated current only when actually selected, except WD1770 and GAL, and this is actually true only for a fraction of time.
Pr0f wrote: Fri Mar 21, 2025 5:07 pm
I suspect it doesn't need any of the funky timing for RAS / CAS that the original GAL's use to provide.
But was the trick to relocate the ROM used I wonder? (needed for non Minverva versions of QDOS)
This is the correct answer, no more RAS/CAS timing logic. And yes, the ROM relocation logic is implemented.
Nasta wrote: Fri Mar 21, 2025 10:37 pm
Since static RAM is used, no need for address multiplexing or refresh. That being said, I have looked at the GAL sources and there still is a MUX input which really should not be there. And yes, it does use the ROM relocation trick like the original. There is also a bit of missed opportunity as there is actually a full 1M on board, which means there is enough replace the top 64k of the internal RAM and shadow the bottom 64k where the screen areas are, making it quite a bit faster, just by adding some code to the GAL.
That's a missed opportunity I keep meaning to take... the MUX input still being there is just a bit of laziness.
...)
