HuHaha...

[Petari]

I wanted to see some infos about new Jaguar game, but saw instead some silly ranting:
http://dbug.kicks-ass.net/dbugforums/cgi-bin/yabb2/YaBB.pl?num=1322235856

"And that only because of that hungarian guy together with his followers? A sad day for the Atari community."
Perfectly logical  

"Nope, it's because for years and years people said "why isnt there a HD loader like WHDLoad for the ST" - and then there was, and pretty much nobody else cared.
And *then* it got stolen by that Hungarian dude."

Yes, ULS is something like WHDLoad for Amiga. At least I know so according to some talk with Amiga people. So, CJ says that I stolen ULS.
Isn't ULS offered for everyone, as open source, free to use project, some kind of API for doing hard disk patches ?

Did I posted some sources of my projects like Gamex and GOS ? So, instead writing bullshits and believing what CJ writes, please compare ULS and my game launchers - then will see that whole concepts differ.

Actually, I just wanted to write something about it here, so here are concrete details:

ULS is shortage of Universal Loading System.  And right here we may see something important: it is responsible for loading. Takes care to replace game's floppy loading with hard disk loading. ULS does not much more considering adapting (patching) games for hard disk run. There is snapshot saving/restoring, screen saving, exit to Desktop and it is all. Btw. who to blame that D-Bug self barely used snapshot saving - maybe in some 5-10 games total ?
The problem with ULS is that it is not good for all games - because hard disk run adapting requires more than loading from disk. We have TOS version compatibility problems, TOS function call problems etc. D-Bug just misjudged a lot of things. CJ talked that most of ST games use 'DMA load' what should mean direct floppy controller access instead TOS calls. But it is wrong. My statistic says that 2/3 use TOS calls, and only 1/3 direct FDC access. See : http://atari.8bitchip.info/agcat.html

Basic principle of ULS is RAM swapping - as game and TOS (with hard disk driver) use same RAM area,   we need to solve that conflict somehow. ULS saves TOS workspace to high RAM by game launch. When game needs to load something:  low RAM (where game code is) is swapped with high RAM containing saved TOS and hard disk driver. Then load is performed. After it need to swap RAM again, so game can continue.
This concept has good side that works with most of hard disk drivers, but is slow. Especially slowness is visible when there is a lot of short disk accessings. This is why they still use RAMdisk, despite 'RAMdisk is dead' clinches at ULS3 presentation  

What I did works different:  the concept, principle is that do not RAM swaps, but run hard disk driver in high RAM. And not only driver, but whole TOS, better said GEMDOS part of it. I choosed TOS 1.04 as base - it is well compatible with games and good with hard disks,

So, somewhere in spring of 2009 I disassembled UK TOS 1.04 GEMDOS part, what was lot of work. Then modded it so, that can work in high RAM. It was base for games using TOS calls. The benefits:  no RAM conflict with games running in low RAM, as TOS and hard disk driver are in High RAM. Launch form Desktop is eq. to AUTO run. TOS compatibility problems solved 99%, as game runs under TOS 1.04. So, what here is 'stolen' from ULS, D-Bug patches ?
Later I discovered that GEMDOS part holds code for mouse, Line-A, Blitter and even VDI. Just need to proper init them, what normally happens at AES start. So, I added some initialisataions for mentioned. Games like Millennium 2.2 and lot of other mouse driven work well under any TOS, TT, Falcon. Later I added monochrome support. Almost all Silmarils games work in mono and color mode, and my adapts support both modes. Nothing from it by D-Bug.
Later I did support for games with direct FDC access, so not using TOS for loading from floppy. Base was same - GEMDOS of TOS 1.04. But I needed only filesystem part of it. So, it is stripped down, what was necessary because of goal that it must work together with Gamex on 1MB machines.  Limit if 512MB per partition is result of this, and may be bad only for Falcon users. On TT we have same, 512MB partitition limit.
Here was necessary to mod. several thousands of lines in GEMDOS code.

My concept needs more code, because it must take care about hard disk driver reinstall after game launch. So, different than ULS. I added support for my drivers, normally, and it is best as then no real reload, just moving driver in high RAM (it is fully PC relative coded). With other drivers it is not so good and simple. I added support only for AHDI, as regular Atari driver and Hddriver as most popular. And it took lot of time, while those drivers are not really good for gaming - Timer-C sensibility, lot of RAM usage by Hddriver, complicated settings. slower C code etc.
Btw. geniuses at D-Bug did not even realised how to set Hddrive caches - see thread where they talk that it can not be lowered   I found how to do it in some 15 minutes.  And here we are at relevant point:  their knowledge is very limited. They know 68000 coding, but not well TOS, hard disk related things. 68030 ? Not so good - did not fix EPIC for Falcon. But main thing is that they have no right way for many games using TOS calls.
MFP code: mine is completely different. And I updated it 4 times in last 2 years. Paged MMU code for TT, Falcon - same case.

OK, they spread misinformations, lies, slanters ... But what is really wrong is that people which should take care about correct information about things happening in Atari 'scene' are acting properly. Actually, most of them, forum admins, moderators and Atari related WEBsite maintainers are in some friendly relationship with D-Bug. So, they will take everything said by 'as cache' (as ww say here). Heavy Stylus talked how ULS3 will solve Dungeon Master running from hard disk. I just laughed about it. People just cares not - they want games working on their system. It is understandable, but forget looking on whole thing from side of people working on it. Efficiency of doing hard disk adaptations is completely forgotten, ignored. Feedback - very poor.

Back to WHDLoad for ST question:  I think that we don't have really WHDLoad equivalent for Atari ST serie. Because ST differs in many things from Amiga. OS is different in first place. I'm not sure, but I guess that with Amiga is much less OS version compatibility problem - but I will ask about it in some forum. Another thing is that Atari community is less coherent, and it is thanks to morons like D-Bug and bad forum admins.

D-Bug had his chance - they could improve things, and do some better TOS support, as Klapauzius did (he uses ULS, but has own solutions for TOS dependant games). Instead it, they rather went into some wars with 'competition' and wrote huge bullshits, many-many times. They spit on my Armour-Geddon adapt, while everyone can see how they did it - crippled intro, need for RAMdisk and 2MB RAM (despite RAMdisk is dead) ...
Not to mention that did not fix some reported errors as in Helter Skelter and Future Worlds. And now, I'm the one because who CJ left Atari ST coding. I can say only that he may did it really because of that - after realised that he is not the smartest and that his ULS is not only way, that some others did it better. Doing over 550 games means something, and I learned a lot, and can now do some things really fast. Those who believe D-Bug nonsenses let avoid my stuff - it is not for them and their valuable datas   

[Petari]

I got some informations about hard disk runnabitity of Amiga games:  http://eab.abime.net/showthread.php?t=62128

So, the answer on question about having WHDLoad for Atari ST is little complexer:  2 machines are not same, and you can not port complete WHDLoad to ST, only some parts of it. Concrete:  ST has complete OS in ROM, while Amiga loads part in RAM. This is very important diff.
It means less problems with OS version by Amiga, as can load specific, compatible version.
ULS took only concept of RAM swapping from WHDLoad. And it is good for games not using TOS calls.
Real WHDLoad equ. for ST should care about TOS dependant games too, what D-Bug just 'forgot' .

Conclusion:  ULS is presented as something what finally solves all problems with running ST games from hard drive, with not too much RAM (no need for RAMdisk).  But the reality is:  it is not first solution for it. Over decade ago crew Superior made FFLS system, what had it's limitations, but worked well and fast.

Whole attitude of D-Bug is wrong and immature:  they just know for 'superb' and 'crap'. Nothing inbetween. Only reasonable approach is looking good and bad sides of some SW, solution, and judge what is best for our needs, and what we can do better.
Additionally, they went in somekind of Nazy propaganda, spreading lies and horror stories for small kids - like 'wiping disks', stealing code etc.

OK, enough of them.

I prepare some nice stuff currently:  latest versions of DM and CSB (1.2 and 2.1) with games and strong cheat options. Image with latest hard disk driver-GOS5 solution for smooth loadings, and  some special changes in Steem, for making TT, Falcon fixes of ST SW, games easier. Stay tuned 

[Anemos]

sly hits never stop.
In my country say:hit the trees that make good fruit.
"The unusable trees do not need to hit because they donot produce fruit."
So you look like a good tree that produces many good results.
keep up the good work..im sure "ALL" is happy (or not..) but using "eating" thats "fruits" hehe