GeoProgrammer Pain

[xlar54]

Wow... so I actually in earnest did some poking around with GeoProgrammer today.  See if I could actually write something that would do something.  Man... without docs, its just not going to fly.  There is apparently alot to GeoAssembler and Linker that one must understand before the tools can be useful.  I assumed that even very simple ML programs (as simple as LDA #$00 and RTS) would at least assemble and link, but GeoProgrammer had its own ideas.  Docs are a must.  Then the pain of actual development on Vice or a real 128.  Certainly theres things you can do on VICE to speed up the emulator (I run GEOS at 200%, WITH emulated REU), and its still painfully slow when you're used to today's development environments.  It takes a patient person to do this kind of work on the real thing.  Im actually rather surprised that Berkley made developers use GeoWrite to do the coding in.  Its a fair enough word processor, but using it for development it is way overkill.  GeoWrite makes it more painful than it needs to be.

A few months back I messed around the cc65 and the geos library.  Gotta say... unless you like pain or *really* want to relive the old days, cc65 is probably the only way to do it anymore.  Im curious to hear of other's experience with it, if anyone has done so.

[SeanHuxter]

Well of course it needs docs, it's a complicated program. geoProgrammer also comes with various sample source files for a Desk Accessory and an Application, and once you get familiar with those, assembling a simple program is a snap.

For my latest project I used geoProgrammer in VICE, and the only real issue I had with it was that the Debugger isn't working because of the unique way the C128 (I was using VICE128 and GEOS 128) does the Restore key. For some reason VICE wouldn't accept it, so there's no way to switch back and forth from the debugger to the application I was coding to do any serious debugging. But since I am very good at debugging code by hand, that was NOT a deal breaker.

If you really require the debugger, then I'd suggest using the real 128. Assembles and links are much slower, but the debugger can be incredibly helpful. It's a tradeoff.

geoProgrammer is an elegant coding system. geoWrite 128 doesn't require side-scrolling in GEOS 128 unlike the C64 version, so that's not an issue. It also allows you to paste in your graphics from geoWrite clips and is a very very good assembler with macros and its own math parsers so you can say FOO = 8 and then just use FOO wherever you need it.

But of course you need the manual. It's essential. Also, it is almost equally essential that you have Berkeley's GEOS Programmer's Reference Guide.

Luckily, both are available here: http://lyonlabs.org/commodore/onrequest/geos.html#manuals

I have them in book form from way back in the day, so of course that's the best way...

I found that geoProgrammer got me up and coding far faster than most systems I've used. All you really have to do is cut code out of the sample source files and put in your own. Of course you'll also learn to link multiple source files together and for larger programs that's essential. My latest project, geoGlyph, used 8 source geoWrite files and one of them reached the maximum limit of pages a couple of times... so yeah, you'll need the docs.

For further info on what I was able to do with geoWrite, please see:
http://www.huxter.org/geoglyph.htm

And for my previous projects (from the 1990s) - http://www.huxter.org/c64/geos/geos.htm

Sean.

[Hydrophilic]

OMG, that's the most comprehensive set of geoProgramming stuff (software, docs) that I have ever seen!  Thanks for sharing!! 

I must agree with xlar54, using geoWrite is overkill.  Sure it's nice to see images in your source code, but geoWrite should be an option, not a requirement.  It is the main reason I never got really deep into programming GEOS.  A real shame because it is a very interesting system and with today's emulators (or I imagine with an REU on a real system) it is a nice environment.