First Slave problem

[bippym]

Hey guys :)

I decided to try and do a simle (for you experts) slave for the amiga action coverdisk demo of zonewarrior.

I followed Codetappers excellent tutorial on his site and this game is very similar, simple rob northern trackloader etc.

Well the problem is the patch seems to overwrite the robd loader and the slave fails.

Can someone have a look and give me some advice please

Thanks

(Attached is lzx containing slave, source and disk image)

[Galahad/FLT]

Anything but LZX!!!

[Codetapper]

I'm not sure what the hell Galahad is going on about, LZX is the best and most suitable archiver on the Amiga...

Anyway Bippy first impressions are that it is OK (except it's all space indented not tabs, and has double return characters here!)

The boot operation loads the first part to anywhere in memory, then relocates itself (from offset $56) to $60000, so I would start by loading the game directly into where it wants it so you can skip all that copying junk. Not critical but speeds up the loader ever so slightly!

ie. Load the first file to $60000-$56 (write it like that in code rather than $5ffaa as that's another random looking number) instead of $a4a2 (was that a random value you picked?), then you can skip the copying stuff in the loop at around offset $46.

Your main problem however is you are overwriting jmp ($1d00).w (which is 4 bytes) with a patch (6 bytes) which destroys the first 2 bytes of the Rob Northen loader patch. You've overwritten the $4ef9 jump!

Patch the jmp ($1d00).w at offset $84 instead of $8a since it's just testing for a load failure which will never occur with WHDLoad. If the disk image is broken or corrupt, WHDLoad will just quit, not return from the loader.

That'll get you going a bit further, don't want to spoil the fun so I will stop here! Yell if you need more hints later...

Oh yeah, one more thing, your keyboard patch will not work correctly. $bfec01 contains the raw key code, but you must convert it before comparing with the quit key:

move.b $bfec01,d0
ror.b #1,d0
not.b d0
cmp.b _keyexit(pc),d0
beq _quit

Obviously if you change d0 (as I have done) you will have to put it back to the original value if the user did not press the quit key, or patch the keyboard routine in a different place.

[bippym]

Thanks codetapper :)

That gets me a little further but alas there is another loader to patch it seems :)

I'll get right on it.

[bippym]

Right update:

Made the alterations suggested to get the slave to boot the game, patched the other 2 loaders in the main file but for some reason the fire-button is not recognised.

i'll look into this more, but obviously my asm knowledge is limited but let's see :)

[killergorilla]

Good luck sir :)

And nice work!

[bippym]

Okay I can't find the routine that loads the third load-routine.

[I know where it is in memory ($16670) but for the life of me i can't find the routine that loads or jumps to the file so I can intercept it.

Help please

[Joe Maroni]

damn...bippy...did you try to write a slave before i do ??

:mad

:laughing

[Codetapper]

Bippy: If you are using a real Amiga to patch this should be an easy job as WHDLoad will quit when disk access is attempted if you use the SNOOP functions with an accelerator with MMU built in.

If you are using WinUAE can you not just set a breakpoint in the debugger or alter the RN loader in your slave so once it has loaded that bit it bails out at that point and you can look around?

[bippym]

Well my real amiga is packed away but maybe i should find it out.

As for winuae, i know where the routine is I just don't know where it is called from.. i'm currently following the code thru line by line checking the memory range as i go to see when data starts to appear there.

[bippym]

I think I might have figured it out!

Game jumps to $14F32 which then jumps to the new loader.

Just got to find the routine which loads the data which jumps. Tomorrow now :)

[Retro-Nerd]

Or the more comfortable lzx plugin for the Total Commander.

http://www.ghisler.com/dplugins.htm

[Anubis]

I thought an "elite" such as yourself would know these things!

Every great hero has his weak point.:agree :cheese

Bippy, how about those programs needed to follow instructions? ;)

[bippym]

thread cleaned

[Asman]

Hi

First I agree with Codetapper remarks but ... :). Now my few remarks. Better place for patch jmp $1d00 is offset $84 ( not $8a, now you know why ( magic 6 bytes ) ). Second, please dont jump exactly $1d00. choose other ( like $1d0c or after stupid dummy set intCOPER and intPORTS ($1d20)
I found bug in your patch. In your source you use lea $2446,a0 for patch keyboard, but the correct address is $1d00 + $2446, always remember where you are ( jmp $1d00 mean you are at $1d00:) ). Please check all addresses in source ( i do that now :) ).

You want patch keyboard in PORTS int, better way is find and overwrite place where PORTS int is set ( look in $1d00 + $23d8 :) ).
You can use int PORTS in whdload sources ( keyboard.s ). Another reason for that way is little easy add support to emulate joystick.

Final remark. Remember that game with custom trackloader may be harder to fix then one file game. And don't give up. Every game is possible to fix ( but this may take some time ).

Any comments and question are welcome.

[Boo Boo]

:bowdown

[bippym]

The offsets I use are the offsets that are used in game!

so the $2446 is where in memory the game uses (from offset 0 not 1d00) tho I know it is wrong anyway :D

I cannot figure this out just yet, the third loader is an absolute bitch and my asm knowledge isn't quite there yet!

[Joe Maroni]

Final remark. Remember that game with custom trackloader may be harder to fix then one file game. And don't give up. Every game is possible to fix ( but this may take some time ).

please show us some examples...the only tutorials i know use their own trackloaders.

it would be very helpful to get some easier tutorials...:)

or better a tutorial where nothing needs to be patched...:rolleyes

[Asman]

please show us some examples...the only tutorials i know use their own trackloaders.

it would be very helpful to get some easier tutorials...:)

Ok, I will prepare tutorial for one file games as soon as possible.

Gretz

[Joe Maroni]

wonderful...:great

please write it as understandable as possible for us newbies...:)

[bippym]

quick q

i have the following ingame code (addresses are for demo purposes)

bsr 00005678
bsr 00009123
jmp 4000
<another routine>

now if I put the patch in at jmp4000 it overwrites the start of the next routine by 2 bytes, so am I right in thinking i can put the patch over bsr 00009123 and then put the branch at the end of the patch before the jmp 4000?

[Codetapper]

It depends if it is jmp ($4000).l which is 6 bytes, or jmp ($4000).w which is 4 bytes. If it's 6 bytes you're fine (ie. the opcode is $4ef9) but if it's $4ef8 you have to do something else.

There really are a huge number of ways around the problem, for example if the bsr 0009123 was a loading routine you have patched anyway, you could check if the new bit has loaded at $4000 and if so, patch it automatically at the end of the loading routine.

Or change the bsr 00009123 to jsr into your code, which does a jsr $9123 then patches the game and returns (as you suggested).

Some crackers used to change the jmp $4000 to something like jmp $100 and put a little routine/trainer at $100 which then calls jmp $4000 etc.

Basically whatever is easiest for you and will work generically (ie. check that the same bit of code is not used to load different levels at different places etc as that might cause you problems if the patches are different for each level).

[bippym]

Okay here is the code with offsets

0780A0 LEA 00004000.S,A0
0780A4 LEA 00004000.S,A1
0780A8 BSR 000780B0
0780AC JMP 00004000.S

0780B0 MOVEM.L D0-D7/A0-A6,-(A7)

and here is my/your patch


lea $a8(a5),a0
move.w #$4ef9,(a0)+
pea _Patch(pc)
move.l (sp)+,(a0)+

move.l _expmem(pc),d0

jmp $30(A5) ;Start game



_Patch

lea $9fac,a0 ;Patch Rob Northen loader
move.w #$4ef9,(a0)+
pea _RobNorthenLoader(pc)
move.l (sp)+,(a0)+
bsr 000780B0 ; code we removed
jmp $4000

should that in theory work or should it be a jsr instead of bsr?

[musashi5150]

If you want to run the code at $780b0 it should be a jsr bippy. bra/bsr is only used for code that isn't too far away from the PC. Your patch is most likely in a completely different memory section - so a branch wouldn't work any more.

I can't comment on anything else though because I'm not really paying attention on what you're doing - I'll leave that for Codetapper :)

[StingRay]

Maybe some explanation about bsr vs. jsr makes it easier to understand. Even if you write bsr $78000, it's not an absolute address (as it would be if you do jsr $78000). Instead, what happens is that the distance from current pc to destination is calculated and then used as destination. If you disassemble, you will see that for the jsr $78000 you'll see the $78000 in the opcode while for the bsr you won't. ;) Just play a bit around and do bsr's to different locations and check the opcode, then you'll see how it works. Hope it was somehow understandable. :)

Edit: Just forgot, bsr will only work for a distance of about 32k from current pc (4bytes for the opcode, signed word for the distance)

[bippym]

Slaves have to be PC relative (i think) so I dunno if jsr is gonna work.. only one way to find out ;)

[StingRay]

well, bsr $78000 is done in the original, so jsr $78000 even though absolute jmp is totally ok! :) this jmp doesn't need any relocation, it's plain absolute so no problems using it in your slave. ;)

[bippym]

right it gets further..

I now get a line 1010 emulator exception when i execute.. what is this?

[StingRay]

That means you probably trashed code somewhere, line_f opcodes are used f.e. for fpu instructions. Check the code and see if you made an error somewhere like patching wrong location ect. There can be many reasons. :)

[Codetapper]

In your patch code you seem to be destroying registers. You load up a0 with $9fac then it gets moved forward a few bytes and start the game. Is it possible the game wanted the value that was in a0 left intact and that is causing the crash?

All patches should save all registers on the stack, do the patches, then restore the values and continue the game so it has no idea anything was altered.

Either that or don't use any registers:

move.w #$4ef9,$9fac
pea _RobNorthenLoader(pc)
move.l (sp)+,$9fae

or use one of the macros:

patch $9fac,_RobNorthenLoader

(I don't use that macro so that syntax might be wrong but one of them writes a $4ef9 then the address, check whdmacros.i to confirm)

As StingRay says it's likely a dodgy bit of code has overwritten the wrong location causing the line-f fault to occur. Once the game gets itself into a position where it's using absolute addresses, there's no need for offsets, just hit the addresses you need to change directly. And change that bsr $78000 to a jsr (I'm surprised that would even assemble to be honest). Good luck!

[bippym]

ok i'll take a look :)

[bippym]

I've had some success guys thanks but another problem

The game stores expansion mem at $ffc and then loads data to that location before jumping there.

Now i've used whdload expmem function to put expansionram into d0, then let the game move this to $ffc.

I then take over the code and patch the instruction before JMP (a0) (a0 is loaded with the contents of a0 before the jmp).

In my patch i pit the changed command back

movea.l $00000FFC,a0

I then preserve a0 before letting my routine patch another loader at address a0+$10f80

I then restore a0 and jump to it.


I get the following error: exception illegal instruction ($10) at $10f74000 (expmem $0) occured

[StingRay]

is $ffc used as ptr? or as direct address? there is a big difference between move.l $ffc,a0 and move.l #$ffc,a0 you know. :) That's the only idea I have without knowing the slave/game.

hmm, ffc, that reminds me of something :P

[bippym]

it's a pointer to the loaction of the expansion mem.

In the game it held $c00000 as i'm using kick 1.3 +512kb slowmem

[StingRay]

Hmm, I see. Can you post source of your current slave? :)

Oh, and what happens if you just disable ext. mem in your slave? It might be possible the game ONLY handles ext. mem in the $c00000 area.

[bippym]

sure

[StingRay]

Hmm, as I wrote in the other thread, Barfly generates wrong code for "lea ($10f80,a0),a0" if 020 mode is not enabled (just generates a negative offset...). I actually consider it to be a serious bug in Barfly. Anyway, replace by add.l #$108f0,a0 and check if that works.

[bippym]

yup tried that and it failed too :(
attached is complete source and disk image etc

[StingRay]

Oki, I'll have a look. :)

[bippym]

it compiled if i went with add.l etc

bombed out when running..

[StingRay]

With the same error I suppose?

[bippym]

it wont compile if i use lea so i dunno

I know the expmem address is passed into $FFC and then into a0 a few times before the program jumps to it.

[StingRay]

yes, I just saw that too, have to look around a bit more. :) What I already saw though, the extension memory is allocated using AllocMem and then stored in $ffc.w. But in your slave I don't see that you remove this AllocMem call.

Edit: Another thing I just saw in your slave: in _patch you have:

move.w #$4eb9,$40ba
pea _patch2(pc)
move.l (sp),$40bc

change the last line to move.l (sp)+,$40bc so you won't trash/alter/fuckup the stackpointer!

[bippym]

I jumped past it (jsr $30(a5))

[StingRay]

Where did you do that? can't find it anywhere in the source. :)

Edit: ok, jmp $78030 you do, I see. :) Anyway, correct the stackpointer thingie! :)

[bippym]

line 145 i think

144 - move.l _expmem(pc),d0
145 - jmp $30(a5)

[StingRay]

yeah, except that jmp $30(a5) is jmp $78030 :D at least in the source I have. =)

[bippym]

ah i changed it :p

[StingRay]

Hehehe no worries :D Anyway, I've fixed the stack stuff and now I get the "Line 1010 Emulator" you mentioned earlier. Will check what's causing it now :)

[StingRay]

Hmm, why do you jmp to $780b0 instead of $78000 in your patch? The instruction you replaced was bsr $78000 so I don't see any reason why you don't do jsr $78000 in your patch.

Edit: My fault. :) Forget what I just wrote. :P

[bippym]

forget what ;)

[StingRay]

This:
Hmm, why do you jmp to $780b0 instead of $78000 in your patch? The instruction you replaced was bsr $78000 so I don't see any reason why you don't do jsr $78000 in your patch.


:D Another thing I found though, in _Patch you save a0 on the stack yet, there's no move.l (a7)+,a0 anywhere. :D Doesn't fix the problem but is not correct either. :) Watch your stack. ;)

[bippym]

i fixed that one shortly after..

[StingRay]

Ok, fine. :) I'll check further. :D

Edit: ok, found another nice thing. :) In _Patch you have the patch for the RNC loader at $9fa8. Yet, at the time you patch it, the file has not been decrunched properly yet. Thus you trash crunched data! :) Guess what the routine at $780b0 does? :P So first execute the jsr $780b0 and then do your patch! :)

[bippym]

well i'm getting other errors now, but i know that's cuz i've been messing about.. it's the mem problem that is problem Jmp(a0)

[StingRay]

Well, I got it working :D Read what I wrote correctly! :) I did nothing more than what I wrote. ;) If you do the same, you will at least see the title picture, after that you will get another error from WHD but you should be able to figure out how to fix that one easily. ;)

[bippym]

i get as far as the team17 logo.

what did you mean by fixing the stack?

[StingRay]

Look for: move.w #$4eb9,$40ba
pea _patch2(pc)
move.l (sp),$40bc

It should be (sp)+ in the last line. else (a7) will still contain address of _patch2 when your routine returns. The other one was the move.l a0,-(sp) in _patch2 but you didn't do move.l (sp)+,a0 at the end. :)

[StingRay]

I'll attach my source here so you can have a look :)

[bippym]

right i managed to get it loaded up until patching the next loader :)

It loads if I put disk in, i also know the last loader is at offset $10f80 from start of expmem.

Now to figure this out


Thanks for all your help so-far stingray and to you too codetapper

[StingRay]

no problem. :) for me it works without any disk inserted but I didn't really test very thoroughly. :) But it loads some pictures and then a level of the game. :)

[bippym]

i've not quitw got the 2ndloader patch working properly, it's still looking for the disk when the t17 logo pops up...

[StingRay]

Hmm, weird, for me it works, the only thing I changed was a tiny bit in the rnc loader patch. Check the source I attached, maybe it fixes your problem.

[musashi5150]

Sounds like things are coming together here - nice work guys :)

[bippym]

still not happening here :(

gets to the t17 logo then fails

[StingRay]

Hmm, what error do you get?

[bippym]

it looks for the disk, fails and the screen corrupts

[StingRay]

Hmm, totally strange as it doesn't happen for me. I'll attach the .exe of "my" slave, I'd like to know if you have the same problems with it.

[bippym]

Your assembled slave seems to work fine, and your edited code assembles and works!

I can't for the life of me see what is wrong!

This is weird!

[musashi5150]

Don't get stressed out and just take your time checking the differences.

I had a real headache debugging the decrunch routine for my latest packer... turned out I'd put a sub.w instead of sub.b :)

Take a little break and come back to it - you'll fix it I'm sure.

[killergorilla]

Good to see you persisting bip, and good to see so much interest in this thread. I hope it comes good :)

[bippym]

Had a little progress, though it's now asking for disk.2?!?!?!?!?

[bippym]

Stingray did you change the robloader?

I have changed the addq #1,d2 to a moveq #1,d2 and it works

[StingRay]

Yes I did. :) look what I wrote:

If you do the same, you will at least see the title picture, after that you will get another error from WHD but you should be able to figure out how to fix that one easily.

and here:

Hmm, weird, for me it works, the only thing I changed was a tiny bit in the rnc loader patch. Check the source I attached, maybe it fixes your problem.

:D Check my source and you will see a moveq #1,d2 there as well! :) Nice you got it working now! :) Now try to install another one to get some more experience! :) If you get stuck, you know what to do. ;)

[StingRay]

Don't get stressed out and just take your time checking the differences.

I had a real headache debugging the decrunch routine for my latest packer... turned out I'd put a sub.w instead of sub.b :)

Take a little break and come back to it - you'll fix it I'm sure.

Hehe, reminds me of something that happened to me lately when I was coding while being very tired. I couldn't figure out some weird crash so after a while I just did a jmp $bed :D to continue next day. Then, after some hours of sleep, I immediately saw the problem, I was copying some stuff that was about 120k, I changed the loopcounter and stuff but didn't change the dbf to a subq/bne so I was just copying 65536 bytes. ;)

[bippym]

Well I want to add keyboard quit routine and then add some proper thanks ;), write an installer etc and release it :)

Might be a simple slave, but it is a slave non-the-less :D

Also might train it and add custom tooltypes if i can :)

[StingRay]

Cool, go for it! :) Since the game installs its own Keyboard irq it should be easy to add quit option! :) Adding some trainers would be nice as well. :) Looking forward to your finished install. Good luck! :)

[musashi5150]

dbf to a subq/bne so I was just copying 65536 bytes
I've been guilty of that before ;)

[Joe Maroni]

well done bippy...:great

[bippym]

cheers mate. just gotta find the keyboard routine and patch that.. though it seems to quit now, but i guess that is a debug feature that will be gone if i turn off the whd debugging

[StingRay]

I suppose it's a WHDload feature but I think it's always better to patch things yourself, even if it's just to gain experience. :) I somehow most of the time only trust my very own code so if it bugs I can only blame myself. :) Having to do C++ programming at work and being dependent on some Compilers proved me right to only believe in my code. ;)

[Codetapper]

No, the keyboard quitting relies on WHDLoad intercepting interrupts on a 68020+ Amiga and reading the keyboard. Sometimes this causes problems as it intercepts the keypress and then the game will not allow keys properly. Far better to find the keyboard routine, patch it yourself, and that also means you can have trainers like pressing Help to toggle infinite lives. It also means 68000 Amiga users can quit the games.

[StingRay]

Yes, that's exactly what I thought! :) Thanks for confirming it. :) Even if WHDload would have some "auto keyboard handler" I'd still always patch the keyboard routine in the game/demo just to be on the safe side! :)

[Codetapper]

Note that if WHDLoad reading the keyboard stops the game from processing keys correctly, you need to set WHDLF_NoKbd in the slave flags. It will then be up to you to ensure you can quit the game by patching the keyboard routine.

Real professionals will ensure the keyboard routine can be accessed at any time during the game. Certain sloppy installers (no names, you can probably guess!) force you to quit from only one specific place in the game which is lame!

[bippym]

how do you find the kb routine and any hints on setting the custom tooltypes?

Is there any chance of seeing source for a couple of your older slaves please?

[bippym]

Here is the first version of the slave.

It has only been tested in winuae so can some of you real amiga users please test and report back to me please.

I plan to add the following when I get more experience:


Skip the intro, so game can just start (setting tooltype, or adding firebutton support)
Remove the 2 minute timer (I have already figured out what mem location to change, just need to know how to implement it)
Add weapon trainer
Add the special weapons that the demo has disabledI might just map these to the keyboard as that would be easier to do for me for now.

[StingRay]

Real professionals will ensure the keyboard routine can be accessed at any time during the game. Certain sloppy installers (no names, you can probably guess!) force you to quit from only one specific place in the game which is lame!

I totally agree! Either quit at any time is possible or there shouldn't be any quit option at all.


how do you find the kb routine and any hints on setting the custom tooltypes?

Several possibiliies: Check where $bfec01 is accessed in the game. Or check where $68.w vector is accessed, if the game handles VBR (which is 99% not the case for A500 games), then find out where it gets address of the vbr and accesses vbrptr+$68 later.

[Psygore]

Real professionals will ensure the keyboard routine can be accessed at any time during the game.Real professionals? Who are the fake? :)
Certain sloppy installers (no names, you can probably guess!) force you to quit from only one specific place in the game which is lame!I didn't received your bugreports ;)Several possibiliies: Check where $bfec01 is accessed in the game. Or check where $68.w vector is accessed, if the game handles VBR (which is 99% not the case for A500 games), then find out where it gets address of the vbr and accesses vbrptr+$68 later.The game must not access to the VBR under whdload. If it reads it, you must patch it.

[StingRay]

The game must not access to the VBR under whdload. If it reads it, you must patch it.

Why is it not allowed to read the VBR for the game? I'd like to know the reason for that as I can't think of any that would make sense. When WHD starts the slave, system is running in SuperVisor mode so where is the problem?

[Joe Maroni]

perhaps because the MC 68000 don´t have a VBR :D

and most games are written for the MC68k..???

[StingRay]

I know that there is no VBR on 68000... Still I don't see any reason why it is forbidden to access the VBR when WHD is running. There are games (yes, also games for A500!) that check the CPU version and if it's >68000 they relocate the interrupt vectors using VBR.

[Codetapper]

For all WHDLoad installed games, the VBR is effectively 0. If a game reads the VBR you must make it look like it's at 0.

WHDLoad will know where the real VBR is and use that internally for all of it's black magic, but the game will think all useful zeropage stuff is located from $0-$c0. Otherwise the game will be destroying WHDLoad's own patches!

[StingRay]

Thanks Codetapper, that indeed makes sense. :) Nice to know.

[bippym]

update

tried adding custom stuff, but again probs

source attached if someone can take a peek please :)

[StingRay]

I'll have a look :)

[Psygore]

update

tried adding custom stuff, but again probs

source attached if someone can take a peek please :)

lea _Tags(pc),a0
lea _resload(pc),a1
jsr resload_Control(a1)

move.l a0,(a1) ;save for later use

It should be this:

lea _resload(pc),a1
move.l a0,(a1) ;save for later use
lea _Tags(pc),a0
move.l (_resload,pc),a1
jsr resload_Control(a1)

[bippym]

thanks Psygore :)

I managed to fix it shortly after posting..

[Asman]

Hi,

Note that if WHDLoad reading the keyboard stops the game from processing keys correctly, you need to set WHDLF_NoKbd in the slave flags. It will then be up to you to ensure you can quit the game by patching the keyboard routine.

As I remember with this flag WHDLF_NoKbd my install Lost Vikings don't work properly for some machines ( thanks Mailman for info ). When I delete this flag, then at last Mailman may quit from Lost Vikings. The real reason is not correct fix for keyboard ( you can check this, press many times left and right cursors on numeric keyboard, then you see that viking run to left or right without keyboard hit ). So my install need fix ( but now i know how fix this, use only PORTS int :) ).


Real professionals will ensure the keyboard routine can be accessed at any time during the game.


Agree. I think that proper PORTS int is the best ( with this you can emulate joystick as keyboard - some my not realesed slaves use this ( Emerald Mine, Nibby Nibble ) ).

One simple way for ensure the PORTS int can be always accessed is check places when ints is disables/enables.


Any question or comments are welcome.


Gretz

[Wepl]

Note that if WHDLoad reading the keyboard stops the game from processing keys correctly, you need to set WHDLF_NoKbd in the slave flags. It will then be up to you to ensure you can quit the game by patching the keyboard routine.
I have to correct this.
The flag WHDLF_NoKbd is only needed for games which do not use the int $68 (PORTS) to read the keyboard. There are some games which read the keyboard from the VBI (int $6c) and do not use the int $68 at all. Only for these games is the flag. That means for 98% of the games this flag should not be used. If this flag is used RestartKey, FreezeKey and probably DebugKey will not work.

Background: WHDLoad checks on any interrupt the keyboard. If it thinks there is no keyboard handler active it will acknowledge it (and the game will not see the key then).
It thinks there is no active keyboard handler if the $68 vector is not initialized or the PORTS interrupts are not enabled.

[Codetapper]

Cheers for that correction Wepl!

There are also a few games that have an intro reading the keyboard one way, and the main game using the other. Those games also need the flag set or you cannot quit from one of them. (Most likely a different programmer was involved in creation of the intro and game).

[Galahad/FLT]

Real professionals will ensure the keyboard routine can be accessed at any time during the game. Certain sloppy installers (no names, you can probably guess!) force you to quit from only one specific place in the game which is lame!


Why guess Ian, be a man and name names, no-one likes subterfuge

[bippym]

Here is the finished slave

It is not 100% perfewct with regards the weapon system (read readme) but it does seem to work, and there are 4 of the special weapons available (unlike the pre whdload where only 2 are available).

Wepl is this ok to be released officially?

[Joe Maroni]

anyone like to help me creating my first slave after bippy´s is finished ...???

it uses TRAP exceptions and i don´t know currently how to solve that stuff with whdload...:sad

[Galahad/FLT]

what game?

[Joe Maroni]

Brian The Lion...it seems that its based on TRAPs.....:rolleyes

[Codetapper]

Usually you don't have to worry about traps (if you are meaning the trap #0-#15 stuff) because you just set WHDLF_EmulTrap in the flags and WHDLoad will pass them through to the game to handle.

[StingRay]

Here is the finished slave

It is not 100% perfewct with regards the weapon system (read readme) but it does seem to work, and there are 4 of the special weapons available (unlike the pre whdload where only 2 are available).

Wepl is this ok to be released officially?

I have just tested it on my A4k, unfortunately it doesn't seem to work. Right after the titlepicture a "Line 1111" exception occurs. I'm gonna check where the problem is. :)

Edit: Ok, 'NoCache' did the trick and I could start the game. But I have more bad news: After I pressed fire, an 'Access Fault' occured. (Word Read from $120008)

[Wepl]

Here is the finished slave

It is not 100% perfewct with regards the weapon system (read readme) but it does seem to work, and there are 4 of the special weapons available (unlike the pre whdload where only 2 are available).

Wepl is this ok to be released officially?
I get the same 'Line 1111' exception as StingRay here. This must be fixed first.

Then:
- please use the install script from the latest WHDLoad release
- the directory containing the install stuff should have an icon
- the default tool of installer must be 'Installer' not 'C:Installer'
- the name of the icon should match his type, its a newicon so *.newicon should be used instead of *.inf
- the archive must be lha not lzx
- if the demo is downloadable somewhere it would be nice to include a link in the readme
- if ready please send it to release.at.whdload.de

PS: You may find other installs not matching these criterias, but we want to start with a good one ;)

[bippym]

ok.. it's the actual game that is at fault, adf fails on a4000 too.

Will look into it

[bippym]

can anyone say what the fault may be?

The game needs cache's off for a4000 anyway, but other than that any reason the slave is failing?

[Galahad/FLT]

can anyone say what the fault may be?

The game needs cache's off for a4000 anyway, but other than that any reason the slave is failing?


quite likely a bus error on the A4ooo. Some were fitted with a dodgy Buster chip, both my A4ooo's have this fault. Get Stingray to send you the file whdload log file that records all the registers, and thats your first port of call.

Could be simple enough to clear a high word of a register.

[StingRay]

I'll attach the coredump to this message. Apparently a3 points to $120008 which is definitely wrong. :) So you need to check where a3 should really point to. :)

[bippym]

Wepl: What was your test machine?

Can a member with a 1260 please test this so we can narrow down the problems

Thanks

[Wepl]

bippym: i have a a4k with csppc and 060/50

the first problem does not occure with option NOCACHE
I assume this is a missing flush cache problem
remember the default cache setup by whdload, at start basemem is nc and expmem is full caches (mmu assumed)
any code written to expmem must be followed by a flush cache before executing (several resload function do a flush implicit).
either you fix that or disable caches using resload_SetCACR, installs for release must not use NOCACHE option.

the later access fault is probably harder to fix, looks like ingame bug, try WHDLF_ClearMem, otherwise make a deep analyse what happens there.

[bippym]

It seems the later option is 060 related as i cannot reproduce the problem.

Stingray too had 060 in his a4k