• Please review our updated Terms and Rules here

Display Telecommunications Corporation "Megaboard".

I just ran the BIOS on a IBM 5150. I must report an almost full success! It's complaining about the ROM checksum, but otherwise everything works flawlessly.

My configuration is:
- IBM 5150 motherboard, fully populated with 256KB of RAM, V20 processor, no 8087
- IBM CGA card, monitor connected via composite (I don't have a CGA monitor or a suitable converter)
- IBM floppy controller
- AST SixPackPlus, fully populated with 384KB of RAM
- XT IDE
- 360KB drive attached, though still not tested with the BIOS
- MS-DOS 6.22
- Motherboard switches set to: SW1: Off-On-Off-Off-On-Off-On-On, SW2: On-Off-On-On-Off (rest don't care)

So far the only issue I've found is that it hangs during CheckIt 4's "Multipage Screen Access Test (Mode 03h)" and stays in "Testing Video Page #3". Otherwise things are looking really good! I will try to resolve this and the checksum issue. The easy way of solving it is by using DXC to append the checksum byte. However, that would mean stripping the "H" from "DKH" at the end of the BIOS. I think it's a reasonable compromise, at least for the time being.
 
Here are some pictures of the experiment:

Initial screen, with the checksum error code (001):
PXL_20240220_202759829.jpg

BIOS splash screen while it's trying to boot from floppy:
PXL_20240220_202806864.jpg

Boot error from floppy (no diskette was present at this time):
PXL_20240220_202813715.jpg

Successful boot from XT-IDE:
PXL_20240220_203025460.jpg

I tried reproducing the video test failure, but this time it passed fine so no screenshot for that.
 
I just ran the BIOS on a IBM 5150. I must report an almost full success! It's complaining about the ROM checksum, but otherwise everything works flawlessly.

My configuration is:
- IBM 5150 motherboard, fully populated with 256KB of RAM, V20 processor, no 8087
- Motherboard switches set to: SW1: Off-On-Off-Off-On-Off-On-On, SW2: On-Off-On-On-Off (rest don't care)
So... one thing to note... the 5150 is wired differently to the PPI than a 5160 (or every other clone) with regards to the DIP switches, so it may not work quite as expected with regards to setting the RAM size and video type. It may work, out of just dumb luck though, with some video adapters.

So far the only issue I've found is that it hangs during CheckIt 4's "Multipage Screen Access Test (Mode 03h)" and stays in "Testing Video Page #3". Otherwise things are looking really good! I will try to resolve this and the checksum issue. The easy way of solving it is by using DXC to append the checksum byte. However, that would mean stripping the "H" from "DKH" at the end of the BIOS. I think it's a reasonable compromise, at least for the time being.
I found that several of the decedents of this BIOS used offset 0x1fef (the row right above the "H") to insert the checksum byte since it's otherwise unused... so I'd just make a guess that's what DKH did originally! Might be wrong... won't know until we uncover an original binary ROM someday! :) On my build of it, replacing the FF byte with AA balanced the checksum (leaving the DKH as is), so if that works for you then you know our binary builds are identical. (y)
 
So... one thing to note... the 5150 is wired differently to the PPI than a 5160 (or every other clone) with regards to the DIP switches, so it may not work quite as expected with regards to setting the RAM size and video type. It may work, out of just dumb luck though, with some video adapters.
You're absolutely right. I'll check how the BIOS expects the switches and update accordingly. What surprises me is that it boots so fast. Makes me wonder if it's actually doing any memory test at all. However it did detect 640KB. Also, just verified that it doesn't respond to SW1 5 and 6. So I'm stuck with CGA 80 columns.

I found that several of the decedents of this BIOS used offset 0x1fef (the row right above the "H") to insert the checksum byte since it's otherwise unused... so I'd just make a guess that's what DKH did originally! Might be wrong... won't know until we uncover an original binary ROM someday! :) On my build of it, replacing the FF byte with AA balanced the checksum (leaving the DKH as is), so if that works for you then you know our binary builds are identical. (y)
I'll try modifying a random byte to make it match. I think the easiest way to do this (for now) is to use DXC, then drop the extra byte. In the future, a custom tool could be written to remove the extra byte and modify a value in a certain location (unused) so the checksum zeroes correctly.
 
Back
Top