Mac Plus - Installing whole new ROM - for linux ?

[uniserver]

well steve is some of the way there with his Katy project.

http://www.bigmessowires.com/2014/11/17/68-katy-68000-linux-on-a-solderless-breadboard/

He has a ROM already made up for Katy,  granted, none of Katy  (other then the 68000 cpu) is Apple specific,  but it might be kinda interesting project?

Mac Plus these days you can still pick up for reasonable amounts of money, and with bbraun's PS/2 mouse/keyboard adaptor

and now with complete control of the ROM... + bbraun's adaptor, might bring some non apple guys to vintage apple hardware?

 

[bigmessowires]

It's something I was daydreaming about, but I'm not sure if it's really practical. There are a few Unix/Linux options for 68030 Macs, but apparently none of them work with 68000 since it lacks an MMU. Instead of trying to load a new OS from disk, I was thinking about replacing the entire Mac Plus ROM with a modified version of the one I made for that 68 Katy project. It wouldn't be able to run Mac programs then, but it would boot directly into Linux.

Probably just a pipe dream, but it's fun to think about...

 

[uniserver]

well it seems to work pretty good with Katy and she only runs at 2mhz,  so @ 8mhz might be slightly better hahah

And as you said if you can start out with all the I/O going out of the serial ports, that would be kinda cool... then

when you get time knock out the other challenges one by one.  

 

[uniserver]

for those of you that are too lazy to click on the link.

here is a video of Steve's 68000 Katy computer working.

 

[CC_333]

Well, up until recently, full read/write emulation of an HD20 was thought to be a pipe dream.

So, why can't this work? Granted, it's kind of ambitious, but if you can do all these other things, I don't think this would be that hard for you once you start doing it.

c

 

[lameboyadvance]

...In regards to an MMU on a 68000, it seems the slighly upgraded version (68010) was capable of using an MMU (68451).

 

[Bunsen]

... and the 68010 is a drop in replacement for a 68000 ...

 

[Gorgonops]

...In regards to an MMU on a 68000, it seems the slighly upgraded version (68010) was capable of using an MMU (68451).

Inserting said MMU into a Mac would require a piggyback board housing both the CPU and MMU; the 68451 has to straddle the address lines (and a bunch of control signals) between the CPU and main memory and, somewhat infamously, drastically changes the RAM timing. (The 68451 adds a wait state and it also apparently wasn't really designed very well for demand paging as implemented in "modern" UNIX variants; the limitations of the unit were severe enough that many vendors, most famously SUN, just designed their own more efficient MMUs.) Arguably you don't gain that much over just building your own single board computer trying to upgrade a Plus with an MMU.

(Perhaps more mundanely, you:

A: Don't need an MMU for uClinux anyway, and,

B: I'm *pretty* sure there's no "full" Linux port that works with either the 68010 or the 68451 so it's not as if wedging an MMU in there is suddenly going to give you more software to run. The only free UNIX-oid I know of that works on any 68010 computer is the NetBSD port for the Sun2, which, again, uses the proprietary SUN MMU. It might well be possible to duplicate the SUN MMU with a few CPLDs and a fast static RAM chip; here's the engineering manual for the CPU board, it doesn't use that many parts.

 http://bitsavers.trailing-edge.com/pdf/sun/sun2/800-1185-01_2-120_CPU_Engr_Sep84.pdf

That might be a really educational thing to do on a single-board computer... but certainly not a trivial project either.)

 

[uniserver]

looks like steve got his PCB's in !!

http://www.bigmessowires.com/2014/12/30/68-katy-pcb-dead-on-arrival/

 

[bigmessowires]

Yeah, the reason for choosing uClinux in the first place was that it doesn't need an MMU. That means a badly-behaved program can mess up other programs, or even crash the whole system, but that's no different than under System 6 or 7.

The other downside of not having an MMU is that physical memory can become fragmented over time. You might have more than 500K of free RAM, but can't satisfy a 500K allocation request, because the free RAM is scattered across lots of smaller chunks. As far as I know System 6 and 7 suffer from the same problem, though, so it's not the end of the world.

 

[Bunsen]

Alright, I might be completely on crack here (wouldn't be the first time):

One thing I've been pondering in regards various minimal embedded OSes like FreeRTOS, µcLinux, chibi-OS, Minix etc, is the possibility of running them *as a process* under Mac system software - much like the old MachTEN Unix.  They'd launch as a program, then sieze control of the CPU (unco-operative multitasking ), and make Mac Toolbox / System calls as required for display, IO, etc.

 

 

[Bunsen]

One thing the bootable ROM could be useful for is replacing the initial MacOS boot partition (do they still use those?) which then launches *nix.

 

[onlyonemac]

They'd launch as a program, then sieze control of the CPU (unco-operative multitasking ), and make Mac Toolbox / System calls as required for display, IO, etc.

What you are describing is called accelerated virtualisation, except that your version is unco-operative. If you make it co-operative then you will have proper virtualisation.

Also I don't see why, if uClinux can run the Macintosh Plus hardware, why we can't just boot it from a floppy or hard drive like we do with *NIX on our other 68k Macs.

 

[Gorgonops]

 They'd launch as a program, then sieze control of the CPU (unco-operative multitasking ), and make Mac Toolbox / System calls as required for display, IO, etc.

MachTen's secret sauce was the VM that their flavor of UNIX ran inside and said VM was undoubtedly pretty nasty to write. (And required a heavily hacked version of BSD to go on top of it.) It undoubtedly wouldn't be *impossible* to recreate something like it so you could use something like µcLinux as the hosted OS but it's going to involve a lot of antique Mac programming expertise. (Remember, you don't have a MMU to work with so you can't "according to Hoyle" virtualize on the 68000. If the guest OS is hardwired to, for instance, want to use the low memory global space for itself (like the Mac OS wants to) it'll have to be rewritten to respect whatever boundaries are necessary to preserve a working System in memory to make calls to.)

Probably the least arduous way for someone who *isn't* a Mac programmer (and doesn't want to learn to be one) to make, say, µcLinux go on a 68000 machine would be to do what most 68k (or Old World PowerPC, for that matter) compatible Linux/BSD distributions did, which is use a "bootloader" which is actually a MacOS program; let the hardware get initialized and the system running the normal Apple way and then run an evil binary which disables interrupts, clobbers all the low memory variables, and sets up the necessary vectors to point at a Linux (or other) kernel which has sufficient device driver support to take over loading the rest of the system from a dedicated SCSI hard disk (or partition). I could be wrong about this but I'm *reasonably* sure that all the hardware interrupts in the Mac point to vectors in low memory and not directly to addresses in ROM... *checks "Inside Macintosh... aha*:

The MC68000 recognizes seven different levels of interrupt, each with its own interrupt handler.

The addresses of the various handlers, called interrupt vectors, are kept in a vector table in

low memory. Each level of interrupt has its own vector located in the vector table. When an

interrupt occurs, the processor fetches the proper vector from the table, uses it to locate the

interrupt handler for that level of interrupt, and jumps to the handler. On completion, the handler

restores the internal status of the processor from the stack and resumes normal execution from the

point of suspension.

So you should be able to completely hijack a Mac Plus with a pretty trivial binary and said takeover should hold until a hardware reset occurs. (At which point the memory mapping hardware that movies the ROM down to $000000, moves the RAM up, and resets the CPU to start executing at zero, thereby undoing all your hard work.) The downside is that you lose the drivers in the System/ToolBox ROM but on the Plus side for a µcLinux geek writing a drivers for the parts you really care about (serial ports, SCSI port, and Display/Mouse/Keyboard in about that order) may well be easier than trying to learn all that MacOS arcane-ity. (Remember, you let the ToolBox ROM intialize everything so with any luck you should be able to take everything over in a known state.) As noted, really all you get by making a custom ROM is the ability to skip having MacOS on the machine at all. (In *principle* you could construct a bootloader which mimics as a working System installation and does the hijacking for you but System and the ROM's boot procedure are so tightly intertwined that's basically Mission Impossible.) I guess if you're interested in *only* the Mac Plus hardware and never want to touch System/Toolbox *ever* making the ROM makes sense, you need to write full devices drivers anyway, but, well... seems almost like you might as well at least verify your drivers by doing the "evil binary" thing outlined above and running some test programs linked to them, if not the full OS kernel, before burning said ROMs. (Otherwise you'll have to either do a lot of frustrating blind testing or develop your ROM in as hardware-accurate-an-emulator as possible, which pretty much points to MESS.)

 

[bigmessowires]

Yes, this is basically my understanding as well.

Also I don't see why, if uClinux can run the Macintosh Plus hardware, why we can't just boot it from a floppy or hard drive like we do with *NIX on our other 68k Macs.

I think you could do that, if there were already a version of uClinux for the Plus. Putting it in ROM would just make it more direct -- it's basically an excuse for something interesting to do with the Plus ROM adapter board.

 

[Gorgonops]

You need an extended version of that board that allows a flash ROM to be written over an on-board serial port from another machine without pulling it out of the Mac. (Or, hey, even better: hijack the power-on hardware initialization to jump to a "recovery loader" which checks to see if some kind of switch is held down on powerup and, if so, initializes the Mac's SCC and accepts a new flash image over the built-in serial.) Then imagine all the fun you can have writing bare-metal software for the Plus!

(Hack together some solution for interfacing a joystick and port video games to it. It already bears a striking resemblance to a Vectrex....)

 

[bigmessowires]

Hehe… already done. If you haven't been following the thread about it - I wrote a utility program to update the flash ROM image from the running Mac, without having to power down or pull the chips out. http://www.bigmessowires.com/2014/12/20/rewritable-rom-disk-for-mac-plus/

 

[Gorgonops]

Yeah, I'd seen you'd put together a MacOS flasher (which is awesome, don't get me wrong) but wouldn't you be SOL if you flashed a ROM on there that can't get you into MacOS? I was thinking essentially a "rescue image" which if triggered "somehow" would be able to pull a reload over serial with no OS dependancies. (Obviously any non-MacOS-booting ROM image loaded would have to preserve this functionality or the possibility of bricking it remains.)

Brain-dead hack way: split the ROM area in half by adding a switch that swaps the top address line, thereby letting you keep a MacOS ROM in one half and load experimental bare metal roms in the other?