68kMLA Classic Interface
This is a version of the 68kMLA forums for viewing on your favorite old mac. Visitors on modern platforms may prefer the main site.
| Click here to select a new forum. | | Unravelling Connectix Compact Virtual | Posted by: Builder68 on 2026-07-18 19:07:08
I put today my G4 MDD to work on some meaningful tasks.
I spent the day tearing apart Connectix Virtual 3.0 RC4, using only the Powerfox browser, Super ResEdit, HexEdit, and a free online LLM.
The goal was to grasp the basics of what happens when you select a specific brand and model during installation, and to determine whether those settings could be modified for a custom homebrew accelerator.
Probably a few things are not entirely accurate, but is enough good new insights of this famous piece of software to shared as it is.
Hoping the real experts would not resist to jump in and make this information richer in details and more reliable.
Here is what I found:
When you select an accelerator model, the Virtual installer writes two things:
- A table where the only change is a 16-bit word in 'mach' resource (ID 4064). It appears to be a product code that serves merely as a reference to identify which accelerator was selected during installation.
I dumped the tables for the profiles I was interested in:
Profile
| Word
| Mercury 030
| EF1B
| Gemini 030
| EF03
| Gemini Upgraded
| EE14
| Gemini Ultra
| EE02
| Gemini Integra
| E8FD
| Dove Marathon
| E8C8
| Novi Quick30
| E8FA
|
2. The 'VMEM' resource contains a "Default Prefs" table (ID 1). This is the actual configuration table, which is mostly zero-padded. The bytes that change per profile are located at offsets 0x90 through 0x94.
Here is the breakdown:
Byte
| Purpose
| 0x90
| Entry count (number of extended configuration dwords that follow)
| 0x91
| Sub-type / memory controller generation
| 0x92
| MMU configuration mode
| 0x93
| Cache configuration
| 0x94
| Extended feature flags
|
The Per-Profile VMEM Settings
Profile
| 0x90
| 0x91
| 0x92 (MMU)
| 0x93 (Cache)
| 0x94 (Flags)
| Mercury 030
| 00
| 00
| 02
| 01
| 00
| Gemini 030
| 01
| 00
| 02
| 09
| 00
| Gemini Upgraded
| 0F
| 01
| 03
| 02
| 07
| Gemini Ultra
| 0F
| 04
| 03
| 04
| 02
| Gemini Integra
| 0F
| 04
| 03
| 04
| 02
| Dove Marathon
| 10
| 00
| 02
| 00
| 00
| Novi Quick30
| 0E
| 01
| 00
| —
| —
|
MMU Configuration (0x92)
Four modes are selected by a jump table in the 'cdev' resource code:
- 00: Clears everything. No MMU setup. Used by the Novi Quick30.
- 01: 8 MB logical page space, 384 KB page table. Exists in the code, but none of the dumped profiles use it.
- 02: 7 MB logical page space, 384 KB page table. Used by the Mercury 030, Gemini 030, and Dove Marathon series. This is the standard 68030 MMU configuration.
- 03: ~4.25 MB logical page space, ~270 KB page table. Used by high-end Gemini boards. Employs a different page table layout.
Cache Configuration (0x93)
The lower 3 bits select a basic cache mode (0–7) written to the 68030's CACR register:
- 0: All caches OFF
- 1: Instruction cache ON
- 2: Data cache ON
- 3: Both caches ON
- 4–7: Extended modes
Bits 3–7 trigger additional configuration via a separate code path for values ≥ 4:
Bit
| Function
| 3
| Burst mode enable
| 5
| Cache inhibit out (for external cache)
| 6
| Serialized bus access
|
• Note: The Mercury's 01 means I-cache only, no burst. Gemini 030's 09 means I-cache + burst + serialized. Gemini Ultra's 04 means extended mode with burst and external cache inhibit.
Extended Flags (0x94)
Three bits, each dispatching to different subroutines in the code. Tracing bit 0 reveals it loads a resource and configures additional MMU mappings. The exact meaning of the other two bits remains unknown.
RAM Discovery and The 32-bit Boundary
Virtual does not hardcode RAM sizes. Every profile uses a dynamic probe: it walks physical addresses, writes test patterns, reads them back, and stops when the hardware stops responding.
The probe uses the VMEM exclusion tables (separate resources for Plus, SE, and Outbound 2030S Notebook) to skip over known I/O zones (SCC, VIA, SCSI, ROM).
The discovered physical RAM regions are then stitched into a contiguous logical address space by the MMU page table builder. For example, a board with 4 MB at 0x00000000 and 4 MB at 0x01000000 is mapped as 8 MB of contiguous logical RAM starting at 0x00000000. The physical hole between them is invisible to the OS.
The 32-bit Boundary: There is a hardcoded check at CMPI.L #$01000000, D0 in the cdev resource code.
- If total probed RAM exceeds 16 MB, the code enables 32-bit addressing and splits RAM into "low" and "high" regions.
- If total RAM is under 16 MB, the code takes the below-boundary path but still configures the MMU, mapping RAM into the 24-bit logical space.
On machines like the Mac Plus and SE that run in 24-bit mode, the GemStart 3.x driver (paired with Virtual) patches the system to enable full 32-bit addressing. Without it, the logical space is capped to wait it founds in the 24-bit address space.
Pending Items
- The exact function of extended flag bits 1 and 2 (subroutines not fully traced).
- The sub-type byte at 0x91 (code path not traced).
- Several header fields in the VMEM table (0x50–0x60).
Major Takeaways
- Configurable, not hardcoded: Virtual configures itself from VMEM tables. The per-accelerator block at offset 0x90 controls MMU mode, cache behavior, and feature flags; everything else is discovered at runtime.
- Dynamic probing is universal: All profiles use dynamic RAM probing. While there is code for fixed bank descriptors (bank counts 2–4), none of the dumped profiles use it.
- MMU mapping: The MMU maps physically discontinuous RAM into a contiguous logical space, masking physical holes. This confirms that a second RAM bank would be discovered and probed.
- Cache sensitivity: The cache byte is the most hardware-specific field. It must match whether your board uses async DSACK (Mercury 01) or synchronous burst with STERM (Gemini).
- Homebrew viability: For a custom async 68030 board with extended RAM at 0x01000000, the Mercury profile is the safest choice.
| | 1 |
|