286 Compatible BIOS for Diamond SpeedStar64 (Cirrus Logic CL-GD5434)

[sqpat]

The most advanced (fastest?) tier of ISA VGA cards (Cirrus CL-GD5434, S3 928, ATI Mach64) all have 386 instructions in their BIOS and do not run on a 286, which is unfortunate. All prior cirrus cards worked fine on a 286 so I assumed that was the best bet to investigate a 286 compatible bios hack.

The BIOS didn't actually need a lot of work. There was a half dozen spots or so where 32 bit registers were used to attempt to interact with the pci bus. It was easy to just patch these with returning the carry flag or jumping past (the default behavior when the card is not found on the PCI bus). Perhaps the same BIOS was used for the PCI version of the card.

Then there was one spot where dword string instructions were used for scanning and testing video memory at startup. This was patched pretty lazily, but the end result worked. I tested on 86box and then on my card on real hardware and both worked, and the performance on real hardware shows a 3-4% performance bump on heavy vga benchmarks in general compared to a CL-GD5429 which is another very fast card.

Some other people have said the card does not work for them, so I am kind of curious about collecting some data points and seeing if I can produce a working version for everyone.

I think the CL-GD5434 has some pretty advanced 2d acceleration/windowing features. I also know some people have been creating and modifying windows drivers relatively recently. I'm not so familiar with that realm but am in general kind of curious as to how many hardware drivers out there might work for this card. I might enjoy contributing to windows drivers for the card.

The BIOS can be found here

 

[sqpat]

Today I had access to my hardware again, I tested a whole bunch of my 286 motherboards, after being told by many people the bios/card did not work for them.

Does Work:

C&T SCAT:
JCS Router Board
VLSI SCAMP:
Biostar mb-1220
PC-Chips m218
Citygate TD-90:
Zida TD60c

Does not work:

TACT82000:
Delta 065-3.3-0789
UMC UM82C230 (286 MORTAR):
CDTek 286 (UMC '230)
Headland HT-12
Unicorn ENDAT-286xx REV. 4A
DFI 286-12/16E
Octek (HT12 286)
Headland HT-18: ( NOTABLE: 386sx headland ht-18 works)
Lucky Star CM286
Protech PM286
Headland HT-21:
PC Chips M216
Suntac ST62C00x:
JS-168A
Citygate TD-60:
HEDAKA HED-988/PCChips M205
CHIPS NEAT:
Jaton Jam-Super AT-V5
ACT A27C001: (might be rebadged td60 now that i look at it)
CDTek Super 286

Thoughts:

Based on post codes on various systems, it seems the Video BIOS returns ok, but then in some cases the System BIOS fails it's own test of video memory for some reason. AMIBIOS in particular, on multiple chipsets often failed after post code 1A (Returned from video ROM) and beeped 2 long 8 short (i think), without showing code 1B (Display memory read/write test OK) and several other video codes. And then went straight to post code 30 which has to do with virtual memory checks.

This brings me to a thought: why is it the System BIOS's business to test video memory?? Isn't that the video BIOS's job?

I don't know, maybe there was a brief period in time where system bios tested video memory assuming knowledge of VGA, then something changed in video card hardware breaking old BIOS and stopping them for working. I will note the 5434 has only MEMR and MEMW connected while other VGA cards only seem to have SMEMR and SMEMW wired up. Supposedly has to do with VESA 2.0 and the 15-16 mb hole? Maybe for some reason BIOS memory accesses to video memory is not asserting these lines... not sure, just putting this info all out there in case this makes sense to someone. I don't know if the question to answer is "why does the test run" or "why does the test fail".

Further testing notes:

- Can confirm the same bios works on Kelvin64 and STB Nitro as well as Diamond Speedstar.
- Performance seems hampered by having only 2 slots of ram filled
- Speedstar 64 seems to have EDO memory versions of the card while all my STB Nitro and my single Kelvin 64 are FPM only
On my VLSI scamp (286) i can run the bus clock significantly faster than the CPU clock which always allows for silly experiments.

- These monsters POST with ISA bus clocks north of 50 MhZ obliterating my previous bests (ATI Mach 32 at 43 mhz).
- I had one card work successfully as high as ~61.50 MhZ
- They post fine beyond this but have render artifacts.
- Unconvinced ram speed is the limiting issue on overclocking performance, so I don't think shoving 25-30ns edo is going to make them faster.

 

[Plasma]

This brings me to a thought: why is it the System BIOS's business to test video memory?? Isn't that the video BIOS's job?

Yes, the system BIOS should only be testing video memory if configured for MDA or CGA.

On a 286+ where you have a CMOS setup instead of hard switches, the BIOS may switch video configs by itself to try to avoid a bad state where the user can't see anything to change the config manually.

So I suspect whatever the BIOS is doing to check for EGA/VGA installed is failing, and it's switching back to CGA or MDA.

 

[sqpat]

On a side note, I tried the mono/color jumper on a couple boards just in case that toggled some of the video testing behavior but it didn't help anything.

I spoke with 640KB (of GLaBIOS fame) a bit and it seems it should be the VGA BIOS's job to enable the display via INT 10h,AH=0 and maybe some screen mode set. It feels like this part is not happening for the problematic boards. In theory, if the VGA BIOS was called, even if this failed memory check happened there should already be the diamond speedstar banner on the top of the screen, I think?

I might try some different system BIOS versions out, especially MR BIOS if i can find it for some of these boards. Otherwise i might compare the speedstar 64 bios with the speedstar 24 (542x based cards) and see if theres something different the enabling of the video.

 

[Plasma]

On a side note, I tried the mono/color jumper on a couple boards just in case that toggled some of the video testing behavior but it didn't help anything.

Both MDA and CGA memory tests will likely fail on an uninitialized VGA.

I spoke with 640KB (of GLaBIOS fame) a bit and it seems it should be the VGA BIOS's job to enable the display via INT 10h,AH=0 and maybe some screen mode set. It feels like this part is not happening for the problematic boards. In theory, if the VGA BIOS was called, even if this failed memory check happened there should already be the diamond speedstar banner on the top of the screen, I think?

The VGA BIOS initializes the display when the VGA option ROM is invoked by the system BIOS, during the scan for option ROMs in C000-EFFF. Depending on the VGA BIOS, you may or may not see a banner. Later on, the system BIOS calls int 10 to set the startup video mode.

If the VGA option ROM is invoked but failing some self test (memory or otherwise) during initialization, it may not even attempt to display a banner or hook int 10. In this case, the system BIOS will assume there is no EGA/VGA and may revert to CGA/MDA video testing (which will also fail).

If you have an MDA/Hercules and mono monitor, you can run it together with your VGA. Set the primary display to mono and it should boot. There should be a blinking cursor on the VGA screen if it's initialized, and mode mono/co80 should switch between displays if int 10 is hooked by the VGA BIOS. If the VGA is not initializing, check to make sure you can read the entire VGA BIOS at C000 and that the signature and checksum are correct.

 

[sqpat]

Out of curiousity i tried out some MR BIOS ROMS.

On VLSI SCAMP (which worked with 5434 card) - MR BIOS for generic 286 machines successfully got video out
On Headland HT-12 (which did not work with 5434 card) - MR BIOS still did not work with the 5434.

I am soldering together some 5434 cards right now, once i have one put together and working i might be more motivated to try some experiments on the pins to see what happens (i do not think merely soldering wires to bridge them will work... right?).

Thinking about it, here are things I think might explain the current behavior

- The nonworking boards are not able to access the C000 vbios code on the vga card for one reason or another. This would obviously lead to vbios not running or failing. I could write a boot rom with some code which checks for some bytes in there then writes to a post card. Or i could dupe the vbios ROM and put it on another 8 bit rom card listening on C000, but i have a feeling this wouldnt fix all the issues.
- The machine is not sending memw/memr signals to the card. Not sure why this would happen though. Maybe 16 bit accesses are broken up into two 8 bit accesses with SMEMW/SMEMR rather than MEMW/MEMR assertion?


EDIT: The datasheet ( https://dosdays.co.uk/media/cirrus_logic/GD543x_DataSheet.pdf ) and the MEMR/EROM pins seem to have some mention of the mechanics of what is going on.

 

[sqpat]

Progress:

Tried CGA/MDA boot on HT-12 machine with the card installed (both worked)
- Nothing present at c000:0000 according to debug (all FF). Shadowing video bios did not change this

Set up NIC to have 32k bootrom at c000
- failed video init with bootrom in NIC
- successful video init (!) with bootrom in both NIC and Video card. Shadowing video bios did not change this. You still get one long, 3 short beeps indicating video failure despite this.

I noticed on this particular motherboard, POST continues whether the video initialized or not (you could hear the memory test speaker clicks). Maybe not every bios works this way. I think there is some moment where the video card's ROM becomes visible by the machine.

I did not do super thorough testing but did some graphical demos and the performance seemed great. I don't know if LFB would work in this situation, but I'm not sure how to test anyway.

By the way, the online 5434 repo's design seems to use the 8-bit SMEMW/pins SMEMR which suggests it should work fine with all these 286 machines, but also that LFB is probably not supported.

 

[sqpat]

Following up with a few more tests:


TACT82000:
Delta 065-3.3-0789 - Worked
Headland HT-12
DFI 286-12/16E - Worked
Headland HT-18:
Lucky Star CM286 - Worked
ACT A27C001:
CDTek Super 286 - Worked
UMC UM82C230 (286 MORTAR):
CDTek 286 (UMC '230) - Did NOT work

So this solution does work on most of boards (4/5) that did not work before. I have a feeling that this is somehow fixable in BIOS with the two-card solution.

 

[rodney]

Maybe 16 bit accesses are broken up into two 8 bit accesses with SMEMW/SMEMR rather than MEMW/MEMR assertion?

Sorry to respond a little late to your post but I can clarify the matter of SMEMW/SMEMR compared to MEMW/MEMR.

/SMEMW and /SMEMR are gated with "below 1MB" address decodes.
That means that any access below 1MB specifically will only activate the /SMEMW and /SMEMR.
If the address is a location above the 1MB region, this is decoded by the PC/AT system and the commands /SMEMW and /SMEMR will remain quiet.

Only /MEMR and /MEMW are always active in the entire memory map of the CPU with memory or DMA commands, at any given address.

So how does this translate with relevance to the memory decoders in VGA cards?

Simply put, if a VGA card does not use the LA17-LA23 lines, it contains a simpler memory decoder.
And in that case this is combined with using /SMEMR and /SMEMW so the card does not(need to) look at higher address lines above A19.
So the /SMEMW or /SMEMR commands are not triggered in above 1MB address range so the "simplified" VGA controller does not respond to any mirrors in the memory map with the same A0-A19 states.
I would say that this mechanism is typically a more simple type of VGA card. Some VGA cards use jumpers to select using LA17-LA23, or not use these. In a PC/AT system, one should always enable using LA17-LA23, on the chance that faster VGA cycles by the CPU would then become possible, hopefully.

Also in a PC/AT card or memory decoder design for simple 8 bit access, we could for example use less address lines up to A19, and combine the decode to activate commands with the /SMEMW and /SMEMR lines.
This can save some address connections and decoding logic for certain designs.
Using SA0-SA19 also stems from the 8 bit card era and is a backward compatibility thing as well for 8 bit cards using memory commands.

Generally, the faster VGA cards will always use the LA17-LA23 address lines, I expect.
Why do they do this? Because LA17-LA23 come directly from the CPU itself during CPU memory command cycles, so these follow the pipelined address timing, enabling earlier decodes and more address setup time available for the VGA controller. The VGA controller acts as a memory controller to provide access to VGA RAM behind the controller chip to the CPU.

So the VGA controller is in charge when it can permit the CPU to access its critical timing driven VGA RAM.
When a VGA cycle from the CPU interferes with the VGA controller video and other related tasks, the VGA controller will use IOCH_RDY to create wait states until it is ready to transfer the CPU VGA RAM cycle.

So we could assume here that advanced newer VGA cards like a newer Cirrus Logic use LA17-LA23 to decode VGA RAM window location address and VGA BIOS ROM address cycles by the CPU.
By using LA17-LA23 this enables early address decodes allowing for longer address setup times with more advanced VGA controllers who are able to pull this off, and typically this will combine with /MEMW and /MEMR as the memory commands. It's much like using zero wait state timing on the main system RAM which requires more advanced mechanisms which are fully aware of the CPU and system timing.
It would make sense to do so, though arguably it would also be possible to only decode LA17-LA19 and combine with /SMEMR and /SMEMW, if the designer was inclined to do so for some reason like maybe limited pins on a chip package etc.. Just generally if enough pins are available it would make much more sense to do the more elaborate design and facilitate the fastest VGA cycles, which is the actual goal of the design of course with these fastest ISA slot VGA designs.

I can also add as a general info that I have observed with Cirrus Logic VGA cards, the timing of LA17-LA23 absolutely needs to match the direct CPU assertion timing, or the card will start to exhibit VGA artifacts, missing characters on the first text column, and entire text lines being corrupted, etc. These cards operate on the edge of timing and any delay will result in screen errors. Though arguably this is most relevant to new PC/AT system designs to observe this point carefully.

Kind regards,

Rodney

 

[rodney]

By the way, the online 5434 repo's design seems to use the 8-bit SMEMW/pins SMEMR

In any case, I would not do this unless the controller chip is only able to see address lines up to LA19 or SA19, see my explanation.

I should study these designs to see what's going on there with this command choice on the slot.
If a VGA controller connects with all LA17-LA23 pins, it would not make sense to wire it up to /SMEMW and /SMEMR, in my opinion.
I am not trying to bash these designs and I am grateful for these to exist, and respect the amount of work to make these, I am only stating what would make sense to me personally.
Of course, they may decode certain things internally in the VGA controller to require doing it that way, however I would still want to test with /MEMR and /MEMW in a new design if the LA17-LA23 are actually used in the VGA controller chip.

Kind regards,

Rodney

 

[sqpat]

Hi Rodney, thanks for your reply. I was going to ask you eventually about how you handle this on REV3E especially because I was curious about it.

/SMEMW and /SMEMR are gated with "below 1MB" address decodes.
That means that any access below 1MB specifically will only activate the /SMEMW and /SMEMR.
If the address is a location above the 1MB region, this is decoded by the PC/AT system and the commands /SMEMW and /SMEMR will remain quiet.

Only /MEMR and /MEMW are always active in the entire memory map of the CPU with memory or DMA commands, at any given address.

OK - yes, this was all my understanding too.

I would say that this mechanism is typically a more simple type of VGA card. Some VGA cards use jumpers to select using LA17-LA23, or not use these. In a PC/AT system, one should always enable using LA17-LA23, on the chance that faster VGA cycles by the CPU would then become possible, hopefully.

Interesting, is this how the "0WS" jumpers work? It makes sense because you would need to use LA17-LA19 in conjunction with MEMCS16. But then since the address is still <1MB you could use SMEMR/SMEMW.

Also in a PC/AT card or memory decoder design for simple 8 bit access, we could for example use less address lines up to A19, and combine the decode to activate commands with the /SMEMW and /SMEMR lines.
This can save some address connections and decoding logic for certain designs.
Using SA0-SA19 also stems from the 8 bit card era and is a backward compatibility thing as well for 8 bit cards using memory commands.

Right, this all makes perfect sense.

Generally, the faster VGA cards will always use the LA17-LA23 address lines, I expect.

Why do they do this? Because LA17-LA23 come directly from the CPU itself during CPU memory command cycles, so these follow the pipelined address timing, enabling earlier decodes and more address setup time available for the VGA controller. The VGA controller acts as a memory controller to provide access to VGA RAM behind the controller chip to the CPU.

Usually VGA is accesses via A000-BFFF but there is another feature called "linear frame buffer" (LFB) that appeared late in ISA's lifetime. This is one of the few ISA cards supporting the feature. Basically, VGA memory can be mapped in a high memory address like the 3MB-4MB range, or 15-16 MB range, so that processors can access it all in one big range of memory without having to paginate it via VGA registers. I think this was probably more common on VLB, PCI, etc and on 386/486 class machines. Because of this the higher address pins (LA20 and LA21 in this case) are actually in use, and of course MEMW/MEMR must be present.

One thing I want to note is that it seems MEMW/MEMR pins are not present in earlier 0WS cards (like the cirrus I sent you for example). They still use SMEMW/SMEMR because they are exclusively used with A000-BFFF mapped video memory. So its just these few cards with LFB support which have MEMW/MEMR present.

In any case, I would not do this unless the controller chip is only able to see address lines up to LA19 or SA19, see my explanation.

I should study these designs to see what's going on there with this command choice on the slot.
If a VGA controller connects with all LA17-LA23 pins, it would not make sense to wire it up to /SMEMW and /SMEMR, in my opinion.
I am not trying to bash these designs and I am grateful for these to exist, and respect the amount of work to make these, I am only stating what would make sense to me personally.
Of course, they may decode certain things internally in the VGA controller to require doing it that way, however I would still want to test with /MEMR and /MEMW in a new design if the LA17-LA23 are actually used in the VGA controller chip.

So, the problem was that it seemed like the VBIOS in the commercial cards with MEMW/MEMR was 'invisible' to most 286 systems except very late chipsets (SCAT, SCAMP, perhaps TOPCAT). So the card simply did not initialize and VGA bios didn't run. I could confirm with a monochrome card in ms-dos that the vbios was not visible at C000 hence using a second card with a BIOS copy at C000 to get around this. I have no idea about why this happens on some chipsets and not others. I wondered if older 286 systems perhaps did not assert MEMR for 8 bit reads from the video card BIOS. I was curious about how Rev3E works here.

Well, I will finish building the card in 2 or 3 days once the rest of my parts arrive, then I will know for sure if this design with SMEMR "fixes" the issue on older 286 systems.

The 5434 datasheet describes some options about these pins. The 5434 chip has its own MEMW/MEMR pins and there is another pin called EROM (enable ROM buffers) which has some notes about tying to SMEMR or MEMR on the isa bus and how to support it in either case.

From the datasheet:

MEMR: This active-low input is used to indicate that a memory read is occurring. If linear addressing is being used, this pin must be connected to ISA signal MEMR*. If linear addressing is not being used, this pin can be connected to ISA signal SMEMR*. TheCL-GD5434 decodes LA[23:17] and SA[16:15] to determine if a display memory read is occurring. If so, data is placed on the System Data pins according to the Read mode and the contents of display memory. TheCL-GD5434 decodes LA[23:17] and SA[16:15] to determine if a BIOS read is occurring. If so, the CL-GD5434 makes EROM* active for the duration of MEMR*.

ENABLE ROM BUFFERS*: This active-low output is used to control the Output Enable pins of up to two 8-bit bus drivers. These buffers are used to connect the data pins of the BIOS EPROMs to the System Data bus. This output is forced high when RESET is active. This output goes active only for memory read cycles to the Address Range C000:0through C7FF:F. This output is gated with MEMR* in ISA mode, and is un-latched Local Bus Address decode in local bus modes. For local bus only, this signal is active for I/O Addresses 3C6-3C9 when CF[12] = 0.

It does sound like the designers of the chip had either case in mind. All commercial designs used the MEMR/MEMW pins, and didn't claim 286 support. So when I backported the BIOS to support 286 CPUs i finally hit this odd behavior.

If there really is a design flaw in older 286 motherboards, or if its an issue with the commercial card designs I'm not sure. But to be fair they didnt claim 286 support. Nonetheless I'm not sure why every 386 board runs fine with the card. If its an incompatibility with the older hardware with the MEMR/MEMW design then in an ideal world a design might have a jumper to toggle whether the 8 bit or 16 bit pins are used. While LFB sounds cool, I'm not sure any 286 software or drivers exist to support it. I think you would have to do it in protected mode, which is rare to see software supporting for 286 to begin with. At the same time, a modern recreation shouldn't drop the advanced features present for later cards I think.

 

[rodney]

I was going to ask you eventually about how you handle this on REV3E especially because I was curious about it.

Right, and I normally handle this type of thing in the same way as the 5170 since it set the standard.
Keeping with that design seems to me the safest choice for the sake of compatibility.

Interesting, is this how the "0WS" jumpers work? It makes sense because you would need to use LA17-LA19 in conjunction with MEMCS16. But then since the address is still <1MB you could use SMEMR/SMEMW.

Right. The 0WS jumpers in addition change how the VGA controller internally handles the VGA RAM cycles from the CPU.
So it may change the timing of how the cycles are being terminated, so that would mean to do the data transfers on the first command cycle after the status cycle.
The VGA controller will then assume that the transfers will always want to occur right after the status cycle.
Of course, it can still assert IOCH_RDY whenever this is not possible due to other VGA RAM access internally for the display system on the card.
Absolutely if below 1MB the /SMEMR and /SMEMW could be used.
/MEMCS16 is used here by the VGA controller to set the bit width of the memory access cycles to be the faster 16 bit type of transfer.
The 0ws jumper is not necessarily a means to get faster VGA access. In my tests with the SCAT system I found the normal VGA transfers just as fast as with the 0ws jumper enabled.
Same with the REV3E, I have done experiments with 0ws however this never yielded faster cycles.
If a card is truly capable of 0ws operation, then that will make a bigger difference of course.
The card would then be as fast or faster than the internal system RAM of the particular system, if the 0ws operation is possible.
This situation would yield a super fast VGA operation, about as fast as we can hope for with a PC/AT type system.

there is another feature called "linear frame buffer" (LFB)

Okay, cool, nice to know. I imagined such a mode would also become possible as long as software operating in protected mode is used.
It seems this should be treated as very optional and require the software in question to be aware of this so it can handle the transfers through this alternate window.
This reminds me that this should be considered with 286 systems where the RAM capacity is larger or even maxed out.
So this mode of operation should not be using any card with a LFB feature. Otherwise also the memory decoder needs to be altered as not to enable the memory data bus on the mainboard in these LFB areas.
Basically in the REV3E we can mostly do anything we want and adapt the logic for these types of situations.
If we could detect the VGA controller activity we could even create some kind of interaction between the VGA controller and the REV3E memory systems if a situation would call for such an adaptation.

Basically, VGA memory can be mapped in a high memory address like the 3MB-4MB range, or 15-16 MB range, so that processors can access it all in one big range of memory without having to paginate it via VGA registers. I think this was probably more common on VLB, PCI, etc and on 386/486 class machines. Because of this the higher address pins (LA20 and LA21 in this case) are actually in use, and of course MEMW/MEMR must be present.

Right, I see how this can yield many advantages for example also for windows type GUI software where you would want to move windows with contents around in the memory area.
So transferring the data linearly will be substantially faster.

One thing I want to note is that it seems MEMW/MEMR pins are not present in earlier 0WS cards (like the cirrus I sent you for example). They still use SMEMW/SMEMR because they are exclusively used with A000-BFFF mapped video memory. So its just these few cards with LFB support which have MEMW/MEMR present.

I see, indeed it's good to be aware of this. It seems that these designs may aim for supporting 8 bit systems optionally where the system doesn't even have a /MEMR and /MEMW available. So in those cases the card still at least can be able to function.

So, the problem was that it seemed like the VBIOS in the commercial cards with MEMW/MEMR was 'invisible' to most 286 systems except very late chipsets (SCAT, SCAMP, perhaps TOPCAT). So the card simply did not initialize and VGA bios didn't run. I could confirm with a monochrome card in ms-dos that the vbios was not visible at C000 hence using a second card with a BIOS copy at C000 to get around this.

This seems still weird to occur really, something may be off and non standard according to the design of the PC/AT.
So possibly the chipset will only assert /SMEMR and /SMEMW and not /MEMR and /MEMW in the VGA window? It seems so.
That would be a not so standard design choice, but it's possible.
I mean, if no /MEMR and /MEMW activity occurs it would explain that some card designs will not enable the ROM.

You also can verify the ROM on the card design to see the connectivity of the output enable pin of the ROM. Is it connected to the VGA controller, letting the VGA controller be in charge of the memory command passing or not passing tot the ROM, or does the ROM simply take the memory output enable command from either /SMEMR or /MEMR, combined with the chip select input of the ROM to actually decode the BIOS address range to be valid. If certain systems don't see the BIOS, this should be checked. If the ROM is hard wired to either /SMEMR or /MEMR, this could be a clue to a failure to see the ROM.
I need to look at this card really.
Okay is it this project?

GitHub - Leshak-pcb/Pine-CL-GD5434: CL-GD5434-based ISA VGA card.

CL-GD5434-based ISA VGA card. Contribute to Leshak-pcb/Pine-CL-GD5434 development by creating an account on GitHub.

github.com

I checked the schematic and it's using /SMEMW and /SMEMR.
The ROM is always outputting data and the card uses a transceiver to enable the data onto the slot.
Probably they do this to speed up the ROM output when using slower type of ROM chips.
So from the ROM perspective it is always in full operation outputting data.
So the enable speed onto the bus per cycle is then determined by the speed of the external transceiver.
The VGA controller enables the transceiver in the design as if it's the actual ROM OE pin.

Anyway, let's not overlook the fact that /SMEMW and /SMEMR are used here in this particular card design.
And the original card it's derived from may be doing the same thing as well, it probably is.
This seems to be the issue with the VGA ROM not loading in certain systems.
So those systems could look at moving the pins going to /SMEMW and /SMEMR onto the /MEMW and /MEMR pins of the slot to see if this could provide a solution. It depends on the system how it handles the activity of /MEMR and /MEMW to possibly be a better choice to drive the card. Of course, if the PCB didn't create the card pad on /MEMW and /MEMR to save some gold plating that would not be an option either.
Well, it is what it is once the card is manufactured of course.

Maybe I should design one of these cards in the future and add some design features where the user can choose to rewire stuff according to their system to accommodate how the system works and then be able to use the card. Or just design the card in a way that I feel would be better. This type of card design has a lot of considerations for power planes etc which is described in the datasheets. A lot of things need to be considered according to the datasheets.

And since the card(if I am looking at the right GitHub project) is wired this way, it won't work with any LFB feature if present.
The GD5434 only has a single set of /MEMR and /MEMW inputs so the designer must make the choice.
So a card design should be able to use /MEMR and /MEMW from the slot and this is also mentioned in the datasheet.
I don't know if the BIOS could then be functional in those cases where it is failing.
Maybe more is going on in those system designs and it won't help either.

Anyway if the BIOS is not loaded, it must be a command issue and this would indicate that possibly using the /MEMW and /MEMR in those systems could help.

In the REV3E we could do a lot of things the way we want for a particular configuration.
We can even move the VGA BIOS into the 8 bit mode ROM and supply it ourselves, if we disable the external ROM on the card.
There it is really easy to do because we can desolder the transceiver for the ROM.
Card users could opt to design a small decoder of themselves and cut the EROM trace to the GD5434 and supply the signal with their own decoder circuit.
That should also enable loading the VGA ROM.
Anyway it's a roundabout way then since possibly using /MEMW and /MEMR could do the trick already.
I will look at the PCB design and his GitHub as well, we could possibly make an updated layout and use /MEMW and /MEMR for our particular application types where we want to use the latest types of chipsets anyway. The decoding is not the problem since the GD5434 uses LA17-LA23 anyway.

Kind regards,

Rodney

 

[rodney]

If its an incompatibility with the older hardware with the MEMR/MEMW design then in an ideal world a design might have a jumper to toggle whether the 8 bit or 16 bit pins are used. While LFB sounds cool, I'm not sure any 286 software or drivers exist to support it. I think you would have to do it in protected mode, which is rare to see software supporting for 286 to begin with. At the same time, a modern recreation shouldn't drop the advanced features present for later cards I think.

I think even with the older hardware, the design should use the more sensible configuration.
Or provide jumpers to connect the memory commands either to /SMEMW and /SMEMR or /MEMW and /MEMR.
My personal preference would be just use /MEMW and /MEMR since it's supported by the GD5434 controller.
And with the note that any system which only activates /SMEMW and /SMEMR in the region will not work.
This would seem irregular for the system to do so, frankly speaking, but that's just my view at the moment, without knowing possible reasons for the designers.
Maybe it's all related to VGA BIOS shadow, and users could opt to disable that in the BIOS settings if they can, and retest.
Or enable and retest if it's off. The shadow copy routines may disable commands to even activate on the slot to avoid contention after the shadow copy is made.

We can make the design for our own application with a more modern chipset and RealDOOM since the whole reason for using this card is mostly to gain fps performance.
I need to look into the datasheet how the chip configures the bus mode between the different operation types.
Maybe this requires programming or hardwiring pins etc.
It seems that would be set at hardware level since otherwise maybe the BIOS would not be loaded if the chip is in the wrong mode.

Kind regards,

Rodney

 

[maxtherabbit]

In my experience the 0WS jumper just physically disconnects the 0WS pin on the ISA bus from the VGA ASIC. I.e. the ASIC is always asserting 0WS whenever it can and you are just choosing whether or not to allow the chipset to sample that.

 

[rodney]

In my experience the 0WS jumper just physically disconnects the 0WS pin on the ISA bus from the VGA ASIC. I.e. the ASIC is always asserting 0WS whenever it can and you are just choosing whether or not to allow the chipset to sample that.

Right, I just checked and indeed the 0ws is merely an open collector output of the GD5434 so the chip always tries to assert the SREADY function of the system controller.
So the controller does not sense a jumper being in place, it's output only.

And there also the VGA controller can decide when it has the data ready to be transferred.
Indeed this function does not guarantee that the data transfers will be at zero wait states since the timing is still decided by the VGA controller itself.
Which would explain that connecting the pin with the Diamond Speedstar card made no difference with a SCAT system when I was testing this.
So the SCAT assumed the VGA cycles to be of equal timing as the VGA controller itself is directing.
There was no difference between 0ws enabled or not, in that case.
In the REV3D system I also was able to do VGA cycles with similar speeds I think.
I would have to find and check my notes about this.
With the REV3D and REV3E system we can speed up the VGA RAM cycles by changing the decoders.
When disabled, the VGA RAM cycles will run at the same speed as system RAM.

I found that chipsets handle VGA cycles in different ways, some are using faster transfers than others.

I think with the TOPCAT, the BUSCLK speed decides the speed of VGA cycles proportionally together with other types of cycles such as slot IO.
So tweaking the effective BUSCLK will speed several things up which then needs to be tested.
The 16 bit IO wait states can be tweaked as well in the VLSI 331 so then this can further tweak the IO speeds as well relative to the VGA cycle speed as determined with BUSCLK.

Anyway, the effective speed of a VGA controller with the video RAM cycles is still highly variable depending on IOCH_RDY assertion by the controller.

I also would like to test with a GD5434 controller at some time to find out what level of VGA RAM transfer speeds it's capable of. I wonder if RealDOOM could run much faster with this controller in an otherwise optimized configuration of the system it runs in.

Kind regards,

Rodney

 

[sqpat]

I also would like to test with a GD5434 controller at some time to find out what level of VGA RAM transfer speeds it's capable of. I wonder if RealDOOM could run much faster with this controller in an otherwise optimized configuration of the system it runs in.

So in my experience, replacing the diamond speedstar 24 with one of these on a SCAT or SCAMP chipset increased performance by about 3% which is pretty good IMO. My best guess is that because the memory is buffered and quite fast, it reduces write wait states to the VGA memory.

--

This is sort of getting out into the weeds but would it be possible to handle read/writes to video memory (A000-BFFF) on a separate dedicated bus that would reduce bus contention with the main bus? Obviously this is complicated with regards to DMA (not sure if VGA memory is ever targeted by DMA?) but I know a few chipsets catch writes to video memory and handle it differently (like SCAMP and its fast video write feature). Conveniently this memory range lines up with a 128 KB boundary for 16 bit ISA 0WS lines. I suppose it'd be more realistic with integrated video, or perhaps with a dedicated card slot meant for this behavior.

 

[sqpat]

OK, small rant.

I finished soldering all these stupid microscopic resistor packs and some other things and finished the card. Then I go to the multimeter for a few last checks and notice 5v and gnd are shorted, great. It must be something I did today because I would have noticed that earlier. I check everything visually, the only thing I can't confirm is this stupid tiny surface mount 14.318 mhz oscillator. I end up lifting 3 traces pretty badly when lifting it, but I notice the short is gone. I assumed i must have damaged it during my soldering so I put another one on, after doing some PCB surgery and replacing traces. Same problem! Turns out when I chose a replacement for the oscillator from the BOM (which I couldn't find) , it had a different pinout, with pins 2/4 being GND instead of GND/Vcc, and it just works in a different manner. Learned something new. So now i have to wait another week for one more part to finish and test the card. When this is all done I will put together a wishlist of things for the card.

 

[rodney]

So in my experience, replacing the diamond speedstar 24 with one of these on a SCAT or SCAMP chipset increased performance by about 3% which is pretty good IMO. My best guess is that because the memory is buffered and quite fast, it reduces write wait states to the VGA memory.

Right, that's probably the reason. It's the dynamic wait states which are probably further reduced.
These are always occurring with VGA writes. I should feature a LED output to be able to see these wait states occurring.
Maybe in a future system controller in the REV3E we could do this type of thing to provide LED indication of IOCH_RDY occurring.
I am getting more interested in this GD5434 so I will study this card design more.

would it be possible to handle read/writes to video memory (A000-BFFF) on a separate dedicated bus

Basically it's not the bus itself causing the delays and speed reductions, it's the wait states and other cycle control being used such as an alternate state machine being used for the VGA RAM transfers with different clock sources than the main RAM access state machine to slow down the writes that is happening on the VGA window.
As you mentioned with the SCAT having provisions for setting faster VGA transfer speeds by reducing cycle control which is normally in place in the VGA RAM region.
With systems that separate the slot speeds when you push the slot access state machine too far it will start to fail in the IO transfers.
If we could completely eliminate that cycle control, the throughput to the VGA would become equal to normal memory transfers.
With the REV3E or future designs using a single more advanced state machine for all operations, we could then have the option to completely release the cycle control and treat VGA transfers as normal system memory operations. That's in the normal situation the fastest you could achieve and much more efficient. Maybe there is a 25% or more to be gained from that. Then combined with zero wait state speeds somehow that would be really the most optimal you can achieve.

Obviously this is complicated with regards to DMA (not sure if VGA memory is ever targeted by DMA?)

Theoretically VGA memory could be accessed with 16 bit DMA if the VGA controller had these provisions to respond to the DMAC-2. However this still poses issues with interrupting the VGA controller by pushing data into the VGA RAM while the real-time display generation process is also ongoing. It's the throughput itself that is the issue.

Really, a VGA controller that can handle fast writes is what we would like to find. Even the fastest ISA slot cards such as this GD5434 solution don't have true provisions for transparent continuous writing at full transfer speeds from the CPU, I would be surprised if it actually does. So you can say, such a thing doesn't exist yet.

A bit off topic, however in my opinion, it's probably a FPGA which would be the best option for achieving transparent full speed access to VGA RAM. An FPGA with a lot more resources internally could offer dual port internal RAM for direct uninterrupted and unmodified access. This FPGA RAM could operate at constant extremely high speeds without limitations. Even faster than typical system RAM. An FPGA VGA controller with such a dual port memory system could possibly even offer some form of accellerated transfers where you could program a transfer and the FPGA then handles it internally at extremely high speeds. If the VGA controller could supply a dedicated section of dual port RAM which is then mapped into the normal system RAM, this could act as a buffer preparing to move updated data into the actual display RAM when so programmed. It's in effect a kind of hardware accelleration of what a VGA controller would normally also do to move data from the VGA RAM window into the screen RAM locations.

So a FPGA VGA controller would be the fastest solution to speeding up VGA writes really. Dual port RAM can be written to and read from by two difference sources so one process never disturbs the other. This would require to choose a FPGA with a large amount of internal dual port RAM to accommodate screen memory, and designing a card to feature this FPGA with level shifters etc to interface to the 5V ISA bus.

As we are working on the REV4 designs, we could kind of do what you suggest, we could use a high speed internal connection to another FPGA which is dedicated for the video output. Different types of accellerated transfers and data manipulation could be conceived however these would then require some form of software support to interact with the PC system. An FPGA can move data much faster than the CPU can.

I think a next issue that presents itself with RealDOOM is that there are lots of calculations happening to create the screen. That is a bottleneck which always is present regardless of how fast the VGA RAM can accept transfers.

I think the real charm of our work is to try to do more with less, get more out of a system, increasing efficiency because there is a lot to be gained in that. So then the ultimate result would then theoretically only be limited by the true speeds of the CPU. This can get the most out of the 286 processor that it can possibly offer. That seems pretty optimal and cool, and I really wonder what fps levels that could result in. One important goal in efficiency is of course achieving true zero wait states. If those also can apply to the VGA window, I wonder what then the fps would be, even at 25MHz.

With my currently still limited insight into HDL, I had a look at the VGA controller in the AO486 design, and this seems to be an 8 bit wide solution judging from the IO defined in the HDL code. Internally in a FPGA only system that 8 bit will be amazingly fast of course since the transfer speed internally is very high, so the bit width is not an issue. If this design could somehow be converted to 16 bit, it would be more ideal for our PC/AT to accommodate the 16 bit data width processor. Anyway, we could start by creating the hardware for such a card, and just go on from there I suppose. It's a process regardless. We could start out with a 8 bit operation just to get it functional and proceed from there. If you have something to test with, maybe it can eventually lead to a practical application and starting the project is the first step in getting there I suppose. The cool thing could also be to create provisions tailored to RealDOOM operation, maybe some form of more optimized operation by the card to suit RealDOOM. You could detect for the presence of the card and then add some card specific operations. Or compile a separate RealDOOM version for FPGA video. Later on when we are more experienced with using FPGAs we can revisit these ideas as well. The first start will be the REV4 and then I suppose a VGA card design maybe. Possibly after building and debugging the REV4, we can then create another more optimized REV4 design, and then focus on a VGA solution. The charm with FPGA is that you can move the design into other forms more easily later on, so the designs can be reused which is really cool.

Kind regards,

Rodney

 

[rodney]

I finished soldering all these stupid microscopic resistor packs and some other things and finished the card. Then I go to the multimeter for a few last checks and notice 5v and gnd are shorted, great. It must be something I did today because I would have noticed that earlier. I check everything visually, the only thing I can't confirm is this stupid tiny surface mount 14.318 mhz oscillator. I end up lifting 3 traces pretty badly when lifting it, but I notice the short is gone. I assumed i must have damaged it during my soldering so I put another one on, after doing some PCB surgery and replacing traces. Same problem! Turns out when I chose a replacement for the oscillator from the BOM (which I couldn't find) , it had a different pinout, with pins 2/4 being GND instead of GND/Vcc, and it just works in a different manner. Learned something new. So now i have to wait another week for one more part to finish and test the card. When this is all done I will put together a wishlist of things for the card.

That is really one of the most annoying things that can happen!
I am also not a fan of microscopic stuff really. It may be nice for machine assembly but less nice for humans.

I remember once soldering an entire turbo XT mainboard together, only to discover that VCC and GND were shorted.
I was unable to find the cause and started the whole soldering job from scratch on a new board.
Which resulted in being double the work!
I desoldered the 100nF through hole caps and moved them to the new board, every time checking again with the multimeter.
Finally I saw a short again! Turns out a few caps had developed a short probably from the heat or mechanically when moving them from one board to another one. Since I soldered the thing in sections I could trace back which ones were the likely cause.

Sometimes when you cannot find a short between power and ground, you can use a ohm meter and probe around on components to find the lowest resistance on the board, which will be the area where the short is located. Or inject a low voltage and see what gets hot on the board, but this needs specialized equipment to inject voltage and monitor heat.

It's unfortunate that you anticipated testing and this part created a problem. It was not possible to rewire the thing in some crude but safe way? As long as you have a clock at least if not ideal, at least you can see some form of operation.

Anyway best of luck with your work, let's hope otherwise it may go more smoothly.
I will be interested what your findings are.
I am tempted to also look into this board.

Kind regards,

Rodney

 

[bakemono]

would it be possible to handle read/writes to video memory (A000-BFFF) on a separate dedicated bus that would reduce bus contention with the main bus?

You could have a FIFO that accepts writes immediately, from the perspective of the CPU, and retires them to video memory in the background while the CPU is doing other things. Some VGA chips already have a FIFO, so if your CPU is the same speed as the ISA bus, the matter is already settled. When the CPU is faster than the ISA bus, you'd want the FIFO in the chipset or in the CPU (like write gathering on 6x86MX and PPro+ CPUs). The FIFO needs to be flushed/disabled when graphics controller or banking registers are changed.