Bare-metal Mac project

[sharpjon]

Hello fellow 68k enthusiasts,

I'd like to share a Mac project I've been working on for a bit now.  I've been exploring "bare-metal" programming on the original Macs (128k/512k/Plus) and just got around to writing up my initial efforts here:

http://jonsharp.net/retrocomputing/bare-metal-macintosh-programming-part-1/

But perhaps more importantly, I'd like to solicit some help in the next stages of my efforts to produce something modestly useful/interesting on the Mac hardware, without any real help from the ROM/System.

I've got an 'experimental' branch in my 'HappyJon' repo that carries things further than the initial demo in my writeup.  This branch demonstrates a compact font, character and string assembly routines, and the beginnings of porting newlib.  And it's this last part that I'm hoping to get some help with.  I'm having some difficulty with pc-relative code and linking...  

Anyway, would love some feedback on this or any other aspect of the project.

Here's the repo: https://github.com/jrsharp/HappyJon

Thanks all!

--

Jon

 

[Elfen]

This is interesting to say the least. But as I recall, the Mac boots up in Bitmapped Graphics Mode, under this bare metal idea to use text, you would have to reinvent the wheel in creating text screen windows. These routines are already in the Toolkit so that programmers do not have to reinvent a wheel, and keep a program small.

But it does show the power of the 68K. The beauty in this I see is taking one of the many 68K Bare Metal Projects/Kits out there ans turn one of them into an Open source Mac!

 

[Paralel]

Your 1-bit rendering makes you look exactly like Seth Rogan.

 

[techknight]

oooo... This is cool! but I think this belongs in the Hacks section. 

 

[sharpjon]

Thanks everyone, I appreciate the feedback.

Elfen: Yes, I'm not sure exactly what bootstrapping of the framebuffer the ROM startup code is doing.  It was an open question for me.  And it's partly why I said "with any *real* help from the ROM/System..."  My end goal would actually be to create a replacement ROM in which *zero* Apple code was involved.  Of course, this may not quite be possible, or rather, there really may only be one way to initialize certain peripherals, etc.  For now, I'm content to leverage the ROM, both for the framebuffer setup, but also for that initial disk booting, as this is the most convenient way to test any code in development.  (that is, until I get BMOW's ROM adapter: http://www.bigmessowires.com/2014/12/20/rewritable-rom-disk-for-mac-plus/)

As far as the fonts, character routines, etc., they are all independent of Toolbox functions -- aside from assuming I have a memory-mapped bitmap display at ScrnBase.  But again, that's all in the 'experimental' branch and I haven't written all of that up yet.

 

[bigmessowires]

I like this concept very much. To be truly independent of the ROM, you'll need to replace the interrupt handlers with your own - else you'll have some ROM code executing periodically for mouse and keyboard and vertical blank that makes certain assumptions that might not be valid anymore. For example, maybe your memory layout is different, or you leave the SCC or VIA or IWM in a different state than the ROM routines expect. The floppy disk driver also executes periodically in the background, driven by a timer interrupt if I recall correctly. Writing your own floppy disk or SCSI driver is a pretty big task, I think, so you may be happier reusing those parts as-is and focusing your effort on replacing the system and application level stuff.

As I recall, there are documented ROM routines to do something like "read sector XX to a memory buffer", which might be enough to build your own OS and application environment on top of. The details of the Linux for Mac 68K project would also probably be helpful. http://www.mac.linux-m68k.org

 

[sharpjon]

techknight: you are probably right about the hacks/development section... Maybe I'll start a new thread there detailing more of the font routines, etc., and the linker issues I'm experiencing now...

 

[Elfen]

Not to throw anyone a curve ball, but I found this - a 68K Card for the Apple II! OK, one is not going to run Mac Software on their Apple II with it; it was for CP\M-68K similar to the Z80 cards running CP\M on the Apple II.

But, it was the board schematics AND board layout for the card! So one can build it if one likes! And of course, mod it. CP\M was a powerful OS for it's time but it would not last to the IBM PC and MS DOS they stole from Digital Research. This would put the the 68K on a Bare-Metal system for building something bigger.

Imagine the possibilities... '040 Apple II Plus? LOL! There's never a time machine when one needs one.

EDIT: Forgot the link:

http://www.vcfed.org/forum/showthread.php?30049-Apple-II-68K-card

Edit II: Sorry, that's a 68008... But still a bit more "magic" and who knows!

 

[CC_333]

Interesting!

I believe the 68008 is the 8-bit variant of the 68000. I sorta doubt a full-on 68040 at 40 MHz would work as is

But who knows??

c

 

[Bunsen]

oooo... This is cool!

It sure is!

but I think this belongs in the Hacks section.

It sure does!  Moving it now.

 

[Bunsen]

something modestly useful/interesting

How about a VT100/VT102 serial terminal?

And, now that I've read your blog entry ...

To do anything meaningful I will need to break out of my 1024-byte boot block jail…

How about a simple bootloader so you can load code directly into RAM from the serial port?  That would make the Mac even more like a honking-big microcontroller.

 

[MidnightCommando]

This is really solid work, sharpjon!

If your endpoint is to create a replacement ROM, you're in luck, as the Macintosh is an extensively documented computer; while there may indeed only really be one way to make some things work, it should also be pretty possible to build that from first principles.

At that point, however, you may not want to bother with Newlib; any boot code you write is going to have the sole task of initialising devices and chain-loading a boot block from somewhere else (in the case of a 128/512/Plus, probably the floppy drive), which simplifies things a lot. You may want to persevere without C there.

Regardless of the direction you take with this, though, I'm super interested to see your progress, and I hope you'll share with us!

 

[rickyzhang]

Reinventing wheel is fun. I believe classic Mac ROM is 128KB to 512KB. If 68K instruction is average 3 bytes and ignore the data in the rom, you may have around 42K - 170K assembly to type. It is a quite daunting task. It is not infeasible but too much to type. But it is definitely a good learning process. 

I think you can write it as rom patch as Basilisk II does. Please keep us posted your work!

PS: Rom is not encrypted. If you dissemble it, you can always get the source. You may find another hidden bit map image some where in the ROM.

 

[sharpjon]

Hey all,

Thanks for the feedback!  

Bunsen:  a vt100 terminal is precisely one of the ideas I had.  It's non-trivial, but not terribly sophisticated, either.  I've got a few other ideas, too.  And I like the idea of loading more code over the serial port.

MidnightCommando:  Yes, I've been relying on the available docs.  I've even got a fairly complete set of Inside Macintosh volumes that I've pored over as part of this effort, as well.  As far as Newlib is concerned, I just managed to punch through my issues with relocatable code and managed to get enough of the Newlib stubs put together to get puts() working to output a string to the Mac framebuffer using my lower-level assembly routines.  (This is all in the latest commit of the 'experimental' branch of the HappyJon repo)  I've still got a lot of work to do here, but I'm pretty excited to have the newlib stuff working at a proof-of-concept level.

rickyzhang:  Yeah, I've dumped the annotated ROM using FDisasm.  My eventual goal might be to replace the ROM entirely, or at least in part...  I won't need all of the Toolbox stuff, but as BMOW points out, I wouldn't mind hanging onto the keyboard "driver" and disk drivers....

Guys, feel free to download/fork the latest commits and check out the stuff I'm working on currently.  I'm anxious to get my "Part 2" written up, where I go into the font and low-level assembly routines for character/sting handling where I create a 102x25 character terminal out of the Plus display...

Stay tuned...

 

[Bunsen]

One of my madder ideas (which I have an almost complete lack of skillz to carry out) was to try and port a modern embedded OS to the old Macs, like eCos, Contiki, FreeRTOS, µcLinux or suchlike.  Bigmessofwires has µcLinux up and running on his 68Katy, a homebrew 68008 computer, which is about as resource constrained as a Mac 512 or Plus.

 

[Bunsen]

Just stumbled onto this little bit of information:
 

Guy Kawasaki “begged” Infocom to get their games onto the Mac, and delivered several prototypes to make it happen. It turned out to be unexpectedly challenging. The pre-release version of MacOS that Infocom received with the prototypes was so buggy that they finally decided to throw it out altogether. They wrote their own simple window and menu manager instead, packaging it onto self-booting disks that dumped the player straight into the game.

 
http://www.filfre.net/2014/02/macware/

 

[sharpjon]

Bunsen,

Man, you're right there with me.  I've been wanting to do a simple FreeRTOS example for this once I have the newlib stuff working properly.  I had seen MBOW's uclinux work for his homebrew machine and had in fact taken some of my inspiration from that project.  It at least demonstrated the possibilities.

Having basic screen/terminal I/O working using newlib will open up a host of possibilities, I think.  One thing I'd like to do is port some kind of portable Forth over, (pforth seems like a good candidate) so it can provide a real operating environment upon which to build new and unique apps.  (Forth is of course what the Canon Cat was built on)  Also, since Open Firmware is a Forth environment itself, this would be a kind of "Open Firmware for classic 68k Macs," which might be interesting.  

That bit about Infocom is very interesting indeed, as one of my more immediate plans was to attempt to get the Frotz z-code interpreter to work within my terminal environment.  (Their "dumb" terminal option looks suitable)  Eventually, this could lead to Zork I/II/III in ROM.

But... I have good news as far as my status goes, I've made some good progress of late and now have a working _write implementation, allowing one to use things like 'puts()'.  My latest commits to the 'experimental' branch demonstrate this.  (BTW, if you don't have an m68k toolchain installed, the 'floppy.img' file is being updated with each commit if you just want to download and fire it up in an emulator.

I'll be writing up my 'part 2' soon, and will try to get into all of the compiler optimization issues I've run into, etc.  In the meantime, I'd love any more feedback/help on things at this point.  Fork away!

--

Jon

 

[bdurbrow]

You are in a maze of twisty little wires, all alike.

>

 

[sharpjon]

Ok, folks... Here's part 2:

http://jonsharp.net/retrocomputing/bare-metal-macintosh-programming-part-2/

I'm still playing catch-up, documenting the things I'd done a while back now.  As I mentioned above, I managed to get some of the newlib stuff working.  But this write-up covers the font, character routines, loading code off disk into memory, building relocatable code, etc.

The next thing on my agenda is revamping my keyboard input stuff to I can get a working _read() implementation for my newlib port.

Anyway, let me know what you think.

--

Jon