remove redundant code and add jmp to the common sequence
two more bytes could be saved at the expense of longer sequence with interrupts disabled by moving sei/cli
The target util convert.system is to be used in conjunction with GEOS on the Apple II but has to be built as an "ordinary" Apple II program. The way the cc65 library build system is designed there's no way to define dependencies between targets. The solution used so far was to explicitly trigger a build of the target 'apple2enh' from the target 'geos-apple'. However, that approach tends to break parallel builds which may be in the middle of building 'appple2enh' at the time it is triggered by 'geos-apple'.
There might be ways to get this fixed - but the the cc65 library build systrem is already (more than) complex enough, so I really don't want to add anything special to it.
On the other hand there are easier ways (outside the scope of cc65) to archive what convert.system does so I don't presume convert.system to be actually used - it's more a reference type of thing.
Putting all facts together the decision was easy: Just move convert.system from the target it is used with to the target(s) it is built with.
Certain scenarios (e.g. not running any Applesoft program at all since booting DOS 3.3) can make DOS 3.3 consider cc65 device input (e.g. getchar()) that reads a CR interpreting the command in the keyboard buffer. Setting the hibyte of the Applesoft currently executed line number to some value <> $FF (beside setting the input prompt to some value <> ']') makes DOS 3.3 understand that we're not in intermediate mode and that therefore I/O not preceded with ctrl-d mustn't be fiddled with (see DOS 3.3 routine at $A65E).
ca65's logical (Boolean) NOT operator was used where bitwise NOT should be used. The effect was that all sprites were shifted to the left side of a screen when the mouse sprite was put on the left side.
* Docs say that CLK_TCK is an obsolete alias of CLOCKS_PER_SEC so there's no point in individual definitions.
* All targets determining the clock rate at runtime can use a common handling.
* rand() use XOR to break up unwanted pair correlation
This form of rand() cannot return the same value twice in a row.
Two additonal EOR instructions produce a more even distribution of successive pairs.
see comments on #951
* rand.s document purpose of XOR
* suggested srand() optimization: zero fill unnecessary
* test to validate implementation of rand()
* srand() improving behaviour and adding startup test
* srand() with a tail call to rand() for better initial shuffle
* srand() can fall through to rand() instead of tail call
Please refer to https://github.com/cc65/cc65/pull/532 for background info.
I wrote in https://sourceforge.net/p/cc65/mailman/message/35873183/
===
cputs() wraps to the next line if the strings is too long to fit in the current line. I don't know if it's worth the effort to allow cpeeks() to continue reading from the next line. I'd like to discuss this aspect with the actual implementers.
===
This is still as unclear today as it was when I wrote the above. Therefore this change just doesn't add cpeeks() at all.
Since f8c6c58373 the Apple II CONIO implementation doesn't "need" revers() anymore - meaning that (nearly) every possible value can be placed in VRAM with a straight cputc() (without the need for a previous revers(1)).
The implementation of cpeekc() leverages that cputc() ability by always returning the value that can be fed into cputc() without a previous revers(1). Accordingly, cpeekrevers() always returns 0.
So after the sequence revers(1); cputc(x); a cpeekc() will return a value different from x! However, I don't see this behavior braking the cpeekc() contract. I see the cpeekc() contract being defined by the sequence textcolor(cpeekcolor()); revers(cpeekrevers()); cputc(cpeekc()); placing the very same value in VRAM that there was before. And that contract is fulfilled.
By 'inverting' the loop, we can save 16 cycles by removing the `cpy #8`,
saving 16 cycles. But we need an extra `ldy #7` at the start of the
loop, so the total cycles saved is 14. Code size doesn't increase due to
the addition of the `ldy #7` negating the removal of the `cpy #xx`.
The driver requires a special linker configuration: "vic20-tgi.cfg".
The VIC-20 computer needs at least 8K of expansion RAM!
"tgidemo.c" needed to be adjusted because the VIC-20's vertical (y) range is greater than its horizontal (x) range -- the opposite of most other platforms. Also, the circle demo would jam on the VIC-20.
The implementation is a bit tricky as it requires to take different code paths for the //e, the //c and the IIgs. Additionally the //c only provides a VBL IRQ flag supposed to be used by an IRQ handler to determine what triggered the IRQ. However, masking IRQs on the CPU, activating the VBL IRQ, clearing any pending VBL IRQs and then polling for the IRQ flag does the trick.
As described e.g. in the Apple IIe Technote #6: 'The Apple II Paddle Circuits' it doesn't work to call PREAD several times in immediate succession. However, so far the Apple II joystick driver did just that in order to read the two joystick axis.
Therefore the driver now uses a custom routine that reads both paddles _at_the_same_time_. The code doing so requires nearly twice the cycles meaning that the overall time for a joy_read() stays roughly the same. However, twice the cycles in the read loop means half the resolution. But for the cc65 joystick driver use case that doesn't hurt at all as the driver is supposed to only detect neutral vs. left/right and up/down.
CPU accelerators are supposed to detect access to $C070 and slow down for some time automatically. However, the IIgs rather comes with a modified ROM routine. Therefore it is necessary to manually slow down the IIgs when replacing the ROM routine.
For some reason or another both the author of the PR in question and its reviewers didn't notice that the two functions in question were totally overlooked.
Do not check $fbbe when detecting the Apple //e card. This byte is a version number for the Apple //e card according to misc technote #7 and it appears that the last version of the software that I am aware of has a 3 at this location.
Prior to this change, Apple //e cards which we not version 0 would be detected as an Apple //e enhanced.
tmp1 was used at two places resulting in the bug that VDC_CSET was set to garbage on 16k VDC.
pagecount and curpage were not reset on INSTALL resulting in non-reentrant code on static linkage of emd driver.
To do this we add a constructor call to UPDCRAMPTR, which is the ROM
routine that fixes up CRAM_PTR to match the screen location pointed to
by SCREEN_PTR.
This adds two additional bytes to programs using cputc() or other
routines that call it. These are in theory recoverable, but the VIC-20
does not yet free space used by constructors after the constructors
have been called.
Thanks to <greg.king5@verizon.net> (GitHub: greg-king5) for
investigating the difference in the VIC-20 KERNAL from the C64 and
proposing this solution to the problem.[1]
[1]: https://github.com/cc65/cc65/issues/946#issuecomment-538502820
On C64, VIC-20 and Plus/4, the conio library PLOT routine uses direct
calls into the Kernal, including the Kernal PLOT routine that we're
replacing. These were previously hardcoded addresses; we change these
to use the symbols for those routines defined in cbm_kernal.inc. (This
changes no functionality.)
To do this, we need to import cbm_kernal.inc in a namespace so we
don't have a collision between the PLOT that we're defining and the
Kernal definition.
We also add a UPDCRAMPTR symbol (used by kplot for VIC-20 and C64) to
the direct entry kernal routines in in cbm_kernal.inc, and expand the
comments describing what the "direct entry" Kernal routines are.
<greg.king5@verizon.net> (GitHub: greg-king5) came up with this idea
and did initial testing of it.
This has been tested on VICE xvic, x64 and xplus4 emulators with a
program that does a cputs() call (github.com/0cjs/vic20cc65) to
confirm that it works the same way after as it did before.
Restructured according to review in pull request #567.
The "inputc" function was moved in slightly modified form
to kbhit.s and replaces the old keyboard scanner.
cgetc() uses the new kbhit() to read a character.
* The sprite-types for black and transparent backgrounds were swapped.
* A filler-byte for text output isn't printed. (A hardware bug might not need that work-around in most cases.)
load and run address now configured from header
fix error codes not to conflict with test
fix test/misc/endless.c which is supposed to fail if an endless loop does not occur
3d8c3a4948 caused an unintended "shadowing" of files in /libsrc/runtime by files in /libsrc/common. Therefore the files in question are renamed (again) in /libsrc/common to make the files in /libsrc/runtime "visible" again.
This follows a suggestion by Sijmen Schouten in issue #818.
Platoterm64 now works with mouse at 1200 baud.
Bump MOUSE_API_VERSION in asminc/mouse-kernel.inc.
Fix typo in testcode/lib/mouse-test.c.
If detected, the program refuses to run, preventing a crash.
The check only works with SpartaDOS. I don't have an overview which
DOSes potentially use the RAM under the ROM. Or which other installed
programs might use it.
No additional runtime memory space is consumed, since the change
is in the "system check" load chunk which gets replaced by the
user program during loading.
Although documented nowhere (!!!) ProDOS trashes the random counter locations $4E/$4F. Is discovered this because my TCP connections didn't have random local ports.
It's a really funny coincidence that David Finnigan discovered only 3 years ago the very same issue because of the very same reason: https://groups.google.com/forum/#!topic/comp.sys.apple2.programmer/1ciep_Oetvo
In order to have randomize() work as expected (and the Apple II random number generation in general) it is necessary to update the random counter during keypress wait just like the ROM function does.
Extendend memory is mapped over the main memory in the 0x4000..0x7FFF
area. Many DOSes disable interrupts while extended memory is banked in,
but not all (e.g. SpartaDOS-X).
This change modifies the initial interrupt handler to map in main memory
before chaining to the "worker" handlers.
Since the initial interrupt handler uses a data segment to store the
trampoline to chain to the original handler, introduce a new "LOWBSS"
segment to hold this trampoline. Otherwise the trampoline may end up
inside the 0x4000..0x7FFF area.
Add a link time warning if "LOWCODE" segment lays within the extended
memory window.
Fixes this issue:
https://github.com/cc65/cc65/issues/722
ftell() returns the value returned by lseek(), and lseek() for the
Apple II wasn't returning a value.
According to https://github.com/cc65/wiki/wiki/Direct-console-IO it is undefined what happens when the end of the sceen is reached. But it is _not_ undefined what happens when the end of the line is reached. So implement the usual thing - which was easy enough to do after all.
Originally the Apple II had a 64 char set and used the upper two bits to control inverse and blinking. The Apple //e brought then an alternate char set without blinking but more individual chars. However, it does _not_ contain 128 chars and use the upper bit to control inverse as one would assume. Rather it contains more than 128 chars - the MouseText chars. And because Apple wanted to provide as much backward compatibility as possible with the original char set, the alternate char set has a rather weird layout for chars > 128 with the inverse lowercase chars _not_ at (normal lowercase char + 128).
So far the Apple II CONIO implementation mapped chars 128-255 to chars 0-127 (with the exception of \r and \n). It made use of alternate chars > 128 transparently for the user via reverse(1). The user didn't have direct access to the MouseText chars, they were only used interally for things like chline() and cvline().
Now the mapping of chars 128-255 to 0-127 is removed. Using chars > 128 gives the user direct access to the "raw" alternate chars > 128. This especially give the use direct access to the MouseText chars. But this clashes with the exsisting (and still desirable) revers(1) logic. Combining reverse(1) with chars > 128 just doesn't result in anything usable!
What motivated this change? When I worked on the VT100 line drawing support for Telnet65 on the Apple //e (not using CONIO at all) I finally understood how MouseText is intended to be used to draw arbitrary grids with just three chars: A special "L" type char, the underscore and a vertical bar at the left side of the char box. I notice that with those chars it is possible to follow the CONIO approach to boxes and grids: Combining chline()/cvline() with special CH_... char constants for edges and intersections.
But in order to actually do so I needed to be able to define CH_... constants that when fed into the ordinary cputc() pipeline end up as MouseText chars. The obvious approach was to allow chars > 128 to directly access MouseText chars :-)
Now that the native CONIO box/grid approach works I deleted the Apple //e proprietary textframe() function that I added as replacement quite some years ago.
Again: Please note that chline()/cvline() and the CH... constants don't work with reverse(1)!
