Little Computer People IPF problem

Hello. I was doing some research on Little Computer People and I decided to give the Amiga version a try. My understanding is that using an IPF is better than using an ADF since the IPF is verified to be dumped properly and completely. However, I have encountered a problem with the IPF that I don't have with an ADF copy that I found. Primarily, my little computer person on the IPF version is invisible I can hear his footsteps moving about the house, but I can't see him anywhere. When I run the ADF version, I can see the person moving about. I have verified this problem on both the latest E-UAE on Ubuntu and WinUAE on XP, since I thought maybe it was an issue with the linux version of UAE. Can anyone shed some light on this issue? I would appreciate it. Thank you very much.

Procyon

[davideo]

LCP needs a standard setup without fastram.

Have you tried a quick start with a standard A500 setup?

Dave G

[Interceptor]

yup, you need to disable fast ram, the default quickstart config for a500 has fast ram, but you can change one of the drop down boxes and disable it.

or just use the A500+ quickstart option.

the ADF file probably has the workbench utility 'NoFastRam' added to its startup sequence, or the code itself has been changed.

you'll also notice if fast ram is present the sounds are mixed up.

interestng game though: http://www.softpres.org/article:game...omputer_people

Thank you very much for your help, I really appreciate the suggestions. I believe that I followed them, but it does not appear to have worked. I have it set to A500, Kick 1.3, Chip RAM 512 kB, Slow RAM 512 kB, Fast RAM None. Not sure what else I can try. If someone has actually gotten the IPF version to work, please let me know what configuration you used. Until then, I'll just work with the ADF.

[Retro-Nerd]

Try 512KB Chip Ram only, no Slow Ram/Fast Ram.

Hi Retro-Nerd, thank you very much, your suggestion worked. It's very interesting, I'm a long time computer person with a BSE in Computer Science, but I'm a bit of an Amiga newbie. I'm puzzled as to how the presence of so-called Slow RAM and Fast RAM have such a dramatic impact on the performance of such a program. These days, we would load the sprite of the little computer person (and his dog) in VRAM, but I suppose there was no such designation on the Amiga. So I wonder what it is about those optional RAM settings that cause abnormal behavior for this program. It's probably a discussion for another forum. I greatly appreciate the help. My little computer person has entertained me with a few ballads on the piano so far.

Procyon

[Interceptor]

i beleive there is no such thing as 'slow ram', its just what winuae calls the trap door expansion ram. they call it slow ram as although its fast ram in nature, its still contented and speed wise isnt actually 'fast' at all.

the amiga still calls it fast ram.

'fast ram' is something that the graphics and sound hardware doesnt have access too, what this game does bythe looks of things is assumes that all ram is 'chip ram' and the graphics and sound is kept there for access. but when the game runs, some graphics cant be used as the chipset cant access them.

i.e crappy programming.

the basic A500+ configuration (which you didnt try) only has chip mem, and is probably the easiest way to run LCP on winuae.

[dlfrsilver]

also let the IPF writes enabled, in order to get saved your little guy. This game automodifies itself.....

[mr.vince]

Originally Posted by Interceptor

i beleive there is no such thing as 'slow ram', its just what winuae calls the trap door expansion ram. they call it slow ram as although its fast ram in nature, its still contented and speed wise isnt actually 'fast' at all.

the amiga still calls it fast ram.

'fast ram' is something that the graphics and sound hardware doesnt have access too, what this game does bythe looks of things is assumes that all ram is 'chip ram' and the graphics and sound is kept there for access. but when the game runs, some graphics cant be used as the chipset cant access them.

i.e crappy programming.

the basic A500+ configuration (which you didnt try) only has chip mem, and is probably the easiest way to run LCP on winuae.

i think you can best desribe slow ram as fast ram with chip ram restrictions. it can only be accessed by the cpu but at the speed of chip ram (if i remember right it was to wait until the bus is ready).

i have not tried but if the memory allocation is "static" by having dc.b in the program code (which i remember as a DO NOT DO THIS!), one might be able to patch the executable by changing the hunk type (my memor is not very exact in regard to wording, but i think everybody knows what i mean). another solution i can think of is adding a special boot block (from memory the game is a standard dos disk with a protection track somewhere, mybe track 0 side 1) which disables fast ram. this might at least be handy for a real world amiga...

i really liked this game!

[StingRay]

Originally Posted by mr.vince

i have not tried but if the memory allocation is "static" by having dc.b in the program code (which i remember as a DO NOT DO THIS!)

It would be ds.b and there's nothing wrong with that approach.

Originally Posted by Interceptor

the basic A500+ configuration (which you didnt try) only has chip mem, and is probably the easiest way to run LCP on winuae.

Hi Interceptor. I should have elaborated on my efforts. I did in fact try the A500+ configuration on WinUAE, and got the correct behavior. However, as I am still getting familiar with E-UAE, which seems to be missing many GUI controls for most of the settings, I am unsure of how to instruct E-UAE to run in A500+ mode, or even if E-UAE is capable of using configurations at all. I'm sure if I dig around for a FAQ, I will find my answer, but as I have been able to successfully achieve my desired result in both WinUAE with the A500+ config, and E-UAE by disabling Fast and Slow RAM, I have not been thoroughly motivated to find the answers to my questions yet. Thank you for the suggestion though.

Procyon

Well, the fruits of my labor are complete. Please have a look at http://strategywiki.org/wiki/Little_Computer_People if you are at all interested. Feel free to make any corrections if I made a mistake somewhere. By the way, there is a dearth of Amiga game coverage on StrategyWiki, so if any of you are interested in covering some of your favorite neglected Amiga games, they would be a welcome addition to the site. Thanks again for everyone's help.

[mr.vince]

Originally Posted by StingRay

It would be ds.b and there's nothing wrong with that approach.

...well unless you make sure it gets loaded into the right type of memory... or does ds.b automatically get loaded into chip? I think this can easily be declared with just one or two commands.

And I am still sure that some programming guide back then had some good reasons for allocating memory at runtime and not including it as a static placeholder in the executable. Could have been to preserve disk space, if I remember right. This is of course only true for memory that is used for calculations etc., storing sprites will take the same amount of disk space if stored in a separate file, maybe even more because of the file handle.

[StingRay]

Originally Posted by mr.vince

...well unless you make sure it gets loaded into the right type of memory... or does ds.b automatically get loaded into chip? I think this can easily be declared with just one or two commands.

Simple Section,BSS_c does the trick.

Originally Posted by mr.vince

And I am still sure that some programming guide back then had some good reasons for allocating memory at runtime and not including it as a static placeholder in the executable.

That doesn't mean that reserving memory using ds.b is a "DO NOT DO THIS!" like you claimed. I prefer correct information instead of this "I read it somewhere" stuff. I doubt you ever coded anything. I could also give you good reasons to use ds.x instead of AllocMem, yet, I won't say using AllocMem is a "DO NOT DO THIS!". Anyway, if you use ds.x in a BSS section it won't take any space in the executable, only the hunk header will be slightly larger.

[Toni Wilen]

I wouldn't suggest using non-KS1.x configuration for A1000/A500 era game.. especially when there is A500 + 0.5M chip quickstart configuration..

(and StingRay is 100% right about ds.x. It is much easier to use if memory "allocation" size is static)

[mr.vince]

Stingray, it's good to have someone who is always more precise and points things out. I worked at a company that had to learn the hard way that direct hardware programming (and several other things) made support for new hardware pita. So please forgive me if my "I remember..." (combined with capital letters) gave anyone the false impression that this was a major mistake to be avoided by any means.

I still stand the point that for system-friendly programming a program has more choices to react if the memory is allocated at runtime (which does not make it faster for sure - which is mostly irrelevant on modern architectures). But this is obviously was modern software architecture thinking applied to the Amiga, where a "more direct" / different approach makes sense in regard to speed and other things.

But please enlighten me: Can ds.x be used for binaries that are loaded via a trackloader without making use of the system? My assumption would be that for the hunks to be "executed" one would need to have (at least some part) of the system structures running? I am just assuming this because there is no real block of data reserved in the binary for this (guessing again, but if it does not take disk space). And I do remember code that actually used dc.b to store something initially and then move.b or move.l something else there...

BTW: It might make sense to move this to the programming section.

[IFW]

If not using AmigaDOS you need to write your own loader that can handle all hunk types - our games did exactly that.
ADOS will handle that otherwise at load time.

[StingRay]

Originally Posted by mr.vince

But please enlighten me: Can ds.x be used for binaries that are loaded via a trackloader without making use of the system? My assumption would be that for the hunks to be "executed" one would need to have (at least some part) of the system structures running?

This is possible. All you have to do is coding a relocator to "emulate" what AmigaDOS does, i.e. you'd have to allocate memory (or just use fixed addresses if the system is totally killed) and use the info in the RELOC32 hunks to relocate to that address. It's perfectly possible and has been done in several demos/games.

And I do remember code that actually used dc.b to store something initially and then move.b or move.l something else there...

Not sure what you mean here but I suppose you saw something like dcb.b which is (almost) the same as ds.b

Edit: posted at the same time as IFW.

[mr.vince]

Ok, that's what I assumed... you "parse" the hunks and do what the system would have done.

Btw: Doesn't PowerPacker have a HunkLab...? If I remember right the budget release of LCP has no on disk protection, so maybe the binary executable can be patched to force it into chipram...

[IFW]

Yes, afair PP had that.