[cc65] GEOS Reloaded

Hi,

I've been improving the cc65 support for GEOS and would like to let
you know about it...

1. VLIR (aka overlay) programs

Up to now VLIR support was limited to assembler programs. Now it works
for C programs too.
Up to now building a VLIR program was quite complex:
http://www.cc65.org/doc/grc-5.html
Now it is a simple one step process:
http://www.cc65.org/snapshot-doc/grc65-5.html
Up to now you had to provide many details in the 'VLIR section' of
your resource file:
http://www.cc65.org/doc/grc-3.html#ss3.3
Now you just set set size and numbers of your overlays in the 'memory
section' of your resource file:
http://www.cc65.org/snapshot-doc/grc65-3.html#ss3.3

Code is assigned via #pragma's to the individual overlays (like in any
non-GEOS scenario). The overlay area is automatically placed at the
end of the available memory. Overlays are simply loaded via
ReadRecord(OVERLAY_ADDR, OVERLAY_SIZE);
using two predefined macros. There's a sample program showing
everything mentioned above.

2. Optional release of screen backbuffer

Usually a GEOS program can use 23kB RAM ($0400-$6000). But if a
program avoids the use of the background screen buffer it can use 31kB
RAM ($0400-$8000). Building a program for this setup requires simply a
'backbuffer no' in the 'memory section' of your resource file. This
works with VLIR programs too.

3. Custom application icon

Now you can replace the default application icon (an empty frame) with
a custom icon with something like 'icon "sprite.raw"' in the 'header
section' of your resource file:
http://www.cc65.org/snapshot-doc/grc65-3.html#ss3.2

4. 'geos' becomes 'geos-cbm'

The cc65 target 'geos' was renamed to 'geos-cbm' (with 'geos' as alias
'geos-cbm'). This was done due to the upcoming support of Apple GEOS,
which will allow you to target both GEOS 64/128 and Apple GEOS with a
single set of C sources - cc65 at its best :-)

5. Lookout

1.) and 2.) now allow to create rather complex GEOS programs in C.
Just in case you feel motivated to implement one but happen to not
have a great idea here's my take:

I was looking for something highly interactive but not an actual
productivity tool. Rather something entertaining but not an actual
game. Something that really benefits from the mouse over keyboard-only
input. And something that can be done withe our 1 MHz 64kB beast. What
I came up with is a "Sudoku Assistant" - not to be mixed up with a
Sudoku Solver. The typical UI for such a Sudoku Assistant looks like
http://img278.imagevenue.com/loc33/th_526594469_candidats_122_33lo.jpg.
I've already checked out if it is feasable to reproduce that type of
grid on the C64 (and Apple II) display - which works out nicely as it
requires a height of 185 pixels
(http://img182.imagevenue.com/loc32/th_26262_grid_122_32lo.jpg).

There's a lot of Sudoku literature describing usual algorithms in
interactive Sudoku solving. Just search i.e. for the term "sudoku
naked single". A cool Sudoku Assistant is able to apply these
algorithms on user request to make suggestions. I haven't search for
existing open C source code implementing these things but I'm pretty
optimistic that there's some stuff to find - if needed ;-)

And as a cool add-on one could integrate a real Sudoku Solver. I don't
know if you are aware of the "Sudoku Solver v2.0 for the Apple II"
(http://home.comcast.net/~mjmahon/Sudoku.html)? It's a higly optimized
6502 assembly language Sudoku Solver - people were pretty amazed by it
(http://groups.google.com/group/comp.sys.apple2/browse_frm/thread/3b09e33f1f6f991d/3782ec4fa293fdcc?hl=en&tvc=1&q=apple2+sudoku+solver).
I had a brief look into the source code and it doesn't seem to create
large RAM tables or alike that could hinder it from integration into a
GEOS application. And it would be a nice showcase of using ca65 to
integrate assembler with C for hotspot optimization - while staying
cross-target.

Regards,
Oliver
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.