* The 16-bit comparison code actually didn't compare the high byte.
* This implementation supports only the 1541, 1571, and 1581; but, it didn't exclude the other drive types that GEOS supports.
* Two error code numbers were swapped.
* A 1571 converter didn't catch sector numbers that are too high.
* A 1581 converter didn't catch sector numbers that are too high.
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.
The Apple II linker configs don't define symbols for the STARTP segment anymore. There refer to the load/start address in the same way the executable file header does.
This function is used by many other CONIO functions, and the user program not
necessarily uses 'cgetc'. Having "setcursor" in a different object file saves
space in this case and also allows the user program to override it (e.g. when
not using GRAPHICS 0 mode).
As discussed in https://github.com/cc65/cc65/pull/452 after my premature merge the two functions in question don't work as expected.
Additionally I adjusted several style deviations in the pull request in question.
Please note that this change is absolutely untested!
Apart from the recent driver interface change:
- vic20-stdjoy.s was "slightly broken" because it didn't clear x on return from joy_read.
- vic20-ptvjoy.s was "heavily broken" because it returned a totally different set of bits of the first joystick.
The change is inspired by the code of the standard joystick driver. It is however absolutely untested.
Note: Sites like http://raster.atariportal.cz/english.htm state that there needs to be a delay when reading joysticks via the MultiJoy adapter. There's no such delay in the driver. But I don't dare to decide to add it.
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
Some of the files in "libsrc/*/extra/" include other library files. But, the "lib/*.o" files weren't rebuilt when those other files changed.
The new dependency rules must be "bootstrapped". You must force a rebuild of all of the extra library object files (it will create the dependency files). Use these commands:
rm lib/*.o
make lib
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.
The configuration file and runtime (crt0.s) provided for the default NES
ROM layout (2x16k PRG, 8k CHR) incorrectly added interrupts (IRQ1, IRQ2,
TIMERIRQ) which are not supported by the NES hardware. For example, see
the NESdev wiki, which makes no reference to these interrupts.
https://wiki.nesdev.com/w/index.php/CPU_memory_map
The VECTORS region was also incorrectly set to 0xFFF6, which would have
left the 0xFFF4 normally unspecified. This did not result in any error,
however, since cc65 simply placed ROMV directly after ROM0 regardless of
start address.
(This layout may be due to a copy-and-paste from the PC-Engine
configuration, whose interrupt registers start at 0xFFF6, begins with
the three interrupts listed above, followed by NMI and START, and does
not end with a final IRQ interrupt.)
Despite the absence of any actual error, since START is still placed at
0xFFFC, this patch removes the nonexistent interrupts and also correctly
aligns the ROM0 and ROMV regions. It also has the (admittedly very
minor) benefit of freeing up 6 additional bytes for ROM0.
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).
For quite some time I deliberately didn't add cursor support to the Apple II CONIO imöplementation. I consider it inappropriate to increase the size of cgetc() unduly for a rather seldom used feature.
There's no hardware cursor on the Apple II so displaying a cursor during keyboard input means reading the character stored at the cursor location, writing the cursor character, reading the keyboard and finally writing back the character read initially.
The naive approach is to reuse the part of cputc() that determines the memory location of the character at the cursor position in order to read the character stored there. However that means to add at least one additional JSR / RTS pair to cputc() adding 4 bytes and 12 cycles :-( Apart from that this approach means still a "too" large cgetc().
The approach implemented instead is to include all functionality required by cgetc() into cputc() - which is to read the current character before writing a new one. This may seem surprising at first glance but an LDA(),Y / TAX sequence adds only 3 bytes and 7 cycles so it cheaper than the JSR / RTS pair and allows to brings down the code increase in cgetc() down to a reasonable value.
However so far the internal cputc() code in question saved the X register. Now it uses the X register to return the old character present before writing the new character for cgetc(). This requires some rather small adjustments in other functions using that internal cputc() code.
The final part of exec() called 'excexit' and only then restored the
stack pointer to its value at program entry. 'excexit' does all
cleanup (the same as '_exit()'), which means that on the atarixl
target the ROM is banked in again. On big programs the 'SP_save'
variable might reside at a high memory address which is no longer
accessible after the ROM has been banked in.
The change just moves the restoration of the stack pointer before
the call to 'excexit'.
Another change lets exec.s compile if UCASE_FILENAME is not defined.
And some other small cleanups, also in open.s.
