Silkcut/TBL

[Bobic]

Hello,

has anyone managed to get the latest demo "Silkcut" from The Black Lotus (released at Breakpoint 04) to run under WinUAE? This impressive production crashes for me and some other people after the mountain scene. An error message that the program can't allocate XXXXX bytes comes up.

Starting the demo from CLI without booting the startup-sequence or selecting more RAM doesn't help.

The demo can be downloaded from here:
http://ftp.snt.utwente.nl/pub/misc/d.../Amiga%20Demo/

[Enverex]

I thought it was a 060 only demo?

[Toni Wilen]

There are no 68060-only programs (except some 68060 configuration programs that naturally require 68060..) 68060 even has less instructions than 68040.

Some demos and games are "68060-only" only because _real_ 68060 is much faster than 68040.

[Duke]

I have the same problem, it crashes while displaying the mountain scene

[Bobic]

The readme says, that it works with WinUAE, too. Kalms, the coder, don't know why it won't run for us.

[Enverex]

Toni: What do you mean by "_real_"?

[FreakyDan]

I've managed to get it to work. I had the same problems as you. I just selected 8 mb to the fast mem and 64mb to the Zorro3 and it worked perfectly, and run it directly from CLI

[Jope]

Originally Posted by Enverex

Toni: What do you mean by "_real_"?

Real as in actual silicon, whirring away inside an actual Amiga.

If you emulate them, you wouldn't gain any speed if you emulate a "060" or a "040" as the instruction sets in both processors are almost the same! The emulation still has to do the exact same computations for each instruction, as both processors give the same results for the same instructions.

The 060 is a better design than the 040, so that's why it's faster at the same clock speed - it executes the instructions in less clocks than the 040 and has other enhancements to the CPU core.

The emulation, however, doesn't emulate the internal bits of the processor, but the instruction set, and it's already doing that as fast as it can..

Please ask if you need clarifications.. That wasn't the most linear or clear explanation..

[Jope]

Originally Posted by FreakyDan

I've managed to get it to work. I had the same problems as you. I just selected 8 mb to the fast mem and 64mb to the Zorro3 and it worked perfectly, and run it directly from CLI

The 8MB block of Zorro 2 fast mem probably doesn't help here at all - you can forget about it. The demo wants huge contiguous bits of RAM and the 8MB fragment probably will not even get allocated.

[Toni Wilen]

The emulation, however, doesn't emulate the internal bits of the processor, but the instruction set, and it's already doing that as fast as it can..

True, except when emulating 68000 in cycle-exact mode.

[hype]

mountain scene... *crash*

[RetroMan]

Thought I give this one a try on newer WinUAE Version !

Still crashes at mountain scene but continues when setting cycle-exact option, but that is REALLY REALLY slow

[kas1e]

works fine for me over winuae and over real 1200/060. i do not make anythink, just run it

[AMIGAZ]

Works fine here too on my A4000 '060, 81mb fast ram
So if you can emulate my A4000 I guess it'll work

OK I have a theory/question about the "Silkcut crashing in mountain scene on WinUAE" problem:

The message talks about a "memory allocation failure in sysDefaultPool". I do not know much about amiga and I am using a ClassicWB setup. I wonder if this crash has anything to do with the initial memory partition setup or something. Is there a system setting somewhere that we can use to adjust this sysDefaultPool size? I was thinking maybe there exists such a setting and whatever value the ClassicWB uses might not be enough causing this crash...

Any ideas ?

[StingRay]

"sysDefaultPool" is just something that's used in TBL's demosystem, you can't set or adjust it. The demo works perfectly fine on a real Amiga and I think if you disable JIT right before the mountain scene is about to start it might work on WinUAE too as I seem to remember that the problem disappeared when you slow down UAE, strange but true.

hmm thanks for the info stingray. Maybe there is a magic address in the .dat file that has the sysDefaultPool size Kalms? That would be great if he jumped in the discussion and said something like "yeah using a hex editor change the 4 bytes at the address 0x20393A"

[Toni Wilen]

I am not interested in wasting time debugging if sources still exist (not public, of course) and original programmers haven't disappeared yet

[_ThEcRoW]

Maybe if you deactivate jit, it could work?. I have been experiencing crashes on demos/progs that banged the hardware that worked perfectly when turned jit off.