• Please review our updated Terms and Rules here

Build IBM 5150 BIOS from Source

willmurray461

Experienced Member
Joined
Jun 11, 2018
Messages
303
Location
Boca Raton, FL
Whilst on my journey to upgrade my 5150 to a 486, I've encountered a problem with the original IBM BIOS. Unfortunately, for some reason, the combination of a Transcomputer HPi 486 and Intel Inboard cause the BIOS's 8253 or 8259 test to fail, thus halting the system. If I swap the BIOS for a generic turbo xt bios, the system is able to boot. However, I would like to use the original BIOS if possible. I've determined the necessary edits that need to be done to the original BIOS to disable this check (along with a checksum disable), however I can't seem to figure out how to assemble the file. I know that the bios must be built with Intel's ASM86 2.0, but I don't know how to do this. There is a copy of ASM86 3.0 available for DOS, however it seems that 2.0 existed only for Intel development systems. When attempting to build the source with ASM86 3.0, I get an error (which also has no line number reference unfortunately), and a .lst and a .obj file, which I don't know how to link. Using the Intel LINK86.exe, I just get a .LNK file. Does anyone know how to properly build this BIOS?
 
Does anyone know how to properly build this BIOS?
What I did was converting the text to NASM format. Unfortunately the outputted BIN file is not the same as the original one: Nasm translates some instructions into other but equivalent codes than NASM/TASM does. I did disassemble various BIOS of some Commodore PCs, assembled the results with NASM, calculated e new checksum byte and those PCs ran just like if the original BIOS had been inserted.
If interested, I have the 1981-04-24 BIOS in NASM format, but not documented. I created a little tool that checks for differences of the generated BIN with the original ROM. If found, it checks if the difference is an instruction that can be translated into more than one binary code. If indeed, it continues testing, if not, I have to find out where things went wrong. If an error occurs, in most cases the code generated by NASM has a different size, resulting in bytes that don't match with the original ones anymore after that instruction. In that case I replace the instruction with a DB statement.
 
In case anyone wants to know, I now know how to edit and compile the 5150 '82 BIOS (and theoretically any other IBM BIOS created for the ASM86 Macro Assembler). Using the guide here, I was able to learn the syntax for the command line tools needed (ASM86.EXE, LINK86.EXE, LOC86.EXE, OH86.EXE, DXC.EXE), and run them in DOSBox to create a byte-for-byte copy of the original BIOS. The real trouble was finding DXC.EXE, which is needed to convert the output file in Intel Hex format into a usable plain binary. At first, I couldn't find it anywhere on the internet as it wasn't packaged in any of the archived Intel toolchains (or anywhere else, for that matter), so I tried some other programs that claimed to be able to do the same thing. I tried various versions of hex2bin for DOS and Windows, as well as srec_cat on OS X, but neither of them worked properly (either giving errors or producing strange 1MB bin files). Eventually, I contacted the owner of the website and he kindly sent me the file I needed. Without him, none of this would have been possible, and I'm curious as to how he got the file in the first place. Anyway, I'll attach the files here for anyone else who wants to give it a try.
 
Hi,

Can you build me the BIOS for the IBM 5160 and out put the IBM logo ? Big "I B M" blue text on black background. That will be chick!!!!
 
I'm sorry for side tracking this completely awesome thread but I'm going to do it anyway. Has anyone ever found the source code to the IBM 5150's cassette basic which is loaded into ROM?
 
Hi,

Can you build me the BIOS for the IBM 5160 and out put the IBM logo ? Big "I B M" blue text on black background. That will be chick!!!!

If you're asking me, I'm not too much of an expert when it comes to assembly. I also don't really have the time right now. It might be really easy, requiring only BIOS interrupts (I'm not sure if you can call one from within the BIOS though). It might also be more complex, requiring manipulation of CGA color registers. Either way, If you really want this, I suggest you try on your own. Assembly can be a daunting language to try to learn, but with the right literature it can become understandable.

I'm sorry for side tracking this completely awesome thread but I'm going to do it anyway. Has anyone ever found the source code to the IBM 5150's cassette basic which is loaded into ROM?

We have the source code for the 5150/5160/5170 BIOS's thanks to their listings being published in IBM Technical Reference books, presumably to help programmers. However, AFAIK, no versions of ROM Basic ever had their source code published. If there is a version of the source code out there, it would likely be in the hands of one of the original developers, or someone who inherited it from them. It would also likely be on a disk readable only by Intel ISIS development systems, something few people have.
 
It's definitely possible to reverse engineer binaries, however it requires someone with enough time and the right expertise. In any case, I wouldn't really hope on it ever happening unless you taught yourself how to do it though...
 
I'm sorry for side tracking this completely awesome thread but I'm going to do it anyway. Has anyone ever found the source code to the IBM 5150's cassette basic which is loaded into ROM?

Microsoft wrote the 5150's cassette BASIC and the BASIC.COM / BASICA.COM "extensions". Source for the ROM is unavailable, but the GW-BASIC sources circa 1983 have been released by Microsoft:

https://github.com/microsoft/GW-BASIC

I suspect that large portions of the ROM will match with what's in the GW-BASIC source. With enough time you could essentially cross-reference the ROM disassembly with those sources and produce a coherent listing of the ROM with proper symbols and labels and comments.

(I've been working to do this for the PC-DOS 1.10 version of DEBUG.COM, using the MS-DOS 2.11 sources as a reference.)
 
That sounds like a great strategy. Sadly, it's not something I'd be able to put time into anytime soon.
 
One kind of gross thing about the Microsoft BASIC source code for the IBM PC is at the time Microsoft maintained a lot of the "core" parts of their code as a semi-machine-independent pseudocode (Mostly based on how the 8080 rolls, I believe?) so the resulting assembly that's available (Microsoft hasn't released the secret sauce it's based on) isn't the easiest thing in the world to follow.
 
How feasible would it be to disassemble it into something that compiles?

It is compiled now :) So if you disassemble it, it should still compile - on the assembler which you used to disassemble it. What you'll lose are all the variables, symbols, offsets, etc. which the original programmers put there.

I have been wanting to disassemble and de-entangle the Cassette BASIC ROMs for a little while now.

I will report back with my progress.

Obviously it wouldn't be possible to get the original source code by this method, but my goal is to get an understanding of how they work.

I suspect that large portions of the ROM will match with what's in the GW-BASIC source. With enough time you could essentially cross-reference the ROM disassembly with those sources and produce a coherent listing of the ROM with proper symbols and labels and comments.

This might work, but for my purposes I wasn't planning on doing it. I could do a cursory check of the BIOS binary and the COM binary to see where if at all they are the same
 
This might work, but for my purposes I wasn't planning on doing it. I could do a cursory check of the BIOS binary and the COM binary to see where if at all they are the same
Would dumping them to text files as hex and using a regular text diff tool tell you anything useful?
 
Would dumping them to text files as hex and using a regular text diff tool tell you anything useful?

It's possible. It would be a little bit more involved though - since if a module is written into the ROM at like 6KB into the file and the same module is in the COM at 14KB then the diff wouldn't show them. That would take looking for substring matches, which is more computationally involved. It would give good insight though.

Someone who knows more about this might have another idea, also.
 
Would dumping them to text files as hex and using a regular text diff tool tell you anything useful?

My approach is to load up the disassembly and source in a side-by-side editor and then just add empty lines at various points in the disassembly to get it to roughly match up with the source lines. Then I'll start modifying the source so that it matches the disassembly exactly. Once I've matched up some subroutines, I get enough offsets of variables to start working on the layout of the data section. It's very tedious. Eventually most of the data offsets and subroutine starting labels will be lined up, and at that point there will be only a handful of differences between the original binary and the binary as assembled from the modified source -- a binary diff is then helpful to track down the final changes.

The MS-DOS sources for v2.11 are quite nice because (most of) Microsoft's edits use lowercase asm mnemonics while the original 86-DOS 1.x code used uppercase, and the order of the various subroutines wasn't modified very much at all.
 
Back
Top