Curious, if there are no DIP switches on the board what happens if you IN port 62h (with bit 3 of 61h 1 or 0)? All 0's, all 1's?
From what I've heard, this is a bit of a strange point with the EMM boards-- they are perhaps not as obsessive about electrical termination as "real" products, so I've seen "unconnected" ports display unpredictable results-- sometimes you'd get different values with an 8088 card versus the V40 card. Reading port 62 produces 0x0E for me whether port 61 is 4C or 40. I think 0x0E or 0x0F on dead ports has been widely reported.
That definitely makes sense why it would report a DMA error if there is no DMA channel 0, as that is not a situation I had considered. So it doesn't have a DMA chip at all and you are using the Malinov floppy ROM for INT 13h, which supports your floppy/flash emulation hardware, right?
You can get an 8237 on a card for DMA purposes. By default it does not cover DMA channel 0, but does do the others. Floppy drives work fine with it. There's a jumper on the card to enable DMA 0 but it still seems to report a "DMA" error at boot.
The Anonymous BIOS tries to set up the DMA controller for refresh, but just passively ignores the fact this didn't actually enable refresh. It probably assumes "well, if no refresh happens, when we get to RAM check or parity later, it's gonna blow up and we'll know THEN"
Can you try this? Under "Enable/Disable POST tests", set all of the tests to 0 and build it again and see if it comes up. Then we can re-enable them one by one and see which is causing it to halt with black screen. I've pushed the other two fixes, though if you don't want to pull and re-merge your V40 code you'll need to change the "JMP SHORT INT_02_AFTER" to "JMP INT_02_AFTER" for it to assemble after you turn off all those POST tests (that's changed in the update I just made too).
I just fetched the 0.1.1 repo and added back the same shimming for now.
I turned off POST_TEST_DMA and it now boots at 8Mhz, and even at 14MHz. For some reason, at anything over 8MHz, many things are stable, but something tends to fire a NMI when you run TOPBENCH. This happens with the other BIOS too. Yours fails with a "tries to reboot, in a weird graphic mode, and freezes at 192k" error, but at that point we're outside "expected to work" territory-- the other BIOS is equally stupid, throwing up a nonsense "Parity error at 00000" message despite the system not being equipped with parity.
Looking at the code, it seems like if the WB_TEST process fails, it tries to jump to WB_TEST_DONE, but there's no return there. It's just marked an ENDP, then "116 bytes empty space" followed by the INT12 handler. In my code, I have the "initialize V40 and keyboard controller" stuff there, and that jumps back to the top of the boot process; I could see this causing an endless loop if the test failed.
Adding a "RET" after WB_TEST_DONE makes it behave how you'd "expect" -- the DMA test fails with an endless loop of two short, four long beeps. I think it booted normally at 7.5MHz still. I did see at least one reboot where it hung, but that was before adding the RET-- maybe the 7.5MHz setup fails a small percent of the time.
That's an easy one -- I found the display bug and it's fixed (1024*16*63 doesn't fit in 16 bits, duh)! Funny, I'd never tested a drive larger than 33MB other than using a Malinov XT-IDE BIOS - which don't actually "POST" until INT 19 so they just aren't visible to the BIOS during on the post screen, thus I never saw one that was wrong. Another great test case - thank you!
Cool. Thanks.
So your CH375 BIOS doesn't actually hook INT 19, rather it just re-vectors INT 13 and expects the BIOS ROM to attempt boot at 80h? I hadn't encountered that in any adapters that I've tested but it makes sense. So the BIOS INT 19 should first attempt boot at drive 0h and failing that try again with 80h? I added a INT_19_BOOT_HD option (enabled by default) that implements that behavior now.
It *optionally* hooks INT 19 (compile-time option). Since the Anonymous BIOS already tries to boot from drive 80, I usually left it off. Of course, something like the XT-IDE BIOS also offers similar functionality. Not a big deal either way-- I suspect the norm on XT class machines may be to override INT 19.
Makes total sense. For whatever reason I had explicitly written "start at 0C800H, end below 0F400H" so whatever source I had read must have been wrong or I misunderstood it - so yeah, F4000 should be included in the scan. Fixed! Great suggestion to add these are configurable options, did that too.
So how much stuff are we talking about? Possible to screenshot just so I know what we're dealing with?
Well, I think it depends on the cards installed. It's completely cosmetic, but I don't know what most "real" drive controllers do. This is probably among the worst case scenarios, two chatty devices, to where the signature for the floppy BIOS rolled off the screeen. Maybe the simplest cleanup would be to draw the floppy/HDD count line after the option BIOSes complete, so they aren't trampling on the same line of the screen. The XT-IDE BIOS, by comparison, is silent at init-time and seems to do all its work during the actual-boot phase.
To clarify, did the error you saw say "KB Init" or "KB INT"? They are actually two different errors, though I can see now that they're a bit too similar -- I'll re-word one of them.
Looks like KB INT. I seem to get it more on warm boots than cold, but I note the DMA error does not seem to occur on a warm boot. Key Stuck is pretty consistently there.
I can probably just add that as an ARCH option for build and have it conditionally included. Is that port range (FFFx) totally standard for the V40? Anything else I should know about the V40 too?
The V40 has configuration registers at FFFx, but the exact values are subject to change. The EMM board doesn't use all the V40 peripherals (notably, giving up on their DMA controller and serial port because it's not PC-like enough), and the wait-state mappings at 0xFFF5 and possibly what memory->wait state mappings at 0xFFF4 are subject to personal taste. The values I'm using now, FFF5=0x25 is are "0 WS for IO, 2 WS for memory over 640k, and 1 WS bvelow that". A more conservative default may be 0xFF (3 WS for everything) and then using a post-boot tool to dial in your preferences.
I can definitely understand the desire to treat this as a generic BIOS, especially early on. There's plenty of dragons to chase in this hardware. It's "north of Sanyo MBC-550, but south of Compaq Portable" levels of compatible, and it probably makes more sense to focus on more standard kit first, so we don't end up wrecking something for everyone else so one weird little hobby kit works better.
On the other hand, maybe the "generic XT" you want to target is a bit of an envelope, and you want machines that bend the envelope. I figure, even if this only targets "100% compatible" machines, it's still valuable for my machine because perhaps it can be hammered into shape as a seperate branch, or used as a source of good ideas. At the least, I see some value in the idea of modular power-on tests, because you could build different options for testing known-incomplete machines. If you know the DMA controller is shot, it's helpful to be able to skip it just locking up on testing that, and move on to other things that could be erroring.
I will note at least one thing this BIOS does better than the Anonymous one-- it was able to autodetect my third serial port, and doesn't have some easily-spooked tests for game ports and clocks. (Since it has some noise on dead ports, these often mislead)
