if it were me, I would just shove it all in an XC9536. but eh. Are GALs still manufactured out of curiosity?
Last edited by a moderator:
-
Hello MLAers! We've re-enabled auto-approval for accounts. If you are still waiting on account approval, please check this thread for more information.
Macintosh Portable SRAM card: Schematics available?
- Thread starter Stephen_Usher
- Start date
Yes, Atmel was bought by a company called "Microchip", who are now manufacturing them.
I checked Aliexpress and they appear to have CMOS in DIP, but of course you're kind of making a bet at what you're going to get. (And be waiting for it for two months.) Personally I'd go with the pair of 74HC138s, that'll take less space than the '154 plus all those resistors unless you go surface mount.
Also, I don't think you need pull-ups between the 244 and either the GAL or the LS154 (assuming you stick with that). CMOS "high" outputs should be fine for driving TTL inputs, it's TTL high reliably driving CMOS that can be the issue.
Maybe it would be valid to have the GAL watch SYS_POWER and have it hold all outputs high unless the system is "awake", that'd be a trivial enough change, but I doubt it's necessary. All outputs should be high unless the machine is accessing the memory card anyway, the only gray area would be if for some reason the address bus produces random garbage that might trigger a spurious chip select when it's asleep.
That adapter alone seems to sell for about $22 quantity one, that's as much as all the active parts plus a decent chunk of a quantity 5 PCB run at an outfit like JLCPCB.
Last edited by a moderator:
The 154 I can get is the HC version (SIOC package). It's recommended that you use a pull-up between the output of an LS or AC part and an HC one, from what I've read.
As for SYS_POWER*, the 154 has two enable pins and both have to be low to allow any of the output to be pulled low, so putting SYS_POWER* on one of them and then having the /RAM_CS_ENABLE derived from the GAL as the other one would work fine. I may just leave it off anyway in case it's not doing what I think it's doing.
I've a few reasons for playing with this in the way I am. Firstly, it gets old kit working in a reversible manner with the smallest number of changes. Secondly, it's a useful project for the lock-down. Then it's also practise as I'm looking into replacing the fried "DECODE1" chip on the motherboard of a Sun 3/80, which is a similar VLSI PLCC-44 chip, once I've worked that pin-out out. (Rather more complex as I don't have the schematics for the main circuit board!)
As for SYS_POWER*, the 154 has two enable pins and both have to be low to allow any of the output to be pulled low, so putting SYS_POWER* on one of them and then having the /RAM_CS_ENABLE derived from the GAL as the other one would work fine. I may just leave it off anyway in case it's not doing what I think it's doing.
I've a few reasons for playing with this in the way I am. Firstly, it gets old kit working in a reversible manner with the smallest number of changes. Secondly, it's a useful project for the lock-down. Then it's also practise as I'm looking into replacing the fried "DECODE1" chip on the motherboard of a Sun 3/80, which is a similar VLSI PLCC-44 chip, once I've worked that pin-out out. (Rather more complex as I don't have the schematics for the main circuit board!)
FYI: Here is my logic design that works. (Chips are 2MB Chips so)
Corrosponding pins.
Hopefully this helps. Before you question the design, Keep in mind that this works/worked.
Code:
#PACE: Start of PACE I/O Pin Assignments
#NET "iCLK" LOC = "p1" ;
NET "A20" LOC = "p2" ;
NET "A21" LOC = "p1" ;
NET "A22" LOC = "p44" ;
NET "A23" LOC = "p43" ;
NET "AS" LOC = "P3" ;
NET "CE1" LOC = "p39" ;
NET "CE2" LOC = "p40" ;
NET "CE3" LOC = "p41" ;
NET "CE4" LOC = "p42" ;
NET "BANK" LOC = "p38" ;
NET "OE" LOC = "p29" ;
NET "WE" LOC = "p30" ;
NET "BOE" LOC = "p32" ;
NET "DIR" LOC = "p31" ;
NET "LED1" LOC = "p19";
NET "LED2" LOC = "p20";
NET "LED3" LOC = "p21";
NET "LED4" LOC = "p22";
NET "DELAYCS" LOC = "p33";
NET "MUXOUT" LOC = "p5";
NET "NORIN" LOC = "p6";
#NET "DTACK" LOC = "p34";Corrosponding pins.
Hopefully this helps. Before you question the design, Keep in mind that this works/worked.
Last edited by a moderator:
No questioning, man.
I was momentarily confused trying to figure out what was the deal with the single "WE" pin, but then I realized you were using 16 bit wide memory chips and using a buffered version of /LDS and /UDS for byte selection.
The resistor I was questioning is the one you have on the outputs of your 74HC244 and the inputs of the 154 and the GAL (RN3 on your diagram). That's an HC driving LS; CMOS has a wider voltage swing than LS for a given supply voltage so CMOS outputs should basically always be valid inputs for LS. Not debating that you might need the pull-ups on the outputs of an 'LS154 driving the CS inputs on those old 32K RAM chips.
It was a "belt and braces" approach and probably not needed but seeing as it's trivial to add to the schematic I thought I'd add it. I could just not fit the resistor array after all and see if it works. If it doesn't that I can easily solder the component on the board, which I couldn't if the holes weren't there.
You'll just be making the CMOS chip work unnecessarily hard when it asserts a "low". Here is a quick rundown. TL;DR, you need the pull-up when going TTL->CMOS, when going CMOS->TTL the main limitation is fanout. Adding a pull-up resistor would just make fanout *worse*, but fanout doesn't matter anyway because you're only driving a single TTL load on each CMOS output of the '244.
Or to put it another way, there's no reason, scientifically, that you need that pull-up.
And, again, you could avoid pullups *period* if you used a pair of 74HC138s instead of a 74LS154.
Last edited by a moderator:
It'll be a 74HC154 (there's just not a symbol for that in the KiCad database, but they're pin compatible). I'd still need to pull up the output from the 244 into the 154 as that's TTL -> CMOS (according to what I've read this is required).
By the way, I'd like to say that I really appreciate the advice both of you are giving.
By the way, I'd like to say that I really appreciate the advice both of you are giving.
Why not use an HC '244 instead of LS? They're a completely standard part readily available in both DIP and surface mount.
... And for laughs, if you prefer DIP here's a version of the GAL code that provides a "HI" and "LOW" MEMCS signal for directly driving two readily available DIP 74HC138s. Simply put the 3 demux inputs for the '138s on A16-A18 and use the appropriate MEMCSHI/MEMCSLOW on one of the E inputs.
Code:
GAL16V8 ; memory decoder
MACTHING ; done
A19 A20 A21 A22 A23 LDS UDS RW AS GND
NC 245DIR MEMCSLOW MEMCSHI 245OE RAMOE RAMWEHI RAMWELO NC VCC
245DIR = RW
/245OE = /RAMOE +
/RAMWEHI +
/RAMWELO
/MEMCSLOW = /A19 * A20 * /A21 * /A22 * /A23 * /AS
/MEMCSHI = A19 * A20 * /A21 * /A22 * /A23 * /AS
/RAMOE = /MEMCSLOW * /UDS * RW +
/MEMCSLOW * /LDS * RW +
/MEMCSHI * /UDS * RW +
/MEMCSHI * /LDS * RW
/RAMWEHI = /MEMCSLOW * /RW * /UDS +
/MEMCSHI * /RW * /UDS
/RAMWELO = /MEMCSLOW * /RW * /LDS +
/MEMCSHI * /RW * /LDS
DESCRIPTION
; Decoding logic to repair a 1MB Portable memory card
; 245DIR is just a buffered version of R/W direction register on card
; A chart in the Portable (BL) dev note implies this is right
; SYSPOWER isn't used.
; Actual chip addresses need to be decoded by an external multiplexer.
Last edited by a moderator:
Just be super careful mixing TTL with CMOS parts. I have gotten myself into trouble with this, especially with the LS166 vs HC166 on the SE/30's UE8. Most of the time you can get away with it, BUT, not always!
Last edited by a moderator:
ISTR the HC and HCT identifiers being the determining factor? Have very vague memories of having trouble with one or the other not working with TTL, but that was 30+ years ago so . . . :blink:
Last edited by a moderator:
Well I got burned by that working on an SE/30 logic board that had weird artifacts after replacing UE8. And this was why. I used an HC in place of an LS.
Yeah, I had gnaw marks all over my backside from that bug hunt, THAT I remember. :lol:
I've just checked Farnell, I can get the HCT parts for both the 244 and 154 easily, so that's probably the way to go (rather than mixed LS/HC). That should negate the need for pull-ups at all.
You just dont want anything floating that could result in erroneous selections of the ICs when /AS isnt valid for the decode space. Or, accidental bus contention. That too would be bad.
Last edited by a moderator:
HCT is CMOS process logic (so it uses less power than LS) but it essentially has built-in pull-ups so it can be mixed freely with TTL logic. I've mixed LS and HCT in the boards I built for my Tandy 1000s freely and it works fine. HC, yeah, you have the "pull up" issue.
Here's a PDF talking about why HCT exists.
So, for sanity's sake, what are the signal levels coming out of the Mac, is it TTL or CMOS? If it's CMOS then I would recommend using HC for everything. (The GAL should be fine with CMOS signal levels.) HCT is *explicitly* for either working as a go-between between TTL and CMOS or to replace TTL with lower power logic. It uses slightly more power and has slightly lower noise resistance than pure HC, if the Portable is CMOS and the RAM chips are CMOS (and the buffers on the card are CMOS) and you can get an HC version of every part there's no reason to use HCT.
