XT clone built from ebay components

[jh1523]

This XT clone has no physical RAM above 640k. And the hardware EMS board I'm using has so far proven incapable to give me anything else than the EMS page frame. The remainder of the upper memory area remains empty except for the CGA buffer and the XTCF BIOS. All of the other programs I've used confirm that there is no physical RAM there.

 

[Trixter]

My system is configured similarly to yours, and QRAM is providing UMBs using the page frame. I don't know if it reduces the size of the page frame to do this or how it operates, but it is working and I can both load small programs high as well as run programs that use EMS (even disk caches).

I'm not in front of it right now so I can't provide a RAM assignment dump, but my config file looks like this (PC DOS 7):

DEVICE=c:\DRV\EMM.SYS PC 258 ND RD
DEVICE=C:\QRAM\QRAM.SYS R:2
DOS=umb
DOSDATA=UMB
DEVICE=c:\qram\loadhi.sys C:\PCDOS2K\setver.exe
FILES=30
BUFFERS=99
LASTDRIVE=H
stacks=0,0
shell=c:\ndos.com /e:768 /u

(ndos is an OEM version of 4dos.) I also load a network packet driver high in autoexec. I have 590KB available with this configuration, and I have a full 640KB on the motherboard and am not remapping anything else; only the EMS board provides a 64KB page frame.

 

[jh1523]

OK I'll see what qram can do. But first I have a few more harebrained schemes about that extra flash memory.

 

[jh1523]

I tried something a bit weird, and it didn't work. Not sure why.
My idea is: how about I move the XTIDE bios and the floppy bios to another area so that when I'll be able to fill the upper memory with RAM I'll have bigger contiguous blocks.

Skimming through the mechanism of recognition of BIOS extensions, it looks like the BIOS initialization routine scans an area from C000 to F400. It stops once it hits F600. I disassembled the BIOS of this board, and it looks like it's doing it right:

00000347  BA00C0            mov dx,0xc000
0000034A  1E                push ds
0000034B  8EDA              mov ds,dx
0000034D  BB0000            mov bx,0x0
00000350  8B07              mov ax,[bx]
00000352  3D55AA            cmp ax,0xaa55
00000355  7536              jnz 0x38d
00000357  B84000            mov ax,0x40
0000035A  8EC0              mov es,ax
0000035C  32E4              xor ah,ah
0000035E  8A4702            mov al,[bx+0x2]
00000361  B105              mov cl,0x5
00000363  D3E0              shl ax,cl
00000365  03D0              add dx,ax
00000367  B104              mov cl,0x4
00000369  D3E0              shl ax,cl
0000036B  8BC8              mov cx,ax
0000036D  E89416            call word 0x1a04
00000370  7515              jnz 0x387
00000372  52                push dx
00000373  26C70667000300    mov word [es:0x67],0x3
0000037A  268C1E6900        mov [es:0x69],ds
0000037F  26FF1E6700        call word far [es:0x67]
00000384  5A                pop dx
00000385  EB0A              jmp short 0x391
00000387  26800E150020      or byte [es:0x15],0x20
0000038D  81C28000          add dx,0x80
00000391  81FA00F6          cmp dx,0xf600
00000395  7CB4              jl 0x34b

So, the idea is if I burn the code in an EPROM and pop it at say address F000 (which is in the system BIOS area) it will be recognized as such, and then I'll be able to remove the flash chip from the XTCF board (which is mapped at C800) and it will still work, while leaving C800 as available for RAM. And since my motherboard has 8 EPROM sockets, numbered from 0 to 7, where the system BIOS is in socket 7 and sockets 3-6 have the Basic EPROMs, I thought it would be as simple as putting the burned EPROM in socket 0, and it'll be good to go.

But... it doesn't happen. After doing just that, and removing the flash chip from the XTCF board, the drives aren't recognized anymore. And a quick look with debug.exe at F000:0000 shows that the area is empty. It's just as if the EPROM wasn't there. But I verified it, and it really contains the code in question.

I'm stumped. Why doesn't this work?

(edit: I tried the EPROM in socket 1 also, and it still doesn't work)

 

[Trixter]

I've had a chance to review my configuration and I owe you an apology -- what QRAM does (on my system) is use EMS 4.0's ability to remap RAM and stand up an additional 64KB at E000, and that's where it (and PC DOS 7) loads stuff high. If your board can't remap RAM, this won't work for you. Sorry.

 

[jh1523]

OK preliminary proof-of-concept done. I used a lo-tech ISA ROM board, with the chip flashed with the XT IDE bios and the FDC bios, then mapped at F000:0000 as 32KB. Initially the system gave me error #20 at boot, because part of the flash chip was overlapping one of the Basic ROMs (the ISA ROM board unfortunately cannot map 16KB, only 32K or 64K). I removed EPROM #4 and that let the board successfully POST and boot, and recognize 1.44M floppyes as well as the CF card attached to the XTCF. I should say that I had previously removed the flash chip from the XTCF itself. An examination of the upper memory reveals that it's indeed completely empty save for the CGA buffer at B800-BFFF.

So it can be done. The downside of this method is that I had to disable the onboard BAsic by removing one of its chips. A potential workaround would be to flash the ROM board with ALL of the BIOS code, including the XT-IDE, FDC, Basic and system BIOS and map the chip over the whole F000 segment, then remove all of the EPROMs.

I still don't understand why the motherboard won't recognize EPROMs placed in the empty sockets. I even tried a different EPROM chip, and it's still not seen. If I could get this to work it would be IMHO a much more elegant solution.

 

[tipc]

the links provided on post #6 do weird things to my browser.

 

[tipc]

I quickly scanned all the posts. I think you may need to try using an 8 bit floppy/hd controller. Perhaps the floppy controller seeks to use 16 bit transfers. If we're talking about an IDE controller on that card, it most definitely will not work w/an XT mobo.

 

[jh1523]

I quickly scanned all the posts. I think you may need to try using an 8 bit floppy/hd controller. Perhaps the floppy controller seeks to use 16 bit transfers. If we're talking about an IDE controller on that card, it most definitely will not work w/an XT mobo.

That part is solved a long time ago. I'm using a 16-bit multi-IO card of which of course the HDD controller doesn't work, but the FDD controller does, in DD mode only. I then added a BIOS extension made of the firmware of a 8-bit FDD controller, and that gave it support for HD floppies as well. It all works beautifully, but now I'm looking for a method to move the BIOS extension from the C000 segment to the E000 segment so that I leave more room in the upper memory area for a future RAM board.

I'm using a lo-tech XT-CF board to attach a CF card as a hard drive, and that works quite well also.

My current problem is that the motherboard has empty EPROM sockets which should map in the F000 segment, but any EPROM chips that I place there aren't recognized.

 

[nestor]

My current problem is that the motherboard has empty EPROM sockets which should map in the F000 segment, but any EPROM chips that I place there aren't recognized.

I think that is the expected behavior, F000 segment is reserved for the main BIOS, so it is not scanned for extension bios.

 

[jh1523]

I think that is the expected behavior, F000 segment is reserved for the main BIOS, so it is not scanned for extension bios.

Actually it is, see my post #46 above. The BIOS scans for extensions from C000 to F400 (code snippet in post #44). When I placed the extensions at F000 in a flash chip mapped in that region it works (the motherboard built-in BIOS doesn't start until F600, area F000-F600 is blank) , however I'd rather not do that but instead place the code in an EPROM there.

 

[Krille]

I think it should work if you combine the FDC BIOS with XTIDE Universal BIOS and then put the resulting file in the beginning of the free area of the system ROM. The ROM memory map would thus look like this;

| FDC BIOS 8 KB | XUB 8 KB | Free Area 8 KB | System BIOS 40 KB |

I'm using a 16-bit multi-IO card of which of course the HDD controller doesn't work, but the FDD controller does, in DD mode only.

Have you tried using that HDD controller as a "16-bit ISA IDE in 8-bit mode" controller with XTIDE Universal BIOS? If the planets are all aligned it might just work.

BTW, I'm looking into the problem with the Hitachi microdrive. Is the drive size reported to be 39.19 MB on the 386 as well? Have you tried using another version of DOS just to make sure it's not a bug in DOS? If I were you I would be using MS-DOS 6.22 anyway to avoid bugs in 6.20.

 

[jh1523]

I think it should work if you combine the FDC BIOS with XTIDE Universal BIOS and then put the resulting file in the beginning of the free area of the system ROM. The ROM memory map would thus look like this;

| FDC BIOS 8 KB | XUB 8 KB | Free Area 8 KB | System BIOS 40 KB |

That is exactly the configuration I had in the setup from post #46. Just that the XTIDE and FDC code was in flash, and the rest in EPROMs. I'm sure it would work as well if I moved all to flash, and removed the EPROM chips. But that's what I want to avoid. I'd prefer to have everything in EPROMs, and use the flash board for something else (I'm using it in another system for similar purposes).

Have you tried using that HDD controller as a "16-bit ISA IDE in 8-bit mode" controller with XTIDE Universal BIOS? If the planets are all aligned it might just work.

I can give it a try, but I doubt it. The HDD controller uses data and IRQ lines from the 16-bit part of the ISA connector, which currently hangs in air.

BTW, I'm looking into the problem with the Hitachi microdrive. Is the drive size reported to be 39.19 MB on the 386 as well? Have you tried using another version of DOS just to make sure it's not a bug in DOS? If I were you I would be using MS-DOS 6.22 anyway to avoid bugs in 6.20.

No, on the 386 I can use a 2GB partition on it. But that's with a different revision of the XT-IDE BIOS, which I compiled about a year ago specifically for that machine. I don't remember which modules were included, but I'm sure it had 286 opcodes at least. I didn't try another version of DOS, because 6.20 is what I have (courtesy of work, a long long time ago). I'd be surprised if DOS were at fault since the same version is what I use on the 386.

 

[jh1523]

Have you tried using that HDD controller as a "16-bit ISA IDE in 8-bit mode" controller with XTIDE Universal BIOS? If the planets are all aligned it might just work.

Actually I have to take back my words from the previous post. It works!!! I'm seriously impressed. It appears to be even faster than the XT-CF card. It boots from the CF card, and from the 39.19MB microdrive. It does not boot from the other microdrive, the one that has a 2GB FAT16 partition. In fact with that one attached it doesn't even finish to POST. The XT-IDE BIOS probes for drives, recognizes the microdrive as master and doesn't find a slave drive, then freezes, doesn't even show the boot menu.

I have now removed the XT-CF card completely from the system, as its functions are superseded by the ISA flash/ROM card which holds the code, and the IDE controller from the multi-I/O card which contributes the physical interface.

This computer is becoming quite the hotrod. If only my EPROM trick worked, I'd be happy as a clam.


(BTW I configured the XT-IDE bios with "16-bit ISA IDE in 8-bit mode" and no interrupt FWIW)

 

[jh1523]

I am such an idiot. I found the problem. Now I have the XT-universal-IDE BIOS and the HD FDC BIOS all booting from the EPROM sockets, with no extra ROM cards used at all.

...the problem was that I was using 27C256 EPROM chips because I don't have any 27C64 available. They're pin-compatible, right? Right, except that the motherboard doesn't know they're 27256, so all the signals to all pins are sent as for 2764s. And so, pin 27 receives the signal intended for 2764's P which is always 1 while reading - but the 27256 interprets it as A14. And pin 26 which is not connected in the 2764 receives... who knows what from the motherboard, which is interpreted as A15 by the 27256. So depending on what the motherboard sends to those 2 pins, a different 8KB block of the 27256 chip gets selected and read. I had flashed only the first 8KB block of the EPROM with code, and evidently a different block was selected by the motherboard, and it was reading it correctly but it was blank.

The solution? Well, the obvious one would be to use 2764s. But I don't have any. So I mirrored the 8KB code 4 times, and flashed the resulting 32KB file in each EPROM. This way regardless of which block gets selected by the extra signals, the code will be there.

And it works.

I'm happy now.

I have one extra EPROM socket available for BIOS code. What should I use it for? Perhaps I'll save it for another day.

To sum it up, my system now comprises the following:
1.motherboard

2.CGA card

3.16-bit multi-IO card (inserted in an 8-bit connector), of which: the serial ports, parallel port work natively; the floppy controller works as high-density thanks to the FDC bios used in an EPROM at address F000:2000; the IDE controller works in 8-bit mode thanks to the XT universal IDE BIOS configured for generic 16-bit IDE in 8-bit mode, and placed in an EPROM at address F000:0000.

Nothing else attached now. I have another EPROM socket usable for 8KB of code at address F000:4000, currently empty. All the original BIOS chips are in their respective places and working as intended.

I will next await for all the parts the build the 1MB ISA RAM board using the PCB I received from lo-tech (Thanks, pearce_jj!), fill all that yummy empty UMBs, and then add some EMS with the 8-bit Rampage board I have, for a nicely tricked-out XT.

 

[jh1523]

Hmm. Wondering if I can map 2 copies of the XT universal IDE BIOS at the same time, one configured for the XTCF card, the other one for generic IDE controller. This way I could potentially use both at the same time. Why? Well, why not?

Or even better if I could have just one copy but configured for both, one primary and the other secondary.

(edit) it appears that you can configure up to 4 IDE controllers. But testing will have to wait for another day. If someone wants to test before I do here is the file: https://dl.dropboxusercontent.com/u/107843342/ide_xtc_configured_for_XTCF_and_8bitIDE.bin

When I get a chance I will also test a AHA-1542CF card (SCSI+floppy) as well as some of the many ISA VGA cards I have. Unfortunately I don't have documentation for any of the VGA cards so I don't know how/if any of them can be configured for 8-bit operation.

 

[Krille]

I think it should work if you combine the FDC BIOS with XTIDE Universal BIOS and then put the resulting file in the beginning of the free area of the system ROM.

For some reason I thought the system BIOS was on a 64 KB ROM. Sorry for the confusion.

Or even better if I could have just one copy but configured for both, one primary and the other secondary.

(edit) it appears that you can configure up to 4 IDE controllers. But testing will have to wait for another day. If someone wants to test before I do here is the file: https://dl.dropboxusercontent.com/u/107843342/ide_xtc_configured_for_XTCF_and_8bitIDE.bin

Yep, that's the way to do it. I loaded that file in XTIDECFG and it seems to be correctly configured. I haven't actually tried it though.

Regarding the problem with the Hitachi microdrive being 39.19 MB; I made a build of the latest revision using the same modules and options as your XT_Custom build and then put that on a ROM board in a 486 machine together with one of these drives. With the exception of the controller type being a standard 16-bit IDE there's no difference to your build. I then installed MS-DOS 6.22 and when using FDISK and FORMAT the true size of the drive is displayed. IOW, I can't reproduce this problem. I agree that it's unlikely that DOS 6.20 is the reason for this problem, I suggested using 6.22 for other reasons (some rather harrowing bugs that might lead to data loss in DOS 6.20).

When you configured the BIOS, did you use a version of XTIDECFG made from the same revision as the BIOS? If not, then that could be the reason.

 

[jh1523]

Regarding the problem with the Hitachi microdrive being 39.19 MB; I made a build of the latest revision using the same modules and options as your XT_Custom build and then put that on a ROM board in a 486 machine together with one of these drives. With the exception of the controller type being a standard 16-bit IDE there's no difference to your build. I then installed MS-DOS 6.22 and when using FDISK and FORMAT the true size of the drive is displayed. IOW, I can't reproduce this problem. I agree that it's unlikely that DOS 6.20 is the reason for this problem, I suggested using 6.22 for other reasons (some rather harrowing bugs that might lead to data loss in DOS 6.20).

When you configured the BIOS, did you use a version of XTIDECFG made from the same revision as the BIOS? If not, then that could be the reason.

I've actually solved that problem a while ago. I kept formatting and reformatting the microdrive with all kinds of fdisk/format programs, until the DOS fdisk saw its full size. I think the last thing I did before that was to use the Linux gdisk to wipe out the partition table. Now I have two 2GB and one 1.7GB DOS partitions on that drive.

 

[jh1523]

Uploading manuals of the motherboard, CGA card and multifunction card.


Motherboard manual scanned; has motherboard schematics at the end (not very good quality but readable; that's how they are printed, nothing I can do to improve quality)
https://dl.dropboxusercontent.com/u/107843342/xt/xt-golden-motherboard.zip

CGA card; has a large size (A3 I think) complete schematic. The schematic didn't fit in my scanner even folded in half, so I scanned it in 4 parts which can be pieced together.
https://dl.dropboxusercontent.com/u/107843342/xt/CGA card.zip

Multifunction card (RAM, serial, parallel, game, RTC). The manual references a series of utilities for managing the card; unfortunately I don't have them, and Google didn't help. Also includes schematics.
https://dl.dropboxusercontent.com/u/107843342/xt/MultiFunction.zip

Pictures of the cards:

CGA

Multifunction

 

[modem7]

Multifunction card (RAM, serial, parallel, game, RTC). The manual references a series of utilities for managing the card; unfortunately I don't have them, and Google didn't help. Also includes schematics.
https://dl.dropboxusercontent.com/u/107843342/xt/MultiFunction.zip

The manual for the multifunction card is a combined manual for the MF-100 card and its associated MFPLUS software suite.
The MF-100 is made by Diamond Flower Inc. (DFI).
The MFPLUS software is at [here].