feipoa wrote on 2025-05-05, 11:13:

On a similar note, since I'll be using 10 ns 128Kx8 DATA chips, will I be able to use my sole 8 ns 64kx8 chip as the TAG? Or will some grounding or lifting of pins be needed?

I already did the modification for 64Kx8 TAG at 1MB and 32Kx8 TAG at 512KB. The footprint change isn't done yet, but it will happen the next days.

Looking forward to this...

feipoa wrote on 2025-05-09, 13:42:

Looking forward to this...

I just finished https://github.com/karcherm/mb8433-uud-cache- … leases/tag/v1.1 - I hope this suits your requirements. This comes with absolutely *no* *warranty*, as I only tested a prototype of v1.0, but as the current version still passes the built-in checks in KiCad (no pins forgotten to connect, no traces too close to each other), I am quite confident that there are no serious errors in this version.

As you said, PCBs are cheap nowadays, so if something went wrong, it is mostly wasting your time in assembly and troubleshooting, but not a lot of money on PCBs. As the assembly hints in the main README state: Be careful with the memory chip orientation!. Chips U5..U9 are 180° turned in comparison to the DIP sockets on the mainboard! The board is designed this way to get the data pins of all data RAMs close to each other, so one set of data pins can be easily used for both banks.

Nice!

When you uploaded these zip files (v1.0 or v1.1) to JLCPCB, did you see "Detected 0 layer" and notice that Gerber Viewer cannot open? Normally, the website detects the correct layer and Gerber Viewer works.

feipoa wrote on 2025-05-10, 03:04:

When you uploaded these zip files (v1.0 or v1.1) to JLCPCB, did you see "Detected 0 layer" and notice that Gerber Viewer cannot open? Normally, the website detects the correct layer and Gerber Viewer works.

Oh, that's strange. I tried the automation of the Gerber generation on my system before setting up the automatic GitHub action to generate them, and I successfully uploaded them to JLCPCB. I tried it again, and it still works for me. Did you try to upload the "Source code (zip)" file? This is the wrong file. The "Source code" just contains the design files for KiCad. The Gerber files are in the automatically generated file "Biostar.MB-84xx-UUD.1MB.cache.module-_JLCPCB_compress.zip".

I had clicked "Download Zip" from this page, but it did not contain JLCPCB gerbers. This is the zip I had been uploading to JLCPCB which didn't work. Shown here:

Looks like I must download the files one by one under Assets, in particular the *compress.zip file. Uploaded this to JLCPCB and it is working fine now. Shown here:

Just ordered. 5x of v1.1 and 5x v1.0. $8 shipped.

feipoa wrote on 2025-05-10, 08:54:

I had clicked "Download Zip" from this page, but it did not contain JLCPCB gerbers. This is the zip I had been uploading to JLCPCB which didn't work. Shown here:

The attachment Github_screenshot_1.png is no longer available

I'm sorry for that misunderstanding. I tried to avoid that by directly linking the v1.1 release page in my last post, which has the assets section below the release note, instead of just linking the front page of the project which has the "Download ZIP" link you used. It seems I should be even more explicit. The idea of having this board as Open Source Hardware on GitHub is that other people can download the KiCad design files and create their own variations (maybe trying to re-design it to use TSSOP chips, or making a 256K version for the 8ns chips. So the data that's primarily managed on GitHub is the schematic and PCB layout in the file format used by KiCad. When I do a release, I programmed a script that uses KiBot to automatically generate the assets as additional files for the release, doing an ERC (electrical rules check) and DRC (design rules check) first. These files are not managed by the version control system, and do not exist for every editing step I commit, but only for dedicated releases.

feipoa wrote on 2025-05-10, 08:54:

Looks like I must download the files one by one under Assets, in particular the *compress.zip file. Uploaded this to JLCPCB and it is working fine now. Shown here:

You don't need to download all the files under "Assets" unless you want all of them. Most likely you don't care about the logs that the rules checks succeeded, but there were some ignored "courtyard overlap" warnings on the PCB, which just means some components are placed with less spacing between them than recommended. You only need the JLCPCB_compress.zip file for board production. If someone adds SOJ32 3D models to the KiCad 3D model repository, I will likely add 3D renderings to the assets of new releases, but without the cache chips, the 3D renderings are kind of pointless. I reported the missing 3D models for the SOJ32 footprint that has been recently added to KiCad, but it seems they don't consider generating the appropriate 3D models an urgent issue.

Got the A19 line soldered back in, and fixed it with super glue as strain relief this time. The system still works with at 3-1-1-1 at FSB50. But I got one step faster! If I disable "early cache write mode" in the CMOS setup, the performance at a given cache timing setting does not drop (at least according to "DOOM max details" in speedsys), but this allows me to go 2-1-1-1 at FSB50. For Quake mininmal details, option "c" in speedsys: Using an AMD 5x86 I get 17.6fps at 3*50 with 1MB 2-1-1-1 cache with a Virge PCI card and the PCI bus at 25MHz. IIRC the 486DX4 at 2*50/2-1-1-1 was at 12.1fps. I couldn't boot to DOS at 3*60 with anything faster than 3-2-2-2, and Quake crashed even with cache disabled at 3*60.

mkarcher wrote on 2025-05-18, 13:46:

Got the A19 line soldered back in, and fixed it with super glue as strain relief this time. The system still works with at 3-1-1-1 at FSB50. But I got one step faster! If I disable "early cache write mode" in the CMOS setup, the performance at a given cache timing setting does not drop (at least according to "DOOM max details" in speedsys), but this allows me to go 2-1-1-1 at FSB50. For Quake mininmal details, option "c" in speedsys: Using an AMD 5x86 I get 17.6fps at 3*50 with 1MB 2-1-1-1 cache with a Virge PCI card and the PCI bus at 25MHz. IIRC the 486DX4 at 2*50/2-1-1-1 was at 12.1fps. I couldn't boot to DOS at 3*60 with anything faster than 3-2-2-2, and Quake crashed even with cache disabled at 3*60.

The PCI speed is 25 MHz because, as you posted in another thread, the 2/3 output is is misshapen, as if it has a duty cycle that is not 50%.

Could the PCI clock be provided in some other way with additional circuitry to try and supply a 33 MHz one, or there would be no way to control the chipset's clock source in that case?

I believe the 2/3 PCI divider is the distinguishing characteristic between UM8881 and the EDO variant of the SiS 496; with that divider being usable, is it worth revisiting the 496?

jakethompson1 wrote on 2025-05-18, 17:07:

The PCI speed is 25 MHz because, as you posted in another thread, the 2/3 output is is misshapen, as if it has a duty cycle that is not 50%.

Exactly. Maybe I can find a PCI graphics card that doesn't care about the wrong duty cycle, and use the 2/3 divider.

jakethompson1 wrote on 2025-05-18, 17:07:

Could the PCI clock be provided in some other way with additional circuitry to try and supply a 33 MHz one, or there would be no way to control the chipset's clock source in that case?

I'm afraid that likely the PCI clock is hardwired to the output of the programmable divider, and possibly the design on the 8881 relies on a strict phase relationship between the FSB clock and the PCI clock, so injecting 33MHz from a free-running clock source is possibly problematic, even if it were possible. OTOH, what is likely possible: As the PCI bus specification only cares about the rising edge of the PCI clock, you could use a PLL locked to the 33% duty cycle PCI clock output and have it generate a 50% duty cycle clock signal for the PCI bus, which essentially just shifts the irrelevant edge of the PCI clock.

As one example, the CY2305 clock buffer chip can be used to generate up to 5 PCI clock outputs at 50% duty from an input with "any" duty cycle. The datasheet doesn't seem clear on what duty cycles are supported, but it is clearly specifying that the PLL locks on the rising edges. The output voltage of that 3.3V chips is suitable for the "5V" PCI specification, but you need a 3.3V supply for that chip, possibly just a LM1117 (or clone). You might also be able to find zero-delay clock buffers for 5V operation.

jakethompson1 wrote on 2025-05-18, 17:07:

with that divider being usable, is it worth revisiting the 496?

I guess this is personal preference. One advantage of the 496 is that the PCI divider is jumper selected instead of being software controlled, which helps with picky cards (like the Matrox Millenium G450 PCI) during early boot. UM8881 boards usually start up at 1:2, then auto-set 1:1 or 1:2 during the main part of the post depending on the detected FSB clock (1:1 up to 33, 1:2 higher), and only switch to the PCI divider specified in the CMOS RAM when the POST is finished. As the Matrox Millenium G450 is not working properly at PCI@20MHz, having 1:2 during POST at FSB40 ist bad.

Personally I just run my '496 system with the PCI clock at 50. Just requires curated cards

Do you know of a network card that won't mind 50MHz PCI speed ?

Many of the intel pro/100 cards are 66MHz capable iirc

Unfortunately for me, all the Pro/100S I have go nuts with 50MHz (random freezes, unable to get IP and other oddities), but are completely fine at 40 and 33... But I don't think they are 66MHz capable either. I had some luck with RTL8169 but I never found a driver that works in Win95.

PCI network cards can be hit or miss on a 486, sometimes even at 40 MHz. I usually give in and install an ISA network card.

I couldn't get ANY PCI NIC to coexist with my promise ULTRA133 in the '496 system, even at 33MHz bus. So yeah I went 3c509