Looking for a Rosetta-like translator for 68K Apple apps running on AS

[Citysnaps]

Looong ago, between hardware/systems engineering jobs, I dabbled in software development and created a compact scientific calculator, something I needed for other stuff I was doing on my 68K-based Mac II ci. And tried my hand marketing it.

It worked great natively on my II ci, Quadra, first gen Mac Pro. When Apple switched to Intel, Rosetta handled that perfectly with no issues. Eventually Apple dropped support for that version of Rosetta. And that forced me to go with pCalc. That's a nice scientific calculator, but I liked mine a lot more, having more features and taking up far less display space.

Question: Is there any kind of Rosetta-like translator out there that can run on AS and handle 68K code? I kind of doubt it, but thought I'd inquire as I'd really like to use it again.

 

[Colstan]

I wish you the best on your quest, traveller. Tis rough seas ahead. The brackish waters are fraught with danger, for here be dragons. The blasted plane you must traverse is one of peril, unknown foul beasts roam the land. Even if you succeed, the result may not be as thou hath desired. Fortunate favors the bold, and I wish you well on your adventure.

 

[Yoused]

It worked great natively on my II ci, Quadra, first gen Mac Pro. When Apple switched to Intel, Rosetta handled that perfectly with no issues. Eventually Apple dropped support for that version of Rosetta.

Was it some sort of fat binary? 68K code no longer worked after Leopard dropped the Classic environment. If it worked on Rosetta, it must have been written in Carbon, which I am pretty sure has gradually been killed off. It would need a rewrite.

 

[KingOfPain]

The closest thing might be AMS, but I‘m not sure how compatible it is:

Advanced Mac Substitute

GitHub - jjuran/metamage_1: Metamage open source, general repository, iteration 1

Metamage open source, general repository, iteration 1 - GitHub - jjuran/metamage_1: Metamage open source, general repository, iteration 1

github.com

There is also an updated version of the really old Executor, also not sure how well it works:

GitHub - autc04/executor: A modern fork of the classic Mac emulator

A modern fork of the classic Mac emulator. Contribute to autc04/executor development by creating an account on GitHub.

github.com

The most compatible is probably a full blown emulator like Basilisk II (I really liked it on BeOS, but the macOS version is strangely lacking with the need of an additional executable to configure the preferences file):

Basilisk II [E-Maculation wiki]

www.emaculation.com

 

[Citysnaps]

Was it some sort of fat binary? 68K code no longer worked after Leopard dropped the Classic environment. If it worked on Rosetta, it must have been written in Carbon, which I am pretty sure has gradually been killed off. It would need a rewrite.

Long ago there was a small company in Arizona called Zedcor and started by the Gariepy brothers, who produced a product called ZBasic, which then morphed into Future Basic. It was one of the most complete Basics available at the time and also included a complier that produced 68K code. The code was quite fast and relatively compact. In the true spirit of Apple products, it just worked and had a great edit and debug environment, with the ability to use others' user interface enhancements. It was a pretty quick way of getting a complete program running without having to be a software engineer, fuss with Inside Macintosh books (which I had), etc.

At this stage a rewrite using Swift, with the learning curve it would entail, is pretty much off the table.

 

[Citysnaps]

Here's a pic of the calculator:

 

[Yoused]

Do you still have the source code?

 

[Citysnaps]

Do you still have the source code?

Doubtful. Those computers are long gone. Maybe on a 5 MB SCSI backup hard disk stored somewhere.

Still have a PowerBook Duo 230 laptop that runs and boots up the calc. In B&W.

 

[MEJHarrison]

At this stage a rewrite using Swift, with the learning curve it would entail, is pretty much off the table.

We're almost to the point where you could feed ChatGPT an image of your original app and ask it to recreate it in Swift. I'm sure there would be tons of work left to do, but it would be a push in the right direction.

 

[Citysnaps]

We're almost to the point where you could feed ChatGPT an image of your original app and ask it to recreate it in Swift. I'm sure there would be tons of work left to do, but it would be a push in the right direction.

That's a very interesting thought. Could be a good way of learning Swift, having a real project and purpose for motivation. Since it came out about 10 years ago I've wanted to learn to program in Swift, but never had a real or compelling need.

OTOH... pCalc works pretty good. It just feels a little bit inefficient, and with not as many features that matter to me.

 

[MEJHarrison]

Swift might be my favorite language. Of course I only play with it. If I had to work with it daily, I'm not sure if I'd still enjoy it or not. I also think SwiftUI is pretty brilliant for UI work. Miles better than the old way of building UI. And their new SwiftData is off to a great start as well. I've been playing with the beta and like it so far.

If you were going to jump back into programming on Apple devices, it's not too bad these days.

With that said, I don't have the same spunk I did when I was younger and understand just getting something else instead of building my own.

 

[Nycturne]

I also think SwiftUI is pretty brilliant for UI work. Miles better than the old way of building UI.

I’m building in full SwiftUI because it is the future, but I find it a bit more mixed. It is better for certain ways of building UI, and it’s about the only way to describe things in ways you can reuse across Apple’s platforms, but with a steeper learning curve than good ol IB.

 

[Citysnaps]

Swift might be my favorite language. Of course I only play with it. If I had to work with it daily, I'm not sure if I'd still enjoy it or not. I also think SwiftUI is pretty brilliant for UI work. Miles better than the old way of building UI. And their new SwiftData is off to a great start as well. I've been playing with the beta and like it so far.

If you were going to jump back into programming on Apple devices, it's not too bad these days.

With that said, I don't have the same spunk I did when I was younger and understand just getting something else instead of building my own.

Does it lend itself for easily blocking out and graphically designing the UI first?

For example, in my case, defining the calculator window, four level stack display, buttons, the four large drop down buttons and windows where mathematical operations and features can be displayed in a grid, and detecting mouse actions to select one of the operations causing something to happen in a subroutine (even if it's just a beep in the beginning)?

And then later, over time, gradually adding the non-UI code that does the work and produces results.

 

[KingOfPain]

Doubtful.

It‘s a bummer that you don‘t have the source code, since Future Basic still seems to exist:

FutureBasic

 

[KingOfPain]

We're almost to the point where you could feed ChatGPT an image of your original app and ask it to recreate it in Swift. I'm sure there would be tons of work left to do, but it would be a push in the right direction.

It‘s funny that you mention this. Just yesterday I read a short article where someone asked Bard to generate a calculator in Python with a GUI and this was the result (which also didn‘t work):

https://heise.cloudimg.io/v7/_www-heise-de_/imgs/18/4/2/7/0/8/4/4/tasch-b24072b74be9655a.JPG

 

[throAU]

Looong ago, between hardware/systems engineering jobs, I dabbled in software development and created a compact scientific calculator, something I needed for other stuff I was doing on my 68K-based Mac II ci. And tried my hand marketing it.

It worked great natively on my II ci, Quadra, first gen Mac Pro. When Apple switched to Intel, Rosetta handled that perfectly with no issues. Eventually Apple dropped support for that version of Rosetta. And that forced me to go with pCalc. That's a nice scientific calculator, but I liked mine a lot more, having more features and taking up far less display space.

Question: Is there any kind of Rosetta-like translator out there that can run on AS and handle 68K code? I kind of doubt it, but thought I'd inquire as I'd really like to use it again.

If you can get install media for a variant of macOS for PPC that includes 68k emulation you could try run it in UTM.

UTM can run PPC macOS pretty well on Apple Silicon, and if the PPC version of macOS still iincludes 68k emulation that should work?


Another way could be to get Amiga emulation working and look for a copy of ShapeShifter (Mac emulator for the Amiga that ran faster than native) but that's going down an old rabbit hole.


I think UTM may even be able to run macOS 68k (haven't tried it) - its a front end for QEMU which has a 68k emulation engine in it.

This may be of assistance:

Documentation/Platforms/m68k - QEMU

wiki.qemu.org

 

[Nycturne]

Does it lend itself for easily blocking out and graphically designing the UI first?

For example, in my case, defining the calculator window, four level stack display, buttons, the four large drop down buttons and windows where mathematical operations and features can be displayed in a grid, and detecting mouse actions to select one of the operations causing something to happen in a subroutine (even if it's just a beep in the beginning)?

And then later, over time, gradually adding the non-UI code that does the work and produces results.

The WWDC talks showing the basics should be available to folks without developer accounts I think. They are about 4 years old at this point, but they show how to get rolling.

But yes, you can do this. Xcode also has a preview feature that lets you see how the UI actually looks as you make edits to the code, so you can do the sort of thing you are describing faster. Button actions for example are closures in Swift, and can call anything or nothing to begin with.

This is also doable in Interface Builder, since it’s meant to block out the whole UI and then attach it to actions and state.

I didn’t do much development work pre-OS X but it’s a whole new world compared to those days, to be honest.

 

[MEJHarrison]

0

It‘s funny that you mention this. Just yesterday I read a short article where someone asked Bard to generate a calculator in Python with a GUI and this was the result (which also didn‘t work):

https://heise.cloudimg.io/v7/_www-heise-de_/imgs/18/4/2/7/0/8/4/4/tasch-b24072b74be9655a.JPG

I actually saw a video a month or so back where they fed I believe ChatGTP 4 an image of a UI literally scribbled onto a napkin and it was able to turn that into an app. Not fully functional of course, but regardless, the AI was able to build the UI from it. That's where the idea came from.

Honestly, a basic calculator is not a complicated UI. It's a small window with a bunch of buttons and a text output area. I'd do a button. Then make it a row of buttons. Then add additional rows of buttons. Then wire it all up and give it a place to display the output. There's no data to persist, no internet calls need to happen, it doesn't need to scale well, and so on. While I don't want to build it, it's not an overly complicated bit of code.

If I'm not mistaken, this is the video where the UI was built from a napkin.

 

[MEJHarrison]

Does it lend itself for easily blocking out and graphically designing the UI first?

I'd think so. If you've ever crossed paths with React, I'd say it's like that, but much cleaner. SwiftUI is also built on Swift. You're describing your UI with code. So you'd need some basics, but wouldn't need to know some of the more complicated parts of the language just for UI.

 

[KingOfPain]

If you can get install media for a variant of macOS for PPC that includes 68k emulation you could try run it in UTM.
UTM can run PPC macOS pretty well on Apple Silicon, and if the PPC version of macOS still iincludes 68k emulation that should work?

For OS 9.0.4 (or older PPC MacOS) I prefer SheepShaver. While it‘s a bit of a hack, I think it‘s easier to use than UTM, and even though the dynarec doesn‘t work on Apple Silicon, I believe it‘s actually faster as a pure interpreter compared to UTM.