Image Map Image Map
Page 1 of 4 1234 LastLast
Results 1 to 10 of 35

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

  1. #1
    Join Date
    May 2011
    Location
    Outer Mongolia
    Posts
    1,931

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

    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.)
    My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs

  2. #2

    Default

    what video card is it?

    what's in the E segment?

  3. #3
    Join Date
    May 2011
    Location
    Outer Mongolia
    Posts
    1,931

    Default

    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.
    My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs

  4. #4

    Default

    Quote Originally Posted by Eudimorphodon View Post
    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

  5. #5
    Join Date
    May 2011
    Location
    Outer Mongolia
    Posts
    1,931

    Default

    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.
    My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs

  6. #6

    Default

    Quote Originally Posted by Eudimorphodon View Post
    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.

  7. #7
    Join Date
    May 2011
    Location
    Outer Mongolia
    Posts
    1,931

    Default

    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.
    My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs

  8. #8

    Default

    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.

  9. #9

    Default

    Quote Originally Posted by Eudimorphodon View Post
    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

  10. #10
    Join Date
    May 2011
    Location
    Outer Mongolia
    Posts
    1,931

    Default

    Quote Originally Posted by pcdosretro View Post
    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.
    My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •