On Wed, 24 Dec 2008, Charlie wrote:

> 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.

I'm planning to use UniDOS, actually - and code to DOS 3.3.  The asm I use 
runs natively on the PC side, I have a toolkit to import stuff but have a 
practical limit of about 32K per side out of necessity.

(I just think it would be 1337 to have the IIgs GUI stuff come up on DOS 
3.3 of all systems, lmao)

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

:)

I've never used memory management on any system I've coded for but that 
would be very useful.

>> 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.

Figured as much.

>> 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.

Which isn't that hard to deal with.

>> 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 :-)

I've had to do it before.  All my emulators do it.  Toolbox would make 
things so much easier but I figured if I didn't have the code to write on 
the screen in Shaston 8 I could always do it the good ol' fashioned way 
like I do in my emulators.

> 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.

One usually considers the highest-level stuff as needing to be loaded from 
disk, but it would seem with the IIgs that the high-level stuff is in ROM, 
and only the low-level stuff needs to be pulled from disk!

> 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.

Easy enough to switch to 16-bit mode, call the toolbox, drop to 6502 mode, 
not?

>
>> 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'll look around there.  I read that site a lot.

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

I've been looking, and will continue to.

-uso.
--- SBBSecho 2.12-Win32