Apple II Adventures

When I started this blog, I imagined I would be focusing almost exclusively on software/programming, a) because I don’t have the skills to attempt my own hardware hacks and b) because I wanted to explore what has/could be done with an Apple II that was not enhanced with expansion cards (outside of the pretty standard 64k aux memory card).

Well, I was wrong.  Or rather, I discovered that while a) and b) are still true, I am also c) VERY interested in enhancing the Apple II with hardware when it comes to sound.  Inspired by the 8 bit Sound and Fury site, I acquired a Mockingboard and started looking around for a more complex set-up that would include a music keyboard I could use to make real-time synthesized music on the Apple II.

Several weeks ago I bought a set-up that realizes this wish.  It includes the Passport Designs Soundchaser keyboard and accompanying interface card and software, and the two Mountain Computer Music System cards that actually do the music synthesis.  I also picked up a Decillionix DX-1 Sound Sampling card at the same time.

Here you can see the Music System cards (connected to each other by their alarmingly thin white ribbon) in slots 4 and 5, and the Soundchaser interface card in slot 7 (behind the Music System cards you can see the Mockingboard and the DX-1):

Here’s the Soundchaser keyboard with its software running in the background.  The rainbow ribbon in the lower left runs from the Soundchaser interface card into the keyboard.

The Soundchaser’s software interacts with the Music System cards to play two sounds simultaneously whenever you hit a key.  The two sounds (oscillators) each have separate envelope parameters (attack, decay, sustain, release) that can be tweaked in real-time, and there’s also a Low Frequency Oscillator effecting both sounds that likewise can be tweaked real-time.  In addition, three basic waveforms (one for each sound + one for the LFO) can be separately edited.  All of that means there’s quite a lot of flexibility and fun to be had in playing around with the various settings to produce different sounds.  (This seems in stark contrast with the software that came with the Music System cards – its default sounds are horrible and tweaking them seems fairly laborious — it seems like the Soundchaser folks did some careful thinking about how to get better sound out of the Music System than the Music System’s original creators did.)  Once you have tweaked a particular voice to your liking, you can save its settings to disk as a Preset to be recalled again.  10 Preset voices (default or your own) are loaded at any one time, and you can switch between them while playing.

The DX-1 Digital Sampling card, which I hadn’t rabidly wanted like the keyboard (I almost didn’t get it), ended up being quite versatile.  It can hold up to 8 digital samples at once (the total depends on the size of the individual samples), and comes with three sets of example samples on its accompanying disk.  It actually has a very clean sound and responds great to real time, musically-pitched playing (triggering) via the Soundchaser keyboard. I haven’t tried sampling an original sound yet, I need to buy a proper cable for that.

The following example recording is a sloppy mess, but it gives you an idea of some of the sounds the Soundchaser and DX-1 are capable of.  This was mostly recorded one track at a time, with a little double-tracking on the Apple II via the Soundchaser software’s 4-track recording feature.  The drums are the DX-1 in ‘rhythm mode’ (ie, a loop) – occasionally played backwards (a DX-1 feature), and the bass line and first (and sporadically recurring) lead are both DX-1 samples being played in real-time via the Soundchaser.  All the other sounds are produced by the Soundchaser software via real-time playing of the keyboard.

Audio clip: Adobe Flash Player (version 9 or above) is required to play this audio clip. Download the latest version here. You also need to have JavaScript enabled in your browser.

(Download ‘The Awkward Party’)

Anyway, with this fun new gear, I hope to produce a new bit of Apple II music every month for the Mozomedia Music Podcast, starting with the June episode.

Whoa, it’s been a while since I last updated!  That’s partly due to so-called Real Life eating up my time, and partly due to me spending time arranging and launching my first podcast, the Mozomedia Music Podcast.  While that has meant a drought for this blog, the good news is that I want to feature Apple II-generated original music on that podcast, and that means I’m motivated to a) make some more soundsets for Michael J Mahon’s Real Time Synthesizer b) make a ‘play the Mockingboard with your Apple II keyboard’ Applesoft program that’s hopefully superior to the pathetic ‘play with the keyboard’ program that’s included with the Mockingboard demo disk.

In Search of an Engine…

Even better news for this blog — I’ve been obsessing over, and have successfully cobbled together an Apple II game engine framework recently.  The basic idea was to have the ideal handful of speedy machine language routines handling graphics and sound that would be called when needed from an Applesoft BASIC program – the BASIC program would handle input and general game logic.  Of course, such a set-up would not work for an action game (because of Applesoft slowness) or for scrolling graphics, etc, but it could be sufficient for an adventure game, simple strategy game, or turn-based, light RPG game.

Out with the old…

I actually collected such a game framework previously, for my Scruffy and the Sword game idea — that first framework involved the combo of ProntoDOS for disk loading speed, Beagle Graphics routines for images and hi-res text, and a little assembly language program (also by the Beagle Brothers) for simple music.  Well, that will still be a great framework for that game, but I’ve become unenthused about that implementing that particular game and that previous framework has some problems.  Beagle Graphics is wonderful for making it easy to produce quickly produce nice hi-res pictures thanks to mouse control, various geometric shapes being available, etc.  But the graphics it generated, even when compressed with the nifty program Double.Scrunch, were still fairly hefty in size — I could hope to maybe get 40 or so of them on a disk that held no other files.

It would be far superior to use a program like Penguin Software’s The Graphics Magician, which records the steps used to draw a graphic instead of saving every point on the screen, which allows for amazingly compressed images files (really vector-construction instruction files) that are speedily reconstructed by TGM’s included assembly routines.  I would be able to get 200 or so such files on a single disk compared to Beagle Graphic’s 40.  Also TGM allows you to designate certain images as ‘objects’ that are to be drawn over other images at chosen x,y locations.   For example you could have a table background and one bottle image, but draw 3 copies of the bottle image on the table at different locations.

The main issue I had with The Graphics Magician was that its controls, esp. compared to Beagle Graphics, were horrible.  Using the joystick to guide the crosshair cursor was too unwieldy, even in its restricted movement ‘zoom’ mode.  Fortunately, I found on a disk image of a version of The Graphics Magician released later than the physical copy I own, and this later release has a mouse control mode. This makes all the difference in the world in terms of achieving the desired image!  Unfortunately, I don’t have a mouse for my actual Apple II’s, and this mouse mode hangs in the Virtual II emulator, but it does works perfectly in AppleWin, so I’m fine with booting into my Windows Boot Camp partition to do some Apple II image scrawling.

Memory Wrangling

The other issue with Beagle Graphics is that its machine language routines did not play nice with some sound routines I wanted to use.  I tried the sound routines one-at-a-time in conjunction with Beagle Graphics, but there was always some kind of memory conflict that clobbered the sound routine.  The only one that worked was the most basic of the ones I was contemplating.  Graphics Magician, on the other hand, offers two different versions of its main drawing routine, one that resides in high memory ( 36096 / $8D00 ), one in low (4096 / $1000).   Using the low memory version, I was able to run Joe Strout’s very versatile Sound Wizard routine with no conflicts!  (Sound Wizard’s on the 1990 disk from the Sam Stoddard Nibble program collection available here.)

I didn’t leave the Beagle Brothers completely behind, though – I still want to use ProntoDOS for its impressive boost to read/writing from disks.  Also, this time around I’m utilizing ProntoDOS’s DOS-Up program which I foolishly overlooked before.  DOS-Up moves DOS into the language card/RAM card area of memory ($D000-$FFFF),  leaving a huge extra swath of high memory (around 10k) available for use.  This solved another problem, because normally the one disadvantage of using the low-memory version of Graphics Magician’s PICDRAW is that the safe buffer for storing pictures/variables reduces from from around 12k to 3k.  However, with DOS-UP, suddenly there’s a nice wide expanse of high RAM that can be loaded with many TGM images for swift recall (instead of reading images from a disk each time they need to be displayed, it’s possible to load multiple images into memory at once at the beginning (or at various transition points) so they can be speedily summoned).

The one remaining snag was The Graphics Magician’s character generation routine, HPRINT.  The routine itself worked fine, but the process of Applesoft looping through ASCII characters in memory and plugging them into proper locations for HPRINT to work on made the printing of a single line a slowish affair, and the printing of a screen’s worth of text would be painfuly slow (unless you wanted to always have a ‘typing typewriter’ kind of effect).  So this lead me to write my first (!) assembly language program, HPRINTHOOK.  It’s very simple, but gets the job done.  From BASIC, you poke in the starting address of the ASCII text you want to read (the text has been previously BLOADED into memory), poke the text’s x and y screen locations for HPRINT, and then call HPRINTHOOK, which handles looping through the ASCII codes in memory and handing them off to HPRINT immensely faster than Applesoft does.  It also handles carriage returns (signified by a $04 byte in the string of ASCII) and returns to the Applesoft program upon hitting a $00 byte (which serves as an ‘end of message’ delimiter).

So with those programs, the framework’s memory usage is lined up like this:

• 39936 to 48815 ($9C00 to $BEAF) — Space for Graphics Magician images, binary ASCII files loaded into memory for quick access, etc
• 39600 ($9AB0) — HPRINTHOOK
• 39424 ($9A00) — HPRINT PL
• 36864 ($9000) — SOUND WIZARD
• 16384 – 36608 ($4000 to $8F00 ) — BASIC program and variables (HIMEM is set to 36608, BASIC program start has been poked to begin at Hi-Res page 2, $4000)
• 8192-16384 ($2000 – $4000) — Hi Res Page 1
• 5120 – 8192 ($1400 – $2000) — free space for misc.
• 2048 – 5120 – ($800 – $1400) — PICDRAWL

So that gives a good amount of room to play, both for the BASIC program, and for big chunks of graphics/ASCII text in high memory — and Sound Wizard is left unscathed and ready to sound-effect-ize.

Here’s a screenshot from a test of the framework running on Virtual II (apologies to Tom Wham for bastardizing one of his wonderful Awful Green Things):

Not the best that’s achievable with The Graphics Magician, but the test draws the Awful Green Thing, then draws the exclamation point as an Object Image over the Awful Green Thing, then Sound Wizard is called to play two effects to make sure it hasn’t been clobbered by any other routines, and finally HPRINTHOOK reads some ASCII bloaded into high memory and prints it out near instantly.  All of the routines are happily working together!  And the test also worked in AppleWin and on my actual Apple IIe and IIc.

Now to decide exactly what game to make with the framework (I have several ideas swirling around…)

***

P.S. I haven’t completely neglected my Apple II game-playing during these past months – I’ve enjoyed sporadic bouts of Bard’s Tale III on the Virtual II emulator (an emulator’s save state can come in handy) and Might and Magic II: Gates to Another World on my real IIe (very entertained by double hi-res graphics the likes of which I never witnessed on the Apple II grew up with).  I find it strangely addicting to level grind in both of them, but I am greatly wary of how vast both of the games are — the level-grinding/exploration could literally go on for hundreds of hours, so I’m not sure how long I’ll stick with them, but they’re definitely highly playable and refined dungeon/outdoor crawls of their era.  Bard’s Tale III screenshot:

Strategic Simulations Inc. (SSI) was one of the companies known in the 80′s for, among other things, bringing complex turn-based wargaming to the Apple II.  The kind of wargames known for large hex-based maps, complicated rules, combat units defined by many various stats, and simulations of historical conflicts – the kind of gaming grognards (also see here) might like (though how well these complicated table-top wargames translated to Apple II games varied).  As well as historical conflicts, some games explored hypothetical scenarios (NATO vs USSR with then-modern armies, for instance).  Some hypothetical scenarios even reached into a nuclear-war-radiated future complete with cannibals and motorcycle gangs, as evidenced by Roadwar 2000, which was released by SSI in 1986 (requiring a mere 48k of memory).

Roadwar 2000 is a turn-based strategy game that puts you in charge of a gang of, well, road warriors in a post-apocalyptic North America.  With the government mostly broken down, you and your gang are the only hope to track down 8 scientists who have a cure for a nasty mutated virus threatening to wipe out what’s left of humanity.  While carrying out this search, you have to take on the rival gangs and factions controlling what’s left of the continent’s cities (hopefully gaining control of the cities yourself) — and to do that you’ll need to amass better and bigger vehicles, more and more-highly-skilled gang members, lots of fuel, weapons and ammo and fight a bunch of Mad-Max-esque road battles.  Well, okay, it’s kinda awkward to place a do-gooder, world-saving quest on the shoulders of high-octane-highway-carnage-makers, but you didn’t come here for the plot, did you?

The game starts you off on a random location on a North American map that’s several monitor screens wide and high in total size.  Here’s an example screenshot:

On this screen you decide to investigate your current location, move to an adjacent location, and various other actions.  A neat thing about the map is that different kinds of locations have truly different qualities – bigger cities will have higher quality vehicles to scavenge and more supplies, but likely tougher enemies lurking in them than towns; oil fields have lots of fuel available but are usually already watched over by a strong rival gang, etc.   Moving costs fuel and food, so there’s strategy involved in every move you make.  A complaint about the map screen:  you press a number key to choose direction of movement, but on a keypad the numbers do not match the compass point positions they represent – they’re counter-intuitive.  This seems to be a holdover from other SSI games of the same era.

You can Search a location for loot (vehicles and weapons) or people (new gangmembers), all of which you desperately need at the beginning of the game.  When looking for new recruits, you’ll encounter various groups who may join you, or fight you.  If there’s a fight with a ‘footgang’, you get to enjoy the most unfun part of the game.  These battles are tiresome scrolling text ’2 Gangmembers killed’ , ’1 Gangmember killed’ affairs with no input available for tactics, etc.   These battles are often very rough, too, especially when you’re starting the game. You can send out a scouting party to get the lay of the land first (for instance, to discover that the town is held by deadly religious fanatics, which tells you you’d probably want to skip scavenging for now), but those scouting excursions can cost you personnel as well.

Fortunately, the actual road battles make up for the annoying footgang battles.  Here your vehicles, with their various ratings of maximum speed, maneuverability, carrying capacity, breaking and acceleration capability, etc. come into play.  Here’s an example stats screen of a vehicle:

You’re shown a top-down view of the battleground, which is nicely detailed and, like the N. American map, several screens wide and tall.  As well as roads, vegetation, fences, and various obstacles you’ll also see the flaming wrecked vehicles of other gangs’ battles littering the road (and you’ll add your vehicles to their number if you’re not careful!). Here’s an example:

And another portion of the same battle area:

You can manually choose (within certain limits) the starting locations of your vehicles and choose which gang members will occupy which vehicles, or have the computer automatically handle that set-up.  Appropriately Road Warrior-ish, you can (and should) deploy men both in and *on top of* your vehicles.  Then it’s time to rumble!

Road combat is pretty engrossing because there are a lot of factors at play.  A vehicle’s maneuverability effects how many 45 degree direction changes it can make during a single turn, and is further effected by speed and damage.  Moving fast is helpful to avoid getting rammed or boarded (yes, both you and the enemy can board and capture each other’s vehicles), but can end up taking you where you don’t want to go thanks to momentum and reduced maneuverability (tactical braking is just as important as accelerating).  Ramming is a useful tactic but can do damage to both vehicles (unless it’s a flatbed truck vs. motorcycle situation).   Your vehicle’s facing is ever important since it determines both where your current speed will force you to go as well the directions its crew can shoot in.

The AI seemed fairly competent in the road battles I’ve fought so far.  It moved its vehicles into decent line-of-sight positions to shoot at me, and certainly took full advantage of ramming me when I sloppily passed too close with flank exposed.  I did see one of its vehicles get unnecessarily stuck between some of the flaming wreckage on the road, so it might be a mixed bag.

Overall, Roadwar 2000 offers a unique setting for turn-based strategy and an original flavor of tactical combat, despite some various quirks.  I need to play more to render a final judgement, but it seems to have enough detail to be interesting, but not so much detail as to be overwhelming, and I’m definitely motivated to play more to witness some epic many-vehicle battles – bring on the trailer trucks!

A group of South Korean Apple II enthusiasts have been making some homebrew clones of the Mockingboard sound card and selling them on eBay recently.  I was lucky enough to win one of these auctions, and the card arrived last week and was installed this weekend.

Here it is installed in slot 4 (that’s the Disk Controller card in slot 6).

Here’s another shot that shows the stereo jack line running out the back of the IIe:

The auction made it clear that the speech synthesis aspect of this clone was iffy, but that’s fine with me, because it’s the music/sound effect aspect of it that I’m interested in.

I ran the stereo jack to the two desktop speaker/floor bass speaker unit I’d previously used with a PC that died a year and half ago (the speakers had just been gathering dust), and it sounds great!  I went through the Mockingboard demo disk and also loaded up Ultima IV and liked what I heard.

I’ve gone through a Word doc version of the Mockingboard manual, but I haven’t had time yet to make any original music with it.  But here’s a sample of some of the Ultima IV music playing though it, which is charming enough to almost make me want to try to finish that game again.  Both Virtual II and AppleWin do pretty good Mockingboard emulation, but, of course, there’s something special about hearing the real thing (or a clone of the real thing ):  Unfortunately, I only have one mike, which means this is a mono recording and you’re missing the cool way the two lead voices are each panned to a different speaker, but it still gives you a taste of Mockingboard-ness:

>> Listen to the Ultima IV title screen music played through the Mockingboard clone

(Edit: I’ll try a direct-in stereo recording later this week, and replace the mono one above with it if I’m successful)

EOS intro

The intro screen (shown above) for Earth Orbit Stations features a nice animation of a space shuttle launching, and the game that follows that neat intro does not disappoint.  EOS was programmed by Karl Buiter and published by Electronic Arts in 1987.  It puts you in charge of building and turning a profit from, you guessed it, space stations orbiting not only Earth but potentially other planets of our solar system as well.

An interesting twist in the set-up is that you are not simply running a government-funded, NASA-sponsored project – you are one of several entrepreneurs competing to make money with your station, through a combination of commercial and research uses of your station’s modules, and by building new and more advanced stations.  Rivals, who can be either computer-run or actual human players, will be building their own stations and trying to beat you to reach the goal of whatever particular mission you’ve currently chosen.

The interface is very nicely handled, which saves this fairly complex program from being too clunky on an Apple II.   A big block serves as the cursor, which you move by the joystick to select menu options or to inspect and place station modules.  The menus themselves are easy to navigate – moving around to get the information you need goes pretty smoothly.  There is an amount of disk-swapping you have to endure when first loading the game (and when first creating your own mission disk to save gaves onto), but once you’re playing, if you’ve got two drives, there doesn’t seem to be any annoying swapping at all.

Each game turn is a fiscal quarter.  You’ll start by being greeted with news articles for the current quarter, which you can peruse or ignore.  Most of these have to do with the fluctuations of various markets, but there are some flavor ‘scientific discovery’ and such news items.

Once done with the news, it’s wise to hop into the Commerce menu and check the market activity screen, which will show a color-coded summary of which markets (pharmaceuticals, forestry, resources, etc etc) are on the upswing, which are stable, and which are falling.  This info will help you plan what new station modules to buy, and tweaks you may want to perform on your existing modules.

Then you can head to the station screen, where you can peruse, buy, and place new modules, and even start additional stations if you have the funds.  Each station has to have a set number of bare necessity ‘support modules’ (living quarters, power, gym facilities, etc.), after that you’re free to build as you like, constrained by your money (you can take loans, deposit money in savings, etc) and your tech level.  You can, for instance, install a solar collector module which will give you a big energy boost, as well as being available for commercial and research uses.

Each module has its own crew and energy requirements, as well as quarterly upkeep cost.  Each module can either be set to commercial use (you basically lease it out to those who will pay), research (gives you technology points), or deactivated (if you don’t have enough of a support coverage to go around, for instance).  When you buy a module, you rotate it and place it sorta Tetris-piece style in the ‘grid’ of your station.  Connector pieces form the backbone of your station around which the modules attach.

Here’s the humble beginnings of my station in my first game:

My EOS station

And here’s it a little further on:

My EOS station, expanded

BTW, I apologize for the dodginess of the screenshots (like the washed-out-ness of the first of the two above).  While it would be very simple to get emulator screen captures, I’d rather post images of games running on the actual Apple hardware, but I haven’t figured out the best settings for doing this yet with my Canon PowerShot – so I apologize for scanlines and other ugliness.

You’ll notice in the second station screenshot that some of the modules are green – this represents that they have been set to commercial use for the current quarter.  The non-support modules that are not green are carrying out research (a disabled module will show as blue).  In the commerce menu, you can see how much use paying customers are making of your available modules, and combine this info with the current status of the markets to decide if you’re going to change the rate you’re charging for that kind of module, or switch a module to research or even de-activate it.

Here’s a shot of inspecting a module from the Commerce menu (the big ugly scanline is not on the actual screen but thanks to my poor photography skills) :

Looking at a module in the Commerce Menu

It’s pretty fun expanding the station, and gives you an immediate incentive to manage things wisely so you’ll have more moolah to expand further and get more advanced stuff.  And, of course, there’s your competitors to goad you as well.

The first mission I tried was a race to see who’d have the most recent points by a certain end date.   You have to have everything set to commerce as first, to build up enough funds to keep you going and expand, and then switch some over to research.   I started to think my two computer opponents, the dastardly ‘apple 2′ and ‘apple 3′, were dim bulbs, because as we neared the end date, they both still had almost all their non-support modules set to commerce, where I had been doing a balancing act for awhile, steadily building up some research.  Unfortunately, I was wrong about their dim bulb-ed-ness – by the very last quarter their increased funds had allowed them to expand very far.  In fact, evil apple 3′s station filled the whole screen:

Apple 3's station

And he dastardly switched all those commerce modules to research his last turn, funneling in the research points!

Apple 3 is a jerk

This won Apple 3 the game.  I did beat Apple 2 though, who had tried a variation on the switch-at-the-last-minute strategy.  Anyway, it seemed to bode well for the AI not being a push-over.

There’s also a lot of things I didn’t get to see in this particular game – with advanced stations you can have a docking station for space shuttle missions, send out planetary probes, maintain a space hospital, do mining and refining, even attach a propulsion unit to your station to make it mobile and take it other planets.  So I should be getting some more fun out of this well-designed game.

Just a quick post that the Apple IIe purchased from Digital Dinos is now up and running.  I won an eBay auction for a homebrew Mockingboard clone, so I figured I should set up the IIe so it’ll be ready to receive that sound card.

Set-up went smoothly. I installed the Expanded 80 Column Card and the Disk Drive Controller Card in the IIe, hooked up the drives, monitor, and power, and gave it a spin.

Apple IIe Setup

I used Infocom/Westwood’s Battletech game to test both the extra memory on the 80 Column card (the game requires 128k)  and to test the drives (it can use 2 drives).

My IIc in pristine shape, its case clean and non-aged.  This IIe on the other hand has typical yellow-y aging on the case, and is also scuffed up and marked a bit.  Yet I never had a IIc growing up, I had a IIe.  I have a more immediate connection with the IIe’s size, shape and the feel of its keyboard.  Using it feels more like an authentic time machine.

Apple IIe closeup

The IIc has certain advantages:

1. Its compact size means there’s a bit more deskspace when it’s occupying the computer table instead of the IIe.
2. Its headphone jack is *very* handy for recording its audio output (I ran it straight into a Zoom H4 recorder).  Since making 8-bit music on these computers is one of main interests, that’s a big plus for getting a clean recording.  The on-its-way Mockingboard clone has some kind of ‘stereo jack’ – I’ll have to see how well that works, but even so, for non-Mockingboard audio, like RT.SYNTH, I’d have to stick a microphone somewhere near the IIe case.  So for doing final recordings of Apple II audio, I may end up mostly using the IIc.
3. I would need another card (a super serial card) to do disk transfers with ADTPro on the IIe.  With the IIc, you just use its built-in serial port.

Nevertheless, the IIe’s greater nostalgia/personal time-machine aura means I will probably use it more, outside of the necessary audio recording and ADT uses of the IIc.  And of course, the IIe’s expandability though its available card slots is a huge plus, and something that drives a large portion of the current 8-bit Apple enthusiast community.  Playing with the Mockingboard should be good fun, and I *do* want to get and try out the Uther ethernet card and the CFFA card (basically a Flash card hard drive for the 8-bit Apples) at some point.  For that matter, a TransWarp card is looking good to speed up some of the slow SSI strategy games I’ve been playing.

Thanks to Simon Williams’ site 8-bit Sound and Fury (be sure to check out the software and great Apple II-generated music there) and Michael J. Mahon’s Real Time Synthesizer, I’ve begun my musical journey with 8-bit Apples.

Simon’s site and an email conversation with him lead me to look closer at Michael’s RT.SYNTH, which allows the real-time playing (via your computer keyboard) of 8 different synthesized instruments (one instrument at a time), each of which can play in 6 octaves. You can switch between instruments and octaves in real-time, and record and play back your performance as well. It’s is all software-driven, requiring nary a Mockingboard or other add-on hardware. For all the juicy details, visit Michael’s site (linked to above).

It is also possible to build new virtual instruments (voices) for RT.SYNTH. After I emailed him about creating new voices, Michael kindly provided extra info and some programs he uses to build the voices. I had many false starts, producing wav files (transferred to disk images thanks to Apple Commander) that crashed the voice-generation programs, and after that producing voices that crashed RT.SYNTH once loaded.

But fortunately I was able to produce two new, working voices. I have to say, it really helps to do work like this on an emulator, as parts of the audio-processing procedure would be painfully slow on the actual Apple, whereas I could crank Virtual II‘s speed up and whip through it (which also made it less painful to start over when the voice didn’t work). On the other hand, Virtual II’s sound emulation, which is solid in general, makes a slow-responding, tinny mess of RT.SYNTH’s music. To really hear its instruments as intended, you need to run RT.SYNTH on an actual Apple. So once I discovered the voices were functional, I was happy to transfer their disk image over to my IIc via ADTPro and try them out for real.

Both voices are based on a sample of one of Logic Pro’s clavinet instruments, which I’m very fond of. By the time I had created the first non-crashing voice, I had still messed up either the sample, the sequencing of the sample, or both, but it turned out to be a happy accident, as it produced a off-kilter spacey timbre that would not sound out of place in an 80′s video game:

>> Hear a bit of the Spacey Voice

The second non-crashing voice used more portions of the same sample, and was more ‘correctly’ constructed, as it sounds more like the original. But it’s too short (fades too quickly for it to achieve the clavinet sound) and ends up not be as fun as the ‘mistake’ voice. I’ll revisit it later and try to get it closer to the clavinet original:

>> Hear some of the Sorta-Clavinet-y Voice

I’ll be sure to work on some more voices, and post a disk image of them once I’ve made a decent collection, for any other RT.SYNTH users to try out.

I read a description of how memory addressing for the hi-resolution screen works three times, each time from a different source.  The first two times my brain simply melted before such a byzantine structure.  The third time it finally clicked.  Surely this had something to do with it being my third attempt to grasp the concept, but I believe even more of it had to do with the third source’s description being the most clear, well-written and well-illustrated.

That third source is “Applesoft BASIC Subroutines & Secrets” by Jeanette Sullivan and David Sullivan. It appears to be an excellent book all around.  Below are scans of the two pages on hi-res memory addressing, to assist anyone else puzzling out the same issue:

Hi Res Memory Addressing 1

Hi Res Memory Addressing 2

(click on the images above to download full-size scans)

The book also includes a nifty little BASIC program that will compute the address of any particular block, and lays out the formula the program uses, further reinforcing how the addressing works.  Scans of that are below.

Hi Res Memory Addressing Program

Hi Res Memory Addressing Program

(click on the images above to download full-size scans)

In assembly programming news, “Assembly Language for the Applesoft Programmer” continues its traditional of clear writing/explanations and annoying typos in listings.  I’m also going through Don Lancaster’s “Assembly Cookbook for the Apple II/IIe” — Lancaster completely skips over the basics (he basically waves his finger at you and says ‘Don’t you dare think of using an assembler until you’ve learned to code 100s of lines of machine language on your own’), but has lots of opinionated advice on surrounding aspects of assembly.  I’m learning, slow but steady.

Some of the Maxis open-ended simulation games (SimCity, SimCity 2000, SimLife, The Sims) have been personal favorites and huge time-evaporators for me, so I thought it appropriate for my first mini-review here to be of an Apple II predecessor of The Sims, Activision’s Little Computer People (aka House on a Disk).

Will Wright has said in a CNN interview that he did play Little Computer People “a long time ago. I’ve since gotten to know several people who were involved with that project, and many of them gave valuable feedback on The Sims…”.  This makes sense, since, although they are very different games, there are some interesting similarities in their core mechanics, and of course, the setting.

Little Computer People presents itself as a research project where you, as researcher, get to observe and interact with one of the, you guessed it, Little Computer People living inside your Apple.  This is reinforced by the instruction manual including a place for you to take notes on the habits of your LCP (I’ll use this abbreviation, which the manual does as well, from here on), the title screen of the game featuring a lab research notebook, etc.

The game’s main setting is a a cutaway view of a 3-story house. In this house lives your LCP and his pet dog. As you watch, your LCP will putter about his little domain, performing various everyday tasks and enjoying ocassional diversions.  These activities include making dinner, reading the newspaper, washing up, talking on the phone, feeding the dog, listening to music, etc.  Like a Maxis Sim, the LCP will autonomously move about the house and perform activities on their own, but also, like a Maxis Sim, the LCP may not take the best care of themselves — you may end up needing to remind him to drink water, eat, etc.

This is where the interaction comes in – you can type commands to your LCP, such as PLEASE DRINK WATER, PLEASE FEED THE DOG – they appear at the top of the screen and on pressing return, you LCP will usually oblige your request (it also apparently improves their mood of you THANK him after he does so!).  It might be different on the other versions of LCP, but on the Apple there seems to be some weirdness with when you can and can’t type in commands – sometimes you type, but your input does not appear in the ‘text’ area up top.  This doesn’t happen enough to be truly annoying, however.

You can play games with LCP – anagrams and a couple of card games – which will boost his mood, and one particularly amusing form of interaction is the LCP sitting down at the typewriter and writing a letter — the letter will be addressed to you and will highlight the ways the LCP is currently pleased or annoyed.  In addition, you can refill the LCP’s water cooler, deliver human and dog food to the door, and “pet” the LCP (a little mechanical hand extends beside the lounge chair, which will pet the LCP once he sits in the chair).

Little Computer Person about to type a letter

I was going to try to make a little video of some of the gameplay, but I discovered someone else has saved me the trouble!  Thank you, bluecolor3k (note the sound effects are not so annoying when playing LCP on an actual Apple II):

>> Watch Little Computer People gameplay on YouTube

So how is it as a game (or as a simulation/toy)? The graphics are very charming, and the actions of the LCP amusing, and it’s certainly a very innovative game design.  I’d imagine that after seeing everything the LCP does many time, it would start to get old (this was a problem with the Sims for me as well – at least until I started downloading and mixing-and-matching all the crazy custom content that users made for the game).  However, there is one thing in particular that’s keeping me playing currently – Luther’s mood.

Different LCP (there’s only one per disk) have different ‘digital DNA’ – meaning they have different likes and dislikes.  My LCP’s DNA must have strong sequences of EMO. See this page from the instruction booklet:

Little Computer Person moods

And see my LCP, Lucas, close up:

Lucas the Sad

He always has that expression.  I give him water, food, pet him, play games with him and he still keeps his frown.  I bought my copy used, and the ‘researcher name’ that shows on the title screen is ‘Francisco Quesada’, and maybe Francisco was a very abusive LCP owner, leaving me with tons of LCP bad blood to undue.

Little Computer Person Abuser?

Regardless, I’m determined to make that sour bastard Lucas happy.

Little Computer People manual

As well as a attempting a simple RPG in BASIC, I’m also getting my feet wet with Assembly.  I have two main goals with Assembly, ones that cannot be reasonably achieved with BASIC:

1. Sound creation and manipulation
2. Tile-based graphic scrolling ala the early Ultima games.  Even as I’m coming to general grips with Apple II graphics, I have no idea how this was done, so I’m curious to explore it.

An ultimate goal with tile-based scrolling would be do make some sort of super-simplified Starflight clone (I was always jealous that Starflight didn’t exist for the Apple II) — but that is REALLY pie-in-the-sky – I’d be happy just make a successfully little one-area demo.

I’ve just started “Assembly Language for the Applesoft Programmer” by Finley and Myers, and it seems pretty well written.  Despite the title, it’s not about just getting some binary programs to run from your BASIC programs, it’s more a full-on assembly tutorial aimed at weaning a programmer away from BASIC and into pure assembly.  Assembly’s making sense so far, a lot of which is probably due to my working through the wonderful book Bebop Bytes Back 6 years ago or so.

I’m using the Merlin assembler, which seems to have a very friendly environment, and I’m delighted it allows the entry of decimal numbers, which I’ll be using to “cheat” as much as possible (sorry, purists).

One alarming thing: there was a typo in one of the early sample programs in the “Assembly Language for the Applesoft Programmer” – a typo that was in fact repeated twice.  The program was simple enough that I was able to spot it immediately, but it makes me worried about the longer, more complicated program listings – I might not spot the typos so easily there, which could lead to lots of frustration.  If that becomes a problem, I may have to switch to some other book, which would be a shame, because I like the clear writing in this one.