PC-DOS 3.2 for 5150

[maxtherabbit]

Here is the driver to enable the SRAM-in-boot-PROM-socket feature on the WD8003. Defaults to NIC base port 280 and segment D800 for the RAM window. Both configurable via command line arguments, can be run from command prompt or loaded as device driver in CONFIG.SYS. Thanks to Chuck for providing the parser function!

View attachment WDSRAM.zip

 

[maxtherabbit]

@kdr can you give my driver a try? I tested that it writes the registers properly, but I'm still waiting on a SRAM chip to give it a real spin

 

[kdr]

@kdr can you give my driver a try? I tested that it writes the registers properly, but I'm still waiting on a SRAM chip to give it a real spin

Yes, I'm planning to give it a try soon - thanks for putting together a proper driver!

(Sadly the first WD8003 card has died [cause of death yet to be determined] so I need to install the spare.)

I also have a couple of new arrivals: AT28C64 and AT28C256 EEPROMs and a 28-pin ZIF socket. I -think- that the 28C256 will work in the WD8003 card in SRAM mode, which would be great because then I can get started with doing some option ROM coding.

 

[maxtherabbit]

Yes the eeproms will work but the writes are pretty slow. You will have to make sure you pause after each 64 byte page to let the write cycle complete

 

[maxtherabbit]

Bit of a setback with this project. The SRAM chip finally arrived and I found out my driver does it's job just fine. However, there are a couple issues.

1) The card actually USES the memory for network communications. After loading the packet driver and initializing the NIC, writes to the normal, built-in 8kB buffer located at the D000 segment will be mirrored onto the first 8kB of the add-on SRAM chip at D800. I confirmed this in DEBUG by filling 8kB at seg D000 and then reading back the same contents from seg D800. The reverse is not true, writes to D800 don't get duplicated to the factory SRAM buffer. I need to pour over the documentation of the packet driver and chip datasheets to see if this behavior can be altered with a register or something.

2) The Last Byte exhibits the same "bad or missing CON" error when trying to load it as in installable device driver in PC-DOS 3.2. It works fine in PC-DOS 3.3, although

3) it will crash if the memory is not 0 filled first. I'll examine that issue in further detail after 1)

 

[kdr]

After loading the packet driver and initializing the NIC, writes to the normal, built-in 8kB buffer located at the D000 segment will be mirrored onto the first 8kB of the add-on SRAM chip at D800.

Hmm, that's interesting. I didn't spend enough time playing with the 32K SRAM configuration to notice that issue. Once I have a working 8003EP card installed I will double-check and see if I can confirm it.

(I had the packet buffer configured at CA00 and the "ROM" configured at D000.)

 

[Eudimorphodon]

1) The card actually USES the memory for network communications. After loading the packet driver and initializing the NIC, writes to the normal, built-in 8kB buffer located at the D000 segment will be mirrored onto the first 8kB of the add-on SRAM chip at D800. I confirmed this in DEBUG by filling 8kB at seg D000 and then reading back the same contents from seg D800. The reverse is not true, writes to D800 don't get duplicated to the factory SRAM buffer. I need to pour over the documentation of the packet driver and chip datasheets to see if this behavior can be altered with a register or something.

That's weird. If that socket is meant for an EPROM maybe it's just flat-out a hardware bug? (Incomplete decoding?)

 

[maxtherabbit]

Still not sure if this behaviour is by design or flaw, but changing the built-in shared memory to base address CA00 just moved the mirrored 8k to D800:2000.

In other news, using The Last Byte's "exclude" option causes it to hang on initialization. I'm about fed up with it, are there any other pre-DOS5 compatible memory managers out there that will support fixed physical memory?

 

[Trixter]

I got fed up with The Last Byte as well, which was one of the straws that broke the camel's back and prompted me to just patch my boot sector.

FYI, I'm making a video about this experience, to compare and contrast the "proper" way vs. how I patched my sector.

 

[dieymir]

Maxtherabbit, try this one

View attachment hiload.zip

I used it a lot in the early 90's with, back then obsolete, memory cards. It includes a high memory ram disk and TSR loader as well as full source code and extensive documentation.

 

[dieymir]

Of course you can also reserve some memory and use a XMS UMB provider (i.e. USE!UMBS) with 4DOS (I use 3.03 version) to squeeze some more memory as I do. I have a Turbo XT with 128 KB of high memory (D000-EFFF) and the following memory map:

* D000-E300 (76KB) for EDISK (see hiload.zip) I have the 4DOS swap file here.
* E300-E400 (4KB) reserved to USE!UMBS I load the transient part of 4DOS here
* E400-EFFF (48KB) to load several other TSRs high

I'm running MS-DOS 3.21 with 600KB free.

 

[Trixter]

So far my record is 703K free: EEMS 3.2 board, MS-DOS 6.22, QRAM, DOSMAX, CGA graphics only.

I could get even more free if 4DOS worked on the system in question, but all versions 3 through 8 just hang (I blame both 4DOS and my system's compatibility equally for this behavior).

 

[maxtherabbit]

I don't understand why you guys are referencing 4DOS in a memory management context, isn't it just a shell replacement? What's the memory angle?

Also @dieymir thank you for the utility!

 

[Eudimorphodon]

I don't understand why you guys are referencing 4DOS in a memory management context, isn't it just a shell replacement? What's the memory angle?

It appears that 4DOS has some functionality to load its transient footprint high, which would save a little bit of conventional memory. PC-DOS 7 has the ability to do that with its version of COMMAND.COM and it does free a bit of space; DOSMAX also has a function to enable that with the post-5.x MS-DOS DOSes. I can't imagine 4DOS could really save *that* much more, but I haven't tried it.

 

[maxtherabbit]

So seeing the post about USE!UMBS working for 4DOS on DOS 3.2 got me thinking. Heretofore I was under the impression it required DOS5 to function (specified in the documentation), but it doesn't.

After loading U!U on my PC-DOS 3.2 system, I was shocked to discover that cute mouse was now automagically loading itself high! Next up I'll try to combine it with DOSMAX

 

[dieymir]

This is a common misconception. There are two (actually three) ways to access UMBs: using XMS int 2F functions or using DOS int21 functions (which itself uses XMS int 2f)
You need dos >=5 for the latter but you can always do the former as long as you have a XMS UMB provider (in PC/MS-DOS HIMEM.SYS isn't, EMM386 is) USE!UMBS is a XMS UMB provider so you can use it with 4DOS or whatever program that is able to load high that way to save some memory. As a bonus 4DOS is a much nicer and capable shell.

There are other UMB providers out there. TLBMM includes one, DR DOS has HIDOS.SYS, ...

NOTE: The third way would be direct manipulation of MCBs. Of course, you don't need DOS >=5 to do this, either

 

[maxtherabbit]

I may give 4DOS a try but I'm fairly set in my command.com ways. DOSMAX has the ability to load command.com into UMB anyway so hopefully that works.

 

[maxtherabbit]

Can't get DOSMAX 2.1 to play nice with the UMBs provided by U!U in PC DOS 3.2 or 3.3. In 3.2 it just halts the system on load and in 3.3 it loads but fails to move any structures.

Guess it's time to give 4DOS a spin

 

[Trixter]

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.

4DOS works perfectly on my 5160, but locks up on my M24 (6300). I tried 4DOS versions 3, 4, and 8 (the last open-source version). Source is available, and maybe someday I'll try to figure it out.

DOSMAX has the ability to load command.com into UMB anyway so hopefully that works.

Only parts of it.

 

[maxtherabbit]

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.

I'm getting this impression also, unfortunately another "dumb" UMB provider that will just allow you to define a fixed range of upper memory doesn't seem to exist.