Make the same changes to the Apple II that were done with 0ee9b2e446 to the C64.
Notes:
- The startup code deliberately doesn't make use of symbols defined for the LC segment as that segment is optional.
- The <...>-asm.cfg configs move the segment BSS to an own memory area BSS although this doesn't seem necessary. However the benefit is that the size of the memeory area MAIN is identical to the number of bytes loaded from disk into RAM. To keep this an invariant for all Apple II configs allows to simplify the EXEHDR to just refer to the symbols defined for MAIN.
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 BSS segment and the ONCE segment share the same start address. So they need to be placed in two different memory areas.
So far BSS was placed in the MAIN memory area and ONCE was placed in an additional memory area. Both memory areas were written to the output file. They just "happened" to be loadable and runnable at a stretch.
Now ONCE is placed in the MAIN memory area and BSS is placed in an additional memory area. Only MAIN is written to the output file. It becomes more obvious that BSS is "just" defined to share memory with ONCE.
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.
Conceptually the INITBSS segment is not initialized in any way. Therefore it makes sense to not load it from disk. However the INIT segment has to be loaded from disk and therefore moved to its run location above the INITBSS segment. The necessary move routine increases runtime RAM usage :-(
Therefore we now "unnecessarily" load the INITBSS segment from disk too meaning that the INIT segment is loaded at its run location. Therefore there's no need for the move routine anymore.
After all we trade disk space for (runtime) RAM space - an easy decision ;-)
Notes:
- The code allowing to re-run a program without re-load present so far could not have worked as far as I can see as it only avoided to re-run the move routine but still tried to re-run the code in the INIT segment that was clobbered by zeroing the BSS. Therefore I removed the code in question altogether. I'm personally not into this "dirty re-run" but if someone wants to add an actually working solution I won't block that.
- INITBSS is intentionally not just merged with the DATA segment as ROM-based targets can't reuse the INIT segment for the BSS and therefore have no reason to place the INIT segment above INITBSS.
- Because ROM-based targets don't copy INITBSS from the ROM (like it is done with the DATA segment) all users of INITBSS _MUST_NOT_ presume INITBSS to be initialized with zeros!
Kym Greenshields <kym.greenshields@gmail.com> has expressed interest
in contributing and maintaining support for the VTech CreatiVision system.
this resembles commit 8e6b8dd0af from oliver
A call to $FDA3 cannot be used because it re-enables the BASIC ROM. If a large program (such as Contiki's webbrowser80) has destructor code or data "behind" that ROM, then the program might crash when it tries to quit gracefully. Changing that code to set CIA2_PRA works well enough.
They are smaller and faster because they take advantage of the pce CPU's block-copy instructions.
Also, made a small improvement to the common memmove(), so that it is similar to the pce version.
Moving __cwd from BSS into INITBSS does of course ;-) not only impact the CBM targets but all targets with disk I/O support.
Note: Code using `__cwd-1` may trigger an ld65 range error because __cwd may end up at the very begining of a segment. As far as I see this is an ld65 bug which I'm not try to fix - at least here.
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.
Made other changes that were recommended by Oliver.
* Changed its name from move_init to moveinit.
* Used self-modifying code in the subroutine.
* The INIT segment doesn't need to be optional (it's used by the start-up file).
When a program starts running, INIT is moved from one place to another place. Then, INIT's code is executed; and, the first place is re-used for variables. After the INIT code has finished, the second place can be re-used by the heap and the C stack. That means that initiation code and data won't waste any RAM space after they stop being needed.
* Added an important ".code" directive.
* Import a linker-created zero-page symbol as an absolute address; then, convert it to zero-page when it is used.
Fixes bug report #198.
The driver kernels all require IRQ handling even if the actual drivers don't make use of it. So in order to successfully link a NES program using the joystick and/or TGI driver there has to be at least a "dummy" IRQ backend.
That parameter's type is unsigned; but, the functions return an int. If the size is too big for a signed integer, then return an error code.
If the size is zero, then don't write anything into a buffer (the buffer pointer may be NULL). But, do format and count the arguments.
The starting point is the CALL2051:REM <cmdline> approach. It uses the BASIC input buffer at $200. ProDOS stores the name of the loaded program at $280 (which we want for argv[0]) leaving us with 128 char buffer. If we run the program via exec() we don't need the CALL2051 but only the REM token (which is just one char). So have a maximum cmdline length of 126 (plus a terminating zero).
There's no specification for ProDOS BIN file cmdline parameters so exec() just supports the CALL2051:REM <cmdline> approach. In contrast ProDOS SYS files allow for a 'startup filename'. A ProDOS filename is short than 126 chars so having exec() general cut the cmdline after 126 chars seems reasonable. If the SYS file we exec() allows for less we cut the cmdline further.
Our 'loader.system' SYS file however allows for an unusually 126 char long "startup filename" as it is targeted towards cc65 BIN porgrams with their 126 cmdline length.
Experiments show that under BASIC by default
25 rows by 24 columns are used. 24 columns is
also the width that is fully displayed on a real
C1P on the monitor. conio now matches that now.
If kbhit() detects that a key is pressed, it fetches and
buffers the character. If cgetc() detects a buffered character,
this one is returned instead of fetching one with the PROM
routine.
Adjusted comment formatting in several assembler files.
Removed dummy kbhit() function, as it's better to get a linker
error than an implementation that does the wrong thing.
- Put a BASIC-language stub at the beginning.
- Removed the Autostart flag.
Those changes make it easy to give command-line arguments to a program.
* Made the Atmos configure file accept a special symbol definition on ld65's command line. We can use "__RAMEND__" to increase the amount of RAM that's available to programs.
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').
A description of positions [left, right] is appropriate more for C code than for Assembly code. (A description of timing [first argument, second argument] is more appropriate for the way that Assembly code is written.)
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 :-((
- make cursor character of text mode callback configurable
- change default cursor character of text mode callback from 'plus' to 'diamond'
- set P/M callback as default
After all it seems much cleaner to explicitly control the behaviour from the .travis.yml file than to behave differently "under the hood" when detecting a Travis CI build.
