Megalextoria
Retro computing and gaming, sci-fi books, tv and movies and other geeky stuff.

Home » Digital Archaeology » Computer Arcana » Apple » Apple II Emulation » Strange behavior in AppleWin?
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
Re: Strange behavior in AppleWin? [message #365259 is a reply to message #365249] Sat, 17 March 2018 16:16 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: 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)?
Re: Strange behavior in AppleWin? [message #365260 is a reply to message #365160] Sat, 17 March 2018 16:54 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: 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!]
Re: Strange behavior in AppleWin? [message #365283 is a reply to message #365260] Sat, 17 March 2018 22:50 Go to previous messageGo to next message
Michael AppleWin Debu is currently offline  Michael AppleWin Debu
Messages: 1262
Registered: March 2013
Karma: 0
Senior Member
> [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
Re: Strange behavior in AppleWin? [message #365284 is a reply to message #365259] Sat, 17 March 2018 23:55 Go to previous messageGo to next message
qkumba is currently offline  qkumba
Messages: 1584
Registered: March 2013
Karma: 0
Senior Member
> 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.
Re: Strange behavior in AppleWin? [message #365285 is a reply to message #365283] Sun, 18 March 2018 03:32 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: James Davis

On Saturday, March 17, 2018 at 7:50:05 PM UTC-7, Michael AppleWin Debugger Dev wrote:
>> [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

I was just joking about those future AppleWin modes in the last two bracketed sentences. Don't waste your time on those.
Re: Strange behavior in AppleWin? [message #365288 is a reply to message #365259] Sun, 18 March 2018 03:37 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: 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.]
Re: Strange behavior in AppleWin? [message #365289 is a reply to message #365284] Sun, 18 March 2018 04:43 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: 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].
Re: Strange behavior in AppleWin? [message #365290 is a reply to message #365237] Sun, 18 March 2018 04:59 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: James Davis

On Friday, March 16, 2018 at 10:38:50 PM UTC-7, Brian Patrie wrote:
> 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.

Check out:

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

https://groups.google.com/forum/#!topic/comp.sys.apple2/etas lJJg0SY
Re: Strange behavior in AppleWin? [message #365305 is a reply to message #365288] Sun, 18 March 2018 12:37 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: 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.
Re: Strange behavior in AppleWin? [message #365308 is a reply to message #365305] Sun, 18 March 2018 15:51 Go to previous messageGo to next message
D Finnigan is currently offline  D Finnigan
Messages: 1154
Registered: October 2012
Karma: 0
Senior Member
Brian Patrie wrote:
> 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.
>

That's correct behavior. They changed reset behavior with the Language Card
in the IIe.
Re: Strange behavior in AppleWin? [message #365339 is a reply to message #365288] Sun, 18 March 2018 23:23 Go to previous message
Steve Nickolas is currently offline  Steve Nickolas
Messages: 2036
Registered: October 2012
Karma: 0
Senior Member
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.
Pages (2): [ «    1  2]  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: AppleWin Feature Requests
Next Topic: AppleWin's 5 F8 Monitor ROM versions?
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Fri Mar 29 01:32:41 EDT 2024

Total time taken to generate the page: 0.09131 seconds