Oliver Schmidt [Fri, 3 Jun 2016 09:08:53 +0000 (11:08 +0200)]
Added --print-target-path option.
If cc65 is installed and used as designed there's no need whatsoever for CC65_HOME (both on *IX and Windows) from the perspective of the cc65 binaries. If the user however has to access files from the 'target' directory thenhe ends up with some assumption on the cc65 installation path nevertheless :-(
In order to avoid this I added the --print-target-path option. It "exports" the logic used by the cc65 binaries to locate their files to the user thus allowing him to leverage the same logic to locate the target files in his build scripts / Makefiles.
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.
projects / cc65 / log