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.
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
About all CONIO functions offering a <...>xy variant call
popa
_gotoxy
By providing an internal gotoxy variant that starts with a popa all those CONIO function can be shortened by 3 bytes. As soon as program calls more than one CONIO function this means an overall code size reduction.
The constructors are _NOT_ allowed anymore to access the BSS. Rather they must use the DATA segment or the INIT segment. The latter isn't cleared at any point so the constructors may use it to expose values to the main program. However they must make sure to always write the values as they are not pre-initialized.
The name RAM doesn't make much sense in general for a memeory area because i.e. the zero page is for sure RAM but is not part of the memory area named RAM.
For disk based targets it makes sense to put the disk file more into focus and here MAIN means the main part of the file - in contrast to some header.
Only for ROM based targets the name RAM is kept as it makes sense to focus on the difference between RAM and ROM.
The way we want to use the INITBSS segment - and especially the fact that it won't have the type bss on all ROM based targets - means that the name INITBSS is misleading. After all INIT is the best name from my perspective as it serves several purposes and therefore needs a rather generic name.
Unfortunately this means that the current INIT segment needs to be renamed too. Looking for a short (ideally 4 letter) name I came up with ONCE as it contains all code (and data) accessed only once during initialization.
So far the INIT segment was run from the later heap+stack. Now the INIT segment is run from the later BSS. The background is that so far the INIT segment was pretty small (from $80 to $180 bytes). But upcoming changes will increase the INIT segment in certain scenarios up to ~ $1000 bytes. So programs with very limited heap+stack might just not been able to move the INIT segment to its run location. But moving the INIT segment to the later BSS allows it to occupy the later BSS+heap+stack.
In order to allow that the constructors are _NOT_ allowed anymore to access the BSS. Rather they must use the DATA segment or the new INITBSS segment. The latter isn't cleared at any point so the constructors may use it to expose values to the main program. However they must make sure to always write the values as they are not pre-initialized.
Up to now static drivers were created via co65 from dynamic drivers. However there was an issue with that approach:
The dynamic drivers are "o65 simple files" which obligates that they start with the 'code' segment. However dynamic drivers need to start with the module header - which is written to. For dynamic drivers this isn't more than a conceptual issue because they are always contain a 'data' segment and may therefore only be loaded into writable memory.
However when dynamic drivers are converted to static drivers using co65 then that issue becomes a real problem as then the 'code' segment may end up in non-writable memory - and thus writing to the module header fails.
Instead of changing the way dynamic drivers work I opted to rather make static driver creation totally independent from dynamic drivers. This allows to place the module header in the 'data' segment (see 'module.mac').
This change was suppsed to fix the issue that the former JUMPTABLE is merked as 'ro' while it is actually written to in several scenarios. When drivers are converted using co65 and then compiled into ROMs the JUMPTABLE isn't copied to RAM and therefore the write operations in question fail.
However unfortunately I didn't succeed in changing that :-( Just setting the former JUMPTABLE to 'rw' broke the drivers. So I placed the DATA segment directly after the former JUMPTABLE segment. This made the drivers converted with co65 work again - obviously after changing libsrc/Makefile:235 from '--code-label' to '--data-label'. But the actual dynamic drivers still didn't work as the former JUMPTABLE wasn't placed as the beginning of the loaded file anymore. That effect could be changed by exchanging src/ld65/o65.c:1391 with src/ld65/o65.c:1394 but doing so broke the drivers again :-((
The Apple2 doesn't have sprites so the Apple2 mouse callbacks place a special character on the text screen to indicate the mouse position. In order to support the necessary character removing and redrawing the Apple2 mouse driver called the Apple2 mouse callbacks in an "unusual way". So far so (sort of) good.
However the upcoming Atari mouse driver aims to support both "sprite-type" mouse callbacks as well as "text-char-type" mouse callbacks. Therefore the interface between mouse drivers and callbacks needs to be extended to allow the mouse callbacks to hide their different types from the mouse driver.
The nature of this change can be seen best by looking at the Apple2 file modifications. The CBM drivers and callbacks (at least the current ones) don't benefit from this change.
The mouse reference is a pointer. If it's NULL, the driver uses a default. If it's non-NULL, then it points to a function that the driver can call. That function will adjust the driver's calibration value. It could ask the user to adjust the pen; or, it could read a file that holds a value from a previous calibration.
Application writers can choose how it's done: a function that's provided by the library, a custom function, or nothing.
Occasionally dynamically drivers suffer from not being to refer to
content in the C library. Therefore I added a mechanism to allow
a C library for a certian target to define a symbol that will be
handed over to dynamic drivers for that target. Then the drivers
can use their refernce to that symbol to access content in the C
library.
They use the mouse driver programming interface.
Added a test program for lightpen drivers. Now, it knows about only those two drivers; it will need updating when others are added.
- No complex shell logic.
- "Source file shadowing" for all targets via vpath.
- Dependency handling.
- True incremental build.
- Don't write into source directories.
- Easy cleanup by just removing 'wrk'.
- No complex shell logic.
- "Source file shadowing" for all targets via vpath.
- Dependency handling.
- True incremental build.
- Don't write into source directories.
- Easy cleanup by just removing 'wrk'.
Moved getdevice.s from 'c64'/'c128' to 'cbm' making use of the new 'ST' setup.
git-svn-id: svn://svn.cc65.org/cc65/trunk@5834 b7a2c559-68d2-44c3-8de9-860c34a00d81
consequence it didn't work when write(FILENO_STDOUT, ...) was used. So we will
have to disable scrolling on a per character basis in cputc.
git-svn-id: svn://svn.cc65.org/cc65/trunk@4617 b7a2c559-68d2-44c3-8de9-860c34a00d81
kernal routine does not work, when the cursor is not at the same position
where it was switched on, because when switching it on, the kernal remembers
the character attribute and restores this when switching it off. So characters
may get the wrong attribute. The solution is to always switch the cursor on,
before switching it off.
git-svn-id: svn://svn.cc65.org/cc65/trunk@4592 b7a2c559-68d2-44c3-8de9-860c34a00d81
cleared, which in turn causes the display to scroll when a character is output
in the lower right corner.
git-svn-id: svn://svn.cc65.org/cc65/trunk@4590 b7a2c559-68d2-44c3-8de9-860c34a00d81
Machines with RAM in pages 2+3 are quite rare, so it's better to have the
additional code+features in a separate driver.
git-svn-id: svn://svn.cc65.org/cc65/trunk@4575 b7a2c559-68d2-44c3-8de9-860c34a00d81
Note: Originally I planned to create a module to be linked to the driver. However this turned out to cause quite some issues with the Makefiles - especially on the Apple2 where one driver uses to generic LINE implementation and the other doesn't. The final Makefile was so ugly that I rather opted for including the code in question on source level. In order to avoid to unwanted cross dependencies the whole .inc file content is wrapped in its own scope.
git-svn-id: svn://svn.cc65.org/cc65/trunk@4553 b7a2c559-68d2-44c3-8de9-860c34a00d81
named EXEHDR.
* Renamed BASICHDR to EXEHDR for the PET-II machines.
* Moved the call to CHRCH in front of the code that saves the zero page, since
open files are sometimes remembered in the zero page, so we need to close
them before we grab a copy.
git-svn-id: svn://svn.cc65.org/cc65/trunk@4507 b7a2c559-68d2-44c3-8de9-860c34a00d81
