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. | |||||||||||||||||||||||||||||||||||||||||||
| Macintosh Personal Color, a Fantasy 1986, 68000 Mac with a 4bpp Color Mode (Emulator) | |||||||||||||||||||||||||||||||||||||||||||
| Posted by: Snial on 2025-03-03 13:43:14 Near the beginning of my exploration for Mac Color Personal (I now prefer MacCP to MacPC 😉 ), I considered how developers might develop on it. The biggest issue is how to run a suitable compiler on a Mac 512K. At the time, I was aware of Consulair C, but I had the feeling that it was a bit too primitive and therefore thought that an early THINK Lightspeed C would be the minimum, and it'd need 1MB, i.e. an expanded Mac CP. More recently I've come across the MegaMax C compiler. There's a download for it on the Macintosh Garden. It's a really interesting compiler, a one pass 'C' compiler (and inline assembler) that fits in 96kB!!! It's still very primitive. It's probably most famous for the Asteroids clone Megaroids, which was written entirely in MegaMax C and is very playable! The way it's designed to work is that you run the Editor and the Editor's file menu (note the non-standard lower case!) has some options to transfer to the compiler and linker. However, I found that when I tried to do that, it crashed and corrupted my project disk, so until I get around to seeing if that can be fixed, I just quit the editor and then run the compiler. So, this is my main desktop when running MegaMax C under MFS System 3 (because the Mac ColorPersonal only has a 64kB ROM).  I have a list of the apps in one desktop window, so when I quit the editor I can choose another app. mmcc is the compiler itself, which produces .o files so you then need mmlink (just off the bottom of the window) to link an application. Most of the time MFS disks get in the way, because all the folders are fake and I'd forgotten how frustrating that can be. When you open a file, you see every single file on the disk and they all have to have different names, as do the folders. Then when you compile, it doesn't matter if your .c files are in a folder, they end up at the root of your project disk anyway. That's why you can see edit.o, Edit and parts of my other compiled files. MegaMaxC supports the Macintosh Toolbox, but stupidly, they made all the Toolbox symbols (types, functions etc) lower-case. Also only the first 10 characters in an identifier count and really oddly, short is 8-bit. Nevertheless, the initial colour palette demo is very similar to the THINK C version:#include <qd.h>
#include <misc.h>
#include <mem.h>
#include <res.h>
#include <win.h>
#include <control.h>
#include <event.h>
#include <qdvars.h>
#define kPalSize (16)
unsigned int gClrPal[kPalSize]={
0x000, 0x400, 0x080, 0x480,
0x008, 0x408, 0x088, 0x255,
0x4aa, 0x700, 0x0f0, 0x7f0,
0x00f, 0x70f, 0x0ff, 0x7ff
};
#define VidMdSet(aVal) *((unsigned int*)0xbffffa)=(aVal)
#define PalSet(aEntry, aColor) VidMdSet(0x8000|(aEntry<<11)|aColor)
#define MdeSet(aMode) VidMdSet(aMode)
rect gSrcRct;
windowrecord gMainWin;
windowptr gWin;
InitTlbx()
{
/*
Startup toolbox managers
*/
initgraf(&theport);
initfonts();
flushevents(everyevent, 0);
initwindows();
initcursor();
}
BtnWait()
{
while(button()) { /* wait for button up */
}
while(!button()) { /* wait for button */
}
}
main()
{
int ix;
InitTlbx();
/*
Initialize screen rectangle
*/
setrect( &gSrcRct, 4, 40, 256, 128);
/*
Create Initial window
*/
gWin = newwindow( &gMainWin, &gSrcRct, "Video", 1, 0,
(long)-1, 1, (long)0);
setport( gWin);
moveto(0,12);
drawstring("Click the button!");
BtnWait();
for(ix=15; ix>=0; ix--) {
PalSet(ix, gClrPal[ix]);
}
MdeSet(1); /* now we're in color mode */
BtnWait();
PalSet(0, 0x7ff);
PalSet(1, 0);
MdeSet(0); /* now we're in mono mode */
}And indeed it works too:  Also, the cursor is initialised properly to an arrow, which is recognisable on the colour screen. As before, with my palette setup we get green on the left and magenta on the right, because a single colour scanlines is 128 bytes, or 2 standard Mac 512K scanlines and the checkerboard pattern has 0x55 on even lines (Green) and 0xaa on odd lines (Magenta). According to a book I was reading on the compiler, it can't handle programs bigger than 32kB. I think that's not true since at least 2 code segments get linked into a fairly standard program and they have individual names. This means the segment names are part of the object files and I guess it's possible to define your own segments then. Finally, one of the real oddities about the MegaMax C compiler is that it has no make program and no project manager. Instead, large, multifile projects are handled using a batch language driven by the application batchX. Bizarre huh? But it makes a bit more sense once you know that MegaMax C was also available on the Atari ST, also within its 512kB limits and I guess the ST's MSDOS-like file system made batch processing a more natural tool (or maybe they developed it as a cross compiler on a PC first?). Anyway, that's my foray into the world of 1985 Macintosh 'C' compilers. I'm not totally traumatised, so I count it as a win 😵 ! | |||||||||||||||||||||||||||||||||||||||||||
| Posted by: Snial on 2025-03-08 03:25:53 One of the aspects of the Mac CP I'm interested in is how well it can reproduce realistic images. The 16 colour palette and limited resolution would suggest that the answer is not very, or at least very unsatisfactorily. To test this I wrote a Java program (yay!) that can take an image, such as a .png or .jpg and convert it (with optional dithering) to my default 16 colour palette (which is the set of primary colours at 50% brightness + primary colours at 100% brightness + 1/3 grey and 2/3 grey). Then I wrote a simple application in THINK C to open such a file (a .px4 file, with type 'PX4 ' and fake creator: 'cPnt' or 'Cpnt' I forget which) and read it to the CP's screen. You'd need to first resize the image so that the dimensions are exactly 256 x 171; otherwise, you're going to crash the Mac application when it runs. I tried it on a few sample images. The first one was a fake image of Earth in space (note, no clouds!), next to the Mac CP version on the right:  .  At the same scale it looks surprisingly good, I think! You can see plenty of speckled effects from the Floyd-Steinberg dithering algorithm, but the tonal range seems pretty decent. If you were to enlarge either image, you'd see how blocky they both are. Next up: kittens!  .  This is a picture of our cats, Kyra (on the left) and Casper (on the right) in early 2013 when they were maybe just a couple of months old. In many ways this is a more convincing image, except you can see that the specular reflection in Casper's eyes has virtually gone. Sadly, Kyra is no longer with us, but Casper is now 12 and still in good health! A Word About Dithering Dithering is surprisingly effective at compensating for poor colour depth, effectively trading image resolution for depth. Apple used a lot of dithering algorithms in the late 1980s for early Colour Macs, because memory was still expensive and indexed 256-mode colours were the most practical. I remember getting my PowerCD for my LC II back in 1994 and exploring the demo PhotoCD that came with it: seeing realistic images on the LC II, even in 256 colour mode seemed really impressive - the dithering is often not that noticeable, when you squint and walk to the back of the room 😉 . But it's certainly more challenging with 16-colour modes. First let's look at both images without dithering:   This is how such images might typically have been displayed on Atari STs in the late 80s or Windows 3.1 in the early 1990s in 16 colour modes. They are pretty awful. What Floyd-Steinberg dithering scan every single pixel in turn, in raster order. For each pixel it computes the difference between the closest colour you can generate and the actual pixel's colour; replaces the actual pixel with that closest one and then adds a fraction of the error to the pixels immediately below and to the right. Generally speaking errors then accumulate until a future modified pixel becomes nearer to a different colour than it would have been, before being modified. The dithered kitten image IMHO looks better than the dithered earth image. That's because the kitten image is both brighter and has more tonal variety. At low brightness levels the speckling effect becomes more noticeable (because the ratio between the dithered colours is greater), but also the kitten image's is already fairly busy: quite a lot of colours, fairly closely spaced which disguises the dithering effect. Of course, it's possible to improve low-brightness dithered images by picking a less bright palette, but this won't work if there are some fairly dark areas + some bright areas elsewhere - the same palette can't do a good job for both; and of course, the colour range for the palette is fairly limited: just 4 bits for Red and Green, and only 3 bits for Blue. Floyd-Steinberg is pretty slow though; my Java implementation is far from optimised and I use floating point arithmetic and 24-bit internal colour calculations to generate the best resultant image I can. An Atari ST-era computer would struggle with the memory requirements (192kB for 320x200) and the computation could never be done in real-time, AFAIK. As a consequence, Apple picked quicker, though usually less effective dithering algorithms. I've supplied my THINK C project (it's not got much error-checking!) and Java dithering algorithm. The THINK C project also contains the converted px4 images shown here (22kB each). | |||||||||||||||||||||||||||||||||||||||||||
| Posted by: Snial on 2025-03-16 13:53:11 Hilariously, you can run System 7.1 on an InfiniteMac, emulated Quadra 650 at 256x172 in 4bpp mode! 🤣 !  Boy, it scrolls quickly! | |||||||||||||||||||||||||||||||||||||||||||
Posted by: joevt on 2025-03-16 14:21:39Hilariously, you can run System 7.1 on an InfiniteMac, emulated Quadra 650 at 256x172 in 4bpp mode! 🤣 !It uses the BasiliskII emulator which has a custom screen size option like SheepShaver does which I showed in #3 . DingusPPC will also have a custom screen size option eventually. The Power Mac 8500/8600 emulation has an emulated composite/video out mode which is 256x192. | |||||||||||||||||||||||||||||||||||||||||||
Posted by: Snial on 2025-03-16 16:29:35It uses the BasiliskII emulator which has a custom screen size option like SheepShaver does which I showed in #3 .Thanks, I did read it at the time. I knew the Q650 emulator could do non-standard screen sizes and I had used that before, mostly to simulate LC screenshots at 512x384. I'd never tried anything as small as 256x172 (note: it can't do 256x171!) - I didn't seriously think that classic Mac OS could run at that resolution! And this is the Q650 at Atari ST resolution and depth vs an Atari ST screenshot at the same resolution:   Slightly less ridiculous, but it illustrates some of the design considerations between classic Mac OS and GEM TOS. Namely: even System 1 looked a lot nicer than TOS; while being more functional, yet it's visually more of a squeeze. GEM TOS uses tinier fonts to make their clunky GUI more usable. The windowing system is just plain awful though. I hadn't worked out how to move or copy a file easily from one folder to another, because when you open a folder it opens into the same window as the disk window, so you can't see two folders independently. So what I've been doing is navigating to the inner folder, then copying the file(s) to the Floppy Disk icon, which pops it at the top level; then I can move it deeper. However, I've just discovered it's possible to open two windows for the same root disk, which means that it works more like Mac OS X than classic Mac OS. DingusPPC will also have a custom screen size option eventually.Great! And curious - didn't the 6100 only support 640x480? The Power Mac 8500/8600 emulation has an emulated composite/video out mode which is 256x192.Close and very Sinclair, so I approve! | |||||||||||||||||||||||||||||||||||||||||||
Posted by: joevt on 2025-03-17 18:20:50Slightly less ridiculous, but it illustrates some of the design considerations between classic Mac OS and GEM TOS. Namely: even System 1 looked a lot nicer than TOS; while being more functional, yet it's visually more of a squeeze. GEM TOS uses tinier fonts to make their clunky GUI more usable.classic Mac OS is like the Retina/HiDPI of GEM TOS. Just as modern macOS is the Retina/HiDPI of classic Mac OS or old Mac OS X. Everything looks better when you give it more pixels. didn't the 6100 only support 640x480?It supports these modes: Rgb12in 512x384 VGA 640x480 Rgb13in 640x480 Rgb16in 832x624 Portrait 640x870Of course, you can connect different graphics cards which support more modes. | |||||||||||||||||||||||||||||||||||||||||||
| Posted by: NJRoadfan on 2025-03-17 18:50:24 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. | |||||||||||||||||||||||||||||||||||||||||||
Posted by: Snial on 2025-03-18 06:32:55The GEM screenshot is actually 640x200 stretched to 640x400 to correct the aspect ratio.It's actually 320x200 stretched to 640x400 on the PCE emulator. All the emulation screen sizes are the same so that the emulator can just open a 640x400 SDL window. 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.I think what you meant by "what if" was that the Apple IIgs was what I'm intending by the Mac Color Personal. Is that correct? I think my response is that the IIgs wasn't, because it "threatened the Mac while not really challenging the ST or Amiga". A 2.8MHz 65C816 just doesn't have the power to compete with a 7.5MHz 68000. e.g. Dhrystones = 236 (=236/1757=0.134 Dhrystone MIPs) vs 702 for Macintosh (=0.40 Dhrystone MIPs) (I found a similar figure for the Atari ST when compiling on MegaMax C). Sadly, you need an 8.4 MHz 65C816 to compete. 
Has anyone run the Dhrystone MIPS 2.1 benchmark on a stock, 2.8MHz, Apple IIgs?I can't find any Dhrystone MIPS figures for the Apple IIgs, be it the stock 2.8 MHZ WDC 65C816 variant, or any of the overclocked or accelerator card packing variants. Has anyone tried the benchmar...
retrocomputing.stackexchange.com
Also, the IIgs must have been relatively expensive to produce.  It's not expensive just because it has about 46 chips. The connectors, separate display and disk drive and expansion slots will add to the cost too. Compare with the Mac Personal (the CP is basically the same since the colour hardware would be mostly in the ASIC). 16 chips + 2x ROMs + 16 DRAMs = 34 chips; one edge connector. I would never say the IIgs isn't a lovely computer - I was wowed by it when I first saw it in Personal Computer World:  Aesthetically it's great: Clean Snow-white Platinum design; somewhat Apple ///-ish; well-proportioned monitor; vibrant colours (3200 in 320x200 mode with the interlace palette trick). It just couldn't compete with the Atari or Amiga. 1.5M IIgs systems were sold between 1986 and 1992 vs 2.1M Atari STs (or 4-6M depending on the source) and 4.8M Amigas. 
Total share: 30 years of personal computer market share figuresIt's been a long, strange trip for the personal computer over 30 years. Ars …
arstechnica.com
 But a better what if question is surely - what if they'd ploughed the effort of the IIgs into a Mac CP? And for education users who really needed Apple ][ compatibility, provide a software emulator (https://macintoshgarden.org/apps/ii-in-a-mac) or a CPU-based emulator like they did with the LC? It's not that there were easy choices to make in the transition from 8-bits to 16-bits; here I'm simply exploring a quick hack to compete with STs and Amigas. | |||||||||||||||||||||||||||||||||||||||||||
| Posted by: olePigeon on 2025-03-18 09:46:35 @Snial I think this is really cool and could open up avenues for displays not normally used, like those tiny OLED displays. Or those 1:1 square ratio displays. That would be neat. | |||||||||||||||||||||||||||||||||||||||||||
| Posted by: MIST on 2025-07-25 10:48:20 If the main purpose of this is to reuse Atari ST color code, wouldn't it the make sense to make the color plane arrangement identical to the Atari? You'd then read 4 16 bit words into a shift register and shift then in parallel giving 4 bits per pixel into the palette. | |||||||||||||||||||||||||||||||||||||||||||
Posted by: Snial on 2025-07-25 13:18:32If the main purpose of this is to reuse Atari ST color code, wouldn't it the make sense to make the color plane arrangement identical to the Atari?It's more that the main purpose is to imagine a minimally hacky version of a Mac 512K era Mac that could do similar things to the Atari ST/Amiga type computers. I chose chunked pixels rather than planar pixels, for two main reasons. Firstly, an earlier conversation which I linked to at the start of this thread was saying that the Atari ST and Amiga's planar colour turned out to be hindrance when parallax games fell out of favour. Secondly, lots of other computers around that era actually had chunked colour pixels, e.g. BBC Micro/Electron, QL, PC (CGA & MGCA), Amstrad CPC, Archimedes, IIGS. I don't know how the French Thompson TOx computers managed colour (perhaps @zefrenchtoon knows). Also, when Macs finally went colour properly, they did chunked colour pixels. And I think there's slightly less hardware needed for chunked colour (32-bit shift reg vs 4x16-bit). But anyway, to me it implies that chunked pixels were fairly well established for games machines then anyway. Admittedly, parallax scrolling would be pretty slow. 1 pixel scrolling would have code something like: movem.l (a0)+,d0-d2 ;32c
rol.l #4,d0 ;14c
move.w d0,d7 ;4c
and.w d6,d7 ;bottom 4 bits 4c
or.w d6,d5 ;d5 is complete now 4c
eor.w d7,d0 ;clear bottom 4 bits. 4c [30c]
movem.l d3-d5,(a1)+ ;write back previous 3 regs. ;32c
rol.l #4,d1
move.w d1,d7
and.w d6,d7 ;bottom 4 bits
or.w d6,d0 ;d0 is complete now.
eor.w d7,d1 ;clear bottom 4 bits.
rol.l #4,d2
move.w d2,d7
and.w d6,d7 ;bottom 4 bits
or.w d6,d1 ;d1 is complete now.
eor.w d7,d2 ;clear bottom 4 bits.
;One cycle complete, next one begins as:
movem.l (a0)+,d3-d5
rol.l #4,d3 ;
move.w d3,d7
and.w d6,d7 ;bottom 4 bits
or.w d6,d5 ;d5 is complete now
eor.w d7,d3 ;clear bottom 4 bits.
movem.l d0-d2,(a1)+ ;write back previous 3 regs.It takes (30c*3+64c)=154 cycles to scroll 24 pixels (3 long words). That's 6.4 cycles per pixel. Not terrible. 23 fps (and 23 pixels or 11.1s for a full screen). Scrolling two pixels at a time would be 8c/pixel (a simple byte move taking 16c for 2 pixels) or 7.4c using the above algorithm with a #8 shift (6.43s/full screen). Scrolling three pixels would be another nybble algorithm, but would be 8.9c (5.2s). Scrolling 4 pixels is very fast, because it's just a block move (144c for 8 regs x 8 pixels per reg = 2.25c per pixel, 66fps or 1.03s/screen). Given the plethora of graphics architectures for mid-1980s games I'm not (yet) convinced that chunked colour pixels would be a problem. | |||||||||||||||||||||||||||||||||||||||||||
Posted by: jjuran on 2026-01-08 13:04:56Hilariously, you can run System 7.1 on an InfiniteMac, emulated Quadra 650 at 256x172 in 4bpp mode! 🤣 ! Congratulations, you inspired me to test a 256x172 screen in Advanced Mac Substitute, leading to the discovery of a MoveWindow() crash (in StdBits()) and its subsequent fix: ams-qd: Fix read off end of screen in StdBits() · jjuran/metamage_1@76eaff4This can be easily reproduced by setting a screen resolution of 256x172, opening the About box in an application where mac::app::show_About_box() is called for this purpose, and moving the About bo...
github.com
| |||||||||||||||||||||||||||||||||||||||||||
Posted by: Snial on 2026-01-09 01:00:24Congratulations, you inspired me to test a 256x172 screen in Advanced Mac Substitute, leading to the discovery of a MoveWindow() crash (in StdBits()) and its subsequent fix:AMS is a really intriguing project. Does it provide all the original Mac or Mac Plus ROM calls yet? (I'm aware it provides a lot of stuff for colour Macs, I think. Aaah, that's a related project.) | |||||||||||||||||||||||||||||||||||||||||||
| Posted by: adespoton on 2026-01-09 10:38:48 I really need to add AMS to https://docs.google.com/spreadsheets/d/1us6SCBgVs8NqbxofJXTmHDeK3nKQJpcgya2nWC9_t2w/edit?gid=0#gid=0 -- I have to admit, I haven't played around with it enough yet. Then again, I don't have Executor or MACE in that list either. But the lines between hardware emulation and OS emulation are already blurred.... | |||||||||||||||||||||||||||||||||||||||||||
Posted by: jjuran on 2026-01-09 16:17:29AMS is a really intriguing project. Does it provide all the original Mac or Mac Plus ROM calls yet? (I'm aware it provides a lot of stuff for colour Macs, I think. Aaah, that's a related project.)Advanced Mac Substitute implements most of the original trap calls, although some of those implementations remain incomplete or otherwise incorrect. There's some support for 128K ROM routines, and even beyond: Last year I added basic support for Sound Manager channels in addition to modification of resource files. | |||||||||||||||||||||||||||||||||||||||||||
Posted by: Snial on 2026-01-10 01:24:58Advanced Mac Substitute implements most of the original trap calls, although some of those implementations remain incomplete or otherwise incorrect. There's some support for 128K ROM routines, and even beyond: Last year I added basic support for Sound Manager channels in addition to modification of resource files.64kROM is good enough. I know that MACE lists which managers it's implemented. Is there a corresponding list for AMS? If it did exist, is it on a Google docs spreadsheet and if so, could it be of the form:
How many people are working on AMS? | |||||||||||||||||||||||||||||||||||||||||||
Posted by: jjuran on 2026-01-11 18:12:4964kROM is good enough... I didn't mean to hijack this thread. Shall we move here? https://68kmla.org/bb/threads/advanced-mac-substitute.32386/ | |||||||||||||||||||||||||||||||||||||||||||
Posted by: Snial on 2026-01-12 01:34:34I didn't mean to hijack this thread. I didn't feel you were. Shall we move here? https://68kmla.org/bb/threads/advanced-mac-substitute.32386/Sure! | |||||||||||||||||||||||||||||||||||||||||||
| < 2 | |||||||||||||||||||||||||||||||||||||||||||