Aargh! I'll deal with this tomorrow.

See if this is the same:

https://1drv.ms/u/s!As-dKk-N73dSmEkFZg_pNT5wSMjP?e=Eoet0g
MD5: dcd8b6e6d402cd2e4f11dcb14d6c8e1c

same

Ok, try this:

https://1drv.ms/u/s!As-dKk-N73dSmEsryRtGmBsAF5ws?e=pa0HUz
MD5: 2d3d76a2d724099200f169c24b6b9cfd

There should be a mode change to 640x480/16.

It's using a VESA call to change bank. I don't know if this can page in the BIOS. But it's worth a shot.

still got something thats not looks like a ROM, check maybe i am wrong?

No you're right, Maybe the Rendition doc is wrong and the BIOS isn't mapped at that address.

https://1drv.ms/u/s!As-dKk-N73dSmExl2KIwxAc4NjTl?e=fOAE2V
MD5: 9370c8affb2f6070e74608f3f28ec323

This is built on the assumption that the BIOS will be paged in at 0xC000:000 and not 0xA000:0000. We tried A000 and it didn't work.

There're two exes, fifo0 and fifof. Try them both. Both of them should produce the first 64 KB of RAM correctly. If the second half is a duplicate of the first, then it's failed. If you just scroll through them with a hex viewer you should the same set of string s(Phoenix BIOS, Rendition, blah blah) at around the halfway mark.

This time I'm also checking the bankSelect register after writing to it to make sure something hasn't gone wrong.

success

Thanks, but that's not actually correct. The first 64 KB repeats in the second block.

So the paging's not working properly.

This is the problem:

Access ROM bank 0000FFFE
ReadDWordFromPort D074
Read 80FE0000 from port D074
Error current bank is 80FE0000, set bank is FFFE0000

and this:
Access ROM bank 0000FFFF
ReadDWordFromPort D074
Read 80FE2000 from port D074
Error current bank is 80FE2000, set bank is FFFE2000

I think we tried this already:

https://1drv.ms/u/s!As-dKk-N73dSmE1ZoyJTgfeulhQA?e=XrEZmO
MD5: d9660325dc281fc0eed096c6785beb7e

if this doesn't work, it doesn't matter I'll find another way to get the stuff running. I have a few ideas.

The reason the ucode never affected RReady was that I implemented different observed behaviours as feature flags which could be enabled or disabled depending on the app. Quite a few of them are used by multiple apps. I think these differences are down to microcode.

For instance MDK renders solid colours with an alpha of 0. There's one other game that does that. They do this with blending enabled which means nothing should be visible. Using an alpha of 0 for solid colours produces a blank screen with RReady but not actual Verite hardware. Other games like vQuake 2 uses 0xFF for alpha, which is what you would expect. So for MDK and the other game I force alpha to be 0xFF for solid colours (or colour * texture) (and only for these two). I think these differences are down to microcode.

At the time I just assumed it was because of a misinterpretation of the RRedline spec. But now I'm not so sure.

@Raven-05, does your board use IRQ 10 and

@AgentoftheBSOD, does yours use IQ 11?

how to get know? will try to find , not sure on how to.

Device manager should list it, I think, under properties for your board (in one of the tabs).

https://fex.net/s/apkboet IRQ is 11, i hope under dos its same, i think it should be.
not a bios dump i think

I think I've confused the setmode folders. @agentbsod's irq must be 10

The ports and mem range match the dos results.

in dos go to c:\dos\
msd.com

and also here
C:\CTCM
ctcu.exe

you can change cards irq in bios by "reserving for legacy/isa cards" the irq the card uses right now