Hello all,
I've just reached "Hello World!" status here[1] and I'm feeling like a hot shot
:) This whole thing is pretty cool[2]. It's a 67 bytes binary that runs directly
off the boot sector and uses QuickDraw to draw its "Hello World!".
So it's bare metal alright, *but* it piggy backs on the Mac ROM. And this is
why I think I might be innovating here. My intention is not to use my current
"gr/pixbuf" routines on this port. Fitting Mac's screen buffer to it would
introduce complexity and my own code would be slower than Apple's
super-optimized ROM.
However, I do intend for this port to have a Grid and a Screen. I think that
Dusk has enough flexibility to supply the operator with the same API while at
the same time maximally piggy-back on ROM routines.
I'm running this on a Powerbook 520, so not a super early mac, but according to
the specs I read, I don't see why this port of Dusk wouldn't work on the whole
68k line. I certainly don't need a MMU.
According to a forum thread I found[3], there aren't a whole lot of bare metal
alternative OSes for the m68k macs. I haven't looked closely at NetBSD/mac68k
but it seems to me, from the general complexity of NetBSD, that it would lack
the flexibility necessary for it to elegantly piggy-back on the ROM in the way
I plan to. I might be wrong though. Anyone has an idea?
So, all in all, this should be a pretty glorious port.
Onwards,
Virgil
[1]: https://git.sr.ht/~vdupras/duskos/commit/da69e7c30f37ab210e8ebebfe842945b12d9b6fc
[2]: https://git.sr.ht/~vdupras/duskos/tree/master/item/fs/xcomp/m68k/mac/deploy.fs
[3]: https://68kmla.org/bb/index.php?threads/any-operating-systems-for-68000-mac-classic.29955/
On Sat, Jan 25, 2025 at 09:26:31AM -0500, Virgil Dupras wrote:
> Hello all,> > I've just reached "Hello World!" status here[1] and I'm feeling like a hot shot> :) This whole thing is pretty cool[2]. It's a 67 bytes binary that runs directly> off the boot sector and uses QuickDraw to draw its "Hello World!".> > So it's bare metal alright, *but* it piggy backs on the Mac ROM. And this is> why I think I might be innovating here. My intention is not to use my current> "gr/pixbuf" routines on this port. Fitting Mac's screen buffer to it would> introduce complexity and my own code would be slower than Apple's> super-optimized ROM.> > However, I do intend for this port to have a Grid and a Screen. I think that> Dusk has enough flexibility to supply the operator with the same API while at> the same time maximally piggy-back on ROM routines.> > I'm running this on a Powerbook 520, so not a super early mac, but according to> the specs I read, I don't see why this port of Dusk wouldn't work on the whole> 68k line. I certainly don't need a MMU.> > According to a forum thread I found[3], there aren't a whole lot of bare metal> alternative OSes for the m68k macs. I haven't looked closely at NetBSD/mac68k> but it seems to me, from the general complexity of NetBSD, that it would lack> the flexibility necessary for it to elegantly piggy-back on the ROM in the way> I plan to. I might be wrong though. Anyone has an idea?> > So, all in all, this should be a pretty glorious port.> > Onwards,> Virgil> > [1]: https://git.sr.ht/~vdupras/duskos/commit/da69e7c30f37ab210e8ebebfe842945b12d9b6fc> [2]: https://git.sr.ht/~vdupras/duskos/tree/master/item/fs/xcomp/m68k/mac/deploy.fs> [3]: https://68kmla.org/bb/index.php?threads/any-operating-systems-for-68000-mac-classic.29955/
I stumbled on EMILE[1] which is a bootloader for Linux on the mac68k. Because
it's small, it's easy to look for answers I'm looking for, that is, "am I
innovating on the front of maximally piggy-backing on QuickDraw in an
alternative mac68k OS?".
What we see by grepping its code is that it calls _InitGraf, as it must to have
any access to screenBits. But then, in second/vga.c, we see what seems to be
code that simply directly access screenBits, probably to end up with a console.
When we look at libmacos/macos/traps.h, we see that there is no reference to
_DrawXXX traps, indicating that they're in fact brute-forcing their way into a
console.
Because calling QuickDraw is in fact the quickest path to having a console,
this tells me that Linux, and probably NetBSD, are too inflexible to allow a
piggy-back on the ROM like I'm planning to.
Of course, again, I might be wrong... But I have more evidence than when I
wrote my first email.
So it looks like I might really be innovating! All I need to do now is to
actually do it :)
Onwards,
Virgil
[1]: https://github.com/vivier/EMILE
On 1/25/25 6:26 AM, Virgil Dupras wrote:
> Hello all,>> I've just reached "Hello World!" status here[1] and I'm feeling like a hot shot> :) This whole thing is pretty cool[2]. It's a 67 bytes binary that runs directly> off the boot sector and uses QuickDraw to draw its "Hello World!".>> So it's bare metal alright, *but* it piggy backs on the Mac ROM. And this is> why I think I might be innovating here. My intention is not to use my current> "gr/pixbuf" routines on this port. Fitting Mac's screen buffer to it would> introduce complexity and my own code would be slower than Apple's> super-optimized ROM.>> However, I do intend for this port to have a Grid and a Screen. I think that> Dusk has enough flexibility to supply the operator with the same API while at> the same time maximally piggy-back on ROM routines.>> I'm running this on a Powerbook 520, so not a super early mac, but according to> the specs I read, I don't see why this port of Dusk wouldn't work on the whole> 68k line. I certainly don't need a MMU.>> According to a forum thread I found[3], there aren't a whole lot of bare metal> alternative OSes for the m68k macs. I haven't looked closely at NetBSD/mac68k> but it seems to me, from the general complexity of NetBSD, that it would lack> the flexibility necessary for it to elegantly piggy-back on the ROM in the way> I plan to. I might be wrong though. Anyone has an idea?>> So, all in all, this should be a pretty glorious port.>> Onwards,> Virgil>> [1]: https://git.sr.ht/~vdupras/duskos/commit/da69e7c30f37ab210e8ebebfe842945b12d9b6fc> [2]: https://git.sr.ht/~vdupras/duskos/tree/master/item/fs/xcomp/m68k/mac/deploy.fs> [3]: https://68kmla.org/bb/index.php?threads/any-operating-systems-for-68000-mac-classic.29955/
Well done, Virgil! I really enjoy these updates on porting Dusk to new
platforms.
How hard is it to obtain one of these m68k Macs in the US? What would be
the best route to get one?
--Aaron
On Sat, Jan 25, 2025 at 06:20:22PM -0800, Aaron Miller wrote:
> On 1/25/25 6:26 AM, Virgil Dupras wrote:> > > Hello all,> > > > I've just reached "Hello World!" status here[1] and I'm feeling like a hot shot> > :) This whole thing is pretty cool[2]. It's a 67 bytes binary that runs directly> > off the boot sector and uses QuickDraw to draw its "Hello World!".> > > > So it's bare metal alright, *but* it piggy backs on the Mac ROM. And this is> > why I think I might be innovating here. My intention is not to use my current> > "gr/pixbuf" routines on this port. Fitting Mac's screen buffer to it would> > introduce complexity and my own code would be slower than Apple's> > super-optimized ROM.> > > > However, I do intend for this port to have a Grid and a Screen. I think that> > Dusk has enough flexibility to supply the operator with the same API while at> > the same time maximally piggy-back on ROM routines.> > > > I'm running this on a Powerbook 520, so not a super early mac, but according to> > the specs I read, I don't see why this port of Dusk wouldn't work on the whole> > 68k line. I certainly don't need a MMU.> > > > According to a forum thread I found[3], there aren't a whole lot of bare metal> > alternative OSes for the m68k macs. I haven't looked closely at NetBSD/mac68k> > but it seems to me, from the general complexity of NetBSD, that it would lack> > the flexibility necessary for it to elegantly piggy-back on the ROM in the way> > I plan to. I might be wrong though. Anyone has an idea?> > > > So, all in all, this should be a pretty glorious port.> > > > Onwards,> > Virgil> > > > [1]: https://git.sr.ht/~vdupras/duskos/commit/da69e7c30f37ab210e8ebebfe842945b12d9b6fc> > [2]: https://git.sr.ht/~vdupras/duskos/tree/master/item/fs/xcomp/m68k/mac/deploy.fs> > [3]: https://68kmla.org/bb/index.php?threads/any-operating-systems-for-68000-mac-classic.29955/> > Well done, Virgil! I really enjoy these updates on porting Dusk to new> platforms.> > How hard is it to obtain one of these m68k Macs in the US? What would be the> best route to get one?> > --Aaron>
I have no idea. I don't buy machines at vintage price anymore, I have enough to
keep me busy and vintage price is really expensive. I've been weak in the past,
not anymore :) The Powerbook was at 50 bucks in a local listing, so I jumped on
it.
... but the thing is that I underestimated how problematic the "no power
adapter" part of the deal was. Proprietary connectors. Blearg. I ended up buying
that adapter for nearly 100$ on ebay.
As long as you don't mind shelling a few hundred bucks, I think they're quite
easy to find.
Regards,
Virgil
To echo Virgil, I would say that getting a 68k Mac computer in 2025
requires at least one of:
- Money (paying high prices for "vintage" hardware on ebay)
- Expertise (skills to fix broken machines sold more cheaply)
- Time (checking around junk stores and flea markets)
Good luck!
On 1/27/25 8:38 AM, d_m wrote:
> To echo Virgil, I would say that getting a 68k Mac computer in 2025> requires at least one of:>> - Money (paying high prices for "vintage" hardware on ebay)> - Expertise (skills to fix broken machines sold more cheaply)> - Time (checking around junk stores and flea markets)>> Good luck!
OK thanks d_m and Virgil. I realize I don't have enough of these three
(I'm particularly lacking in time). Maybe in the future.
I'll continue to cheer from the sidelines :)
Best,
Aaron
Yesterday, I was curious about how uxn had been implemented in THINK Pascal,
only to find out, unless I missed something, that it hasn't!
So this port will also be the first time a m68k mac will run uxn+varvara?! I
hope it behaves well on monochrome...
It's funny you mention that, Rekka and I are just about done for the
Oquonie build for the playdate which is a monochrome screen! This is
going to look fabulous inside System 7.
https://assets.merveilles.town/media_attachments/files/113/915/396/212/043/514/original/ab76cf9ee8a1058d.png
On 2025-01-30 06:54, Virgil Dupras wrote:
> Yesterday, I was curious about how uxn had been implemented in THINK Pascal,> only to find out, unless I missed something, that it hasn't!> > So this port will also be the first time a m68k mac will run uxn+varvara?! I> hope it behaves well on monochrome...
On Thu, Jan 30, 2025 at 08:08:52AM -0800, Hundred Rabbits wrote:
> It's funny you mention that, Rekka and I are just about done for the Oquonie> build for the playdate which is a monochrome screen! This is going to look> fabulous inside System 7.> > https://assets.merveilles.town/media_attachments/files/113/915/396/212/043/514/original/ab76cf9ee8a1058d.png> > > On 2025-01-30 06:54, Virgil Dupras wrote:> > Yesterday, I was curious about how uxn had been implemented in THINK Pascal,> > only to find out, unless I missed something, that it hasn't!> > > > So this port will also be the first time a m68k mac will run uxn+varvara?! I> > hope it behaves well on monochrome...>
Dusk is going to run bare metal, so we can't say that it will run on system 7.
But it's going to use QuickDraw.
Hello all,
The development of the port is still going really well. I'm currently on
"entry[]" and "code". It's so fun to write a Forth kernel, each of those
cornerstones being so small, yet so powerful.
...But I have to make an emergency pause on the port! Those USB floppy drives
are incredibly frail! When you look for them on the internet, there's really
only one model that you can buy. This model is crap. My first one fried when I
made the mistake of plugging it through a USB 1.1 hub.
This second one increasingly make very disturbing mechanical noises. It still
works, but I don't think I have many uses left in it before it dies. I'm not
buying another one!
So, to anyone having bought this no-name black USB floppy drive, you should
know that it's not made for heavy use.
I have my old school PC with a floppy drive that works very well, but so far
I've been using the USB floppy drive to propagate Dusk updates I make from my
UNIX environment to it.
Now I'll need another method. It's going to be XMODEM... But that needs to be
implemented!
So, be right back, implementing XMODEM...
Regards,
Virgil
On 2/3/25 6:17 AM, Virgil Dupras wrote:
> Hello all,>> The development of the port is still going really well. I'm currently on> "entry[]" and "code". It's so fun to write a Forth kernel, each of those> cornerstones being so small, yet so powerful.>> ...But I have to make an emergency pause on the port! Those USB floppy drives> are incredibly frail! When you look for them on the internet, there's really> only one model that you can buy. This model is crap. My first one fried when I> made the mistake of plugging it through a USB 1.1 hub.>> This second one increasingly make very disturbing mechanical noises. It still> works, but I don't think I have many uses left in it before it dies. I'm not> buying another one!>> So, to anyone having bought this no-name black USB floppy drive, you should> know that it's not made for heavy use.>> I have my old school PC with a floppy drive that works very well, but so far> I've been using the USB floppy drive to propagate Dusk updates I make from my> UNIX environment to it.>> Now I'll need another method. It's going to be XMODEM... But that needs to be> implemented!>> So, be right back, implementing XMODEM...>> Regards,> Virgil
That's a good tip. I was thinking about getting one of those USB floppy
drives. So if you want a reliable floppy drive, you need hardware from
back when floppies were still popular?
A somewhat tangential question: how much work is it to implement USB
mass storage?
--Aaron
On Mon, Feb 03, 2025 at 08:36:03AM -0800, Aaron Miller wrote:
> On 2/3/25 6:17 AM, Virgil Dupras wrote:> > > Hello all,> > > > The development of the port is still going really well. I'm currently on> > "entry[]" and "code". It's so fun to write a Forth kernel, each of those> > cornerstones being so small, yet so powerful.> > > > ...But I have to make an emergency pause on the port! Those USB floppy drives> > are incredibly frail! When you look for them on the internet, there's really> > only one model that you can buy. This model is crap. My first one fried when I> > made the mistake of plugging it through a USB 1.1 hub.> > > > This second one increasingly make very disturbing mechanical noises. It still> > works, but I don't think I have many uses left in it before it dies. I'm not> > buying another one!> > > > So, to anyone having bought this no-name black USB floppy drive, you should> > know that it's not made for heavy use.> > > > I have my old school PC with a floppy drive that works very well, but so far> > I've been using the USB floppy drive to propagate Dusk updates I make from my> > UNIX environment to it.> > > > Now I'll need another method. It's going to be XMODEM... But that needs to be> > implemented!> > > > So, be right back, implementing XMODEM...> > > > Regards,> > Virgil> > That's a good tip. I was thinking about getting one of those USB floppy> drives. So if you want a reliable floppy drive, you need hardware from back> when floppies were still popular?
I don't know. There are probably good floppy drives out there. It's just that
this specific no-name USB floppy drive is bad. At least the two I've got.
> A somewhat tangential question: how much work is it to implement USB mass> storage?
From what I glanced of the specs, it doesn't look like a gargantuan task, but
the prerequisites are tricky: USB 2.0 support is needed.
In the tests I've made on a PC, USB keys can't be enumerated by the UHCI driver
because, from what I see in the specs, the EHCI controller will "snatch" the
device from under UHCI's feet.
So either it needs to be developed from the RPi which has the DWC driver, which
should normally handle USB 2.0 transactions correctly, or develop a EHCI
driver, or find a way to bypass EHCI controller, or use old hardware that only
has a UCHI controller.
Regards,
Virgil
