Iron Dignity 2020

Hi there,

I’m so glad that Jared made his 22 year old game engine demo “Iron Dignity” to run on an RPi3/4, released on Function Demo Party 2020 tonight. Runs pleasantly on an RPi4 at 1920×1080, and an RPi3 at 1280×720. Just software rendering :-) Check out the pouet entry here, the direct download of the Risc OS files here or the youtube link directly here

You might have to setup the resolution/buffering settings in the config file. 1920×1080 works unbuffered 1280×720 is also okay at tripple buffering.

Even if the base is 22 years old, it’s a real showcase in 2020 for RISC OS I think :-)

Excellent, Thanks for sharing! I saw your demo at Revision but that is the only demo party i tend to watch, i should watch more.

Frank found his old code, AND made it 32bit/ARMv8 compatible, AND released it? Impressive.

Yesterday, someone told me that he bought a Risc PC off eBay and the front flaps were still intact. And he connected any old serial mouse to it and it worked out-of-the-box with the standard RISC OS 3.5 serial mouse driver.

So it seems to be “lucky September” for RISC OS things!

Now, stretching the “luck” theme, maybe Frank could also release his souped-up version of Magnetoids…

@Steffen: Yeah I kind of encouraged him…and voila…we almost feared the sources were gone, as powering up his old Risc PC wasn’t successfull at first…luckily “only” a battery replacement and reinit of the scsi podule mostly…the hard drives themselves were surprisingly okay. I’ll ask him about Magnetoids :-)

Impressive.

Yeah, it’s almost ¹ good enough that one could design “objects”, set up camera movement, and object movement, and have it render scenes in real-time.

luckily “only” a battery replacement

Wow. You’re lucky the battery hadn’t caused a motherboard replacement.

¹ It is good enough, but people probably expect the sort of quality that comes out of Blender these days, despite the fact that most Blender videos are actually technically worse – the ones that look good are the ones that have lots of credits at the end!

I can’t get it to work on my PI3 (OS 5.27 06-Sep-20). I tried various combinations of resolutions and buffering but it always crashes at the same location.

Error block: 80000002 Internal error: abort on data transfer at &000123C4
R0 = 0113e1a4
R1 = 00000000
R2 = 000c9628
R3 = 00005358
R4 = 0113e194
R5 = 0113e6b8
R6 = 00000000
R7 = 000c961c
R8 = 000c961c
R9 = 000c962c
R10 = 0010ab44
R11 = 0010b670
R12 = 0010b674
R13 = 0010b654
R14 = 0000912c
R15 = 000123cc
CPSR = 20000110
R13_usr = 0010b654
R14_usr = 0000912c
R13_svc = fa208000
R14_svc = fc1a6ebc
SPSR_svc = 40000193
R13_irq = fa102000
R14_irq = 20000113
SPSR_irq = 20000113
R13_abt = fa301fa8
R14_abt = 000123cc
SPSR_abt = 20000110
R13_und = fa402000
R14_und = 00017ba8
SPSR_und = 00000110
OSMem16: 2 = fa100000, 00002000, 00002000
OSMem16: 3 = fa200000, 00008000, 00008000
OSMem16: 4 = fa300000, 00002000, 00002000
OSMem16: 5 = fa400000, 00002000, 00002000
Memory: fa100000 - fa102000
Memory: fa200000 - fa208000
Memory: fa300000 - fa302000
Memory: fa400000 - fa402000
Memory: ffff0108 - ffff010c
OSRSI6: 69 = ffff0108

R15 = 000123cc = +a3cc in application memory
R14_usr = 0000912c = +112c in application memory
          Function call to 000123a0 = +a3a0 in application memory

What’s the faulting instruction? [I’m surprised the dump doesn’t tell you that]

Error block: 80000002 Internal error: abort on data transfer at &000123C4

The demo ran on my RPi4 but did leave a ZeroPain log at that address. Impressive though.

Time: Mon Sep 21 21:22:01 2020
Location: Application space
Current Wimp task: Unknown
Last app to start: <Obey$Dir>.!RunImage 2><Obey$Dir>.stderr

R0  = 0113e1a4 R1  = 00000000 R2  = 000c9628 R3  = 00005358
R4  = 0113e194 R5  = 0113e6b8 R6  = 00000000 R7  = 000c961c
R8  = 000c961c R9  = 000c962c R10 = 0010ab44 R11 = 0010b670
R12 = 0010b674 R13 = 0010b654 R14 = 0000912c R15 = 000123cc
DFAR = 00000018  Mode USR32  Flags nzCv if   PSR = 20000110

00012384 : e5950004 : LDR     R0,[R5,#4]
00012388 : eb011050 : BL      &000564D0
0001238c : e1a00005 : MOV     R0,R5
00012390 : e91b6830 : LDMDB   R11,{R4,R5,R11,R13,R14}
00012394 : ea01104d : B       &000564D0
00012398 : e5a01010 : STR     R1,[R0,#16]!
0001239c : e1a0f00e : MOV     PC,R14
000123a0 : e1a0c00d : MOV     R12,R13
000123a4 : e92dd970 : STMDB   R13!,{R4-R6,R8,R11,R12,R14,PC}
000123a8 : e24cb004 : SUB     R11,R12,#4
000123ac : e15d000a : CMP     R13,R10
000123b0 : 4b011007 : BLMI    &000563D4
000123b4 : e1a04000 : MOV     R4,R0
000123b8 : e1a05001 : MOV     R5,R1
000123bc : e5b01010 : LDR     R1,[R0,#16]!
000123c0 : e3a06000 : MOV     R6,#0
000123c4 * e5912018 * LDR     R2,[R1,#24]
000123c8 : e1a00842 : MOV     R0,R2,ASR #16
000123cc : e5b12020 : LDR     R2,[R1,#32]!
000123d0 : e5941008 : LDR     R1,[R4,#8]
000123d4 : e1a02842 : MOV     R2,R2,ASR #16
000123d8 : e0813fa1 : ADD     R3,R1,R1,LSR #31
000123dc : e3510000 : CMP     R1,#0
000123e0 : e04030c3 : SUB     R3,R0,R3,ASR #1
000123e4 : e5843000 : STR     R3,[R4,#0]
000123e8 : e594300c : LDR     R3,[R4,#12]
000123ec : e0833fa3 : ADD     R3,R3,R3,LSR #31
000123f0 : e04220c3 : SUB     R2,R2,R3,ASR #1
000123f4 : e5842004 : STR     R2,[R4,#4]
000123f8 : da000017 : BLE     &0001245C
000123fc : e594200c : LDR     R2,[R4,#12]
00012400 : e3a08000 : MOV     R8,#0

R15 = 000123cc = +a3cc in application memory
R14_usr = 0000912c = +112c in application memory
          Function call to 000123a0 = +a3a0 in application memory

Ah, that’s what I suspected. A null pointer…

@Andre: Jared/Frank runs for sure on a RPi3…though I don’t know his OS version…I suspect it’s may be one of the Risc OS Direct downloads and I guess that’s basically an older ROM ?

basically an older ROM ?

FWIW the demo does not abort on the RPi1 OS5.26, in either ARMv5 or ARMv7 strict modes, without ZeroPain module present.

I suspect it’s may be one…

Or alternatively you’re using either a low vector build or the compatibility mode, so you’re just not seeing this?

If the failing instruction is LDR R2,[R1,#24], then it is trying to load something from an array element, like the 7th word in the array, but it is failing because the base address is zero.
This is often a case of struct structdef *blah = NULL; and then at some point using blah before it had been allocated or set to point at something. It’s a common mistake, we all do it from time to time…

PS: might help, these days, to build with function names included ;-)

Well that’s a coincidence as I was going to release the original demo via packaged distribution earlier in the month. What stopped me was I couldn’t find where I’d put it on my Pi3 having ironically spent ages fixing page zero bugs.

…AND found his way into a RISC OS forum first time in the century. Hi Steffen, hi all.
Yes it’s a bug as described, and one with a long beard. I can provide an updated RunImage with the fix.

Iron Dignity was impressive back in the 90’s, and I still think it looks amazing today. We may never get the Iron Dignity game that we wanted, but I’m very happy to see it updated to work on RISC OS 5 and new hardware. Huge thanks Jared.

Do you have any plans to do anything with RISC OS again? Or are you unsure what your plans are?

I remember showing the original Iron Dignity demo to anyone who would watch back in the 90s! It is great to see it back, and even better to see the original author back on these forums! Welcome, and thanks for bringing it back. But you know, you’ll start me dreaming again! ;)

This news is Uber awesome! Thanks to Jared! and thanks to Kuemmel for sharing! :)

Hi there,

Jared send me a fixed version. It’s now uploaded to all the former links. Or directly here

If you could give some response if the bug is gone, would be nice.

If you could give some response if the bug is gone,

The Zero Page error I saw previously has now gone. The Demo ran through to the end perfectly.

Works good on my ARMX6 but I wondering, not on Titanium.
Is the same with the old one.
stderr: “mode 1920×1080×5bpp not valid”
Monitor, MDF … all the same.
In MX6 stderr I not found a mode info.

Hi Jared! Thanks for releasing the new version! I still remember when I first ran the original demo, and the Iron Dignity text folded up. Young Michael was super impressed! :) It’s nice to see you’re still around.

Thank you for the release and a young Andrew was also similarly impressed.

For me on this Pi4 most of the demo is super smooth, except for the scenes with the tanks and the second initial flying camera shot which aren’t as smooth in their animation – slight judder?

It still looks great after all this time… :)

@Jared
Zurück zu Deinen alten Sünden ;-)

Have try to install the “Stealth Combat Demo” to DOSBox-X + WIN98 on my Titanium.
Install is possible but start fails with “Failed to set fullscreen mode”.
Not sure what the reason is.
Is it possible to set up lower settings in “Stealth Combat” SCom.cfg file. Have seen there but I not know the possible settings. Fullscreen is set to 1; have try 0 and two… gives effects but nothing I can use…
Do you remember? ;-)
Nothing I will “use”, only for fun.

It’s probably asking for a resolution not supported by your machine or monitor. Finding out what it is after and creating a suitable entry in your MDF might fix.

A lot of the RISC OS demos fail because they ask for a numbered mode which has a resolution or colour depth which the machine and/or monitor can’t do, so RISC OS gives you what it thinks is nearest. That will just about work for something that uses OS graphics calls, but demos using direct screen addressing wont take at all well to being given different colour depths, resolutions or pixel doubling.