Rating: | |
Category: | |
Perspective: | |
Year released: | |
Author: |
Patrick Buckland |
Publisher: |
Casady & Greene MacSoft |
Engine: |
Side-scroller; fly a spaceship on bombing raids over enemy territory, dodging and/or shooting enemy ships and collecting power-ups; land (carefully) on your own turf; repeat. Graphics and sound quite good, but silly. The most fun, when you can manage it, is cruising along with auto-strafe and invincibility.
Awards: MacWorld Game Hall of Fame, 5 Mice MacUser Magazine.
Archive is of version 1.1.9M, published in 1994-1995 by MacSoft.
CompatibilityMinimum requirements: System 6.0.2, b/w or 256 color, Mac OS 7 compatible, later OS versions not recommended.
Comments
wow! This was my childhood game on mac LC
I would like to emulate this in colour on macOS 10.13.6 (Hackintosh), 6700K + GTX 980 + 16GB RAM.
Any thoughts on the emulator/OS to use for best overall performance???
Video of this game:
https://youtu.be/YEeR4_QbnaQ
This game works perfectly in Basilisk II... if you open Crystal Quest or Crystal Crazy (from the same developer) first.
Other software may also cause it to work, but it's crashed on everything else I tried, whereas running it after the above two games makes it run perfectly every single time.
Now I know this works on 9.0.4 on SheepShaver, I am keen to try this on my G3 iBook.
Nearly impossible to play in a window under emulation, but should work great on real hardware!
Are you sure?
(Mac OS 8.5 and newer would require SheepShaver as base)
Got it working on sys 8.6 on basilisk. Good memories!
Many, many thanks for uploading this game! I misspent my college days playing Armor Alley and Sky Shadow and seeing it brought back memories.
Thanks for testing, I've added the SheepShaver to the Emulation panel now.
A fast test of mine confirms the SheepShaver compatibility.
For me, this game runs well in Mini vMac and Bas, with some graphic glitches in the intro screen.
Oddly enough, for me Sky Shadow crashes Basilisk (a prompt to Restart appears) but works on SheepShaver in OS 9.0 just fine.
OK, Thanks!
Here is my solution:
Now, I just dragged the cdr image onto Toast (version 9 at my end) and saved it as .cdr image again.
From that on, it mounts and plays fine within Mini vMac / System 6.
IIGS_User, I appreciate your offer, and by all means do whatever you want on your own hard drive, but please leave this archive as it is. I've now tested with Mini vMac on OS9, OS X PPC, and Windows, and I have not been able to replicate your error. In each case I unzipped the archive, dragged and dropped the Toast image onto Mini vMac 3.1.3 running System 6, and nothing went wrong. I have also downloaded the file several times and tested the md5 checksum and it came out fine every time.
That's completely true, a disk image can't be mounted at host operating system plus the emulated one at the same time.
It is a bit strange that Mini vMac System 6 (not 7) complains about a locked disk even if the .cdr file isn't write-protected, as in host OS.
It seems to be very important to not contaminate classic Mac OS disk images with the .ds_store informations created by Mac OS X. Additionally, the Mac OS X system mix the file/folder structure a bit, by creating some obscure "_MACOS" folders onto the disk, which will confuse Mac OS 6 to 9 users.
Is it OK if i try to create a new .cdr image at my place, readable with System 6?
The Madness Of Roland upload, I've initialized the .cdr image in Mini vMac first, before copying the stuff onto it again.
"It is probably a compressed one?"
Now you've lost me. Just download the .zip file, make sure the Toast image doesn't mount when you unzip it, and drag-and-drop it with Mini vMac. Whenever you test these archives you need to test a fresh, pristine copy that hasn't been molested by other operating systems or emulators. And keep the zip file somewhere safe on your drive.
BTW thanks for that Madness of Roland upload, IIGS_User. It works very well with Mini vMac and I had no idea that game worked in B/W!
Probably it was mounted on a later version of Mac OS first, either Mac OS 7.5 (in Basilisk) or Mac OS 9 (in SheepShaver). I notized the extra space differences between Disk Copy 6.3 and Toast, too, and I think I'll stick to Disk Copy 6.3 (not Hard Disk Utility of Mac OS X, though) to create disk images for Mac Garden in the future.
Except original CD medias, my .cdr uploads so far are direct images created by Toast (except Madness Of Roland which I've prepared to be mountable within Mini vMac).
Now, if a CD game is also playable my a System emulated by Mini vMac, I'll create a Disk Copy 6.3 HFS Standard image first bevore converting to Toast image.
All my previous uploads are disk imaged, though, some .cdr.sit or cdr.zip files, too.
P.S.:
I tried the Cmd-Option trick, it asks me whether I want to re-recreate the desktop file as expected, but still complains about unlocking the disk first.
It is probably a compressed one?
The uploaded disk image opens without problems in Mini vMac v3.1.3 for Mac OS 9, both with System 6 and 7.
Mini vMac (said version at least) does not respect locked images, and insists on being able to write to them; there needs to be some extra unused space on the image or the System will ask to eject or initialize. Tools such as Disk Copy 6.3 can be used to make images with extra space, and Toast can then convert to its format.
If one uses Toast's "Data" option to make an image, it will likely not have extra writing space on it; the "Disc Image" tab is the one to use for conversion.
IIGS_User, is it possible your image was mounted on a later version of the Mac OS before you tried it with Mini vMac? OS X by default will open Toast images after decompression and something conflicting with System 6 may have been saved on the image. Otherwise, there may be a difference with the version of Mini vMac.
Note: The Toast image was locked when archived with MacZip; this attribute usually disappears when opened with other decompression tools.
Before that, I noticed Mini vMac even needs to initialize a CD ROM image at all before mounting the very first time.
Thanks, I will try the suggestions now...
You could force-rebuild the Desktop file by holding Cmd-Option while the disk is mounting. Of course it would have to be in read-write mode (rather than read-only). That Cmd-Option trick works for any disk of any kind when mounting - the OS will try to rebuild the Desktop file if you hold those keys while the volume mounts.
There may be no "Desktop" file on the Toast disc image. In System 6, this was used to store details of window sizes, positions, application icons, etc. System 6 needs this to work, it's probably trying to build this (known as rebuilding the Desktop) when you mount it. If the disk image is locked, or a read-only disk image it's going to have issues.
Mac OS 7 used the "Desktop DB" and "Desktop DF" files to store the same information (used all the way up to OS9). These are probably present. Note that if you successfully create a System 6 "Desktop" file, then come back to Mac OS 7, it'll automatically rebuild the desktop (in Mac OS 7) when you mount it. Mac OS 7 did this if the "Desktop" file was more up-to-date than the Mac OS 7 "Desktop DF".
I'm sure that you knew all this already, so the issue must be that System 6 sees the Toast image as read-only / locked.
Edit: Changed 'xxx 7' to 'Mac OS 7' - IIGS User
In Mini vMac booted with Mac OS 6, this .toast image tells me, "Please unlock the disk 'Sky Shadow' and try again. The desktop file couldn't be created".
Mac OS 7 mounts fine.
Could anyone please check, too?
Edit: Changed 'xxx 7' to 'Mac OS 7' - IIGS User
I get a 404 on this one. I hope it's a simple error