This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii
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=
>> 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=
>> "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=
>> 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=
>> alter it to use the $24/$25 memory addresses like the Apple ][ firmware
> 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
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=
>> 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=
own implementation of 6502 BASIC which, while lacking graphics support, is=
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=
>> 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
>> 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:
> 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=
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: