Re: [MiNT] XBIOS function bending

[Michael Schwingen <rincewind@discworld.dascon.de>]

On Thu, Dec 30, 1999 at 08:42:37PM +0000, Vincent Barrilliot wrote:
> 
> Yes I understand your position. But making things like this make the TOS
> not easily expandable because for the slightest thing you need to patch
> the whole trap. Here is my explanation :
> I thing that _KBDVECS struct is called like this because it contains the
> functions used by the KEYBOARD interrupt of the MFP. So far, it only
> contains functions which deal with received bytes. It is because BIOS does
> not manage interrupt driven byte sending to MIDI and keyboard ACIAs.
> 
> But if you wanted to improve BIOS to give it this feature, would you
> put the vectors of the fonctions (that would also use the KEYBOARD interrupt
> of the MFP) somewhere else from the _KBDVECS ? no, I think. So you would
> like to be able to add fields in the _KBDVECS, it means create a struct
> somewhere else in the memory and modify a documented variable (which value
> would be returned by Kbdvbase).
> That's why I think BIOS/XBIOS functions should rather rely on the Kbdvbase(), 
> (or at least a documented vector) and shouldn't make free asumptions. It's not
> up to the Bconxxx or Midiws() to decide where is the _KBDVECS.

If *I* were to expand the TOS, I would either expand Kbdvecs or use some
other place for the vectors.

As long as there is no documented standard for this, you do not gain
anything by expanding Kbdvecs - you can place your vectors anywhere, since
noone will know they are there, and noone can detect that you have expanded
Kbdvecs, so why worry? You can achieve the same result without moving
Kbdvecs.

> Sorry, I didn't mentionned the vectors. They are bconout_vec $57e+12 and
> bcostat_vec $55e+12 (+12 because MIDI=device 3). They are the legal routs for 
> sending midi bytes. It might be midiwc or something else, anyway it's not up
> to Midiws to decide of it.

Yes, it is. I repeat myself: Midiws and Midiwc are Xbios functions, so they
can't use BIOS vectors. After all, the Bios vector you mention calls Midiwc
(in the XBIOS)!

> Parts of code are shared between XBIOS and BIOS. Part of the trap handler
> itself is common. Now I think the routs for sending/receiving (I/O) bytes on
> 'standard' devices typically belong to BIOS.

Partly.

First, sharing code does not mix the OS layers - think about common code
like memcpy which may be called from everywhere. The same is true for common
parts in the trap handlers. Apart from that, there is not much in common,
besides that BIOS heavily calls into XBIOS to do its task.

> I think XBIOS is more specific to atari chips :
> access to floppy, video & serial settings, DSP transfer ...
> If Bconxx routs are exclusively using XBIOS routs, I don't understand why
> they are in BIOS. It would also mean that BIOS is a layer higher than XBIOS,
> which is wrong as far as I know.

No, BIOS *is* above XBIOS. The Bcon* vectors point to the corresponding
routines in XBIOS (or VDI), Rwabs calls Floprd/Flopwr to get its work done
etc..

> Actually I think that Midiws would rather be in GEMDOS. Regarding the way

No, because then it would be called Fwrite.

As it is, Midiws is quite useless in XBIOS, because you have to directly
call it, bypassing all higher OS layers, while the higher layers can't make
any use of it, because BIOS only knows about single characters, and not
about strings.

> than to XBIOS. Then maybe you would accept that a GEMDOS Midiws() must use BIOS 
> bconxx_vec.

No. A Gemdos Fwrite on the MIDI device would have to call the corresponding
BIOS function, and *that* would use the Bcon*-vec. Gemdos (or MiNT) can't
use these vectors for the same reason: they belong to BIOS.

> I didn't. I wrote my own Bconstat(3) and Bconout(3) and wrote their adress
> in the relevant bconxxx_vec. I also wrote my own _KBDVECS->midisys to handle
> MIDI 'transmit' interrupts and that's all. The XBIOS Midiws() still uses
> the old rout (midiwc) as it doesn't look at the bconxxx_vec, but it's its fault,
> and instead of hooking the XBIOS trap, I prefer trying to implement a
> similar function in the relevant place, ie GEMDOS, trough a XDD for FreeMiNT.

No, it's not the XBIOS' fault if you get mangled byte sequences (which will
happen if you mix calls to Midiws and BIOS to output MIDI bytes). If you
want to replace output to MIDI, you have to replace all routines that do
that, and since the XBIOS ones can be called directly, bypassing the BIOS,
you have to take appropriate actions.

> Yes, it would speed up things on slow machines. But I think sending many bytes 
> is more relevant to GEMDOS. Frank's XDD UART Driver for Milan seems to work
> at 11.5KB/s without problem, and it has the advantage that FreeMiNT can lock
> used devices etc, which is impossible with BIOS.

Right. However, if there were a BIOS function to read/write multiple bytes,
then Gemdos could actually *use* these, which would remove a bit of trap
overhead (plus overhead in the lowlevel driver) for every character (in cases
where BIOS is actually called, which is not the case with the UART driver).

Doing everything in one place is a good approach if it can be done in a
clean way (like in the UART driver). If you were implementing a MIDI device
driver for MiNT, you could forget about all the BIOS vectors etc. - you
would *only* hook into the receive vector in Kbdvbase (and that only because
of the shared ACIA interrupt).

However, it seems that you want to stay compatible to TOS for at least the
calling of the MIDI Bios/XBios functions, and that means that you have to
play by TOS's rules to stay compatible. If you don't need compatibility,
then do it the clean way and write a MiNT driver.

cu
Michael
-- 
Michael Schwingen, Ahornstrasse 36, 52074 Aachen