| Re: new ProDOS ports [message #298238 is a reply to message #298236] |
Fri, 21 August 2015 02:59   |
qkumba
Messages: 1584
Registered: March 2013
Karma: 0
|
Senior Member |
|
|
> I presumed that it was *reading* from device space initially, not writing.
>
> Of course, reading can change device state, too, but it's hard to see how
> to do a slot scan without reading!
It's STA $C082, Y.
Then incrementing Y by 16 for each of 7 more iterations.
|
|
|
|
| Re: new ProDOS ports [message #298241 is a reply to message #298229] |
Fri, 21 August 2015 03:38 |
mverpelli
Messages: 289
Registered: May 2013
Karma: 0
|
Senior Member |
|
|
On Friday, August 21, 2015 at 4:06:33 AM UTC+2, sicklittlemonkey wrote:
> On Friday, 21 August 2015 13:21:35 UTC+12, Don Bruder wrote:
>> So it's presumptuous to assume that a device exists, since, unless it
>> did, there would be no way (at the time the game was "current", anyway)
>> to have the code that was making the assumption in RAM to begin with?
>
> But it's writing to slots it didn't load from and hasn't checked the device ID's of.
>
> Cheers,
> Nick.
Nick: do you remember the Sky Travel post? That program fiddle with a specific GS softswitch without checking. Who is without sin...
Marco
|
|
|
|
| Re: new ProDOS ports [message #298349 is a reply to message #298241] |
Sat, 22 August 2015 04:14 |
sicklittlemonkey
Messages: 570
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Friday, 21 August 2015 19:38:44 UTC+12, mver...@libero.it wrote:
> Nick: do you remember the Sky Travel post? That program fiddle with a specific GS softswitch without checking. Who is without sin...
Yeah, but at least that was a motherboard softswitch defined on the IIgs and mapped to the speaker in earlier models. Safe compared to unknown slot I/O registers.
Cheers,
Nick.
|
|
|
|
|
|
| Re: new ProDOS ports [message #303976 is a reply to message #298388] |
Mon, 02 November 2015 16:12 |
qkumba
Messages: 1584
Registered: March 2013
Karma: 0
|
Senior Member |
|
|
|
Bolo - single file, with title screen, is now available for the first time, and awaiting approval in Asimov /incoming. I always loved that game.
|
|
|
|
| Re: new ProDOS ports [message #303990 is a reply to message #303976] |
Mon, 02 November 2015 20:17 |
sicklittlemonkey
Messages: 570
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Tuesday, 3 November 2015 10:12:36 UTC+13, qkumba wrote:
> Bolo - single file, with title screen, is now available for the first time, and awaiting approval in Asimov /incoming. I always loved that game.
Cool! Yes, a lovely game that you don't often hear in top X lists.
Great controls, a maze game, a scanner, nice scrolling, that nice animation when your shots hit something, and what a friend and I used to call "toe-nail" collision detection. ; - ) (Probably EOR.)
I also like how auto-repeating the fire key is suicidal.
Cheers,
Nick.
|
|
|
|
|
|
| Re: new ProDOS ports [message #305134 is a reply to message #305124] |
Wed, 18 November 2015 15:04 |
Steve Nickolas
Messages: 2036
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Wed, 18 Nov 2015, qkumba wrote:
> H.E.R.O. as a clean 12k file is in Asimov /incoming.
>
It's funny that Exomizer spit out a file just 25 bytes shy of being
*exactly* 12K. (I haven't uploaded that - yet, at least - but I did upload
to my own servers a ProDOS port in 3 files.)
-uso.
|
|
|
|
|
|
|
|
|
|
|
|
| Re: new ProDOS ports [message #307113 is a reply to message #307105] |
Fri, 01 January 2016 13:47 |
Steve Nickolas
Messages: 2036
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Fri, 1 Jan 2016, qkumba wrote:
> Burgertime 21k single file in Asimov /incoming. What a monster.
Tell me about it, given that I did a 3-file ProDOS version that was a
nightmare to put together.
-uso.
|
|
|
|
| Re: new ProDOS ports [message #307139 is a reply to message #307113] |
Fri, 01 January 2016 18:07 |
qkumba
Messages: 1584
Registered: March 2013
Karma: 0
|
Senior Member |
|
|
>> Burgertime 21k single file in Asimov /incoming. What a monster.
>
> Tell me about it, given that I did a 3-file ProDOS version that was a
> nightmare to put together.
Yes, it would have been easier for me to let it expand into 64kb, especially for the DOS version, but it runs in 48kb after all.
|
|
|
|
| Re: new ProDOS ports [message #307306 is a reply to message #307139] |
Sun, 03 January 2016 23:29 |
BLuRry
Messages: 489
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Friday, January 1, 2016 at 5:07:14 PM UTC-6, qkumba wrote:
>>> Burgertime 21k single file in Asimov /incoming. What a monster.
>>
>> Tell me about it, given that I did a 3-file ProDOS version that was a
>> nightmare to put together.
>
> Yes, it would have been easier for me to let it expand into 64kb, especially for the DOS version, but it runs in 48kb after all.
It was a blast with these on my //e today. Thanks for the prodos conversions guys, they work FANTASTIC over VSDrive as well. :D Has anyone considered doing a file-crack of Airheart or Rad Warrior? Those games both act like single-load (albeit really huge)
-B
|
|
|
|
| Re: new ProDOS ports [message #307320 is a reply to message #307306] |
Mon, 04 January 2016 03:12 |
Steve Nickolas
Messages: 2036
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Sun, 3 Jan 2016, BLuRry wrote:
> On Friday, January 1, 2016 at 5:07:14 PM UTC-6, qkumba wrote:
>>>> Burgertime 21k single file in Asimov /incoming. What a monster.
>>>
>>> Tell me about it, given that I did a 3-file ProDOS version that was a
>>> nightmare to put together.
>>
>> Yes, it would have been easier for me to let it expand into 64kb, especially for the DOS version, but it runs in 48kb after all.
>
> It was a blast with these on my //e today. Thanks for the prodos conversions guys, they work FANTASTIC over VSDrive as well. :D Has anyone considered doing a file-crack of Airheart or Rad Warrior? Those games both act like single-load (albeit really huge)
>
> -B
>
I haven't played them to see if that's possible. Who knows, I converted
Qix, which is a 128K game, so it might be possible. Maybe one of the real
gurus like LoGo or qkumba is reading and will pull it off successfully. ;)
I've said it before: Floppies will fail, and new ones cease to be
manufactured, and our Unidisks will burn out, but the Apple ][s themselves
will keep working, and with the help of flash media and remote servers, we
will be able to keep using them for many years hence - and ProDOS is
device-agnostic enough to work with those, while classic RWTS needs
something that looks like a Disk ][. So in days long to come, it will be
file cracks and ProDOS ports that keep running on metal, and the disk
copies will be relegated to emulation.
-uso.
|
|
|
|
| Re: new ProDOS ports [message #307342 is a reply to message #307306] |
Mon, 04 January 2016 09:59 |
qkumba
Messages: 1584
Registered: March 2013
Karma: 0
|
Senior Member |
|
|
> It was a blast with these on my //e today. Thanks for the prodos conversions guys, they work FANTASTIC over VSDrive as well. :D Has anyone considered doing a file-crack of Airheart or Rad Warrior? Those games both act like single-load (albeit really huge)
You're welcome. :-) I have Airheart on my list, but as far as I remember, it would require 256kb to run as files because it's not a single-loader - requires write support, at least - so we'd need to stash ProDOS somewhere.
I'm not familiar with Rad Warrior. I'll take a look.
|
|
|
|
| Re: new ProDOS ports [message #307344 is a reply to message #307342] |
Mon, 04 January 2016 11:00 |
BLuRry
Messages: 489
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Monday, January 4, 2016 at 8:59:32 AM UTC-6, qkumba wrote:
>> It was a blast with these on my //e today. Thanks for the prodos conversions guys, they work FANTASTIC over VSDrive as well. :D Has anyone considered doing a file-crack of Airheart or Rad Warrior? Those games both act like single-load (albeit really huge)
>
> You're welcome. :-) I have Airheart on my list, but as far as I remember, it would require 256kb to run as files because it's not a single-loader - requires write support, at least - so we'd need to stash ProDOS somewhere.
> I'm not familiar with Rad Warrior. I'll take a look.
The European name for RadWarrior was Antirad, if that helps. :) As for Airheart, I can help you identify the memory usage if needed. Alternatively it might be possible to shove the game into slinky ram and replace the disk routines with much-smaller ram transfer routines. Of course bank-switched AUX such as RamWorks is also a possibility but I have a RamFactor so my bias is blatant and obvious. ;)
Happy new year and thanks for the great crack(s)!! :D
-Brendan
|
|
|
|
| Re: new ProDOS ports [message #307356 is a reply to message #307344] |
Mon, 04 January 2016 12:21 |
qkumba
Messages: 1584
Registered: March 2013
Karma: 0
|
Senior Member |
|
|
> The European name for RadWarrior was Antirad, if that helps. :)
4am just gave me a present, so I have it now.
> As for Airheart, I can help you identify the memory usage if needed. Alternatively it might be possible to shove the game into slinky ram and replace the disk routines with much-smaller ram transfer routines. Of course bank-switched AUX such as RamWorks is also a possibility but I have a RamFactor so my bias is blatant and obvious. ;)
I said 256k as a neat multiple. As I showed in my write-up, the disk is really full, and all of it is read. 128k for game+16k for ProDOS writing is probably more accurate.
> Happy new year and thanks for the great crack(s)!! :D
Happy New Year to you, too.
|
|
|
|
| Re: new ProDOS ports [message #307438 is a reply to message #307356] |
Mon, 04 January 2016 23:12 |
BLuRry
Messages: 489
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Monday, January 4, 2016 at 11:21:12 AM UTC-6, qkumba wrote:
>> The European name for RadWarrior was Antirad, if that helps. :)
>
> 4am just gave me a present, so I have it now.
As I say to my kids: Sharing is caring. :D
>> As for Airheart, I can help you identify the memory usage if needed. Alternatively it might be possible to shove the game into slinky ram and replace the disk routines with much-smaller ram transfer routines. Of course bank-switched AUX such as RamWorks is also a possibility but I have a RamFactor so my bias is blatant and obvious. ;)
>
> I said 256k as a neat multiple. As I showed in my write-up, the disk is really full, and all of it is read. 128k for game+16k for ProDOS writing is probably more accurate.
I'm willing to bet that it doesn't use compression, so there's probably a good chance at improving on that quite a bit. Not that you have PKZip as an option but it goes down to 84k from 140k with that algorithm. Exomizer or the LZ5 packer that Martin Haye uses might be good avenues.
There's always a way, especially when everyone else says there isn't. ;)
-B
|
|
|
|
| Re: new ProDOS ports [message #307508 is a reply to message #307438] |
Tue, 05 January 2016 16:12 |
D Finnigan
Messages: 1154
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
BLuRry wrote:
> On Monday, January 4, 2016 at 11:21:12 AM UTC-6, qkumba wrote:
>>> The European name for RadWarrior was Antirad, if that helps. :)
>>
>> 4am just gave me a present, so I have it now.
>
> As I say to my kids: Sharing is caring. :D
Which makes the comp.sys.apple2 of the 2010's the most careful Apple II
community! :-)
--
]DF$
The Marina IP stack for Apple II--
http://marina.a2hq.com/
|
|
|
|
| Re: new ProDOS ports [message #307565 is a reply to message #307438] |
Tue, 05 January 2016 23:37 |
qkumba
Messages: 1584
Registered: March 2013
Karma: 0
|
Senior Member |
|
|
>>> The European name for RadWarrior was Antirad, if that helps. :)
>>
>> 4am just gave me a present, so I have it now.
>
> As I say to my kids: Sharing is caring. :D
Radwarrior in two files is in Asimov /incoming.
>>> As for Airheart, I can help you identify the memory usage if needed. Alternatively it might be possible to shove the game into slinky ram and replace the disk routines with much-smaller ram transfer routines. Of course bank-switched AUX such as RamWorks is also a possibility but I have a RamFactor so my bias is blatant and obvious. ;)
>>
>> I said 256k as a neat multiple. As I showed in my write-up, the disk is really full, and all of it is read. 128k for game+16k for ProDOS writing is probably more accurate.
>
> I'm willing to bet that it doesn't use compression, so there's probably a good chance at improving on that quite a bit. Not that you have PKZip as an option but it goes down to 84k from 140k with that algorithm. Exomizer or the LZ5 packer that Martin Haye uses might be good avenues.
The problem is to decompress the data somewhere in a non-destructive way (i..e. the compressed data can't be overwritten because it must be needed again later).
> There's always a way, especially when everyone else says there isn't. ;)
Yes, but it would require ripping apart the game to see what's used when.
Reclaiming 16kb is a big ask, and all that just to save the high scores.
|
|
|
|
| Re: new ProDOS ports [message #307566 is a reply to message #307565] |
Wed, 06 January 2016 00:00 |
mdj
Messages: 301
Registered: December 2012
Karma: 0
|
Senior Member |
|
|
On Wednesday, 6 January 2016 14:37:03 UTC+10, qkumba wrote:
>> There's always a way, especially when everyone else says there isn't. ;)
>
> Yes, but it would require ripping apart the game to see what's used when.
> Reclaiming 16kb is a big ask, and all that just to save the high scores.
I'm not sure what aesthetic rules you're following, but if you can't 'quit' the game and need to reboot to exit, whether or not ProDOS is resident after load seems irrelevant.
With that in mind, you would be able read the ProDOS directory blocks of the game files, stash the block list, and issue Smartport calls, freeing up ~12k of the language card (assuming you kept the Disk ][ driver resident to allow for 5.25" compatibility)
But I suppose that's cheating ? :-)
|
|
|
|
| Re: new ProDOS ports [message #307567 is a reply to message #307565] |
Wed, 06 January 2016 00:09 |
Steve Nickolas
Messages: 2036
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Tue, 5 Jan 2016, qkumba wrote:
>>>> The European name for RadWarrior was Antirad, if that helps. :)
>>>
>>> 4am just gave me a present, so I have it now.
>>
>> As I say to my kids: Sharing is caring. :D
>
> Radwarrior in two files is in Asimov /incoming.
>
>>>> As for Airheart, I can help you identify the memory usage if needed. Alternatively it might be possible to shove the game into slinky ram and replace the disk routines with much-smaller ram transfer routines. Of course bank-switched AUX such as RamWorks is also a possibility but I have a RamFactor so my bias is blatant and obvious. ;)
>>>
>>> I said 256k as a neat multiple. As I showed in my write-up, the disk is really full, and all of it is read. 128k for game+16k for ProDOS writing is probably more accurate.
>>
>> I'm willing to bet that it doesn't use compression, so there's probably a good chance at improving on that quite a bit. Not that you have PKZip as an option but it goes down to 84k from 140k with that algorithm. Exomizer or the LZ5 packer that Martin Haye uses might be good avenues.
>
> The problem is to decompress the data somewhere in a non-destructive way (i.e. the compressed data can't be overwritten because it must be needed again later).
>
>> There's always a way, especially when everyone else says there isn't. ;)
>
> Yes, but it would require ripping apart the game to see what's used when.
> Reclaiming 16kb is a big ask, and all that just to save the high scores.
>
As with my (never 100% completed) 128K Lode Runner, I ditched the ability
to save scores, plus the editor, in order to "ram" the whole game into
memory. ;)
Actually, one thing wracked my brain that, if I could solve it, I bet I
could get Arkanoid to fit into single load (multifile). There's only 33
levels, and they're small, so they should easily fit into the auxiliary
memory, but there's some weird sort of caching system I never quite
figured out.
-uso.
|
|
|
|
| Re: new ProDOS ports [message #307575 is a reply to message #307566] |
Wed, 06 January 2016 01:58 |
qkumba
Messages: 1584
Registered: March 2013
Karma: 0
|
Senior Member |
|
|
>> Yes, but it would require ripping apart the game to see what's used when.
>> Reclaiming 16kb is a big ask, and all that just to save the high scores..
>
> I'm not sure what aesthetic rules you're following, but if you can't 'quit' the game and need to reboot to exit, whether or not ProDOS is resident after load seems irrelevant.
>
> With that in mind, you would be able read the ProDOS directory blocks of the game files, stash the block list, and issue Smartport calls, freeing up ~12k of the language card (assuming you kept the Disk ][ driver resident to allow for 5.25" compatibility)
>
> But I suppose that's cheating ? :-)
The point is that the target isn't a Disk ][ system, but a hard disk, by producing a version contained entirely within individual files, not a disk image. Given that, you'd need quite a lot of ProDOS to be resident in order to be able to write to the file system, in order to save the highscore (hence my reference to the 16kb which admittedly would be a complete ProDOS image, but even a trimmed version will be larger than what seems possible). The game is a single-loader when read, but the ability to save can be required multiple times in a single session (because the game can be restarted without rebooting, and a subsequent game might beat an existing high score).
|
|
|
|
| Re: new ProDOS ports [message #307576 is a reply to message #307565] |
Wed, 06 January 2016 02:05 |
BLuRry
Messages: 489
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Tuesday, January 5, 2016 at 10:37:03 PM UTC-6, qkumba wrote:
>>>> The European name for RadWarrior was Antirad, if that helps. :)
>>>
>>> 4am just gave me a present, so I have it now.
>>
>> As I say to my kids: Sharing is caring. :D
>
> Radwarrior in two files is in Asimov /incoming.
>
>>>> As for Airheart, I can help you identify the memory usage if needed.. Alternatively it might be possible to shove the game into slinky ram and replace the disk routines with much-smaller ram transfer routines. Of course bank-switched AUX such as RamWorks is also a possibility but I have a RamFactor so my bias is blatant and obvious. ;)
>>>
>>> I said 256k as a neat multiple. As I showed in my write-up, the disk is really full, and all of it is read. 128k for game+16k for ProDOS writing is probably more accurate.
>>
>> I'm willing to bet that it doesn't use compression, so there's probably a good chance at improving on that quite a bit. Not that you have PKZip as an option but it goes down to 84k from 140k with that algorithm. Exomizer or the LZ5 packer that Martin Haye uses might be good avenues.
>
> The problem is to decompress the data somewhere in a non-destructive way (i.e. the compressed data can't be overwritten because it must be needed again later).
>
>> There's always a way, especially when everyone else says there isn't. ;)
>
> Yes, but it would require ripping apart the game to see what's used when.
> Reclaiming 16kb is a big ask, and all that just to save the high scores.
Would it help to point out that you can watch active memory in Jace? I would need to adapt it for aux vs main memory though. I know that airheart uses EVERYTHING including all LC banks in Main and Aux.
|
|
|
|
| Re: new ProDOS ports [message #307684 is a reply to message #307565] |
Wed, 06 January 2016 16:07 |
BLuRry
Messages: 489
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Tuesday, January 5, 2016 at 10:37:03 PM UTC-6, qkumba wrote:
>>>> The European name for RadWarrior was Antirad, if that helps. :)
>>>
>>> 4am just gave me a present, so I have it now.
>>
>> As I say to my kids: Sharing is caring. :D
>
> Radwarrior in two files is in Asimov /incoming.
>
>>>> As for Airheart, I can help you identify the memory usage if needed.. Alternatively it might be possible to shove the game into slinky ram and replace the disk routines with much-smaller ram transfer routines. Of course bank-switched AUX such as RamWorks is also a possibility but I have a RamFactor so my bias is blatant and obvious. ;)
>>>
>>> I said 256k as a neat multiple. As I showed in my write-up, the disk is really full, and all of it is read. 128k for game+16k for ProDOS writing is probably more accurate.
>>
>> I'm willing to bet that it doesn't use compression, so there's probably a good chance at improving on that quite a bit. Not that you have PKZip as an option but it goes down to 84k from 140k with that algorithm. Exomizer or the LZ5 packer that Martin Haye uses might be good avenues.
>
> The problem is to decompress the data somewhere in a non-destructive way (i.e. the compressed data can't be overwritten because it must be needed again later).
>
>> There's always a way, especially when everyone else says there isn't. ;)
>
> Yes, but it would require ripping apart the game to see what's used when.
> Reclaiming 16kb is a big ask, and all that just to save the high scores.
Confirmed that RadWarrior works from a mass-storage volume as well. This is quite a treat for one massive gaming volume that all works over VSDrive:
- All apple crunch single load games (converted back to BIN), all start from super selector
- All prodos conversions working: Bolo, Neuromancer, Donkey Kong, Jungle Hunt, Rad Warrior, Karateka, Ultima 3 (Deckard's prodos conversion), Zork Zero, Mr. Do
Is there any luck you guys have had (or need help with) converting these to Prodos?
-Marble Madness
-Spare Change
-Boulderdash (and or Construction Set)
-Lode Runner
-Summer, Winter, and/or California games
-Blazing Paddles
-Music Construction Kit
In exchange I could probably be easily motivated to add Uthernet-II or real serial port support to Jace. Or pick some other feature you want.
|
|
|
|
| Re: new ProDOS ports [message #307692 is a reply to message #307684] |
Wed, 06 January 2016 16:29 |
Steve Nickolas
Messages: 2036
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Wed, 6 Jan 2016, BLuRry wrote:
> Confirmed that RadWarrior works from a mass-storage volume as well.
> This is quite a treat for one massive gaming volume that all works over
> VSDrive:
> - All apple crunch single load games (converted back to BIN), all start
> from super selector
> - All prodos conversions working: Bolo, Neuromancer, Donkey Kong, Jungle
> Hunt, Rad Warrior, Karateka, Ultima 3 (Deckard's prodos conversion),
> Zork Zero, Mr. Do
Didn't Zork Zero *always* run on ProDOS?
> Is there any luck you guys have had (or need help with) converting these
> to Prodos?
> -Marble Madness
> -Spare Change
> -Boulderdash (and or Construction Set)
> -Lode Runner
> -Summer, Winter, and/or California games
> -Blazing Paddles
> -Music Construction Kit
I know Lode Runner can be done, though I tried making it single load, and
never got the high scores (as I intended them to be) fully disabled, or
(more ideally) converted to sit in RAM.
Getting Qix (only 128K game I've done) to run on ProDOS was just luck.
-uso.
|
|
|
|
| Re: new ProDOS ports [message #307694 is a reply to message #307692] |
Wed, 06 January 2016 17:06 |
BLuRry
Messages: 489
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Wednesday, January 6, 2016 at 3:28:53 PM UTC-6, Steve Nickolas wrote:
> On Wed, 6 Jan 2016, BLuRry wrote:
>
>> Confirmed that RadWarrior works from a mass-storage volume as well.
>> This is quite a treat for one massive gaming volume that all works over
>> VSDrive:
>> - All apple crunch single load games (converted back to BIN), all start
>> from super selector
>> - All prodos conversions working: Bolo, Neuromancer, Donkey Kong, Jungle
>> Hunt, Rad Warrior, Karateka, Ultima 3 (Deckard's prodos conversion),
>> Zork Zero, Mr. Do
>
> Didn't Zork Zero *always* run on ProDOS?
>
>> Is there any luck you guys have had (or need help with) converting these
>> to Prodos?
>> -Marble Madness
>> -Spare Change
>> -Boulderdash (and or Construction Set)
>> -Lode Runner
>> -Summer, Winter, and/or California games
>> -Blazing Paddles
>> -Music Construction Kit
>
> I know Lode Runner can be done, though I tried making it single load, and
> never got the high scores (as I intended them to be) fully disabled, or
> (more ideally) converted to sit in RAM.
>
> Getting Qix (only 128K game I've done) to run on ProDOS was just luck.
>
> -uso.
Yes, but the 5.25 version didn't lend itself to hard disk installation AFAIK. Anyway, it also works over vsdrive. :)
I should also note that in the memory viewer of Jace you can see the most recent 5 instructions that accessed or wrote to a given memory location. So for example if you are trying to track down RWTS locations...
|
|
|
|
| Re: new ProDOS ports [message #307753 is a reply to message #307575] |
Thu, 07 January 2016 01:54 |
mdj
Messages: 301
Registered: December 2012
Karma: 0
|
Senior Member |
|
|
On Wednesday, 6 January 2016 16:58:17 UTC+10, qkumba wrote:
> The point is that the target isn't a Disk ][ system, but a hard disk, by producing a version contained entirely within individual files, not a disk image. Given that, you'd need quite a lot of ProDOS to be resident in order to be able to write to the file system, in order to save the highscore (hence my reference to the 16kb which admittedly would be a complete ProDOS image, but even a trimmed version will be larger than what seems possible). The game is a single-loader when read, but the ability to save can be required multiple times in a single session (because the game can be restarted without rebooting, and a subsequent game might beat an existing high score)..
How big is the file containing the highscore/save data ? If the file is a fixed size, then writing its contents without ProDOS resident is actually pretty straightforward, assuming you have a loader program that has access to ProDOS beforehand, and you store save data in its own file.
Assuming that, this is how I'd do it:
1. Get the current prefix with a GET_PREFIX call
2. Open the directory file and locate the file entry for the save file.
3. grab the key block pointer from the file entry
4. Use a SmartPort/Block device call to load the key block into memory
The key block contains a sequential list of all the blocks used to store the files data. This assumes of course, that the file is > 512 bytes and < 128k. If it is < 512 bytes, you're in luck, the key block *is* the files data.. I seriously doubt any file you'd need to worry about is > 128k. If it was, it's definitely too hard to do without ProDOS.
I expect most game titles don't have much of an operating system at all, and just save their data by dumping a bit of memory to disk sectors/blocks/tracks. Once you have your save files block list, reading/writing the data using SmartPort calls is pretty easy, and you can throw ProDOS away. Your resident read/write routines + the key block should be well under a kilobyte - within spitting distance of the size of RWTS :-)
Obviously it's a few hours work to throw together a loader that can do all this stuff, but it seems to me the technique could throw the door open to just about any single-load title, and with some obvious extensions, a few multi-load ones as well.
Matt
|
|
|
|
| Re: new ProDOS ports [message #307777 is a reply to message #307753] |
Thu, 07 January 2016 10:31 |
BLuRry
Messages: 489
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Thursday, January 7, 2016 at 12:54:32 AM UTC-6, mdj wrote:
> On Wednesday, 6 January 2016 16:58:17 UTC+10, qkumba wrote:
>
>> The point is that the target isn't a Disk ][ system, but a hard disk, by producing a version contained entirely within individual files, not a disk image. Given that, you'd need quite a lot of ProDOS to be resident in order to be able to write to the file system, in order to save the highscore (hence my reference to the 16kb which admittedly would be a complete ProDOS image, but even a trimmed version will be larger than what seems possible).. The game is a single-loader when read, but the ability to save can be required multiple times in a single session (because the game can be restarted without rebooting, and a subsequent game might beat an existing high score).
>
> How big is the file containing the highscore/save data ? If the file is a fixed size, then writing its contents without ProDOS resident is actually pretty straightforward, assuming you have a loader program that has access to ProDOS beforehand, and you store save data in its own file.
>
> Assuming that, this is how I'd do it:
>
> 1. Get the current prefix with a GET_PREFIX call
> 2. Open the directory file and locate the file entry for the save file.
> 3. grab the key block pointer from the file entry
> 4. Use a SmartPort/Block device call to load the key block into memory
>
> The key block contains a sequential list of all the blocks used to store the files data. This assumes of course, that the file is > 512 bytes and < 128k. If it is < 512 bytes, you're in luck, the key block *is* the files data. I seriously doubt any file you'd need to worry about is > 128k. If it was, it's definitely too hard to do without ProDOS.
>
> I expect most game titles don't have much of an operating system at all, and just save their data by dumping a bit of memory to disk sectors/blocks/tracks. Once you have your save files block list, reading/writing the data using SmartPort calls is pretty easy, and you can throw ProDOS away. Your resident read/write routines + the key block should be well under a kilobyte - within spitting distance of the size of RWTS :-)
>
> Obviously it's a few hours work to throw together a loader that can do all this stuff, but it seems to me the technique could throw the door open to just about any single-load title, and with some obvious extensions, a few multi-load ones as well.
>
> Matt
Also, Martin Haye has figured out how to relocate prodos out of main memory for anyone who needs to do that sort of thing. :)
-B
|
|
|
|
| Re: new ProDOS ports [message #307779 is a reply to message #307753] |
Thu, 07 January 2016 11:14 |
qkumba
Messages: 1584
Registered: March 2013
Karma: 0
|
Senior Member |
|
|
> How big is the file containing the highscore/save data ? If the file is a fixed size, then writing its contents without ProDOS resident is actually pretty straightforward, assuming you have a loader program that has access to ProDOS beforehand, and you store save data in its own file.
Yes, I realized afterwards that your idea might be possible, but the game isn't a true single-loader - the highscores are read into memory before being updated and then written out again. Presumably, the overwritten content is also read back again later. Still, it's worth investigating further.
|
|
|
|
| Re: new ProDOS ports [message #307826 is a reply to message #307777] |
Thu, 07 January 2016 18:45 |
Michael AppleWin Debu
Messages: 1262
Registered: March 2013
Karma: 0
|
Senior Member |
|
|
On Thursday, January 7, 2016 at 7:31:16 AM UTC-8, BLuRry wrote:
> Also, Martin Haye has figured out how to relocate prodos out of main memory for anyone who needs to do that sort of thing. :)
Oh? Link please! :)
|
|
|
|
| Re: new ProDOS ports [message #307830 is a reply to message #307567] |
Thu, 07 January 2016 19:10 |
gids.rs
Messages: 1395
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Tuesday, January 5, 2016 at 11:08:29 PM UTC-6, Steve Nickolas wrote:
> On Tue, 5 Jan 2016, qkumba wrote:
>
>>>> > The European name for RadWarrior was Antirad, if that helps. :)
>>>>
>>>> 4am just gave me a present, so I have it now.
>>>
>>> As I say to my kids: Sharing is caring. :D
>>
>> Radwarrior in two files is in Asimov /incoming.
>>
>>>> > As for Airheart, I can help you identify the memory usage if needed. Alternatively it might be possible to shove the game into slinky ram and replace the disk routines with much-smaller ram transfer routines. Of course bank-switched AUX such as RamWorks is also a possibility but I have a RamFactor so my bias is blatant and obvious. ;)
>>>>
>>>> I said 256k as a neat multiple. As I showed in my write-up, the disk is really full, and all of it is read. 128k for game+16k for ProDOS writing is probably more accurate.
>>>
>>> I'm willing to bet that it doesn't use compression, so there's probably a good chance at improving on that quite a bit. Not that you have PKZip as an option but it goes down to 84k from 140k with that algorithm. Exomizer or the LZ5 packer that Martin Haye uses might be good avenues.
>>
>> The problem is to decompress the data somewhere in a non-destructive way (i.e. the compressed data can't be overwritten because it must be needed again later).
>>
>>> There's always a way, especially when everyone else says there isn't. ;)
>>
>> Yes, but it would require ripping apart the game to see what's used when.
>> Reclaiming 16kb is a big ask, and all that just to save the high scores..
>>
>
> As with my (never 100% completed) 128K Lode Runner, I ditched the ability
> to save scores, plus the editor, in order to "ram" the whole game into
> memory. ;)
>
> Actually, one thing wracked my brain that, if I could solve it, I bet I
> could get Arkanoid to fit into single load (multifile). There's only 33
> levels, and they're small, so they should easily fit into the auxiliary
> memory, but there's some weird sort of caching system I never quite
> figured out.
>
> -uso.
Have you ever used Aux Language Card for storing data, Steve? As long as the program doesn't need ROM or Prodos, the LC is very easy to switch over to and, read and write, data, without the headache of using the Auxiliary lower 48k.
|
|
|
|
|
|
|
|
| Re: new ProDOS ports [message #307844 is a reply to message #307840] |
Thu, 07 January 2016 23:22 |
gids.rs
Messages: 1395
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Thursday, January 7, 2016 at 8:29:50 PM UTC-6, BLuRry wrote:
> On Thursday, January 7, 2016 at 5:45:15 PM UTC-6, Michael 'AppleWin Debugger Dev' wrote:
>> On Thursday, January 7, 2016 at 7:31:16 AM UTC-8, BLuRry wrote:
>>> Also, Martin Haye has figured out how to relocate prodos out of main memory for anyone who needs to do that sort of thing. :)
>>
>> Oh? Link please! :)
>
> Look at the memory manager for Lawless Legends, starting around line 70 or so.
> https://github.com/badvision/lawless-legends/blob/master/Pla tform/Apple/virtual/src/core/mem.s
>
> -B
It is unnecessary to copy Prodos over to Aux LC. The same thing can be done by implementing the same patches in the Prodos Global page, but with the softswitches to enable Main LC instead and keep the Aux LC turned on while the program is running. The Main zero page and stack would have to be copied over to the Aux zero page though.
And calls made to ROM would still work the same way except that now all references to READ/WRITE LC refer to the Aux mems LC which is where the program would be running from.
He does have an interesting way of flipping softswitches that I have not seen before, using INCrement instead of a STA or LDA.
|
|
|
|
| Re: new ProDOS ports [message #307845 is a reply to message #307830] |
Thu, 07 January 2016 20:43 |
Steve Nickolas
Messages: 2036
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Thu, 7 Jan 2016, gids.rs@sasktel.net wrote:
> Have you ever used Aux Language Card for storing data, Steve? As long
> as the program doesn't need ROM or Prodos, the LC is very easy to switch
> over to and, read and write, data, without the headache of using the
> Auxiliary lower 48k.
I try to avoid using that part of memory - if I can, I pretend it doesn't
exist, as well as the extra 4K on the main LC, and tha I only have 108K.
Keeps things simpler in my mind.
-uso.
|
|
|
|
| Re: new ProDOS ports [message #307914 is a reply to message #307843] |
Fri, 08 January 2016 10:57 |
BLuRry
Messages: 489
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Thursday, January 7, 2016 at 10:19:41 PM UTC-6, mdj wrote:
> On Friday, 8 January 2016 12:29:50 UTC+10, BLuRry wrote:
>
>> Look at the memory manager for Lawless Legends, starting around line 70 or so.
>> https://github.com/badvision/lawless-legends/blob/master/Pla tform/Apple/virtual/src/core/mem.s
>
>
> Interesting. What's the value in LL moving ProDOS to Auxiliary memory ? I've looked at doing this in the past, but primarily because I'm a RamWorks nutter, and moving it to Aux space makes a lot more sense when you have many auxilary banks to play with.
>
> Matt
The raycaster routine is a gigantic unrolled loop (how else is it so fast? ;) So to make room for it and all the graphics, Martin moves Prodos out of the way. Aux bank is used for all of the Plasma code. Basically the memory allocation scheme can be summarized like this: "I drink your milkshake. I DRINK IT UP." We use every scrap of memory we can get, and eventually will expand it further to take advantage of RamWorks and/or slinky cards.
In most cases, data is allocated and deallocated on the fly, so having large contiguous regions of memory to work with presents many advantages. Our engine reads from disk less often than Ultima V when you walk around the map. :D
|
|
|
|
| Re: new ProDOS ports [message #307946 is a reply to message #307844] |
Fri, 08 January 2016 06:54 |
Steve Nickolas
Messages: 2036
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Thu, 7 Jan 2016, gids.rs@sasktel.net wrote:
> It is unnecessary to copy Prodos over to Aux LC. The same thing can be
> done by implementing the same patches in the Prodos Global page, but
> with the softswitches to enable Main LC instead and keep the Aux LC
> turned on while the program is running. The Main zero page and stack
> would have to be copied over to the Aux zero page though.
>
> And calls made to ROM would still work the same way except that now all
> references to READ/WRITE LC refer to the Aux mems LC which is where the
> program would be running from.
I thought maybe this method could be useful for porting 64K non-DOS MECC
software (Odell Lake, Word Munchers, Number Munchers but NOT Oregon Trail
or Fraction Munchers as the former demands too much of a DOS 3.3
filesystem and the latter needs 128K).
Disable the check for 128K and always assume only 64K - then use the AUX
LC memory for stuff above 48K. Not sure how doable that may be.
-uso.
|
|
|
|
Members
Search
Help
Register
Login
Home
