Exactly... he's made a video about something we'd been 100% honest about but not got around to fixing yet....

...whilst still pretending his Armor Geddon and Battle for Britain and everythign else he's butchered are all ok ROFL.

Wow.  I missed the death of this EAB thread, and the one that followed it.  Must of got serious for it to be completely deleted!

Does anyone have a copy of what happened after I posted?  Or can someone fill me in with how Pppppwanker replied to my (pretty reasonable IIRC) posts?

I know!  Does MugUK have an amiga alterego?

Well, for the less technical savy people as my self that could have been a very interesting thread if pperror hadn't trolled his way through it.
Oh well...

Hey come on guys - lets be nice.

I'd imagine that ULS and WHDLoad are built very differently, and although I personally think that save states on an Amiga *are* possible (the Action Replay cart managed this, so why would a software solution not also be possible?), I doubt it is something that could easily be bolted on to the existing WHDLoad code.

Stingray - I sincerely doubt that CJ was meaning to come across as rude.  He can be a bit blunt, but he's one of the nicest people in the scene, so please don't take offence - I read it as a bit of Amiga/Atari banter.

From past experience of working with you, I know that you're an experienced Amiga coder (you hacked the high score routine in Tubular Worlds so it was joystick controlled and saved to the CD32 NVRAM for me).  Maybe if you and the DBug guys collaborated it would be possible to add save state functionality to WHDload, or create a similar soloution as a proof of concept?

Anyway - I'll be in touch soon as I'm planning to make a few more CD32 compilations this year.  I don't suppose you are interested in adding second-button support to Vision's 'Cybernetix'?

(EDIT - After reading the "No Quit Options..." thread, esp. Klaz's comments on the matter, it does sound considerably more than trivial to add save states to the Amiga.  I'm no expert though )

CJ wrote on 11.01.10 at 21:01:05:


That would work if it was simply a copperlist... but then again, how are you going to get access to the pointer to $dff080 which is the copper list pointer.... and read only?

Secondly, if its an older game, chances are it didn't use a  copperlist and simply moved the colour values directly into the colour registers... again, all 32 are read only.

As I said before, the only true way to do it without hardware would be to have to individually patch routines in  the game, thats each and every game, thats each and every pallette routine... that now becomes a serious amount of work.

Like I said before, i'm not interested in having to recode my slaves to accept save states when most Amiga games have a save function built in anyway.

I can assure you, doing a save state via a software solution on Amiga is not trivial..... its why it hasn't been done

CJ wrote on 12.01.10 at 00:45:43:


Its only possible if each game has been individually patched to get the game copperlists and palletes, and all the other shit that needs to be extracted from the game to ensure a proper continue of the game, and frankly, I think you utterly underestimate the level of work required to do that.

On a game like Hook for instance, there must be about 8 or 9 separate code files that would have to be patched to ensure that a save state restores the correct copperlists and palletes for whichever piece of code happens to be running.

It seems to me that on the ST this really is a trivial exercise to accomplish, because your ULS code is what does the work, no extra patching is required to get the save state to work.

On Amiga games, its just a whole different ball game.  WHDLoad patchers would have to patch a shitload more just for a save state, when frankly, its just not needed.

I can not code a catch all save state that will work on all games on Amiga, I can only patch 1 game at a time, and for some Amiga games, thats going to be proper messy and extraordinarily tedious and time consuming, time that would be far better spent improving existing slaves and ensuring that any missed games get supported.

I just don't see it happening, and i'm sure as hell not doing it. 

CJ wrote on 12.01.10 at 06:45:53:


Seconded

CJ wrote on 09.01.10 at 14:23:56:


I admit that I didn't publish sources:

http://ppera.07x.net/atari/playfhd.html

http://ppera.07x.net/atari/GAMEXdoc.html

I admit that only ggn got STX of Encounter. Before November 2009. Then Ben Gun sent it to me. Now put him on yout blacklist too...

I went on EAB to ask for help to porting WHDLoad on Atari ST.... Or maybe I said there that ULS is it ...

I admit that only proper way to compare speed of 2 SW is: running one on 50MHz 68030 and other on 8MHz 68000 ....

Shall I continue ?

Nikolai wrote on 14.01.10 at 15:40:15:


Nope, you're banned.

haha, poor fucking pcunt

Why do I get the feeling you wanted to say that on EAB but thought the moderator might stop you?

Now, as a moderator I am forced to comment on this and issue a warning.

"Well done Phill!"

and

"Perror, don't ever come back here again. Consider yourself warned."

CJ wrote on 14.01.10 at 20:34:47:


Simple, it only works under certain circumstances.

One thing that increases success is the Atari OS. In the zero-page of memory it shadows various hardware registers. Each VBL, those shadow registers are copied by the OS to the hardware registers. So programs that use those shadow registers instead of writing directly to the hardware registers have a higher chance to be restored correctly.

Also when programs rewrite the registers every VBL the write-only registers are no problem. The first 1/50th (or 1/60th for NTSC) of a second you won't notice if things are wrong.

I tried the software freezer. Many games I couldn't even load with the Freezer software loaded. One of the causes could be that the loaded program overwrites the Freezer software. Also if the program circumvents the OS, the freezer hooks will not be active.

One of the programs that did work was the "Molecule Man Maze Editor" and here you see what can go wrong when the game is restored. The editor uses a player (sprite) for giving the available object pane a different background color (reddish), a player for the object selector (white square) and a player for the maze position selector (blue square). Since the display is quite simple it does not write the hardware registers each VBL. The freezer software can't restore the write-only registers and you will see that the restored program has an incorrect display. There is no reddish background color and the white and blue selectors are garbled (the white and blue pixels at the bottom of the screen)

Robert

Woo-hoo! He-e-e-e-e's back! They love him! They really really love him!

http://eab.abime.net/showthread.php?t=50531

If he is stupid enough to write any software on Amiga, i'll be ensuring, as i'm sure Stingray will that it never gets used nor adopted.

I see nothing that he could code that doesn't already exist on Amiga.

Re-inventing the wheel as a square is not what is required!