Quite simply the answer is...

I can't be bothered to add them.. if a game desperatly needs them (or it's requested for a valid reason) I can go back and add it in a fairly short time... but otherwise these things are taking 10-20 minutes each to patch, the extra time for the state management/quit takes that to around 30-60 minutes.

In short, I'd rather:

• Patch another game in the time I have
• Sleep
• Be with my family for that time

Hope you all understand!

CJ

Well, I dunno if the WHDLoad chaps had quit available from the first version, but they have been around for much longer!

It's down to how much bothered is the patcher at the moment of doing a game.

Of course, like CJ says, we're not deaf, so make a request and we'll consider it

Just to add that the quit to desktop feature certainly seems to add a professional feel to the patches (not that i am implying that the patches are not in any way professional,l im sure you know what i mean)....thought id better cover my ass

CJ wrote on 18.01.09 at 13:51:53:


I guess they already have stopped, once they had noticed that we have state save/restore, which they don't. 

We were just crazy enough and went ahead with it - the only way things progress

Or in other words. Amiga lacks an mmu therefore it's superior.

Christos wrote on 10.02.09 at 00:12:31:


Show me any 68000 Atari with a real(!) MMU. Classic own goal. (*starts to laugh hysterically* )


CJ wrote on 10.02.09 at 03:27:22:


Well, that's one custom chip you have to take care of. So I suppose the way you do it is to patch every write operation to that very chip in the game and save these values so you can restore them later? That's how I'd do it at least without any MMU and stuff. 
On Amiga things look a bit different as you have shitloads of custom registers and since they are all used extensively that approach would be way too time consuming (not to forget it would slow down the game/demo code quite a bit). Anyway, I do agree that save states are a very cool thing and at least that's one of the few things where the inferior Atari hardware wins.

Klapauzius wrote on 10.02.09 at 18:07:18:


Well, quit is rather easy to do as all you have to do is restoring the system (i.e. memory, interrupts/dma, copperlists etc. pp). This is all no problem as the OS provides the necessary routines to f.e. restore the system copperlist and the interrupt registers are read/write registers, i.e. you can easily restore them without much hassle. Basically any decent demo startup/restore code with some added extras (memory save/restore f.e.) could be used for that job.

However, save states require much more than that. ALL the custom registers need to be saved (so they can be restored when loading the save state) otherwise you'll end up with a screwed game! And this is where the headache starts! You can not easily grab, say, the contents of the color registers (they are write only!). So f.e. game sets color register 0 ($dff180) to $f00. You have NO way (without any MMU) to know that $dff180 contains this value without intercepting the write to $dff180. Now, just imagine a simple AGA Faderoutine which writes to the color registers and performs bank switching etc, you can probably imagine how much it would slow down the game when you need to intercept each write operation. As another example, you can also not know which address $dff080 (copperlist) points to (which was the reason why you could easily stop cartridges such as Action Replay from freezing your demo/game, you'd just fool it by setting a copperlist that would initialise all imortant hardware registers and then switch to the main copperlist, the cartridge would not know about the writes to the custom registers in the first copperlist and you can easily imagine the result). So, the only sane solution for reliable save states on Amiga is using an MMU, everything else is just not going to work properly. And even with an MMU it's not exactly easy to do!

ggn wrote on 11.02.09 at 19:05:07:


Easy, we usually don't. I can count the Amiga stuff that bothers to fade out the current workbench/cli palette on the fingers of one hand. But yes, the OS (graphics.library) stores the pointer to the current system palette in a structure. But it's usually like this: turn off multitasking (i.e. kill the system), bang in your new copperlist and don't care about the system until you need to restore it.

I remember a software freezer that could do this on the A8, no hardware required - and it was pretty good as well worked with most things.

Can't remember what it was called tho! (stupid write-only human brain!)