WinUAE/Real Hardware Memory Differences

[mcgeezer]

Hi all,

So I have a situation where I have an ADF of my game which works in a base 1200 config on WinUAE but does not on Real Hardware (base config).

I was having a chat with @alpine9000 and he mentioned that WinUAE would always seem to clear/zero any declared bytes (ds.b/ds.w/ds.l) and a real Amiga would not necessarily do this so I'm wondering if this could be part of the problem? Even looking into my code I can see some instances of where I'm not initializing enough bytes in some of these arrays... but is the theory correct?

Another quick question... is it work me nulling each block of allocated memory before I occupy it... I guess is could be in there too.

On the stock winuae I even have enforcer running but it isn't popping up with anything (where normally it would in these situations).

Any help is appreciated.

Geezer

[meynaf]

Data declared as DS directives is guaranteed to be zero except in code-bss or data-bss sections (= code/data sections with bss at the end).
You don't need to clear allocated data by hand, AllocMem will do that for you if you pass in the relevant flag.

Under winuae the situation isn't very different. Only thing, memory is normally zeroed upon startup. But don't count on it, as it's no longer zero as soon as some program has used it (even if a reboot occurs).
Enforcer detects completely illegal accesses, not accesses to uninitialized memory.

[Toni Wilen]

RAM chips at power up contain partially random bit patterns (depends on internal row/column details so it can depend on size and manufacturer etc..). I don't have enough information to emulate it properly. It is not simply random.

Assuming it is dos loaded executable, you can try this: http://eab.abime.net/showthread.php?t=91321 It detects many kinds of invalid accesses that enforcer and similar utilities can't.

[zero]

I'd have thought it's more likely to be something like a slightly different version of Kickstart than the random contents of memory causing your code to work.

[nogginthenog]

Run Mungwall on your real Amiga. It fills ram with data. Using it with enforcer is even better.

http://www.memphisamigagroup.net/dis...l/MungWall.doc

[ross]

Do a little program, the first on s-s, that allocate all the RAM (using the clear flag).
Release the memory.

Launch Rygar.
If there is no more a crash then is the pseudo-random pattern on RAM of a real machine (a memory leak somewhere in your code that read a "bad" value for a variable).

[mcgeezer]

Thanks for responses all... @Toni I will certainly look at the UAEDBG tool...looks excellent.

I've managed to fix this, I recreated the ADF for starters and changed two things... the first was that I was using add21k instead of add44k for AGA, but I also added a tool called 'Memclear' which zero'd out all of the ram.

Probably still have an issue in the code somewhere but at least it is mostly fixed.

[ross]

Originally Posted by mcgeezer

... the first was that I was using add21k instead of add44k for AGA

I really never advised you my "addchip" bootblock? I have to be really distracted

Reliable, can be used instead of all addxxk commands and also recovers the memory allocated for external drives.

['Memclear' is exactly what I mean ]

[mcgeezer]

Originally Posted by ross

I really never advised you my "addchip" bootblock? I have to be really distracted

Reliable, can be used instead of all addxxk commands and also recovers the memory allocated for external drives.

['Memclear' is exactly what I mean ]

I think you might have recommended that at some point but if i recall I couldn't compile it but as well, I didn't (and still don't) have an easy way of writing the boot block.

[ross]

Originally Posted by mcgeezer

I think you might have recommended that at some point but if i recall I couldn't compile it but as well, I didn't (and still don't) have an easy way of writing the boot block.

No more glitch over CLI screen on startup.

The bootblock can be expanded to cover MemClear function.

[Removed: use official Rygar release ]

[phx]

Originally Posted by mcgeezer

I didn't (and still don't) have an easy way of writing the boot block.

Probably because you don't build the complete ADF image with a custom trackloader, but just an executable file which has to be loaded from an AmigaDOS file system?

If you don't want a trackloader (which is what I pefer for simplicity and efficiency) you might further automatize (is this a legal english word?) the process by including some open source ADF tools into your project, which can write files to OFS/FFS formatted images.

I do not remember what the best tools were. Maybe something like http://lclevy.free.fr/adflib/ or http://lallafa.de/blog/amiga-projects/amitools/xdftool/ ?

With an ADF image automatically built you could easily attach your custom boot block as well.

[roondar]

There are a few bootblock tools on Aminet as well (though not all of them generate a correct checksum ). IIRC, http://aminet.net/package/disk/moni/BB20 works well, as does http://aminet.net/package/disk/misc/BootWriter

However, I'm not at my development PC right now and I recall trying several before I found one that worked so it is possible I'm misremembering which one I ended up using before I started using PHX's disk image writing tool and skipping on the OS altogether.

[Hewitson]

Originally Posted by phx

automatize (is this a legal english word?)

Automate