Why is Hardwired so broken on AGA ?

[LittleSandra88]

Dear all =)

The Silents/Crionics demo Hardwired is a mater piece in many ways, but quite broken on faster Amiga's.

The loader seams(?) fine, but many effects finish too soon and some effect are not displayed correct. E.g. many of the dot effects have been flattened.

I have OSC demos that work perfectly that were even made before the release of the A1200.

Can someone explain what is wrong with Hardwired on faster Amiga's?

Hugs,
Sandra =)

[Seiya]

some demos was programmed with self-modifying code with bad effect on 68040 and 68060

[TCD]

Which is why this exists: https://whdload.de/demos/CrionicsSilents_Hardwired.html

[a/b]

The loader (seems to) work fine because they overcompensated to ensure it runs on all drives: timings are above ultra safe, calibrations are frequent and act as a 5th audio channel :P (nothing too much wrong with that, but could've been done more reasonably).
When you push the hardware you usually have to make compromises and sometimes bad things happen on faster hardware. Sometimes you have a hard deadline. Sometimes you can't find your phone to dial 1-800-docbrown.
Many possible reasons, especially when you have ~5 coders working on it.

[LittleSandra88]

Interesting. About the 5th audio channel. Is that why the ripped music is a custom format?

When using the music tracker for changing effect, I would have expected the demo to change effect correctly, as the music isn't played faster?

On my machine the WHD version seams to be the same as running is from disk?

[StingRay]

Originally Posted by LittleSandra88

Can someone explain what is wrong with Hardwired on faster Amiga's?

Despite the nice effects, much of the code is quite bad/dirty, which causes a lot of problems. I hate the Hardwired code with a passion (bset #1,$dff02e still haunts me to this day).

[Torti-the-Smurf]

Originally Posted by StingRay

(bset #1,$dff02e still haunts me to this day)

[LittleSandra88]

Originally Posted by StingRay

Despite the nice effects, much of the code is quite bad/dirty, which causes a lot of problems. I hate the Hardwired code with a passion (bset #1,$dff02e still haunts me to this day).

Is it the code that glues the effects together or the effects code that is bad?

I am guessing it is not simple 1:1 search/replace to fix this?

[StingRay]

Some of the code is OK, some is less than OK and some of the code is really bad. The bset #1,$dff02e line for example, is responsible for a black screen when the "48 faces glenz" should be on screen.

It takes quite some time to fix the demo to work properly on all machines (which is why I still didn't finish the update WHDLoad patch for this very demo).

To give you a rough idea, you can check the ReadMe of the Desert Dream WHDLoad patch. For this one, I had to patch the disk version of the demo to gather the timing data which I then could use to fix the timing for all Amigas.

[paraj]

They obviously knew there were issues on faster amigas. Funny excerpt from UAE changelog from a little while ago:

960105 Added AvailMem(), AllocMem(), AllocAbs() and FreeMem() dummies.
       The Hardwired demo times the multiplication instructions and prints
       "This demo don't like Axel" if they are too fast. Apparently, Axel has
       a 68040. Added a WANT_SLOW_MULTIPLY option to config.h.
       Fixed the fast blitter emulation (seems to work now).

I'm guessing they decided it had to run (well/at all) on 68k+512+512 and be finished for TP91, anything else being a bonus.
If even one coder didn't have regular access to a faster machine it's tough to debug this stuff. Understandably no one else is going to do it for them - have you ever seen OTHER PEOPLE's code? It's horrible

[TCD]

Originally Posted by paraj

The Hardwired demo times the multiplication instructions and prints
"This demo don't like Axel" if they are too fast. Apparently, Axel has
a 68040.

We should collect these gems from the WinUAE changelogs somewhere

[paraj]

I don't have any more good quotes off hand

FWIW in this case I think "Axel" doesn't refer to a person, but is meant to be short for "accelerator" (maybe there's a limit on the characters on that screen).

Actual timing loop:

00008016 0c39 0040 00df f006      cmp.b #$40,$00dff006
0000801e 66f6                     bne.b #$f6
00008020 23fc 0000 0cdc 0000 00fc move.l #$00000cdc,$000000fc
0000802a 4ff9 0000 7800           lea.l $00007800,a7
00008030 3e3c 00df                move.w #$00df,d7
00008034 7cff                     moveq #$ff,d6
00008036 ccc6                     mulu.w d6,d6
00008038 51cf fffc                dbf.w d7,#$fffc
0000803c 7a00                     moveq #$00,d5
0000803e 1a39 00df f006           move.b $00dff006,d5
00008044 0445 0040                sub.w #$0040,d5
00008048 0c45 0014                cmp.w #$0014,d5
0000804c 6a12                     bpl.b #$12        ; OK

So 224 multiplications and it has to take around 20 raster lines (~9k 7Mhz) cycles. Don't need a 040 for that to fail

[LittleSandra88]

If if the Axel test succeeds, then the demo just run as fast as it can? And the parts that doesn't require 100% cpu will then finish sooner than planned?

[paraj]

Originally Posted by LittleSandra88

If if the Axel test succeeds, then the demo just run as fast as it can? And the parts that doesn't require 100% cpu will then finish sooner than planned?

No, at least with the original disks it just halts (e.g. on an A1200).

[mnemo]

Originally Posted by LittleSandra88

Interesting. About the 5th audio channel. Is that why the ripped music is a custom format?

The music is a standard MOD, but it uses 256 song step entries while SoundTracker only allows 128. I guess Jesper Kyd copied the module to a "part 2" after a while when he realized he needed more song steps and then used the same sample set in this second module. The coders then took the additional song steps and patterns and modified the play routine to play 256 steps.

There is a "fixed" / combined version that uses the normal 128 steps done by Gryzor:
https://modarchive.org/index.php?req...id&query=44272

The "5th audio channel" is a joke by a/b, they were referring to the sounds of the floppy drive.

[Nobby_UK]

Not working for me:

[Photon]

In general (for anything coded before update X): software can only be backwards compatible, not future-compatible.

AGA wasn't too backwards-incompatible, and neither was KS3.0, but when you push the limits you can start to deviate from documentation.

To this is added that users or even bookstores couldn't just order the books. You basically had to have company and find their international number and phone them to order copies. And in the time it took for the documentation to arrive from Commodore-Amiga, and for a teenager to finally get it, many bad habits had time to form.

Few demos used self-modifying code. The slowmem of A500 is uncached, but there is no easy way (certainly not a documented one), to prevent other Amigas loading it into FastRAM, which on later CPUs would have an instruction cache and make self-modifying code more difficult to write (to execute as intended).