Re: Coding to the ][, Coding to the ///?

[schmidtd <schmidtd@my-deja.com>]

On Dec 10, 2:49 pm, lyricalnanoha
<lyricalnan...@usotsuki.hoshinet.org> wrote:
> Now that I've gotten some very limited /// stuff running (thanks to
> MESS)...I've been thinking of trying to code to the ///.
>
> Fortunately, getting software to the emulated /// is a snap.  I'd just use
> the same strategy as I use for the ][, using the emulated ][+ from
> ApplePC.  Save to a ProDOS disk, boot on the ///.  The questions become a
> bit more complex here.

Indeed it does.

> 1. I assume the 40x24 text mode works similarly to the ][.
>     Running on MESS, part of the text screen would periodically get
> "colorized", and I suspect the color memory is stored on text page 2.
> This would mean that I'd want to place my memory floor at 3K, not 2K, when
> running on the ///.

Yes; you can poke away at $400 and see characters appear.  I don't
know where the color memory is myself, but it would be pretty easy to
find out.

> 2. Console I/O?
>     I might just take the code I used when first porting Symbasic, then
> alter it to use the $24/$25 memory addresses like the Apple ][ firmware
> uses.

There isn't the firmware console I/O stuff in the /// that there is in
the II.  If you want to print it, you've got to write a routine to do
it.

>     Also - charset loading?

That's a bit of a mystery.  There are some "invokables" (assembly
helper modules) that will load up different character sets from BASIC
or Pascal.  But it's a tricky business...

> (Random: I wonder if it's possible, at all, to get around the ///'s nerfs
> and load DOS 3.3 and FPBASIC up in native mode. o.o)

Well, that kind of already happens with the Apple II emulation disk,
doesn't it?  You only get 48k (there is a 60k version out there...)
but that's enough for DOS and FP.  There's so much code in the II ROMs
that's missing from the /// that you would have to port all of that
too anyway.

> 3. SOS API vs. PRODOS API?
>     This won't really come into play until I'm sufficiently familiar with
> ProDOS's API, though.

The APIs are largely similar, but SOS has more memory management
stuff, not to mention all the device driver I/O that isn't present in
ProDOS.

> 4. SOS.INTERP?
>     I suppose it's a matter of knowing file type, load address, if it needs
> a header, etc.?

SOS.INTERP is your user program.  SOS loads whatever code is called
SOS.INTERP on disk into $2000 and executes it upon bootup.  There is a
very definite signature you'll need to add to your program to make SOS
believe it's valid.  The first volume of the SOS manual, starting on
page 118, goes through all of that:
http://1000bit.net/support/manuali/download.asp?id=662

The MESS /// emulation has trouble with booting the Apple II emulation
disk (sub-emulation?!?) and shows the colorization you mention.
That's a problem for MESS to fix; but if you're going to talk to the
native ///, you don't need to worry about it.

Finally, take a look at a couple of articles I've collected.
Jeppson's "Guided Tour of Highway III" is especially helpful:
http://adtpro.sourceforge.net/apple3.html