Re: Software for MS-DOS 1.25

Baltissen, GJPAA (Ruud) wrote:

> We could have a look at the source codes of MS-DOS 1.1, see what IO.SYS looks like and compare it with a disassembly of "our" IO.SYS..

We pretty much know what IO.SYS from 1.x does - in the beggining, it
contains a small jump table to a handful of functions to read/write a
disk sector, read/write console character etc. But I don't see we need
to duplicate this effort and write our own IO.SYS because...

> I teraz po Angielsko, proszę?

What I meant was that instead of writing our own IO.SYS, we can just use
the code from PC-DOS if we write correct interrupt implementations like
INT 13h, because (hopefully) the PC-DOS IO.SYS does not do any dirty
tricks on its own and just calls BIOS interrupts.

> Just my two cents: for the moment I would focus on the software that does everything according the book, thus using calling INTs to handle things. And software that used this "feature" appeared when there were hardly any non-compatible PCs to find. And that was late DOS 2.11 / early DOS 3.1. And DOS 2.0 had functions that certainly weren't supported by DOS 1.x. So IMHO the video RAM problem won't be the only problem you run into anyway. 

Well, that does not seem to be the case. For example, VisiCalc, one of
the first software written for the PC, accesses video memory directly.
So it seems that PC software did that from the very beginning.

I made Microsoft BASIC compiler work at this moment, as it does things
"by the book" by using INT 10h and INT 16h. Programs compiled with this
compiler work (for the most part - I still have some INT 10h functions
missing).

The big problem is that there is hardly any software for MS-DOS 1.x,
most requires 2.x and onward. And to use that we need to make MS-DOS 2
run first.

> Just to make sure that things won't get mixed up: in a PC with an ISA bus the hardware interrupts, IRQ0..7, are handled by the software interrupts INT 8h..0Fh.

I have no idea how the interrupt controller is programmed on the 8088
card - there is code in the EPROM which initializes it but I am not
familiar with the chip.

Anyway, a cursory look at the schematic tells me interrupts are signaled
routed to the 8259 chip this way:

IR0 - PB6 from the CIA on the card
IR1 - TOD clock
IR2 - 8087 FPU
IR7 - PB7 from the CIA

It makes sense that IR0 corresponds to INT 08h, the same way as on the
PC. I have then no idea what IR7 is for, but perhaps it could be used
for 6509 signaling the 8088 that some external event happened and it
should respond. Currently INT 0Fh is unused and the vector points to
0000:0000.

> In a PC this INT would handle the on board timer. The corresponding IRQ0 comes from the on board 8253 or 8254. OK, that won't hurt us you could assume. But the moment a piece of software hooks into INT 8h because it thinks its is hooking into the timer interrupt, we could run into trouble. Which on its turn means we cannot use any software depending on hooking into any INT in the range from 8 to 0Fh for the simple reason we don't have the hardware. 
> Hmmm, just a thought: can we direct a 6509 IRQ to the 8088 in one or another way? If that is possible, we can support INT 0Ah en 0Bh for the COM ports (read: 6551).

If you rewrote the 6509 part significantly, you could use INT 0Fh
instead of 08h (I say significantly, because IR0 is negated coming out
of the CIA while IR7 is not). But are there really many programs that
hook to INT 08h?

> Couldn't it be exactly what the original INT 13h does: handling access requests for a disk? In this case the request has to be forwarded to the 6509, just as you describe.

No. The code there is too simple - it just passes the value in AL to
6509 and calls it. You can't have an implementation of INT 13h using
just AL. Besides, what sense would it make to code an implementation of
INT 13h and leave out much more useful interrupts like INT 10h? Also,
several INT 13h semantics make even no sense on the Commodore (like,
"format track").

Just for the fun of it, I called INT 13h and the result was somewhat
unexpected - the disk drive started formatting my disk #0, which
happened to be of course my MS-DISK disk which I need now to image
again. That was quite annoying. My wild guess would be that the function
is meant to prepare a bootable disk, formatting it first. I think we can
safely ignore it.

Regards,
Michau

       Message was sent through the cbm-hackers mailing list