| |
jcompton
Registered: Feb 2006
Posts: 70 |
Release id #188012 : PSI-5 Trading Company +4D
The number keys 1-4 should be able to select a mission, but that doesn't seem to work. |
|
... 13 posts hidden. Click here to view all posts....
|
| |
Trurl
Registered: Mar 2002
Posts: 61 |
Quoting ϵʟʞThe loader is great as it is - including the on the fly decruncher!
True, but I wish more people would actually enable the kernal fallback support :P |
| |
Krill
Registered: Apr 2002
Posts: 2982 |
Quoting ϵʟʞThank you Krill for the great loader! It is the master piece! [...] don't make upgrade if it could take something out - I mean e.g. size, speed, etc. Then better name it with the different name like 'SD2IEC Krill loader'. Thanks for the praise! :)
Not sure if i made this clear enough. I meant upgrading SD2IEC-side code to support the loader, not the other way around. SD2IEC already comes with support for a few select fast/IRQ loaders and their custom protocols.
I was musing about adding support for this loader to SD2IEC firmware, without changing anything in the C-64/drive code.
Quoting TrurlTrue, but I wish more people would actually enable the kernal fallback support :P It does come with a fair bit of caveats by having to make ROM calls (including the code not touching associated zeropage/lowmem variables), and making sure that it actually works isn't trivial.
But i think there's also a common misconception that "KERNAL fallback" would actually be the old slow-load we know from an unexpanded machine.
In fact it's using the closest thing to a standard API for loading we have, and any kind of KERNAL enhancement (IDE64 with its DOS, JiffyDOS, ...) would work with it.
That is, you can have fast and even IRQ loading with KERNAL fallback being active, depending on whatever the machine brings in terms of non-standard KERNAL.
Quoting ϵʟʞThe loader is great as it is - including the on the fly decruncher! Thanks again! I'm in fact currently working on a new version. Added some fixes and speed improvements first, now i'm on to adding new decrunchers.
ZX0 and LZSA2 are very promising in both speed and pack ratio: locate Exo3 in this graph https://introspec.retroscene.org/compression/pareto_20210128.png and see how it relates to ZX0, then LZSA2. =D
The next thing on the list would be a (hiscore/savegame) saver plug-in, but not sure if it will make it into next release already or the one after that. |
| |
DKT
Registered: Aug 2004
Posts: 99 |
Hi.
The first most important thing was to speed up loading in this game and important was to choose a flexible, most compatible and small enough loader. The game uses almost all c64 memory. As I remember we used some stack space (the only available space after we put loader somewhere under $0400) to implement some translation jumps, so Krill's loader was a perfect choice (with NTSC compatibility enabled). The 3rd opportunity which we found during development was that we are able to put all on one disk side \o/
Saving option for the loader would be really appreciated and would be a gem for all crackers (I'm not the one, but I think the others would be very happy :)
Thanks Krill.
Cheers |
| |
Krill
Registered: Apr 2002
Posts: 2982 |
Quoting DKTSaving option for the loader would be really appreciated and would be a gem for all crackers The saver will probably be rather limited, as in it will probably not be able to create new files.
So i'm thinking of pre-existing hiscore or savegame files.
The saver would then overwrite those existing files with new data, with the overwritten files being as big (same amount of blocks, not necessarily bytes) afterwards as they were before.
The question now is if this would satisfy most or even all the regular saving requirements for games, and if not, what it should be able to do. |
| |
DKT
Registered: Aug 2004
Posts: 99 |
I think, overwriting existing file only should be enough in most cases |
| |
jcompton
Registered: Feb 2006
Posts: 70 |
The additional mission seems to be a way to smooth out the difficulty curve between missions 2 and 3 (or missions 1/2 from the three-mission version). Risk level was fairly modest throughout (I never saw it go higher than 10, and rarely had more than four ships on the scanner at any one time just by occasionally bouncing between course A and B when I wanted to quiet the fretting navigator). Perhaps useful for players who have been frustrated trying to make the transition to longer missions and just need more time in-flight to get their routines down, although the fact that the risk level stayed so low (it was down in the 0-3 range a surprising amount on course B!) might make it tricky to really push beyond and learn new tricks. |
| |
ϵʟʞ
Registered: May 2012
Posts: 26 |
Quoting DKTI think, overwriting existing file only should be enough in most cases
Hi my friend! And YES - I can imagine that it will be useful enough.
Reserving space on disk for saves then writing at this place.. It is what I will need to have for our next not yet finished release .) |
| |
ϵʟʞ
Registered: May 2012
Posts: 26 |
Quoting jcomptonThe additional mission seems to be a way to smooth out the difficulty curve between missions 2 and 3 (or missions 1/2 from the three-mission version).
Yes! Additionaly, in the right meaning mission to 'Markus-3' is not 'additional' as it is not my 'addition', the best on it is that it was already included in the original code! :) |
| |
jcompton
Registered: Feb 2006
Posts: 70 |
Ah, interesting.
Since you seem to have spent more time digging through the game's code than most, have you tracked down how the different crew characteristics are configured? (for example, how the game assigns weapons officers their skill with each of the four weapons and their likelihood to open fire without orders, etc.) |
| |
ϵʟʞ
Registered: May 2012
Posts: 26 |
Uhm, I did not pointed at the game logic, because what you are talking about is not so trivial to understand.. The game is really the masterpiece. There are really lots of routines combined together.. This massively increase the number of branching of possible cases. I found the places of where data is written and tried to understand to some of them but not all I discovered.. They are spread on many different places in C64 memory. This logic is the most important part of what this game is about. To analyze the whole process for me would need really lots of time. Maybe someone more skilled could decompile all of them and better understand. But - if you imagine the machine code look and the memory size of C64 - I was fighting with the free space in memory for my modifications - there is not much space left in memory! |
| Previous - 1 | 2 | 3 - Next |
