Invoking Bitsy-Bye via MLI QUIT with 80 columns active nukes expansion RAMdisk

[apple2geek]

Description

If an MLI QUIT ($65) call is made while the system is in 80-column mode, and if Bitsy-Bye is the active QUIT code (i.e., it hasn't been replaced in memory by alternate QUIT code), the contents of screen holes $77C and $47C are both apparently overwritten with the value #$A0 and any existing memory-expansion-based RAMdisk volume - regardless of volume name - is blanked/erased/re-initialized into a new, empty, volume called "/RAM4". Any existing contents of the previous RAM-based volume are LOST WITHOUT WARNING at this point.

Expected Behavior

ProDOS will check the contents of memory location $77C for the value #$A5 at initialization. If the value #$A5 is not found, ProDOS re-initializes the expansion memory RAMdisk volume (with a default name of /RAM4), sets the value of $77C to #$A5, and sets the value of $47C to the number of 64K banks present on the memory expansion card. Once these values are set, no code should overwrite the $47C/$77C screen holes unless an explicit call to the ProDOS format routine is made to wipe the RAMdisk volume clean, and even then the values should be re-written as #$A5 and number-of-banks as expected. Only a power-cycle of the system should cause these values to be lost/changed, since changing them results in the loss of the contents of the /RAM4 volume, which can be a... bit of a nasty surprise.

Actual Behavior

When the MLI QUIT is invoked with 80-column mode active, the screen is cleared and switched back to 40-column mode, and the Bitsy-Bye interface is presented. If the "tab" key is used to cycle through available volumes at this point, it will be discovered that device at "S4,D1" is now a BLANK volume, with a volume name of "/RAM4", regardless of any existing volume that may have been present on the memory expansion card prior to the MLI QUIT. Dropping out to the ROM monitor at this point will also reveal that the values in memory locations $47C and $77C are both - probably not coincidentally - now set to #$A0 (a space character).

Note that if 40-column mode is active - even if the 80-column firmware itself is active (non-blinking cursor) - when the MLI QUIT call is made, OR if the Bitsy-Bye QUIT code has been replaced with, for example, Bird's Better Bye, Super Selector, or some other "third-party/alternate" QUIT code, the contents of the expansion RAM volume on S4,D1 remain intact, unaltered, and accessible.

Possible Fix

I've confirmed that the Bitsy-Bye code that is present in the ProDOS 2.4.2 release does NOT exhibit this behavior. Something in the changes to Bitsy-Bye between ProDOS 2.4.2 and ProDOS 2.5.0a2 is apparently the baseline cause. Reverting to the previous B-B code would (presumably?) eliminate the issue - but that would obviously be at the expense of any features, enhancements, and bug-fixes to B-B. Examining the deltas between the 2.4.2 B-B and the 2.5.0a2 B-B will (presumably?) limit the amount of code that will need to be analyzed.

Steps to Reproduce

1. Bootstrap system with ProDOS 2.5.0a2
2. Place any contents onto the /RAM4 volume using any convenient ProDOS tools/utilities
   • Optionally, reformat and/or rename said volume prior to populating it.
3. Invoke any .SYSTEM program that does not alter/replace the Bitsy-Bye QUIT code
   • BASIC.SYSTEM is a usable option
   • Another is an "absolute minimal" 29-byte .SYSTEM application I have for testing purposes that only sets up the stack and JMP's to the ROM monitor at $FF69.
4. Enable 80-column mode (ESC-8, or PR#3)
5. Exit the .SYSTEM program via a standard MLI QUIT call
   • "BYE" from within BASIC.SYSTEM is one option.
   • A raw call to MLI QUIT with the assembly code presented here: http://www.easy68k.com/paulrsm/6502/PDOS8TRM.HTM#5.1.5.2 is another.
6. Observe that the existing RAMdisk volume and its contents are gone, replaced with an empty volume always named "/RAM4".

Context

I've unexpectedly and unceremoniously lost the contents of the expansion-RAM volume on this machine three times now. Luckily, I finally got smart and made a backup of what I wanted to have loaded, so I'm able to replace its contents, but replacing it is time-consuming and a bit of a hassle. The whole point of the battery-backed RAM expansion combined with the ROM 5x is to AVOID having to seed the RAMdisk with contents every time the system is powered on. I primarily use Super Selector as my "QUIT" code, so invoking Bitsy-Bye is uncommon for me. Unfortunately, it does happen occasionally, and if the conditions are right - BAM! - I've lost my RAMdisk, and I have to take the time to reload it all over again from scratch.

Your Environment

See Hardware

Hardware:

Apple //c+ A2Heaven RamExpress II+ Battery-backed Expansion RAM card/clock http://www.a2heaven.com/webshop/index.php?rt=product/product&path=73&product_id=144 ROM 5x Firmware Enhancement https://github.com/mgcaret/rom4x This firmware explicitly sets the values of $47C and $77C to valid, proper values as part of the initialization/power-up cycle of the system, specifically to avoid the ProDOS RAMdisk initialization behavior and thus allow the battery-backed RAMdisk to be used as a power-on boot device. As long as you don't trigger this bug, it works perfectly. I've booted successfully from the RAMdisk for as much as two weeks before accidentally triggering the bug, and having to reload the RAMdisk. Again. :smile:

ProDOS8 version:

2.5.0a2

Non-Operating System release software being used:

Essentially zero. Behavior can be reproduced with ONLY ProDOS 2.5.0a2 active in memory and with raw calls to the MLI interface using nothing more than the $FF69 ROM Monitor.

Edit: Corrected the address of the ROM Monitor from $FF59 to $FF69.

[JohnMBrooks]

Please try to repro using 2.50a3 here:

https://drive.google.com/file/d/1DNFFd2BLIXL3krPbGWvfu8E0m9fwZiRP/view?usp=sharing

I did not see the problem. My test was: mtr 47c:00 77c:a5 c600g wait for 2.5.0a3 to boot select basic.system mtr 47c confirm 47c is 00 77c confirm 77c is A5

[apple2geek]

I appreciate the fast response. I've retrieved the 2.5.0a3 image, and I'll be getting it installed shortly.

In the meantime, your test steps listed above aren't sufficient to reproduce. I listed the steps 1-6 required to reproduce above. I see nowhere where you've executed an MLI QUIT, or activated 80-column mode. You must:

• execute an MLI QUIT ($65) call
• into Bitsy-Bye
• while the system is in 80-column mode

to trigger the bug. NO other conditions reproduce the behavior, but following the steps provided, the behavior is 100% repeatable. I have even reproduced the behavior now on a second system (a //e that doesn't even have a /RAM4 device) and the same two screen holes are overwritten with #$A0 when MLI QUIT into Bitsy-Bye is invoked with 80 columns active. There are probably other screen holes being hit as well, but $47C/$77C are the ones that destroy the /RAM4 volume when overwritten.

If necessary, I can provide a more direct method of reproducing, which requires absolutely nothing but the ProDOS 2.5.0a2 "PRODOS" file, and a single 42-byte .SYSTEM file on a disk.

[apple2geek]

Confirmed, the 2.5.0a3 PRODOS behaves identically.

[JohnMBrooks]

I do not have the //c+ hardware to reproduce the problem as described. Can you repro the $77C stomp using Virtual II, Applewin, Open Emulator or GSplus?

I've tested Virtual II & GSplus using these steps:

1) Boot P8 2.5.0a3 floppy 2) Select BASIC.SYSTEM 3) PR#3 4) MTR 5) 77C:A5 6) BYE 7) Select BASIC.SYSTEM 8) MTR 9) 77C 10) Verify value is $A5 11) PR#3 12) PR#6 13) Select BASIC.SYSTEM 14) MTR 15) 77C 16) Verify value is $A5

The above test passed on Virtual //e configured as an enhanced //e w/65c02, and on GSplus emulating a GS.

[apple2geek]

I don't have any virtual systems, only physical. I will follow your above steps on my physical systems later tonight to see if they behave differently than my own reproduction steps. Your steps 1-6 should be sufficient to reproduce. In my case, though, I don't re-invoke BASIC.SYSTEM a second time, and its initialization may affect the values in the screen holes. In the case of my //c+ with the RAMdisk, the RAMdisk volume is destroyed at step "6" in your above steps.

Meanwhile, the following steps reproduce the behavior 100% on both my (physical) modified/expanded //c+, as well as my bog-standard (physical) unmodified 128K Enhanced Apple //e. They also permit direct confirmation of the memory contents, and avoid any possible interference by other code such as BASIC.SYSTEM:

Create a simple SYSTEM file that contains only the most essential code for a SYSTEM program to function, plus a hard-coded MLI QUIT ($65) command that can be easily called. This SYSTEM program ends by jumping directly to Monitor at $FF69. The MLI QUIT begins right after that jump at $201D. Prompts are included for clarity.

] CREATE RAW.SYS,TSYS
] CALL -151
* 2000:a2 ff 9a a9 69 8d f2 03
* 2008:a9 ff 8d f3 03 a9 5a 8d
* 2010:f4 03 a9 00 8d fc bf 8d
* 2018:fd bf 4c 69 ff 20 00 bf
* 2020:65 23 20 04 00 00 00 00
* 2028:00 00
* ^C
] BSAVE RAW.SYS,A$2000,L$2A,TSYS

Create a bootable ProDOS disk, and copy only "PRODOS" (2.5.0a2 or 2.5.0a3) and the 42-byte "RAW.SYS" from above onto it. Boot this disk. Since there is no .SYSTEM file present, you will be greeted with Bitsy-Bye. Select "RAW.SYS", you will be dropped to the ROM Monitor prompt. Set the screen-hole locations to known values and call the provided MLI QUIT back into Bitsy-Bye:

* 47C:47
* 77C:77
* 201DG

Select "RAW.SYS" in Bitsy-Bye again, and observe that the screen holes remain unmolested:

* 47C

047C- 47
* 77C

077C- 77

Activate 80-column mode, and call the same MLI QUIT back into Bitsy-Bye once again while 80 columns are active:

* 3^P
* 201DG

Finally, select "RAW.SYS" again for Monitor access, and observe that the screen holes have been overwritten with #$A0 (space):

* 47C

047C- A0
* 77C

077C- A0

With my physical systems, the above steps are 100% repeatable.

The overwrite occurs when Bitsy-Bye is invoked via MLI QUIT with 80 columns active. The overwrite DOES NOT OCCUR if 80 columns are NOT active. The overwrite DOES NOT OCCUR if the Bitsy-Bye MLI QUIT code is replaced with some other alternative QUIT code. For example, I typically use Super Selector - as long as Super Selector is active as the quit code, the problem DOES NOT OCCUR.

[apple2geek]

It appears this may be a case of emulators not accurately reflecting the behavior of physical hardware. I am unable to reproduce the problem in AppleWin, using the above "RAW.SYS" method.

[mgcaret]

I am attempting (edit: not unable, yet) to reproduce with 2.5.0a3 and ROM 5X as released at https://github.com/mgcaret/rom4x/releases/tag/r20121209

Did you use the ROM 5X binary maker (at the above link), build it yourself, or buy a chip? If the latter two, when did you build it or who did you buy the chip from?

If you burned your own ROM, can you send me the image?

P.S. I don't know how I messed up the release date when I did that, but it's not from 2012. :-)

[mgcaret]

Can confirm I am unable to reproduce.

[apple2geek]

I purchased my ROM 5X from Reactive Micro, and it works exactly as advertised - as long as the 47C/77C screen holes don't get accidentally overwritten after power-up, I can successfully boot from the battery-backed RAMdisk for days or weeks at a time. I don't know what image RM used to create it.

Are you attempting to reproduce on physical //c+ hardware? Because I can consistently reproduce on two very different physical systems (one is the //c+, the other is a Platinum Enhanced //e) using the "RAW.SYS " steps above, and only the //c+ has the ROM 5X. The //e has the factory Apple-Corp "CF" ROM. I don't believe the ROM 5X is a factor, but it was the reason I noticed the behavior, when my RAMdisk contents abruptly vanished for no apparent reason.

[mgcaret]

Thanks for the info. The Reactive Micro ROM is an image built by me.

I am not attempting to reproduce on the physical hardware at the moment, but I am using the emulator I use to develop ROM 5X. I will test on real hardware tonight. That being said, there should be no reason an emulator would behave differently in this regard. If it were, I would think that other issues would appear due to the emulation inaccuracy.

I assume your //c+ passes the RAM diagnostic...

[apple2geek]

Thanks for the info. The Reactive Micro ROM is an image built by me.

That's encouraging to hear, since I didn't know before now what their source was.

there should be no reason an emulator would behave differently in this regard.

I totally agree. But as I often say to friends and co-workers - "Should. That's my favorite word!"

I assume your //c+ passes the RAM diagnostic...

It does, both the expansion RAM diagnostic from the ROM 5X menu, and the system-provided self-test. The self-test leaves garbage characters on the screen in addition to the "System OK" message, but as I understand. this is expected behavior on the //c+.

I have enough Apple II hardware available that I intend to expand my testing/diagnostic footprint this evening once I'm home.

[mgcaret]

I am unable to reproduce with: Physical Apple IIc Plus, ProDOS 2.5.0a3, ROM 5X.

An interesting thing is that the RAM expansion card firmware is supposed to recognize that the screen holes are filled with A0 and not reformat the RAM disk (stock behavior, not related to ROM 4X/5X), you can see it in the listings of the Apple //c Technical Reference.

I'm at a loss.

[mgcaret]

I've tried every which way I can think of to make this happen, including all methods in this discussion. I have yet to see the screen holes have unexpected values and my RAM disk has not had any damage.

[JohnMBrooks]

@apple2geek Can you repro the issue on a //e? If so, what cards & rom version are you using?

[peterferrie]

In BitsyBye, the removal of a JSR $FB2F before the JSR $FC58 is responsible for the effect. The $FB2F call sets the zpage dimensions for the screen. Without it, the screen appears to be too large and the screen holes get hit.

[JohnMBrooks]

Thanks @peterferrie! I switched to ctrl-q to disable 80-col which is larger than without $FB2F, but smaller than hitting the screen holes & $C00C directly.

@apple2geek Try this fix:

https://drive.google.com/open?id=1DNFFd2BLIXL3krPbGWvfu8E0m9fwZiRP

[apple2geek]

Sorry for being out of touch there for a bit.

We appear to have a fix! With the PRODOS from the above-linked disk image, my reliable reproduction steps no longer demonstrate the behavior on EITHER my //c+ or my //e. The contents of the screen holes remain unchanged after Bitsy-Bye is invoked, and the contents of the battery-backed RAMdisk on the //c+ remain intact and accessible.

Thanks to everyone for the quick solution!

[mgcaret]

An interesting thing is that the RAM expansion card firmware is supposed to recognize that the screen holes are filled with A0 and not reformat the RAM disk (stock behavior, not related to ROM 4X/5X), you can see it in the listings of the Apple //c Technical Reference.

Hah, I just gave that part of the listing a thorough read and it turns out that the code in the firmware that is supposed to not reformat the RAM disk if the screen holes contain $A0 was completely broken when they ported the code from the Slinky card to the Apple //c.

If not for this bug in the Apple //c firmware, the Bitsy Bye bug may never have been discovered.

[apple2geek]

the code in the firmware that is supposed to not reformat the RAM disk if the screen holes contain $A0 was completely broken

Heh. Is it worth trying to fix in an updated ROM4X/5X revision? Or to reclaim the space for more useful code?

[mgcaret]

The fix comes at the cost of a few bytes.

The next ROM 4X and 5X are a ways off. I plan to do complete rebuilds rather than patching, and I will include fixes for the other slinky bugs in the firmware, as well.