Macintosh Personal Color, a Fantasy 1986, 68000 Mac with a 4bpp Color Mode (Emulator)

[lauland1]

Progress. Screenshot is SillyBalls using "Slowhand" with its mac plugin in 16 color mode. m68k code running in Basilisk.

The standard Quickdraw is overridden, with all new funcs prefxied with an SH prefix. SillyBalls calls those for drawing, but every other Toolbox call is passed through.

This means when SillyBalls calls, for example. RGBForeColor, it really goes to SHRGBForeColor, which calls the plugin's set_foregroundc, which, because the plugin is a "mac" one, calls the real Quickdraw's RGBForeColor. Inefficient, but proof of concept achieved.

The text isn't showing due to differences in the way the graphics state is handled in my plugin architecture vs Quickdraw. Mine expects an explicit state passed to the functions, while Quickdraw has an implied one.

So MoveTo acts on the current GrafPort without having to be specified. Slowhand maintains this state, but doesn't expose it to the plugins yet.

It calls the standard Toolbox to open the window and then Button to wait for a mouse click.

The next step would be to write the framebuffer plugin that wrote to a raw framebuffer.

I also need to fix the plugin architecture so it can get to the implied state of calls like MoveTo, etc.

 

[Snial]

@lauland1

I think I might have to change the hardware spec of Mac CP. I was re-reading up on:

Linux/m68k for Macintosh - Mac Plus hardware

Because I had realised that there wasn't any way of detecting if the Mac was a MacCP. That is, MacCP would have the same 64K ROM as an original Mac, so MacCP software support would be provided either by sticking an INIT into the system folder which enabled the minimum number of CP Traps or because a user would be running a MacCP game that just bypassed any OS support. But in the former case, users would frequently transfer disks (MFS-800kB typically) to other Macs (e.g. in college) so the INIT would certainly need to detect if it had CP support.

But the CP hardware is write-only. However, we can detect it. In the above link, it says "a byte read of an odd SCC read address tries to reset the entire SCC". So, I think it's plausible that in the CP, that could be disabled. This means the INIT can detect CP mode, by putting a non-zero value in an SCC register then reading from an odd SCC address and then checking if it's been reset.

But also, I noticed that it said: "A word access to any SCC address will shift the phase of the computer's high-frequency timing by 128 nanoseconds.." So this means that my current interface, a word write to an even SCC address won't work, it would mess up the high-frequency timing. And this means, I think that it ought to use a byte-interface rather than a word interface. And the problem with that is that it would need to coexist with existing SCC access.

I also started looking at the schematics for the Mac 128K/512K:

https://bitsavers.org/pdf/apple/mac/schematic/050-0073-C_Mac128_512.tif

The decode logic for SCC access is interesting, because it uses both the /LDS signal from the 68000 to provide the WR input to the SCC and bit 21 of the address to provide the /RD input to the SCC. That's why the read address is $9FFFF8 (with bits 0 and 21 low) while the write address is $BFFFF9 (with bits 0 and 21 high). The combinations are thus:

Addr	Mac Rd	Mac Wr
$9FFFF8+2n	SCC Read	Both 68K and Scc write.
$9FFFF9+2n	SCC Reset	SCC output, 68K output
$BFFFF8+2n	Nothing.	Nothing.
$BFFFF9+2n	Nothing.	SCC Write

This means that there are 4x byte writes to $BFFFF8+2n (n=0..3) which would have no effect, because SCC.WR would be low and /SCC.RD would be high (so the SCC wouldn't try to enable outputs and it wouldn't latch any inputs). Also, there are 8 read addresses which ought to have no effect. Therefore they can (I guess in theory) be reassigned as:

Addr	Mac Rd	Mac Wr	MacCP Rd	Mac CP Wr
$9FFFF8+2n	SCC Read	Both 68K and Scc write.	SCC Rd	x
$9FFFF9+2n	SCC Reset	SCC output, 68K output	No SCC/Rst	x
$BFFFF8+2n	Nothing.	Nothing.	4 CP Sel	CP Wr
$BFFFF9+2n	Nothing.	SCC Write	4 CP Sel	SCC Wr

So, I'm planning to change the HW design so that Read $BFFFF8 is now defined as mode 0, $BFFFFA is mode 1. I'm also planning to change the hardware design so that a Write of PaletteEntry<4>:Value<4> to $BFFFF8 sets the bottom 4 bits of an 8-bit palette entry indexed by PaletteEntry<4> to Value<4> and a write to $BFFFFA sets the top 4 bits.

This means that Palette entries reduce from 11-bit palettes R<4>:G<4>:B<3> to 8-bit palettes R<3>:G<3>:B<2> making the colour range a bit worse than an early Atari-ST (9-bits) and significantly worse than an Amiga (12-bits). This is a choice, because I could use $BFFFFC and $BFFFFE to provide up to 16-bit colour entries and the extra 2 x 16-entry x 4-bit registers + DAC resistors might not cost all that much.

And the reason for this is because already in 1985 Apple were planning on a Colour Macintosh after Gassée helped oust Jobs. And I suspect that given that Apple would want the future Mac II to be startlingly better than any possible earlier colour Mac, So, it would be a case of deliberately constraining the Mac CP: with R<3>:G<3>:B<3> it's not possible to have a full range of a single shade in 16 palette entries, the most you can have is 8.

It wouldn't make any difference to yours and my earlier examples though. The same default 16-colour palette with RGB primary colours and a brighter set of RGB primaries would still be possible and look the same.

 

[olePigeon]

The GEM screenshot is actually 640x200 stretched to 640x400 to correct the aspect ratio. The ST did support 640x400, but only with a monochrome monitor. All three of the 16-bit micros offered GUIs running on 640x200 (hence why I mentioned the IIgs as a "what if" situation), so it was a serviceable resolution. Apple's Shaston font was optimized for this use case.

Uh oh. Do Atari peeps also argue about "perfect circles" and "correct aspect ratio" like DOS peeps?

 

[olePigeon]

I'm having a hard time following this project (sorry.) Did pre-Color Quickdraw Macs technically support 4-bit color? So is this a project to realize that theoretical past of a 4-bit color Macintosh instead of the B&W one we got?