• Please review our updated Terms and Rules here

Via Mini-ITX EPIA as a retro DOS machine: setting up UMBs?

Eudimorphodon

Veteran Member
Joined
May 9, 2011
Messages
6,866
Location
Upper Triassic
Inspired by a recent thread on the worst x86 CPUs ever made I've dusted off an old mini-ITX thin client I've had untouched in my garage for at least a decade and decided to see how well it works as a strict, according-to-Hoyle DOS computer. (No Windows 95+.) The machine is based on one of the first EPIA revisions that uses a Via Apollo PLE133 North Bridge (SDRAM memory) with Trident-based VGA and an AC'97 sound codec that also includes some rudimentary Soundblaster hardware compatibility. The build at this point includes only what's on the motherboard, a single 512MB DIMM, and a PATA-to-SD converter with a 64GB card that DOS can't see most of.

After some fits, starts, and a 15 minute interlude where I decided the machine had definitively died and was about to strip out the DIMM and chuck it in the trash(*) I seem to have the machine pretty much working. But I have some questions/concerns about exactly how the hardware is set up.

My first crack at getting things running involved DOS 6.22 and MEMMAKER. Memmaker ran through its probing of upper memory and decided that the only unoccupied region suitable for UMBs was a 32k slice from D800-DFFF. (It complained very loudly that EMS wasn't a possibility because there was no room for the page frame.) Obviously 32k isn't anywhere near enough to be useful on a machine like this.

(Soundblaster emulation relies on a 38k TSR to do FM synthesis, only the digitized sound is aliased directly to hardware, and to make matters worse the packet driver for the onboard Rhine Ethernet also occupies 39k; an annoying amount considering the NE2000 driver on the Tandy 1000 is only 5k...)

I switched to PC-DOS 7.01, and instead of bothering with its memory setup wizard I tried setting up UMBPCI.SYS instead. When run without any arguments this driver apparently uses similar probing critera to MEMMAKER because it likewise only gave me 32k at D800-DFFF. Reading the manual it marks any area that doesn't return all zeros as occupied, so I blindly started playing with the /I switch to include larger and larger blocks of Shadow RAM.

Right now I have the machine booted up and seemingly working with the following line in config.sys:

DEVICE=C:\VIA\UMB\umbpci.sys /I=cc00=efff

Which results in mem /c showing the expected 144k of upper memory:

Code:
Modules using memory below 1Mb:

  Name           Total       =   Conventional   +   Upper Memory
  --------  ----------------   ----------------   ----------------
  SYSTEM      13,776   (13K)     13,760   (13K)         16    (0K)
  HIMEM          816    (1K)        816    (1K)          0    (0K)
  UMBPCI         160    (0K)        160    (0K)          0    (0K)
  COMMAND      2,656    (3K)      2,656    (3K)          0    (0K)
  CTMOUSE      3,104    (3K)          0    (0K)      3,104    (3K)
  DOSKEY       1,152    (1K)          0    (0K)      1,152    (1K)
  VIAFMTSR    38,928   (38K)          0    (0K)     38,928   (38K)
  FETPKT      40,208   (39K)          0    (0K)     40,208   (39K)
  FREE       700,976  (685K)    636,928  (622K)     64,048   (63K)

Memory summary:

  Type of Memory       Total    =     Used    +     Free
  ----------------  -----------   -----------   -----------
  Conventional          654,336        17,408       636,928
  Upper                 147,456        83,408        64,048
  Reserved              312,320       312,320             0
  Extended (XMS)     67,043,328        65,536    66,977,792
  ----------------  -----------   -----------   -----------
  Total memory       68,157,440       478,672    67,678,768

  Total under 1Mb       801,792       100,816       700,976

  Total Extended (XMS)                 67,043,328  (65,472K)
  Free Extended (XMS)                  66,977,792  (65,408K)

  Largest executable program size         636,832     (622K)
  Largest free upper memory block          63,664      (62K)
  Available space in High Memory Area      14,192      (14K)
  PC DOS is resident in the high memory area.

The base of CC00 was derived empirically by observing the following: When set to C800 the machine would boot fine into text mode, but running any kind of graphics software would crash to a garbage screen. This didn't happen with the base at D000, and splitting the difference seems fine as well. (However, the only software I've tried so far uses standard CGA/EGA/VGA modes, so I definitely can't say I'm not still sitting on top of part of the video BIOS.) So presumably if I tell it to use the 16k between C800 and BFFF I'm squatting on top of ROM, which would generally be discouraged.

Anyway. 96K seems like a heck of a lot of memory for a video BIOS, so I'm wondering if there's any sort of tool for looking at the Option ROM area of more modern machines like this and identifying what the contents of "occupied" areas are in more detail. Unfortunately I couldn't find anything remotely like this in the manuals for the motherboard. Maybe as long as it doesn't crash it doesn't matter so I can stick to just "try and fit"-ing it until I see a problem, but I'd still love to know what I'm stepping on. Unfortunately Checkit3, the tool that's usually really useful on the old machines, seems a little out of its depth here. I'm hoping some of that ROM is, I dunno, a huge wad of bloated PXE boot code that's deactivated anyway.

If anyone else is running a rig like this and has some tips for best setting up a pure DOS environment on such a "legacy free" PC I'd love to hear them. It would be nice if this thing had an ISA slot so I could set up a real Soundblaster card. Is there a PCI soundcard that can actually do FM synth in hardware under DOS? The FM synth from the TSR is a little wonky, but it does work, I guess. I'm curious about how compatible it's going to be with programs running under DOS extenders. (If at all.)

(* footnote: that "I almost threw it away" thing: this board has never had a fan on the CPU heatsink so I've always assumed it was a low power Eden board, but now I'm thinking some wanker harvested the fan off it before it ended up in the trash pile I stole it out of. It was running *hot*. It's been stable since I added a fan, fingers crossed.)
 
Video is the shared-memory Trident Blade 3D derivative they built into the chipset. Again, maybe I’m just out of touch thinking 96k is big for a video BIOS? Since the board does support some optional features like network PXE Boot I was wondering if there were several functions glommed together starting at C000.

As for the E-segment, good question. Checkit just identifies the final 128k as belonging to the Award BIOS. Nothing seems to break, though, with UMBs mapped there, if there is ROM in that area I wonder if it might be the BIOS setup menu code/data.
 
Video is the shared-memory Trident Blade 3D derivative they built into the chipset. Again, maybe I’m just out of touch thinking 96k is big for a video BIOS? Since the board does support some optional features like network PXE Boot I was wondering if there were several functions glommed together starting at C000.

As for the E-segment, good question. Checkit just identifies the final 128k as belonging to the Award BIOS. Nothing seems to break, though, with UMBs mapped there, if there is ROM in that area I wonder if it might be the BIOS setup menu code/data.

96kB is really large for a video BIOS, but not unprecedented - especially with PCI cards
 
I guess I should find some software that hits VESA extended modes and try to trip it up. I doubt there’s any native DOS drivers specifically for this card.
 
I guess I should find some software that hits VESA extended modes and try to trip it up. I doubt there’s any native DOS drivers specifically for this card.

If I were in your position I would use NSSI to dump the video and system BIOS and probe around them with a hex editor. See if all the reported space is actually filled with data.
 
I did some PEEKs from BASIC and there does seem to be “data” in these locations, or at least they definitely aren’t all zeros. My hope was there might be some kind of mapping/profiling utility to run on PCs like this and identify what modules lived where to see if it’s safe to map over them, but maybe that’s not a thing. From a dump I suppose I might at least be able to eyeball some guesses.
 
The byte at C000:0002 is the size of the video BIOS in 512-byte units (example 40h = 32KB). You can use DEBUG to display this (D C000:2). I have never seen a video BIOS ROM exceed 64KB.

You should look at the memory areas with DEBUG or a memory dump utility before assigning them as UMBs. E0000h-EFFFFh is generally part of the system BIOS on PCs after around 2000. Often the beginning of this area will be unused but depending on the BIOS there may be code in the remainder so you should check this area before attempting to use it as upper memory.

Note: there is no PC DOS 7.01, I assume you mean PC DOS 2000 which is PC DOS 7.00 revision 1 (INT 21h function 30h still returns major version 7 and minor version 0). The revision number was added with DOS 5.0 but was only used twice: PC DOS 5.00.1 (PC DOS 5.00 revision 1) and PC DOS 2000. Even though Microsoft added this feature to DOS they never actually used it.
 
I did some PEEKs from BASIC and there does seem to be “data” in these locations, or at least they definitely aren’t all zeros. My hope was there might be some kind of mapping/profiling utility to run on PCs like this and identify what modules lived where to see if it’s safe to map over them, but maybe that’s not a thing. From a dump I suppose I might at least be able to eyeball some guesses.

if it was actually empty space they would be all 1s from the bus pullups
 
The byte at C000:0002 is the size of the video BIOS in 512-byte units (example 40h = 32KB). You can use DEBUG to display this (D C000:2). I have never seen a video BIOS ROM exceed 64KB.

Bingo. The byte there is 60, so it's 48k long.

Dumping at CC00 the first three bytes are 55 AA 4C, so apparently there's another option ROM that's 38k long immediately after the video bios. Snooping around that's confirmed; there's code/data from CC00 to D57FF; above that it's all FFs. UMBPCI has a resolution of 16k for mapping pages, so that explains why it thinks it can't start until D800. Scrolling through the contents it looks like my guess was dead on: starting at CC10:5 is an Intel PXE-2.0 copyright/build version message. I have PXE disabled in the BIOS and I don't see the message at boot time but it still apparently squats on memory space. So, great, it's probably safe to squat a UMB on top of this. (The Ethernet card seems to work fine with the DOS driver with it covered up.)

Looking at E000 there isn't the 55 AA signature, so it probably is part of the main system BIOS. I'll try dumping it and looking for strings to see if it looks like it might be data tables or diagnostic code. Or maybe I'll just pretend it's okay until I get a crash.

Note: there is no PC DOS 7.01, I assume you mean PC DOS 2000 which is PC DOS 7.00 revision 1 (INT 21h function 30h still returns major version 7 and minor version 0).

Yes, it's PC DOS 2000 I was referring to. It's mildly confusing because a few sites call it 7.01, mostly ones that are making distinctions between it and the "7.1" that people cobble together using that based-on-Window 9x's DOS kernel version. :p

(I'm thinking of trying the latter, although I don't know what the compatibility implications will be.)

In other news, just for the heck of it this morning I copied over Jazz Jackrabbit from the DOSbox install on my real computer, and after applying the Turbo Pascal speed patch it fired right up with music that sounds... okay? when configured for a Soundblaster Pro. (I'm almost tempted now to pull my old BP6 out of storage and fit it with the SoundBlaster AWE32 to bake off against the real deal.) This thing is showing some actual potential as a rig for playing with 1990's DOS stuff on.
 
Yes, it's PC DOS 2000 I was referring to. It's mildly confusing because a few sites call it 7.01, mostly ones that are making distinctions between it and the "7.1" that people cobble together using that based-on-Window 9x's DOS kernel version.

Those sites are wrong, I have an authoritative list of DOS versions here - https://sites.google.com/site/pcdosretro/dosver and here - https://sites.google.com/site/pcdosretro/doshist
Basically you have this:
PC DOS 7.0
MS-DOS 7.0 (Windows 95)
MS-DOS 7.1 (Windows 95 OSR 2 and Windows 98) - FAT32 support
PC DOS 2000 (PC DOS 7.0 revision 1) - PC DOS 7.0 with Y2K mods and Euro symbol support
PC DOS 7.1 - not a complete or official release but it also has FAT32 support (different coding from MS-DOS 7.10)

I suspect that IBM did PC DOS 7.1 for some third-party who needed DOS with FAT32 support; Symantec perhaps (for Norton Ghost) ?
 
I suspect that IBM did PC DOS 7.1 for some third-party who needed DOS with FAT32 support; Symantec perhaps (for Norton Ghost) ?
is that essentially the same version you built with the only change being FAT32 support added?

Bingo. The byte there is 60, so it's 48k long.

Dumping at CC00 the first three bytes are 55 AA 4C, so apparently there's another option ROM that's 38k long immediately after the video bios. Snooping around that's confirmed; there's code/data from CC00 to D57FF; above that it's all FFs. UMBPCI has a resolution of 16k for mapping pages, so that explains why it thinks it can't start until D800. Scrolling through the contents it looks like my guess was dead on: starting at CC10:5 is an Intel PXE-2.0 copyright/build version message. I have PXE disabled in the BIOS and I don't see the message at boot time but it still apparently squats on memory space. So, great, it's probably safe to squat a UMB on top of this. (The Ethernet card seems to work fine with the DOS driver with it covered up.)
IIRC the intel PCI NICs have a DOS utility available that can disable the option ROM outright
 
is that essentially the same version you built with the only change being FAT32 support added?

I only worked on PC DOS 7.0 - I started with PC DOS 6.3 and the end result was PC DOS 7.0. I had nothing to do with PC DOS 2000 though I did analyze the differences - https://sites.google.com/site/pcdosretro/pcdos2000diffs - as for PC DOS 7.1, yes it is built upon PC DOS 7.0 with the major additions being FAT32 and LBA support. Since there was no official release of PC DOS 7.1 there were apparently multiple revisions. The early revisions are unstable - for instance attempting to run MSCDEX hangs in the earlier revisions. The last known revision 1.32 appears stable but of course it uses more memory that PC DOS 7.0 due to the additional support. Also some of the standard DOS commands were updated like FDISK and FORMAT as necessary.
 
Those sites are wrong

I wasn't saying they were right, just noting that I'm not the first person to inaccurately refer to 2000 as being a minor point release of PC-DOS 7. But if hairs must be split 100% correctly I'll attempt to stay on the right side of it. (PC DOS 2000 just strikes me as kind of a cumbersome name. I'll just say DOS 7 and leave it as that.) Many apologies.

Next on my list on this point, I guess, is to fiddle with these same include switches and see if they work with EMM386, or if it'll refuse to land on top of ROMs. UMBPCI.SYS seems to work fine and may be the better solution for general use because it runs without needing VM86 mode but I do have a yen to try some things that want EMS.
 
IIRC the intel PCI NICs have a DOS utility available that can disable the option ROM outright

This PXE code targets the onboard Via Rhine II Ethernet. I guess it might be interesting to see if the ROM signature goes away if I disable the port. (There's no utility I see for disabling just the BIOS.) I wouldn't think it would matter since it doesn't look like that code is even touched unless "Network" is enabled in the boot order options.
 
I wasn't saying they were right, just noting that I'm not the first person to inaccurately refer to 2000 as being a minor point release of PC-DOS 7. But if hairs must be split 100% correctly I'll attempt to stay on the right side of it. (PC DOS 2000 just strikes me as kind of a cumbersome name. I'll just say DOS 7 and leave it as that.) Many apologies.

Next on my list on this point, I guess, is to fiddle with these same include switches and see if they work with EMM386, or if it'll refuse to land on top of ROMs. UMBPCI.SYS seems to work fine and may be the better solution for general use because it runs without needing VM86 mode but I do have a yen to try some things that want EMS.

There's no need for apology, I was just clarifying.

EMM386 should work the same though running in real mode is always faster than running in V86 mode.
 
MSD has a nice memory block display and browser. Disabling "Legacy USB" and using a PS/2 keyboard should also free up some space.

ESS Solo 1 (ES1938S) is a good PCI sound card with real FM synth that works in pure DOS. The device driver only uses 112 bytes in my machine.
 
Last edited:
If you wanted to go further back and play some 80's DOS games on it too, try this:
http://www.oldskool.org/pc/throttle/DOS

It's a slowdown utility to make your machine work with non-speed controlled titles, and there are a lot of them. This slowdown tool is controlled via hardware and provides smooth slowdowns and will not interfere with any game like TSR based slowdowns can.

The VIA chipset on that motherboard utilizes an otherwise reserved bit to control the throttle amount, so that machine has double the amount of slowdown options.
 
Digging around it looks like DOS drivers exist for the Sound Blaster Live! Series of cards. I think I have a couple different variants of those in the junk box. Would that be any improvement over the built in sound, or does it also rely on software for FM synthesis? I will say the emulation on Via board doesn’t sound terrible to me, but I’m not a huge connoisseur of sound card quality. (It sounds at least as good as DOSbox?)

It is kind of sad the Via board doesn’t have a game port, or a header for one.
 
Rummaging through the scrapheap I've managed to turn up a Sound Blaster Live CT4830 (looks like that translates to the "Value" skew) and an Aureal Vortex 2. The latter looks like it's probably a waste of time; it has a DOS driver but it looks like its wavetable emulation is entirely software and, if Phil's Computer Lab's video is any indication, it may be worse than the Via's emulator. According to some threads on Vogons it sounds like the Live!'s DOS support is just a rehash of the Ensoniq AudioPCI's emulator software, IE, also all emulated.

Does anyone know if I shove one of these cards into the PCI slot if the gameport will at least show up under DOS at the standard address and work if I don't install the DOS sound drivers for the card? I'm guessing not.
 
Back
Top