All but one TGI drivers didn't use IRQs. Especially when the TGI driver kernel was the only .interruptor this meant quite some unnecessary overhead because it pulled in the whole IRQ infrastructure.
The one driver using IRQs (the graphics driver for the 160x102x16 mode on the Lynx) now uses a library reference to set up a JMP to its IRQ handler.
All but one joystick drivers didn't use IRQs. Espsecially when the joystick driver kernel was the only .interruptor this meant quite some unnecessary overhead because it pulled in the whole IRQ infrastructure.
I was told that the one driver using IRQs (the DXS/HIT-4 Player joystick driver for the C64) can be reworked to not do it. Until this is done that driver is defunct.
So far the joy_masks array allowed several joystick drivers for a single target to each have different joy_read return values. However this meant that every call to joy_read implied an additional joy_masks lookup to post-process the return value.
Given that almost all targets only come with a single joystick driver this seems an inappropriate overhead. Therefore now the target header files contain constants matching the return value of the joy_read of the joystick driver(s) on that target.
If there indeed are several joystick drivers for a single target they must agree on a common return value for joy_read. In some cases this was alredy the case as there's a "natural" return value for joy_read. However a few joystick drivers need to be adjusted. This may cause some overhead inside the driver. But that is for sure smaller than the overhead introduced by the joy_masks lookup before.
!!! ToDo !!!
The following three joystick drivers become broken with this commit and need to be adjusted:
- atrmj8.s
- c64-numpad.s
- vic20-stdjoy.s
This change includes some cleanups, removal of mainargs.s (game console
programs never have arguments), and a workaround for a problem I'm seeing.
The problem is that sometimes (in fact, more often than not) the clrscr()
call in testcode/lib/joy-test.c writes some garbage chars on the screen (most
often a "P"). Could be my hardware (I haven't seen it on MAME), but to
me the root cause is still unknown.
Stefan Dorndorf, author of XDOS, pointed out that retrieving the
default device by looking at an undocumented memory location won't
work in future XDOS versions.
He also showed a way to get the default device in a compatible
manner.
This change implements his method and adds a version check (XDOS
versions below 2.4 don't support this -- for them the behaviour
will be the same as, for example, AtariDOS: no notion of a default
drive).
