Actually, creating the ramdisk feature was one of the first features we added to ULS, because the first experiment (aka F1GP) loaded quite slowly.

And, the option to turn it on/off of course exists because we don't want to increase the total memory footprint required. Contrary to what that fucktard says, most games do work with 1mb, but like WHDload when it gets tight in memory, loading will suffer a bit. Still it's more convenient than loading from floppy, right?

In conclusion, another one of Mr. Partition Wiper's FUD campaigns against us faces the cold hard facts and falls dead on its tracks .

He's right tho. He's the only one who does "adaptations" and he isn't co-operative or have enough knowledge.

I'd love to know how he can justify that statement when we've produced the ULS code over 4+ years of hard work and testing, and then given it away freely to the community, with full source code, documentation and continued support with constant updates while all his stuff is closed source, buggy, consistantly bad crap.

ULS is now every bit as mature, stable and feature rich as WHDload on the Amiga (which is a fantastic piece of code, btw) and it has proven itself time and time again as a rock solid platform for producing Falcon/HD fixed games, and is being used by more people than just us (Hi Klaz, Hi Phill from Fairlight!)

oh he's on EAB.. so am I ..
lets see!

Chaps, can you come and get your lamer back?  You've left him on EAB!

Christos wrote on 06.01.10 at 18:25:39:


Have you still got the receipt?  As far as 'gifts' go, this one sucks balls! 

Christos wrote on 06.01.10 at 18:45:58:


He's been plauging you lot for years, just how long does a Troll season go on for?

i'm not too concerned, the backlash has begun on EAB, so I think it won't be long before he volunteers himself a hiatus to bother someone else.

He's asking some really stupid questions frankly.  How does him learning about partitions on Amiga help him to code his own ULS / WHDLoad style system?

I would have thought that by analysing Atari ST stuff would be the way to go, but it appears i'm very much mistaken in the belief that if you're going to code for a specific machine, learning about that machine is the way to go?!?!

Silly me! 

Don't worry chaps, we won't wear him out too much, we know you want him back... though I doubt he will be in pristine condition

CJ wrote on 06.01.10 at 20:55:29:


Season of giving?  Did that include sexually transmitted diseases as well?

Some bloody season that was!

Seriously though, he's pissing us off, the jokes over, its no longer funny, we have standards don't you know... and your 'gift' falls way below that.

Damn it, we'll PAY for you to take him back! 

Seriously, though, can't we team up and package him off to an x68000 or Sega Geneis forum?

he's always welcome here We love discussing things with him

Pperror is such an ass.  No one in the atari community wants to talk with him, so off he runs to the Amiga scene - to talk about his buggy and rather pointless Atari stuff!  Why does he bother?!

Klapauzius wrote on 07.01.10 at 10:03:33:


Mayby he try found some users for his "better than other programs - program"?

Heavy Stylus wrote on 07.01.10 at 09:10:19:


Because stupid little ppera is craving for attention. What an easy question that was. *runs away and giggles like a 13 year old schoolgirl*

I opened a new one in OFF TOPIC to respond to his silly Amiga related guff.

http://ppera.07x.net/atari/imgrun.php

Check the backdrop

"Graham's" lack as sense of humour?! as if!

Heh you have an Amiga version of MugUK as well!

This is the bit I dont get with WHDload:

Quote:


If you have to disable/restore the OS - *why* can't it support savestates?  Sting tried to explain it but it all sounded like guff

As for locking that thread, I thought we were having a nice polite discussion. Oh well, no fear of locking it here

he's even locked the "off topic" one!! how bizarre!

Shw

The off-topic topic at EAB wasn't even insulting.  Just seemed to me to be more informative than anything.

*shrugs*

Oh, well.

CJ wrote on 08.01.10 at 21:58:12:


Yes Amiga has a blitwait function, but if the blitter is kept constantly busy because the game hasn't used blitwaits and just runs blits concurrently one after another, waiting for the blitter to finish might never occur.

Also its possible and some programmers do use the blitter from the copperlist, which can then cause problems restoring as you'd need to restart that copperlist, and it could be a dynamic one that is constantly being altered which will again cause problems.

But thats all childs play compared to having access to read only custom registers and restoring them.  Action Replay got by this because of its Zorro access to the memory bus so it could intercept and monitor writes to custom registers and memory, all Amigas would need an MMU to do a proper 100% accurate save state.

it would be possible I suppose for someone to to a software version that assumes certain custom registers would get their proper values restored by the game and hardware once the game gets up and running, but theres no guarantee of that.

Its just a little more complicated on Amiga, otherwise it would have been successfully integrated already

Its not as if the Amiga lacks the talent

Phill wrote on 08.01.10 at 23:33:44:


If all interupts are off, and the cpu is in your code, how is it possible for it not to finish?

Exactly.

So if all ints are off, and you have the CPU... if you wait for the current blit to finish... how can you possibly be in the middle of another blit operation when you state save?  There's no way to "re-start" the blitter at that point.

http://p_p_e_r_a.07x.net/forum/viewtopic.php?f=4&t=67

Aww look, you made a new friend

(remove the _ from the domain name)

CJ wrote on 09.01.10 at 12:57:39:


Fvcking coward!  The guy is a first class fvcking moron!

@Anemos, since he'll obviously read that

Feel free to say anything you want about me. I couldn't care less!

BTW, why does ppera have a forum?? A blog is more than enough for his needs.

BTW @anemos

If you'd care to give us your IP I can easily block you from downloading from us. After all, your wonderful chum Mr Buggyboy Troll does everything for you now, you have no need for us.

I guess your too dumbfucked in the head to know most of his games don't actually work. Either that, or you are a super intelligent shade of the colour blue and can complete Armor Geddon in under two minutes (despite the fact that 400k of game data is missing)

His account on EAB has now been deleted.

The original thread on EAB has now been deleted, so Pperror has nothing to link to.

The YouTube servers would run out of space if we uploaded all the vids of his fucked up stuff

Seriously boys, fucking annihilate the prick on YouTube, this dick needs taking down!

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! 

Phill wrote on 04.02.10 at 09:32:37:


Who will do so for us Atarians?
Noone needs a harddrive erasing disk imager