Oliver Schmidt [Wed, 1 Jun 2016 21:45:27 +0000 (23:45 +0200)]
Removed shell for-loop.
Just a few of the many reasons why shell for-loops have no place in (GNUmake) Makefiles:
* They don't conform to https://www.gnu.org/software/make/manual/html_node/Utilities-in-Makefiles.html
* They break Windows builds for sure
* They don't fit to make's approach of working with sets
* They break make parallelism
Oliver Schmidt [Wed, 1 Jun 2016 21:00:37 +0000 (23:00 +0200)]
Don't hide build commands.
The samples Makefile serves educational purposes. From that perspective it's counterproductive to hide the actual build commands. Apart fom that it becomes visible if an installed cc65 is used to build the samples.
Oliver Schmidt [Wed, 1 Jun 2016 17:46:02 +0000 (19:46 +0200)]
Don'r presume that the C64 is the only target.
Other targets have disks too and if at some point some one is interested enough to add support for disk creation for other targets too then 'disk' is no good goal name for a C64 disk.
Oliver Schmidt [Wed, 1 Jun 2016 17:41:51 +0000 (19:41 +0200)]
Don't fiddle with foreign files.
No cc65 tool creates *~ files so we don't cleanup *~ files. If some other tool (like an editor) creates *~ files it's up to the user - and only him - to decide when those files are to be deleted !
Atari: add new function '_is_cmdline_dos()' and some other small changes.
- use this function instead of directly looking at _dos_type in the included
targetutil and test programs
- fixes/improvements to the Atari runtime library regarding the recently
changed _dos_type values
- libsrc/atari/targetutil/w2cas.c: exit if no filename was entered
- add documentation for the new function
OzHawk [Wed, 11 May 2016 09:54:16 +0000 (19:24 +0930)]
Update the missing entries in the kernel jump table for the Vic20 with the actual function addresses.
The Vic20 does not have kernal table entries for the following functions.
;-----------------------------------------------------------------------------
; Functions which are not in the kernal jump table for VIC-20 but are for C64
CINT := $E518
IOINIT := $FDF9
RAMTAS := $FD8D
All other kernal entries are the same as the C64, however, without this change, the startup code fails.
Without this change the vic20.lib builds incorrectly.
Greg King [Fri, 22 Apr 2016 15:33:52 +0000 (11:33 -0400)]
Added the optional C keyword "volatile" to the __asm__ statement grammar.
It prevents the statement's Assembly code from being optimized (e.g., moved or removed). Optimization is disabled for that statement's entire function (other functions aren't affected).
Oliver Schmidt [Fri, 25 Mar 2016 20:57:06 +0000 (21:57 +0100)]
Allow _sys() to call ROM routines.
_sys() is supposed to be (primarily) intended to call ROM routines. Leveraging the "file overlay" mechanism of the cc65 build system allows to provide a Apple II specific _sys() implementation that temporarily switches in the ROM.
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.
Oliver Schmidt [Wed, 16 Mar 2016 15:28:32 +0000 (16:28 +0100)]
Adjusted constructors.
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.
Oliver Schmidt [Sun, 13 Mar 2016 21:18:51 +0000 (22:18 +0100)]
Fixed INIT properties.
The main chunk load header references __BSS_LOAD__ so BSS must be the first bss type segment. Subsequent changes will move ONCE to share its address with the BSS. Then it'll be necessary to load INIT from disk. Therefore we do it right now.
Oliver Schmidt [Sun, 13 Mar 2016 13:32:07 +0000 (14:32 +0100)]
Cleaned up C64 linker configs.
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.
Oliver Schmidt [Mon, 7 Mar 2016 00:28:55 +0000 (01:28 +0100)]
Renamed RAM to MAIN for all disk based targets.
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.
Oliver Schmidt [Sun, 6 Mar 2016 20:26:22 +0000 (21:26 +0100)]
Renamed INITBSS to INIT and INIT to ONCE.
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.
Oliver Schmidt [Sun, 28 Feb 2016 18:29:37 +0000 (19:29 +0100)]
Load INITBSS segment from disk.
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!
projects / cc65 / log