MODTracker audio replay on early 68k macs

[Snial]

Bumping this. I am going to port the ProTracker replayer to 68000 Macs one day, I just need to set up a development environment that compiles C code (for loader/GUI) and assembles assembly code (replayer/mixer), linking together the two into a single executable. Any suggestions for a dev setup for this purpose on System 6?

I played with Retro68 for the work I did on MODTracker, but frankly I'd choose THINK C 5 as it's a much cleaner, direct development environment. It works under System 6 and you can do inline assembly pretty well. You can write your VBL (replayer/mixer) task to work in inline assembly. Assembly stuff can see the 'C' symbols and vice versa. THINKC can do Object Orientation with a subset of C++ features including virtual methods and has a well respected Class Library (TCL) for writing OOP-based apps.

 

[8bitbubsy]

OK, so THINK C 5 it is, but I need an assembler as well. I don't want to inline the whole mixer and replayer, and I want both of those to be in 100% assembler for minimal overhead.

 

[Snial]

OK, so THINK C 5 it is, but I need an assembler as well. I don't want to inline the whole mixer and replayer, and I want both of those to be in 100% assembler for minimal overhead.

I understand. Maybe MDS could help there. But inline assembler is a very nice old-style inline assembler, where you just do stuff like _asm { and then type lines of assembly until you want to stop with } . It's not like GNU inline assembler. It sets up a stack frame, which costs a couple of instructions.


Which compiles to when you choose Source: Disassemble:

-cheers from Julz

 

[8bitbubsy]

Thanks! That’s indeed nice and clean. No need for a separate assembler after all. Does it support the REPT directive for repeating a block of asm code?

 

[olePigeon]

If it matters at all, as a non-programmer, I discovered that the AI coding agents will actually produce useable code for THINK C. I tried for many, many hours to get it to do anything for CodeWarrior with zero success. I think it's because the code it steals for THINK C is, by necessity, clean and concise as it must adhere to specific standards. CodeWarrior is more loosey goosey and forgiving of mixing styles and standards, so the code the AI steals and regurgitates is really sloppy.

I'm only saying this incase you use it as a tool for a tiny bit of troubleshooting or for commenting code and/or libraries to better understand what's going on. It's also the only thing of (relative) value I feel I could contribute.

 

[joevt]

MPW has a powerful 68K assembler that supports macros and such.

Can you link object files generated from that into Think C? I did that with Think Pascal.

Attached are some projects I implemented in Think Pascal and 68K Assembly from "Zen of Graphics Programming" by Michael Abrash (First Edition © 1995). The code in the book is C and i386 assembly.

The 68K assembly files have extension .a. I think they are formatted in MPW with Geneva 9 pt font, tab space 4.
An MPW worksheet named "Compile" has commands for compiling the assembly files (to generate object files) and doing other stuff in MPW such as searches. The compile commands should probably be converted to an MPW MakeFile (with dependency lists, etc.). In this worksheet form, you select a command to execute, and press enter - similar to BBEdit.app worksheets in modern macOS.
The files use classic Mac OS carriage return line endings. If you add them to a GitHub repository, you'll want a script to convert to and from Unix linefeed line endings and to add the MPW or Think file type and creator codes.

 

[Snial]

Thanks! That’s indeed nice and clean. No need for a separate assembler after all. Does it support the REPT directive for repeating a block of asm code?

I guess you could use the C pre-processor? Define the block of code in a macro, then define a rept macro to repeat another macro a number of times with some kind of recursive #ifdef trickery? Finally, have a AsmRept(n, macroName) in the asm block?

@8bitbubsy , [ @joevt ], if you're familiar with MPW, it's more of a heavy-weight, more sophisticated development environment, which perhaps is worth looking at. It's not really like a VS / THINK / Xcode / CodeWarrior / Eclipse type environment though. Steeper learning curve, but more rewarding if you're committed enough.

 

[Snial]

Thanks! That’s indeed nice and clean. No need for a separate assembler after all. Does it support the REPT directive for repeating a block of asm code?

e.g:


Works, although it's a little clumsy.

 

[8bitbubsy]

e.g:

View attachment 99324
Works, although it's a little clumsy.

At least #define can be used for inline asm, that is good enough for me (#define a block of code, repeat the definition N times inside the inline asm).

 

[MIST]

So you'll port the Amiga code to the slower Mac _and_ add a software mixer? Sounds cool. When do you expect to have some working demo?

 

[8bitbubsy]

So you'll port the Amiga code to the slower Mac _and_ add a software mixer? Sounds cool. When do you expect to have some working demo?

Yes. I already made a 4ch 16-bit software-mixer for 7MHz 68000 Amigas using the original PT replayer, so I know it works. It mixed at around the same rate as the Mac version will use (22kHz).

Not sure when I'll have something to show off, I'll need to set up some stuff on my Macintosh Classic first, then find the motivation.
And I also need to take into account that I may get stuck getting it to be fast enough. I know there are some limitations on 68k Macs as the available CPU time is not really 100%.

 

[Snial]

Yes. I already made a 4ch 16-bit software-mixer for 7MHz 68000 Amigas using the original PT replayer, so I know it works. It mixed at around the same rate as the Mac version will use (22kHz).

Not sure when I'll have something to show off, I'll need to set up some stuff on my Macintosh Classic first, then find the motivation.
And I also need to take into account that I may get stuck getting it to be fast enough. I know there are some limitations on 68k Macs as the available CPU time is not really 100%.

Original 68K Macs up to a Mac Plus, have about 6.5MHz of effective performance, because the video hardware fetches a word every 8 cycles when copying the actual frame buffer. Thus 4*(512/16)*342*60.15=2633126.4 are taken/ second. In theory, this leaves only 4866873.6cycles /second, but obviously a lot of 68000 instructions have internal cycles so it's a bit better than that.

The Mac SE and Mac Classic are a bit better because they fetche 32-bits every 16 cycles (1/4 potential memory fetch cycles). Thus 2633126.4/2=1316563.2 are taken/second, leaving 6.2M cycle/s available for the CPU. Having written that the Mac Plus has 6.5MHz of CPU, that can't quite be right, because it implies the SE has: 6.2M/4.9M*6.5MHz=8.2MHz, which is impossible. Hmmm.