Re: [MiNT] XBIOS function bending

[barrilli@club-internet.fr (Vincent Barrilliot)]

Hi Michael,

> Which is absolutely correct - since there is only a function to query the
> location of _KBDVECS, but none to set it, it can not be moved, so TOS knows
> where to look. Also, for a single struct of known, constant size, there would
> not be any benefit if you could move it somewhere else - after all, you can
> replace all the vectors in it, which is sufficient.

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.

> Which ones? Midiws jumps directly to midiwc which writes the byte to the

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.

> As for the BIOS vectors: Midiws can't use these, because it is a *X*Bios
> function. The BIOS uses the BIOS vectors (at $5xx) when using Bconout() on
> the Midi device, and then calls the corresponding XBIOS function to get the
> work done.

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.
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.

Actually I think that Midiws would rather be in GEMDOS. Regarding the way
devices are managed under FreeMiNT, writting several bytes to a file or a 
device -but it's not too different for FreeMiNT- is more relevant to GEMDOS 
than to XBIOS. Then maybe you would accept that a GEMDOS Midiws() must use BIOS 
bconxx_vec.

> The point is: if you want to replace the low-level MIDI handling stuff to
> use transmit interrupts, you need to replace the corresponding XBIOS fonctions

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.

> Unfortunetely, there is no BIOS function to read/write multiple characters
> from/to a device - this would be helpful for serial ports, too.

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.

Vincent