Scraphoarder wrote on 2024-05-07, 16:59:

Thanks and nice to see someone else also made progress on making theese boards usable. Maybe i will try to dig up one of mine that also have two unresponsive ram slots and flash your BIOS.

I don't think the issue with RAM slots could be fixed from the BIOS side. The RAM slot problem was more likely hardware. My BIOS files only added additional microcodes needed for proper support of 45nm CPUs as well as updated all of them to the latest available version.

The 008 version of BIOS apparently had a few additional options in the ACPI part that were not present in 009 version, though it was not too important to me. It's advised to use the same BIOS version as the one your board has, as flashing the other version requires a few extra options to "force" it.

I did not actually fix the ISA DMA problem on the BIOS side. I simply found out the cause of it and that can be easily corrected using programs that could manipulate PCI registers.

Its inability to fully utilize quad-core CPU was likely due to its ACPI tables declaring only two CPU entries compared to four in the ACPI tables from ASRock 865 boards. I just don't know which is the correct way to edit and rebuild ACPI tables for old AMI BIOSes...

It seems the 1.0s1.2 (865G with real AGP slot) version is becoming harder to find around my place... while 865GV, which 1.0s1.3 uses, is rather unfit for use with a discrete PCI video card, due to its onboard video cannot be disabled. The respective register controlling whether or not to enable the onboard video is read-only in 865GV, while read-write in 865G. As such, if using a discrete PCI video card, both the onboard and discrete video would be active in the OS which may lead to problems if you're not actively using the onboard video.

Was a little unclear what i wanted to do, but i was thinking to try tinkering with the board with bad ram slots if something went poop with flashing modded BIOS. I have two other thats ok. All my three boards are v1.0S1.2, but since i wasnt eager and able to fork out $275 for a russian BIOSmod with some software i put them all in storage waiting for better times.

I purchased one of these boards a month or so ago and am working on putting together a system with it.

The BIOS battery had already been replaced with a CR2032 holder.

All memory slots seem to work fine.

However, even with the posted BIOS with the added microcode, I am unable to get any QX CPU to work with it.
I have tried:
QX6700
QX6850
QX9650

All I get is a a single repeating beep over and over again.

I do have an X6800 on the way.

Is the FSB mod required for the 1066 FSB CPUs to work at all? Previous posts seems to make it look like it is not required.

cyclone3d wrote on 2024-06-10, 21:32:

I purchased one of these boards a month or so ago and am working on putting together a system with it. […]
Show full quote

I purchased one of these boards a month or so ago and am working on putting together a system with it.

The BIOS battery had already been replaced with a CR2032 holder.

All memory slots seem to work fine.

However, even with the posted BIOS with the added microcode, I am unable to get any QX CPU to work with it.
I have tried:
QX6700
QX6850
QX9650

All I get is a a single repeating beep over and over again.

I do have an X6800 on the way.

Is the FSB mod required for the 1066 FSB CPUs to work at all? Previous posts seems to make it look like it is not required.

I recommend against using Extreme edition CPUs including X6800. The BIOS' CPU ratio option is bugged. With an Extreme edition CPU, it will first try booting with a maximum ratio (something like 60x) and fail. You need to somehow force the BIOS to believe there's an overclock failure so it'll start in a failsafe mode at lowest possible ratio, then you can specify the ratio value you want.

Ideally you'd want 1066 FSB CPUs to work at 800 FSB. Getting 1333 FSB CPUs to work at 800 FSB may not be as easy as with 1066 FSB ones. The FSB mod in question was applied to a transistor related to a BSEL bit, not directly on the CPU, according to the Modlabs post I referred to when I did mine.

However, it seems BIOS still shows 1066 for an E7600 I tried. I wasn't able to conduct further tests to prove whether it really worked, as I kind of irreversibly borked the test board when I tried modifying its ACPI table to add a 3rd and 4th CPU entry (in hope this will enable proper quad-core CPU support). A key part is that with the FSB mod applied, I did not have too much trouble getting E7600 booted, while previously I had to set RAM down to 266MHz (lowest) in order to let it boot properly.

Again, the board's ACPI table had only two CPU entries so only dual-core CPUs can work as expected. Similar 865 motherboards that do have proper BIOS support for Kentsfield (65nm C2Q) have 4 CPU entries.

With correct microcodes added 45nm Pentium Dual-Core E5000 family (FSB 800) will work best. 65nm CPUs would occasionally drop bus speed to 100MHz, while I don't see this happening often on 45nm ones. The only major caveat with 45nm CPUs is that ACPI shutdown no longer works. The system would simply freeze once it finishes shutdown, and you need to manually power it off by holding the power button for at least 5s.

Ok, that clears things up a bit. I bet I can get quads working. If I brick the BIOS somehow I can pull the chip and reflash it.

I also want to try to recreate the Russian fixes so ISA DMA works without having to have a program to set it.

cyclone3d wrote on 2024-06-11, 03:22:

Ok, that clears things up a bit. I bet I can get quads working. If I brick the BIOS somehow I can pull the chip and reflash it.

I also want to try to recreate the Russian fixes so ISA DMA works without having to have a program to set it.

Just be careful. I think you should backup a complete copy of your BIOS ROM (using an external programmer) before you try to make changes.

AFUDOS won't save everything. It's possible some stuffs in NVRAM may be needed in case you bricked and requires recovery.

I never did a full ROM backup, and now the board doesn't even boot anymore after I replaced the BIOS chip with another one flashed a known working AFUDOS backup -- it just gives out a long beep followed by 6 short ones.

As for ACPI table editing -- IASL probably isn't a good idea. I made my modifications with IASL and while there were no errors when recompiling and re-decompiled results did not look too out of place for me, it borked the BIOS when I tried it (the BIOS can boot, but will hang at a POST code supposedly about building ACPI tables). For old AMI BIOSes like these you probably need to look for Microsoft's ACPI tools to do the job.

On the other hand, if you have knowledge with BIOS editing perhaps you can try peeking into the behaviors of the DMA reserving toggles in the PCI/PnP section, and see if you can somehow alter their behavior, like setting "Reserved" to make the particular DMA channel route to PC/PCI instead of LPC (according to the datasheet).

I had looked at IASL and came to the conclusion that it would not be the right tool to use. From what was coming up, it looks like it is specifically meant for hackintoshes and the instructions say that it automatically adds the changes when using the tools to get the AHCI tables which is not what we want.

Edit: were you using the iASL from Intel or one of the ones posted around different hackintosh sites?

cyclone3d wrote on 2024-06-11, 14:38:

I had looked at IASL and came to the conclusion that it would not be the right tool to use. From what was coming up, it looks like it is specifically meant for hackintoshes and the instructions say that it automatically adds the changes when using the tools to get the AHCI tables which is not what we want.

Edit: were you using the iASL from Intel or one of the ones posted around different hackintosh sites?

I did my edit from Arch Linux. IASL is part of the "acpica" package in "extra".

Just I don't know which is the correct way to replace the ACPI table in old AMI BIOSes...