First, thanks to Henry Spragens for leaving a comment on the Boxy’s Lament post, pointing to his site where he has samples of various fascinating 8-bit Apple II music experiments he did. Lots of pics/info on sound hardware of the time and a bunch of great music demos, be sure to check it out!

Second, I wanted to feature an abandoned Apple II project of mine.  As has been noted in Apple II retro-dom, The TV series LOST featured an Apple II (with the Apple logo replaced by a Dharma one and, apparently, an Apple III monitor being used?) as the “Dharma Initiative computer” — most prominently in Season 2.

Between Season 5 & 6, I had an idea to make an actual Apple II program that would simulate connecting to the Dharma Initiative’s DharmaTel network.  After connecting, the user would recieve a report, from the DI’s perspective, on the cataclysmic Incident that served as the climax of Season 5 and a focal plot point of much of the show.  The user would type out various keywords (highlighted in all caps in the report) to navigate to various parts of the report.  It would include images from the show, translated into Apple II hi-res screens via the jpeg-to-HGR-screen routine I posted about earlier, and use the Beagle Brother’s Pronto DOS to allow somewhat speedy loading of those images.

I made a VERY short demo of the idea, and embedded the disk image in an AppleIIGo java applet. Here’s a screenshot:

Dharmatel Report Demo screenshot

You can try it out by clicking the link below.  Enter anything you want as the username.  You may have to click on the applet’s screen to gain focus before typing.

>> DharmaTel Report DEMO

(Note: the applet seems to hang in Mac Chrome sometimes.  Other browsers seem OK.)

(And really, I should have AppleIIGo set to monochrome monitor mode for more fidelity to the show’s computer.)

I was going to collaborate on the report entries with a friend of mine who was even more of an obsessed LOST fan, but I wanted to wait to see how Season 6 was going to treat the post-Incident world.  Well, the way Season 6 unfolded made the Dharma Initiative’s view of the Incident not so very important anymore, at least to my eyes, and I lost enthusiasm for completing the project.

I still enjoy the image of Desmond messing with the Dharma Apple II with the lid off, though.

© JJ Sonick for Apple II Adventures, 2010. | Permalink | One comment | Add to del.icio.us
Post tags: AppleIIGo, Dharma Initiative, Henry Spragens, LOST, Music, sound cards

Feed enhanced by Better Feed from Ozh

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:

© JJ Sonick for Apple II Adventures, 2009. | Permalink | 5 comments | Add to del.icio.us
Post tags: Assembly, BASIC, Beagle Brothers, framework, Graphics, graphics magician

Feed enhanced by Better Feed from Ozh

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.

© JJ Sonick for Apple II Adventures, 2008. | Permalink | 2 comments | Add to del.icio.us
Post tags: Assembly, BASIC, books, Graphics, hi-res

Feed enhanced by Better Feed from Ozh

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.

© JJ Sonick for Apple II Adventures, 2008. | Permalink | 7 comments | Add to del.icio.us
Post tags: Assembly

Feed enhanced by Better Feed from Ozh

For the game, I’d stick to the medieval setting – Scruffy and Sidekick can simply be “in character” as adventurers, having come to a little towne where they’ve heard tale of a Blacksmith who can make a perfect +2 Vorpal Sword.  In the game’s intro, they would witness the Blacksmith’s cursing the sword and throwing a mighty far distance – all the way, in fact, to a nearby orc-infested tower.  To retrieve the sword, they’ll have to travel to several different locales, bash various monsters, and collect gold to buy better weapons/armor til they’re finally strong enough to storm the tower.

I’m planning to program this in Applesoft BASIC, relying on the Beagle Brothers’ tremendous Beagle Graphics to create hi-res images, and their ProntoDOS routines to allow speedy loading (for the Apple II) of those images.  The Beagle Graphics program Double Plot has turned out delightful to use, especially in an emulator so I can draw with the mouse (though I do plan to get a mouse for the actual Apple IIs sometime).  Here is the first (and only so far) screen I’ve done, the ‘Presents’ screen that will precede the Title Screen:

Scruffy and Sword game Presents screen

Since I’m using BASIC, I think it’d be best to keep things simple.  They’re won’t be any animation or even single frame sprite-shapes moving about the screen — all graphics will be static screen images and all input will be menu-driven (Beagle Graphic also allows for easy programmatic printing of text to the Hi-Res screen from BASIC).  So for instance, in Town, the top half of the screen will show a picture of the various buildings Scruffy and Sidekick can enter, and on the bottom half will be a simple lettered menu reiterating those choices (Where should we go?  A. Marv Ellis’s Shoppe B. The Blacksmith C., etc), with one choice being Leave Town. When the player leaves town, a new image is loaded showing the nearby landscape and available place to go, and an appropriate menu.   Likewise, combat will be a similar affair, if a bit more complicated display wise: An image of the enemy on the upper left half of the screen, an image of Scruffy and Sidekick on the upper right half with stats displayed below each (that text would be dynamically added after the picture has loaded), and the bottom half would be used for hi-res text, alternating between menu of choices and displays of battle results.  That kind of display for combat would be similar to, but simpler than, the ones used in Wizardry, The Standing Stones, Wasteland and such. Here’s a Wasteland combat for example:

Wasteland Combat example

The Double.Scrunch utility provided with Beagle Graphics allows nice compression of hi-res images that must be stored on and loaded from a disk.  Using it, I’m hoping I can get around 40 hi-res images on a single disk (I’ll be making hi-res and not double hi-res images to save space).  The game would then consist of two disks.   The first disk would hold the BASIC program, the required Beagle Graphics loaders, and a few introductory images.  After the BASIC program loads, and intro graphics are viewed if the player wishes, the player is asked to insert disk 2 into the drive.  After that, all images needed are loaded from disk 2 as the game unfolds.

With that framework, I’m hoping I can make an amusing little game.  We shall see…

© JJ Sonick for Apple II Adventures, 2008. | Permalink | 4 comments | Add to del.icio.us
Post tags: BASIC, Beagle Brothers, Beagle Graphics, RPG, Scruffy and Sword

Feed enhanced by Better Feed from Ozh