Strange behavior in AppleWin?

[James Davis]

To the AppleWin team:

In my experimentation with running the various Apple II models in AppleWin (version 1.27.0.0), the Apple II (original) and the Apple II Plus, do not seem to work right when I try to boot them using my (ProDOS-8 J.B. version 2.4.2) 32MB hard disk drive (*.HDV) image (in slot 7, drive 1), [the A2 just boots from slot 6 and the A2+ hangs up trying to boot from slot 7], but do work when booting from the "APPLE DOS 3.3 SYSTEM MASTER.dsk" or the (John Brooks) "ProDOS-8 2.4.2.dsk" (in slot 6, drive 1, and with slot 7 disabled).

With the original Apple II, once it drops into the Old Monitor ROM, I am using 7<ctrl-P> to boot slot 7, but it drops to slot 6 to boot, like slot 7 isn't there even though it is enabled.

With the Apple II Plus, I have to click the Apple ("F2") icon two times to get it to boot from slot 6, when slot 7 is enabled and AppleWin is trying and failing to boot from slot 7. On the first attempt to boot, after the first click of the Apple icon, the indicators are flashing "T0/S0 T0/S??" very rapidly (max. speed), then the second click boots from slot 6.

Is this by design, or is it strange behavior?

[Or, is this an indication that my hard drive image is going bad?]

James Davis

[sicklittlemonkey]

On Sunday, 11 March 2018 14:43:38 UTC+13, James Davis wrote:
> In my experimentation with running the various Apple II models in AppleWin (version 1.27.0.0), the Apple II (original) and the Apple II Plus, do not seem to work right

What happens when you boot in the //e modes?

The HD image (.PO) that I'm using works fine in the II modes, so I suspect your image.

There are a few quirks to the HD firmware but it doesn't use 65C02 opcodes or anything.

Cheers,
Nick.

[James Davis]

When I boot in the //e modes, original or enhanced, everything works as expected. I just noticed this recently while analyzing the original Apple II System Monitor and the Apple II Plus Monitor II using AppleWin 1.27.0.0 and comparing them to what is printed in my reference manuals.

I replaced (copied over) ProDOS and Basic.System and ProSel.System (And, maybe more; I don't remember for sure.) with backups/originals from the disk images they originally came from, but it had no effect and did not eliminate the problem. I am wondering if one of the other .System files, down the road in the boot process, may be the culprit. This is the order I have them in:

"PRODOS" "SYS" "$0000" 18-Jan-18 07:00 ProDOS 17128
"NS.CLOCK.SYSTEM" "SYS" "$2000" 28-Apr-91 23:18 ProDOS 1536
"PROSEL.SYSTEM" "SYS" "$2000" 01-Apr-88 14:05 ProDOS 512
"SELECT.SYSTEM" "SYS" "$2000" 23-Nov-86 17:31 ProDOS 1019
"LAUNCHER.SYSTEM" "SYS" "$0800" 02-Mar-92 10:49 ProDOS 7468
"SYSUTIL.SYSTEM" "SYS" "$B800" 03-Mar-88 09:37 ProDOS 782
"FASTCOPY.SYSTEM" "SYS" "$2000" 27-Feb-92 15:42 ProDOS 20054
"BASIC.SYSTEM" "SYS" "$2000" 30-Aug-16 07:56 ProDOS 10240
"BOOT.SYSTEM" "SYS" "$2000" 15-Sep-16 09:49 ProDOS 365
"QUIT.SYSTEM" "SYS" "$2000" 15-Sep-16 09:41 ProDOS 56
"SWU.SYSTEM" "SYS" "$0000" 08-Dec-87 22:48 ProDOS 2048
"NS.CLOCK.UTILS" "SYS" "$2000" 21-Apr-91 21:43 ProDOS 5519

It is probably the NS.CLOCK.SYSTEM file that is not working with the A2/A2+ modes. It flashes something on the screen just before everything hangs. ProSel.System never happens.

[Michael J. Mahon]

Try deleting NS.CLOCK.SYSTEM.

--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com

[James Davis]

On Sunday, March 11, 2018 at 10:24:03 PM UTC-7, Michael J. Mahon wrote:

> Try deleting NS.CLOCK.SYSTEM.
>
> --
> -michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com

I don't have to delete it. I can just move it down the list with CatDr, then test again.

[gid...@sasktel.net]

You don't even have to do that. Just rename it.

[Michael J. Mahon]

Agreed!

So, did it work? ;-)

[James Davis]

The problem boils down to the fact that the Apple II (original) and Apple II Plus modes on AppleWin are 64K, and not 128K, machines. Most of the *.SYSTEM files in my list either want to run on an Apple IIe or on a 128K machine. John Brooks Bitsy Bye, QUIT.SYSTEM followed by BOOT.SYSTEM (BB renamed), works well for the older Apple II/+ modes. Most of the other SYS files return you to it, or tell you why they don't work on an Apple II/+. ProSel hangs or boots slot 6 next depending on which mode you use.

It would be nice if there were options to set up the older mode machines as 64K or 128K machines with either the opposite language card, an 80-column card (also missing), an extended 80-column card (missing also), or a >64K RAM card (e.g., RamFactor/RamWorks), like the Apple IIe modes have. Back in the day, everyone I knew with an Apple II/+ got all those cards for their machines as soon as they became available, so why not include the options for them in AppleWin?! We still need a way to emulate other real hardware (and/or peripheral card) setups in AppleWin!

[Michael AppleWin Debugger Dev]

> It would be nice if there were options to set up the older mode machines as 64K or 128K machines

> or a >64K RAM card (e.g., RamFactor/RamWorks)

You mean with the GUI?

Currently you need to use the command line to enable RamWorks.

(Saturn support is currently a Work-In-Progress.)

> We still need a way to emulate other real hardware (and/or peripheral card) setups in AppleWin!

I think what you are getting at is a way to streamline the entire virtual configuration visually making it "plug and play". Yeah, the configuration is definitely not as easy as it could/should be.

Q. Which peripheral's support is still missing?

[James Davis]

Michael,

On Wednesday, March 14, 2018 at 8:56:36 AM UTC-7, Michael AppleWin Debugger Dev wrote:
> > It would be nice if there were options to set up the older mode machines as 64K or 128K machines
> > or a >64K RAM card (e.g., RamFactor/RamWorks)
>
> You mean with the GUI?
>

I suppose so, but not necessarily.

> Currently you need to use the command line to enable RamWorks.
>

Okay, I didn't think of that! But, the Apple II/II+/IIe/eIIe model to start up with needs to be included in the command line options. As it is now, Applewin starts up in the model last used; unless, you have a saved state set up already (to load in) with the -r option in the command line, too.

Then also, the "Help" "Command Line' page needs to have some examples showing how to setup machines corresponding to some real world possibilities (e.g., various models with various amounts of RAM and with various peripheral cards (and their slot); all of which need to be included in the command line options, too).

> (Saturn support is currently a Work-In-Progress.)
>

Good! I don't use the sound features, so I would like to have two 3.5" flippy drives in slot 5, but other people might want to have them in some other slot that corresponds to all possible real setups.--(This also applies to all possible types of peripheral cards.)

>
> > We still need a way to emulate other real hardware (and/or peripheral card) setups in AppleWin!
>
> I think what you are getting at is a way to streamline the entire virtual configuration visually making it "plug and play". Yeah, the configuration is definitely not as easy as it could/should be.
>

Yes, GUI again. The AGAT emulator has a settings dialog-box that allows one to setup what type of peripheral card is in each slot, but it is too limiting, also. It does not allow for all possible combinations/permutations corresponding to real hardware, only what is thought to be the most popular setups (in Eastern Europe). You might want to take a look at it to stimulate your ideas for a 'Setup Interfaces' control panel page in AppleWin.

> Q. Which peripheral's support is still missing?

A: Every peripheral card for the Apple II line ever made. I realize that this is practically impossible, but if all of us Apple II Enthusiasts were to contribute ROM images of our real hardware, and any peripheral card schematics we have, and find all such information that is already out there, and submit it to the AppleWin team, then you could (get more {qualified} volunteers to) analyze it and make it into packages that could be incorporated into AppleWin.

If and when I ever get a proper setup (an ADT setup that works) to do this with my real hardware, then I will also contribute what I can.

This is my current/last peripherals setup:

(I couldn't find it. It is in one of my previous posts to comp.emulators.apple2, though. It is a {Robert S. Claney} SlotScan.)

Found! You can find it here:

https://groups.google.com/forum/#!searchin/comp.emulators.apple2/Robert$20S.$20Claney/comp.emulators.apple2/Ko_0sO81kfg/TajOJAzvAQAJ

This (document) is what I do have, though:

======================================================================
Currently not for sale, my main Enhanced Apple IIe system consists of:
======================================================================
8-MHz ZipChip.
The shift key mod on the motherboard is jumpered.
The 16-pin Game Port has an S.C.R.G. Paddle-Addaple attached.
The Auxiliary Slot has the AE 1-Meg RamWorks III with 2-Meg Plus and the ColorLink RGB with Magnavox RGB (CRT) monitor attached.
Slot 1 has an Epson APL parallel printer interface card with Epson MX-100 Printer attached. (This got zapped last year when I was removing the computers top cover during static electricity season!)
Slot 2 has an AE DataLink 2400 Rev.C MoDem. (This will eventually be replaced by an SSC.)
Slot 3 has an S.C.R.G. Slot-3-Clock (with a dead battery).
At one time, Slot 4 had a Laser UDC with 2 Laser 3.5" drives attached. (Moved to slot 5.)
Now, Slot 4 has my mystery card?--I don't remember what's in there!--I think I added more Mega-RAM from AE, maybe. (What this really is, is in the previous post.)
At one time, Slot 5 had the Call—A.P.P.L.E. BigBoard (1-Meg RAM Disk) by ADON Corp. (Removed.)
Now, Slot 5 has a Laser UDC with 2 Laser 3.5" drives attached.
Slot 6 has a Disk II controller card by Fourth Dimensions with 2 Gamma 5.25" half—height drives attached.
Slot 7 has a Xebec Rev.H SASI card with FCP Sider D4T hard drive and T6 tape backup attached.
Two sets of dual-paddles and a joystick.
Tandy Power Switching System (switches everything on/off at once or individually).
And, hundreds of Apple II books/magazines (and personal creations).
======================================================================

I hope this helps you. [Even if it is to general. :-)]

James Davis

[James Davis]

On Wednesday, March 14, 2018 at 8:56:36 AM UTC-7, Michael AppleWin Debugger Dev wrote:

> Currently you need to use the command line to enable RamWorks.

The AppleWin Apple II/II+ modes are 64k machines only according to the help, so all my experiments with the -r -load-state <savestate> options on those modes have been a waste of time!

[gid...@sasktel.net]

> > Currently you need to use the command line to enable RamWorks.
>
> The AppleWin Apple II/II+ modes are 64k machines only according to the help, so all my experiments with the -r -load-state <savestate> options on those modes have been a waste of time!

There is a way to turn a IIe into a II+. In one of the Nibble magazines shows the ROM differences and allows one to replace the code of the IIe ROM and save it in the Language card (Dos 3.3 only).

A way to turn a 128 kb IIe into a 64 kb IIe is to remove the memory check for auxilliary Ram or if a comment comes up that Aux Ram is used by a Ramdisk, disable it y/n?, then refuse to allow the program access to use it.

[James Davis]

That is not what is needed!

AppleWin needs a slot 0 for the 'Apple II (original)' and 'Apple II Plus' modes that functions just like the real thing.

Then it needs the options of being a 64k machine, or a 64k machine with an Applesoft BASIC (slot 0) card for the 'Apple II' mode, or a 64k machine with an Integer BASIC (slot 0) card for the 'Apple II Plus' mode, or a 128k machine using a (slot 0) 64k Language Card for either mode, or a >128k machine using a (slot 0) RAM card for either mode.

AppleWin also needs to be able to run multiple instances that use separate windows registry entries so that they do not interfere with each other. That way, one could run an AppleWin instance for each mode at the same time (e.g., to test Apple II programs in each mode for immediate comparisons). Either that, or just have 2-4 AppleWin versions [4 versions: one for each mode; or 2 versions: one version for the II & II+ modes and one version for the IIe & eIIe modes, both with the same ability to run multiple instances (e.g., to test Apple II programs in each mode for immediate comparisons {again})].

[James Davis]

P.S. I forgot to include the 80-column and Extended RAM 80-column cards in that list of slot 0 cards. Although, IIRC, the latter is also known as the Language Card.

[sicklittlemonkey]

On Friday, 16 March 2018 08:43:04 UTC+13, James Davis wrote:
> That is not what is needed!
>
> AppleWin needs a slot 0 for the 'Apple II (original)' and 'Apple II Plus' modes that functions just like the real thing.

I'm still a little hazy on exactly what is needed.

First you talk about SYSTEM files wanting 128k. That doesn't necessarily mean they'll run on a II or II+ that has 128k.

Which software do you want to get working on AppleWin in II or II+ modes that works on a real machine but not in AppleWin?

Cheers,
Nick.

[Brian Patrie]

On 2018-03-15 14:43, James Davis wrote:
> Then [AppleWin] needs the options of being a 64k machine, or a 64k

> machine with an Applesoft BASIC (slot 0) card for the 'Apple II' mode,
> or a 64k machine with an Integer BASIC (slot 0) card for the 'Apple II
> Plus' mode, or a 128k machine using a (slot 0) 64k Language Card for
> either mode, or a >128k machine using a (slot 0) RAM card for either
> mode.

The only way to have a 64k II or II+ is to have either the Language
(RAM) card, or the firmware card in a slot other than 0--which is the
normal location for both of them. (Now i'm wondering how many
programmes will actually look for them in other slots.)

[Brian Patrie]

This is a little confusing.

"Language Card" normally refers to the slot 0 16k RAM cards. (They're
called that, because they allow loading another language (e.g.
AppleSoft, Interger BASIC, Pascal).) These are not 80-column cards
(which, in the II,II+ normally go in slot 3).

If by "80-column and Extended RAM 80-column cards", you mean the IIe
80-column cards, those are Aux slot cards--not slot 0. They are not
applicable to the II,II+--and, consequently, those modes of AppleWin.

(It might be fun to have II,II+ 80 and 132 column card emulation in
AppleWin; but i suspect that it's a very low priority.)

[Michael AppleWin Debugger Dev]

Disk Muncher does/did.

Back in the day as a kid I added 3 (or 4x?)16KB Language Cards to my ][+ to get 96 KB+! Couldn't quite get a full disk copy in 1 pass (since I didn't understand 140KB disk capacity at the time) but it was cool before things started getting "toasty." ;-)

[Michael AppleWin Debugger Dev]

What are these cards you are referring to???

* Applesoft BASIC (slot 0) cards
* Integer BASIC (slot 0) card

The 16 KB Language Card is just RAM. If you want them "preloaded" at boot time we could maybe look into adding a command line to load from a 16 KB file.


> for the 128k machine using a (slot 0) 64k Language Card for either mode

That's one of the reasons I'm adding 128 KB Saturn support -- so the Apple ][ and ][+ have extra memory to play with.

[Michael AppleWin Debugger Dev]

Nick, that's a great question.

Normally I'd agree with you and say "Just use the bloody //e confit already!" -- and that's someone who was one of the ][+ hold-outs!

But from I can gather the use case is for testing.

I.e. Start up 4 copies of the emulator at the *same* time:

* Apple ][
* Apple ][+
* Apple //e (original)
* Apple //e (enhanced)

When I was writing my 6502 Linux Logo it was a bit of a PITA to keep switching models to verify my machine identification code was working properly -- sometimes I'd forget I was in one model thinking I was in a different model.

The lack of RAM in the ][, and ][+ puts a bit of a damper on this simultaneously testing.

[James Davis]

Michael,

After Apple Computer, Inc. created the Apple II Plus they created the Integer BASIC ROM card for people to make it backwards compatible with the original Apple II. IIRC, they also created a similar Applesoft ROM card for the original Apple II to make it forward compatible with the Apple II Plus.

I am sorry about the confusion. I forgot that these ROM (fixed language) cards and the RAM (any) Language Card were 16k, not 64k cards. But, they went into slot 0, IIRC. I haven't had my hands on a real original (Integer BASIC) Apple II nor a real Apple II Plus since 1985. I also forget whether they had 80-column capability back then, but I thought they did because I have been using a real Enhanced Apple IIe with 80-column capability for so long (since 1985 until 1997) that I can't remember not having it.

Maybe the AppleWin Apple II/II+ modes already have a 16k RAM Language Card built in, and I am wrong, because after booting them with the APPLE DOS 3.3 SYSTEM MASTER.dsk, it is possible to switch back and forth between Integer BASIC and Applesoft BASIC; but, before booting DOS, the Apple II is strictly an Old Monitor & Integer BASIC machine. and the Apple II Plus is strictly an Autostart monitor & Applesoft BASIC machine, (except if you are using the Freeze's ROM). If they were configurable with the ROM cards instead, they could switch languages just using the FP & INT commands from the get-go without DOS having been booted.--[From an AppleWin POV (programming/making it), FP & INT could just switch between Apple II/II+ modes. Didn't the original hardware work this way? Or, did you have to use a peek/poke? Depending on the back-panel switch?]--Although, this might not be very practical without having DOS up and running; I suppose the way it works now with DOS up, is good enough.

When you said, "Saturn," I thought 3.5" Flippy Disk Drive(s), not 128k RAM card.
I have two of their drives, but I am not familiar with Saturn RAM.

I'll continue this later. It's suppertime.

James Davis

[gid...@sasktel.net]

The only difference between a slot #0 II/II+ and a IIe is the monitor/applesoft ROM. The slot#0 with a 16kb card works exactly the same as a IIe language card.

The IIe has the option to become a 64kb machine. Just don't use the code to look for extra memory. It is the same with an extended RamWorks card. You don't know it's there til you use the software to check for it.

Also a IIe in Integer Basic is exactly the same as a II/II+ in Integer Basic due to applesoft ROM being switched out and both are using the language card which works exactly the same on all 3 machines.

For all intense and purposes, you have everything you need to do everything you are asking and is exactly what is needed.

[Brian Patrie]

On 2018-03-15 22:51, James Davis wrote:
> If [AppleWin's II/II+ modes] were configurable with the ROM cards

> instead, they could switch languages just using the FP & INT commands
> from the get-go without DOS having been booted.--[From an AppleWin POV
> (programming/making it), FP & INT could just switch between Apple
> II/II+ modes. Didn't the original hardware work this way? Or, did
> you have to use a peek/poke? Depending on the back-panel switch?]--
> Although, this might not be very practical without having DOS up and
> running; I suppose the way it works now with DOS up, is good enough.

> INT & FP are DOS commands; so they're not available just booting to
> ROM. But, it /would/ save loading the other language from disk.

Without DOS, it would be possible to make a little machine language
program that hits the appropriate softswitch trigger to read from the
bank that you want, then JMP to $E000:

0300: 8D 80 C0 STA $C080 ;CALL 768 to start card BASIC
0303: 4C 00 E0 JMP $E000
0306: 8D 81 C0 STA $C081 ;CALL 774 to start motherboard BASIC
0309: 4C 00 E0 JMP $E000

Or maybe even from the System Monitor, with:

C080:0 ^B

to start the BASIC on the card.

C081:0 ^B

to start the BASIC on the motherboard.

(I tried these in II mode, with the 42-sector FPBASIC loaded into the
language card, so the Monitor is copied from ROM. With a firmware card
(or the 50-sector FPBASIC/INTBASIC), it will be the older or newer
Monitor, so switching mid-parse might end badly. Attempting it from
BASIC certainly would. The ML version is definitely safe.)

[Gee whiz. i kinda geeked out on this one.
Hope it's not in information overload.]

[Michael AppleWin Debugger Dev]

More technical details are always preferred over incomplete, non-technical ones -- it helps avoid ambiguities.

[James Davis]

That is very:

in•tense \in-"tens\ adj 1 : existing in an extreme degree 2 : marked by great zeal, energy, or eagerness 3 : showing strong feeling; also : deeply felt — in•tense•ly adv

(c)2000 Zane Publishing, Inc. and Merriam-Webster, Incorporated. All rights reserved

I think you meant:

1) in•tent \in-"tent\ n 1 : the state of mind with which an act is done : volition 2 : purpose, aim 3 : meaning, significance

(c)2000 Zane Publishing, Inc. and Merriam-Webster, Incorporated. All rights reserved

and/or:

2) intent adj 1 : directed with keen attention <an ~ gaze> 2 : engrossed; also : determined — in•tent•ly adv — in•tent•ness n

(c)2000 Zane Publishing, Inc. and Merriam-Webster, Incorporated. All rights reserved


;-D

[James Davis]

Nothing in particular. I was just trying to figure out why my hard disk image wouldn't boot completely using the AppleWin II/II+ modes. It is because most of the system files in the boot chain are made for an Apple IIe with ProDOS, not for the older machine modes. The only system that really worked was John Brooks' Bitsy Bye.

[James Davis]

On Thursday, March 15, 2018 at 11:10:30 PM UTC-7, Brian Patrie wrote:
> On 2018-03-15 22:51, James Davis wrote:
> > If [AppleWin's II/II+ modes] were configurable with the ROM cards
> > instead, they could switch languages just using the FP & INT commands
> > from the get-go without DOS having been booted.--[From an AppleWin POV
> > (programming/making it), FP & INT could just switch between Apple
> > II/II+ modes. Didn't the original hardware work this way? Or, did
> > you have to use a peek/poke? Depending on the back-panel switch?]--
> > Although, this might not be very practical without having DOS up and
> > running; I suppose the way it works now with DOS up, is good enough.

I did not say this, it must be part of your response:

> > INT & FP are DOS commands; so they're not available just booting to
> > ROM. But, it /would/ save loading the other language from disk.

More of your response:

> Without DOS, it would be possible to make a little machine language
> program that hits the appropriate softswitch trigger to read from the
> bank that you want, then JMP to $E000:
>
> 0300: 8D 80 C0 STA $C080 ;CALL 768 to start card BASIC
> 0303: 4C 00 E0 JMP $E000
> 0306: 8D 81 C0 STA $C081 ;CALL 774 to start motherboard BASIC
> 0309: 4C 00 E0 JMP $E000
>
> Or maybe even from the System Monitor, with:
>
> C080:0 ^B
>
> to start the BASIC on the card.
>
> C081:0 ^B
>
> to start the BASIC on the motherboard.

Thanks for that. It is good to be reminded how it all works.

I don't quite understand what you did here:

> (I tried these in II mode, with the 42-sector FPBASIC loaded into the
> language card, so the Monitor is copied from ROM. With a firmware card
> (or the 50-sector FPBASIC/INTBASIC), it will be the older or newer
> Monitor, so switching mid-parse might end badly. Attempting it from
> BASIC certainly would. The ML version is definitely safe.)
>
> [Gee whiz. i kinda geeked out on this one.
> Hope it's not in information overload.]

Just the last part.

[James Davis]

On Friday, March 16, 2018 at 6:29:13 AM UTC-7, Michael AppleWin Debugger Dev wrote:
> More technical details are always preferred over incomplete, non-technical ones -- it helps avoid ambiguities.

Sorry Michael, and to everyone else here:

I seem to be harping on in generalities. I guess I got a little confused about how the Apple II/II+ and the AppleWin II/II+ modes really work(ed). And, about the 80-column cards versus 64K RAM cards for those machines versus the Apple IIe. I know I had a Lower Case Adapter on my Apple II Plus, but I don't remember if it and my friends Apple II (Old Monitor ROM & Integer BASIC machine) had any kind of 80-column adapter/card/capability.

James Davis

[Michael AppleWin Debugger Dev]

There were 80-column cards for the Apple ][+ -- I used to run WordStar CP/M (with a Z80 add on card back) in the mid 80's in 80 column mode (ugh, enough 80s!) but I don't recall who made it or what model it was. It was probably some no-name clone. I think I might still have a few left in the garage -- I'll have to dig them up.

With the //e model Apple standardized the expansion RAM and 80-cols since everyone and their dog was producing slightly incompatible ones.

[gid...@sasktel.net]

> > For all intense and purposes, you have everything you need to do everything you are asking and is exactly what is needed.
>
> That is very:
>
> in•tense \in-"tens\ adj 1 : existing in an extreme degree 2 : marked by great zeal, energy, or eagerness 3 : showing strong feeling; also : deeply felt — in•tense•ly adv
> 
> (c)2000 Zane Publishing, Inc. and Merriam-Webster, Incorporated. All rights reserved
>
> I think you meant:
>
> 1) in•tent \in-"tent\ n 1 : the state of mind with which an act is done : volition 2 : purpose, aim 3 : meaning, significance
>
> (c)2000 Zane Publishing, Inc. and Merriam-Webster, Incorporated. All rights reserved
>
> and/or:
>
> 2) intent adj 1 : directed with keen attention <an ~ gaze> 2 : engrossed; also : determined — in•tent•ly adv — in•tent•ness n
>
> (c)2000 Zane Publishing, Inc. and Merriam-Webster, Incorporated. All rights reserved
>

I meant "intense". I was going to originally write "For all intense purposes", that is just my light sense of humor if you can recognize it.

Just an FYI from one of your other posts. I can't speak for Dos 3.3 as I don't deal with it much, and it may have a built in "FP" command, but "FP" is also a built in command in Integer Basic to engage Applesoft. My Prodos version of Integer Basic uses it to go to Applesoft (I didn't program that into it).

And Applesoft already has an "INT" command for other purposes, which is probably the reason it is built into Dos3.3 and why I coded the ampersand under Applesoft to re-enter Integer Basic.

[gid...@sasktel.net]

> > For all intense and purposes, you have everything you need to do everything you are asking and is exactly what is needed.
>
> That is very:
>
> in•tense \in-"tens\ adj 1 : existing in an extreme degree 2 : marked by great zeal, energy, or eagerness 3 : showing strong feeling; also : deeply felt — in•tense•ly adv
> 
> (c)2000 Zane Publishing, Inc. and Merriam-Webster, Incorporated. All rights reserved
>
> I think you meant:
>
> 1) in•tent \in-"tent\ n 1 : the state of mind with which an act is done : volition 2 : purpose, aim 3 : meaning, significance
>
> (c)2000 Zane Publishing, Inc. and Merriam-Webster, Incorporated. All rights reserved
>
> and/or:
>
> 2) intent adj 1 : directed with keen attention <an ~ gaze> 2 : engrossed; also : determined — in•tent•ly adv — in•tent•ness n
>
> (c)2000 Zane Publishing, Inc. and Merriam-Webster, Incorporated. All rights reserved
>

[James Davis]

"For all intense purposes", with an emojie [e.g., ;-D ] or a "Ha! Ha! ..." would be more recognizable as humor, but it's cool, I like it. The dictionary thing was humor too.

Yeah, INT and FP are built into the BASICs, but they don't seem to work in AppleWin (all modes) unless DOS is booted up and the alternate BASIC has been loaded in via the HELLO program. If they were DOS commands they would need to be put in a print statement preceded by a control-D [e.g., Print Chr$(4);"FP" or Print Chr$(4);"INT"], right? Do they have a page 3 vector that DOS hooks into them with? If they did, you could use it instead of the ampersand vector. The Apple II/II+ and DOS page 3 vectors are listed in chapter XIII of the old What's Where in the Apple, volume 1. The DOS HELLO program that loads in the BASICs might have some clue to how the switch is implemented.--Just an idea.

[James Davis]

On Thursday, March 15, 2018 at 3:04:19 PM UTC-7, sicklittlemonkey wrote:

Nick,

Who are you, really? I don't mean to offend you, but every time I see your "sicklittlemonkey" handle, it makes me think you are some kind of pedifile or child pornographer or something sinister, like that. It makes me nausious. And, I wonder why the proper authorities haven't been knocking at your door.

James Davis

[gid...@sasktel.net]

Prodos doesn't have either command in its vocabulary, so there are no hooks. And I don't think they were meant to be used as a disk command, just at the prompt.

It seems kind of redundant to me to have an applesoft basic program enter integer basic from a running applesoft program and vice versa. And doing a ?CHR$(4)"FP" in an applesoft program is the same as typing NEW.

I really don't know what Apple's thought process was here.

[Brian Patrie]

On 2018-03-16 12:38, James Davis wrote:
> I did not say this, it must be part of your response:
>
>> > INT & FP are DOS commands; so they're not available just booting to
>> > ROM. But, it /would/ save loading the other language from disk.

You're right; that is part of my response. I apparently goofed whilst
editing, and joined it to the quote. Sorry 'bout that.

> More of your response:
>
>> Without DOS, it would be possible to make a little machine language
>> program that hits the appropriate softswitch trigger to read from the
>> bank that you want, then JMP to $E000:
>>
>> 0300: 8D 80 C0 STA $C080 ;CALL 768 to start card BASIC
>> 0303: 4C 00 E0 JMP $E000
>> 0306: 8D 81 C0 STA $C081 ;CALL 774 to start motherboard BASIC
>> 0309: 4C 00 E0 JMP $E000
>>
>> Or maybe even from the System Monitor, with:
>>
>> C080:0 ^B
>>
>> to start the BASIC on the card.
>>
>> C081:0 ^B
>>
>> to start the BASIC on the motherboard.
>
> Thanks for that. It is good to be reminded how it all works.
>
> I don't quite understand what you did here:
>
>> (I tried these in II mode, with the 42-sector FPBASIC loaded into the
>> language card, so the Monitor is copied from ROM. With a firmware card
>> (or the 50-sector FPBASIC/INTBASIC), it will be the older or newer
>> Monitor, so switching mid-parse might end badly. Attempting it from
>> BASIC certainly would. The ML version is definitely safe.)

Without having an actual II with AppleSoft Firmware Card config to work
with, i faked it by booting the january 1983 edition of the DOS 3.3
System Master, to load FPBASIC into the Language Card (LCRAM). The way
this version of the System Master does this is by loading only the 10k
BASIC part of the ROM from disk, and completing the image in LCRAM by
copying the remaining 2k from the machine's ROM. This means that the
System Monitor in LCRAM is identical to the one in ROM, so switching
between them whilst its parser is running (processing the command line)
is sure to go down without a hitch.

In the case of an actual (or emulated) firmware card, there might be
enough difference between the two that changing ROMs whilst code in
those ROMs is running could make the Monitor command method crash.

Since the machine language version is running from an area of memory
that is not being switched, it is safe from this issue.

[Brian Patrie]

On 2018-03-16 21:32, James Davis wrote:
> Who are you, really? I don't mean to offend you, but every time I see your "sicklittlemonkey" handle, it makes me think you are some kind of pedifile or child pornographer or something sinister, like that. It makes me nausious. And, I wonder why the proper authorities haven't been knocking at your door.

There are many forms of sickness that are not paedophilia (or
pedophilia, if you prefer; but not to be confused with pediphilia--which
is foot fetishism)

That said, i'm suspect that they're being facetious with their nym. :)

[Nick Westgate]

On Saturday, 17 March 2018 15:32:46 UTC+13, James Davis wrote:
> Who are you, really? I don't mean to offend you, but every time I see your "sicklittlemonkey" handle, it makes me think [...]

It's just a handle. (A reference to The Ren & Stimpy Show.)

But thanks for the reminder. Google Groups just shows "me" as the author for my posts, so I'd forgotten it was still set. I've changed it to my real name, as I did for CSA2 some time back.

Anyway, we've corresponded before. I dabble with emulators when I have time.

Cheers,
Nick.

[James Davis]

Thanks for the spelling correction. I couldn't find the proper spelling of 'pedifile' nor 'nausious' in my dictionary, so I just went with those spellings.

[James Davis]

I have never seen nor heard of that show. I suppose if I had seen it I might feel differently about the handle. Sorry, but I just had to tell you the truth.

[James Davis]

Now, I understand what you did.

Booting the "Apple DOS 3.3 January 1983.dsk" with AppleWin II/II+ modes, loads in the opposite/appropriate BASIC, but I will have to go back and see how the Monitors are affected. I suspect that the Old Monitor will be loaded along with Integer BASIC when AppleWin is in the Apple II+ mode and that the Autostart Monitor will be loaded along with Applesoft BASIC when AppleWin is in the Apple II mode; but if not, then pressing 'Reset' (ctrl-break) will always land you in the Old Monitor ("*" prompt) in the AppleWin Apple II mode (and especially for the testing if you are in FP/Applesoft when you do it), and vice-versa, pressing 'Reset' will always land you at the current BASIC prompt in AppleWin Apple II+ mode (and especially for the testing if you are in INT/Integer BASIC when you do it); otherwise, just the opposite will occur in each case.

[James Davis]

On Saturday, March 17, 2018 at 9:46:24 AM UTC-7, James Davis wrote:
> Now, I understand what you did.
>
> Booting the "Apple DOS 3.3 January 1983.dsk" with AppleWin II/II+ modes, loads in the opposite/appropriate BASIC, but I will have to go back and see how the Monitors are affected. I suspect that the Old Monitor will be loaded along with Integer BASIC when AppleWin is in the Apple II+ mode and that the Autostart Monitor will be loaded along with Applesoft BASIC when AppleWin is in the Apple II mode; but if not, then pressing 'Reset' (ctrl-break) will always land you in the Old Monitor ("*" prompt) in the AppleWin Apple II mode (and especially for the testing if you are in FP/Applesoft when you do it), and vice-versa, pressing 'Reset' will always land you at the current BASIC prompt in AppleWin Apple II+ mode (and especially for the testing if you are in INT/Integer BASIC when you do it); otherwise, just the opposite will occur in each case.

Results: (I suspected wrongly, the 'but if not, ...' occurs in each case.)

Each modes ROM ($F800~$FFFF) Monitor remains in force (after the language is loaded and/or after a 'reset'). [I also looked at the $FFFA~$FFFF NMI/RESET/IRQ vectors to identify the specific Monitor there.]

The Autostart Monitor IS NOT LOADED along with Applesoft BASIC when AppleWin is in the Apple II mode! And, Applesoft is not re-invoke-able with 'FP' after a 'reset' and 'ctrl-C' warm start of Integer BASIC. You have to reboot the DOS Master disk-image to re-install Applesoft. [And: The page 3 ($03D0~$03FF) DOS vectors were not destroyed. (They are destroyed when pressing the AppleWin Reset (F2) button.)]

The Old Monitor IS NOT LOADED along with Integer BASIC when AppleWin is in the Apple II+ mode! And, Integer BASIC is not lost after either a 'reset' and 'ctrl-C' warm start of whichever BASIC was active at the time of the 'reset' nor after a 'ctrl-B' cold start of the current BASIC after it. [Again: The page 3 ($03D0~$03FF) DOS vectors were not destroyed. (They are destroyed when pressing the AppleWin Reset (F2) button.)]


Which brings up the questions:

Where in RAM are these opposite BASIC languages? Are they parallel to their counterparts (e.g., in the {emulated} 16k language card RAM)? Or, are they in the lower 48k somewhere? [I thought it would be the former case, but now I am not sure. {I have got to quit making such assumptions!}] [Aside: If the language loader puts the language in the lower 48k somewhere, then why won't it work under ProDOS? Is ProDOS using the same space?]

I don't know the answers to these questions. Does anybody have an answer to these questions? Is there any Apple Computer, Inc. documentation about this (real hardware)? Is there any AppleWin documentation about this (emulated hardware)?

[James Davis]

On Thursday, March 15, 2018 at 4:39:36 PM UTC-7, Michael AppleWin Debugger Dev wrote:
> ... the use case is for testing.

>
> I.e. Start up 4 copies of the emulator at the *same* time:
>
> * Apple ][
> * Apple ][+
> * Apple //e (original)
> * Apple //e (enhanced)

That is right. Either give AppleWin the ability to run separate instances simultaneously (under Windows) or have four separate types of AppleWins [e.g., AppleWinII, AppleWinII+, AppleWinIIe, and AppleWinEIIe (Non-Platinum Enhanced) and/or AppleWinPEIIe (P for Platinum)--if there's a difference from an AppleWin POV]. Either way, they need to have unique Windows Registry Entries that don't interfere with each other.

[Then in future you could add AppleWinIIc, AppleWinIIc+, AppleWinIIGSrom1, and AppleWinIIGSrom3.]

[And, some more humor, for all the morning people: Then do all the Macs as MacWin's for all the A.M. enthusiasts!]

[Michael AppleWin Debugger Dev]

> [Then in future you could add AppleWinIIc, AppleWinIIc+, AppleWinIIGSrom1, and AppleWinIIGSrom3.]

We have no plans to add GS support, but yes, I would like to add //c and //c+ support at some point, along with Laser 128, and Laser 128EX.

> [And, some more humor, for all the morning people: Then do all the Macs as MacWin's for all the A.M. enthusiasts!]

Eventually we'll get SDL support and thus get OSX and Linux support "for free."

There is no point in having 3 different names.

i.e.
AppleWin
AppleMac
AppleLinux

[Peter Ferrie]

> The Autostart Monitor IS NOT LOADED along with Applesoft BASIC when AppleWin is in the Apple II mode!

I think that's expected. The autostart was a feature that was added at some later point.

> The Old Monitor IS NOT LOADED along with Integer BASIC when AppleWin is in the Apple II+ mode! And, Integer BASIC is not lost after either a 'reset' and 'ctrl-C' warm start of whichever BASIC was active at the time of the 'reset' nor after a 'ctrl-B' cold start of the current BASIC after it. [Again: The page 3 ($03D0~$03FF) DOS vectors were not destroyed. (They are destroyed when pressing the AppleWin Reset (F2) button.)]

Unlike on the Apple IIe and later, pressing Reset does not restore the LC protection, so the active BASIC will remain active.
I don't know about the other cases.

[James Davis]

I was just joking about those future AppleWin modes in the last two bracketed sentences. Don't waste your time on those.

[Brian Patrie]

On 2018-03-17 15:16, James Davis wrote:
> On Saturday, March 17, 2018 at 9:46:24 AM UTC-7, James Davis wrote:
>> Now, I understand what you did.
>>
>> Booting the "Apple DOS 3.3 January 1983.dsk" with AppleWin II/II+ modes, loads in the opposite/appropriate BASIC, but I will have to go back and see how the Monitors are affected. I suspect that the Old Monitor will be loaded along with Integer BASIC when AppleWin is in the Apple II+ mode and that the Autostart Monitor will be loaded along with Applesoft BASIC when AppleWin is in the Apple II mode; but if not, then pressing 'Reset' (ctrl-break) will always land you in the Old Monitor ("*" prompt) in the AppleWin Apple II mode (and especially for the testing if you are in FP/Applesoft when you do it), and vice-versa, pressing 'Reset' will always land you at the current BASIC prompt in AppleWin Apple II+ mode (and especially for the testing if you are in INT/Integer BASIC when you do it); otherwise, just the opposite will occur in each case.
>
> Results: (I suspected wrongly, the 'but if not, ...' occurs in each case.)
>
> Each modes ROM ($F800~$FFFF) Monitor remains in force (after the language is loaded and/or after a 'reset'). [I also looked at the $FFFA~$FFFF NMI/RESET/IRQ vectors to identify the specific Monitor there.]
>
> The Autostart Monitor IS NOT LOADED along with Applesoft BASIC when AppleWin is in the Apple II mode! And, Applesoft is not re-invoke-able with 'FP' after a 'reset' and 'ctrl-C' warm start of Integer BASIC. You have to reboot the DOS Master disk-image to re-install Applesoft. [And: The page 3 ($03D0~$03FF) DOS vectors were not destroyed. (They are destroyed when pressing the AppleWin Reset (F2) button.)]

The normal way to get back from the Monitor to the language you were
using, is to enter 3D0G--which will also reconnect DOS, so its commands
will work again. Using ctrl-C will warm start BASIC, leaving DOS in a
disconnected state; same problem with using ctrl-B to initialize BASIC.

> The Old Monitor IS NOT LOADED along with Integer BASIC when AppleWin is in the Apple II+ mode! And, Integer BASIC is not lost after either a 'reset' and 'ctrl-C' warm start of whichever BASIC was active at the time of the 'reset' nor after a 'ctrl-B' cold start of the current BASIC after it. [Again: The page 3 ($03D0~$03FF) DOS vectors were not destroyed. (They are destroyed when pressing the AppleWin Reset (F2) button.)]

Yes, F2 emulates a cold start from power off; so it wipes out everything.

When you do a normal reset (ctrl-Pause, or ctrl-F2), the ROM is
reenabled, so you'll get the Monitor native to the machine--which is
why, in II mode, you always land at the Monitor prompt. (With a
Firmware Card, the ROM enabled is determined by the position of the
switch on the back of the card.)

> Which brings up the questions:
>
> Where in RAM are these opposite BASIC languages? Are they parallel to their counterparts (e.g., in the {emulated} 16k language card RAM)? Or, are they in the lower 48k somewhere? [I thought it would be the former case, but now I am not sure. {I have got to quit making such assumptions!}] [Aside: If the language loader puts the language in the lower 48k somewhere, then why won't it work under ProDOS? Is ProDOS using the same space?]

The alternate BASIC is loaded into the (emulated) 16k Language Card.

There /are/ a few versions of Integer BASIC that load into the lower
48k--one of which was used to make a (currently somewhat rough) ProDOS
IntBASIC loader that someone is working on; but that's a whole other,
terribly complicated, story. [/I/ have questions about those
suckers--like whether Programmers Aid calls get translated.]

[James Davis]

On Saturday, March 17, 2018 at 8:55:12 PM UTC-7, Peter Ferrie wrote:
> > The Autostart Monitor IS NOT LOADED along with Applesoft BASIC when AppleWin is in the Apple II mode!
>
> I think that's expected. The autostart was a feature that was added at some later point.

According to my "APPLE LANGUAGE SYSTEM - INSTALLATION AND OPERATING MANUAL" [the older pamphlet with the "One Drive" and "Two or more Drive" chapters (still) included], the L.C. "Autostart" F8 Monitor ROM will be in force. (Whichever language is loaded into the Language Card RAM and whichever language is in the ROM on the Motherboard, doesn't matter!) The Motherboard F8 Monitor ROM is not used at all. If the Motherboard has the Old Monitor ROM, and you want to use it instead of the Autostart Monitor ROM, you have to swap the two chips. [I suppose you wouldn't even need to put one back into the motherboard.]

> > The Old Monitor IS NOT LOADED along with Integer BASIC when AppleWin is in the Apple II+ mode! And, Integer BASIC is not lost after either a 'reset' and 'ctrl-C' warm start of whichever BASIC was active at the time of the 'reset' nor after a 'ctrl-B' cold start of the current BASIC after it. [Again: The page 3 ($03D0~$03FF) DOS vectors were not destroyed. (They are destroyed when pressing the AppleWin Reset (F2) button.)]
>
> Unlike on the Apple IIe and later, pressing Reset does not restore the LC protection, so the active BASIC will remain active.

I don't quite understand what you mean here. Please elaborate.

> I don't know about the other cases.

By "other cases," do you mean the "Applesoft" and/or "Integer BASIC" Firmware/ROM Cards? I am pretty sure their F8 Monitor ROMs are only in force when the language is in force; because the Integer BASIC Card has the Old Monitor F8 ROM in force when Integer BASIC is active and the motherboard has the Autostart Monitor F8 ROM in force when Applesoft is active. The Applesoft Card should work similarly.

The L.C. also has two DOS Disk Controller chips that force a reboot when reset is pressed [IF: PASCAL (not BASIC) is the language it contains at that time].

[James Davis]

Check out:

Using the Old Monitor ROM with an Apple Language Card switch!

https://groups.google.com/forum/#!topic/comp.sys.apple2/etaslJJg0SY

[Brian Patrie]

On 2018-03-18 02:37, Brian Patrie stuck his foot in his mouth:

> When you do a normal reset (ctrl-Pause, or ctrl-F2), the ROM is
> reenabled, so you'll get the Monitor native to the machine

I was wrong. After some testing, i find that, at least in AppleWin,
resetting does not change from LCRAM to ROM. (In II mode, i made a full
12k ROM image, then loaded it into LCRAM in II+ mode, entered INT to
enable it, and reset into the old monitor. I double checked with F666G
to start the Mini Assembler.) In the IIe modes, it does reset to ROM.

[D Finnigan]

That's correct behavior. They changed reset behavior with the Language Card
in the IIe.

[Steve Nickolas]

On Sun, 18 Mar 2018, Brian Patrie wrote:

> There /are/ a few versions of Integer BASIC that load into the lower 48k--one
> of which was used to make a (currently somewhat rough) ProDOS IntBASIC loader
> that someone is working on; but that's a whole other, terribly complicated,
> story. [/I/ have questions about those suckers--like whether Programmers Aid
> calls get translated.]

They don't.

-uso.