Jump to content
Sign in to follow this  
sharpjon

Bare-metal Mac project

Recommended Posts

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

 

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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...

Share this post


Link to post
Share on other sites

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!

Edited by Elfen

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

oooo... This is cool!

 

It sure is!

 

but I think this belongs in the Hacks section.

 

It sure does!  Moving it now.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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...

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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/

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

especially for someone that hadn’t written 68k assembly before this project

 

I must say, this is very encouraging :)

Share this post


Link to post
Share on other sites

Great project! I can confirm that it runs on my 128k, both from Floppy Emu and from a physical disk:

 

post-2585-0-10579800-1476488634_thumb.jpg

 

(Slightly stretched display is an analog board issue on the machine, nothing to do with the code.)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×