f



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

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.

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

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.
    Also - charset loading?

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

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

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

-uso.
0
12/10/2008 7:49:07 PM
comp.sys.apple2 11066 articles. 3 followers. antoine.vignau (1077) is leader. Post Follow

2 Replies
1558 Views

Similar Articles

[PageSpeed] 10

On Dec 10, 2:49=A0pm, 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. =A0I'd just =
use
> the same strategy as I use for the ][, using the emulated ][+ from
> ApplePC. =A0Save to a ProDOS disk, boot on the ///. =A0The questions beco=
me a
> bit more complex here.

Indeed it does.

> 1. I assume the 40x24 text mode works similarly to the ][.
> =A0 =A0 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, whe=
n
> 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?
> =A0 =A0 I might just take the code I used when first porting Symbasic, th=
en
> 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.

> =A0 =A0 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?
> =A0 =A0 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?
> =A0 =A0 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=3D662

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
0
schmidtd (1096)
12/10/2008 8:52:27 PM
  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--1749432381-1058418094-1228945190=:23780
Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii
Content-Transfer-Encoding: QUOTED-PRINTABLE



On Wed, 10 Dec 2008, schmidtd wrote:

> On Dec 10, 2:49=C2=A0pm, 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. =C2=A0I'd j=
ust use
>> the same strategy as I use for the ][, using the emulated ][+ from
>> ApplePC. =C2=A0Save to a ProDOS disk, boot on the ///. =C2=A0The questio=
ns become a
>> bit more complex here.
>
> Indeed it does.
>
>> 1. I assume the 40x24 text mode works similarly to the ][.
>> =C2=A0 =C2=A0 Running on MESS, part of the text screen would periodicall=
y 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, wh=
en
>> 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.

I'm guessing, based on the weird behavior which MESS exhibits (missing=20
page support?), that it's at $800.

>
>> 2. Console I/O?
>> =C2=A0 =C2=A0 I might just take the code I used when first porting Symba=
sic, 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.

Yeah.  Fortunately I've already written it for the ][.  It's not perfect=20
and it's brittle on the ][ but I might have better luck on the ///.

>> =C2=A0 =C2=A0 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 nerf=
s
>> 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.

Hence, FPBASIC... which on the stock ][, it loads underneath the ROM at=20
the same address.

This is more or less irrelevant to my ultimate project which provides its=
=20
own implementation of 6502 BASIC which, while lacking graphics support, is=
=20
a bit more powerful than FPBASIC.

>> 3. SOS API vs. PRODOS API?
>> =C2=A0 =C2=A0 This won't really come into play until I'm sufficiently fa=
miliar 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?
>> =C2=A0 =C2=A0 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=3D662
>
> 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.

MESS is the only way I have to test /// stuff atm, so I have to base it on=
=20
that, unfortunately. :/

Still, it's looking like I might at least be able to get this program=20
ported trivially in its current state.

> 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

-uso.
--1749432381-1058418094-1228945190=:23780--
0
12/10/2008 9:39:50 PM
Reply: