[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Wed, 10 Dec 2008, schmidtd wrote:


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.
I'm guessing, based on the weird behavior which MESS exhibits (missing page support?), that it's at $800. 




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.
Yeah. Fortunately I've already written it for the ][. It's not perfect and it's brittle on the ][ but I might have better luck on the ///. 


    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.
Hence, FPBASIC... which on the stock ][, it loads underneath the ROM at 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?
    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.
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 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.