• Please review our updated Terms and Rules here

PC-DOS 3.2 for 5150

Trixter said:
I tried USE!UMBS on PC-DOS 7 and the memory block chain got funky when DOS tried to use it. QRAM -- which predated PC-DOS 7 -- did not have this problem, so I stopped using USE!UMBS. I don't believe its implementation is 100% sound.
Click to expand...

I've been using USE!UMBS on my Tandy 1000s with PC-DOS 7 for the bulk of the last year and it seems to work fine, but I guess I don't know what symptoms you're encountering. To load the resident part of COMMAND.COM high I use the built-in support in PC-DOS (/H switch), like so:

SHELL=C:\COMMAND.COM C:\ /e:512 /P /H

not the SHELLMAX helper. It occupies about 5k of UMB with that switch. Conventional memory footprint in "mem /C" in total for my configuration with all drivers loaded is only 9,664 bytes, so if there's any room for optimization I can't imagine it's a lot.
 
Trixter said:
On PC-DOS 7 with USE!UMBS, what does the output of mem /p/c look like? Does it list everything properly, or do some parts look suspicious?
Click to expand...

I guess I don't know what "suspicious" means exactly, but so far as I can tell it's enumerating all my installed drivers with reasonable numbers for how much space they're occupying in conventional+upper memory. The only oddity I've noticed with MEM /C is it seems to want to call the chunk of the DOS kernel/data it loads into upper memory as part of the "RESERVED" total, there's no "upper memory" line item for that and the "Total" figure for upper memory is adjusted accordingly. (IE, if I have 96k of UMB total MEM /C shows about 61k as my "total" amount of upper memory and there's no specific accounting of the 30-something-k part of DOS that's up there.) But I *think* DOS 6.22 did that too? I guess I'd need to boot from a floppy and check.

What should I be looking for?
 
After loading U!U and then running DOSMAX (on DOS 3.3, it froze on 3.2) it printed its first sign on message saying "DOSMAX at DA00" which was the correct segment. However the next message where it lists the data structures, it says "moving" them all to the bottom of conventional memory. 0Dxx and such. Suspect
 
Eudimorphodon said:
I guess I don't know what "suspicious" means exactly
Click to expand...

Capture of MEM /C output with PC-DOS 2000, using DOSMAX/U!U:

Code: 
Modules using memory below 1Mb:

  Name           Total       =   Conventional   +   Upper Memory
  --------  ----------------   ----------------   ----------------
  SYSTEM      27,632   (27K)      9,328    (9K)     18,304   (18K)
  BIOSPTCH       128    (0K)        128    (0K)          0    (0K)
  USE!UMBS       192    (0K)        192    (0K)          0    (0K)
  DOSMAX         240    (0K)          0    (0K)        240    (0K)
  SETVER         816    (1K)          0    (0K)        816    (1K)
  ANSI         3,600    (4K)          0    (0K)      3,600    (4K)
  LTEMM        6,320    (6K)          0    (0K)      6,320    (6K)
  INSTALL        160    (0K)          0    (0K)        160    (0K)
  COMMAND      5,056    (5K)          0    (0K)      5,056    (5K)
  CTMOUSE      3,104    (3K)          0    (0K)      3,104    (3K)
  XPRT           544    (1K)          0    (0K)        544    (1K)
  DOSKEY       3,952    (4K)          0    (0K)      3,952    (4K)
  PNPPD        4,672    (5K)          0    (0K)      4,672    (5K)
  FREE       660,240  (645K)    645,696  (631K)     14,544   (14K)

Memory summary:

  Type of Memory       Total    =     Used    +     Free
  ----------------  -----------   -----------   -----------
  Conventional          655,360         9,664       645,696
  Upper                  61,312        46,768        14,544
  Reserved              331,904       331,904             0
  Extended (XMS)              0             0             0
  ----------------  -----------   -----------   -----------
  Total memory        1,048,576       388,336       660,240

  Total under 1Mb       716,672        56,432       660,240

  Total Expanded (EMS)                  1,048,576   (1,024K)
  Free Expanded (EMS)                   1,048,576   (1,024K)

  Largest executable program size         645,680     (631K)
  Largest free upper memory block          14,256      (14K)

For whatever (nothing?) it's worth so far as I can tell this jives with the memory map data I get out of Checkit3; it's hard to tell for sure because anything loaded from config.sys just gets lumped into a "Device Drivers" blob, of which there are three; there's a 10k blob that I think accounts for ANSI.SYS, BIOSPTCH, LTEMM, etc (*), there's an 18k blob that appears to to be the "SYSTEM" blob that MEM /C displays, and there's a 36K blob that is the right size to account for that part of Upper Memory that's just "disappeared" and lumped in with "Reserved" on the MEM /C output.

(* Yeah, I can confirm by booting an alternate config without LTEMM this entry shrinks by the same amount while the "SYSTEM" 18k and the mysterious 36k block stay. If I had to hazard an inaccurate guess the 36k part is the bulk of what would be loaded above the 1024K mark in a machine that has an actual high memory area instead of the "fake" one provided by DOSMAX?)
 
I also use USE!UMBS with PC-DOS 2000 and DOSMAX with no particular issues. I use 4DOS as shell, and keep the dos structures low because DMA to upper memory do not work with my setup. Beside that, I have the same MEM /C and memory structure described by Eudimorphodon.

HiRAM is an alternative to USE!UMBS. On my Amstrad PC5086 it detects the 64K of upper RAM at D0000 and work as fine as U!U, oddities on mem /c and reserved memory blob included. There are a number of switches to change the way UMBs are managed (I am not expert enough to understand exactly what they do), and it includes a HILOAD program to load TSRs in upper memory for dos < v5.0.
 
maxtherabbit said:
After loading U!U and then running DOSMAX (on DOS 3.3, it froze on 3.2) it printed its first sign on message saying "DOSMAX at DA00" which was the correct segment. However the next message where it lists the data structures, it says "moving" them all to the bottom of conventional memory. 0Dxx and such. Suspect
Click to expand...
You may not have enough upper memory to load everything high. On PC-DOS 7, 32K are not enough to load the kernel high, and dosmax puts only the data structures in upper memory. Dos 3.3 is smaller and the kernel may fit, but there may be enough free umbs for the data structures.
 
davide78 said:
You may not have enough upper memory to load everything high. On PC-DOS 7, 32K are not enough to load the kernel high, and dosmax puts only the data structures in upper memory. Dos 3.3 is smaller and the kernel may fit, but there may be enough free umbs for the data structures.
Click to expand...

AFAIK the DOS 3.3 kernel cannot be moved. That is a feature exclusive to DOS 5+. In any case, loading DOSMAX did not produce a change in reported free memory so it was in fact not loading anything high, except perhaps its own stub.
 
Well I figured out why I was having so much trouble utilizing the SRAM on the NIC. In addition to the overlap with the built-in 8k already discussed, the socketed SRAM is not a valid DMA target. Bizarrely the onboard 8k is.

In debug:
-l d000:0 0 0 1 gives me a sector from the floppy
-l d800:0 0 0 1 writes nothing
 
FYI, I ended up making a video partially about my experience earlier in this thread extending DOS past 640k; no new info for you guys, but the animations might give you a chuckle:

 
I have this RTL8019AS-based 8-bit NIC (rev 2.2): https://github.com/hkzlab/ISA_8bitNetwork_8019.
Configuration: I/O 300h, IRQ 7, 64K BOOT ROM @ D000h (via jumpers). Works fine as a NIC.
Using an AS6C4008-55PCN (4Mbit, 512Kx8) SRAM chip (tested, works).

RTL2UMB reports success @0300h but USE!UMBS (@D000-E000) freezes.
Also freezes when using jumperless mode (i.e. config via EEPROM).

USE!UMBS (@D000-E000) works when using a lo-tech 1mb ram card.

Any ideas?
Should I use a different SRAM chip?

Thank you in advance.
 
Have you tested using the driver to try to enable the SRAM and then used BASIC or something to probe to see if the RAM is really there? (It's pretty simple; in GWBASIC/BASICA/QBASIC use:

DEF SEG=&HD000

To set the data segment base to the start of your UMB, and then try POKE-ing some values in and PEEK-ing them back...

FWIW, it looks like the ROM socket on that card is set up for the SST39SF040; I vaguely remember that there were some pinout differences between the smaller SST39SF010 and the AS6C4008 (I've built cards using both), let me look at the datasheets...

Oh, yeah, that be your problem. The pinouts of the two chips have some fatal differences. Some of the address lines are rearranged, which while annoying shouldn't matter much for RAM, but the deal killer is the write pin on the DIP-packaged RAM is pin 29, while write is pin 31 on the flash. You'll need to tinker up some jumper wires to swap those two pins to make the RAM work.
 
Not RAM detected at the specified segment.

I will swap pins 29 & 31 and report back with the result.

Anyway, thanks!
 
Eudimorphodon said:
Have you tested using the driver to try to enable the SRAM and then used BASIC or something to probe to see if the RAM is really there? (It's pretty simple; in GWBASIC/BASICA/QBASIC use:

DEF SEG=&HD000

To set the data segment base to the start of your UMB, and then try POKE-ing some values in and PEEK-ing them back...

FWIW, it looks like the ROM socket on that card is set up for the SST39SF040; I vaguely remember that there were some pinout differences between the smaller SST39SF010 and the AS6C4008 (I've built cards using both), let me look at the datasheets...

Oh, yeah, that be your problem. The pinouts of the two chips have some fatal differences. Some of the address lines are rearranged, which while annoying shouldn't matter much for RAM, but the deal killer is the write pin on the DIP-packaged RAM is pin 29, while write is pin 31 on the flash. You'll need to tinker up some jumper wires to swap those two pins to make the RAM work.
Click to expand...
Success!!! Crosswired pins 29 & 31 and it works like a charm!

I really appreciate your help!
 
MadMaxx1234 said:
Success!!! Crosswired pins 29 & 31 and it works like a charm!

I really appreciate your help!
Click to expand...

Hah! Cool, glad it worked. Maybe you should post an issue on the card designer's github explaining what you're doing and suggest they consider adding a jumper option for using the socket for RAM as well as ROM.

I actually have a baggie of those RTL8019 chips in my IC hoard nagging at me to do something with them, it's actually kind of a shame they didn't make the memory paging capabilities of the chip just *very* slightly more capable. It has almost enough hardware built into it to let you write an EMS driver; it's capable of paging through 4Mb of memory in 16K pages, but unfortunately only *one* 16K page.

(I think the EMS 4.0 standard *technically* had a provision for using fewer than 4 pages in the page frame, but software support for that is practically nonexistent?)
 
Eudimorphodon said:
Hah! Cool, glad it worked. Maybe you should post an issue on the card designer's github explaining what you're doing and suggest they consider adding a jumper option for using the socket for RAM as well as ROM.

I actually have a baggie of those RTL8019 chips in my IC hoard nagging at me to do something with them, it's actually kind of a shame they didn't make the memory paging capabilities of the chip just *very* slightly more capable. It has almost enough hardware built into it to let you write an EMS driver; it's capable of paging through 4Mb of memory in 16K pages, but unfortunately only *one* 16K page.

(I think the EMS 4.0 standard *technically* had a provision for using fewer than 4 pages in the page frame, but software support for that is practically nonexistent?)
Click to expand...
I was thinking of exactly that! Will post on designer's github.

Pitty that so many RTL8019s are *nearly* capable... :(

AFAIK, indeed LIM EMS 4.0 allows for 1 to 4 16K pages in the page frame - unfortunately I guess that someone must write an EMS driver supporting this configuration and then test some software ...

I also confirm that DOSMAX must be run with the "/S+" option to prevent floppy drive "misbehaviour" (as previously reported in this thead).
 
Last edited:
MadMaxx1234 said:
I also confirm that DOSMAX must be run with the "/S+" option to prevent floppy drive "misbehaviour" (as previously reported in this thead).
Click to expand...

Yeah, that's a straight up bug in the 8019AS chipset, you're not supposed to qualify memory accesses on AEN like I/O accesses. But of course it's not going to matter with a boot ROM unless you're doing something extremely weird.
 
The interesting thing is that MS-DOS 3.20 (Not 3.21) from Microsoft Genuine OEM doesn't work on IBM PC 5150 with Rev.0 (04/24/81) and Rev.1 (10/19/81) BIOS.
(But it works on Rev.2 (10/27/82) BIOS)
MS-DOS 3.21 was solved this problem.
 
You must log in or register to reply here.
Back
Top