If you could bring back classic Mac OS software, what would it be?
- Thread starter joshc
- Start date
Yep, 9.3 with upgraded USB and much larger Disk Partitions would be fabulous, no IOS crappiness.
Buggage free 9.1.1 re-release for older machines that top out at 9.1 would be quite nice as well.
1997 called and you were not home.
When somebody said system bus I went to the bus stop and waited.
When somebody said system bus I went to the bus stop and waited.
I too preferred SuperPaint. SuperCard was a separate product to HyperCard, and lasted quite a long time -- the last version was 32-bit Intel, so lasted until 2019 as runnable software. It then stayed in support until 2024 when Scott passed away and the site was taken down.
I never ended up spending much time with SuperCard because it didn't have a free runtime in the early days, and then later on, everything it did could be done in a web browser in a cross-platform manner.
Oh, and then there's GraphicConverter by Thornston Lemke -- slightly more recent than SuperPaint, as it was released in 1992, but unlike SuperPaint, it's still being actively developed today (currently on version 12). And as a bonus, Thornston has made all the "classic" versions freely available - you can still download them from lemkesoft.de today, and he's provided registration codes for them.
I find it awesome that he's been able to keep a shareware product going from 1992 right through 2026 and counting.
I still use GraphicConverter, it still runs well on my M1 MAX.
I almost became an edm artist because of SoundMaster Pro, and PlayerPro … now thinking back, I wish I had.
Interesting. Will it run Arkanoid? As you may be aware, Arkanoid won't run on a Mac that cannot be run in 24-bit addressing mode, so anything running System 7.6 or higher, or a 630 series '040 Mac, all Power Macs, and maybe the 190.
Copland, completed.
Fascinating, but even getting it is the antithesis of everything Classic Mac OS related: there's no compiled application. Nothing turns me off more than wanting to try an application, and finding "type this into the terminal to compile it" without any background instructions. At that point, I just navigate away...
Thanks for the suggestion! Advanced Mac Substitute is 24-bit compatible, so that's no issue. I did discover an actual defect in my emulation (incorrectly setting BufPtr when alternate buffers are used). Another issue is that Arkanoid executes code stored in the alternate screen buffer, so that restriction needs to be relaxed. Also, it sets one of the interrupt handlers, so I have to allow that.
With that, I get working gameplay, although with no sound. So, more work is needed to do it justice — but not a bad outcome for the first day!
I improved the heuristics on my disassembler, allowing me to see the audio output generator. Curiously, while it uses a VBL task for graphics, rather than the typical choice of using the same task for audio, it uses the level 1 autovector interrupt instead, which isn't implemented in Advanced Mac Substitute.
But I was able to reverse-engineer and reimplement the audio generator, and now I have working sound!
But I was able to reverse-engineer and reimplement the audio generator, and now I have working sound!
Nice. 
So at that layer, do you side-step the audio FPU issues altogether? I'm curious how portable that approach would be to non cycle-exact emulators.
The FPU isn't involved, so I'm not really sure what you're asking. There are two issues: One, the installation of an interrupt handler pokes memory where xv68k isn't expecting it, but this is solved by an option that tells xv68k to ignore accesses to exception vectors.
The second issue is that the handler never gets called, because the interrupt isn't implemented. So the code in that handler never runs, and no audio signals are produced. My workaround is to patch the code that installs a VBL task, substituting my own VBL procedure. My procedure does the same thing that the original audio code does, and then calls the original VBL proc.
Well, v68k isn't cycle-accurate to begin with, so it works on at least one.
The reason writing directly to the sound buffer works at all in Advanced Mac Substitute is that reading the sound buffer isn't timing-dependent, but happens automatically when the last sample is written to the buffer. So instead of one sample being read every 44.93 microseconds, the entire 370-sample buffer is read after it's been written (typically every tick) and repackaged into a command that gets sent to sndtrack (the actual sound-producing synthesizer program) over a socket.On authentic emulators, none of this is necessary because the application works as is, so portability isn't much of a concern.
Similar threads
