.

I used your microcode. What's the result, video seems to cut off right at flash complete so not sure how reboot went.

If failed you'll have to manually kick in dual BIOS recovery if it does not itself.

If that failed, then 196 and 155 fail at inserting NCPUCODE on this BIOS, so does 115 I tested and it doubled the size so it's a fail.
Have to try some others next, that or the NCPUCODE you posted isn't good to use modified in tht way.

I see what you mean now, in MCE. That's the microcode you attached. And I see it has 37 in when put in BIOS, but only 34 before that, very strange!

I can make all new ncpucode tonight, and BIOS if you want, but I have to leave right now. Hope you can get recovered before tonight if that's a bad flash above!

.

If you guys are using that checksum patcher called Patch64 I posted in another thread use it with caution because I have found that depending on the option rom it sometimes works and sometimes does not work correctly. Ethaniel in another thread about building a custom nvme option rom driver posted his own checksum patching utility that produced different results though his utility also changes the device vendor ids and was specific to his driver.

No, I did not use patch64 @davidm71, since I see it does something but can't tell what that is I do not use. I saw it say inserting something once when I tested I think, not sure what it said, but whatever it was didn't look like checksum related to me so I don't use.

As for the corrupted microcode, just that one that is doubled or corrupted will fail to load if that CPU is used (CPUID F34 it looks like)

I'll make a new BIOS later tonight, with corrected microcode, that way any CPU you use in the future will work as expected.

* I tested a bunch of cbroms, all that work give that same microcode packing error, so I think maybe it's due to that NCPUCODE.BIN.
I'll make a new one tonight without the editing you mentioned and see if that works better,

.

@Bugger Vance and @MiesMosel and @winactive

The 'Patch64.exe' utility you guys were talking about and shared couple pages back is the same one (checked byte by byte) I had compiled from Pinczakko's source code over here: https://github.com/pinczakko/PCI-Expansi.../master/utility

The way you use it is 'Patch64 option.rom' however I have discovered mixed results and would not use it at all for microcode files (though I never tested that out).

Recommend using a bosch emulator or Qemu to test the checksum corrected roms before flashing.

Just a public service announcement.

As you were.. Carry on..

Thanks for the link and info on that, I'll have to read about it's intended use. I asked you for a copy while back, I remember that, but never used other than a test to see what it did and since not knowing how it was supposed to work it looked off to me so I set aside.
I'll read about it now, thanks! Normally I don't run into issues where checksums are a problem, but always good to have tools to check things when possible and when there is problems.
I see, it's for fixing PCI Rom checksums, so nothing we really need when doing these kind of BIOS mods.

Thanks @konstantiniyyr I download it once from your previous post, that's the code I inserted on the BIOS. I was thinking earlier today, maybe the way you modified it, cbrom saw that and didn't like so tried to correct it maybe? And maybe that's how it gets corrupted on insert?

I'll build a new one myself, and hopefully not have this issue. BIOS coming once I make new NCPUCODE.BIN

@konstantiniyyr I see what you mean now, even with new NCPUCODE I made, same happens with MANY Cbroms (Duplicated microcode entry @ 13 > 37)
I tested following cbroms - 140, 149, 151 & 1551, 180, 182, 195, 196, 198, 199 << all do the duplicated code from middle to end

These cbroms fail to insert, or insert poorly and crash or corrupt etc
115 (Doubles code size), 124, 208, 602, 132, 214, acebrom, ACBROM208, 201, 130, 201b, 205, 207, 215, 217A, 219, 220, 606

Now I see why you did the Hex editing! There will be dupes in this BIOS 1067A (x2) and 10676 (x3), but on purpose, only due to separate codes for different platforms.
This way you can use this BIOS for any 771 CPU too, if you want. These dupes are not same as cbrom created dupes due to this bug, I insert these on purpose to all 775/771 mods

So I think best is what method I mod for you earlier (Cbrom196 for insert of NCPUCODE), I did same now and used my NCPUCODE.BIN and then hex edited (entire BIOS), and remove the dupe cause by cbrom @ last entry only.
So possibly same mod you did initially, but maybe I did better way, so should flash and does not have dupes.
After all that I extracted a PCI ROM with cbrom115 and reinserted post hex edit.
I'm not sure if that's required or not, but I think it's best that way and maybe what cause your initial mod to fail, unless the hex edit/dupe issue caused it

BIOS Attached

.

Ahh! I didn't even notice! When I copied the microcodes from the extract folder, that's the one that's marked bad by MCE when the file is duped (But F32 is the one doubled at the end).
So when I tossed out F34, I forgot to get a new copy, then removed the F32 at the end and must have been thinking that was the "Bad" one without looking back.

I'll make new one shortly and add here, sorry about that! * Attached now, all checked and rechecked again this time, no double and includes F34

I think it's finally done, except your re-edit to update that rom! :)

.

I was wondering if the many codes was making cbrom choke, but it seemed if 34 or 37 all those versions did the dupe thing so maybe it hasbe less than that still.

Anyway, all fixed and attached above now if you want. I think those you mentioned 1067a and 10676 does cover most of the current BIOS most would use.
But you never know what you might want to test or play with and I think that's why we all always try to leave all the older codes there too.
Really, if you wanted, you could only use a single one for your current CPU, so a single microcode in NCPUCODE and that would be fine too, if you wanted to push the minimum :)

.