80 Columns under cc65?
Harry Potter
John B. Matthews
<26441ae2-2977-415d...@d77g2000hsb.googlegroups.com>,
Harry Potter <maspet...@aol.com> wrote:
> How do I get an 80-column text mode on an Apple 2 under cc65?
It looks like the cc65 conio library goes to some lengths to avoid
changing whatever your program loader sets. When running hello for
example, my Basic loader initializes the //e 80-column card via PR#3 and
sets 40-column mode via control-Q; I get a centered 40-column display.
If I change to 80-column mode at the Basic prompt (escape-8) and rerun
hello, I get a centered 80-column display.
So the answer for cc65 is the same as "How do I get an 80-column text
mode on an Apple 2?"
Here's how I initialize the //e 80-column card in the ProForth system
loader under ProDOS:
MACHID EQU $BF98
HOME EQU $FC58
...
LDA MACHID
AND #2
BEQ NO80COL
JSR $C300
NO80COL JSR HOME
It looks like something similar could be added to Oliver Schmidt's
excellent ProDOS system loader-1.3, near "user feedback":
<ftp://ftp.musoftware.de/pub/uz/cc65/contrib/>
Once initialized, the //e 80-column card understands printed control
characters, including:
^K Clear eop
^N Normal
^O Inverse
^Q 40-columns
^R 80-columns
^Y Home
^Z Clear line
^] Clear eol
--
John B. Matthews
trashgod at gmail dot com
home dot woh dot rr dot com slash jbmatthews
Oliver Schmidt
>> How do I get an 80-column text mode on an Apple 2 under cc65?
>It looks like the cc65 conio library goes to some lengths to avoid
>changing whatever your program loader sets.
That's very true. And in fact it goes beyond that: In contrast to at
least some other cc65 targets the Apple2 conio implementation allows
you to mix stdio and conio. Additionally you can use the well-known
Apple2 zero-page variables to restrict the output to a certain window
both for stdio and conio.
> LDA MACHID
> AND #2
> BEQ NO80COL
> JSR $C300
I've tried recently to do that from within a cc65 program via inline
assembler but that mixed up something with ProDOS so file I/O didn't
work anymore. I'll have to investigate but my current work life
situation doesn't allow for that. So the current workaround is to set
80-column mode before starting the cc65 program.
Best, Oliver
John B. Matthews
wrote:
> >> How do I get an 80-column text mode on an Apple 2 under cc65?
>
> >It looks like the cc65 conio library goes to some lengths to avoid
> >changing whatever your program loader sets.
>
> That's very true. And in fact it goes beyond that: In contrast to at
> least some other cc65 targets the Apple2 conio implementation allows
> you to mix stdio and conio. Additionally you can use the well-known
> Apple2 zero-page variables to restrict the output to a certain window
> both for stdio and conio.
Oliver: thanks for expanding on this. I'm still new to cc65:-)
> > LDA MACHID
> > AND #2
> > BEQ NO80COL
> > JSR $C300
>
> I've tried recently to do that from within a cc65 program via inline
> assembler but that mixed up something with ProDOS so file I/O didn't
> work anymore. I'll have to investigate but my current work life
> situation doesn't allow for that. So the current workaround is to set
> 80-column mode before starting the cc65 program.
Oliver: the code above was from a ProDOS system program. A non-system
cc65 program launched from the Basic prompt under ProDOS is running
alongside BASIC.SYSTEM. It might be necessary to update the BASIC Global
Page Default I/O vectors after initializing the card:
BE30: VECTOUT DW COUT1 ;Current character output routine
BE32: VECTIN DW CHIN1 ;Current character input routine
I'll have to learn enough inline assembler to try it myself, but
experimenting from the Basic prompt seems to confirm this. I'm tempted
to just try printing control-DPR#3.
Interestingly, not updating the vectors appears to turn on trace!
]mtr
*c300g
*^c
]10 ?"Hello"
]run
#10 Hello
ProDOS is also disconnected, but call 976 ($3d0) restores normalcy.
Michael J. Mahon
BASIC.SYSTEM runs with "real" trace turned on all the time--that's
how it gets control for continuous garbage collection. So if you
disconnect it without its cooperation, you'll see the trace output.
-michael
AppleCrate: An Apple II "blade server"!
Home page: http://members.aol.com/MJMahon/
"The wastebasket is our most important design
tool--and it's seriously underused."
John B. Matthews
Michael: Thanks!
I'm thinking I can just jsr $c300 and copy the updated page zero vectors
(36.39) to the Basic system page (be30.be33). To exit, I issue a
control-U and restore the system page.
Alternatively, if the loader enables 80 columns, printing control-Q and
control-R switch to 40- and 80-columns, respectively.
Thoughts?
John B. Matthews
Recent experimental findings: This does _not_ work.
Of course, now I'm wondering if DOS might buy it :-)
> I'm thinking I can just jsr $c300 and copy the updated page zero vectors
> (36.39) to the Basic system page (be30.be33). To exit, I issue a
> control-U and restore the system page.
This works, for the given assumptions:
/* Assume 80-column card, ProDOS, Basic */
__asm__ ("jsr %w", 0xc300);
__asm__ ("lda %b", 0x36);
__asm__ ("sta %w", 0xbe30);
__asm__ ("lda %b", 0x37);
__asm__ ("sta %w", 0xbe31);
__asm__ ("lda %b", 0x38);
__asm__ ("sta %w", 0xbe32);
__asm__ ("lda %b", 0x39);
__asm__ ("sta %w", 0xbe33);
> Alternatively, if the loader enables 80 columns, printing control-Q and
> control-R switch to 40- and 80-columns, respectively.
And this works, too.
David Wilson
> > > > Oliver: the code above was from a ProDOS system program. A non-system
> > > > cc65 program launched from the Basic prompt under ProDOS is running
> > > > alongside BASIC.SYSTEM. It might be necessary to update the BASIC Global
> > > > Page Default I/O vectors after initializing the card:
If the cc65 program is running with BASIC.SYSTEM, wouldn't it just
need to do the equivalent to PRINT CHR$(4);"PR#3"?
i.e.
puts("\004PR#3");
That way BASIC.SYSTEM will take care of the I/O vectors for you.
John B. Matthews
<b10f1b65-7cdb-4864...@s21g2000prm.googlegroups.com>,
David Wilson <mcs...@gmail.com> wrote:
Not with conio. Looking at libsrc/apple2/cputc.s, putchar stores
characters in video memory, bypassing the I/O hooks.
I'd have thought sdtio might work, as you suggest. It uses _write, which
calls COUT, which in turn vectors through zero page CSWL/H, owned and
operated by ProDOS. I don't know why it's not working.
Harry Potter
> If the cc65 program is running with BASIC.SYSTEM, wouldn't it just
> need to do the equivalent to PRINT CHR$(4);"PR#3"?
>
> i.e.
>
> puts("\004PR#3");
>
> That way BASIC.SYSTEM will take care of the I/O vectors for you.
I don't think I'm running BASIC.SYSTEM, but I don't know much about
Apple //e programming. If nothing else, I'll just use 40-column
mode. BTW, I'm using conio.
John B. Matthews
<497c90f1-4df2-46dc...@r66g2000hsg.googlegroups.com>,
Harry Potter <maspet...@aol.com> wrote:
How are you launching your program?
Harry Potter
> In article
> <497c90f1-4df2-46dc-b514-ab111a064...@r66g2000hsg.googlegroups.com>,
> Harry Potter <maspethro...@aol.com> wrote:
> > I don't think I'm running BASIC.SYSTEM, but I don't know much about
> > Apple //e programming. If nothing else, I'll just use 40-column
> > mode. BTW, I'm using conio.
>
> How are you launching your program?
>
I want it to start up directly when I insert the disk image into the
emulator's drive and reset.
John B. Matthews
<3e2f7951-2301-4272...@x35g2000hsb.googlegroups.com>,
Harry Potter <maspet...@aol.com> wrote:
Sounds like you're still in the planing stage. In the interim, you can
learn about Apple II operating system and programs here:
<http://home.swbell.net/rubywand/A2FAQs1START.html>
Hello/Startup programs are covered here:
<http://home.swbell.net/rubywand/Csa2DOSMM.html>
But you may need to start closer to the beginning:
<http://home.swbell.net/rubywand/A2FAQs2CONTENT.html>
Harry Potter
> Sounds like you're still in the planing stage. In the interim, you can
> learn about Apple II operating system and programs here:
>
> <http://home.swbell.net/rubywand/A2FAQs1START.html>
>
> Hello/Startup programs are covered here:
>
> <http://home.swbell.net/rubywand/Csa2DOSMM.html>
>
> But you may need to start closer to the beginning:
>
> <http://home.swbell.net/rubywand/A2FAQs2CONTENT.html>
>
> --
> John B. Matthews
> trashgod at gmail dot com
> home dot woh dot rr dot com slash jbmatthews
All that is true. I will check out those sites now.
Dave Althoff, Jr.
: I'm thinking I can just jsr $c300 and copy the updated page zero vectors
: (36.39) to the Basic system page (be30.be33). To exit, I issue a
: control-U and restore the system page.
I'm not nearly as good with ProDOS as with DOS 3.3 with such things...
But if you do a JSR to $C300, you will disconnect BASIC.SYSTEM (or
whatever you're using) because the routine at $C300 isn't smart enough
to reconnect DOS; that's why you have to call the [Pro]DOS warmstart
vector at $3D0. [Pro]DOS IS smart enough to keep track of the I/O hooks
at warmstart and NOT disable the 80-column software. In fact, calling
the warmstart vector should copy the CSW and KSW vectors ($36-$39) for
you. Or was that the call to $FB6F that I always made before calling
$3D0...can you tell I haven't even thought about this in years? 8-)
But why enable the 80-column software the hard way, when you can let
[Pro]DOS do it for you? I saw it in this thread: PRINT CHR$(4);"PR#3"
will enable the 80-column software WITHOUT disabling BASIC.SYSTEM.
: Alternatively, if the loader enables 80 columns, printing control-Q and
: control-R switch to 40- and 80-columns, respectively.
Be careful. I always made it a habit to only use the 80-column display
driver in 80-column mode, and if I wanted to operate in 40-column mode,
I always went back to the non-80-column display driver by printing a
CHR$(21). When I started 80-column mode, I was always careful to print
something (a few spaces will do) on the screen, then clear it, because
some versions of the 80-column firmware would behave strangely if I
didn't.
--Dave Althoff, ][.
/X\ _ *** Respect rides. They do not respect you. ***
/XXX\ /X\ /X\_ _ /X\__ _ _ _____
/XXXXX\ /XXX\ /XXXX\_ /X\ /XXXXX\ /X\ /X\ /XXXXX
_/XXXXXXX\__/XXXXX\/XXXXXXXX\_/XXX\_/XXXXXXX\__/XXX\_/XXX\_/\_/XXXXXX
NEW! When emailing this account, include the 'canonical magic word' in
the body of your message for a quicker response.
Dave Althoff, Jr.
Oh. Now I see the problem.
If I remember correctly, BASIC.SYSTEM parses lines that are printed from
running BASIC programs, but NOT characters that are passed through COUT.
Sending the DOS command via COUT worked beautifully in DOS 3.3, but in
ProDOS you have to send the command to ProDOS directly. The problem
with THAT is that there is no equivalent for PR# in the ProDOS MLI. It
looks like there is a method where you can put the command string into
the input buffer:
$200:D0 D2 A3 B3 8D
...then JSR to DOSCMD at $BE03. The reference I am looking at, though,
cautions that this only works in deferred mode...that is, while a BASIC
program is running. I wonder how you can simulate that...Wasn't this
covered in one of the last issues of Softalk....?
--Dave Althoff, Jr.
John B. Matthews
I think you're right.
> The problem with THAT is that there is no equivalent for PR# in the
> ProDOS MLI. It looks like there is a method where you can put the
> command string into the input buffer:
>
> $200:D0 D2 A3 B3 8D
>
> ...then JSR to DOSCMD at $BE03. The reference I am looking at, though,
> cautions that this only works in deferred mode...that is, while a BASIC
> program is running. I wonder how you can simulate that...Wasn't this
> covered in one of the last issues of Softalk....?
Interesting, looks like CURLIN+1 ($76) has something other than $FF when
running. It might be worth another try, although fixing up the ProDOS
vectors worked fine, too.
1500 CURLIN .EQ $75,76 CURRENT LINE NUMBER
1510 * ( = $FFXX IF IN DIRECT MODE)
John B. Matthews
"Dave Althoff, Jr." <dalloff....@sbcglobal.net> wrote:
> John B. Matthews <nos...@nospam.com> wrote:
> : Alternatively, if the loader enables 80 columns, printing control-Q and
> : control-R switch to 40- and 80-columns, respectively.
> Be careful. I always made it a habit to only use the 80-column
> display driver in 80-column mode, and if I wanted to operate in
> 40-column mode, I always went back to the non-80-column display
> driver by printing a CHR$(21). When I started 80-column mode, I was
> always careful to print something (a few spaces will do) on the
> screen, then clear it, because some versions of the 80-column
> firmware would behave strangely if I didn't.
Experimenting with the firmware already enabled:
putchar('\x11'); // switches to 40-columns
putchar('\x12'); // switches to 80-columns
Your suggestion is probably the right thing to do when initializing the
firmware, perhaps in the loader.
Michael J. Mahon
> If I remember correctly, BASIC.SYSTEM parses lines that are printed from
> running BASIC programs, but NOT characters that are passed through COUT.
> Sending the DOS command via COUT worked beautifully in DOS 3.3, but in
> ProDOS you have to send the command to ProDOS directly. The problem
> with THAT is that there is no equivalent for PR# in the ProDOS MLI. It
> looks like there is a method where you can put the command string into
> the input buffer:
>
> $200:D0 D2 A3 B3 8D
>
> ....then JSR to DOSCMD at $BE03. The reference I am looking at, though,
> cautions that this only works in deferred mode...that is, while a BASIC
> program is running. I wonder how you can simulate that...Wasn't this
> covered in one of the last issues of Softalk....?
It's always worth trying. I've found that the cases of several commands
I wanted to use but were "not supported" through DOSCMD worked fine.
Dave Althoff, Jr.
Yes; if you are leaving the 80-column firmware active, then you can use
the firmware commands to switch modes. I should have been more clear
about that.
I'm going way WAY back here...back before the //c, the earliest version
of the 80-column firmware had some strange bugs in it, particularly with
regard to horizontal position. Most of the unexpected behaviors were
cleaned up with the //c ROM, the replacement video ROM in the 'enhanced'
][e, and with the IIgs. So the problems only appear in the earliest of
][e's, and I think ProDOS actually replaces the 80-column firmware with
its own display driver, so under ProDOS it might not even matter. 8-)
John B. Matthews
"Dave Althoff, Jr." <dalloff....@sbcglobal.net> wrote:
> John B. Matthews <nos...@nospam.com> wrote:
> : In article <ojbdk.13727$jI5....@flpi148.ffdc.sbc.com>,
> : "Dave Althoff, Jr." <dalloff....@sbcglobal.net> wrote:
> :
> : > John B. Matthews <nos...@nospam.com> wrote:
> :
> : > : Alternatively, if the loader enables 80 columns, printing control-Q and
> : > : control-R switch to 40- and 80-columns, respectively.
> :
> : > Be careful. I always made it a habit to only use the 80-column
> : > display driver in 80-column mode, and if I wanted to operate in
> : > 40-column mode, I always went back to the non-80-column display
> : > driver by printing a CHR$(21). When I started 80-column mode, I was
> : > always careful to print something (a few spaces will do) on the
> : > screen, then clear it, because some versions of the 80-column
> : > firmware would behave strangely if I didn't.
> :
> : Experimenting with the firmware already enabled:
> :
> : putchar('\x11'); // switches to 40-columns
> : putchar('\x12'); // switches to 80-columns
> :
> : Your suggestion is probably the right thing to do when initializing the
> : firmware, perhaps in the loader.
>
> Yes; if you are leaving the 80-column firmware active, then you can use
> the firmware commands to switch modes. I should have been more clear
> about that.
My fault; I misplaced "probably" and left in "perhaps". I meant to
emphasize adding the old-firmware fix as early in the process as
possible.
The OP's question invites a quick fix, but the design questions remain:
Does the application require/tolerate/preclude 80-columns? What if it's
absent/already enabled? Incompatible? Partially compatible? Preferences?
Key bindings? Aiieee! But I digress. :-)
> I'm going way WAY back here...back before the //c, the earliest version
> of the 80-column firmware had some strange bugs in it, particularly with
> regard to horizontal position. Most of the unexpected behaviors were
> cleaned up with the //c ROM, the replacement video ROM in the 'enhanced'
> ][e, and with the IIgs. So the problems only appear in the earliest of
> ][e's, and I think ProDOS actually replaces the 80-column firmware with
> its own display driver, so under ProDOS it might not even matter. 8-)
I seem to recall that some problems were mitigated with improved
interrupt handling under ProDOS. In particular, the un-enhanced firmware
disabled interrupts for relatively long periods of time, losing data at
1200 bps when scrolling 80 columns:
<http://home.woh.rr.com/jbmatthews/ssc.html>
<http://apple2history.org/history/ah07.html>
Perhaps the odd behavior you mention was fixed in the same revision?
Scott Alfter
Dave Althoff, Jr. <dalloff....@sbcglobal.net> wrote:
>I'm going way WAY back here...back before the //c, the earliest version
>of the 80-column firmware had some strange bugs in it, particularly with
>regard to horizontal position. Most of the unexpected behaviors were
>cleaned up with the //c ROM, the replacement video ROM in the 'enhanced'
>][e, and with the IIgs. So the problems only appear in the earliest of
>][e's, and I think ProDOS actually replaces the 80-column firmware with
>its own display driver, so under ProDOS it might not even matter. 8-)
If this had been the case, it probably wouldn't have been necessary to
upgrade the IIe to enhanced firmware to get most comm software running
right. The biggest problem was that interrupts were disabled for an
unnecessarily long time. Even at 2400 bps, you'd probably start dropping
incoming characters if the screen started scrolling. I only ever used
ProDOS-based comm software, and I had scrolling problems until I obtained
enhanced ROMs and a 65C02 for my IIe. If ProDOS had somehow patched the
buggy firmware out, this wouldn't have been necessary.
_/_
/ v \ Scott Alfter (remove the obvious to send mail)
(IIGS( http://alfter.us/ Top-posting!
\_^_/ rm -rf /bin/laden >What's the most annoying thing on Usenet?
hunt_...@yahoo.com
wrote:
> In article <BKtdk.10220$LG4.7...@nlpi065.nbdc.sbc.com>,
> Dave Althoff, Jr. <dalloff.gcfn....@sbcglobal.net> wrote:
>
> >I'm going way WAY back here...back before the //c, the earliest version
> >of the 80-column firmware had some strange bugs in it, particularly with
> >regard to horizontal position. Most of the unexpected behaviors were
> >cleaned up with the //c ROM, the replacement video ROM in the 'enhanced'
> >][e, and with the IIgs. So the problems only appear in the earliest of
> >][e's, and I think ProDOS actually replaces the 80-column firmware with
> >its own display driver, so under ProDOS it might not even matter. 8-)
>
> If this had been the case, it probably wouldn't have been necessary to
> upgrade the IIe to enhanced firmware to get most comm software running
> right. The biggest problem was that interrupts were disabled for an
> unnecessarily long time. Even at 2400 bps, you'd probably start dropping
> incoming characters if the screen started scrolling. I only ever used
> ProDOS-based comm software, and I had scrolling problems until I obtained
> enhanced ROMs and a 65C02 for my IIe. If ProDOS had somehow patched the
> buggy firmware out, this wouldn't have been necessary.
>
> _/_
> / v \ Scott Alfter (remove the obvious to send mail)
> \_^_/ rm -rf /bin/laden >What's the most annoying thing on Usenet?
Check out Stockhunt.com, turn $150 into $1,000,000.
It works for Jim Cramer why wont it work for.
Sign up now!
http://www.stockhunt.com/news-letter.aspx
hunt_...@yahoo.com
wrote:
> In article <BKtdk.10220$LG4.7...@nlpi065.nbdc.sbc.com>,
>
> >I'm going way WAY back here...back before the //c, the earliest version
> >of the 80-column firmware had some strange bugs in it, particularly with
> >regard to horizontal position. Most of the unexpected behaviors were
> >cleaned up with the //c ROM, the replacement video ROM in the 'enhanced'
> >][e, and with the IIgs. So the problems only appear in the earliest of
> >][e's, and I think ProDOS actually replaces the 80-column firmware with
> >its own display driver, so under ProDOS it might not even matter. 8-)
>
> If this had been the case, it probably wouldn't have been necessary to
> upgrade the IIe to enhanced firmware to get most comm software running
> right. The biggest problem was that interrupts were disabled for an
> unnecessarily long time. Even at 2400 bps, you'd probably start dropping
> incoming characters if the screen started scrolling. I only ever used
> ProDOS-based comm software, and I had scrolling problems until I obtained
> enhanced ROMs and a 65C02 for my IIe. If ProDOS had somehow patched the
> buggy firmware out, this wouldn't have been necessary.
>
> _/_
> / v \ Scott Alfter (remove the obvious to send mail)
> \_^_/ rm -rf /bin/laden >What's the most annoying thing on Usenet?
Check out Stockhunt.com, turn $150 into $1,000,000.