the blog | 65816 dot com

Some Toys I Got

Tue, 10 Mar 2009 22:26:54 -0400

I had fun playing with the Amiga 500, eventually got it up to 4MB of RAM, 750MB of hard disk, upgraded the Kickstart ROMs to 3.1, and put a ton of WHDLoad games on the hard drive by way of RS232 and ZModem (I kid you not). Eventually I got kind of stuck with its slow speed, lack of affordable upgrade path, and worst of all, no ethernet to speak of (yes I'm aware of the rare sidecars or the possibility of adding a Zorro card, good luck with that).

So it's in a closet now. In its place is a brand spankin new Escom Amiga 1200. I got a PCMCIA ethernet card, a 40GB (!) internal 2.5" HDD, 8MB of clockport RAM from Germany, and a brand new Indivision AGA internal scan doubler from their most recent run. The Amiga and Apple IIGS now each get their own displays thus:

Hey, what's that thing sitting on top of the Apple IIGS? The postman also brought me an AE Audio Animator for the Apple IIGS. I always liked the stupid mixer box, but I haven't tried the MIDI yet. In that shot, the Amiga is running Lion King AGA. Let's have a shot of System 6.0.1 and AmigaOS 3.9 side by side:

You can barely see it, but there it is, in 640x480 mode, with colorful icons and the enormous red mouse pointer. I should add that with the Indivision AGA, the Amiga 1200 can push 1024x768. Unfortunately the un-upgraded 14MHz 020 is rather pokey and it runs you out of graphics RAM. Someday I'll spring for what ebay.de (the Amiga supermarket!) calls a "turbokarte", but for now I'm satisfied with the Amiga collection.

Lately I'm getting back to my IIGS video game development (what can I say, goodness takes time), using the IIGS partitions off the CF card, dumped into KEGS-OSX. I'd really like to release something, but I want it to be good. Someday.

-Chris

What Is The IIGS Disk Images

Sun, 21 Dec 2008 15:35:54 -0500

The What Is The Apple IIGS people have come through again.

They appear to have recently gotten onto a CompactFlash kick, by way of the CFFA card. And they've published 10 .hdv hard drive partitions on this page. I've been installing a game or two at a time onto my (Microdrive Turbo) CF card as time permits, but they were way ahead of me. Someone out there actually made sense of all the HD installers and patches.

After playing with the .hdv images in KEGS-OSX and seeing that they were in fact awesome, I ran to Walgreens and paid way too much for a new 256M CF card. Here's the procedure I followed, using a Mac with USB CF reader (which came up as /dev/disk1):

1. Insert old (256M, 8-partition) IIGS CF card, and

dd if=/dev/disk1 of=cfimage bs=512 count=256

This gave me a backup image of my original CF card. The first 256 blocks hold the Microdrive configuration and the partition map, and I need to carry that information over to the new card.

2. Insert new IIGS CF card, and use Disk Utility to re-partition it as 1 partition of 'free space', to keep it from automounting, which kept me from being able to use /dev/disk1. Then,

dd if=cfimage of=/dev/disk1 bs=512

3. Select .hdv partitions to use and install them:

cat WhatIs/System\ 6\ +\ Free\ Games.hdv WhatIs/Action\ Games.hdv WhatIs/Adventure\ and\ Sim\ Games.hdv WhatIs/Sports\ and\ Unreleased\ Games.hdv WhatIs/Social\ History\ and\ Computers.hdv WhatIs/Reading\ Writing\ and\ Maths.hdv WhatIs/Board\ Games\ and\ RPGs.hdv WhatIs/Productivity\ and\ Graphics.hdv > cfimage

dd if=cfimage of=/dev/disk1 bs=512 seek=256

Bingo, just like that, it worked. But understand that because of that 256-block header, the last partition is going to be 128Kbytes short, so some files or directories might not exactly work properly (I think just Emerald Visions 2 in this case).

Between this, and a Golden Orchard CDROM in the AppleCD drive, a stunning percentage of All Things IIGS is available for the clicking. Forgive me as I waste another beautiful Key West Sunday playing games on the Apple IIGS.

-Chris

Adventures Continue

Sat, 20 Dec 2008 20:23:10 -0500

You know how these things go. Work happens. Life happens. Actually, first work got out of hand, then I may have overreacted by moving to the Florida Keys to enjoy a more laid-back atmosphere as it were. But I assure you I'm no stranger to retrogaming despite the recent transplantation of my entire life.

Who's that next to the IIGS? Yes, its old nemesis the Amiga 500. They say they've gotten over that stupid misunderstanding from their BBS years and are the best of friends now. Which is nice because they share a scan doubler (I hesitate to lay out the cash for another one of those).

I've become a Master Detective on Where In The USA Is Carmen San Diego?, having solved some 37 cases. I've also played a ton of Gateway To Apshai on the Atari 130XE and Commodore 64 (DTV Joystick actually) and pondered the ease of porting it to the IIGS, particularly in light of rather complete documentation of how the entire game works.

Thank you to the gentleman who emailed me a couple weeks ago. The dream is alive, and I'll keep these pages up to date.

-Chris

Downgrade

Tue, 08 Apr 2008 20:36:00 -0400

So I finally decided that since I had both motherboards laying around, perhaps it was time to revert to ROM 01, and at least evaluate its merits. I think I'm going to stick with it. I'm not sure that the performance difference from running tools out of ROM, or not loading them from mass storage, is subjectively all that great, and yeah I really did miss the Sales Demo, Shufflepuck Cafe, and Alien Mind. Yes, sound artifacts seem to be increased somewhat, the old familiar cadence of ROM 01 at idle in Finder was frighteningly recognizable from childhood, versus the quieter ROM 03. But that's the biggest difference. Nothing broke. And on a platform where nostalgia clearly matters, I felt it was prudent to aim for maximum compatibility.

To be honest, I tried it the other way, at first. I began stepping through the IIGS Sales Demo and finding out exactly what was breaking on ROM 03. The first hitch was easy enough to see: A BRK crash into E1/00A8, the inline-based GS/OS or ProDOS 16 dispatch vector. But the Sales Demo was written for ProDOS 8. The explanation is that in ROM 03, one of the tool startup calls (I didn't look far enough to see which, I hope it wasn't _QDStartUp) actually makes a GS/OS (or ProDOS 16) stack-based call, thus dispatched via E1/00B0, to open FastFont. E1/00B0 is set up at cold boot, to jump to a ROM-based subroutine that pulls the parameters off of the stack, and allocates new space on the stack to store a dynamically-generated subroutine to make a class-0 (inline) translation of the same OS call (presumably for greater compatibility), and dispatch that via E1/00A8.

Without commenting too deeply on the merits of that decision, I have to say that must have been a tough call for the firmware engineers to make, coupling the ROM tools that closely with the operating system. In the past, I've seen tool calls made from ProDOS 8 very often, and this appears to break them.

But it's an easy fix, right? Change E1/00A8 to something like 5C 00 00 30 6B, to JML to 30/0000, and at 30/0000, add something like:

PLA

CLC

ADC #0006

PHA

SEC

LDA #0046

RTL

Pull the return address off the stack, increment it so the RTL will return to the address after the inline parameters, set carry to indicate error, and set A to $0046 (File Not Found). Fixes everything, right?

Nope. Things do get a few seconds farther, but it only leads up to another crash. But after pondering the number of patches I'd end up doing to make everything run, as well as the nature of ROM changes such as this, I decided to give downgrading a shot.

Oh, and the silly stuff I wrote back in high school that uses $C4xx on the mouse instead of _ReadMouse, magically works again. Ha.

-Chris

February Update

Sat, 23 Feb 2008 20:38:48 -0500

Hello!

Lately I've gone through another one of my phases where the IIGS gets a lot of attention. I started by checking out the new Dora the Explorer Coloring application for the IIGS, and then I was simply blown away by all the goodies on the new Brutal Deluxe website.

After that, I checked out the new Reactive Micro site, and got myself a LittlePower adapter and one of the recommended external ATX PSU's. The externalization of the power supply is always a good thing. I also threw a fan inside the IIGS, thanks to MC Price Breakers. The resulting airflow (and lack of hot noisy internal brick) was enough to make the GS more stable at 12MHz, although 16 is still too hot. Oh well, all TWGS'es (and GS logic boards) are not created equal.

I'm migrating away from using USB/PS2 devices for keyboard and mouse, in favor of an authentic IIGS keyboard and a (super cheap on eBay) ADB Alps Glidepoint. Also picked up a Sirius RAM card, although it has a couple hiccups and will need a bit more TLC before I can make oh-so-important leap from 5MB to 8MB of RAM.

When I'm not playing old Apple II games from The 202 Collection, or coaxing nice IIGS games into installing onto CompactFlash, I'm even working on my game, which is very close to finally hitting Milestone 1, which is to say that I've got a tiled world scrolling while fully digitized music plays through my Oversampler ripoff sound engine. If I ever ship my game, or even show it off at KansasFest, I promise we'll both be surprised.

Anyhow, I just wanted to drop a line and say that work has been hell, but I've still found time to use and enhance my favorite computer of all time, and that we're a lot closer to the day I'll pull back the cover and show you the secret game I've been working on. Till then, what's most important to both you and I, is that this 22 year old computer continues to surprise us.

I've also been collecting a ton of software in anticipation of collecting our old arch-rivals the Commodore 128 and Amiga 1200. These machines have a lot in common with our IIGS, except of course the IIGS's crippling graphics IO bottleneck (and its comparably gorgeous desktop environment).

-Chris

Eureka

Thu, 13 Dec 2007 20:14:27 -0500

I've received all the development tools I needed, plus a copy of the incomparable Spectrum. Recently, I also yanked the Video Overlay and Superdrive cards out of the IIGS on the suspicion that the machine would behave itself better without them. I wasn't wrong. This probably has nothing to do with those cards themselves, but rather the amount of amperage being pulled through the traces of the board and subsequently converted to heat. Interestingly, without those two cards, I have zero stability problems now, which, when combined with the new software (and all the games I've painstakingly and individually tricked into running from the CF card) makes the IIGS a much more appealing computer to use regularly.

So did I get anywhere with the new stuff? Yes.

For the first time ever, I've seen the tiled world of the game I've been working on, scrolling on a IIGS screen in both axes. I'll be working all weekend to combine this with my sound driver into a fun little demo to show off. We're cookin with gas now. I just can't wait to show you what I've been working on all this time.

-Chris

Winter Update

Sat, 01 Dec 2007 04:34:42 -0500

Hardball! (Screen grab not mine)

The IIGS Project did sit idle for a few weeks, no doubt about that, but primarily because I've worked so much. Tonight I got the inspiration to tear the IIGS open and remove a couple cards (VOC and Superdrive), which ironed out a few problems I was having. Now that everything except the ROM 03 incompatible stuff is running, and I'm not having any heat issues, the IIGS is looking welcoming again.

What about your game, Chris?

Yes, that. Well, I'm still waiting on the delivery of some development tools I ordered back in July, honest injun, and I believe they'll be here soon finally. But it isn't all because of that. There's also plenty of work for me to do without that stuff, and it's still getting done. Sorry! Did I mention I hold two full-time jobs? How did you think I managed to afford that eBay IIGS shopping spree?

What I did tonight, was spend a few early morning hours playing all the fun IIGS games and rediscovering, for the umpteenth time this year, the joy of computing. And nothing's going to be me back in the thick of things faster than that, I promise you.

-Chris

Atari 130XE

Thu, 06 Sep 2007 17:03:17 -0400

(Atari 800, my first computer)

(My stylin' 130XE)

I know I have this general rule against collecting even more old computers, but I feel sort of an obligation to make sure I have operational Atari 8-bit hardware. An Atari 800 was my first computer, and in December of 1981 (I would have been 4 and a half, roughly), I began programming it in BASIC. It got an almost-daily workout by me until it was replaced in approximately October 1986, by the Apple IIGS (yeah I know that's an early date to have an Apple IIGS at retail, but it was a dealer demo, a ROM 00 without a Woz signature. But let's leave Apples alone for just one blog entry here).

So in 2003, I'd added an XE Game System to my collection, choosing it for its detachable keyboard. A little while ago, I went to boot it up, and found that its ROM was bad. Now, I'm fully aware that I could fix this problem with the soldering iron I love so much, and a $12 order from Best Electronics, and I probably will someday, but at this point I'd also had enough of the XEGS' enormous footprint for the device + keyboard. I decided to get a 130XE as my new "main" Atari8, because it has that amazing 128K of RAM and FREDDIE memory management chip, and because I think many enthusiasts had also chosen it as the modern jumping-off point. A few clicks on eBay, and a week of waiting, and I had a 130XE in mint condition (the cellophane hasn't even been pulled off label) in its retail box.

I already had an RS232-SIO cable that I had used on the XEGS, but the SIO host back then was a Windows machine running APE, and this time it would have to be the Intel Mac Mini running SIO2OSX. So I also had to order the specific USB-RS232 cable they recommend, because (and I know this from experience attempting to write SIO hosts on the Mac before) the hardware-handshake lines, which are pretty important on SIO, are unreliable on nearly all USB-RS232 cables.

Anyway, after all that, my Atari stuff is working again and I'm pretty happy about that. I have grander plans for it, like installing the 30-in-1 OS ROM switcher, and experimenting with MyIDE and flash carts. But for now, I'm just happy to blast away on some of the first videogames I enjoyed.

When I'm not working on the IIGS game project, of course.

-Chris

Making Moves

Wed, 22 Aug 2007 19:55:10 -0400

Hello, I haven't forgotten about this project in the least. Since last update, I've...

- Sold the RAMFast-D and PC Transporter back to the community via eBay because they weren't going to get used

- Replaced S5,D1 with a 1.4M Superdrive, which makes absolutely no difference

- Passed on several opportunities to replace the TWGS with a Zip GSX, because it would make absolutely no practical difference, other than the much smaller current draw, which isn't enough to convince me yet. The mess stays relatively cool and my power bill isn't outrageous.

- Replaced the RAMFast-D with an Apple High Speed SCSI card, with which I am much more pleased.

And perhaps more importantly, I've...

- Gotten ORCA/C set up and started to adjust to programming the IIGS in a higher-level language (I think I said I was going to do this back in the beginning, it just took me awhile)

- Set up a Generic Tile Engine development environment

- Poured a few more hours of work into making tile maps

- Made image dumps of the CompactFlash partitions and begun more rapid development in emulators (freeing up the actual IIGS for more important stuff like Task Force)

... Also considering putting this old Quantum Fireball to good use by building an experimental GNO HFS development system on it.

Frankly, this part of the project is where it gets boring to you, because I don't have a lot to say until a demo is released, which will be as soon as possible, as long as the 60+ hour work week cooperates. But progress is happening quickly, so who knows...

-Chris

SuperGS Complete

Sat, 04 Aug 2007 10:12:21 -0400

... Or at least mostly so. Whatever modifications I make from here on out, will probably be relatively minor. It took roughly 4 months to acquire and build.

The final allocation of slots:

1. Apple Rev-C SCSI (maybe HS SCSI someday, didn't like RAMFast)

2. Uthernet

3. TransWarp GS / 32K Cache / new GALS / 12MHz

4. MDIDeas Supersonic

5. Apple 3.5" Disk Controller ("Superdrive Card")

6. Apple Video Overlay Card

7. //SHH Systeme Microdrive Turbo, 256M CF card

Memory: Harris Labs GS Sauce, 4MB

The motherboard is still ROM 03 with the prototype ROMs that contain a QuickDraw II bug that is unlikely to bother me. The CDROM drive is an AppleCD 300e, now containing the Golden Orchard CDROM, which is a seemingly-infinite collection of applications, games, information, and even .MODs.

There may be some more minor changes (replace 800K disks with Superdrives, swap some cards around for better circulation, etc), but for the most part, this is it. And I got Toolbox Reference 3 and GS/OS Reference in the mail, so I've got to do some more reading and step into the world of resources. I suspect my game could benefit greatly from a good knowledge of resources. I'm sure I'll dive into it and post something here about the results. Till then.

-Chris

Updates

Thu, 02 Aug 2007 01:03:47 -0400

Sorry, no new code, but as always, some work on the IIGS and NeXT hardware.

The IIGS got a System Saver and a brand new CH Mach III. That's a RAMFast-D with 1MB cache sitting next to the monitor too. The more I mess with it, the less SCSI seems worth the hassle on the IIGS, with the Microdrive Turbo CF setup in place. But I'm not done playing with it yet. Also the System Saver IIGS allows the machine to be stable with the case on at 12MHz, so I think the whole setup looks a bit nicer. Oh and yeah, I might have some Superdrive hardware on the way after all. I've no idea why. But then why do I do any of this...

That's a screen shot from the nearly-revived NeXT Turbo Dimension cube. The monitor's really LCD, the fisheye effect is from the Nikon lens. I'm almost done installing and patching OpenStep 4.2 onto a 4GB 50-pin IBM disk I found today, and then I have to tidy up the setup a bit more, and it'll be done. I'm not sure how often it will be running, but I'm glad it will be able to do something again. These two machines are my only "vintage" computers and they should at least be operational if they're going to be worth more than scrap metal.

Here it is, booted up and awaiting the login...

And here we are all nice and logged in...

And another shot of the Workspace Manager.

I can't imagine there are very many Cubes like this one in operation today. This one has 128M of system RAM and 128M of Dimension RAM (only 64 of which it will actually use), the v74 ROM upgrade, and a Turbo CPU. I have the 90-pound Hitachi CRT that sold with it but I refuse to trot it out and thereby admit that I own a CRT. I also have an ADB soundbox, but never got into NeXT ADB peripherals. This computer was built by me in 1999 from parts dating back to 1991 or so, and for some time in 2000 actually served as a work desktop. Glad to see it alive again.

-Chris

Libsound Beta

Sat, 21 Jul 2007 22:12:43 -0400

Wow wow wow. This is the sound driver I always wanted to write as a kid, but somehow I just couldn't hack it. Today, after a conversation with Lucas, I sat down and wrote it in a roughly 10-hour stretch. I just couldn't believe it, when everything started passing testing.

New Stuff!

This is the same library as before, it will play an infinitely long sound with its Oversampler-ripoff engine. But now it manages and plays one-shot sounds for you, with the following new and exciting C calls:

int loadOneSound( char *path );

Whereas *path is a GS/OS path and not really a c-string again. The int returned, is a libsound Sound ID number that you will use to refer to the sample later in soundPlayShort(). Libsound takes care of allocating RAM for the sample with the Memory Manager handle you gave it during soundInit(), and of course it uses GS/OS to load the sample into that allocated memory.

int soundPlayShort( int soundid, int rate );

soundid is the Sound ID number that loadOneSound() gave you earlier, rate is the Ensoniq DOC playback rate, (32 * sample rate in hz) / 1645. You do not have to worry about DOC RAM position or generator number. Libsound manages a pool of 8 generators and 32K of DOC RAM for you. When asked to play a sound, an unused generator is found, and DOC RAM is allocated with a granularity of $100 (one page). When the sample finishes playing, you don't have to do anything -- the sound MIRQ handler will automatically deallocate the generator and the pages of DOC RAM for you. Hell yes.

Limitations

There are some completely arbitrary limits. They are:

- Only 32 one-shot sounds may be managed. This isn't a design limitation, it is completely arbitrary and can be bumped up (to 64?) if need be.

- Only 8 sound generators are used to play one-shot sounds. This really shouldn't be a problem, as games generally do not play 8 one-shot sounds at a time. But it also is not a design limitation and could easily come up to 16 or more.

Changes

I don't do any error handling anymore. If I get a carry bit set on return from GSOS or the Toolbox, I do my very best to return to you immediately with the error number still in A, and the carry bit set. If a GSOS error occurs during long-sound playback, the file is closed and the DOC voices are halted. I promise I don't dump you to the rolling-apple anymore.

Also, the soundPlayStart function has added more parameters. The prototype is now thus:

int soundPlayStart( char *path, int rate, int oversample, int echodelay );

Whereas oversample = 0 is what you may call 'normal' operation,

oversample = 1 is "2X oversampling", where the sound data is double through interpolation (every other byte is an average of the two around it). In this case, double 'rate' as well.

oversample = 2 is "4X oversampling", which quadruples the size of the sound data, so you should quadruple the playback rate as well.

Oversampling can sometimes add perceived fidelity to the song being played, but you're more likely to just ignore it.

'echodelay' is the delay (in VBL intervals of 1/60th of a sec) between starting playback on L and R channels, to create a faux stereo effect.

These two effects were present in the Oversampler program when I reverse-engineered it and when I refactored it, so I'm putting them in your hands too.

Future Directions

soundPlayShort() will probably get more parameters in the next revision, to allow playback to occur on L, R, or both channels, per sound. There may also be a volume parameter to allow samples to play more softly or loudly.

In Other News

A RAMFast-D and AppleCD 300e are arriving within the next few days (where do I get all these toys!), and I'll be running some tests on the AppleCD 300e with both RAMFast and Apple non-highspeed SCSI cards, to see how well a SCSI CDROM works with the Oversampler engine. If it works well even without a fancy RAMFast, I'm more likely to consider mastering my finished product as an HFS CDROM, as well as .hdv image and/or CF card images.

Click the title for the download link.

-Chris

The Switch

Fri, 13 Jul 2007 18:26:18 -0400

Everything is hosted in ORCA now, and the switch was somewhat pleasant. It took about 4 hours to reformat the source and get used to the new assembler directives and such, but I have a working version of snddemo that launches from the ORCA shell now. This is significant as it clears the way for me to put together my test program that will scroll tiles while playing music. With just a few days left before you-know-what.

-Chris

Turbo Cube Restoration Begins

Thu, 12 Jul 2007 17:29:30 -0400

(Click title for larger picture)

Since the new Apple IIGS building project went so well, I decided to clean up and restore the NeXT cube as well. I did not want to use the 90-pound Hitachi CRT (although I do still have it, sadly enough), but the Samsung Syncmaster 712N LCD supposedly does Sync-on-Green. The Cube has a full 128M of RAM and 128M of NeXTDimension RAM, as well as the Turbo CPU board with the last firmware revision (which allows use of ADB peripherals, although I do not use them, as well as SCSI CDROM booting). The project currently awaits an SVGA-to-13W3 cable and a new root disk (the current one is kaput) in order to be operational. Those should be in place soon. I also have tons more NeXT loot to add to this display, so I'll get more pictures up soon.

-Chris

Another Weekend

Sun, 08 Jul 2007 22:10:02 -0400

(Above: The IIGS corner, which due to square-footage restrictions, is not permitted to exceed this cart. In this case, Disk IIc fits where Apple 5.25" Drive would not.)

Just an update. I've primarily been working on my tiles and maps. I'm really excited about what I have and soon we'll see it on a IIGS (or emulator) near you. I hadn't realized that Generic Tile Engine is presently an ORCA-only affair, which would not be a problem ideally, but since ORCA is still being sold and its only fulfiller is quite a busy man, my options are somewhat limited. But Lucas S is more than helpful and the project will easily make it around this corner.

(Aside, I'm not sure how ethical you think this is, but it passes my test. I'll be very happy to buy ORCA and hope that it gets fulfilled before Christmas, and forward you a copy of the receipt email, if you'll... you know. Just a thought. I only need the assembler. If you're still listening, I also need Spectrum...) I got everything and more, and legally licensed at that. Thanks everyone.

And before I forget, please join me in welcoming Haloscan comments to 65816.com. I'd love to hear all your thoughts on this stuff.

(Above: Super-GS current configuration, with VOC, but PCTransporter yanked. Reactive Heavy Duty Power Supply also installed. Various GALs and crystals laying around. K-rad Megademo disks handy too.)

I spent a lot of time today attempting to stabilize the Super-GS too, mainly because I'd fiddled with crystals so much, I'd broken the fragile legs off of the 25MHz full-can (yes full, so two legs were oddly bent to fit in the half-can socket) oscillator that came with the TWGS when I'd purchased it. This left me with a 55MHz oscillator (for a 13.75MHz system) from my experimental oscillator collection, as a minimum to start from. At 13.75, I managed to get the machine to be stable for 10 entire minutes, which was a new record, but then came the crashes, as always.

I tried pushing the slot sprongers back out, cleaning card edges with eraser, swapping in different GALs, filtered power, a Reactive 200W Heavy Duty Power Supply... all with very little luck. I even tried different chassis/motherboards and ended up getting the same crashes. This says to me then, that my limitations lie with the TWGS card itself. Tomorrow I believe I'll have oscillators for more sane speeds like 8, 10, and 12MHz. Since 13.75 is just barely on the wrong side of stable (I can clear several levels of Wolf3D before it crashes), I think 12 will probably do fine, 10 will be stable if 12 ain't, and 8 will be unnecessarily slow. But I've been wrong about these things before. TWGS experimentation and stabilization is apparently a very slow and personal process for every IIGS nerd, due partly to the tolerances and margins-of-error of equipment that was manufactured 20 years ago. I mean we are talking about freakin antiques here.

In other news, during all this experimentation, I yanked the PC Transporter, again. And realized just how much better the video output looks without that nasty Colorswitch card, again. If it stays yanked for very long, I promise I'll sell it back to the community, because it's one of the more useless cards I have right now.

Am I going to KansasFest? I haven't been to the actual event, seminars and all, since 1993. And this might be the last one. And I actually have some amazing stuff to share. All this is weighing on me towards 'yes', but I have to make the decision this week, so you'll know soon. Everyone else who has played a part in my little year-2007 IIGS adventure will probably be there, so perhaps I should be too. And of course my family is in Kansas City also.

So that's it for now, just another progress report to show you I've been working. And it doesn't even feel like work, because this is among the more gratifying hobbies/money pits I've ever had. The IIGS remains now, as then, a teacher of programatic lessons as well as of the self.

-Chris

Whoops

Sun, 01 Jul 2007 01:32:19 -0400

If you actually tried the Oversampler Sound Driver Demo and the sound skipped on you, it's because DOC registers $A0, $A8, and $B0 should have been initialized to $02 (one shot) instead of $00 (free run). It cost me about 6 hours to track that down. You can patch it yourself or await the next release of stuff here.

Excellent progress with GTE too. I should have something else to share soon.

-Chris

Oversampler Sound Driver Demo

Sun, 24 Jun 2007 22:10:09 -0400

Today, I took advantage of a marvellous rain shower to integrate my basic GS/OS "shell" program that draws a basic menu bar and goes into a TaskMaster event loop, with a sound player that, although recoded by hand, is still a shameless ripoff of Oversampler technology. The end result, though, is to demonstrate a version of this technology that works well and can be integrated into a TaskMaster-style event loop. This fulfills the first milestone of my upcoming product's development. The next milestone involves getting familiar with Lucas' Generic Tile Engine and adding a scrolling tiled map into the mix. At that point, the results will begin to get progressively more exciting, I hope.

The Merlin 16+ Source link, will display the source to the GS/OS program, while the "ShrinkIt Demo Archive" link contains an actual playable music file as well as the built GS/OS program that plays it. It's a little over 900 lines of source, and is probably the nicest thing I've ever done on the GS so far. It works perfectly on Super-GS.

Just something to show you I've been working. :)

-Chris

(Click entry title for links)

Just Another Update...

Wed, 13 Jun 2007 21:46:21 -0400

Haven't gotten a new power supply yet, or finished upgrading one by myself, however I did put the VOC and PC Transporter and SCSI card back into the machine, thus occupying all 7 slots as well as the memory slot (with planning and careful management of card protrusions to prevent shorts, this is possible). With the TransWarp GS at just 7MHz and the new low-power components installed on that board, the machine will run with all 7 cards inserted and the case lid on, indefinitely. Those TWGS upgrades help so much even if you don't swap crystals.

(For the interested, that's 1:Uthernet 2:PCTransporter 3:TransWarpGS 4:MicroDrive Turbo 5:VOC 6:MDIDeas SuperSonic 7:SCSI MM:GS Sauce 4MB. I'll get pictures soon.)

Also, I'd like to tell you that the 8x2 internal joystick pin header shouldn't be used due to logistical inconvenience as well as the idea that a good yank would stress your 20-year-old logic board. But none of those reasons applied to me, I just snipped that pin header off of my Kraft joystick (same model pictured above) when I got tired of trying to argue it through the GS back ports. A few weeks later, I picked up the wreckage, identified the wires in the cord, and put a nice Radio Shack DB9 metal plug on it and screwed it to the back of the GS. It works wonderfully, and my countless games of Task Force and Xenocide are testament to that fact.

Oh, and the Uthernet card is working great. I was able to configure it and use the textmode telnet program that comes with Marinetti. I've yet to more fully explore it, but now that I've got a joystick and a pretty stable system, I've got a million things I wanna try when I get time.

There aren't many hardware improvements and tinkerings left to do at this point, so I promise I'll get back to programming.

-Chris

IIGS on 42" Westinghouse LCD

Sat, 09 Jun 2007 21:34:08 -0400

TWGS Upgrades

Sat, 09 Jun 2007 21:17:03 -0400

I received a mega-order from GSE-Reactive today and immediately put it to use. The TWGS board got a new set of GALs, the 32KB cache board with 1.8S firmware, a new 65816, and various crystals. You might also see that I pulled the VOC for now and put the Uthernet in Slot 1 (with which I have not yet had time to mess).

So far it's very stable at 7MHz, but temperamental even at 13.75MHz, and will crash before it even boots at 18MHz. Changing out the PSU with another (curiously differently-labelled) one seemed to help somewhat. Other factors that are known to help are reseating the oscillator, cold air, and reseating the CPU cable and ZIF socket. Yeah, I know filtered power and a heavy duty power supply will help tons as well, that's on my list.

There are many more variables I can play with. I have a few ROM 01 and ROM 03 boards here, each with its own tolerances and quirks, and one will probably clearly prove itself to be more stable than others. Also note that the board I've been using was never intended to be sold to customers in the first place. So I'm not worried, but it's going to take me a few days to get it up to rip-roaring speed along with everything else.

So give me another GS-messin session or two, and I'll post about my stable IIGS and give my impressions of the Uthernet card too.

-Chris

More Setup Photos

Fri, 01 Jun 2007 21:35:19 -0400

Memory Expansion - Fully-populated Harris Labs GS Sauce

Slot 7 - Microdrive Turbo IDE/CF Adapter, 256M CF Card

Slot 5 - MDIDeas Supersonic

Slot 3 - TransWarp GS

Slot 1 - Video Overlay Card

(Cards spaced a slot apart to try and permit some sort of airflow)

Oversampler Commentary

Mon, 28 May 2007 01:47:14 -0400

Equally as important as writing new code, is reading old code. Sunday, I picked apart the venerable Oversampler, because I'd been considering using its technology in something I'm developing. I don't really want to say what I'm developing yet, but I figured that the remaining GS users have either an emulator or a CF card (or other huge mass-storage), so I could use 5-megabyte sound files instead of MOD/Soundsmith for a background track, to provide a really stunning soundtrack for a year-2007 IIGS product.

Disassembling IIGS OMF-linked files is easier than ever, you just double-click on them in CiderPress. In the space of about 8 hours, I managed to completely understand Oversampler, and I want to share a bit about its technology with you.

You may know that Oversampler loads up to 16KBytes of data from the disk at a time, and if you request, performs "oversampling," or averages the values of every two bytes and inserts the average between them, thus doubling the resolution of a file from say, 23khz to 46khz, for example, for "2x oversampling." It also has a "4x" mode for even greater resolution.

Most of Oversampler is actually desktop interface and windows, so let's dive right into the player code...

; init player

00/03E3: A2 12 0A LDX #0A12

00/03E6: 22 00 00 E1 JSL E10000 WaitCursor()

00/03EA: 20 7E 09 JSR 097E ; init DOC RAM and registers

00/03ED: 20 4E 0A JSR 0A4E ; read from disk and stash to DOC (2x$4000)

00/03F0: 90 08 BCC 03FA {+08} ; skip to player if no problems

00/03F2: A2 04 CA LDX #CA04 ; else set cursor back to error and stop

00/03F5: 22 00 00 E1 JSL E10000 InitCursor()

00/03F9: 60 RTS

Nothing too fancy here, except that I should show you what's done to init the DOC RAM and registers, and load the first chunks from disk.

The routine below is responsible for setting all the registers of the DOC to default values as specified in the table after it, as well as filling up the DOC RAM with a value of $80, or silence. Note the construction of LDA E100CA / AND #0F / ORA #60 / STA E1C03C. If you've programmed the DOC before, you know that this is because the system volume is at E1/00CA, and when we ask the DOC for access to its registers, we must preserve the bits for system volume. 00 is stored in C03E/C03F to indicate the beginning of the DOC's 64K RAM, and then $80 is slammed into C03D 65,535 times. Then, the table at 09C5 in the program code is read, and for each value in the table, a subroutine is called to set the given DOC register to the particular value.

; clear out the DOC RAM to all $80 (baseline)

00/097E: E2 20 SEP #20

00/0980: AF CA 00 E1 LDA E100CA

00/0984: 29 0F AND #0F

00/0986: 09 60 ORA #60

00/0988: 8F 3C C0 E1 STA E1C03C ; select DOC RAM, auto-increment

00/098C: A9 00 LDA #00

00/098E: 8F 3E C0 E1 STA E1C03E

00/0992: 8F 3F C0 E1 STA E1C03F ; zero it out high and low

00/0996: A0 00 LDY #00

00/0999: A9 80 8D LDA #8D80 ; LDA #80

00/099C: 23 0B AND 0B,S ; STA 0B23

00/099E: 8F 3D C0 E1 STA E1C03D ; store data into the doc

00/09A2: C8 INY

00/09A3: D0 F9 BNE 099E {-07}

00/09A5: C2 20 REP #20

00/09A7: A0 00 00 LDY #0000

00/09AA: B9 C5 09 LDA 09C5,Y

00/09AD: C9 FF FF CMP #FFFF

00/09B0: F0 12 BEQ 09C4 {+12}

00/09B2: 29 FF 00 AND #00FF

00/09B5: AA TAX

00/09B6: B9 C5 09 LDA 09C5,Y

00/09B9: EB XBA

00/09BA: 29 FF 00 AND #00FF

00/09BD: 20 3C 09 JSR 093C ; set DOC register

00/09C0: C8 INY

00/09C1: C8 INY

00/09C2: 80 E6 BRA 09AA {-1A}

00/09C4: 60 RTS

; default DOC register settings

00/09C5: 00 00 BRK 00 ; register 00 (freq low0) = 00

00/09C7: 20 08 10 JSR 1008 ; register 20 (freq high0) = 08

00/09CA: 00 30 BRK 30 ; register 10 (freq low16) = 00

00/09CC: 08 PHP ; register 30 (freq high16) = 08

00/09CD: 08 PHP ; register 08 (freq low8) = 00

00/09CE: 00 28 BRK 28 ; register 28 (freq high16) = 08

00/09D0: 08 PHP

00/09D1: 40 RTI ; register 40 (volume 0) = 00

00/09D2: 00 50 BRK 50 ; register 50 (volume 16) = 00

00/09D4: 00 48 BRK 48 ; register 48 (volume 8) = 00

00/09D6: 00 80 BRK 80 ; register 80 (address low0) = 00

00/09D8: 00 88 BRK 88 ; register 88 (address low8) = 00

00/09DA: 00 90 BRK 90 ; register 90 (address low16) = 00

00/09DC: 00 C0 BRK C0 ; register C0 (wavetable info0) = 00

00/09DE: 00 C8 BRK C8 ; register C8 (wavetable info8) = 00

00/09E0: 00 D0 BRK D0 ; register D0 (wavetable info16) = 00

00/09E2: 00 A0 BRK A0 ; register A0 (control 0) = 02 one shot, no int

00/09E4: 02 A8 COP A8 ; register A8 (control 8) = 02 one shot, no int

00/09E6: 02 B0 COP B0 ; register B0 (control 16) = 02 one shot, no int

00/09E8: 02 FF COP FF ; FFFF - end of register defaults

00/09EA: FF

Let me show you that DOC register-setting routine too, while I'm at it. Notice that Ciderpress' disassembler choked a bit after SEP #20, but I was able to fill in. The LDA E1C03C/BMI loop just waits till the DOC isn't busy, and then of course the LDA E100CA / AND #0F / STA E1C03C construction again. Note that we store $0 into the upper part of C03C this time whereas above we stored $6 there. That's because $6 means, access the DOC RAM in auto-increment mode (where each successive write will write to the next address in DOC RAM), whereas $0 means we want access to the DOC's registers.

; subroutine to set a doc register

; a = data

; x = register number

00/093C: E2 20 SEP #20

00/093E: 48 PHA

00/093F: AF 3C C0 E1 LDA E1C03C ; sound control register

00/0943: 30 FA BMI 093F {-06} ; loop till it isn't busy

00/0945: AF CA 00 E1 LDA E100CA ; get system volume

; * disassembler error: should be

; * AND #0F - select DOC registers

; * STA E1C03C

00/094F: 8A TXA

00/0950: 8F 3E C0 E1 STA E1C03E ; doc register number

00/0954: 68 PLA

00/0955: 8F 3D C0 E1 STA E1C03D ; doc register data

00/0959: C2 20 REP #20

00/095B: 60 RTS

; read a doc register

; a = data

; x = register number

00/095C: E2 20 SEP #20

00/095E: AF 3C C0 E1 LDA E1C03C

00/0962: 30 FA BMI 095E {-06} ; wait till sound controller not busy

00/0964: AF CA 00 E1 LDA E100CA

; * disassembler error: should be ; * AND #0F - select DOC registers ; * STA E1C03C

00/096E: 8A TXA

00/096F: 8F 3E C0 E1 STA E1C03E

00/0973: AF 3D C0 E1 LDA E1C03D

00/0977: AF 3D C0 E1 LDA E1C03D

00/097B: C2 20 REP #20

00/097D: 60 RTS

So now that the DOC RAM and registers are initialized, let's continue with the player. Next is a call to a routine at 0A4E, which loads chunks from disk and shoves them into the DOC RAM. As you might imagine, there's a lot of magic here, so let's take a closer look.

; read up to 16 kbytes from disk and stash to DOC, twice

; fills DOC RAM from $0000-$8000 (32k) with or without oversampling

00/0A4E: A9 00 00 LDA #0000

00/0A51: 8D DD 0E STA 0EDD

00/0A54: 8D DF 0E STA 0EDF

00/0A57: 20 3C 0E JSR 0E3C ; seek to file position

00/0A5A: B0 33 BCS 0A8F {+33} ; return if error?

00/0A5C: A6 88 LDX 88

00/0A5E: A4 8A LDY 8A

00/0A60: 8E C3 0E STX 0EC3

00/0A63: 8C C5 0E STY 0EC5 ; give GSOS the pointer to our $4000 bytes

00/0A66: A9 00 40 LDA #4000 ; start with 4000 bytes but scale down if

00/0A69: AE 26 05 LDX 0526 ; oversampling

00/0A6C: F0 04 BEQ 0A72 {+04}

00/0A6E: 4A LSR ; $2000 bytes if 2x, $1000 bytes if 4x, etc

00/0A6F: CA DEX

00/0A70: D0 FC BNE 0A6E {-04}

00/0A72: 8D C7 0E STA 0EC7

00/0A75: 9C C9 0E STZ 0EC9 ; EC7/EC9 contains bytes to read, 4000/2000/1000

00/0A78: 20 4F 0E JSR 0E4F ; do GSOS read

00/0A7B: B0 12 BCS 0A8F {+12} ; return if error

00/0A7D: A2 00 00 LDX #0000

00/0A80: 20 90 0A JSR 0A90 ; stash data to DOC (x=0)

00/0A83: 20 4F 0E JSR 0E4F ; do GSOS read

00/0A86: B0 07 BCS 0A8F {+07} ; return if error

00/0A88: A2 01 00 LDX #0001

00/0A8B: 20 90 0A JSR 0A90 ; stash data to DOC (x=1)

00/0A8E: 18 CLC

00/0A8F: 60 RTS

; this is where we stash data to the DOC

; a, y - trashed

; $88 - pointer to the data

; x=0 - stash data at $0000 in DOC RAM

; x=1 - stash data at $4000 in DOC RAM

00/0A90: E2 20 SEP #20

00/0A92: AF CA 00 E1 LDA E100CA

00/0A96: 29 0F AND #0F

00/0A98: 09 60 ORA #60

00/0A9A: 8F 3C C0 E1 STA E1C03C ; select DOC RAM, auto-increment

00/0A9E: A9 00 LDA #00

00/0AA0: 8F 3E C0 E1 STA E1C03E ; address low word: $0000

00/0AA4: E0 00 00 CPX #0000

00/0AA7: F0 02 BEQ 0AAB {+02} ; if x=0, do low 16K, else set up for high 16K

00/0AA9: A9 40 8F LDA #8F40 ; LDA #40

00/0AAC: 3F C0 E1 A0 AND A0E1C0,X ; STA E1C03F for addr high word

00/0AAF: A0 00 LDY #00 ; LDY #0000

00/0AB1: 00 B7 BRK B7 ; LDA [88],Y - $88 is pointer to the $4000 bytes

00/0AB3: 88 DEY ;

00/0AB4: D0 01 BNE 0AB7 {+01}

00/0AB6: 1A INC ; INC if zero so sound doesn't break

00/0AB7: AE 26 05 LDX 0526

00/0ABA: F0 03 BEQ 0ABF {+03} ; skip oversampling if it's not on?

00/0ABC: 20 D7 0A JSR 0AD7 ; else perform oversampling

00/0ABF: 8F 3D C0 E1 STA E1C03D ; stash data to DOC

00/0AC3: C8 INY

00/0AC4: CC CB 0E CPY 0ECB

00/0AC7: 90 E9 BCC 0AB2 {-17} ; keep looping till y=0ECB

00/0AC9: CC C7 0E CPY 0EC7

00/0ACC: F0 06 BEQ 0AD4 {+06} ; just return if not end of file?

00/0ACE: A9 00 LDA #00

00/0AD0: 8F 3D C0 E1 STA E1C03D ; store final zero for end of sound

00/0AD4: C2 20 REP #20

00/0AD6: 60 RTS

; 2x oversampling

00/0AD7: E0 02 00 CPX #0002

00/0ADA: F0 13 BEQ 0AEF {+13} ; do 4x oversampling if it's on

00/0ADC: 48 PHA

00/0ADD: C2 20 REP #20

00/0ADF: 18 CLC

00/0AE0: 6D 23 0B ADC 0B23

00/0AE3: 4A LSR ; (ByteA + ByteB) / 2

00/0AE4: E2 20 SEP #20

00/0AE6: 8F 3D C0 E1 STA E1C03D ; stash data to DOC

00/0AEA: 68 PLA

00/0AEB: 8D 23 0B STA 0B23

00/0AEE: 60 RTS

; 4x oversampling

00/0AEF: 48 PHA

00/0AF0: C2 20 REP #20

00/0AF2: 18 CLC

00/0AF3: 6D 23 0B ADC 0B23

00/0AF6: 4A LSR

00/0AF7: 8D 21 0B STA 0B21 ; (ByteA + ByteB) / 2

00/0AFA: 18 CLC

00/0AFB: 6D 23 0B ADC 0B23

00/0AFE: 4A LSR ; Point halfway between oversample byte and ByteA

00/0AFF: E2 20 SEP #20

00/0B01: 8F 3D C0 E1 STA E1C03D ; ... to DOC

00/0B05: AD 21 0B LDA 0B21

00/0B08: 8F 3D C0 E1 STA E1C03D ; Byte A to DOC

00/0B0C: 68 PLA

00/0B0D: 8D 23 0B STA 0B23

00/0B10: C2 20 REP #20

00/0B12: 18 CLC

00/0B13: 6D 21 0B ADC 0B21

00/0B16: 4A LSR ; Point halfway between oversample byte and ByteB

00/0B17: E2 20 SEP #20

00/0B19: 8F 3D C0 E1 STA E1C03D ; ... to DOC

00/0B1D: AD 23 0B LDA 0B23 ; and get ByteB ready to slam in there next

00/0B20: 60 RTS

Notice there isn't a lot there that you haven't already seen. We call a subroutine (that isn't listed here) to do the GSOS seek and read into a $4000 (16k) byte buffer that was allocated earlier with _NewHandle. If we're doing 2x oversampling, we tell GSOS to only read $2000 bytes because the sample size will be doubled in DOC RAM. Similarly, only read $1000 bytes for 4x oversampling. Then, the data is written to the DOC, and as we do so, the oversampling calculations are performed, if enabled, and $00 bytes are transformed to $01 bytes to keep the oscillator from halting when they are encountered. The other thing to notice is that it happens twice. Once, DOC RAM is filled from $0000 to $3FFF, and the second time it is filled from $4000 to $7FFF, so now we've got 32K (half) of DOC RAM full of sound data.

And we return to the main player...

; open player window, draw controls

00/03FA: 48 PHA

00/03FB: 48 PHA

00/03FC: F4 00 00 PEA 0000

00/03FF: F4 00 00 PEA 0000

00/0402: F4 00 00 PEA 0000

00/0405: F4 00 00 PEA 0000

00/0408: F4 00 00 PEA 0000

00/040B: F4 77 0B PEA 0B77 ; 0B77 = window redraw callback

00/040E: F4 00 00 PEA 0000

00/0411: F4 00 00 PEA 0000

00/0414: F4 02 00 PEA 0002

00/0417: F4 00 00 PEA 0000

00/041A: F4 F8 0F PEA 0FF8

00/041D: F4 0E 80 PEA 800E

00/0420: A2 0E 61 LDX #610E

00/0423: 22 00 00 E1 JSL E10000 NewWindow2(@T,RC/4,@draw,@def,pDesc,pRef/4,rType):@W

00/0427: 68 PLA

00/0428: 8D 14 05 STA 0514

00/042B: 68 PLA

00/042C: 8D 16 05 STA 0516

00/042F: 20 EB 09 JSR 09EB ; set up keyboard interrupts

Nothing fancy about that, just a call to NewWindow2... except for the last part there. Keyboard interrupts? Yeah, Oversampler uses its own keyboard interrupt handler to tell if you pressed ESC so it can stop playing. That handler is nothing fancy, and it doesn't provide insight on Oversampler technology though, so I'm skipping it. Let's continue...

00/0432: A9 FF FF LDA #FFFF

00/0435: 8D 18 05 STA 0518

00/0438: AD 16 05 LDA 0516

00/043B: 48 PHA

00/043C: AD 14 05 LDA 0514

00/043F: 48 PHA

00/0440: A2 10 10 LDX #1010

00/0443: 22 00 00 E1 JSL E10000 DrawControls(@Wind)

00/0447: A0 00 00 LDY #0000

00/044A: B9 28 05 LDA 0528,Y ; set up DOC registers to default

00/044D: C9 FF FF CMP #FFFF

00/0450: F0 12 BEQ 0464 {+12}

00/0452: 29 FF 00 AND #00FF

00/0455: AA TAX

00/0456: B9 28 05 LDA 0528,Y

00/0459: EB XBA

00/045A: 29 FF 00 AND #00FF

00/045D: 20 3C 09 JSR 093C ; set DOC register

00/0460: C8 INY

00/0461: C8 INY

00/0462: 80 E6 BRA 044A {-1A} ; loop till we're done setting them

; at this point, 0 is stopped, 8 and 16 are playing?

; oscillator 0 - echo-delayed channel if any

; (otherwise it plays same as 16)

; oscillator 8 - quiet, used as timer for irqs

; oscillator 16 - "main" channel

I'm not interested in the call to _DrawControls, but you see there at 44A, we start setting up DOC registers from a table again, and that table is:

; DOC register defaults for player

00/0528: 00 E3 BRK E3 ; 00 (freq0lo) - E3

00/052A: 20 01 10 JSR 1001 ; 20 (freq0hi) - 01 - 483 for freq0?

00/052D: E3 30 SBC 30,S ; 10 (freq16lo) - E3

00/052F: 01 08 ORA (08,X) ; 30 (freq16hi) - 01 - 483 for freq16

00/0531: E3 28 SBC 28,S ; 08 (freq8lo) - E3

00/0533: 01 40 ORA (40,X) ; 28 (freq8hi) - 01 - 483 for freq8

; 40 (volume0) - FF

00/0535: FF 50 FF 48 SBC 48FF50,X ; 50 (volume16) - FF

; 48 (volume8) - 00

00/0539: 00 80 BRK 80 ; 80 (addr0) - 00

00/053B: 00 88 BRK 88 ; 88 (addr8) - 80

00/053D: 80 90 BRA 04CF {-70} ; 90 (addr16) - 00

00/053F: 00 C0 BRK C0 ; C0 (multi0) - 3F (play 32k sound)

00/0541: 3F C8 3E D0 AND D03EC8,X ; C8 (multi8) - 3E (32k sound, different resolution)

00/0545: 3F A0 01 A8 AND A801A0,X ; D0 (multi16) - 3F (play 32k sound)

; A0 (control0) - 01 (free run, halt, no int)

00/0549: 08 PHP ; A8 (control8) - 08 (free run, no halt, int)

00/054A: B0 10 BCS 055C {+10} ; B0 (control16) - 10 (free run, no halt, no int)

00/054C: FF FF A9 FF SBC FFA9FF,X ; FFFF - end of table

Note that the frequency doesn't have to be 483, that is a default that's changed by the slider bars elsewhere. Same for frequency. But the biggest thing is the last three registers changed: Oscillator 1 is set up so that it would run in free-run mode with no interrupts, as soon as the halt bit is taken off. This is because it's the "echo delay" channel and starts after the other two. Oscillator 16 plays the same sound and starts immediately, because its halt bit isn't set. Oscillator 8 had its volume set to 0, because Oversampler uses it as a timer of sorts. Note that interrupts are enabled on it, meaning that when it gets to the end of sound data, it is going to throw a Sound IRQ, which is going to be very important soon. Note also that timer Oscillator 8 is missing a resolution bit, causing it to "play" every other byte and thus throw IRQ in half the time as the other oscillators take to play the sample. This is very helpful for the "refilling" process as you may imagine, so that when the two "live" oscillators are playing sound from the upper part, we can refill the lower, and vice-versa.

00/0464: AE 22 05 LDX 0522 ; echo delay

00/0467: F0 13 BEQ 047C {+13} ; wait a certain number of vblanks

00/0469: E2 20 SEP #20

00/046B: AF 19 C0 00 LDA 00C019 r:RDVBLBAR

00/046F: 10 FA BPL 046B {-06}

00/0471: AF 19 C0 00 LDA 00C019 r:RDVBLBAR

00/0475: 30 FA BMI 0471 {-06} ; wait for vblank(s?)

00/0477: C2 20 REP #20

00/0479: CA DEX

00/047A: D0 ED BNE 0469 {-13}

00/047C: A2 A0 00 LDX #00A0 ; register $A0 - Control 0

00/047F: A9 00 00 LDA #0000 ; value $00 - free run, no interrupt, not halt

00/0482: 20 3C 09 JSR 093C ; set DOC register

; at this point 0 is playing first chunk from disk

; (delayed if applicable)

All we did here was read the value of the echo delay, and wait a few vblanks, then turn Oscillator 1 loose. So at this point, 1 is playing delayed if asked, 16 is playing non-delayed, and 8 is the timer.

00/0485: 9C 1A 05 STZ 051A

00/0488: 9C 8C 05 STZ 058C

00/048B: 9C 8E 05 STZ 058E

00/048E: A9 FF FF LDA #FFFF

00/0491: 8D 1C 05 STA 051C ; init the high/low flipflop variable

; main player loop?

00/0494: AD 8C 05 LDA 058C

00/0497: D0 36 BNE 04CF {+36} ; branch to stop/return if we hit the end

00/0499: AD AB 05 LDA 05AB ; read keypress register

00/049C: C9 1B 00 CMP #001B ; if ESC

00/049F: F0 2E BEQ 04CF {+2E} ; stop player and quit

00/04A1: AD 1C 05 LDA 051C

00/04A4: D0 EE BNE 0494 {-12} ; keep looping till 051C is zero (int on osc 8)

; interrupt happened (generator finished playing)

00/04A6: CE 1C 05 DEC 051C ; set 051C back to FFFF

00/04A9: 20 4F 0E JSR 0E4F ; read chunk from soundfile

00/04AC: B0 21 BCS 04CF {+21} ; stop if error

00/04AE: AE 8E 05 LDX 058E

00/04B1: 20 90 0A JSR 0A90 ; stash data to DOC (high/low $4000 depends on 058e)

00/04B4: AD 8E 05 LDA 058E

00/04B7: 49 01 00 EOR #0001

00/04BA: 8D 8E 05 STA 058E ; flip 058E between 0000 and 0001

00/04BD: AD 1C 05 LDA 051C

00/04C0: D0 D2 BNE 0494 {-2E} ; keep looping if interrupt didn't happen already

; interrupt happened while we were refilling?

00/04C2: EE 1A 05 INC 051A

00/04C5: AD 1A 05 LDA 051A

00/04C8: C9 03 00 CMP #0003 ; got here 3 times? sucks, let's bail

00/04CB: F0 06 BEQ 04D3 {+06} ; stop player, draw alert, and exit

00/04CD: 80 C5 BRA 0494 {-3B}

00/04CF: 20 EF 04 JSR 04EF ; stop player

00/04D2: 60 RTS

Above is the main code of the sound player. A few variables are zeroed out to start. 051A is a counter that keeps track of how many times an interrupt happened while we were refilling the DOC. If that happens 3 times, we throw an alert window (which I imagine says something like "too fast, dude!") and bail out. 058C is a quit flag set elsewhere, and 058E is flipped back and forth between 01 and 00, and is used to provide the x register for the call to refill the DOC RAM (recall that the x register determines whether high or low 16k is refilled in that subroutine). 051C is set by an interrupt handler that was installed by _SetSoundMIRQV when we started up. Let's have a look at that interrupt handler real quick:

; sound MIRQVector that got installed at startup

00/0555: 08 PHP

00/0556: 8B PHB

00/0557: 0B PHD

00/0558: C2 30 REP #30

00/055A: 4B PHK

00/055B: AB PLB

00/055C: AD 9B 00 LDA 009B ; original data bank register

00/055F: 5B TCD

00/0560: A2 E0 00 LDX #00E0 ; register #E0: Oscillator Interrupt Register

00/0563: 20 5C 09 JSR 095C ; read DOC register

00/0566: 89 80 00 BIT #0080 ; is an oscillator generating an interrupt?

00/0569: F0 0B BEQ 0576 {+0B} ; branch if not

00/056B: 29 3E 00 AND #003E ; mask out all bits except osc number

00/056E: C9 10 00 CMP #0010 ; is it oscillator 8?

00/0571: D0 03 BNE 0576 {+03} ; if not, don't zero-out 051C

00/0573: 9C 1C 05 STZ 051C ; zero-out 051C to show that an int happened

00/0576: A2 A0 00 LDX #00A0 ; register #A0: Control Register 0

00/0579: 20 5C 09 JSR 095C ; read DOC register

00/057C: 29 01 00 AND #0001 ; is it halted?

00/057F: F0 06 BEQ 0587 {+06} ; return if not, else halt them all

00/0581: CE 8C 05 DEC 058C ; set 058C to show that we've hit the end

00/0584: 20 2C 09 JSR 092C ; halt all voices

00/0587: 2B PLD

00/0588: AB PLB

00/0589: 28 PLP

00/058A: 18 CLC

00/058B: 6B RTL

So all we do in the interrupt handler is clear the interrupt, and check to see if it was oscillator 8 that threw it. If it was oscillator 8 (the timer oscillator, recall), then we alter 051C, which is used by the player loop to know when the DOC RAM needs refilling from disk.

And there we have it, all the secret sauce contained within Oversampler. Now just think for a moment, what if some silly person decided to fill several disk partitions with sound files to play through this engine, while scrolling a plane of tiled graphics with Generic Tile Engine? We could have something truly interesting, couldn't we? More soon.

-Chris

Manipulating the PCTransporter HDV Image in OSX

Thu, 24 May 2007 21:45:50 -0400

... is pretty easy, considering it's just a raw HD image. First, pull it off your GS with CiderPress, then mount it up on the mac by typing something like this into a Terminal.app prompt:

% sudo hdiutil attach /Users/cshepher/Desktop/freedos-img/c.img

/dev/disk3 FDisk_partition_scheme

/dev/disk3s1 DOS_FAT_12 /Volumes/Untitled

At this point, a new volume called "Untitled" becomes useable on the Mac. I copy over a few test utilities and games (Tunneler? Space Quest? Astrotit?), and then..

% sudo hdiutil detach disk3
"disk3" unmounted.

"disk3" ejected.

At which point you're free to take c.img back down the CiderPress hole and into your GS (don't forget to set filetype to $6F as you do so. I always forget and it always costs me a reboot).

I'm not sure how much more I'll say about the PC Transporter, since a 640Kbyte MS-DOS computer with CGA graphics is primarily useful for making the IIGS look really really good by comparison. My guess is this card's primary use was Lotus123 and Wordperfect. Still an interesting thingy and I may yet find a use for it one day.

In other news, my development environment has made The Switch and is now completely hosted on the IIGS with Merlin 16+, and development has begun on some "My First" sort of desktop programs. Look for my first development notes to appear this weekend when I get down to real hackin.

-Chris

PC Transporter Works

Thu, 24 May 2007 00:28:53 -0400

No problem with the video really, except that sometimes the scan converter has to reset a couple times before getting it right. The Colorswitch card is switching between the output from the PC Transporter and the VOC. The Transwarp GS is not disabled.

I know the suggested bootstrap procedure is to find MSDOS on 720kbyte 3.5" floppies or whatever. Do not waste your time. Use this file provided by the Bochs sourceforge project. It is a raw dump of a 10-megabyte virtual hard disk, with FreeDOS installed. How convenient. After about 2 hours of pondering how I'd trick this all into happening, I ran across this file, transferred it to a ProDOS volume on the CF card with CiderPress, and set its filetype to $6F (HDV). I set the PC Transporter to use it as a C: drive, and everything worked.

Perhaps for the next PC Transporter update, we can cover Scorched Earth and Commander Keen.

-Chris

RGB-SCART Cable Arrives

Wed, 23 May 2007 15:58:20 -0400

Clean image, as you can see!

More Stuff Arrives, And A Few Trials

Fri, 18 May 2007 21:09:47 -0400

My IIGS MicroDrive/Turbo IDE Controller arrived from GSE-Reactive. What an amazing device. I quickly discovered CiderPress and used it to load the card up with all sorts of goodies. Truly amazing, especially when paired with a Transwarp GS.

At first I couldn't figure out why some applications would randomly crash. I would later discover, after nearly going mad, that whenever a card was piggybacked on the CV Tech GS Memory Card, or whenever the card was jumpered to use more than 2MB of RAM, random memory corruption would result in the upper 2MB of RAM on the card. Ugh. For now, I'm working around it by disabling the latter 2MB. For the longer term, I was able to locate a GS Sauce card with 4MB. Super-GS will stay around 5MB of RAM it seems. I was just glad the problem wasn't in any of the more fancy/expensive expansion cards. By the way, Wolf 3D is not only fun, it's the best way to quickly expose any memory problems in the GS.

Also, the PC Transporter card arrived, although I really can't test it (or the Video Overlay Card) yet until I get the RGB-to-SCART cable, let's hope that's shortly. That leaves just one useable slot left, and I'm saving it for the Uthernet card, and finally the guts of the GS will be complete. It's also getting a nice set of speakers soon. I'll photograph the whole mess when it's done.

I also found time to debug my first few hundred lines of GS assembly code to arise from this project. TaskMaster wasn't returning any events because I wasn't initializing the event mask properly. These things get easier to figure out when you can debug a program by randomly inserting BRK's, and only wait 2 seconds for the super-fast emulator to reboot into the development environment.

One more thing before I forget, the Belkin F1D080 speaks a newer ADB mouse protocol than the IIGS does, making mouse control erratic to say the least, so a real ADB mouse has to be plugged into its 'spare' ADB port. The PS/2 keyboard is still useable enough though. I suspect someone could patch the ADB tools on the IIGS to permit compatibility with the newer mouse protocol, but who knows.

This week, I should get the video cable, Transwarp modding accessories, and a couple more manuals. Who knows what kinda stuff I can blow up. Best case scenario, my development environment is all ready to go by this weekend, and I can start showing off some of my work.

-Chris

Super-GS, First Looks

Wed, 16 May 2007 14:02:53 -0400

Here's some IIGS porn for you. So far, my development system has 5MB of expansion RAM, an MDIDeas SuperSonic stereo sound card, a Video Overlay Card, an Apple SCSI controller, and an unmodified Transwarp GS. Yes, it does boot, so far. I heard a rumor that a PC Transporter and CompactFlash adapter card were on the way, and maybe even an Uthernet card. Where will they all fit? Won't the power supply blow up? Stay tuned.

-Chris

Meanwhile...

Tue, 15 May 2007 11:39:18 -0400

Last night was my first time in roughly 15 years, that I stayed up past 3am hacking Apple IIGS assembly code.

I ended up writing most of it in TextMate on the Mac, then exporting it, first by filtering it through tr '\n' '\r' to convert it to the kind of line-breaks that the GS/Merlin likes. Then I used the Perl CPAN ProDOS module to export these files to a fresh ProDOS volume image, which was mounted on KEGS and built with Merlin. It is a few steps, but mostly able to be automated, and easy to master when you get the hang of it. Oh, and if you do this, do not use control-I tabs for spacing, Merlin hates that. Be thankful it will import text files without the high bit set on ASCII characters. You'll have to strip that high-bit back off if you do some debugging/etc and bring the files back into UNIX.

There are ways to optimize this kind of development for sure. For example, I'm sure I could set up netatalk somewhere, do all the editing with Merlin on files that reside on the netatalk share, and use svn on the computer hosting the share. Or perhaps I could pull the files off the GS with Silver Platter and an Uthernet card, and then manage them. Regardless, I still insist on source code management.

Anyhow, as I'd hoped, I'm a lot better at this stuff than I was 15 years ago. I made liberal use of macros, tools, and even a relocatable linker segment, to produce a silly program that loads/starts up all the tools and builds a menu bar. Soon I hope to open an svn repository and start making this code available.

One last note, I know I said I'd use MPW on a Powermac and target the IIGS that way, but all it took was a few minutes of trying MPW (and especially, trying MPW on the PowerMac when accessed via VNC), to dissuade me. The Powermac's reprieve is probably near an end, then. Dumpster Ahoy! I'm probably going to be using IIGS native assemblers, compilers, and linkers (the speed penalty won't be so bad after all because I have a TransWarp GS now).

All my goodies have been shipped. Maybe some of them will arrive today. Details comin. I have to get out of the club house now and go back to the Real World. These Real World people have no sense of humor and they want me to do this "work" stuff.

-Chris

eBay Luck and Other Musings

Sun, 13 May 2007 17:24:10 -0400

On eBay, I scored a TransWarp GS (unmodified at least until I get my hands on it), MDIDeas Supersonic sound card, Video Overlay Card, SCSI card and drive, and another Apple IIGS chassis (which doesn't appear to be in impressive shape, but who knows, it may be useful), for under 300 bucks.

Aside from TransWarp GS hackery, a Highway Electronics SCART-to-VGA scan converter, and possibly a heavy-duty power supply, my hardware-purchasing is finally coming to a close. Which, holy-moly, is a great thing, because I was beginning to wonder how much more I was willing to finance all at once.

Anyhow, back to the waiting game. Hopefully all my parts arrive this week, and the system I've been carefully planning, can come together and be photographed.

-Chris

Parts Begin to Arrive

Fri, 11 May 2007 11:04:12 -0400

Presently, I have three IIGS chassis:

- ROM 03, plain case in grade-A condition (showroom quality), "prototype" ROMs. I couldn't ask for a nicer specimen. I was even able to scrub its little rubber feet clean to the pristine platinum color. For now, this is my favorite. Pictured above. The white labels on the FC and FE ROMs show part numbers 341-0728 and 341-0749.

- ROM 03, Woz case in grade-C condition (a couple chips in the finish, ugh). Was supposed to be my favorite, but I don't like the case's condition. Backup favorite. Interestingly, its FC ROM is also a 341-0728.

- ROM 01, plain case in grade-C condition (yellowed, dirty, no power supply, left over from a brief year-2000 IIGS experiment that I mostly donated to public schools). For parts.

I've also received a 3.5" floppy drive, so I can actually boot up California Games and watch it on the composite output, instead of just doing the diagnostic test on the machines.

The CV Technologies GS Memory card is here and tests just fine, but the funny thing about it is, if you put a card in the piggyback slot, and put the top on the GS, the piggybacked card shorts against the case's RF shield, which fortunately did not cost me a power supply or logic board to discover. But it is amusing. Solutions to the problem include not piggybacking a card (most likely), or insulating the case (less likely).

I'm humbly waiting on the postman to deliver Toolbox Reference, Volumes 1, 2, and 3, as well as the GS/OS Reference, my CF card adapter, and a couple other goodies. I've read nearly every book and all the sample source code I could find, and I'm literally itching to begin development.

If you go to amazon.com and search for "cpu stand," you'll find a few nice CPU stands that will nicely accomodate a vertical IIGS, even with a fairly-close color match.

Although I will be trying a JAMMA CGA to VGA conversion box, I'm also going to try a very highly recommended combination of GS-to-SCART video cable plugged into SCART to VGA scan converter, which supposedly yields a sharp, shake-free image.

Also, depending on how auctions go this week, I may pick up an accelerator and much more. Wish me luck. I want this waiting/building stage to be over, so I can get down to development, but these are 20 year old computers after all, and there may yet be another few weeks of waiting for all the parts to arrive and be assembled.

I've read every book. I've read mounds of source code. I'm so eager to get started on this, that I've written a few pages of source already. Too bad I can't build it yet. But it won't be long now.

-Chris

Video Hardware Experiment

Mon, 07 May 2007 18:15:13 -0400

Per my recent comp.sys.apple2 postings, I will be attempting to use the Wei-Ya ACV-011 "Cherry Master" JAMMA-to-SVGA converter board to get output from the IIGS. It accepts RGB+composite sync, as well as 12VDC, both of which are available from the IIGS, allowing the board to be mounted inside the case. For now, the plan is to cut up a 15-pin Mac monitor cable and run the proper lines into the converter board, and see how the SVGA output looks. More on this when it arrives.

The CV Technologies GS Memory card (halfway populated, I'll do the rest with chips from GSE-Reactive) arrived today, with a fully-populated Apple Memory Expansion card piggybacking on it. Neat.

-Chris

Week One: Assembling the Development Environment

Sun, 06 May 2007 17:30:14 -0400

I've been away from Apple IIGS development since about 1992, I'd say. And even then, I was at a severe disadvantage as these things go. I had a single un-accelerated computer with 1.25 megabytes of RAM and a copy of Merlin 16+ on an 800k floppy disk, and no financial means to attain either mass storage or complete documentation. Under these circumstances then, it is not unforgiveable that my efforts tended towards lame little FTA-wannabe Toolbox-free demonstrations, showing my ability to write about 200 lines of absolute-position Merlin code that did something vaguely interesting by applying techniques more suitable for the IIe.

About two weeks ago, I began reading nearly all of the documentation for the IIGS (and most of that is freely available in PDF format, particularly at the French site in my links list, don't worry, there's a ton of English-language stuff there). It quickly became apparent to me (after a decade of professional software development) that most things could be done in C, and with the help of the Toolbox (and should be), and only the blazinfast speed-sensitive things need be done in assembly, and even those should be position-independent OMF libraries.

There are a fair number of choices of development environments for the IIGS, even today. You can develop on GS hardware, emulated GS hardware, Mac OS 9, or even UNIX. You can use ORCA, APW, MPW, Merlin, LISA816, or even more esoteric 65816 cross-assemblers. After weighing all of these on their merits (and surveying the resources I have available here), I decided to run MPW with the IIgs targetting tools on a PowerMac 6500 running Mac OS 9, for my development computer. Testing would be done on emulated GS hardware as well as actual GS hardware.

Putting this development environment together is somewhat challenging. Fortunately, I've amassed most of the documentation, as well as the PowerMac 6500 running MPW under Mac OS 9. I also have an extensive hard drive image (courtesy of old pals online) that runs great in KEGS. What I don't have, is an Apple IIGS.

Le Machine

I've ordered parts from eBay, and this is what my IIGS system is shaping up to be:

- ROM 03 logic board with "prototype" (341-0728/341-0749) buggy ROMs (I couldn't resist the rarity and I knew I could count on people to burn a set of "proper" ROMs if the bugs ever bit me)

- Woz Limited Edition case (not like that's hard to come by, but it adds flair, no?)

- CV Technologies RAM card with 4MB RAM, and a fully-populated Apple IIGS Memory Expansion Card piggybacked, for a total of 6MB, including the 1 meg on the logic board

- IIgs Turbo IDE Controller and 256M GS/OS formatted CF card from GSE-Reactive

- One 3.5" floppy drive

- NO AppleColor RGB monitor; CRTs are strictly forbidden in my office. Will start with composite signal to Dell 2405FPW composite input; Will eventually upgrade to horizontal scan doubler to get more accurate signal into the 2405FPW's SVGA port

- NO ADB keyboard and mouse; Using Belkin F1D080 ADB to PS/2 adapter, with roll-up plastic USB/PS2 keyboard and Microsoft optical Intellimouse

I'll photograph this setup as parts arrive. As it is, it will already run circles around my original IIGS, and if I can find an accelerator, I'll probably get that as well.

(Fun fact: if you're a digg.com reader, you may recall the recent story about the Apple IIGS That Sold For $668.18. Well guess what, I'm the guy who bid $658.16 and got outbid, thus producing that price. It had a ZipGS, a Video Overlay Card, and even a Second Sight, for cryin out loud)

Things I Don't Have, But Need

I don't have these books, because they're not readily available in PDF:

- IIGS Toolbox Reference Volumes 1-3

- GS/OS Reference

... every other IIGS reference of note, I have in book or PDF form, and probably have mostly read in the past couple of weeks.

My development toolchain is also incomplete, I need licenses and manuals for:

- ORCA/M IIGS

- ORCA/M for MPW

- APDA IIgs assembler/compilers for MPW

(fortunately Syndicomm sells all of this stuff pretty cheap, considering)

So the remainder is only a modest expense, and then we can get on with the actual development. I have a couple strong concept ideas that might actually serve a need within the year-2007 IIGS community, but we'll talk more about them later. First, I'm going to keep reading, playing with the emulators, and waiting for pieces to arrive. Every day I continue to be amazed at what I did not know about this machine. Bystanders are encouraged to contribute source code, game ideas (particularly for games that could run well under the Generic Tile Engine), or anything else for me to study in the next one or two weeks till I come up to full speed on this. I'm already able to write simple GS/OS applications with a toolbar and such, and I'm getting better every day, but every single thing I can read at this point, helps a ton.

-Chris

We Have A Pulse

Fri, 04 May 2007 15:12:14 -0400

Hello, and welcome to 65816.com. We're going to talk a lot about the Apple IIGS, and other matters of tangental interest, such as the Apple II family and retrocomputing. Let's start off by explaining the mission and ground rules for this site.

I want to discuss programming and enhancing the Apple IIGS. That's it. I enjoyed programming it in the 1980s, and two decades later, I lack all budgetary, parental, and time constraints, and that's why I'm doing it now. That's right, now that this kid is all grown up, he's building the train set he always wanted, because he finally can. Okay, there are other reasons in there as well, such as the fact that I don't see how I'll ever turn one nickel of profit from this, thus making it a purely voluntary hobby activity, which is something I can really appreciate after years of contract programming for hire.

This place isn't here to be a resource, but many of the sites in the "Further Reading" sidebar are. Here, it's just going to be pictures, musing, articles, source code... you get the picture. Maybe this site will be a footnote, maybe it will be something exciting. My aim isn't to sell ads or to be popular, I'm just trying to liven up the party a bit.

-Chris