We want to add the capability to not only get the time but also set the time, but there's no "setter" for the "getter" time().
The first ones that come into mind are gettimeofday() and settimeofday(). However, they take a struct timezone argument that doesn't make sense - even the man pages says "The use of the timezone structure is obsolete; the tz argument should normally be specified as NULL." And POSIX says "Applications should use the clock_gettime() function instead of the obsolescent gettimeofday() function."
The ...timeofday() functions work with microseconds while the clock_...time() functions work with nanoseconds. Given that we expect our targets to support only 1/10 of seconds the microseconds look preferable at first sight. However, already microseconds require the cc65 data type 'long' so it's not such a relevant difference to nanoseconds. Additionally clock_getres() seems useful.
In order to avoid code duplication clock_gettime() takes over the role of the actual time getter from _systime(). So time() now calls clock_gettime() instead of _systime().
For some reason beyond my understanding _systime() was mentioned in time.h. _systime() worked exactly like e.g. _sysremove() and those _sys...() functions are all considered internal. The only reason I could see would be a performance gain of bypassing the time() wrapper. However, all known _systime() implementations internally called mktime(). And mktime() is implemented in C using an iterative algorithm so I really can't see what would be left to gain here. From that perspective I decided to just remove _systime().
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 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.
- 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'.
- cputc was drawing at the wrong position, therefore one line had to be removed as a workaround.
- chline, cvline were drawing one pixel to large lines.
- cclear was drawing an in both directions one pixel to big rect.
- the cursor was drawn at wrong times at wrong places in a wrong size.
git-svn-id: svn://svn.cc65.org/cc65/trunk@5874 b7a2c559-68d2-44c3-8de9-860c34a00d81
However the stack (usually 1 kB) can be securely placed in the secondary area without effort from the side of the developer. The rest of the secondary area (usually 4 kB) is made available to the developer as (uninitialized) 'EXTBSS'.
git-svn-id: svn://svn.cc65.org/cc65/trunk@5696 b7a2c559-68d2-44c3-8de9-860c34a00d81
However now I understand that CBM GEOS does _not_ use PETSCII so the CBM character specification table doesn't make sense at all. After all this is very plausible because GEOS wants to enable the user to share his files across GEOS variants - so we can share the character specification table too.
git-svn-id: svn://svn.cc65.org/cc65/trunk@5527 b7a2c559-68d2-44c3-8de9-860c34a00d81
- According to the "Hitchhiker's Guide To GEOS" GetSerialNumber returns a string on Apple GEOS (in contrast to a number on CBM GEOS).
Given both facts and that the API is presumably not important at all it seems reasonable to just go without it on Apple GEOS.
git-svn-id: svn://svn.cc65.org/cc65/trunk@5503 b7a2c559-68d2-44c3-8de9-860c34a00d81
