- 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
