Re: Software for MS-DOS 1.25

Hello!

Baltissen, GJPAA (Ruud) wrote:

> I run MS-DOS 6.22 on my PC20-III which is PC-XT compatible. Normally 3.3 would be a better choice because it uses less memory. Its disadvantage is that only supports FAT12 which means the maximum hard disk drive partition is 32 MB. My PC20 has an IDEXT card with an 8 GB HDD. And then 32 MB is rather small.

Let's say I will be worrying about it when I find a way to attach a 8 GB
hard disk to the 710 (and make it accessible from the 8088 side) ;-) I
think we shouldn't set the bar too high at the beginning, so it's MS-DOS
3.3 for now.

> Oops, just popped up in my mind: I replaced the PAL that controls the RAS/CAS signals to the DRAMs in an original IBM XT with a GAL and replaced the two banks of 4164 DRAMs with one row of 41256s. It now has the usual 640 KB plus 128 KB from 0D0000h to 0F0000h. A special program, USE!UMBS, enables me to use UMB on this XT. And thus profit from the extra memory available under the 640 KB limit when using 6.22.

IIRC, a similar method is used to upgrade the memory in the 710 to 1 MB,
correct?

> My first impression: you are absolutely right, what we really need could well fit in 4 KB. And chapeau for thinking of the 2364. But then: do we need to alter the ROM at all? I don't know what the original boot program exactly does but IMHO it loads IO.SYS and tells the 8088 to take over and start it. IO.SYS then sets the INT vectors. And IMHO it will overwrite the ones you set in ROM.

The problem here is that in MS-DOS, IO.SYS is loaded at a fixed location
starting from 0070:0000. I tried modifying the boot sector to load it
somewhere else and yet it's still relocating itself there.

So if we wanted to use the IO.SYS as is, then we would have to either
(a) fit all the code below segment 0070 (not possible) or (b) place the
code at the top of the RAM where it would be easily overwritten.

That's why I would like to place the code in the ROM on the card.
There's all this 3 kB of wasted space there ;-)

> If we are going to use MS-DOS 3.3 for example, I assume that we want to use it as-is meaning: we are going to use its original IO.SYS. And I am quite sure that the 3.3 version will change the INT 10h vector Because of some experiments in the previous century). You can check that your self by having a look at the vector: if it does not point to the original BIOS, it has been changed. And that has been done by IO.SYS AFAIK. So what ever DOS we are going to use, we have to create our own IO.SYS otherwise we sure will end up with a non-working system.

Yes, my goal is to use original, unmodified MS-DOS files.

I just booted MS-DOS in PCem and INT 10h stays the same. However, the
DOS patched INT 19h, INT 1Bh and INT 13h. The last one could be a
problem, I need to check what it does and why. However, I don't think
there should be a problem if we provide our own INT 13h implementation
that mimics the PC BIOS - whatever MS-DOS is doing, it should work on
top of the original API, right?

> Be aware: any program changing INT 10h (video), INT 16h (keyboard) or INT 13h (disk operations) will shut down our system (more or less). 

That's true. But there are much more programs that would not work anyway
because they access video memory. So I wouldn't worry about it  now.

> OK, I lost the track a bit: how did we get at this point again?

In short: We have a proof-of-work that it is possible to implement PC
BIOS INT interface by relaying calls to the 6509 code. The goal is to
make this implementation good enough so that we can boot later versions
of MS-DOS.

Regards,
Michau.

       Message was sent through the cbm-hackers mailing list