• Please review our updated Terms and Rules here

List of DOS games that can run on V20 but cannot on 8088

OK, I had some time to get a 12 mhz v20 juko ST board running. The game actually ran on just ~580 kb free fine so I didnt even need to bother with UMB or EMS shenanigans.

blakestonev20.jpg

Recording here, to be honest the performance is still a lot worse than I thought it would be. I'll hack around the renderer and make it faster just for my own amusement, but its going to be like 10-20% faster at best, maybe it needs 3-4x at least though. Seems to be about 3fps at 12 mhz.
This was just 640k... I think load times would be faster with EMS, maybe not ingame fps though. The game seems to disproportionately be weighed down by the physics code rather than renderer code, and I think it's true the wolf3d engine suffers for not having BSP implemented.

 
I tried the new one, but it seems to load in the command line for about a minute then asks for a joystick calibration and quits, back to command line. I tried every combination of NOJOY, but was ignored. But someone else got it working!
 
My best guess - there are different versions of the game out there that may be configured differently with game resources format, etc.

The one I was working on was actually just the shareware version so it should be freely distributable. Here is the whole folder, zipped. I could imagine maybe this exe did not work with one of the registered versions for example.
 

Attachments

sqpat said:
I am taking a look at the renderer and there is a lot of room to be improved. [...] The render code can be half the length and significantly faster using the right combinations of lodsb, stosb, movsb, and some adds here and there.
Click to expand...

Looks like you have to add "Real Blake Stone" to your list of projects. ;)
 
I managed to build the ken's labyrinth source (https://advsys.net/ken/klab.htm) using microsoft c 6.00. I did get this running on emulator (I'm guessing the original ran too) - there are no processor checks however for ingame movement the game does not handle scancodes in an XT compatible way so you cannot move around in the map. (However menu movement works okay). Its hard to tell exactly the framerate but you can stand and crouch using a/z, judging from that the framerate would be around 2 fps on a 16 mhz v20 in emulator. I think its a more advanced engine than wolf3d, but not by much and probably a bit slower. The code structure is a bit of a mess (i think he was a teenager when he wrote it) but it could probably be improved a lot too.
 
I played the Blake Stone 8088, it's hilariously slow. It worked though! I'm legitimately impressed that it even worked as well as it did, but it's hilariously unplayable. A part of me is sad because I legitimately love that game. It's on a slow USB card thing, maybe I can get more speed if I free up more RAM and move it to the faster CF card.
 
sqpat said:
It does not require a 386 at all (despite the box saying so). It's just the wolfenstein engine again, but if it detects 386 it patches some calls to use a 32 bit version instead of the 16 bit version. I forget but wolfenstein may have also done something like this. The blake stone engine is similarly open source so you can see this all in the C code.

I am taking a look at the renderer and there is a lot of room to be improved. Interestingly the wolf engine creates a custom render function per column length. However it does a pretty poor job, using repetitive 3-5 byte "mov al, ds[si + x], mov es:[di+x], al" instructions instead of string instructions. The render code can be half the length and significantly faster using the right combinations of lodsb, stosb, movsb, and some adds here and there. It might make less difference on 386dx but it would be a big difference on 16 and especially 8 bit cpus done this way.
Click to expand...
A BSP renderer would have been faster than raycasting (although that's more work to create the maps, but it wouldn't be that bad to make the tools to do this); but yes, the raycasting generator could have been a lot better.

In particular there would be 8088 and 8086 optimised ways to do it that would take quite different approaches. This would be a fun exercise.
 
Not a game, but I think worth mentioning in this context is that it seems that a Trantor/NEC 8-bit ISA SCSI card I have (can't remember exact model, can look it up if anyone is interested) contains 80186/V20 instructions in the BIOS, while the driver that can be loaded from config.sys runs on an 8088.
This must had been an oversight by Trantor, surely? Like why would they sell an 8-bit ISA card if it wouldn't be fully compatible with 8088 computers?
 
Because most of the cards put in a 286/386 before 1990 were 8 bit ones? 16-bit card where you don't need it (a HDD controller, HDD is the bottleneck), is a significant raise of manufacturing cost.
Even the VGA didn't need 16-bit access.
 
The Trantor T130B uses insw/outsw which have no benefit on an 8-bit bus. So as Chuck says, probably they only built one BIOS and used it on both 8-bit and 16-bit cards. There's supposed to be a check for 8088, but it only works correctly for reads and not writes. I bet Trantor fielded many tech support calls over that.
 
Yeah there are many 8-bit and 8 bit compatible cards out there not compatible with an 8088. I think you especially see it with SCSI, Ethernet cards... the 186 instructions can be generally pretty useful for saving space. For real mode code, i think many developers defaulted to targeting 186/286 instructions but leaving out 386 real mode stuff for a long period of time, not thinking much about it.

Driver and bios may have had different developers, and one might've been written for what was assumed to be a 16 bit device and card.

16 bit isa cards with 386 BIOS instructions also exist, which means they dont run in 286 machines. And of course some 16 bit cards run in an 8 bit slot, but some of those also have 186 instructions. It's all over the place.
 
Plasma said:
The Trantor T130B uses insw/outsw which have no benefit on an 8-bit bus. So as Chuck says, probably they only built one BIOS and used it on both 8-bit and 16-bit cards.
Click to expand...

It looks like the Trantor was an NEC 5380-based card, which is an 8-bit controller. Is the 53C94 or some other later card with a 16 bit bus compatible enough with it that’d be worth sharing driver code?

(Whatever the case, I’d be interested in the port mapping. To work with word-wide transfers I wonder if Trantor built the hardware to work like the “Chuck Mod” for the XT-IDE, IE, ignore A0 so all the 8-bit ports appear at two contiguous addresses. Either the BUI in a V20 or the bus steering logic in an AT just papers over it at that point.)

In any case, the plus of using the word over the byte version is obvious *if* you’ve already bought into needing the IO string instructions in the host CPU; the same code will just magically run twice as fast if you can make compatible hardware that asserts IOCS16; no 8/16 bit check needed.

sqpat said:
Yeah there are many 8-bit and 8 bit compatible cards out there not compatible with an 8088.
Click to expand...

I basically quit using XTs with new software after 1990 or so back in the day, it was something of an education for me when I got my Tandy 1000 to play with a few years ago just how much late DOS software (not just BIOSes) just absentmindedly broke 8088/8086 compatibility in the 1990’s.
 
Eudimorphodon said:
I basically quit using XTs with new software after 1990 or so back in the day, it was something of an education for me when I got my Tandy 1000 to play with a few years ago just how much late DOS software (not just BIOSes) just absentmindedly broke 8088/8086 compatibility in the 1990’s.
Click to expand...

I'm guessing that was because compilers were not being tested on 8086/88's any longer and the code "worked fine on every machine we tested with." After all, in the 1990's the general advice pushed by the experts was that the 286 machines were on the way out. No one would use a 8086 any more, would they? The reality didn't matter, only what the experts believed mattered.

Of course, the other wrinkle here would be if the developers did "test on 8086's" but were actually testing on V20's or V30's. This thread is highlighting the fact that the 80186 left its mark on the industry, but it was largely hidden/forgotten in specifications. The games listed here as requiring a 286 likely did so because they couldn't run on an 8086/88 and the general public had hardly ever heard of 80186 based systems or that the NEC V series could run code written for them.
 
There are plenty of games that say they require a 386 but run on a 286 just fine too. I think it just gave support an out for “unsupported” hardware. The lack of v20 checks in open source code of the time shows how little devs of the time knew or cared of those CPUs imo.

I don’t think testing was done on v20s thinking they were 8088. These 8 bit cards were probably not 8 bit for 8088 support, but for for cost savings.
 
sqpat said:
I don’t think testing was done on v20s thinking they were 8088. These 8 bit cards were probably not 8 bit for 8088 support, but for for cost savings.
Click to expand...

If you don’t absolutely need the extra speed an 8 bit card is mercifully easier to design and build.
 
You must log in or register to reply here.
Back
Top