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.

 

[adespoton]

I'm not sure that the alternate buffer is the "only" issue here -- back when Paul implemented the BII-style main buffer outside of the emulated stack, Mini vMac already had issues like this with Macsbug. It was on the list of outstanding items back when Paul had to step away from the project.

Which version of Macsbug are you using? I know that later ones implemented screenBits correctly, but there was some really hacky stuff in the earlier versions.

 

[ryandesign]

I wouldn't be surprised if there were other issues! I just figured I'd give it a shot.

I'm using MacsBug 6.2.2 (1991), and I'm happy to use any latest version that would work on System 6 and 7 on a 68000. 6.2.2 does handle bigger screen sizes in the Mac II emulation.

 

[adespoton]

I wouldn't be surprised if there were other issues! I just figured I'd give it a shot.

I'm using MacsBug 6.2.2 (1991), and I'm happy to use any latest version that would work on System 6 and 7 on a 68000. 6.2.2 does handle bigger screen sizes in the Mac II emulation.

Yeah; 6.2.2 implements it correctly; I think it changed with one of the 6.1 betas. So the issue likely lies elsewhere.
We need to run this software through a debugger

Actually, that's not a bad idea: can you replicate this issue in Snow with a custom screen resolution? Because if you can, then you can use Snow's external debugger to debug Macsbug.

 

[ryandesign]

What is Snow?

 

[joevt]

What is Snow?

https://snowemu.com

 

[ryandesign]

That looks neat! I don't know when I'll make time to try it out but it would certainly be helpful to have a debugger that runs outside of the box.

 

[ryandesign]

can you replicate this issue in Snow with a custom screen resolution?

Does Snow support custom screen resolutions? Its web page says "The aim of this project is to emulate the Macintosh on a hardware-level as much as possible, as opposed to emulators that patch the ROM or intercept system calls." Custom screen resolutions are not possible on Macs without Color QuickDraw without a lot of ROM patching, like Mini vMac does.

I downloaded Snow to verify this. If I choose a Mac II model, it gives me a drop-down menu to choose from a few standard monitor sizes, but with a B&W Mac model, it doesn't give me a screen size option.

 

[adespoton]

You'd have to add your own resolutions via ROM patch, like in Mini vMac. Alternatively, if you choose a Mac II model, you just need to patch in the size you want into the existing code, replacing the existing standard sizes.