MacsBug in Mini vMac Plus/SE/Classic with larger screen

[ryandesign]

Has anyone figured out how to make MacsBug work in a custom build of Mini vMac that's emulating a Mac Plus, SE, or Classic configured to have a nonstandard screen size?

With the standard 512x342 screen size, MacsBug works fine. My assumption is that it uses the alternate screen buffer that exists on these systems, since it is so quick to flip between MacsBug and the real screen with the Escape key.

With a nonstandard screen size, the screen does not change to the MacsBug screen when MacsBug should appear. I know it's running, because it responds to keypresses properly (Command-G will resume the program, for example), but it's not very useful when I can't see the MacsBug output.

When Mini vMac is faking a different screen size, it relocates the screen memory to a larger previously unused portion of the address space somewhere above the ROM. I assume that in this configuration it does not also allocate space for the alternate screen buffer and that it does not respond to the flag to switch to the alternate screen buffer.

When running in a Mini vMac built to emulate a Mac II, MacsBug works fine regardless of the emulated screen size.

I wonder if there is a way either to get Mini vMac to allocate and allow the use of the alternate screen buffer, or to tell MacsBug to use the arbitrary-screen-size-handling code that it uses on a Mac II. I've made no attempt to investigate either of these possibilities yet because I wanted to check first if a solution is already known.

Thanks!

 

[ryandesign]

When Mini vMac is faking a different screen size, it relocates the screen memory to a larger previously unused portion of the address space somewhere above the ROM. I assume that in this configuration it does not also allocate space for the alternate screen buffer and that it does not respond to the flag to switch to the alternate screen buffer.

At least this assumption seems to be correct:

• In setup/SPBLDOPT.i, Mini vMac 37.03's build system sets NeedScrnHack and NeedVidMem to true when using non-default screen sizes on compact Macs.
• In setup/SPOTHRCF.i, it writes the variable NeedVidMem to the config file as IncludeVidMem and writes the variable NeedScrnHack to the config file as UseLargeScreenHack.
• In src/GLOBGLUE.c, when IncludeVidMem is true, it declares a pointer VidMem. (There are more references to that variable in that file but they're not relevant because they all relate to Macintosh II video card emulation.)
• In src/GLOBGLUE.h, when IncludeVidMem is true, it exports the VidMem pointer.
• In src/PROGMAIN.c, when IncludeVidMem is true, it calls ReserveAllocOneBlock to allocate one block the size of the video memory and assigns it to the VidMem pointer.
• In src/SCRNEMDEV.c, when IncludeVidMem is true, the variable screencurrentbuff is always set to VidMem. In contrast, when IncludeVidMem is false, it defines constants kMain_Offset, kAlternate_Offset, kMain_Buffer, and kAlternate_buffer, and uses the latter two when deciding how to set screencurrentbuff based on the value of the flag SCRNvPage2.

With this information it should be easy for me to patch Mini vMac to have the alternate video buffer even when using alternate screen sizes. Whether MacsBug's screen will be at all legible on it (or whether it's hardcoded to expect a 512x342 screen) remains to be seen.

 

[ryandesign]

With the standard 512x342 screen size, MacsBug works fine. My assumption is that it uses the alternate screen buffer that exists on these systems, since it is so quick to flip between MacsBug and the real screen with the Escape key.

This assumption seems correct too, based on the statement in the Notes screen for the game Continuum, which says "Because Continuum uses the second graphic buffer, it is incompatible with the Ramcache, MacsBug, and some INITs that use high memory on all Macs with a 68000 processor."

I've patched Mini vMac so that it allocates the alternate screen buffer and flips to it based on the VIA bit even on nonstandard screen sizes. I fixed the Continuum source code to build with THINK C 5 and to use page flipping on the Classic, which is the model I'm emulating. Continuum does page flip now. The main screen looks wrong because it's hardcoded to assume the screen width is 512, and the alternate screen isn't being drawn because I haven't wired that up correctly in Mini vMac yet.

The big problem with trying to implement the alternate screen buffer for bigger screens is that although Apple always advised developers not to hardcode addresses, for example to use screenBits to find the screen's base address, row bytes, and bounding rectangle rather than hardcoding those values, they don't seem to have provided anything similar for the alternate screen buffer. I can't find any example from Apple showing how the alternate screen buffer was intended to be accessed, and Continuum for example hardcodes that its address is 32K below the main buffer. If that's the way it's being done, that kind of limits the screen size to 32K. I mean, I can think of a way to possibly allow larger screens, but it would be a terrible hack.

MacsBug still doesn't show anything nor perform a page flip when invoked, so implementing the alternate buffer may not be the road to success.