Dogfight Slave....

[killergorilla]

Hi,

I know this is probably going to get a resounding NO, but Is there any chance the dogfight slave could be changed at all?

It currently asks you two questions, both with 4 answers. The first is how much chip ram do you have, and the second is fast ram.

I generally like to include all slave versions in my packs but this means I have to include 16 different versions of this game! :D :help

Is there really a need for that many different options? Can they not be reduced? I mean, who has 1.5MB of chipram anyway? And who uses a 0.5MB chip ram amiga with WHDLoad?

Just a thought, if not, don't worry I'll leave it until last :)

[killergorilla]

Wondering if any of the WHDload guys fancied commenting? :D

[Galahad/FLT]

commenting? Well I think the situation in Iraq needs to change drastically.

[killergorilla]

Wise words. But let's not comment on why or how the problem can be solved :D

[bippym]

why has the author done it this way.. surely memory can be aquired/checked by the slave :/

[Anubis]

Just to make KG's life miserable... :agree

[Galahad/FLT]

Just to make KG's life miserable... :agree

Every waking minute.... :evilgrin

[killergorilla]

I'm miserable in my sleep too because I dream WHDLoad now.

[Galahad/FLT]

I'm miserable in my sleep too because I dream WHDLoad now.

Shit, that is pretty miserable!

[girv]

What does the install script do with the answers to the questions?

[killergorilla]

I don't know off the top of my head, but IIRC there is only one slave file.

I chose a few different options and compared the crc's of the slaves afterwards and they were all different.

[StingRay]

Sounds like the slave author was very lazy if he uses different slaves for different memory configurations. :)

[killergorilla]

Join the WHDLoad team and write a slave update without osemu.400 ;)

[girv]

I chose a few different options and compared the crc's of the slaves afterwards and they were all different.

I guess the script is patching the selected memory requirements into the slave files, since they're hardcoded into the slave header structure.

The slaves may also be identical apart from that: do a binary compare and see if there are any differences in the slaves after the first few tens of bytes. If not, the script is just messing with the amount of memory each slave is requesting.

Fastram can be made automatically optional to the slave (uses it if its there, still works OK if not) with a bit of binary hacking, which would chop down the number of combinations you need to work with.

Do the different memory setups make a difference to the game anyway? Like do you get extra graphics or sound with 1 or 2Mb chipram ? Or does it run faster with fastram ? What does more fastram get you ?

[StingRay]

I guess the script is patching the selected memory requirements into the slave files, since they're hardcoded into the slave header structure.


That's exactly what the install script does. It also removes copy protection that way. I don't see any reason why the slave author did it like this...

[girv]

Sounds like the slave author was very lazy if he uses different slaves for different memory configurations. :)

It's a limitation of WHDLoad, not the slave author. The problem is that the memory requirements are hardcoded into the slave header.

WHDLoad will abort if it can't allocate the memory requested in the slave header, so, for example, if the game is playable on 0.5Mb chip but has extra features for 1Mb chip you need two slaves with these memory configurations coded into their headers. If you do just the 0.5Mb chip slave, 1Mb owners miss out on the extra features. If you do just the 1Mb chip slave, 0.5Mb owners can't run the game.

I had words with Wepl about this many years ago :rolleyes

[StingRay]

Ah ok, thanks for the info. :) Did not know that so I take back all I said about "lazy slave author". :) I totally forgot about the slave header and that the memory configuration is done there. ;) Maybe some "update_header" function in whdload would be nice to have, i.e. you call it once you have changed the memory requirements there and whdload should adapt then. But I don't know how whdload handles the information in the header internally so it might not be possible to add something like this. :) It would be useful though, so go and have a word with wepl again. :D

[StingRay]

Hmm, another idea would be to enlarge the slave header and have something like dc.w OFFSET_TO_MEMCFG_ROUTINE-BASE and if that one is != 0 (i.e. the slave needs/wants to do some custom memory settings), whdload would execute this routine first. That should be perfectly possible to do I think.

[girv]

No probs :)

To avoid this problem, I'd suggested a backwards compatible change to the header structure to define a list of different memory configuration options that WHDLoad could try to allocate in turn. Maybe I'll dig up that old (like, 1998 I think?) email and fire it off again ;)

And by the way...

500TH POST! WOOHOO!

:D

[StingRay]

Congrats for the 500th post :D

I think, it would be more flexible to have whdload execute a custom routine for the memory settings (i use a system like that in my 3d engine and it saved my ass MANY times, specially when I had to add some stuff 5 minutes before a deadline ;D), it's very flexible. I think it might be possible to add that w/o even enlarging the slave header, it would just require some changes in whdload itself. Like, you normally have chipmem_size = $80000 (f.e.) in the header. Now, if that value there is < than the slave size, whd can interprete it as offset to custom routine and execute that one. I don't think, any slave will be 512k in size. :P Anyway, these are just ideas, but flexible memory configuration should be added to whdload in my opinion.

[girv]

Congrats for the 500th post :D
Oh, thanks! How did you know?! ;) :great

I think, it would be more flexible to have whdload execute a custom routine for the memory settings

I guess the routine would need to be told how much chipram and fastram was in the system, then return how much of each it wanted ?

I thought it might be easier for the slave author to just specify different basemem / expmem size combinations with dc.l in a list , using a similar "special value" as you suggested in the current ws_basemem to reference the start of the list. That way, the logic of memory selection can be contained in WHDLoad itself and also WHDLoad can handle any allocation errors etc. and try the next combination. All you need worry about is which memory combinations you need.

but flexible memory configuration should be added to whdload in my opinion.

Let's go see Wepl then :)

[bippym]

500TH POST! WOOHOO!

:D

you must have NO life to acheive 500 posts :p

Congrats roll on the 1k :D

[StingRay]

Oh, thanks! How did you know?! ;) :great


Umm, I really don't know. I just guessed. :D


I guess the routine would need to be told how much chipram and fastram was in the system, then return how much of each it wanted ?


Yep, that's what I had in mind. :) Like, in the case of Dogfight, it would check the available memory and then just return the correct values.


I thought it might be easier for the slave author to just specify different basemem / expmem size combinations with dc.l in a list , using a similar "special value" as you suggested in the current ws_basemem to reference the start of the list. That way, the logic of memory selection can be contained in WHDLoad itself and also WHDLoad can handle any allocation errors etc. and try the next combination. All you need worry about is which memory combinations you need.


Well, of course it's easier for the slave author to have a list where he can choose some memory configurations then. Yet, I totally HATE fixed stuff ;) because sooner or later you will have a game/demo that requires special treatment and that can be easily solved with a custom routine as you are free to do whatever you want then. Like, in my 3d engine I have also pre-defined polyfillers which I use most of the time but often I also need to do something totally different (which I of course didn't plan when I coded the engine) and using my custom routines I can very easily add new polyfillers. That's just an example but I think it's a good one. :)




Let's go see Wepl then :)


Word! :)

[Wepl]

There could be added something to make it possible for the slave to have different basemem setups.
But at least in this example I see it not worth the effort.

I would make one slave which supports all game features. If this slave requires 1 MB chip, then its ok.
Are there really people which use WHDLoad on a machine with 512 kb Chip only?

[StingRay]

Well, while it might be useless in this case, there may be other cases where it will be useful to have! And I think it shouldn't be too hard to add as you have to parse the header anyway. Also, that you think it's not really needed doesn't mean others think the same. ;) So if it's not an insane amount of work, I'd like to see it added. :) I might be naive but all you have to do is a check if memory config is set in the header and if not, call the given routine. Shouldn't need much time. I might be totally wrong though. ;)

[Psygore]

Well, while it might be useless in this case, there may be other cases where it will be useful to have! And I think it shouldn't be too hard to add as you have to parse the header anyway. Also, that you think it's not really needed doesn't mean others think the same. ;) So if it's not an insane amount of work, I'd like to see it added. :) I might be naive but all you have to do is a check if memory config is set in the header and if not, call the given routine. Shouldn't need much time. I might be totally wrong though. ;)I agree with Wepl, it's not really needed :D
Btw, this feature will be only for slaves wich use kick/osemu and they need to be recompiled (some slaves have absolute value for base/expmem).

[StingRay]

I agree with Wepl, it's not really needed :D
Btw, this feature will be only for slaves wich use kick/osemu and they need to be recompiled (some slaves have absolute value for base/expmem).

Assembling the slaves is done in like 2 seconds so I don't see problem here. Also, they don't have to be recompiled as they don't require latest whdload, i.e. new slaves would use the feature, old slaves just wont. And seeing that there are 4 different slaves created for a single game, well, apparently someone could have used the feature of flexible memory allocation. So I am still not convinced that it isn't needed but then again, I won't care much either.

[StingRay]

I would make one slave which supports all game features. If this slave requires 1 MB chip, then its ok.


And this is where I disagree. What about games that are different depending on the available amount of chipram? I remember f.e. one game from back then that had an annoying music if it detected chipram >512k. It didn't have this "feature" with 512k only. Now, if whdload would support flexible memory settings (which I still think is very easy to add), the user could have f.e. a tooltype that sets the chipsize the game will use, one slave, 2 different game versions!
And imho, all that's needed is something like:
; a0: points to start of slave
move.l CUSTOM_MEM_WANTED(a0),d0
beq.b .nothing_to_be_done
move.l d0,a1
jsr (a1)
.nothing_to_be_done

at the very beginning of whdload.

So why not add this for people who might want to use this?

[Galahad/FLT]

And this is where I disagree. What about games that are different depending on the available amount of chipram? I remember f.e. one game from back then that had an annoying music if it detected chipram >512k. It didn't have this "feature" with 512k only. Now, if whdload would support flexible memory settings (which I still think is very easy to add), the user could have f.e. a tooltype that sets the chipsize the game will use, one slave, 2 different game versions!
And imho, all that's needed is something like:
; a0: points to start of slave
move.l CUSTOM_MEM_WANTED(a0),d0
beq.b .nothing_to_be_done
move.l d0,a1
jsr (a1)
.nothing_to_be_done

at the very beginning of whdload.

So why not add this for people who might want to use this?


I think there are so few games that require it as an option, that the effort expended to implement it doesn't warrant the work.

At the moment, the only person inconvenienced at the moment is Killer Gorrilla, and with respect, its not worth the hassle for just one person.

Just my opinion thats all :great

[StingRay]

While I understand that, I don't think implementing a feature like that is a lot of work, so why not? If I am wrong, Wepl should correct me of course! :) If I didn't miss anything obvious, my code posted above should be all that has to be added. :) I like to have features even if I might not use them all the time, I just think it makes coder's life easier (sometimes). ;)

[Galahad/FLT]

While I understand that, I don't think implementing a feature like that is a lot of work, so why not? If I am wrong, Wepl should correct me of course! :) If I didn't miss anything obvious, my code posted above should be all that has to be added. :) I like to have features even if I might not use them all the time, I just think it makes coder's life easier (sometimes). ;)

The slaves have reserved space for future options, and I'm guessing Bert doesn't want to use those up if far better ideas come up in the future.

[StingRay]

Hmm, I'm sorry but that doesn't convince me either. ;D As what I suggested would just occupy 4 additional bytes in the slave header. ;) (would be possible to reduce it to 2 bytes if size REALLY matters). ;)

[musashi5150]

What about if the slave header stays the same as it is now - and you fill in the minimum required options for the slave to run. Then there could be a WHDLoad_AllocMem() function which you can use if you need it...

It could be linked to the CUSTOM tooltypes of the slave to turn it ON/OFF if you "didn't want the shitty music" for example :)

[StingRay]

That approach would of course work but I think that this would require much more effort to implement in whdload. :) (4 bytes added to the slaveheader + a few lines of code vs. complete allocmem function). :) And even if I sound as if I couldn't live w/o that feature, I actually can very well. :) But it's nice to discuss these things! :)

[Codetapper]

I agree with Wepl, Psygore and Galahad. For the 10 (max?) games that have multiple slaves, it's not worth the added complexity. From memory I have done it twice:

I used 2 slaves in Walker - one for speech and one without. The version with speech requires more chip memory, but you are forced to listen to it before each level and cannot skip it, so I always play without the speech!

Mortal Kombat 2 gains extra stuff with 2Mb chip.

Most other slaves that can have optional extras work with fast memory, which is an optional value. You can tell WHDLoad you want 512k but if there is none, it will still continue.

If including 4 versions or 16 or whatever is such a problem, why not just have 2? One for cut-down machines, and one for kick-arse machines?

Also if the only difference is the slave itself, what is the problem with including multiple icons? Is it really such a problem?

[StingRay]

Well, I always hear "added complexity" and stuff here and all kinds of workaround solutions. Now I'd really like to know, what is complex about 4 lines of code plus one additional (long)word in the slave header? I really don't get that. But that might just be me. ;)

[StingRay]

For the 10 (max?) games that have multiple slaves, it's not worth the added complexity. From memory I have done it twice:


10 games that you KNOW OF, that doesn't mean there are no other games needing it! Also, what about demos? No, I'm sorry, that argument doesn't convince me. :)

And for added complexity again, all that you (the people who find this feature useless) would see is one additional dc.l 0 in the slaveheader, nothing more, nothing less! You don't like it/need it? Just ignore it!

[DrBong]

Also if the only difference is the slave itself, what is the problem with including multiple icons? Is it really such a problem?

That would make the most sense for KG's "dilemma" IMHO- just a single Dogfight archive in the pack instead of 16 (which would probably confuse some among the masses). The icons could be clearly labelled to indicate which version is which, and another readme file (if needed) could be appended to the archive to spell it all out for the real WHD novices among the masses. Would also keep the size of the pack down and save bandwidth/download volume too.

What Stingray suggests isn't without merit, but I'm sure Bert has a fair list of yet-to-be-implemented features he'd much rather spend time on. No doubt these features would comparatively have far greater benefit for the user base as a whole too! ;)

[Galahad/FLT]

Well, I always hear "added complexity" and stuff here and all kinds of workaround solutions. Now I'd really like to know, what is complex about 4 lines of code plus one additional (long)word in the slave header? I really don't get that. But that might just be me. ;)


Problem with that is there is limited reserve space in the structure of the slave for Bert to simply add stuff everytime someone suggests it. At the moment, all slave structures are the same, if Bert adds too much, there will come a time when he has to expand the structure size and all of a sudden 4000 installs won't work with WHDLoad but a couple of slaves will.

[StingRay]

Problem with that is there is limited reserve space in the structure of the slave for Bert to simply add stuff everytime someone suggests it. At the moment, all slave structures are the same, if Bert adds too much, there will come a time when he has to expand the structure size and all of a sudden 4000 installs won't work with WHDLoad but a couple of slaves will.

Well, that sounds to me as there won't ever be any additions at all. I mean, 4 (or 2) bytes are really not that much for something that I for myself consider useful. I see what you mean but even if the slave structure has to be enlarged, that does NOT mean that all existing slaves won't work anymore! The headersize can be checked within WHDLOAD, old header detected -> new features disabled/not used. Not much of a problem imho. But as said, I can live w/o that feature as it somehow looks like there is this "oh new feature? nah, better don't touch anything that runs!" mentality here. Years ago we had cars without airbags and they worked well but then someone invented airbags and even though you (hopefully) won't ever use/see them in action there are certain situations where they can be very helpful!

[Codetapper]

10 games that you KNOW OF, that doesn't mean there are no other games needing it! Also, what about demos? No, I'm sorry, that argument doesn't convince me.

Well I've done approximately 1/4 or 1/5 of installs ever made, and I've done it twice. 2 x 5 = 10 installs, a pretty good guess I would think.

From my experience with hacking 300+ games, they all pretty much test for a block of 512k of extra memory, and if found will run and if not, will bail out. There are sod all that require 1Mb of chip and then an optional extra 512k or whatever. I'm sure all the other WHDLoad slave authors will back me up on this.

And for added complexity again, all that you (the people who find this feature useless) would see is one additional dc.l 0 in the slaveheader, nothing more, nothing less! You don't like it/need it? Just ignore it!

Wepl is the one that knows how difficult this would be, he replied earlier in the thread saying it wasn't worth doing for the few installs that need it. Nobody but him knows how complex the code would be with optional chip memory segments etc...

Anyway since I do not play sims (except F-18 Interceptor!) it sounds to me that the Dogfight slave itself is junk, so why doesn't someone just change/fix that rather than going through all the hassle of WHDLoad changes? Wepl's very busy, I'm sure does not want to risk breaking WHDLoad for this kind of feature unless there really is a lot of installs that will benefit from it, and I don't believer there is!

[StingRay]

Well I've done approximately 1/4 or 1/5 of installs ever made, and I've done it twice. 2 x 5 = 10 installs, a pretty good guess I would think.

From my experience with hacking 300+ games, they all pretty much test for a block of 512k of extra memory, and if found will run and if not, will bail out. There are sod all that require 1Mb of chip and then an optional extra 512k or whatever. I'm sure all the other WHDLoad slave authors will back me up on this.


Well, said it before and I'll say it again: What about demos? I know you have done a lot of installs, no question, but you can't know every game/demo.


Wepl is the one that knows how difficult this would be, he replied earlier in the thread saying it wasn't worth doing for the few installs that need it. Nobody but him knows how complex the code would be with optional chip memory segments etc...


I'm sorry, but what is the problem, as said, there is NOTHING complex here! And I posted the code already!

As it is now: chipmem size is defined in the header using dc.l chipmemsize

Flexible allocation: have an additional longword in the header, if it's empty, nothing changes, if it contains a value than that is interpreted as offset to a routine which does nothing more than setting the chipmemsize! So, please, tell me, only Wepl knows how to do this?

Now:
_chipmemsize dc.l $80000 ; fixed, can't be changed at runtime

my approach:
_chipmemsize dc.l 0
_memroutine dc.l offset_to_memcfg_routine ; fills chipmemsize

And that just has to be checked ONCE when the slave is started.

There really is absolutely NOTHING complex here. And even though I am not Wepl I think I can say that as I actually thought about these things before posting them.

[Codetapper]

I'm sure if it was a 1 minute change and was worth doing, Wepl would. I don't believe you have thought it all through though:

- New header files needed
- Extra code to test for WHDLoad 17 specific flags
- Code to handle slaves with bogus values in the new field
- Possible change of tooltypes/prefs file
- Check/adjust all the MMU/memory protection code
- Heavy testing of a selection of slaves to make sure the existing 1000+ slaves still work
- Docs changes for all the languages
- Reissue all the user/dev WHDLoad packages
- Website update (copy into history, other archive into older versions, news item etc)

As you can see, this is no 5 minute fix. And I still think my 10 installs that use it wouldn't be too far off the mark. Demos are just the same as games, they usually want 512k chip, or 512k chip + 512k other mem. In fact I can't think of any demos off hand that even have multiple slaves for different memory configs!

This whole argument is pointless anyway, Wepl is the boss, he said it wasn't worth doing, seems the majority of the WHDLoad guys agree so life goes on.

[StingRay]

I'm sure if it was a 1 minute change and was worth doing, Wepl would. I don't believe you have thought it all through though:

- New header files needed
- Extra code to test for WHDLoad 17 specific flags
- Code to handle slaves with bogus values in the new field
- Possible change of tooltypes/prefs file
- Check/adjust all the MMU/memory protection code
- Heavy testing of a selection of slaves to make sure the existing 1000+ slaves still work
- Docs changes for all the languages
- Reissue all the user/dev WHDLoad packages
- Website update (copy into history, other archive into older versions, news item etc)


Ok, since you seem to know everything better, here is what I have to say:

- New header files needed
Yes, but that I said right from the beginning!

- Check/adjust all the MMU/memory protection code
Why? Totally NOT needed!

- Possible change of tooltypes/prefs file
Why? Totally NOT needed!

- Docs changes for all the languages
Why? I am sure the developers of the slaves all understand english.
And user documentation is not needed for a feature like that!

- Heavy testing of a selection of slaves to make sure the existing 1000+ slaves still work
- Website update (copy into history, other archive into older versions, news item etc)
- Reissue all the user/dev WHDLoad packages
Would have to be done for other changes too so it's irrelevant!


And I still think my 10 installs that use it wouldn't be too far off the mark. Demos are just the same as games, they usually want 512k chip, or 512k chip + 512k other mem. In fact I can't think of any demos off hand that even have multiple slaves for different memory configs!

Ok, I take it you have seen every demo, resourced all of them and know how they all work. You have my respect for that!


This whole argument is pointless anyway, Wepl is the boss, he said it wasn't worth doing, seems the majority of the WHDLoad guys agree so life goes on.

As said, I can live w/o that feature. But your reasons why it's not worth to have are just as pointless as this argument then. Also I DO know that this is not a "high priority" feature and Wepl most probably works on more important fixes/changes. However, that doesn't automatically mean this feature is useless!

[Psygore]

Well, said it before and I'll say it again: What about demos? I know you have done a lot of installs, no question, but you can't know every game/demo.I've done only 2/3 game' slaves which use extra chipmem. Demo which extra sound/gfx? never seen one :p
As said, I can live w/o that feature. But your reasons why it's not worth to have are just as pointless as this argument then. Also I DO know that this is not a "high priority" feature and Wepl most probably works on more important fixes/changes. However, that doesn't automatically mean this feature is useless!No, it automatically means that is useless if none of whd author will include it. :nuts

[Wepl]

And this is where I disagree. What about games that are different depending on the available amount of chipram? I remember f.e. one game from back then that had an annoying music if it detected chipram >512k. It didn't have this "feature" with 512k only. Now, if whdload would support flexible memory settings (which I still think is very easy to add), the user could have f.e. a tooltype that sets the chipsize the game will use, one slave, 2 different game versions!
This is already possible using current specs. Just give the Slave the max required chip mem and then use custom tooltype to select if the installed games sees all mem or only 512k. It wastes some memory in the latter case but if its below 1mb its acceptible IMHO.

And imho, all that's needed is something like:
; a0: points to start of slave
move.l CUSTOM_MEM_WANTED(a0),d0
beq.b .nothing_to_be_done
move.l d0,a1
jsr (a1)
.nothing_to_be_done

at the very beginning of whdload.

All inits must be done before the Slave is called. But it doesnt make sense anyway to discuss technical details here. Because I said its possible but not worth the effort in my opinion.

So why not add this for people who might want to use this?
Did you ever wrote a Slave? Sorry, I dont remeber...

[Codetapper]

Even if this feature was added to WHDLoad, I would not modify my existing installs. I think it's easier for the user to double click the correct icon to choose whether they want speech in Walker and Mortal Kombat 2 respectively.

Stingray: If Dogfight is so important as to warrant WHDLoad changes, why don't you make a single slave without the 16 versions or whatever it is? Maybe Dr Zarkov didn't know how much memory the game required exactly so just put all these questions when in reality it's probably a standard 1Mb game.

[killergorilla]

Maybe I should have just kept my mouth shut....

:crazy

[girv]

Wow, what a lot of discussion!

I guess this is academic as Wepl doesn't think it's worth the effort to implement anyway, but I have to comment. "You are all entitled to my opinion" in other words ;) :D :)

Firstly, Stingray and I were proposing different things I think. My suggestion was a way for the slave author to specify a list of choices of base/expmem configurations for WHDLoad to try to get at startup time. Instead of trying just the single config, it would try multiple ones in order of preference and fill in the header base/expmem fields with the first one that was successful. After that WHDLoad would continue as if the slave had been hardcoded with that configuration from the outset, so what's the big scary risk? It wouldn't need an extension to the slave header and I still don't see how it would need recompilation or retesting of existing slaves, alteration of the MMU code etc. Sure, it would need a documentation / web update, but it could have been released along with any WHDLoad point release when these things would have been done anyway.

Secondly, IIRC this was proposed a looong time ago, before the optional expmem allocation was added to WHDLoad (I think that may have resulted from the discussion, but it was a long time ago and I don't recall exactly). But now that optional expmem allocation has been around for a long time, how difficult, risky or non-backwardly-compatible would it be really to add a form of optional basemem allocation as well in a similar manner? That's a rehtorical question really, but I don't understand what everyone is so worried about :confused :banghead

[Codetapper]

Girv: What actual benefit will you gain from what you have suggested?

If a game works with 512k chip and 512k other mem, the slave will have that memory config set in the slave anyway. If it needs 1Mb chip, it will have that as the requirement.

Nobody has been able to name any software that will benefit from any of these changes therefore the whole argument is pointless. You could add hundreds of optional features to WHDLoad that will never be used by anyone, but what's the point? It'd be used about as much as a tooltype that forces you to click the left mouse button 50 times between loading each file.

Psygore (the demo master) hasn't noticed any demos that will benefit from this, and the handful of games we have identified work perfectly fine with a couple of icons so why bother? If someone rewrote the Dogfight slave correctly I'm sure it would only need a single slave anyway, rendering this thread useless!

Also I fail to see how you can implement all this multiple memory configs stuff without expanding the header or using up the reserved longword. How would you ask for 512k chip + 1Mb fast, or 1Mb chip and 512k fast mem without further fields?

[girv]

If a game works with 512k chip and 512k other mem, the slave will have that memory config set in the slave anyway. If it needs 1Mb chip, it will have that as the requirement.
...and if it works with 512k chip but is better with 1Mb or 2Mb ? Off the top of my head, Uridium 2 and Paradroid '90 benefit from extra chipram with new graphics and more music, and you have given other examples yourself.

Nobody has been able to name any software that will benefit from any of these changes therefore the whole argument is pointless.
You mean like Walker, MK2, Paradroid'90, Uridium 2 ?

The benefit is to do away with multiple slaves for alternate memory configurations, and the associated build and install script complexities. IMHO it's more elegant and less error prone to have this ability centralised in WHDLoad itself.

the handful of games we have identified work perfectly fine with a couple of icons so why bother?
They work perfectly fine because the author has built two or more almost identical slaves, asked the user which one to use and picked or created the correct version on the fly. A flexible memory config built into the slave would avoid all that, so why bother with all that other stuff? It's an improvement. It makes install packages smaller and easier to create and maintain. That's why bother.

Also I fail to see how you can implement all this multiple memory configs stuff without expanding the header or using up the reserved longword. How would you ask for 512k chip + 1Mb fast, or 1Mb chip and 512k fast mem without further fields?

IIRC I suggested using "special values" for ws_expmem that would be interpreted as an offset to a memory preference table in the slave code => backwards compatible and no change in the header. Remember: IIRC this was before expmem could be specified as optional. It probably isn't compatible with that change, but I still believe it would have been an improvement over the "all or nothing" approach to the optional expmem allocation we have now.

There's also a few obsolete fields in the header as well, aren't there (not sarcasm, I can't look up the headers right now)? The new slave would break on old WHDLoads, but you'd have set the required version to higher than that anyway.

But, working within the current header, what I'd maybe propose is to define some flags as special values for ws_basemem to identify which sizes of basemem the slave can utilise: 0.5, 1.0 or 2.0Mb (are there any others?) WHDLoad would try to allocate the sizes specified in decreasing size order and then store the actual size allocated back into ws_basemem for your slave code (and the rest of WHDLoad) to use.

eg:
WHDLMEM_BASE512: equ 1
WHDLMEM_BASE1024: equ 2
WHDLMEM_BASE2048: equ 4

OR these together as required. 1-7 are not valid basemem sizes so this style of usage can be easily and robustly detected. It's not as flexible as specifying the exact basemem size you require, but do you ever specify anything other than 0.5, 1.0 or 2.0Mb ? And by your own argument this would only be used by a small number of installs in any case.

Another, possibly simpler suggestion is using a negative basemem value to specify the -maximum size the slave can use. WHDLoad would allocate 0.5, 1.0 or 2.0Mb depending on the requested size and the available memory. A problem is you could get the situation where you need 1.0 or 2.0Mb, ask for 2.0Mb-max but only get 0.5Mb. The slave would have to check for this and bug out if it didnt get its minimum requirement, but how hard is that? cmp.l #512k, ble fail ? On a subset of a subset of slaves? Cripes, I need a lie down now.

I can't believe this would be a complex change to WHDLoad either. Check a few flags at startup, calculate and store the basemem value and proceed as normal. What am I missing? As for the slave authors, are you saying that changing a single dc.l in the header is more complex than building, distributing and installing multiple slaves? I know which I'd rather do.

These are hacks and it would be cleaner to bump to v17 and extend the header with an offset to a "ws_memconfig" choice table or something. As you say it's probably not worth bumping just for this, but what's the harm in including it if/when v17 comes anyway ?

I don't think its a useless feature at all. I think it's an improvement, useful and worth the small effort I imagine it would take to implement. The only arguments against I'm hearing is that you don't like the speech in Walker (so code a skip-on-fire!) and mainly "it's too much bother". Well OK fair enough, that's Wepl's call. I respect your opinions, but I disagree. It's not the first time. Doesn't mean we all can't still be friends though ;) :) :D

[StingRay]

All inits must be done before the Slave is called. But it doesnt make sense anyway to discuss technical details here. Because I said its possible but not worth the effort in my opinion.


I know that! What I meant was that you read out the chipmemsize value in whdload before the slave is started. So I don't see why it's so hard to read one more variable, i.e. the ptr to the custom routine and execute that. After all, you must have some ptr to the slave header within whdload anyway, that's all I meant!

Did you ever wrote a Slave? Sorry, I dont remeber...
For WHDLoad, no, at least no released one. But I have fixed countless demos and have made my WHDLoad like patching system as well (which I don't use these days anymore though), so if your question was if I know about patching/fixing, yes, I definitely do. And I might do some whd slaves in the future, most probably for demos only. :) And if it was meant as a "you never coded a slave, you have no clue" well, then I better don't comment that!
Edit: you might want to check out this thread http://eab.abime.net/showthread.php?t=28148 just in case you still think "no slave released, no clue"...

[StingRay]

Stingray: If Dogfight is so important as to warrant WHDLoad changes, why don't you make a single slave without the 16 versions or whatever it is? Maybe Dr Zarkov didn't know how much memory the game required exactly so just put all these questions when in reality it's probably a standard 1Mb game.

I might have a look! :) Also please note that I don't consider this feature utterly important (as said), I just thought it would/could be nice to have. I won't die if it won't ever be implemented as that's Bert's decision like you already said. :)

[StingRay]

I've done only 2/3 game' slaves which use extra chipmem. Demo which extra sound/gfx? never seen one :p


Then check certain Sanity demos...


No, it automatically means that is useless if none of whd author will include it. :nuts

That still doesn't necessarily mean it's useless. It's a non-implemented feature then, nothing more nothing less. ;)

[StingRay]

The benefit is to do away with multiple slaves for alternate memory configurations, and the associated build and install script complexities. IMHO it's more elegant and less error prone to have this ability centralised in WHDLoad itself.


They work perfectly fine because the author has built two or more almost identical slaves, asked the user which one to use and picked or created the correct version on the fly. A flexible memory config built into the slave would avoid all that, so why bother with all that other stuff? It's an improvement. It makes install packages smaller and easier to create and maintain. That's why bother.


That's exactly what I think and the reason why I suggested to add flexible memory config. :great At least someone shares my ideas. :cool I thought it, you said it! :great

[Codetapper]

You mean like Walker, MK2, Paradroid'90, Uridium 2 ?

I was hassled by Stingray for guessing 10 slaves might benefit out of about 1300, and we have come up with a definite list of 4. 6 if Psygore could remember his 2.

The no-speech version of Walker is much smarter than you are giving credit for anyway, as the no-speech version deliberately sets all the speech files as not needing to be buffered which speeds up loading etc. The slaves are certainly not identical. And as for the complexity of maintaining 2 files, only one source file builds both slaves anyway! Don't tell me you have multiple source files for the 2 games you have identified?

This whole issue is a bit like an install script upgrade. You can put all the extra features in that you wish, but nobody is going to go back and redo existing installs that work perfectly fine in their current form!

[StingRay]

Update: I've disassembled the Dogfight slave now and it seems as if Dr.Zarkov tried to use the "CUSTOM" tooltypes to set basememsize+extmemsize (CUSTOM4/5). At least there are (unused) parts in the code that look very much like he tried to do that. Will resource the game now and check if it makes use of extended mem.

[StingRay]

I was hassled by Stingray for guessing 10 slaves might benefit out of about 1300, and we have come up with a definite list of 4. 6 if Psygore could remember his 2.


I didn't hassle anyone! I just pointed out what I think, that has nothing to do with hassling. You are always entitled to have your own opinion!


And as for the complexity of maintaining 2 files, only one source file builds both slaves anyway! Don't tell me you have multiple source files for the 2 games you have identified?


I have to comment on this as you contradict yourself here. You say added complexity to whdload is bad but it's ok to have install scripts that are more complex than they need to be?

[StingRay]

I've updated the slave now, turns out Codetapper was right! As far as I could see the game just needs ~256k chip ram and makes use of extended mem if it's available. The slave now requires $80000 bytes basemem and $80000 bytes extended mem. The slave now also removes the copyprotection so that it won't be necessary to modify the gamefile during installation. I also added that the slave first checks for OSEmu400 in the game datadir and if it's not available there it tries to load C:OSEmu400. This way it's possible to use a special version of OSEmu only for that very game as I heard there are several buggy versions around. Unused code has been removed as well. Slave attached to this post, can you please test it, Killergorilla? If it works, I'll create an updated installer script which can then be uploaded to the whdload site.

[Psygore]

Then check certain Sanity demos...They didn't.

[Wepl]

...and if it works with 512k chip but is better with 1Mb or 2Mb ? Off the top of my head, Uridium 2 and Paradroid '90 benefit from extra chipram with new graphics and more music, and you have given other examples yourself.
I would never release a 512k slave then. Release the 1mb slave and we dont need any changes.
This is no argument.
They work perfectly fine because the author has built two or more almost identical slaves, asked the user which one to use and picked or created the correct version on the fly. A flexible memory config built into the slave would avoid all that, so why bother with all that other stuff? It's an improvement. It makes install packages smaller and easier to create and maintain. That's why bother.
which games? still no examples.....:sleep
For WHDLoad, no, at least no released one. But I have fixed countless demos and have made my WHDLoad like patching system as well (which I don't use these days anymore though), so if your question was if I know about patching/fixing, yes, I definitely do. And I might do some whd slaves in the future, most probably for demos only. :) And if it was meant as a "you never coded a slave, you have no clue" well, then I better don't comment that!
Edit: you might want to check out this thread http://eab.abime.net/showthread.php?t=28148 just in case you still think "no slave released, no clue"...
I'm sure you have the capabilities. But you must understand that your opinion has much less weight for me then others which made plenty of installs.
I've updated the slave now, turns out Codetapper was right! As far as I could see the game just needs ~256k chip ram and makes use of extended mem if it's available. The slave now requires $80000 bytes basemem and $80000 bytes extended mem. The slave now also removes the copyprotection so that it won't be necessary to modify the gamefile during installation. I also added that the slave first checks for OSEmu400 in the game datadir and if it's not available there it tries to load C:OSEmu400. This way it's possible to use a special version of OSEmu only for that very game as I heard there are several buggy versions around. Unused code has been removed as well. Slave attached to this post, can you please test it, Killergorilla? If it works, I'll create an updated installer script which can then be uploaded to the whdload site.
If its ready and tested please send me install package. Please make sure that a actual install script from the whd-dev package is used. I would be happy to release it. :)

PS: if possible avoid osemu, use kickemu instead

[girv]

I would never release a 512k slave then. Release the 1mb slave and we dont need any changes.

Why would you not release the 512k slave?
which games? still no examples.....:sleep

I gave examples! You just decided those games only needed one version!

[Wepl]

Why would you not release the 512k slave?

Because I think there is no need to support 512 KB Chip only machines. I think 1 MB Chip can be expected for running WHDLoad. All machines with Kick 2.0+ had 1 MB Chip or more.

[girv]

Because I think there is no need to support 512 KB Chip only machines. I think 1 MB Chip can be expected for running WHDLoad. All machines with Kick 2.0+ had 1 MB Chip or more.

My A500 fitted a with 1.3 / 2.04 kickstart switcher didn't ;) But if you say 1Mb chip is the minimum for WHDLoad, then fair enough.