• Please review our updated Terms and Rules here

8-Bit IDE Controller

Hi All,

I have a couple of questions for the XT IDE team. First, do you have an EDA like Eagle or KiCAD that supports the form factor for the XT card? KiCAD has the PC bus connector as a supported component but it still requires an "EDGES" outline of the PCB itself. Second, have you found a source for the PC card bracket connector? It has mount points which will affect the design of the PCB layout.

My suggestion is that if you already have some candidate PC cards as prototypes you could trace it to build the EDGES outline of the PCB and also determine the bracket mounting holes location.

The above things can be done by someone with no electronics experience or skills. All that would be required is getting a free EDA program and building the PCB outline. I recommend KiCAD although Eagle would work too. There are others like gEDA as well.

Next, do you have an example of the memory address decoding logic for the ROM? I see you have a ROM pin out but the most important pins (OE and CE) disappear into the bowels of an ASIC which tells you nothing about the actual actual decoding logic. It is probably pretty simple but it is important to capture the details if you'd like to add a ROM to the design. Check out the IBM technical reference for schematics to the CGA/MDA card since they contain onboard ROMs or possibly the original IBM XT hard drive controller to seperate out the address decoding logic. They have useful schematics there but there are probably others available.

Thanks and have a nice day!

Andrew Lynch
 
Yeah, I have both Eagle 5.2.0 and a proprietary package that both have a XT card layout and I have several cards that have screw-in backplanes although I'll have to look around to see what is available now.

Your suggestion of checking out the CGA/MDA cards is certainly a good one to see how they work the ROM into the design since I was wondering how someone was going to work out the "plug-in" points between "here" and "there".

As always, Andrew, thanks for your insight.
 
Your suggestion of checking out the CGA/MDA cards is certainly a good one to see how they work the ROM into the design since I was wondering how someone was going to work out the "plug-in" points between "here" and "there".

CGA and MDA wouldn't help, because they don't map their ROMs into the PC's memory space. EGA or a real hard drive controller would.
 
The schematic for one of the variations of the 10MB Xebec controller for the 5150/5160 is at:
http://members.dodo.com.au/~slappanel555/misc/IBM_Xebec_fixed_disk_adapter.pdf

That board has an 8KB ROM at C800:0

In that schematic, the ROM is designated 12J and is in the top-left corner of sheet 1.
You can see that the decode for the ROM's CE pin is done by a single chip, 11J, a 74LS688.

If you wanted to use that part of circuitry as is but instead use the first 8KB of a 27256 EPROM:
1. On the 27256, tie VPP to VCC and tie /CE to ground (both actions put the 27256 into READ mode)
2. On the 27256, tie all unused address pins to ground.
3. Tie pin 19 on the 74LS688 to the 27256's /OE pin
 
Hello guys what happened to idea it did seem great but suddenly not a word, did it just roll over an die?

Will you implement DDO code for the bios?
Will it will be 8086 code.

DDO - Yes. The finished BIOS will support drives up to 137G, using 28bit addressing.
Your operating system is however the next limitation of addressable space.

8086 code - yes. well, 8088 code, but no 32bit registers will be used.

The original BIOS that I disassembled came from an acculogic IDE controller which was PC/XT compatible. IMO, it's poorly written and I've even found a couple minor bugs. I've been slowly re-writing it and I've added the enhanced INT13 support that we need to do big drives, and my big plan for the holiday weekend here is to port it over to a DOS TSR and see if I can make my own "disk manager" type driver that you could use on any machine to upgrade INT13 up to 137G. It'll all be open source and if things go well, available here for download by monday!
 
The schematic for one of the variations of the 10MB Xebec controller for the 5150/5160 is at:
http://members.dodo.com.au/~slappanel555/misc/IBM_Xebec_fixed_disk_adapter.pdf

That board has an 8KB ROM at C800:0

In that schematic, the ROM is designated 12J and is in the top-left corner of sheet 1.
You can see that the decode for the ROM's CE pin is done by a single chip, 11J, a 74LS688.

If you wanted to use that part of circuitry as is but instead use the first 8KB of a 27256 EPROM:
1. On the 27256, tie VPP to VCC and tie /CE to ground (both actions put the 27256 into READ mode)
2. On the 27256, tie all unused address pins to ground.
3. Tie pin 19 on the 74LS688 to the 27256's /OE pin

wow, that's good stuff!
How do we implement selectable addressing via jumpers? Is it really as simple as having jumpers to break/connect other address lines, or is there other logic behind that? Ideally, it would have a minimum of 4 different addresses available, from C800-E000 or so. All my poking on my SCSI card only showed me that the jumpers end up at an ASIC, so that's no good.
 
DDO - Yes. The finished BIOS will support drives up to 137G, using 28bit addressing.
Your operating system is however the next limitation of addressable space.

8086 code - yes. well, 8088 code, but no 32bit registers will be used.

The original BIOS that I disassembled came from an acculogic IDE controller which was PC/XT compatible. IMO, it's poorly written and I've even found a couple minor bugs. I've been slowly re-writing it and I've added the enhanced INT13 support that we need to do big drives, and my big plan for the holiday weekend here is to port it over to a DOS TSR and see if I can make my own "disk manager" type driver that you could use on any machine to upgrade INT13 up to 137G. It'll all be open source and if things go well, available here for download by monday!

The 8088 instruction is EXACTLY the same as 8086, the hardware timing is the only difference.

As for Int 13h, Will DOS (talking of version 2.1 to 3.1) support drives up to 137GB as well, or does it need a patch?
 
wow, that's good stuff!
How do we implement selectable addressing via jumpers? Is it really as simple as having jumpers to break/connect other address lines, or is there other logic behind that? Ideally, it would have a minimum of 4 different addresses available, from C800-E000 or so. All my poking on my SCSI card only showed me that the jumpers end up at an ASIC, so that's no good.

Hi! Just adjust the reference side of the 74LS688 8 bit comparator. It appears the A side is the for the address bus and the B side is the preprogrammed address setting. Put three way jumpers on the B side pins to set their levels to either HIGH or LOW depending on what the address is you are specifying for the ROM to appear at. When the upper address bits appear on the address bus, the 8 bit comparator will "trigger" sending a /CS signal to the ROM (OE and CE).

Thanks and have a nice day!

Andrew Lynch

PS, thanks for the catch on the CGA/MDA. You are correct as they have character generator ROMs only. I was thinking EGA/VGA with its BIOS ROM resident in main memory and misspoke.
 
The 8088 instruction is EXACTLY the same as 8086, the hardware timing is the only difference.

IIRC, POP CS (at a minimum) works on an 8086 and not much else, but there's no such thing in any of my code!

As for Int 13h, Will DOS (talking of version 2.1 to 3.1) support drives up to 137GB as well, or does it need a patch?

http://en.wikipedia.org/wiki/Comparison_of_x86_DOS_operating_systems
(2nd table)

Nope. old MS/IBM DOS versions will only do 32MB partitions.
you'll want to switch to freedos or DR-dos 7 to do a bigger partition, although I'm not sure if those run on anything less than a 32bit CPU. It's an interesting problem that we're going to want to find the best DOS that supports big hard drives and still runs on an 8088!

I suppose at a minimum, DOS 4.01 with many 2G partitions could be fun.
I doubt I will put anything bigger than a 10gig drive in my machine.
 
IIRC, POP CS (at a minimum) works on an 8086 and not much else,

I know, but it works on the 8088 too! It wasn't removed until 80186/80188. The only difference is the input/output controll part of the architecture.

but there's no such thing in any of my code!

That's nice. It isn't really usefull because it is a lot better to use normal far jumps. The problem is: you can only get to a multiply of 16 bytes to/from the adress of the instruction AFTER the "POP CS" instruction. It's worser than using IRet to pop the flags.
 
Last edited:
DDO - Yes. The finished BIOS will support drives up to 137G, using 28bit addressing.
Your operating system is however the next limitation of addressable space.

8086 code - yes. well, 8088 code, but no 32bit registers will be used.

The original BIOS that I disassembled came from an acculogic IDE controller which was PC/XT compatible. IMO, it's poorly written and I've even found a couple minor bugs. I've been slowly re-writing it and I've added the enhanced INT13 support that we need to do big drives, and my big plan for the holiday weekend here is to port it over to a DOS TSR and see if I can make my own "disk manager" type driver that you could use on any machine to upgrade INT13 up to 137G. It'll all be open source and if things go well, available here for download by monday!

Almost seem to good, i wish you all success with the project. Look forward to try the TSR out on my ADP50L. (I have backup on CF)

When DDO is installed does that mean OS utilities like "fdisk", "scandisk" "chkdsk" recognize a bigger driver or must you prepare and format the drive from another HD? Will you post a compiled version of the TSR or just source code?

JT
 
Almost seem to good, i wish you all success with the project. Look forward to try the TSR out on my ADP50L. (I have backup on CF)
Last night I got it working to the point where it ID's a master and slave drive, prints the model # to the screen, stores the drive's parameters internally, and installs the INT 13 handler. I verified that the floppy access via INT 13 still works as expected, and saw the first call from FDISK enter my code. (that's when I stopped for the night)
...and I wasn't even expecting to start working on things until wednesday!

When DDO is installed does that mean OS utilities like "fdisk", "scandisk" "chkdsk" recognize a bigger driver or must you prepare and format the drive from another HD?
JT
It's up to the software itself to call the enhanced INT13 functions to see larger drives. Essentially there are now 2 copies of INT13. Software that knows about bigger drives can call the big routines, and older software calls the old routines. fdisk from dos 4.01 won't see the whole drive. fdisk from windows98 will.

I don't really know how everything is going to work out in the end, but in a perfect world, you should be able to take a newer copy of DOS, setup a brand new hard drive on your XT, pull that drive out and move it over to your P4 machine and it should see your partitions just fine. That's what I'm shooting for anyway.

here's the specification:
http://www.phoenix.com/NR/rdonlyres/9BEDED98-6B3F-4DAC-BBB7-FA89FA5C30F0/0/specsedd11.pdf

It came out in 1995, so the problem now is that at the end of the day, we want to run this on old machines, using software written before 1995.
So I think that DOS should be fine running on a big drive, stuff like norton utilities or other software written pre-1995 could choke. We'll see! (and maybe make some compatibility lists too.)


The first big question is what is the best version of DOS to run on an 8088 machine, which provides the greatest forward compatibility to other O/Ses, and supports drives as big as possible, and doesn't break old applications like PCtools and Norton. I don't have an answer yet-maybe others can chime in?


Will you post a compiled version of the TSR or just source code?
Both. I don't expect people to have access to everything required to compile it, including the desire to, so I'll release everything and a nice readme on how to get it installed on a typical machine for each release I do.

This first release is PIO only, no DMA, no IRQs, no CD-ROM support, 2 drives maximum, standard IDE controller only. Future releases will expand upon that.
 
The first big question is what is the best version of DOS to run on an 8088 machine, which provides the greatest forward compatibility to other O/Ses, and supports drives as big as possible, and doesn't break old applications like PCtools and Norton. I don't have an answer yet-maybe others can chime in?

There are several, but my vote goes to IBM PC DOS 2000, if anything for the Y2K fixes.

BTW, there's no way to avoid breaking PCTools and Norton, unless you're using Norton Utilities 8, the last version released for DOS. 8 is the only one I would trust with large drives and long filenames -- earlier versions of both PC and N fail on such things miserably because they were created before such things existed.
 
Last edited:
There are several, but my vote goes to IBM PC DOS 2000, if anything for the Y2K fixes.

I think my old PC-Xtra did came with IBM dos 1.0, i have the feeling that the sys files and command.com take longer to load on DR-DOS, MS-DOS.

Could it be that the extra functionality make a heavier load on an old xt, and what about the system size?

How much space take PC DOS 2000 compared with IBM DOS 1.0, if i only had the helper application functionality provided from the never versions. I would go for a real old dos, because XT with IBM DOS 1.0 was fast.

JT
 
I think my old PC-Xtra did came with IBM dos 1.0, i have the feeling that the sys files and command.com take longer to load on DR-DOS, MS-DOS.

Could it be that the extra functionality make a heavier load on an old xt, and what about the system size?

How much space take PC DOS 2000 compared with IBM DOS 1.0, if i only had the helper application functionality provided from the never versions. I would go for a real old dos, because XT with IBM DOS 1.0 was fast.

JT

The difference is rather huge... PC DOS 2000 has many many MANY times the feautres of DOS 1.0 (talking about number of Int 21h functions)

*Edit*
The version of DOS you have doesn't really mater for the speed of your computer. The only thing DOS does is to use some RAM and provide usefull functions for programmers. DOS leaves all CPU power to the program executed, so then DOS acts like a normal TRS driver. The program has to return controll to DOS with an "Int 20h" (or "RET" with the word "0000" at the top of the stack). A custom program can compleetely take over controll of your computer and set up it's own Operating system over DOS in RAM. This is partly how earlier versions of Windows works.


Minimum System requirements for PC DOS 1.0:
1 IBM PC or compatible with Mono/CGA compatible monitor with adapter
1 Single Sided Double Density Floppy Disk Drive (5.25")
16Kb of RAM (more for big programs)

Minimum System requirements for PC DOS 7.0 (2000):
1 IBM PC or compatible with Mono/CGA compatible monitor with adapter
1 Double Sided High Density Floppy Disk Drive (3.5")
1 Hard Disk Drive with at least 6Mb of free space
512Kb of RAM
 
Last edited:
I think my old PC-Xtra did came with IBM dos 1.0, i have the feeling that the sys files and command.com take longer to load on DR-DOS, MS-DOS.

Could it be that the extra functionality make a heavier load on an old xt, and what about the system size?

PC DOS 2000 boots nicely on my 4.77MHz 8088 XT. The only drawback with most DOSes that support large drives (ie. MS-DOS 6.x and later, IBM PC-DOS 7.x, FreeDOS) is that the first time you do a DIR, it takes between 14-20 seconds to return. After that it's fine. No idea why the first DIR takes a while.

How much space take PC DOS 2000 compared with IBM DOS 1.0, if i only had the helper application functionality provided from the never versions. I would go for a real old dos, because XT with IBM DOS 1.0 was fast.

The point of this exercise is to get a DOS that supports hard drives. DOS 1.0 does not support hard drives, nor most functionality that people actually need (subdirectories, for one).

PC DOS 2000 takes up around 7MB; MS-DOS 6.22 and DR-DOS 7.03 both take up around 4mb.
 
PC DOS 2000 boots nicely on my 4.77MHz 8088 XT. The only drawback with most DOSes that support large drives (ie. MS-DOS 6.x and later, IBM PC-DOS 7.x, FreeDOS) is that the first time you do a DIR, it takes between 14-20 seconds to return. After that it's fine. No idea why the first DIR takes a while.

The point of this exercise is to get a DOS that supports hard drives. DOS 1.0 does not support hard drives, nor most functionality that people actually need (subdirectories, for one).

PC DOS 2000 takes up around 7MB; MS-DOS 6.22 and DR-DOS 7.03 both take up around 4mb.

I was more thinking about the memory space for the resident system files.

Ok i did not know that 1.0 didn't support HD and directories was along time since i used it.

JT
 
Dos 6.22

Dos 6.22

Hi Gang !

Good to see the IDE XT controller is "progressing". :mrgreen:

My 7¢ worth on the DOS version: I find DOS 6.22 to work very well on an XT. DOS 5 is also very good, but DOS 6.22 has almost all of the features that a person would want, and doesn't seem to need much overhead to perform.

Anyone remember the "Graphics Menu for DOS" ? It was a fantastic little *GUI* program that would fit on a 720k disk, and had a lot of great features. Very advanced for such a small program, allowed the use of a mouse, and in my humble opinion, one of the best GUI's for an ancient 10MHz or lower computer.

Happy Thanksgiving gang !

bobwatts
EartH
 
Back
Top