Help getting started with retro software development

[nightingale]

So lately I've been toying with the idea of developing a new game for my classic macs. I started making a retro-style puzzle game earlier this year in lock down, but then I thought, why not take it a step further and write it for retro hardware as well? The easiest way to describe my game idea is that it is a Chips Challenge style game, where you have to solve puzzles to complete a map. My target system is a stock Macintosh Plus. I want to challenge myself, and this is oldest system I have.

I've been doing some research into different languages and development environments, but before I invest too heavily in going down one path, I thought I'd start by asking for advice. I have some experience coding in C, but I've read that Pascal was the original language of choice for Macintosh. My preference would not be to learn a completely new language, unless there is some compelling reason to write a program in Pascal rather than C. Would there be a performance boost, or anything like that considering the older hardware?

As far as development environments go, I have experimented with Code Warrior on my Power Mac, and I find that fairly intuitive. I've looked at MPW, but it seems like there is a bit more of a learning curve. But again, is there any benefit to learning a new environment? I'm mostly thinking of how the compiled program will run on the Mac Plus.

Also, keeping in mind that my game will be a tile based graphical game, does one langauge or environemnt offer any advantages?

Thanks in advance for any advice anyone can share!

 

[bdurbrow]

How much RAM does your Plus have? If it's not the full 4mb; the first thing I would suggest is upgrading that to the max. Most developers back in the day did that. Also, you will need either a real hard drive; or some modern equivalent (FloppyEmu, SCSI2SD, BlueSCSI, etc).

I would stick to C; probably an early version of Think C. Once compiled, there's no advantage of one language over the other. However, you should familiarize yourself with the differences in the way functions are called; and the difference between a C string and a Pascal string. All the classic Mac C compilers supported creating and calling functions with both styles by way of the 'pascal' keyword.

If you have an original programmer's switch, that would be helpful. Otherwise, get a 3d printed one or improvise something to let you hit the interrupt and reset switches on the logic board. Also, install a version of Macsbug that's appropriate for the System version you are running. You'll also want to download some PDF books that describe how to use Macsbug.

You will also need the full set of Inside Macintosh (volumes I thru III) of course; and here I would "cheat" a little - get the PDF versions and view them on a modern machine that you have (be that a Mac, PC, or iPad).

For graphics, you'll want something that can output PICT files; and you'll want to build a helper application that loads a PICT and slices it into tiles, outputting them as PICT resources. Your basic editor could be something as simple as MacPaint; but if you want to use photos, you may end up running several programs (and possibly an emulator) to go from your modern camera (be that an iPhone, point-and-shoot, or DSLR) to a dithered B&W image in a format that you can convert to PICT files. The old-school way (film, and something like a ThunderScan in an ImageWriter) can be done, but it's a pain to manage.

 

[cheesestraws]

Some thoughts:

This is a good idea and a good project. The classic MacOS is pretty easy to write for, really; it makes some decisions very differently from modern OSes but those decisions are usually fairly sensible in their own right.

The only reason specifically to write in Pascal is if you want to be strictly period or if you like Mac dialects of Pascal. There are some wrinkles in writing C, but there's also lots of sample code out there. If you like C, use C. There's loads of sample code out there in both languages. Use it.

Development environment: run away from MPW as hard as you can. It's a fascinating and powerful swiss-army chainsaw of a tool that uses UI conventions unlike anything else on this good earth. It was a valiant experiment, but at this point belongs more to the history of user interfaces than any sane modern development practice. Codewarrior is good but heavy: if you want something lighter and closer to period that will run on a 68k Mac, try THINK C or Symantec C/C++ (they're the same product, just changed name). If you're willing to try Pascal, THINK Pascal has one of the best debuggers I've ever found anywhere, and I still miss it in my modern software engineering practice. But other IDEs have adequate debuggers too.

ResEdit for editing resources is love. ResEdit is absolute love. Don't fall into the trap of using one of the text-based tools unless you have to. ResEdit makes me happy.

A slightly sideways option here is Retro68, here: https://github.com/autc04/Retro68. Retro68 is a toolchain for modern machines that targets the classic MacOS: if you're comfortable with the GNU tools, and you don't particularly want to develop on an older Mac, it is worth looking at.

Some people will tell you to use macsbug. Macsbug is, let's be clear here, the 'default' debugger, the debugger of last resort. It is flexible, but arcane and unpleasant to use, and is almost always overkill for debugging application level code. I assume these are the same kind of people who tell new developers on UNIX-likes that they have to use gdb, then get secret joy out of watching them struggle. It is one of the perennial shames of the software engineering industry that our debugger UIs are still stuck in the early 80s.

If you want a low-level debugger, something like TMON might be better, but for application code I'd start with just using the debugging tools built into the IDE. They're all "OK".

Inside Macintosh is the canonical reference documentation for the OS and Toolbox. Some of it is decent; some of it is very unclear; some of it is actively misleading. There are two "editions" of it: one where the volumes are numbered I, II, III etc, and one where they're grouped by topic. The ones where they're grouped by topic are much easier to use and read than the numbered ones, where things kind of got added as they happened. PDFs and searchable HTML editions are widely available online, and calls note what version of the OS they're available in.

If you're developing on an old Mac, it's worth getting a copy of THINK Reference (last version was 2.0). This is a desk accessory which provides a hypertext reference to the toolbox. What's key here, though, is that the text was written by different people than those who wrote Inside Macintosh; so where one is unclear, the other is often much clearer, because they have felt the struggle.

I think that's probably about it. By the standards of the time, the classic Mac is pretty sane to write software for, once you've got your head around the OS. Good luck and post here if you need assistance: there are a number of us writing code on a reasonably regular basis who can probably either help or give you a better class of confusion .

 

[cheesestraws]

you'll want to build a helper application that loads a PICT and slices it into tiles, outputting them as PICT resources

or you can just copy and paste from your graphics editor into ResEdit. Or use ICON resources which have a built-in editor in ResEdit.

 

[bdurbrow]

Well, yes, you can do it by hand, but getting each selection on the correct pixel boundaries is going to be rather tedious…

 

[nightingale]

First of all, thank you everyone for all of the great feedback so far!

A couple of points I'll clarify. I have no intention of using the Mac Plus to develop the game -- that's just the target platform for running it. I'm intending to use a more modern machine for development (modern in this context might mean a PPC). That's why I thought of CW at first -- I have it on my PowerMac, and I'm familiar with it. I was more concerned about whether CW or certain languages will create "bloated" applications compared to some of the more era-appropriate tools. I'd love it if I can get my game to fit on and run from a single 800k disk, and work with 1MB of RAM.

I had looked at Retro68, but if there is no clear advantage to using that over CW on a PPC, then I don't really want to learn a new development environment.

As for creating the assets for the game, I may go completely modern and use something like GIMP to create my tileset, and then convert those to PICT resources that the Macintosh can understand. Where this is going to be a tile-based game (let's say 50 distinct tiles as an estimate), I'm thinking I would just store those as resources. I did not realize that ResEdit had a built in editor for ICON resources, so perhaps I can actually do some of the work right in ResEdit. I haven't yet decided how I'm going to store the maps, but I would like to create the ability for people to make their own maps, so they may be separate files. I'll likely create a map editor once I figure out how I want to store things, which will make my work go a lot faster.

Thank you for the suggestions on reading materials -- I had already started looking through some of the Inside Macintosh volumes, but I wasn't aware of the distinction between the two "editions". I think the most difficult part of this for me will be learning the Macintosh-specific things, since I've never written software for this platform before. I have experience with more modern systems.

I'm going to digest all of this great info and may continue to post questions as I continue my learning journey!

 

[dcr]

As I recall, CodeWarrior was pretty much the gold standard for a period. I had (well, still have) it on my PowerMac 7500.

And you definitely want ResEdit. I had a FirstClass BBS and to create icons for different forums and boards and stuff, you used ResEdit on your settings file. I did over 500 icons with ResEdit's editor. So, a definite thumbs-up for ResEdit.

 

[nightingale]

So to get myself started, I've begun work on a Map Editor for my game:




The graphics are just a placeholder, as in I spent about 5 minutes in ResEdit making the tiles. I'll put some more work into them as I progress, but I needed something to work with while I figure out some of the intricacies of the Macintosh Toolbox. This is a good intro for me, and once I'm done this I can move onto the game.

All in all, I'm pretty happy with my progress so far!

 

[cheesestraws]

That's looking promising!

 

[Crutch]

Cool project and looks like you’re off to a good start!

I wouldn’t worry about 68K code bloat with CodeWarrior. An 800K disk is fairly ginormous for the sort of game that is likely to actually work on a Plus (no color, limited sound) and as for fitting in that 1MB ceiling, that’s really just dependent on the code you write. I have written a couple pretty good sized arcade type games and don’t think the CODE resources themselves ever exceeded 100K total. Pretty much any 68K compiler you use is likely to be just fine.

Keep us posted!

 

[Mu0n]

If you want some code snippets here and there in C, I made a website eons ago (2004-2005), which I'll be adding to for the October retrochallenge:

Foray into 68000

The Mac Plus was SPECIFICALLY my target environment as well.

 

[nightingale]

So, I've made some great progress on my project. Creating the map editor was a great way for me to learn, and when I started work on the game itself, it actually went very quickly.

Where I'm stumped right now is on saving data in the resource fork. Essentially, for my maps, I have an icon library in the resource fork, and for each of my maps, I have an array of integers that stores the ID of the icon that should load for each X and Y coordinate. Right now I am saving my maps into a binary file, which works well enough for testing. But I want to store the maps in the resource fork of my app, and I'm not too sure what type of resource would be best for this.

So far the only resource type I've found is STR#, which lets me have an an ID for each map, and then a list of strings, and then my program just converts the strings to integers when loading the map, and puts them into my array. But storing an integer as a string is very inefficient. Ideally, if there is a way that I can store a list of integers or even an array, that would be ideal. I've been reading through Inside Macintosh all weekend, but I'm very stumped here.

Anyone with more experience with resources who can point me in the right direction?

 

[cheesestraws]

But I want to store the maps in the resource fork of my app, and I'm not too sure what type of resource would be best for this.

I think you're confused here because you're conflating two layers of things.

A resource is just a blob of data. When you get a resource, you just get a handle to a block of memory containing that resource. You can treat that block of memory in any way you like. A resource type is just a label to categorise your resources; a resource ID is just an identifier within a resource type.

A layer above that, some of the resource types, by convention, have an internal structure, and utility routines are provided to deal with those. But these are still just blobs of data, really.

Think of a resource like a file-within-a-file: you can treat any given file either as a sequence of bytes, or if you know what format it is, you can use utility routines as a shortcut. But it's still "really" a blob of bytes.

So, if you want to store your own data, invent your own resource type. They need to be four characters long, and if you want a private resource type, it's best to keep them all in lowercase. You can then just use GetResource to get a handle to a block of memory with the contents of one of your resources, which you can then typecast to a handle to whatever you like.

Hope that helps?

 

[nightingale]

Right, so there is no reason why I can't just create my own resource type... As long as my program knows how to interpret it, it will be fine.

A program like ResEdit knows what the common resource types are, and knows how to interpret them and edit them. But just because my resource type is unknown to all other programs, no other programs need to interact with it, so it will be fine. I don't know why I had a mental block on that.

Thank you cheesestraws!

 

[cheesestraws]

I don't know why I had a mental block on that.

Sometimes you just need someone to use the right words. I've been stumped on stuff before that suddenly made sense after someone explained it, then felt like it should have been reasonably obvious

A program like ResEdit knows what the common resource types are, and knows how to interpret them and edit them

For unknown resources, ResEdit will just give you a hex editor, so you can still check that your resources have what you think they ought to have in them .

 

[Crutch]

Don't forget the excellent ResEdit 'TMPL' mechanism ... if you create your own resource type, e.g. 'Maps', you can create a TMPL resource in your resource fork with name 'Maps' and ResEdit will use it to "know" how to format the fields of your Maps resources for easy review and editing. This is even true for resources that contain slightly complicated structures like "some non-repeating stuff followed by a zero-based count followed by an array of structs, then some more non-repeating stuff". It's really quite cool.

This is a great feature while creating/debugging custom resource types. If you like, just delete the TMPL resource from the "published" version (you ARE going to publish right? ) so users can't reverse-engineer your maps quite as easily! If ResEdit can't find the requisite-named TMPL resource in any open resource file, it will revert to the default hex editor.

Explanation of this mechanism in the ResEdit Reference book, chapter 5, which is still freely hosted by Apple here: https://developer.apple.com/library/archive/documentation/mac/pdf/ResEditReference.pdf

 

[nightingale]

Thank you Crutch, that’s a great tip! I love ResEdit for making quick fixes or debugging things, so I will definitely have a look at that!

 

[cheesestraws]

ResEdit is really customisable. In theory you could write an editor to be able to edit your maps directly in ResEdit, but that's probably more trouble than it's worth...

 

[Crutch]

True!

In fact ResEdit was SO good that it basically didn’t need updating for the last 8-10 years of its useful life.

 

[nightingale]

Well, bit of a mixed bag of an update. I was getting very frustrated trying to find correct versions of compilers that would work best for my project (like how confusing is it that CodeWarrior Pro 1 is newer than CodeWarrior 10 Gold??). Also the learning curve for the Macintosh Toolbox was feeling pretty steep. So in an effort to get something done and not lose steam, I switched to RealBasic for the map editor. Now RealBasic programs require a 68020 processor, so I knew this wasn't going to run on my target system of a Macintosh Plus, but I wasn't too worried about that for the Map Editor. As long as the game runs on the Plus, I'm okay with creating the maps on a newer system. Well that went very well, and the Map Editor is basically done, but I will continually modify it as I develop the game and my needs for it change.

I was ready to move on to making the game itself, but was loving the ease of use of RealBasic. So I thought I'd do a quick proof of concept, and in just a few days I basically got a working game made (on account of being able to recycle a lot of the code from the map editor). Obviously there are only a few features, and of course I have spent zero time on the graphics at this point, but here is where I ended up:



I'm pretty impressed with what I got done so quickly. But I didn't want to work too hard on this, since I knew I was basically going to have to start from zero again in CW. This is a black and white game, and it really doesn't make sense if the minimum requirements are a 68020, as that only leaves two B&W systems that it will run on -- the Classic II and the SE/30. So while this quick RB version gave me the confidence to keep going, I'm hitting the brakes on this so I can dive into CW to start again.

My first attempt, I used PowerPlant, and I was quite hopeful that this was going to save me a lot of coding. But alas, when I compiled my test program, it would not run on System 6, it required System 7. And on a Plus with 1mb of RAM, I feel like that's a non-starter. This needs to run in System 6. Plus, with two basic apps that just draw a window and a menubar, the one I coded from scratch was 15K and the PowerPlant one was 220k. So there is a lot of bloat in here, considering most of the functions in the libraries, I probably won't use.

So I'm wondering, are there libraries out there that might help me achieve what I'm going for here without including all the unnecessary bloat and the compiled app will actually run on System 6? If I go with an older version of CW/PP, will the libraries be System 6 friendly? And can I pick and choose the libraries I include instead of all of the ones that are included by default in a PP project?

Hope everyone is enjoying my updates, other than the discouraging day with CW today, this has been a blast to do!