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.