NTSC (TV scanrate) VGA in BIOS success

Only for programmers and BIOS gurus with technical questions.
Post Reply
bc
New visitors - please read the rules.
Posts: 10
Joined: Mon Jun 28, 2004 7:59 pm

I was successful in patching my Award 4.51pg bios to post in an NTSC video mode.

Many old mono monitors, TV's, small LCD's etc are fixed-scan at NTSC
clockrates and have different sync-pulse characteristics. Most, if not all,
VGA cards can drive at these rates, but there was never an "official IBM"
specification for such a VGA mode, likey due to marketing practices of the
time.

To do this, I took a DOS TSR driver and modified it for use in a BIOS
environment and made the appropriate call into it.

http://www.ccs.neu.edu/home/bchafy/ntscbios.zip

There's still bugs/issues (see below), but it's close.

Where/Howto Patch:
--------------------------
Disassemble original.tmp with your favorite disassembler.
Search for the string "Ally" and note the begining data block address.
For example, in at least two separate 4.51pg motherboard bios's of mine, the
disassembly looked like:
E000:383A 65 64 00 db 'ed', 0
E000:383D 2C 20 41 6E 20 45 db ', An Energy Star Ally', 0
E000:3843 6E 65 72 67 79 20

The start of this text data block is 383D.
Now, search for 383D (or whatever is is). If lucky, you should find code
similar to:

E000:1F96 BE 383D mov si,383Dh
E000:1F99 E8 3FB3 call sub_217 ; (5F4F)
E000:1F9C 5A pop dx

si is a register commonly used as a reference to some string data.
(ie es:si, ds:si, etc). Feeling lucky, I took a leap of faith and
replaced the call sub_217 to my driver and see what would happen.
(keeping a backup bios chip handy!).
On bootup it worked!! A few things were missing at
the top. No EPA procedure was executed and the first line of text (and the little
award logo was not displayed). The top line was blank but the second line
displayed the usual (C) Award Bios... All was well through the post and
and dos, etc booted fine.


Bugs/Caveats
-----------------------
There is one big caveat, however. For whatever reason, when I press DEL and
go into the CMOS Setup Utility, the mode switches back to normal VGA. Im
not sure of the cause as of yet (just got this working late yesterday).
It is possible the interrupt table was reset,
or a video mode was set external to int10, or just a bug in the driver.
However, after exiting the CMOS config, POST starts in the NTSC mode as
usual.
If andybody knows where the CMOS Setup Utility entry points are (or what to
search for), let me know.


About the driver:
------------------------
This is a VGA->NTSC video driver for use in a BIOS.
It is based on Tomi Engdal's vga2ntsc.com video driver.
Much of the original code had to be rewritten to work within the limitations
of a bios:
Works with complete position independence. Internal address references are now
offsets instead of absolute.
Read-only data environment. The original driver used to write data to the local
data segment.
Removed all DOS/DOS-services references and replaced with low-level eqivalents.

Adding the driver to original.tmp
------------------------
Find an empty place in your original.tmp, and paste in the driver wherever
there is enough free space.
The entry point to the driver is at whatever the starting address is.
For example I pasted the driver in my original.tmp starting at address
E000:D700. A "call D700" initializes it.

More info
------------------------
It runs a VGA card at NTSC-equivalent scanrates.
This makes the output of a VGA card suitable for use in a TV or other
NTSC-clocked display (for example a small 6" lcd or old mono monitor).
The driver is an ISR for INT 10.
Upon execution, the orignal INT 10 pointer is moved to INT E2. There's nothing
special about INT E2, any other free interrupt could have been used.

Tomi Engdal's original DOS driver:
http://www.hut.fi/Misc/Electronics/circ ... a2tv06.zip

Other links, (hardware, etc):
http://www.hut.fi/Misc/Electronics/circ ... index.html
http://home1.gte.net/bs/sharp2.html
maman
Master Flasher
Posts: 173
Joined: Sun Mar 31, 2002 2:08 pm
Location: Taka Bonerate National Park, Indonesia
Contact:

as what I can understand from my previous Bios reverse engineering experience, the video initialization routine is "embedded" in the EPA procedure. Read here to see my previous work. Near the end of the article I replaced the EPA procedure completely and have to do the video card initialization my self, of course it uses int 10h, perhaps you can change it with your own :D. Btw, AFAIK, the interrupt handler itself is around the "bootblock" area (F000:E000 - F000:FFFF), this is not the real bootblock, but its the "bootblock" that you get when original.tmp get decompressed in RAM. There are another interrupt handlers but they are in the real bootblock area (after the compressed original.tmp), to serve when original.tmp corrupted and bootblock error handling code is in effect.
bc
New visitors - please read the rules.
Posts: 10
Joined: Mon Jun 28, 2004 7:59 pm

Sorry, when I said "EPA Procedure", I was moreless referring to the code that
draws the EPA logo on the screen. I may very well have made a modification to
the EPA procedure itself (ie a method within).
For me, however, this is desirable. Since I want the video bios to
initialize and insert its int10 poitner entry (by whatever mechanism it does).
The driver needs a valid int10 entry to chain to.
The point where the bios starts to draw text on the screen seemed like a
safe place to do a call out.
My next attempt will be to re-add the "call sub_217" at the end of the
driver and see what EPA-logo effects there are.

I could have tried this whole thing inside of a video bios, but bad as
debugging the award bios is, every video bios is different.
Ultimately, linuxbios or openbios would be the best option, but there
are many barriers from chipset vendors.

The problem with the CMOS Configuration Utility appears to be a bug
in the original driver. When an int10 is issued with the high order bit of
al set (ax=0083h instead of 0003h ie to prevent a clearscreen), the driver
does not trap the command and sends it directly to the video bios. The video
mode is then reset. Issuing an int10 with 0 as the high order bit of
al (0003) sets the video mode back to "normal" again. Fortunately, this is
an easy fix.

I read your page recently. However I was unable to find
808EE10110F6461430h or "AWBM" in my bios's. this might be because my test
systems are fairly old socket-7 boards picked out of the trash. Also, on
a FIC VT-502, modbin cannot deal with the checksum at all and refuses to open
the file (even the original backup). But that bios required Flash531 instead
of Awdflash (which also compained about checksums). Awdbedit disected the
file fine however. All my test bios's so far have claimed to be 4.51pg.

When disassembling original.tmp, I first got all the ISR entry points from
IVT.EXE (http://www.xs4all.nl/~matrix/programs_source.html).
I booted into DOS and included anything from segment E000 or F000,
For example:

F000:FFF0 01 main_entry_point
F000:E2C3 02 nmi_isr_cpu_entry
F000:E7D0 04 NULL_misc_isr_entry
F000:FF54 05 print_screen_isr_soft_entry
F000:F84D 11 equipconfig_isr_soft_entry
F000:F841 12 memsize_isr_soft_entry
F000:E739 14 serialservices_isr_soft_entry
F000:E82E 16 keybdserivices_isr_soft_entry
F000:EFD2 17 parallelservices_isr_soft_entry
F000:E7A4 18 rombasic-bootfailure_isr_soft_entry
F000:E6F2 19 bootstraploader_isr_soft_entry
F000:FE6E 1a timeofdayservices_isr_soft_entry
F000:FF53 1c usertimetick_isr_soft_entry
F000:F0A4 1d videoinitdataptr_isr_soft_entry
F000:EC59 40 revectoredFDservices_isr_soft_entry
F000:EFD5 41 HDD0paramtable_isr_soft_entry
F000:F065 42 EGAdefviddriver_isr_soft_entry
F000:EF6D F3 UnknownBios_F3_isr_soft_entry

Something that has been elusive to me about original.tmp and other
modules is the ability to write to local data segments. Traditionally,
a bios is read-only code, as it is stored on eprom. However since the
award bios is composed of compressed images, and those are decompressed
somewhere in RAM and executed, that also implies that any local data-segments
(that is, data living within the same segment as the code) in original.tmp are
writable. But I've also read that the memory is later write locked somehow
after the bios completes. And then there's the elusive "extended bios
data area". Can anybody clear this up?
maman
Master Flasher
Posts: 173
Joined: Sun Mar 31, 2002 2:08 pm
Location: Taka Bonerate National Park, Indonesia
Contact:

These are what I know: From what I've seen in the result of my disassembly on award 4.51PG, award bios components are decompressed by the decompression block which is located around F000:7000h in the ROM image. Before decompressed, the code itself (i.e. the highest 128KB / E000:0000-F000:FFFF bios code in ROM) get copied to RAM at 1000:0000-2000:FFFF by the bootblock, and then jumped into by the bootblock code. From that point, everything are readable and writeable. Then, the "low address" extended BIOS data in ROM such as awardext.rom, acpitbl.bin, etc. which is mapped into C000:0000h- D000:FFFFh (supposedly by the chipset) for a 256KB bios like mine, are copied into RAM beginning at 8000:0000h. Later on, the 128KB that contains original.tmp get decompressed by the code I mentioned above (decompression block that is now at 2000:7000) into 5000:0000-6000:FFFF (if decompression successfull), or remains in 1000:0000h-2000:FFFFh (if decompression failed) in RAM. During the decompression routine execution, the "extended " bios code i.e. awardext.rom, etc. also get decompressed into it's respective area in RAM, depending on their "address signature" (which supposedly you can see from CBROM). Then, the shadowing are first enabled for memory region E000:0000-F000:FFFF in the chipset so that this area are left readable and writeable. Then the decompressed code in 5000:0-6000:FFFF is shadowed/copied into E000:0-F000:FFFF. After the shadowing done, the code jump from segment 2000h into F000h segment at F80Dh. After this, I haven't know yet the details, but generally the readable and writeable properties of E000h and F000h segment are switched back and forth (writeable, readable, R/W-able) by the code as needed. Note that the POST (power on self test) code is called using a "jump table", and if it's successfull, the call will never return. I don't know for sure, but it seems that the last code executed is a bootstrap (int 19h), and this is very logical :D. As for the interrupt service routine, it's located in the F000h segment, it's part of decompressed original.tmp. Also, the Interrupt vectors are re-initiliazed by one of the POST code. That's all I know, this might not be too comprehensive, but at least that's the big picture.
bc
New visitors - please read the rules.
Posts: 10
Joined: Mon Jun 28, 2004 7:59 pm

8O how simple.

Acutally, it does clear up some things.
It looks like nothing really prevents writing to local data segments
so long as the memory is not explicitly locked.

But then what is the techique to locking memory (making it read-only)?
Is this a chipset-specific thing? Are there well known flags/attributes
to get/set this?
bc
New visitors - please read the rules.
Posts: 10
Joined: Mon Jun 28, 2004 7:59 pm

:P woohoo :P
After some bugfixing to the driver, it now works as expected.
The energy* logo now appears as well. The problems I had were due to
the driver forcing mode 03 and clearing the screen on initialization.
Also, mode's 8x were not properly trapped and caused the cmos config screen to jump into vga mode.

The only bad thing (and its not really a big deal) is the text fonts are
ugly in graphics mode. But they're still readable.

I have yet to try a fullscreen bitmap on bootup, that will come later.
Also, as far as i can tell, re-adding the "call sub_217" only
affects whether ", an energy star ally" is drawn. So it could be left out.
I put the updated driver in:
http://www.ccs.neu.edu/home/bchafy/ntscbios.zip
maman
Master Flasher
Posts: 173
Joined: Sun Mar 31, 2002 2:08 pm
Location: Taka Bonerate National Park, Indonesia
Contact:

bc wrote:But then what is the techique to locking memory (making it read-only)?
Is this a chipset-specific thing? Are there well known flags/attributes
to get/set this?
yes, it's chipset feature. It's pretty easy to accomplish. You'll have to see the chipset datasheet and set the appropriate register (that controls the DRAM shadowing, which is possibly located in the Hostbridge) , into appropriate values for the RO, WO, R/W property of some ranges of memory, it depends on the chipset, but in the majority it will be from C 0000h - F FFFFh.
Post Reply