<div dir="auto">Great analysis!<div dir="auto"><br></div><div dir="auto">The SRAM consolidation is definitely on the menu. The bipolar PROM can be replaced with a few things including a GAL: <a href="http://www.retroclinic.com/leopardcats/galprom/galprom.htm">http://www.retroclinic.com/leopardcats/galprom/galprom.htm</a></div><div dir="auto">We can of course go overkill and put in a flash part, and tbh even a modern MCU bit banging the output - see below for some examples. Here's another one for the boot prom:</div><div dir="auto"><a href="https://github.com/wickerwaka/PicoROM">https://github.com/wickerwaka/PicoROM</a></div><div dir="auto">I'm trying to convince this guy to make a 28 pin version, though likely we'll just bump up the implementation on our side before that happens.</div><div dir="auto"><br></div><div dir="auto">TRANSF is a PE_64102 3-pair 1:1 isolation transformer and might be skippable in a pinch. I'm still debugging gremlins in the Ethernet section.</div><div dir="auto"><br></div><div dir="auto">The Zilog SCC can likely be swapped with an Atmel. It's*extremely* underutilized as far as I can tell. Not so for the network, but there it's part of QEMU right now, and might fit again in a MCU that already has an Ethernet impl, or FPGA/etc.</div><div dir="auto"><br></div>I actually had weird experience with the tl7705 voltage supervisor from Digikey - it simply didn't work per spec -neither of the 10 parts in the lot did. I actually made an ATTiny drop-in replacement that just waits for 800ms for the inrush to stabilize. Eventually got a smd part on adapter that actually works as expected. Still don't know what happened but another reason I was glad I kept fidelity with and could experiment on an original.<br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Wed, May 28, 2025, 06:28 Romain Dolbeau <<a href="mailto:romain@dolbeau.org" target="_blank" rel="noreferrer">romain@dolbeau.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Le jeu. 22 mai 2025 à 08:28, Dan Moisa via rescue <<a href="mailto:rescue@sunhelp.org" rel="noreferrer noreferrer" target="_blank">rescue@sunhelp.org</a>> a écrit :<br>
> Putting the BOM together is a PITA because about 40% of the components are not on Digikey/Mouser<br>
<br>
Just checked the 74xx chips for stock or alternative at Mouser, and<br>
there's hope:<br>
* The ALS are in stock in SOIC, all but the ALS652 in DIP (and for<br>
that one, the FCT652 is a cheaper option that might work as a<br>
substitute)<br>
* The F00, F04, F175 are all there, the F374 in SOIC only, the F534 is<br>
MIA but there's an ABT that might work as a substitute; also it's just<br>
a register for BERR, and the 3/160 uses a different part (slower,<br>
non-inverting), so there's options to substiture/reengineer<br>
* The AS are mostly not in stock/no made or expensive; however it's<br>
possible they can be substituted by F, which are cheaper and usually<br>
available. The exception is the AS286, but the FCT11286 has similar<br>
functionality though different pinouts. Also, it's for the parity<br>
generation/checking, required for real workstation/server usage but<br>
could be disabled in a replica if some components are no longer<br>
available.<br>
<br>
On the SRAM side, updating the vintage stuff will be wasteful but<br>
doable; pair of 7188 (u200/u201) could be replaced by IS62C1024AL-35<br>
(8x the needed size...) while 2168 could be replaced by IS62C256AL-25<br>
(idem), though while u205/6 and u207/8 can be merged pair-wise,<br>
u202/u203 have different /WE so need different chips (8-bits SRAM dont<br>
have 4-bits granularity).<br>
<br>
The ICM7170, Am7990 (lance), AM7992, Z8530 I don't see a way to<br>
replace (unless by re-implementing in programmable logic, or having a<br>
go at recreating them with open-source EDA & PDK perhaps as FOSH, but<br>
that's not happening anytime soon).<br>
<br>
The Am25LS2518 is just a dual-output register, it might be possible to<br>
replace it by two registers in parallel with the same input and<br>
control, one for the always-on output and one for the three-state<br>
output.<br>
<br>
I'm not sure what "TRANSF" is ?<br>
<br>
(the PALs are a problem of their own, discussed in the GitHub already).<br>
<br>
Cordially,<br>
<br>
-- <br>
Romain Dolbeau<br>
</blockquote></div></div>