Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
QIX for ProDOS
145 views
Skip to first unread message
Steve Nickolas
Oct 24, 2012, 2:42:22 PM10/24/12
to
http://1.buric.co/qix8.zip
This version, BTW, does not have a garbled title screen. It also has the
FUN TIME ARCADE splash screen (though not the Alien Technology ones, nor
the Taito logo on the first splash).
It is a little less tested than the DOS 3.3 version. All the code I used
is in there, it's messy as hell but it's there.
1. It needs 4 files: QIX.SYSTEM, QIXOVL1, QIXOVL2 and QIXOVL3.
2. Because the code goes up to $B09A, it cannot be run from BASIC.SYSTEM.
If you try, you'll get NO BUFFERS AVAILABLE. (This can prolly be
worked around, but it would require another file.)
-uso.
This version, BTW, does not have a garbled title screen. It also has the
FUN TIME ARCADE splash screen (though not the Alien Technology ones, nor
the Taito logo on the first splash).
It is a little less tested than the DOS 3.3 version. All the code I used
is in there, it's messy as hell but it's there.
1. It needs 4 files: QIX.SYSTEM, QIXOVL1, QIXOVL2 and QIXOVL3.
2. Because the code goes up to $B09A, it cannot be run from BASIC.SYSTEM.
If you try, you'll get NO BUFFERS AVAILABLE. (This can prolly be
worked around, but it would require another file.)
-uso.
BLuRry
Oct 24, 2012, 3:30:29 PM10/24/12
to
Awesome! Thanks!
Steve Nickolas
Oct 24, 2012, 4:15:09 PM10/24/12
to
On Wed, 24 Oct 2012, BLuRry wrote:
> Awesome! Thanks!
*^^*
I wish I knew why it borks in the other file crack, though.
Here's a breakdown:
DOS 3.3 version:
QIXLC - Main LC RAM, Aux LC RAM
QIXGO - Main RAM, 0000-03FF, 0800-1FFF, 4000-AFFF
ProDOS version:
QIX.SYSTEM - "Fun Time Arcade" splash
Main RAM, 0000-00FF, 0180-03FF, 0800-0FFF
Aux LC RAM
QIXOVL1 - Main LC RAM
QIXOVL2 - Main RAM, 7000-AFFF
QIXOVL3 - Main RAM, 1000-1FFF, 4000-6FFF
(That's right, the DOS version copies 128 bytes MORE than the ProDOS
version!)
B000-BFFF memory is copied from 5000-5FFF in both cases.
-uso.
> Awesome! Thanks!
*^^*
I wish I knew why it borks in the other file crack, though.
Here's a breakdown:
DOS 3.3 version:
QIXLC - Main LC RAM, Aux LC RAM
QIXGO - Main RAM, 0000-03FF, 0800-1FFF, 4000-AFFF
ProDOS version:
QIX.SYSTEM - "Fun Time Arcade" splash
Main RAM, 0000-00FF, 0180-03FF, 0800-0FFF
Aux LC RAM
QIXOVL1 - Main LC RAM
QIXOVL2 - Main RAM, 7000-AFFF
QIXOVL3 - Main RAM, 1000-1FFF, 4000-6FFF
(That's right, the DOS version copies 128 bytes MORE than the ProDOS
version!)
B000-BFFF memory is copied from 5000-5FFF in both cases.
-uso.
Steve Nickolas
Oct 24, 2012, 4:59:32 PM10/24/12
to
Followup:
There is a file on http://1.buric.co/qixbas.dsk.gz called QIXBAS.
If you don't need it, don't use it, and just use QIX8.DSK.
It is not a plain BASIC program. The BASIC side checks to make sure all
the necessary files are there so it can error out before trampling
BASIC.SYSTEM, and works around the issue that BASIC.SYSTEM leaves the
PREFIX blank (which other SYS programs can have a problem with). Once
everything is validated, it runs the second part, which frees BASIC's
memory and then loads QIX.SYSTEM. You'll need this if you're using a
BASIC menu system to launch Qix.
-uso.
There is a file on http://1.buric.co/qixbas.dsk.gz called QIXBAS.
If you don't need it, don't use it, and just use QIX8.DSK.
It is not a plain BASIC program. The BASIC side checks to make sure all
the necessary files are there so it can error out before trampling
BASIC.SYSTEM, and works around the issue that BASIC.SYSTEM leaves the
PREFIX blank (which other SYS programs can have a problem with). Once
everything is validated, it runs the second part, which frees BASIC's
memory and then loads QIX.SYSTEM. You'll need this if you're using a
BASIC menu system to launch Qix.
-uso.
Steve Nickolas
Oct 24, 2012, 5:04:53 PM10/24/12
to
Replying to myself.
If for some reason you're using a loader that can't handle a SYS file that
big,
]LOAD QIXBAS
]BSAVE QIX.LAUNCH,A2560,L224
-uso.
big,
]LOAD QIXBAS
]BSAVE QIX.LAUNCH,A2560,L224
-uso.
BLuRry
Oct 24, 2012, 5:48:22 PM10/24/12
to
-B
Steve Nickolas
Oct 24, 2012, 6:09:38 PM10/24/12
to
On Wed, 24 Oct 2012, BLuRry wrote:
> For what it's worth, I was able to start it from Desktop II and Super
> Selector just fine. Great work!
*^^*
> For what it's worth, I was able to start it from Desktop II and Super
> Selector just fine. Great work!
The only reason I was able to pull it off is it's single-load.
BTW... I think it might fail on a //c... but then some stuff weirds out on
that slightly bizarre firmware. I've run into a handful of weird issues
with this program or that because of the //c firmware.
I'm open to cracking more complicated stuff but finding disk access
functions is a lot harder for me. So it might be necessary to have
someone else find the code instead, which I can patch.
I thought of another game I'd like to try to hack - Pick-A-Dilly Pair.
Again, I can't do much until I can replace the disk access code.
-uso.
Steve Nickolas
Oct 29, 2012, 11:46:58 PM10/29/12
to
THREAD NECROMANCY !!!!!
I just noticed an interesting side-effect of file-cracking QIX... it
boots in 1/3 the time >:P. (sloppy timing in Authentic mode in AppleWin:
53 seconds for the original, 17 seconds for my version).
-uso.
I just noticed an interesting side-effect of file-cracking QIX... it
boots in 1/3 the time >:P. (sloppy timing in Authentic mode in AppleWin:
53 seconds for the original, 17 seconds for my version).
-uso.
BLuRry
Oct 30, 2012, 12:26:42 AM10/30/12
to
-B
Steve Nickolas
Oct 30, 2012, 12:43:11 AM10/30/12
to
I just can't seem to top that crack, and I'd really like to make a
*collection* of these games, not just a *couple* of 'em. Naturally it's a
lot harder than Apple Crunch.
-uso.
BLuRry
Oct 30, 2012, 1:59:25 PM10/30/12
to
The best part is that you don't have to reverse engineer anything, and thanks to Jac's work on Wudsn, you could use an IDE to manage the code and build everything.
-B
Steve Nickolas
Oct 30, 2012, 2:36:47 PM10/30/12
to
On Tue, 30 Oct 2012, BLuRry wrote:
> A monster crack would be to recompile PoP to run off of Prodos using the
> filesystem instead of the 18-sector format. It would probably be next
> to impossible though, but man it would rock. Extra points: Restore
> Mechner's original editor. The source is bundled (in fact, intertwined)
> with PoP's source.
>
> The best part is that you don't have to reverse engineer anything, and
> thanks to Jac's work on Wudsn, you could use an IDE to manage the code
> and build everything.
I'm not sure there's enough RAM for that. (I'd have to make sure there's
> A monster crack would be to recompile PoP to run off of Prodos using the
> filesystem instead of the 18-sector format. It would probably be next
> to impossible though, but man it would rock. Extra points: Restore
> Mechner's original editor. The source is bundled (in fact, intertwined)
> with PoP's source.
>
> The best part is that you don't have to reverse engineer anything, and
> thanks to Jac's work on Wudsn, you could use an IDE to manage the code
> and build everything.
at least no use of the C083 language card memory in MAIN RAM, nor the BF
page in MAIN RAM.)
In addition, I think he used Merlin and all my work is in CA65.
Converting the ASM syntax to something I can use would be holy hell.
(Still, if Mr. Sid could make a 64K version, it's prolly not totally
impossible...)
Would be nice though...
-uso.
BLuRry
Oct 30, 2012, 4:47:01 PM10/30/12
to
The source is very nicely segmented and since all the original source is intact, segments can be moved around. Additionally, it should be doable to load in animations and tile sets as needed. I believe that the original loads a bunch of sets in memory that are used for each level -- but it is possible to load a smaller subset I think.
I am slightly more concerned about the use of the aux zeropage and stack -- aren't those off-limits for Prodos apps?
-B
Steve Nickolas
Oct 30, 2012, 5:43:12 PM10/30/12
to
On Tue, 30 Oct 2012, BLuRry wrote:
> This is totally not in keeping with your original topic but I think it's
> possible.
Renamed the thread accordingly.
> This is totally not in keeping with your original topic but I think it's
> possible.
> The source is very nicely segmented and since all the original source is
> intact, segments can be moved around. Additionally, it should be doable
> to load in animations and tile sets as needed. I believe that the
> original loads a bunch of sets in memory that are used for each level --
> but it is possible to load a smaller subset I think.
That might ease up the pressure a little bit.
I wonder if it would be worth it to make separate GS graphics (prolly from
EGA for the main game, at least) ?
> I am slightly more concerned about the use of the aux zeropage and stack
> -- aren't those off-limits for Prodos apps?
drivers though?
-uso.
Steve Nickolas
Oct 30, 2012, 7:23:47 PM10/30/12
to
Another reply on the same topic as before.
On Tue, 30 Oct 2012, BLuRry wrote:
>
> The source is very nicely segmented and since all the original source is
> intact, segments can be moved around. Additionally, it should be doable to
> load in animations and tile sets as needed. I believe that the original
> loads a bunch of sets in memory that are used for each level -- but it is
> possible to load a smaller subset I think.
I don't believe I can do much here beyond writing the initial loader, but
if anyone else is willing to do this or that, I'm willing to organize it
together and host a website for it.
-uso.
On Tue, 30 Oct 2012, BLuRry wrote:
>
> The source is very nicely segmented and since all the original source is
> intact, segments can be moved around. Additionally, it should be doable to
> load in animations and tile sets as needed. I believe that the original
> loads a bunch of sets in memory that are used for each level -- but it is
> possible to load a smaller subset I think.
if anyone else is willing to do this or that, I'm willing to organize it
together and host a website for it.
-uso.
Steve Nickolas
Oct 30, 2012, 7:36:37 PM10/30/12
to
Aaaaaaaaaaaand replying to myself again because I had a slight
brainstroke. If we can squeeze out the RAM, how about the Mockingboard,
if detected?
Nicodim did a good port of the game to the ZX Spectrum - the sound from
his port could potentially be used, as it sounds a bit better than the //e
buzzing.
http://www.youtube.com/watch?v=n5ApyNW6q5I
-uso.
brainstroke. If we can squeeze out the RAM, how about the Mockingboard,
if detected?
Nicodim did a good port of the game to the ZX Spectrum - the sound from
his port could potentially be used, as it sounds a bit better than the //e
buzzing.
http://www.youtube.com/watch?v=n5ApyNW6q5I
-uso.
BLuRry
Oct 31, 2012, 12:58:37 AM10/31/12
to
It would be a big effort to rip up the graphics rendering though -- thinking of such a thing makes me wish I had the coding ability of Burger B. Heineman. Best bet is to target the PC VGA version for graphics. Mechner was quoted saying that felt like the most definitive version of the game.
-B
Steve Nickolas
Oct 31, 2012, 1:28:30 AM10/31/12
to
On Tue, 30 Oct 2012, BLuRry wrote:
> Mockingboard detection is possible. Actually, converting the sound
> engine to 100% mockingboard would free up a lot of CPU. Anyway, for
> music I would just use a lookup table and convert the legacy music data
> as-is. It would only yield two-voice music, but wouldn't require as
> much code surgery.
Well, the intro could be a completely separate module, too.
> engine to 100% mockingboard would free up a lot of CPU. Anyway, for
> music I would just use a lookup table and convert the legacy music data
> as-is. It would only yield two-voice music, but wouldn't require as
> much code surgery.
I was thinking of targetting (for a 5.25" edition) two flippies thus:
1A = Startup (including title screen, hardware detection)
1B = Editor
2A = Game (First Half)
2B = Game (Second Half)
Both sides of disk 1 would be bootable.
I don't know how to pull much of this off - I'd hope I could gather up a
few fans with 65C02 talent! - I do want to do this and would contribute in
any way possible toward it.
I wonder what Mechner'd think. :P
-uso.
BLuRry
Oct 31, 2012, 1:54:41 AM10/31/12
to
-B
Steve Nickolas
Oct 31, 2012, 3:09:55 AM10/31/12
to
I wrote a little system detection code and had done with it for now...
It looks like the first guts are in MASTER.S
Already I have a potential problem because MASTER sits in the top 2K of
memory, which is part of the ProDOS kernel (F880+).
What I'd like to do first is to get just the attract loop running, with
the Arabian-sounding music and everything. While this part is loading I
would display a credit screen.
Probably if interrupted, I would then load the next phase...
...man, I'm in up to my neck.
-uso.
It looks like the first guts are in MASTER.S
Already I have a potential problem because MASTER sits in the top 2K of
memory, which is part of the ProDOS kernel (F880+).
What I'd like to do first is to get just the attract loop running, with
the Arabian-sounding music and everything. While this part is loading I
would display a credit screen.
Probably if interrupted, I would then load the next phase...
...man, I'm in up to my neck.
-uso.
BLuRry
Oct 31, 2012, 12:50:44 PM10/31/12
to
http://jordanmechner.com/wp-content/uploads/1989/10/popsource009.pdf
-B
Steve Nickolas
Oct 31, 2012, 1:17:11 PM10/31/12
to
On Wed, 31 Oct 2012, BLuRry wrote:
> Don't go too much further without looking at Mechner's notes. He lays
> out memory map usage pretty clearly. This can be extremely useful in
> mapping out loader behavior.
>
> http://jordanmechner.com/wp-content/uploads/1989/10/popsource009.pdf
>
> -B
>
Downloaded it back in April.
> Don't go too much further without looking at Mechner's notes. He lays
> out memory map usage pretty clearly. This can be extremely useful in
> mapping out loader behavior.
>
> http://jordanmechner.com/wp-content/uploads/1989/10/popsource009.pdf
>
> -B
>
I'm aware of some of the technical stuff.
The table says there's 48K of code and 8K of buffers. That might be a
problem, given that both the graphics pages are used ("Screen memory
16K").
-uso.
BLuRry
Oct 31, 2012, 3:04:51 PM10/31/12
to
To be honest, shoving lookup data into a slinky ram card is getting more and more temping as I think about it. ;-)
-B
Steve Nickolas
Oct 31, 2012, 5:16:25 PM10/31/12
to
to save swapping. Then in a pinch, the disk.
Since I don't care to support the buggy pre-enhanced //e, it is possible
to go further and use 65C02 opcodes (except the Rockwell ones since stock
chips Apple used didn't have them, nor the 65816). I don't know how much
that would help. (PoP is supposed to work even on the original //e, so
long as it could do DHGR for the attract screen.)
My BLOADer uses about 1.5K buffer but this might reduce down to 1K if done
right? I think PoP has to spool the whole track. It might be possible to
reduce the use of buffers to 1K+whatever ProDOS uses.
-uso.
Steve Nickolas
Oct 31, 2012, 8:49:31 PM10/31/12
to
Recall from earlier in the thread because I have more info.
On Tue, 30 Oct 2012, BLuRry wrote:
>
> I am slightly more concerned about the use of the aux zeropage and stack --
> aren't those off-limits for Prodos apps?
http://mirrors.apple2.org.za/apple.cabi.net/FAQs.and.INFO/A2.TECH.NOTES.ETC/A2.CLASSIC.TNTS/p8026.htm
--quote--
The area from $D100 through $DFFF in bank 2 of the auxiliary language
card is for the use of third-party RAM-based drivers, to be discussed in a
future ProDOS 8 Technical Note. At least one version of Apple II SANE is
configured to load at $E000 in the auxiliary language card, which is
perfectly acceptable since SANE is part of the system software (it just
doesn't ship with the system).
--endquote--
--quote--
The Rule of Auxiliary Memory: If /RAM is enabled, all
auxiliary memory above location $800 may be used by an application
after first removing /RAM as discussed in the ProDOS 8 Technical
Reference Manual. /RAM should be reinstalled upon completion.
If /RAM is not enabled, then auxiliary memory above $800 may be
used at the application programmer's discretion, but the areas
marked as reserved must be respected.
--endquote--
Since we don't intend to have a "quit to ProDOS" option, it's prolly safe
to keep /RAM disconnected and we can prolly step on the Selector when
we're bootstrapped?
Another source suggested that it might be possible to eat the stack, but
$0100 and $0101 need to hold the SP or something.
-uso.
On Tue, 30 Oct 2012, BLuRry wrote:
>
> I am slightly more concerned about the use of the aux zeropage and stack --
> aren't those off-limits for Prodos apps?
--quote--
The area from $D100 through $DFFF in bank 2 of the auxiliary language
card is for the use of third-party RAM-based drivers, to be discussed in a
future ProDOS 8 Technical Note. At least one version of Apple II SANE is
configured to load at $E000 in the auxiliary language card, which is
perfectly acceptable since SANE is part of the system software (it just
doesn't ship with the system).
--endquote--
--quote--
The Rule of Auxiliary Memory: If /RAM is enabled, all
auxiliary memory above location $800 may be used by an application
after first removing /RAM as discussed in the ProDOS 8 Technical
Reference Manual. /RAM should be reinstalled upon completion.
If /RAM is not enabled, then auxiliary memory above $800 may be
used at the application programmer's discretion, but the areas
marked as reserved must be respected.
--endquote--
Since we don't intend to have a "quit to ProDOS" option, it's prolly safe
to keep /RAM disconnected and we can prolly step on the Selector when
we're bootstrapped?
Another source suggested that it might be possible to eat the stack, but
$0100 and $0101 need to hold the SP or something.
-uso.
0 new messages