vm02: calling all IIcs - Take 2

[David Schmenk]

Thanks again to Tom for trying this out. Maybe I can convince him to
try this one out:

http://schmenk.is-a-geek.com/tarfiles/VM02ALPHA3.DSK.zip

I also discovered a couple of other issues now fixed. Certain ROM
routines will disable interrupts. Some of my sample classes that call
ROM routines for low res and hi res graphics all of the sudden stopped
responding to interrupts. I now re-enable interrupts after every native
method. I also discovered that my comparison opcodes would adjust the
stack pointer, then compare the values that were now above the stack.
Tsk, tsk. When an interrupt would occur during the comparison, the
values would get trashed.

Glen Bredon wrote a nifty little TSR style program that would hook the
VBL interrupt to keep time. His notes mentioned problems with various
IIc models. He actually didn't bother calling the mouse firmware to
service the interrupt on a IIc. The VBL interrupt would continue
interrupting anyway. So I now look to see if any hardware claimed the
interrupt. If not, I assume it's the VBL interrupt. Hope this works,

Dave...

[Tom Greene]

Sure thing... alas I didn't get any better results, it still runs fine
on the IIc+ but freezes on the other two ROMs.

One thing I notice with both versions is that keyboard input seems to
extend the run time a bit. That is to say, if I start the helloworld
program and just let it run without touching anything, it runs for
about 30 seconds before freezing. If I start the program and then
pound on the keyboard continuously, it runs about 35 to 40 seconds.

Tom

[mdj]

I wasn't aware of any ROM routine that disabled interrupts without re-
enabling them. At least in a //c, the ROM routines should follow the

PLP
SEI
...
PHP

idiom for interrupt handling to avoid re-enabling in the case where
they were already disabled. If there is one, that counts as a bug
IMO...

Also, re the mouse, there's a particular mouse mode you can call
SETMOUSE in which doesn't require that the requests be handled with a
SERVMOUSE.

It's looking good! Works flawlessly on my IIe (4Mhz Zip Chip on or
off). I'm eagerly awaiting STARTUP protocol support so I can launch
apps via a program selector (and graceful quits of course) :-)

Matt

[David Schmenk]

Hi Tom-

Last time you said it continued to buzz after it stopped responding.
Does it still do this? I thought I caught all cases, unless the mouse
firmware is lying about about the VBL interupt source. Thanks,

Dave...

[David Schmenk]

I am a little puzzled by this as well. The routines in question are the
AppleSoft hires plotting routines and some lo-res routines. Perhaps
there is something else going on here. Issuing a CLI after calling
these routines allowed VBL interrupts to continue, otherwise the ints
stopped. Weird.

>
> Also, re the mouse, there's a particular mouse mode you can call
> SETMOUSE in which doesn't require that the requests be handled with a
> SERVMOUSE.
>

There is a mode (transparent) that automatically updates the screen
holes with the current mouse coordinates. This uses the default
interrupt handler in the system to call SERVEMOUSE as opposed to having
a user installed interrupt handler call SERVEMOUSE. This was for BASIC
support.

I need SERVEMOUSE to tell me if the cause of the interrupt was for a
move or VBL or non of the above. Apparently VBL interrupts don't
require any re-triggering. There might be some timing issue with VBLs
where the mouse firmware won't claim it if the VBL signal goes inactive
before SERVMOUSE is called. Trying to second guess the firmware if
nobody claimed the interrupt seems to be the only option - although this
doesn't appear to work on Tom's machine.

> It's looking good! Works flawlessly on my IIe (4Mhz Zip Chip on or
> off). I'm eagerly awaiting STARTUP protocol support so I can launch
> apps via a program selector (and graceful quits of course) :-)
>
> Matt
>

Thanks, I'll look more into the STARTUP protocol. Which program
selector do you use that implements it? I already parse command line
arguments at the "main class:" prompt, so it shouldn't be a stretch. As
for quits, I'm being a little conservative since I blow away the ProDOS
quit code for my own uses. It will get worse when I use more reserved
ProDOS memory on a 128K machine ;-) Not sure how well ProDOS will
recover after my mucking about.

Dave...

[mdj]

On Aug 29, 9:46 pm, David Schmenk <dschm...@YUCH.gmail.com> wrote:

> Thanks, I'll look more into the STARTUP protocol.  Which program
> selector do you use that implements it?  I already parse command line
> arguments at the "main class:" prompt, so it shouldn't be a stretch.  As
> for quits, I'm being a little conservative since I blow away the ProDOS
> quit code for my own uses.  It will get worse when I use more reserved
> ProDOS memory on a 128K machine ;-)  Not sure how well ProDOS will
> recover after my mucking about.

I use ProSEL, but they all follow the same technique AFAIK. I assume
it's a simple matter of rescanning the input buffer at launch.
BASIC.SYSTEM uses this technique to allow launching BAS and BIN files
from a selector...

I see what you mean with the quit code... Perhaps you could copy it to
the heap area and trash it only when memory becomes tight? As for 128k
systems, that's nice and easy. As long as /RAM is connected when your
SYS program starts, you can disconnect it then reclaim the entire aux
bank for your own purposes. It's only when /RAM is disconnected at
launch that the Aux LC reserved area must be respected.

Matt

[Tom Greene]

Yes, the buzz continues. I take it you haven't had this happen on your
own machines?

Tom

[Michael J. Mahon]

mdj wrote:
> On Aug 29, 9:46 pm, David Schmenk <dschm...@YUCH.gmail.com> wrote:
>
>> Thanks, I'll look more into the STARTUP protocol. Which program
>> selector do you use that implements it? I already parse command line
>> arguments at the "main class:" prompt, so it shouldn't be a stretch. As
>> for quits, I'm being a little conservative since I blow away the ProDOS
>> quit code for my own uses. It will get worse when I use more reserved
>> ProDOS memory on a 128K machine ;-) Not sure how well ProDOS will
>> recover after my mucking about.
>
> I use ProSEL, but they all follow the same technique AFAIK. I assume
> it's a simple matter of rescanning the input buffer at launch.
> BASIC.SYSTEM uses this technique to allow launching BAS and BIN files
> from a selector...

I thought that was done by planting the path at a certain spot a few
byte after $2000 and marked as "present" by a $EE $EE (or something)
sentinel, followed by a length byte and the STARTUP path.

The path is poked into the slot by the selector before handing over
control.

> I see what you mean with the quit code... Perhaps you could copy it to
> the heap area and trash it only when memory becomes tight? As for 128k
> systems, that's nice and easy. As long as /RAM is connected when your
> SYS program starts, you can disconnect it then reclaim the entire aux
> bank for your own purposes. It's only when /RAM is disconnected at
> launch that the Aux LC reserved area must be respected.

Maybe the Quit code should restart the Java environment after an
application runs...

-michael

AppleCrate II: 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."

[mdj]

On Aug 31, 10:37 am, "Michael J. Mahon" <mjma...@aol.com> wrote:
> mdj wrote:
> > On Aug 29, 9:46 pm, David Schmenk <dschm...@YUCH.gmail.com> wrote:
>
> >> Thanks, I'll look more into the STARTUP protocol.  Which program
> >> selector do you use that implements it?  I already parse command line
> >> arguments at the "main class:" prompt, so it shouldn't be a stretch.  As
> >> for quits, I'm being a little conservative since I blow away the ProDOS
> >> quit code for my own uses.  It will get worse when I use more reserved
> >> ProDOS memory on a 128K machine ;-)  Not sure how well ProDOS will
> >> recover after my mucking about.
>
> > I use ProSEL, but they all follow the same technique AFAIK. I assume
> > it's a simple matter of rescanning the input buffer at launch.
> > BASIC.SYSTEM uses this technique to allow launching BAS and BIN files
> > from a selector...
>
> I thought that was done by planting the path at a certain spot a few
> byte after $2000 and marked as "present" by a $EE $EE (or something)
> sentinel, followed by a length byte and the STARTUP path.
>
> The path is poked into the slot by the selector before handing over
> control.

Actually, you're right. I just checked the specifics in the manual.
SYSTEM programs are supposed to start with a JMP instruction, which
can then be followed optionally by $EE $EE following that there would
be a (presumably) 65 byte buffer having the length of the argument
plus the argument (pascal string style)

That being the case, it should be pretty simple to add it to the
loader

> > I see what you mean with the quit code... Perhaps you could copy it to
> > the heap area and trash it only when memory becomes tight? As for 128k
> > systems, that's nice and easy. As long as /RAM is connected when your
> > SYS program starts, you can disconnect it then reclaim the entire aux
> > bank for your own purposes. It's only when /RAM is disconnected at
> > launch that the Aux LC reserved area must be respected.
>
> Maybe the Quit code should restart the Java environment after an
> application runs...

Even better, the loader could save the area to the end of a small
binary program that can sane-ify the environment before issuing a MLI
QUIT

Matt

[David Schmenk]

My IIc and II+ run all day. The good news is the VBL is still active.
I'll work up a scenario to catch it. Thanks for the great feedback.

Dave...

[David Schmenk]

Michael J. Mahon wrote:
> mdj wrote:
>> On Aug 29, 9:46 pm, David Schmenk <dschm...@YUCH.gmail.com> wrote:
>>
>>> Thanks, I'll look more into the STARTUP protocol. Which program
>>> selector do you use that implements it? I already parse command line
>>> arguments at the "main class:" prompt, so it shouldn't be a stretch. As
>>> for quits, I'm being a little conservative since I blow away the ProDOS
>>> quit code for my own uses. It will get worse when I use more reserved
>>> ProDOS memory on a 128K machine ;-) Not sure how well ProDOS will
>>> recover after my mucking about.
>>
>> I use ProSEL, but they all follow the same technique AFAIK. I assume
>> it's a simple matter of rescanning the input buffer at launch.
>> BASIC.SYSTEM uses this technique to allow launching BAS and BIN files
>> from a selector...
>
> I thought that was done by planting the path at a certain spot a few
> byte after $2000 and marked as "present" by a $EE $EE (or something)
> sentinel, followed by a length byte and the STARTUP path.
>
> The path is poked into the slot by the selector before handing over
> control.

I think the ProDOS tech ref or one of the tech notes describes this.
Should be pretty straight forward.

>
>> I see what you mean with the quit code... Perhaps you could copy it to
>> the heap area and trash it only when memory becomes tight? As for 128k
>> systems, that's nice and easy. As long as /RAM is connected when your
>> SYS program starts, you can disconnect it then reclaim the entire aux
>> bank for your own purposes. It's only when /RAM is disconnected at
>> launch that the Aux LC reserved area must be respected.
>
> Maybe the Quit code should restart the Java environment after an
> application runs...
>
> -michael
>
> AppleCrate II: 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."

This makes a lot of sense. I can reload my loader without having to
worry which parts of ProDOS I destroyed ;-)

Dave...

[David Schmenk]

I can add this but I may need some help checking that I got it right.

>>> I see what you mean with the quit code... Perhaps you could copy it to
>>> the heap area and trash it only when memory becomes tight? As for 128k
>>> systems, that's nice and easy. As long as /RAM is connected when your
>>> SYS program starts, you can disconnect it then reclaim the entire aux
>>> bank for your own purposes. It's only when /RAM is disconnected at
>>> launch that the Aux LC reserved area must be respected.
>> Maybe the Quit code should restart the Java environment after an
>> application runs...
>
> Even better, the loader could save the area to the end of a small
> binary program that can sane-ify the environment before issuing a MLI
> QUIT
>
> Matt

That's what rebooting does ;-) I'm unsure (can anyone fill me in?)
about the AUX memory areas used by the RAM disk. I plan on trashing
all of the the AUX LC and MAIN memory areas.

Dave...

[David Schmenk]

So if I find /RAM when I start, I can trash all of AUX - including AUX
LC? I also need to see how the RAMWorks card's /RAM disk shows up
differently than the standard /RAM disk. I have one, I just need to
hook it up someday.

For the quit code, I may restore it in a later version when I implement
memory swapping (swapping the quit code would be easy, then).
Re-launching VM02 may have to suffice for version 1.0.

Dave...

[mdj]

On Sep 2, 11:55 am, David Schmenk <dschm...@YUCH.gmail.com> wrote:
> > Actually, you're right. I just checked the specifics in the manual.
> > SYSTEM programs are supposed to start with a JMP instruction, which
> > can then be followed optionally by $EE $EE following that there would
> > be a (presumably) 65 byte buffer having the length of the argument
> > plus the argument (pascal string style)
>
> > That being the case, it should be pretty simple to add it to the
> > loader
>
> I can add this but I may need some help checking that I got it right.

Too easy... Just post another when you're done and I'll happily test
it...

> >>> I see what you mean with the quit code... Perhaps you could copy it to
> >>> the heap area and trash it only when memory becomes tight? As for 128k
> >>> systems, that's nice and easy. As long as /RAM is connected when your
> >>> SYS program starts, you can disconnect it then reclaim the entire aux
> >>> bank for your own purposes. It's only when /RAM is disconnected at
> >>> launch that the Aux LC reserved area must be respected.
> >> Maybe the Quit code should restart the Java environment after an
> >> application runs...
>
> > Even better, the loader could save the area to the end of a small
> > binary program that can sane-ify the environment before issuing a MLI
> > QUIT
>
> > Matt
>
> That's what rebooting does ;-)  I'm unsure (can anyone fill me in?)
> about the AUX memory areas used by the RAM disk.   I plan on trashing
> all of the the AUX LC and MAIN memory areas.

I suppose I don't really mind if the 64k behaviour is reboot, as long
as the 128k version doesn't break ProDOS at all ... :-)

As for the RAM disk usage of AUX, it's basically all of it, with the
exception of a part of AUX LC Bank 2 (reserved for third party RAM
drivers). The convention is if /RAM is there when your application
starts up, you're free to disconnect it from ProDOS and use the AUX
memory as you see fit. If you want IIc keyboard buffering
compatibility, steer clear of AUX page $02, and respect the AUX
equivalents of the screen holes. Before you quit, you need to
reconnect /RAM, otherwise most applications will refuse to start up.

The only other things to keep in mind: The top two bytes of the AUX
stack are used keep track of the two stack pointers. Since you're
running with interrupts turned on, you'll need to be concerned about
how they get processed in the two possible main area memory
configurations that can exist when the AUX LC is intercepting them.
Oh, and never make a ProDOS MLI call from auxiliary memory.

Matt

[aiia...@gmail.com]

On Sep 1, 7:48 pm, mdj <mdj....@gmail.com> wrote:
> Oh, and never make a ProDOS MLI call from auxiliary memory.

I have a program that will allow ProDOS MLI calls from AUX RAM
(any bank in a RWIII card)

[mdj]

Oh, nice! How did you manage that?

[aiia...@gmail.com]

JSR MLI is
JSR BF00

so at BF00 I put a JMP to my code

it saves return address and current active bank. it then transfers
the MLI code to MAIN RAM, including all parameters.

MAIN RAM is switched in. the prodos call is made. the data is
transferred to the appropriate bank.

the calling AUX bank is restored, along with the RTS address, and
there you go... you just called the MLI from AUX RAM.

I have it working for READ/WRITE/OPEN/CLOSE. I couldn't find a reason
to get any others to work yet.

Rich

[mdj]

Other than CREATE and DESTROY, that seems like enough. Would you be
happy to share this?

Matt

[aiia...@gmail.com]

On Sep 1, 8:25 pm, mdj <mdj....@gmail.com> wrote:
>
> Other than CREATE and DESTROY, that seems like enough. Would you be
> happy to share this?
>

you'll have to pay the $100000000000000000000000000 licensing fee.

(just kidding)

send me email aiiadict AT gmail DAWT calm

[aiia...@gmail.com]

On Sep 1, 8:33 pm, aiiad...@gmail.com wrote:
> > Other than CREATE and DESTROY, that seems like enough. Would you be
> > happy to share this?
>

what would you want to use such a silly program for? (you're the
first
to show any interest besides Oliver who does Contiki)

[David Schmenk]

Good. I can work that just fine.

> If you want IIc keyboard buffering
> compatibility, steer clear of AUX page $02, and respect the AUX
> equivalents of the screen holes. Before you quit, you need to
> reconnect /RAM, otherwise most applications will refuse to start up.
>

I will handle the IIc keyboard interrupts myself and leave the AUX
screen holes alone.

> The only other things to keep in mind: The top two bytes of the AUX
> stack are used keep track of the two stack pointers. Since you're
> running with interrupts turned on, you'll need to be concerned about
> how they get processed in the two possible main area memory
> configurations that can exist when the AUX LC is intercepting them.
> Oh, and never make a ProDOS MLI call from auxiliary memory.
>
> Matt

Right. I need to remember the stack pointer thing as I swap them around
a lot during thread switching. Matt, you are definitely a wealth of
information.

Dave...

[David Wilson]

On Sep 2, 12:15 pm, David Schmenk <dschm...@YUCH.gmail.com> wrote:
> So if I find /RAM when I start, I can trash all of AUX - including AUX
> LC?

Pretty much. In addition to the areas others have mentioned, if you
overwrite LC card page FF remember that there is a copy of the IRQ
vector you will need to avoid if you want to use interrupts while AUX
LC is banked in.