PC-DOS 3.2 for 5150

[Eudimorphodon]

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

I assume that he wired the socket up to the "gated" MEMW coming out of the 8019A ASIC, not straight to the card edge connector.

My two RTL cards have footprints on their boards for a 32 pin DIP, but they have a 28 pin socket soldered in it, I have a feeling might be similarly brain-damaged and need some traces bridged over to enable this, but I'll have to look. The ASIC, if I understood the datasheet correctly, actually has quite a few tricks up its sleeves, like theoretically even being able to page flip the memory in the ROM slot; it's (this) close to being a brain-damaged EMS mapper.

 

[davide78]

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

The RTL8019AS gates the chip enable signal, not the memory write/memory read. With write disabled, chip enable is asserted when MEMR is asserted and the address on the bus is inside the ROM memory window. When writes are enabled, the ASIC enables the rom chip also when MEMW is asserted and the address is inside the ROM memory window. MEMW and MEMR are connected directly from the ROM socket to the isa bus. My card has a DIP28 footprint where MEMR is connected to ground and MEMW to +5V, so I had to wire them to the corresponding pins in the edge connector.

(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.)

Yes, please do it. I will send you my github username.

As for loading DOS high, I realized that moving the dos data segment in the UMB causes problem with floppy disks. DIR A: gets you garbage and lots of disk fail errors. This happens with both DOSDATA=UMB (and no dosmax) and DOSMAX (and no dosdata), with PC DOS 2000 and MS DOS 5 with a minimal configuration (floppy only, no hd nor XTIDE bios). So I assume it may be some bug of my specific machine or BIOS (an Amstrad PC5086). To have a working setup I must add /S+ to DOSMAX.SYS to keep the dos data segment in low memory and load only the kernel high. This decreased free conventional to 619K, or 615K with the packet driver and etherdrv.

 

[maxtherabbit]

It's a common problem with ISA DMA. Your NIC doesn't like being a DMA target apparently

 

[davide78]

That makes sense. Supporting write operation is intended for flashing a ROM, not for adding RAM, and I suppose you don't need to be a DMA target in this case.

 

[Eudimorphodon]

The RTL8019AS gates the chip enable signal, not the memory write/memory read. With write disabled, chip enable is asserted when MEMR is asserted and the address on the bus is inside the ROM memory window. When writes are enabled, the ASIC enables the rom chip also when MEMW is asserted and the address is inside the ROM memory window.

Aaah, okay. I guess I should have looked at the datasheet. So in other words, its chip select algorithm isn't just based on the address, it's based on both address *and* the read/write signals. (And tweaking the register enables the write part of the equation.)

I'll definitely have to take some time to poke around the PCB of my cards and see how fully populated their socket footprints are. I don't have any "wide" 28 pin RAMs lying around (I have some narrow-footprint 32k ones I bought for another project) so I don't have the equipment to test it on hand, but next time I buy chips maybe I'll see if I can toss one in. In theory by doing this I could do 176k of upper memory from C4000 to EFFFF in my 1000 EX and still have 1MB of EMS with the page frame at A0000. I'm sure that'd be good for "something".

(My Tandy 1000s don't have DMA, so it might be an interesting experiment to load the DOS data high into the 8019A memory and confirm the DMA theory. It sounds reasonable; I'm guessing the RTL8019A gates itself on AEN, that's pretty common for I/O devices. It is technically wrong for memory devices, but for a boot ROM I can't imagine it would matter.)

Uploaded the driver to the repository with the others, thanks for the contribution!

 

[maxtherabbit]

I tested ISA DMA from the FDC to the built in RAM on my WD8003 card, works a treat. Used debug to load some sectors from the floppy drive straight to high RAM and the data was correct. I'm still waiting on that cypress SRAM part.

@kdr would you mind sharing your code to twiddle the registers on the WD bus interface?

This business also gave me the idea to resurrect my 16bit ROM card and give it a slight redesign to support SRAM in addition to PROMs. This might be the motivation I need to figure out how to beat the AT latching MEMCS16# on the falling edge of ALE with my assertion based purely on the lower 20 bits of address. Gotta go fast

 

[kdr]

@kdr would you mind sharing your code to twiddle the registers on the WD bus interface?

Well, so far I've only been poking at the registers using DEBUG.COM; no code written yet. Flipping register bits to see what happens is fun, but writing a DOS device driver and parsing commandline parameters is tedious. Besides, since I am committed to running DOS 3.3 on my XT for reasons of "authenticity", I'm not even sure what I would do with a block of UMB!

[Speaking of authenticity, the WD8003 card has surface mount components, really I should replace it with a 100% through-hole card, hmmm...]

 

[maxtherabbit]

Well, so far I've only been poking at the registers using DEBUG.COM; no code written yet. Flipping register bits to see what happens is fun, but writing a DOS device driver and parsing commandline parameters is tedious. Besides, since I am committed to running DOS 3.3 on my XT for reasons of "authenticity", I'm not even sure what I would do with a block of UMB!

[Speaking of authenticity, the WD8003 card has surface mount components, really I should replace it with a 100% through-hole card, hmmm...]

Could you post the register address(es) and value then? I can write the driver

 

[davide78]

FYI, I updated the code of the RTL2UMB driver stub to get the base I/O address from the command line (in the first version the address was hardcoded in the code). The new code is on Eudimorphodon's repository. Parsing the command line in assembler is a tedious work ... very well suited for a foggy sunday afternoon . It got even more tedious when you discover that the command line is passed differently when the driver is executed from CONFIG.SYS from when it is executed as a normal EXE.

Can the unsupported ISA DMA cause problems with other hardware beside the floppy? The only other device that I am sure uses DMA is the sound card: in the few games and programs that I tried digital audio works fine. I don't think they use UMBs though.

 

[maxtherabbit]

XT class MFM/RLL hard drive controllers also use DMA

 

[Eudimorphodon]

Parsing the command line in assembler is a tedious work ... very well suited for a foggy sunday afternoon . It got even more tedious when you discover that the command line is passed differently when the driver is executed from CONFIG.SYS from when it is executed as a normal EXE.

Yeah, I found the whole thing immensely confusing, which is why I didn't even try with EMS2UMB and just hard-coded the I/O register address to the default. (Which happens to be what I used on my register-compatible implementation... although, strictly speaking, because the decode "resolution" of my unit is one bit less than the Lo-Tech version it occupies both the "default" address and the first alternate and would respond to either.) I should put on my list looking at what you did and adding it to EMS2UMB.

And, yeah, original XT MFM/RLL hard disks indeed used DMA. The "standard" XTIDE and XT-CF implementations don't use it; I vaguely recall there *is* an alternate "fast" version of XTIDE that can use (abuse) it, but it's not common?

 

[kdr]

For the WD83C584, here are the relevant registers to enable a 32K SRAM at segment D800:

(Assume the card is at I/O port 0x260-0x27F, bits are D0=LSB ... D7=MSB)

(1) write a zero to bit D1 at port 0x261 (this causes the BIOS ROM Address Register to appear at 0x263) [do a read-modify-write]
(2) write 0xAC to port 0x263 (selects a 32KB ROM at segment D800)
-bits D6:D7 are size (00=disable, 01=16K, 10=32K, 11=64K)
-bits D1:D5 are the address bits (SA14:SA18)
-bit D0 is a software interrupt request, should be '0'
-SA19 isn't specified in this register, it is always '1' (so address must be in upper 512K)
-so 0xAC translates into a 20-bit physical address decode of 1101 10xx xxxx xxxx xxxx (D8000-DBFFF)
-and I think the size specification of 32K causes SA14 to be ignored = decode becomes 1101 1xxx xxxx xxxx xxxx (D8000-DFFFF)
(3) write a one to bit D1 at port 0x261 (select the EEPROM Address Register)
(4) write a one to bit D4 at port 0x263 to enable RAM mode [do a read-modify-write]
(5) write a zero to bit D1 at port 0x261 (de-select the EEPROM Address Register)

Because the RAM bit is kept in the EEPROM Address Register, I don't think it can be loaded automatically from the configuration EEPROM at power-up... the configuration does survive a warm reset though. You can actually just use the EZSETUP.EXE tool from the adapter's driver disk to configure the card's ROM address and size, then all that's needed is steps #3-5 (poke the RAM bit in the EEPROM address register).

Do you have the WD83C584 datasheet? It wasn't the easiest to find... can send it to you if needed.

 

[maxtherabbit]

Thanks! I don't have the datasheet, a copy would be much appreciated. Once I get my SRAM and verify this works I'll post an installable device driver for this.

PS you might want to check "disable smileys" when you edit your post to prevent it from doing that

 

[kdr]

Thanks! I don't have the datasheet, a copy would be much appreciated. Once I get my SRAM and verify this works I'll post an installable device driver for this.

PS you might want to check "disable smileys" when you edit your post to prevent it from doing that

Awesome, would be great to have a tiny little driver for this!

Next up is getting my hands on a 28C64 or 28C256 so that I can make option ROMs that will work on a cold boot.

I missed the edit window but will remember to disable those darned smileys for next time. What a silly default to have on a technical forum! :D

 

[maxtherabbit]

(4) write a one to bit D4 at port 0x263 to enable RAM mode [do a read-modify-write]

Glad you sent me that datasheet, because that's actually meant to be bit D3. That was vexing me for a minute. Pity it can't be edited now

 

[davide78]

Yeah, I found the whole thing immensely confusing, which is why I didn't even try with EMS2UMB and just hard-coded the I/O register address to the default. (Which happens to be what I used on my register-compatible implementation... although, strictly speaking, because the decode "resolution" of my unit is one bit less than the Lo-Tech version it occupies both the "default" address and the first alternate and would respond to either.) I should put on my list looking at what you did and adding it to EMS2UMB.

There is a good explanation of how to parse the command line for normal programs in "The art of assembly language programming", chapter 13:
https://www.plantation-productions.com/Webster/www.artofasm.com/DOS/index.html
I essentially started from there, and then reverse-engineered the code of use!umbs.sys to get the command line when the driver is executed from config.sys.
Feel free to use my code in any way you want.

And, yeah, original XT MFM/RLL hard disks indeed used DMA. The "standard" XTIDE and XT-CF implementations don't use it; I vaguely recall there *is* an alternate "fast" version of XTIDE that can use (abuse) it, but it's not common?

Right, MFM/RLL controllers. Also original 8-bit IDE XT drives used DMA (not the modern XTIDE), from what I remember? My Amstrad happens to have such an 8-bit IDE controller, currently unused since I have no compatible hdd to connect to it. 8-bit compatible drives are somehow rare and expensive, so I went for a modern solution, i.e., an ess audiodrive with and IDE port and the XT-IDE universal BIOS.

 

[maxtherabbit]

@Eudimorphodon

I started in on writing a device driver to set the WD8003 bus interface registers for SRAM using your pastebin derived code as a handy template. Hope you don't mind! In the process, I identified a couple of issues (one major) in the existing code, so I opened a pull request on github to share back the fix. Since we are now using a block device instead of a character device, we need to tell DOS that we're actually initializing 0 units so it doesn't try to parse a junk BPB made of random memory contents.

 

[Eudimorphodon]

@Eudimorphodon

I started in on writing a device driver to set the WD8003 bus interface registers for SRAM using your pastebin derived code as a handy template. Hope you don't mind! In the process, I identified a couple of issues (one major) in the existing code, so I opened a pull request on github to share back the fix. Since we are now using a block device instead of a character device, we need to tell DOS that we're actually initializing 0 units so it doesn't try to parse a junk BPB made of random memory contents.

Thanks! I accepted the commit; I should probably merge the changes you made into the other widgets in the repository. I haven't seen any crash yet but any possibility of doing random things with uninitialized junk data is definitely a BAD THING.

If you'd like commit privileges to the repository I could set that up for you.

 

[maxtherabbit]

Thanks! I accepted the commit; I should probably merge the changes you made into the other widgets in the repository. I haven't seen any crash yet but any possibility of doing random things with uninitialized junk data is definitely a BAD THING.

If you'd like commit privileges to the repository I could set that up for you.

I accepted the invite on github, thanks

 

[davide78]

Thank you @maxtherabbit! I have merged your fix in the rtl2umb utility, that is based on the same pastebin example. I haven't had any issue with the old code, but it is better to initialize things correctly.