Re: Coding for IIgs?

["Charlie" <charlieDOTd@verEYEzon.net>]

"lyricalnanoha" <lyricalnanoha@usotsuki.hoshinet.org> wrote in message 
alpine.DEB.0.99.0812241226560.6020@andisteele.dosius.ath.cx">news:alpine.DEB.0.99.0812241226560.6020@andisteele.dosius.ath.cx...
> I've just gotten to thinking.
>
> I don't know a lot about the IIgs under the hood, though I've kind-of 
> wondered how hard it would be to code for it.  And maybe I'm being a bit 
> of a masochist here by wanting to do all of this without recourse to 
> GS/OS, but at least what I want to do is keep my DOS 3.3 comfort zone 
> (thank ghed for UniDOS and its ability to use the DOS 3.3 api on 3.5" 
> disks xD).
>
> So I've been wondering about how hard it would be (keep in mind the only 
> tool I have for assembling 65816 code is CA65, though it seems that should 
> be adequate) to do some simple stuff.  Like...
>
> 1. Good place to locate this stuff in RAM?  I wouldn't want to step on 
> anything and I don't know the GS's memory map,

Most assemblers for the IIgs create files that are in object module format 
so that they can be easily relocated in memory.  GS/OS uses this.

If you are not going to use GS/OS etc. then you essentially have all the 
memory above bank $01 available and your programs could decide where to put 
things.  The GS uses the same two pages that any Apple II does but it 
mirrors those pages to bank $E0 and $E1 which run at normal 1MHz speed.

You also have a built in memory manager toolset that could possibly help to 
make things easier.

> though I'd need to load the stuff into the "Contiguous 48" and then move 
> it up... prolly isn't that hard as 65816 is 6502 extended...

The 65816 allows you to add a few bytes of code to switch to 16 bit mode and 
back within a normal 8-bit program so moving stuff to anywhere in memory 
isn't very hard.

> 2. Set the 320x200 mode, (is it paletted?

Yes, it is paletted. 16 palettes per screen. Each line can have its own 
palette of 16 colors out of 4096 colors.  4 bits per pixel.

> mb set it up with RGBI, the CGA palette? would be more familiar for me) 
> draw pixels on it, possibly write on it in Shaston 8 (if not, I can always 
> crack out a PC font), cursors etc.

I wouldn't want to tackle fonts without using the toolbox.  But hey, what 
ever floats your boat :-)

>
> 3. Set the 640x200 mode, same as above

Pretty much the same, only 2 bits per pixel.

>
> 4. I wonder how hard GUI stuff is at low-level?

At low-level the GS handles stuff like any Apple II, softswitches in the 
$C000-$CFFF area and memory mapped video.  The SHR video is actually easier 
because the pixel data is in a more logical (for humans) order.  Palettes 
and line info are stored right after the video.

> Like, mouse, menus, windows.  And how much of that is done by the toolbox, 
> and how much by ProDOS-16 / GS/OS?

GUI stuff is pretty much all toolbox calls.  There are also quite a few 
non-GUI tools (text tools, integer math tools, SANE, sound, etc.) There is 
also a miscellaneous toolset that has tools for handling interrupts, low 
level mouse, battery RAM, etc.
GS/OS doesn't have anything to do with the GUI.  I don't think the GUI stuff 
is even mentioned in the GS/OS or ProDOS-16 manuals (I'm going by memory 
here).  GS/OS is mostly an I/O system.  It does integrate with a few of the 
(non GUI) toolsets to load files, etc.

The toolbox routines can be accessed without GS/OS.  I believe a few can 
even be accessed in 8-bit mode (or maybe not :-).  One thing you have to be 
careful with is that some (most) of the toolsets are dependant on other 
toolsets so they have to be loaded/initialized in order before being used.

> This really sounds noob, I know - but I'd just like to try some of this 
> stuff.  Prolly my first experiment will be something simple, like taking a 
> 6502 BASIC interpreter, and engineering it to use graphics routines for 
> text i/o.  (Or FPBASIC "&" hacks to use them?)
>
> -uso.

You might want to take a look at some of Bob Sander-Cederlof's later Apple 
Assembly Line stuff.  If I remember correctly, He did some Apple IIGS 
programming without using ProDOS-16 or GS/OS.

I would also strongly suggest that you read the IIGS hardware and firmware 
references.

Charlie