If you ever wondered about BIOS extensions..

[AndersNielsen]

…I just published a video going over the details of running code pre boot on a machine with 0 drives and just a grumpy old 10base2 card.

Let's make Pong for the IBM PC/XT - without booting it!

Your feedback much appreciated!

 

[GiGaBiTe]

You have your video set to disallow embedding, so your embedded video doesn't work.

 

[hard_fault]

Dig it! This is the good stuff.

Learned something: Never knew about that checksum part. It is strange that some edits I made to Sergey's Floppy Bios and burned onto ROM actually worked (a few extra lines of instruction at the entry to disable Tandy 1000 SL/TL onboard FDC), but I never knew about recalculating the checksum; never did that part. Yet it works... Time to revisit that.

Probably going to fool around just like you're doing at some point, your videos will certainly help me get there faster . Planned on using USB logic analyzers to assist... since from experience with other similar scenarios, I wouldn't want to try very much without one. They're pretty slick these days, shouldn't be a problem capturing at XT/XT Turbo speeds.

Thanks for the video, anticipating the next one.

 

[modem7]

Learned something: Never knew about that checksum part.

Mentioned in the bold text of [here].

It is strange that some edits I made to Sergey's Floppy Bios and burned onto ROM actually worked (a few extra lines of instruction at the entry to disable Tandy 1000 SL/TL onboard FDC), but I never knew about recalculating the checksum; never did that part. Yet it works... Time to revisit that.

8-bit checksums are subject hashing collisions.
For example, both of the following 5-byte blocks have an 8-bit checksum of 00.
5F B0 94 00 5D --> 16-bit checksum = 0200 --> 8-bit checksum = 00
5F B0 94 88 D5 --> 16-bit checksum = 0300 --> 8-bit checksum = 00

If it was only one edit that you did, that edit may have (luckily) resulted in an 8-bit checksum of 00. But you wrote "some edits". Could it be that the BIOS in the Tandy 1000 SL/TL doesn't do a check of the checksum !

 

[hard_fault]

Mentioned in the bold text of [here].


8-bit checksums are subject hashing collisions.
For example, both of the following 5-byte blocks have an 8-bit checksum of 00.
5F B0 94 00 5D --> 16-bit checksum = 0200 --> 8-bit checksum = 00
5F B0 94 88 D5 --> 16-bit checksum = 0300 --> 8-bit checksum = 00

If it was only one edit that you did, that edit may have (luckily) resulted in an 8-bit checksum of 00. But you wrote "some edits". Could it be that the BIOS in the Tandy 1000 SL/TL doesn't do a check of the checksum !

Thanks for that info.

The final cut of the edits I made to the Sergey FDC BIOS ended up being just 2 instructions:
mov al,94h ; Tandy 1000 SL/TL planar FDC, HDD, PPT "off"
out 65h,al

However there were some 4 or 5 instruction iterations I went through before settling on just these two instructions.
First I tried detecting whether or not planar video (TGA) was enabled (among the other bits), and keep enabled bits enabled or keep it disabled bits disabled. Found out that the TL lies; it always returns same value for video enable bit, no matter the actual state. But not the honest SL... the SL returned the correct video enable state. So this idea was scrapped.

Going back to that project folder, I found that Sergey did include with the FDC bios code a binary called "fix_checksum," and it's source "fix_checksum.c." I'm sure he intended for me to actually use it .

If it turns out that this checksum thing can fail on certain systems for whatever reason, I might include my favorite CRC-16 self check in whatever BIOS ROM project I find myself doing in the future.

 

[AndersNielsen]

Thanks for the kind feedback!

@hard_fault If you used Sergey’s makefile that did the fix_checksum for you

@GiGaBiTe Didn’t intend to embed but this forum does so automatically when parsing YouTube links.

Started work on the next one but teaching assembly code is a bit harder for me than basic hw debugging explanations - hopefully it turns out ok

 

[hard_fault]

If you used Sergey’s makefile that did the fix_checksum for you

Makes sense. That's probably what I did.

Started work on the next one but teaching assembly code is a bit harder for me than basic hw debugging explanations - hopefully it turns out ok

Especially x86 assembly... takes one of average intelligence such as myself awhile to wrap my head around how the memory segmentation works. Anyway, I'm sure it's going to be awesome. Your audience probably has at least some knowledge of assembly already, or an interest in learning it... you could always defer more advanced concepts to links to videos or pages in the description for further explanation.

Thanks again.

 

[AndersNielsen]

Makes sense. That's probably what I did.


Especially x86 assembly... takes one of average intelligence such as myself awhile to wrap my head around how the memory segmentation works. Anyway, I'm sure it's going to be awesome. Your audience probably has at least some knowledge of assembly already, or an interest in learning it... you could always defer more advanced concepts to links to videos or pages in the description for further explanation.

Thanks again.

With the previous videos it was easier to "show and tell" because the interesting part is at least partly some physical gadget that I can show on camera. It'll take some effort to make an hour of coding watchable and understood at the same time.

Funny you should mention the memory segmentation - I'll probably be making some graphics to make that a bit easier to grasp, since it's one of those things that'll prevent the code from making any sense if you don't.