• Please review our updated Terms and Rules here

NuXT 1.2, move 32K VGA ROM to either main flash chip or option ROM socket?

thisisamigaspeaking

thisisamigaspeaking

Experienced Member
Joined
Feb 13, 2024
Messages
107
If I needed to clear up C0000-C8000 (location of SVGA bios on a NuXT 1.2) might it work to just move the chip over to the option ROM socket (and set it to D0000)? How about flashing it into the 32k free space in the flash chip used for the system BIOS (located at F4000-FA000)? Will the XT-IDE BIOS be able to handle that? Thanks.
 
The VGA BIOS is almost always at C000. I think you will run into problems if you try to move it. What do you want to put at C000?
 
Plasma said:
The VGA BIOS is almost always at C000. I think you will run into problems if you try to move it. What do you want to put at C000?
Click to expand...

I don't think there's really any reason it *has* to be at C000. IBM PS/2s, for instance, had it up with the rest of the system BIOS, and I think there may have been the odd clone with integrated VGA that moved it. There are also memory managers that in addition to shadowing BIOS code offer the option of compacting it to free up UMB space. Now whether there might be something in any *specific* BIOS that freaks out if you move it, that's an interesting question, but in *theory* at least the VGA BIOS should be packaged up like a standard BIOS extension, and therefore relocatable.

That said.
thisisamigaspeaking said:
If I needed to clear up C0000-C8000 (location of SVGA bios on a NuXT 1.2) might it work to just move the chip over to the option ROM socket (and set it to D0000)?
Click to expand...

Without looking at the NuXT schematics I can't say if you're going to have a problem or not. The BIOS socket is going to have a chip enable signal generated somewhere; if that signal *only* goes to the ROM chip then, sure, you should be able to pull it out and move it. But if that ROM socket is behind a buffer that's going to be activated and driving the bus whether or not the ROM chip is present it's going to take more work to disable that decoding circuitry to allow you to free up the space.

thisisamigaspeaking said:
How about flashing it into the 32k free space in the flash chip used for the system BIOS (located at F4000-FA000)? Will the XT-IDE BIOS be able to handle that?
Click to expand...

It's usual for PC BIOSes to not scan for BIOS extensions located above the F4000 mark, but I'm not sure if that's inclusive or exclusive of F4000? It might be an interesting avenue to try.

FWIW, I've done something kind of similar to your idea here with a Tandy 1000HX; that machine has a huge 128K of ROM from E0000-FFFFF; only 16K of it is the actual BIOS, the rest of it is Personal Deskmate assets (to make it easier to run with a single floppy drive) and a stripped down 47.5K DOS 2.11 boot image. For that I noodled out a way to override the ROM select lines and the directional control of the onboard data buffer to let me free up all the space from E0000-F7FFF, and I relocated the flash ROM socket on my homebrew multi-expansion card to show up at F0000-F7FFF. (The E-page is now dedicated to EMS page frame space.) The XTIDE BIOS is perfectly happy running above the F0000 mark, and I also have a clock BIOS extension installed after that at F2000, so I know that generic BIOS extensions at least don't mind being shoved up that high.

Of course the reason I did this was so I could make room for a decent amount of UMB while having a VGA card present and occupying C0000-C7FFF; without these gymnastics the best I could do would be only 16K of UMB RAM with EMS, 80K without it. With a little more hacking I could in theory map 48K into the F-space and try putting a copy of the OAK VGA BIOS at F2800; if that worked I could in theory free up the entire C0000-EFFFF space, but so far I haven't really needed more than 96K of upper memory. I am curious if it would work...
 
Eudimorphodon said:
I don't think there's really any reason it *has* to be at C000. IBM PS/2s, for instance, had it up with the rest of the system BIOS, and I think there may have been the odd clone with integrated VGA that moved it. There are also memory managers that in addition to shadowing BIOS code offer the option of compacting it to free up UMB space. Now whether there might be something in any *specific* BIOS that freaks out if you move it, that's an interesting question, but in *theory* at least the VGA BIOS should be packaged up like a standard BIOS extension, and therefore relocatable.
Click to expand...
The standard BIOS procedure to scan for option ROMs is to start at C000 and scan upwards. If you put the VGA BIOS after other ROMs like XT-IDE, you will not be able to see what they are doing because video hasn't been initialized.

For systems with integrated video, the main BIOS is aware of where the integrated video BIOS resides and can call that first.

Secondly, as you mentioned, the video BIOS must be written without the assumption that it will be at C000. I wouldn't bet on this.

If the goal is to use both a VGA and PGC together, I would recommend a VGA with a 24K BIOS.
 
Plasma said:
The standard BIOS procedure to scan for option ROMs is to start at C000 and scan upwards. If you put the VGA BIOS after other ROMs like XT-IDE, you will not be able to see what they are doing because video hasn't been initialized
Click to expand...

… oh, yeah, that’s a good point I didn’t think of. That could cause all kinds of weird fallout.
 
Eudimorphodon said:
... what aspect of the xtide universal BIOS did you think was relevant here?
Click to expand...
Ah sorry, I guess it's Sergey Kiselev's 8088_BIOS? I misunderstood and thought the XT-IDE BIOS was a complete BIOS replacement. My point was we have the code for all of that presumably?
 
So far as I know Sergey's BIOS behaves like a standard PC BIOS, in that it "internally" has drivers for CGA and MDA. So I guess the question is... on a real IBM PC/XT you have those switch settings on the motherboard with which you set "CGA 40 column, CGA 80 column, MDA, or "EGA/VGA", IE, look for a BIOS extension. Does the fact that there's a specific switch setting for EGA/VGA imply that there special handling for primary video card extensions over regular BIOS extensions?

I mean, I genuinely don't know the answer to this one. Is it normal for EGA/VGA to be located at C000 because it's vital to ensure that its extension gets read before anything else to avoid bad behavior if a BIOS extension tries to write something to the screen before the VGA is initialized, IE, it's only the position that gets it first in line, or is there something else going on? What would the path be for the console writes of some other extension if it was read before the VGA BIOS? Would it blindly write to the CGA (or MDA) frambuffer area, cause an error beep, what?
 
Eudimorphodon said:
So I guess the question is... on a real IBM PC/XT you have those switch settings on the motherboard with which you set "CGA 40 column, CGA 80 column, MDA, or "EGA/VGA", IE, look for a BIOS extension. Does the fact that there's a specific switch setting for EGA/VGA imply that there special handling for primary video card extensions over regular BIOS extensions?
Click to expand...
In the case of the IBM PC (IBM 5150) and IBM XT (IBM 5160), the answer is no.

For the IBM XT, the relevant part of the power-on self test (POST) is step 21 at [here]. Other BIOS expansion ROM's are searched for at step 28.

In both cases, the POST does the same thing, which is:
If a BIOS expansion ROM found, verify that the 8-bit checksum of the ROM (size is in third byte) is 00. If verification passes, call the initialisation code in the ROM.

The only difference is that the BIOS expansion ROM on EGA/VGA gets executed first.
 
Plasma said:
The standard BIOS procedure to scan for option ROMs is to start at C000 and scan upwards. If you put the VGA BIOS after other ROMs like XT-IDE, you will not be able to see what they are doing because video hasn't been initialized.

For systems with integrated video, the main BIOS is aware of where the integrated video BIOS resides and can call that first.

Secondly, as you mentioned, the video BIOS must be written without the assumption that it will be at C000. I wouldn't bet on this.

If the goal is to use both a VGA and PGC together, I would recommend a VGA with a 24K BIOS.
Click to expand...
So for initializing the ROM first at some other location, I believe that can be solved since I have the .ASM for the BIOS being used.

For the VGA BIOS not being written with the assumption it is at C000: if it were written with that assumption, wouldn't it break or not be able to take full advantage of being shadowed?

Another issue is disabling the chip select on the existing BIOS chip, if that doesn't happen just by removing it.

Do you know offhand of some VGA cards with only 24K BIOS? I assume IBM's own 8-bit ISA card was meant to work with the PGC?

I'm not sure it is even that important to have a working VGA in the system, since the PGC's CGA emulation can be used. I thought it might be easier for debugging to have a definitely-working video output along side the PGC.
 
thisisamigaspeaking said:
Do you know offhand of some VGA cards with only 24K BIOS? I assume IBM's own 8-bit ISA card was meant to work with the PGC?
Click to expand...

I wouldn't necessarily consider it a safe bet that IBM's card got along with the PGC, considering the card was a contemporary of EGA, IE, obsolete when VGA came out... although I guess a BIOS for the "IBM PS/2 Display Adapter" is out there and seems to only be 24K long.

thisisamigaspeaking said:
I'm not sure it is even that important to have a working VGA in the system, since the PGC's CGA emulation can be used. I thought it might be easier for debugging to have a definitely-working video output along side the PGC.
Click to expand...

Maybe I'm looking at it the wrong way, but wouldn't it be simpler if you're testing an unknown PGC to just try to use it in a known working configuration (IE, by itself with CGA emulation enabled) before trying to do something fancy like mixing it with another card?
 
Eudimorphodon said:
Maybe I'm looking at it the wrong way, but wouldn't it be simpler if you're testing an unknown PGC to just try to use it in a known working configuration (IE, by itself with CGA emulation enabled) before trying to do something fancy like mixing it with another card?
Click to expand...
Indeed. I was just considering leaving the built-in VGA enabled on the NuXT since it's there, and disabling the CGA on the PGC, if it were simple to do.
 
The ET3000 has a 24K BIOS. There are probably other early VGAs as well.

Most motherboards with shadowing can do it "in place." Only very early implementations needed to move the code, which sometimes caused problems.

To be clear, I am not saying that this can't work. Just that there are likely to be issues encountered.
 
thisisamigaspeaking said:
Indeed. I was just considering leaving the built-in VGA enabled on the NuXT since it's there, and disabling the CGA on the PGC, if it were simple to do.
Click to expand...

Remember the PGC was a contemporary of EGA and obsolete when VGA came out, so, again, trying to get VGA and PGC to cooperate is definitely not *simplifying* matters.

Do you actually have this PGC card yet and have tried it out? There seems to be a mystery element here.
 
Eudimorphodon said:
Remember the PGC was a contemporary of EGA and obsolete when VGA came out, so, again, trying to get VGA and PGC to cooperate is definitely not *simplifying* matters.

Do you actually have this PGC card yet and have tried it out? There seems to be a mystery element here.
Click to expand...
The PGC just arrived today. I have not tried it. It looks to be in extremely good physical condition. I am waiting on the NuXT system to arrive so I can see if it will work in there, if not I will probably try an AT or AT clone next (don't want to dive that deep into the 8088 scene).

If I can at least see (or read) the onboard diagnostics for the PGC that would be helpful.
 
You must log in or register to reply here.
Back
Top