dartfrog wrote on 2025-05-15, 05:35:

That's an interesting ISA post card and a very cool feature. Have you posted about that somewhere? I'm sure the larger community would be interested in schematics if you're willing to share.

Not in english, can be auto-translated http://rayer.g6.cz/hardware/postcard.htm
Schematic is not complete without display decoder:
http://rayer.g6.cz/hardware/postcard/pisasch.jpg
PCB was drawn manually, far beyond I learned to use some PCB layout SW. Just drawing with permanent pen directly on PCB and etched in FeCl3 solution 😀
I don't see if any commercially available POST card nowdays has configurable address decoder. They usualy use some hardcoded PAL/GAL PLD...

vsharun wrote on 2025-05-13, 19:50:

Gigabyte B85M-D3H rev 1.0 of mine with F14 bios has "enough" overclocking headroom, so 4670k @4.5GHz 1 core 1.32V stable and only 20%-ish slower than 12700k @4.9 in SuperPi (104s vs 80s 8M).

My Sandybridge @4,5GHz: 95s 8M (with fast DDR3 2133MHz)

RayeR wrote on 2025-05-15, 16:52:

vsharun wrote on 2025-05-13, 19:50:

Gigabyte B85M-D3H rev 1.0 of mine with F14 bios has "enough" overclocking headroom, so 4670k @4.5GHz 1 core 1.32V stable and only 20%-ish slower than 12700k @4.9 in SuperPi (104s vs 80s 8M).

My Sandybridge @4,5GHz: 95s 8M (with fast DDR3 2133MHz)

This B85M-D3H can't do more than 1600 (seems chipset limitation) and memory speed aren't something selectable in BIOS. Despite CL9 1833 modules.

vsharun wrote on 2025-05-16, 07:42:

This B85M-D3H can't do more than 1600 (seems chipset limitation) and memory speed aren't something selectable in BIOS. Despite CL9 1833 modules.

AFAIK only Z chipsets (e.g. Z87, Z97) can actually make higher speed memory run at their rated frequency (overclocking). And yes, P67 can also overclock memory.

There's a caveat for 6/7 series, however, is that only B and Q chipsets of those generations have native PCI.

Hm, I wonder how chipset plays role here when the whole DDR3 memory controller is integrated in the CPU (DIMM wires goes directly to CPU pins). It seems to me like stupid BIOS limitation. Similar as when I put K-version of Ivybridge to P67 MB and overclocking was not available until I updated ME module from 7.x to 8.x then BIOS allowed multi up to 63 same as on Sandybridge...

Think you hit the nail accidentally there.
It's not a bios issue, it's firmware in the cpu/me.

myne wrote on 2025-05-16, 14:34:

It's not a bios issue, it's firmware in the cpu/me.

One of the X99 motherboards I tested had a disabled LPC Clock signal, turns out it's part of the ME and completely undocumented.

I really couldn't be bothered figuring it out so I just got another motherboard

Small update, I got the ISA protocol DLL compiled and it seemingly works (untested as I'm waiting on 8 port TLA module and extra probes to arrive but the TLA machine and software both allow for it's selection and loading of the protocol DLL and doesn't crash). It's a full bus analysis support package, so that's neat. It should allow for both 8 and 16bit full ISA protocols as described in the "ISA system Architecture 3rd Ed" book. I'm almost finished with the ISA interposer board. I've got to pack the ISA signals into as few Mictor 38 pin connectors as possible since they are quite expensive at like 18 bucks a piece. It will require DLL recompilation to meet the pin matching of the new board, but that's of no issue. I might be able to get it down to three Mictor38's for each interposer but idk yet probably more like four. Right now finishing up the PCI support package based on the "PCI System Architecture 4th Ed" book, and working on compiling that for Windows 2000 with Visual Studio 6. (Weird fun fact, VC6 still works on Windows 10, 🤣.)

I probably won't respond here for a little while as I wait for gear and finish all this stuff up. I'll still have to wait for PCBWay for interposer boards and futureelectronics for connectors, so it might be a minute before I have another update. However don't worry I'm still full steam ahead, my wife won't let me quit now and requests daily updates haha. In the meantime I've already developed a Pico based AT24C02 programmer and an external AT24C02 configuration tool which will generate a bin for the IT8888's configuration EEPROM, so I'll probably go back and check my work here and mess around with that a little bit, and also add a Pico socket to the prototype for in-circuit programming of the AT24C02 chip for easier fiddling. Basically you plug in a usb to pico from pc, and either paste a hex from config tool or load a pre-generated config bin and the Pico programs the EEPROM for you. That way configuration of the card can be done easy by an end user and me while testing.

Anyway, hope you're all doing as well as I am. 😀

Edit: I modified the TLA700 ISA code to test on my 68 channel module while I am waiting for the 138 channel modules, and yes the compiled DLL does seem to work. So that's awesome! The minimal implementation can see Address, Data, Control, DMA, and IRQ signals. Very nice. PCI 138 channel is also done for now. Super cool and exciting stuff here.

A bit late, but excellent work rasteri! Somehow, your British voice-over on the demo video adds a touch of elegance to the presentation. 😀

One friend sent me a link to document that could be relevant to PCIe bridge implementation:
Oxfor semi. appnote - Incompatability between Legacy Base Addresses & PCIe Devices
https://archive.org/download/33.-oxford-legac … ress_Ranges.pdf

have a check... (page 3 describes what I mentioned before...)

RayeR wrote on 2025-05-22, 16:32:

One friend sent me a link to document that could be relevant to PCIe bridge implementation: Oxfor semi. appnote - Incompatabilit […]
Show full quote

One friend sent me a link to document that could be relevant to PCIe bridge implementation:
Oxfor semi. appnote - Incompatability between Legacy Base Addresses & PCIe Devices
https://archive.org/download/33.-oxford-legac … ress_Ranges.pdf

have a check... (page 3 describes what I mentioned before...)

Atm I've just been trying to confirm baseline ISA/PCI functionality and really haven't been worrying about PCIe yet. But yeah that confirms PCIe is not going to work without a FPGA solution to have a custom address translation layer between legacy address ranges and PCIe device BARs. I did check a bunch of various bridge chips both high-end and lower grade and couldn't find a single one that had programmable address translation features, if anyone can find or knows of one that might work. However it still has the same problem with the FPGA solution. Problem with these is the need to rewrite any software expecting legacy fixed addresses, since it would now need to discover PCIe device BARs dynamically instead of using hardcoded addresses.

Edit: Although, if one used dosbox / emus it might be kind of simple to make dosbox / emus to discover PCIe device BARs dynamically and allow the hardware to been seen by dosbox / emus and fake the dynamically discovered PCIe device BARs as legacy devices. So no legacy software would need to be patched/rewritten.

Pcie is basically an Ethernet network topology.
Most boards have 2 switches.
The cpu, and the chipset.

I expect it's its going to work, direct from the cpu is the way to go.

myne wrote on 2025-05-23, 02:48:

I expect it's its going to work, direct from the cpu is the way to go.

I hope so, but it's problematic as you will probably need to split x16 VGA slot to two x8 and mechanically put VGA in some riser. Not sure if there are other accesible direct CPU PCIe lines like for NVME but at least intel desktop CPUs don't have much PCIe lanes...

Had a long train journey so to kill time I started laying out a PC/104 version of the IT8888 adapter.

Managed to get (nearly) all the PCI traces onto a single layer!

rasteri wrote on 2025-05-25, 18:44:

Had a long train journey so to kill time I started laying out a PC/104 version of the IT8888 adapter.

Managed to get (nearly) all the PCI traces onto a single layer!

That's gorgeous. Great job on routing, I will have to steal your layout haha.

That reminds me, I meant to post a pic of the prototype a while ago when I was in mid-soldering mode. It's been done for a bit now but I don't have a pic of the finished card atm. I'll post one when I get a chance.
Edit: Btw solder joints look "cold" because I use lead free MG Chem 4933 Sn100e. It's like 99.5% Tin, so it always hardens grey/dull. (Yeah yeah get leaded solder I've heard it a million times, no thanks. Yes I use MG Chem flux too, I just clean the board often.)

rasteri wrote on 2025-05-25, 18:44:

Had a long train journey so to kill time I started laying out a PC/104 version of the IT8888 adapter.

Managed to get (nearly) all the PCI traces onto a single layer!

Why does yours look so much prettier?

Did I screw up the slot direction?
Spacing? Wire size?

I have a suggestion for when/if it works.
Make it so an isa card can mount upside down. Ie, the connector from the top with a ribbon maybe.
Then with a bit of jigging and an upside down backplate, it should fit in a pci slot.

LSS10999 wrote on 2025-05-14, 02:37:

I'm not sure about the reliability of Rloew's AHCI driver, as I'm having issues with it on my ASRock X99M Killer/3.1 with dISApp […]
Show full quote

RayeR wrote on 2025-05-13, 18:33:

Yes, it must be some odd issue of your specific MB/BIOS, normally pcie vga is no problem under w98. You can dump and compare pci bridges configuration (pci config space registers) of this MB and similar working MB if you find something...

If you ebable AHCI mode it activate IDE BIOS that provides INT13h services that DOS relies on and win98 can use them in compatible 16b mode. Also if I remember there's some Rloew AHCI driver? I rather use IDE compatible mode that also enable low level utils that access disk via legacy IO ports. Win98 sees it as native dual channel IDE. But only if I boot from HDD on sata2 channel, it doesn't work on sata3 channel (my MB has 2 sata3 + 4 sata2)

I'm not sure about the reliability of Rloew's AHCI driver, as I'm having issues with it on my ASRock X99M Killer/3.1 with dISAppointment v0.2.

Simply put, the AHCI driver would cause I/O errors (which begins with an abrupt stop of disk activities) from time to time on my system, that Windows would show a blue screen every time it happens warning about data loss, though I don't really notice anything apparent as the failed I/O may have been successfully repeated afterwards. Inspecting the partition from Linux via fsck doesn't show any apparent error on the file system.

The I/O errors caused by the driver would register on my SSDs' SMART log which would additionally cause Windows to think my disk has developed bad sectors that it keeps insisting on doing a surface scan, that I had no choice but to disable such checks altogether via msconfig, since the partition was rather big that it's going to take hours to finish even for a SSD, and I worry whether ScanDisk can properly handle disks larger than 137GB. It's just the I/O error counter was incremented, not the amount of pending/reallocated sectors.

As such I had to run Windows 98SE without using any disk driver. The disk performance is as fast as using the aforementioned AHCI driver, just I lose the ability to use animated cursors.

I was just about to post the other day that I had none of these issues with a qm57 chipset and RLOEWs AHCI patch then BOOM the system wanted to scan for bad sectors. It's been months of stability and no bluescreen, it just happened

Dothan Burger wrote on 2025-05-26, 13:17:

I was just about to post the other day that I had none of these issues with a qm57 chipset and RLOEWs AHCI patch then BOOM the system wanted to scan for bad sectors. It's been months of stability and no bluescreen, it just happened

Did you check the disk with some diagnostic tools like HDAT2? Check the SMART log to see if it ever registered any errors and see if any concerning SMART attributes get incremented (I/O errors, pending/reallocated sectors).

In my case the errors are logged in my disk's SMART log as well as I/O error counter, but no reallocation happened, and the affected files don't appear to be really corrupted.

Though I'm curious about how Win9x/ScanDisk would think about doing surface scans on top of standard scans. Does Win9x somehow read SMART info during boot process? The thing is, Windows would keep suggesting doing surface scan even after I checked the file system and cleared dirty flags on it from Linux using fsck.

myne wrote on 2025-05-26, 10:52:

Why does yours look so much prettier?

When I lay out a board I try and get as much routing done on the component side as possible, then leave the bottom side for a ground plane. So the first thing I do for all PCI signals is get them onto the top side.
I'm guessing freerouter prefers to leave signals on the layer they start on, which for the PCI edge connector is sometimes the bottom side.
Also just in general hand-routed boards always look prettier than autorouted ones 😀

If it's any consolation, my ISA section is a complete mess :

I have a suggestion for when/if it works.
Make it so an isa card can mount upside down. Ie, the connector from the top with a ribbon maybe.
Then with a bit of jigging and an upside down backplate, it should fit in a pci slot.

That is a good idea.

LSS10999 wrote on 2025-05-26, 14:20:

Did you check the disk with some diagnostic tools like HDAT2? Check the SMART log to see if it ever registered any errors and se […]
Show full quote

Dothan Burger wrote on 2025-05-26, 13:17:

I was just about to post the other day that I had none of these issues with a qm57 chipset and RLOEWs AHCI patch then BOOM the system wanted to scan for bad sectors. It's been months of stability and no bluescreen, it just happened

Did you check the disk with some diagnostic tools like HDAT2? Check the SMART log to see if it ever registered any errors and see if any concerning SMART attributes get incremented (I/O errors, pending/reallocated sectors).

In my case the errors are logged in my disk's SMART log as well as I/O error counter, but no reallocation happened, and the affected files don't appear to be really corrupted.

Though I'm curious about how Win9x/ScanDisk would think about doing surface scans on top of standard scans. Does Win9x somehow read SMART info during boot process? The thing is, Windows would keep suggesting doing surface scan even after I checked the file system and cleared dirty flags on it from Linux using fsck.

No I haven't checked the drive with any tools. It scanned the drive, found no errors and booted like normal with no subsequent scans. Sorry if this was unrelated.

LSS10999 wrote on 2025-05-26, 14:20:

Though I'm curious about how Win9x/ScanDisk would think about doing surface scans on top of standard scans. Does Win9x somehow read SMART info during boot process? The thing is, Windows would keep suggesting doing surface scan even after I checked the file system and cleared dirty flags on it from Linux using fsck.

AFAIK Win98 doesn't have any SMART check, it was needed to use 3rd party utility for SMART reading. I believe that scandisk is triggered only by dirty flag in FAT16/32. There shouldn't be any periodic timer like in linux that runs fsck if not checked xx times. Are you sure that other OS didn't touched the partition? Maybe even Win98 shutdown properly some service responsible for resetting dirty flag didn't do the job. I don't have such problems on my intel P67 but I'm not booting to W98 very often last years...