• Please review our updated Terms and Rules here

PC-DOS 3.2 for 5150

TheDrip said:
Anyone know of a workaround to get an Oak 077 chipset to always have the ram be visible to the system?
Click to expand...

Turning VGA memory into a DOS extension is a job for VIDRAM.COM from the QRAM distribution. It'll extend conventional memory to 736k and you can toggle it on and off. (Remember, no graphics programs when it's enabled.)

I believe its normal for VGA cards to not map any memory in the A page unless you're actually using an EGA or VGA mode.
 
Eudimorphodon said:
If all it takes is literally just overwriting the value at 40h:13h with the new size I wonder how hard it would be to patch that into an XTIDE BIOS image. (On machines so equipped.) I could test *lowering* it 16k to see if it solved the borked UMB issue on Tandy 1000s....
Click to expand...

I certainly like the option/system ROM editing approach more than messing with the boot sector. XUB uses an EBDA, so it would make sense to put the code in the XUB, since the EBDA would need to be moved anyway.

@trixter did you give up on the UMB MCB chain hammering?
 
maxtherabbit said:
@trixter did you give up on the UMB MCB chain hammering?
Click to expand...

Yes. Too much dark arts necromancy involved. While the "undocumented" low DOS RAM MCB chain is well-documented, I couldn't find sufficient documentation on how the UMB chain works. The first UMB MCB is typically located at 9FFF:0, but where DOS keeps the location of that first block is still unknown to me, which would be necessary to know if I relocate it to AFFF. I found some virus code that claims to manipulate it, but only from the sense that it assumes the first UMB MCB is at 9FFFF. I reverse-engineered no less than three programs that perform this function (including VIDRAM), and gave up after realizing the universal solution was to just boot with 704K. I'm happy to share my .I64 IDA PRO files, or a partial disassembly listing of VIDRAM, if someone else wants to pick up where I left off. (EEMRAM appeared to ignore any UMBs, and The Last Byte's program was written in C and considerably harder to follow than VIDRAM which was written in ASM.)
 
Instead of modifying the boot sector, you could also write a DOS program to change the memory size and then reboot using INT 19H. I don't know offhand if DOS 3.2 restores interrupt vectors, but newer versions do (just don't load any TSRs that hook other ints).
 
maxtherabbit said:
I certainly like the option/system ROM editing approach more than messing with the boot sector. XUB uses an EBDA, so it would make sense to put the code in the XUB, since the EBDA would need to be moved anyway.
Click to expand...

It actually doesn't use an EBDA on an XT if you don't enable "full operating mode". I don't because EBDAs are incompatible with Tandy 1000s unless you pre-allocate a big chunk of memory to make sure the Tandy graphics modes don't overwrite it.
 
Makes me wish that pcdosretro guy hadn't rage quit since he might be able to offer some insight into the MCB chain
 
Eudimorphodon said:
Turning VGA memory into a DOS extension is a job for VIDRAM.COM from the QRAM distribution. It'll extend conventional memory to 736k and you can toggle it on and off. (Remember, no graphics programs when it's enabled.)

I believe its normal for VGA cards to not map any memory in the A page unless you're actually using an EGA or VGA mode.
Click to expand...

Much obliged, I've never seen max executable size be over 630k before on any of my DOS machines now or 30 years ago. Where was vidram.com in 1992 when I needed it? mem is showing 720k max executable size for my 8088 now, incredible!
 
dreNorteR said:
Instead of modifying the boot sector, you could also write a DOS program to change the memory size and then reboot using INT 19H. I don't know offhand if DOS 3.2 restores interrupt vectors, but newer versions do (just don't load any TSRs that hook other ints).
Click to expand...

That didn't work for me, primarily because as you noted warm reboots don't restore interrupt vectors. Something always hung the system, maybe because I always load a packet driver, and use 4dos as a shell.

maxtherabbit said:
Makes me wish that pcdosretro guy hadn't rage quit since he might be able to offer some insight into the MCB chain
Click to expand...

Agreed. That was quite bananas. I do have the DOS 6 source; I was looking at mem.c and other parts when I was working on it.

th3bar0n said:
More C code, but does this have some pieces of the puzzle?
https://sourceforge.net/p/freedos/svn/157/tree//freecom/branches/expRes/loadhigh.c?format=raw
Click to expand...

Hey! This is telling:

/* Turn UMB link on. If MS-DOS UMBs are available, the signature of
* the last conventional memory block will change from 'Z' to 'M'. */
Click to expand...

That explains a lot! That might be what I would have needed to get this working. I did see UMB link state stuff in the code I was RE'ing but didn't understand what was going on.

But I'm leaving this to other people -- my solution is fine for me, and it is very unlikely I'd need to expand/contract DOS size from the command-line. Someone can expand on the ASM source I posted earlier.
 
Trixter said:
That didn't work for me, primarily because as you noted warm reboots don't restore interrupt vectors. Something always hung the system, maybe because I always load a packet driver, and use 4dos as a shell.
Click to expand...

The idea is to run this from plain DOS without any drivers when you need the extra memory.

I recently tried to install OS/2 1.3 on a system with only 1 MB of extended memory (NEAT chipset, 2 MB total but 640-1024K shadowed). The installer crashed because there wasn't enough memory. Wrote a small program to enable RAM at A000-B7FF and reboot from the installation disk, and it worked. Not very usable with this little memory though :)
 
Last edited:
dreNorteR said:
The idea is to run this from plain DOS without any drivers when you need the extra memory.
Click to expand...

I always need the extra memory.

I recently tried to install OS/2 1.3 on a system with only 1 MB of extended memory (NEAT chipset, 2 MB total but 640-1024K shadowed). The installer crashed because there wasn't enough memory. Wrote a small program to enable RAM at A000-B7FF and reboot from the installation disk, and it worked. Not very usable with this little memory though :)
Click to expand...

If you have to jump through hoops to install something, it's generally not worth attempting to run that something once installed.
 
Eudimorphodon said:
I assume that's the Lo-Tech 2MB EMS card? If it is and you want to test a random thing some joker on the internet came up with I wrote a little point-enabler dingus, "ems2umb.exe" to set up a card compatible with the LTEMMS card to give you 64k of upper memory space without having to load the resident driver. The driver as compiled will only work if the I/O of the card is set to the default 260h.

Anyway, using this lets you use USE!UMB.SYS to do upper memory stuff with MS-DOS 5 or later while saving the ~5k or so the EMS driver takes up. Obviously you don't get to use EMS when using it for this.
Click to expand...

I tested your tool on my 5150. When running it from the command line, it works fine (clean boot from PC-DOS 3.2 system disk), but when I tried to load it as a device driver in my CONFIG.SYS it broke the console. The only line in the config was DEVICE=C:\EMS\EMS2UMB.SYS and it printed it's sign on text, but then DOS printed the error "bad or missing CON" and stopped responding to keyboard input.
 
Huh. I'll try it on some other DOS versions and see if I can replicate it. That code wrapper that lets the EXE run from config.sys is pretty much a black box to me.
 
Eudimorphodon said:
Huh. I'll try it on some other DOS versions and see if I can replicate it. That code wrapper that lets the EXE run from config.sys is pretty much a black box to me.
Click to expand...

Try changing the MSB of your device attributes to a 0. That will change it to a block device instead of a character device
 
maxtherabbit said:
Try changing the MSB of your device attributes to a 0. That will change it to a block device instead of a character device
Click to expand...

I did some testing and the verdict seems to be that the EMS2UMB.EXE file works on DOS 3.3 or later, but I do indeed get that "Bad or missing CON" error on 3.21 or 2.11. I wonder what changed between 3.2 and 3.3. I also tested VGAFUDGE.EXE, which uses the same wrapper, on those OSes and it likewise trips the same problem. (It'd worked fine on 3.3, so I guess I assumed it was all good.)

Just made your suggested change, changing the 1010000000000000b in the source to all zeros, and it seems to work! I was able to boot with ems2umb.exe in config.sys on DOS 2.11. (Which amusingly enough lets me run the 128k RAMDISK program that Tandy shipped with a rare 512k variant of their own memory card for EX/HXs on my haxxor'ed HX.) I'll make the same change to VGAFUDGE and ensure that works (and also works on 3.21) and update the github.
 
Both binaries tested on Tandy DOS 3.21 and 2.11 (and PC-DOS 7 to ensure no breakage with higher OS-es), and updated source and binaries pushed to the github repository. Thank you for the help!

(In particular it's probably good to make sure VGAFUDGE.EXE works on DOS 3.21; the UMB driver probably isn't super useful to people running less than DOS 5 except for a few weird cases but it's possible there's someone out there that wants to make a VGA card work right in a Tandy 1000 SX or TX with the original DOS that came with it.)
 
Eudimorphodon said:
NICE!
I just took a look at the datasheet for the RealTek 8019AS in my machine and it looks like the same trick might be possible. The bit in question refers to "Flash Memory", but all it does is gate whether the MEMW pin is enabled on the socket so I can't think of a reason why it wouldn't take an SRAM.
Click to expand...
And I can confirm that ... IT WORKS! I installed a SRAM chip in the ROM socket, and by enabling the "Flash write operation" I got 64K of RAM at the configured address! The socket in my card is hardwired for a 16K ROM, so I had to connect MEMW and the extra address bits with some wire and solder. It's a bit messy, but it works.

Eudimorphodon said:
... EDIT: On second thought, later in the manual it looks like "write enable" register might not have its state loaded from reading the EEPROM, enabling writes is something you'd have to do after power-on. So maybe if you wanted an SRAM in that socket you'd need to make a little device driver stub to throw the write enable at it before loading USE!UMB.SYS, which would sure be a pain. Not 100% sure, though...
Click to expand...
Actually, it is not that difficult. You only need a bunch of writes to the correct registers. I modified your EMS2UMB to enable "rom writes" and now I have 630K of free conventional memory, thanks to USE!UMB.SYS and DOSMAX. 621K if I load a packed driver and ethersrv. The code of the device driver stub is here: View attachment rtl2umb.zip

Code: 
Modules using memory below 1Mb:

  Name           Total       =   Conventional   +   Upper Memory
  --------  ----------------   ----------------   ----------------
  SYSTEM       9,488    (9K)      9,440    (9K)         48    (0K)
  USE!UMBS       208    (0K)        208    (0K)          0    (0K)
  4DOS         4,896    (5K)        800    (1K)      4,096    (4K)
  DOSMAX         272    (0K)          0    (0K)        272    (0K)
  ANSI         3,600    (4K)          0    (0K)      3,600    (4K)
  SETVER         784    (1K)          0    (0K)        784    (1K)
  FILES        1,504    (1K)          0    (0K)      1,504    (1K)
  FCBS           272    (0K)          0    (0K)        272    (0K)
  BUFFERS      5,344    (5K)          0    (0K)      5,344    (5K)
  LASTDRIV     2,304    (2K)          0    (0K)      2,304    (2K)
  INSTALL        160    (0K)          0    (0K)        160    (0K)
  CTMOUSE      3,184    (3K)          0    (0K)      3,184    (3K)
  FREE       651,872  (637K)    644,896  (630K)      6,976    (7K)

Memory summary:

  Type of Memory       Total    =     Used    +     Free
  ----------------  -----------   -----------   -----------
  Conventional          655,360        10,464       644,896
  Upper                  28,544        21,568         6,976
  Reserved              364,672       364,672             0
  Extended (XMS)              0             0             0
  ----------------  -----------   -----------   -----------
  Total memory        1,048,576       396,704       651,872

  Total under 1Mb       683,904        32,032       651,872

  Largest executable program size         644,880     (630K)
  Largest free upper memory block           6,976       (7K)
 
I don't follow - if you had to hardwire the MEMW strobe to the socket then what are the register writes actually doing? I thought the whole point of the register bit was to gate the memory write strobe
 
davide78 said:
And I can confirm that ... IT WORKS! I installed a SRAM chip in the ROM socket, and by enabling the "Flash write operation" I got 64K of RAM at the configured address! The socket in my card is hardwired for a 16K ROM, so I had to connect MEMW and the extra address bits with some wire and solder. It's a bit messy, but it works.

Actually, it is not that difficult. You only need a bunch of writes to the correct registers. I modified your EMS2UMB to enable "rom writes" and now I have 630K of free conventional memory, thanks to USE!UMB.SYS and DOSMAX. 621K if I load a packed driver and ethersrv. The code of the device driver stub is here:...
Click to expand...

That's awesome! It occurred to me after I posted that comment about it being a pain to have to initialize the card registers before using it that the config.sys exe wrapper I used for my stuff would be a perfect fit for this problem, as long as programming the registers wasn't too much of a pain. I'm glad the code was useful start.

(Is it okay if I mirror your source on the same repository as the others? If you have a github account I could give you submit privileges to the repository.)
 
You must log in or register to reply here.
Back
Top