Help trying to build Manic Miner RISC OS from sources

Hi there,

I have found this open source version of the great Manic Miner game for RISC OS:

http://old-www.moreofthesa.me.uk/progs.source.html

However, I am unable to build it. I installed GCC using PACKMAN, along with MAKE, but when trying to build I get:

make: * No rule to make target “system.riscos.c.init”, needed by “o.init”. Stop

Any help is appreciated, as this version of Manic Miner looks very good and a native 32-bit version would be great!

It looks like the Makefile.r is set up to use the Norcroft tools, not gcc.
There will probably be other adjustments needed, but you may be able to fix the

make: * No rule to make target “system.riscos.c.init”, needed by “o.init”. Stop

type errors by undoing the suffix swapping in Makefile.r
e.g. system.riscos.c.init becomes system.riscos.init.c and o.init becomes init.o
Similarly with any other .c or .o files.

the assembler in systems.riscos needs altering to remove the 26bit style function exits as well.

First visible item is the “HAT” references in the macros.
Then there’s the 8 instances of MOVS PC,R14

Moving on there’s some cleanup of the GameModes module and TimPlayer module, unless you have a location for a 32 bit version. At first glance GameModes looks like a simple cleanup.

The makefile also tries to run a tool called “datatoaof”. The only reference I can find to this is from 1992!

Moving on there’s some cleanup of the GameModes module and TimPlayer module, unless you have a location for a 32 bit version.

Doh! Memory span of a goldfish… of course there’s a newer version of TimPlayer

Edit:
So drop that in as a replacement, comment the gamemodes line in !Run and see what falls over after that, but on RPCEmu RO5.23 (17-Dec-16) it starts and seems to run. Bound to be something in the Manic application code that needs attention…

@Steve: After replacing TimPlayer and commenting out GameModes, I get

Internal error. Data abort at &00008B8C

I did say:

on RPCEmu RO5.23 (17-Dec-16) it starts and seems to run.

and I’m going to guess you’re using a Pi so the following applies:

Bound to be something in the Manic application code that needs attention…

So a recompile is required, after cleaning up the source. I suspect the only file needing work is ROSupport.s

@Steve: yes, I am using a Pi. However, ARM assembler is out of my knowledge. Do you know what the changes need to be exactly? I could try applying them and rebuilding for the Pi.

I can sort out the assembler for you, if someone knowledgeable on GCC can help you sort out on the C side.

Once you’ve figured that one out, we should probably look at Jet Set Willy.

@Jon: I am more or less familiar with GCC (compiler, linker, etc…) on GNU/Linux, so I may be up to the task with help on the RISC OS side of things (library paths etc).

As Steve pointed out previously, you need to edit system.riscos.rosupport/s and search/replace:

1. “}$_HAT” with “}”
2. “MOVS PC,R14” with “MOV PC,R14”
3. “MOVEQS PC,R14” with “MOVEQ PC,R14”
4. “MOVNES PC,R14” with “MOVNE PC,R14”

However, unless we can find a copy of “datatoaof” you won’t be able to compile it. This utility puts an AOF header around a data file. I’ve search the net for it to no avail, it was possibly on Hensa, but that site went years ago.

However, unless we can find a copy of “datatoaof” you won’t be able to compile it.

There is a ‘datatoaof’ in the new APDL Library site in b150.zip

I also have something called datatoaof that might be what you’re looking for. Email me if the APDL library link above is no good – dot blatchley at yahoo dot com.

Entertainingly there is mention of ‘datatoaof’ in DDE26, in AcornC/C++.Makefiles.StdTools

DATA2AOF        = datatoaof

But a mention is all there is!

Perhaps this was in the 26bit DDE if one goes back far enough.

The APDL zip contains !DataToAOF, by Paul Fidler, version 1.00 (11th Feb 1993) and includes a 26bit absolute ‘datatoaof’.

Yup. This is the same obstacle I’m hitting. Got Miner to build (I think) with the DDE – I just put all the files into c or h directories, then created the necessary o directories. Problem is, like you all, without datatoaof the data files aren’t available so the project won’t build. Hmm…

I wonder if making the data files under emulation would be acceptable to the linker (as a temporary hack)? If it’s just data, there shouldn’t be any 32 bit issues to worry about.

I’m going to bow out for now, new animé season starting so… ☺
[though tbh there’s only one programme that looks good; the others I’ll be watching are to see if there’s anything else worth looking at]

If it’s just data, there shouldn’t be any 32 bit issues to worry about.

Is a new 32-bit AOF header required, or have there been no changes there?

Problem is, like you all, without datatoaof the data files aren’t available so the project won’t build. Hmm…

Ye Olde discussion of data in a C project: http://www.verycomputer.com/24_90b3705a7b41335e_1.htm

Edit:
And regular users of Zap might recognise the location of the 32 bit utility Bin2c :)

There’s a binaof tool in CVS which probably does pretty much the same thing as datatoaof.

https://www.riscosopen.org/viewer/view/mixed/RiscOS/Library/Build/binaof%2Cff8
https://www.riscosopen.org/viewer/view/mixed/RiscOS/Library/Build/Docs/binaof?rev=1.1

(n.b. you may need to fetch it from a source archive or via CVS directly, I’m not sure if cvsweb has been fixed to not mangle binary files)

However if you’re using a recent version of GCC you’ll almost certainly want a tool which produces elf output, or as Steve points out you may want to use the more portable solution of a tool that produces a C file containing a big array.

Internal error. Data abort at &00008B8C

I got that on the Titanium, on the RPi3 all I got was a black screen. The game should run in mode 13 or 49 according to its help. They are both 256 colour modes which the Titanium will not handle. I am not too sure why the RPi3 failed.

The build was done on OS4.39 VRPC where the game does run. The GameModes module is in ROM. As I recall Select moved legacy modes into a separate module.

As Steve pointed out previously, you need to edit system.riscos.rosupport/s and search/replace:

“}$_HAT” with “}”
“MOVS PC,R14” with “MOV PC,R14”

However, unless we can find a copy of “datatoaof” you won’t be able to compile it.

Second item addressed by information from Jeffrey, or the Bin2C option if you want to leave your compiler options open.

First item:
HAT strip from MACROS
MOVS strip/replace in assembler
plus MOVEQS and MOVNES
and finally TEQP (x 2)

How those are done probably depends on whether people are aiming for a pure 32 bit or a bit agnostic version.

I am not too sure why the RPi3 failed.

There’s also some machine type detection in there and if you check the warnings from ObjAsm there’s a nice collection of deprecated instructions in the ROSupport assembler.

The APDL zip contains !DataToAOF, by Paul Fidler, version 1.00 (11th Feb 1993) and includes a 26bit absolute ‘datatoaof’.

That’s the one..thanks.

There’s also some machine type detection in there and if you check the warnings from ObjAsm there’s a nice collection of deprecated instructions in the ROSupport assembler.

The TEQP’s can be ignored, the machine type detection is using OS_PlatformFeatures, so hopefully works. I can’t get it to compile to check though, as my DDE doesn’t seem to contain several includes, namely osargs.h, osfind.h, osgbpb.h, taskmanager.h

The deprecated instructions can probably be ignored, it’s the APCS style entry/exits its complaining about which stack R13. There’s also a few deprecated STM’s with PC in them and R14,PC combined. If you really wanted to fix them, you could recode to use LDR/STR for the deprecated registers.

I am not too sure why the RPi3 failed.

I’m attempting to compile on DDE24 which (going by Elite) may not be fully AAsm32/ARMv7 compatible, so I’m not expecting it to run on Pi3.

I can’t get it to compile to check though, as my DDE doesn’t seem to contain several includes, namely osargs.h, osfind.h, osgbpb.h, taskmanager.h

OSLib

Hmmm… Removed the obvious 26 bit stuff in ROSupport. Also removed most of the findMachineType routine and hardwired it to think that a StrongARM RiscPC was connected (it doesn’t understand anything more recent than that).

Now starts, displays the bouncing title. But upon clicking anything it begins to draw the game screen and then bombs out. The backtrace goes back to UpdatePianoKeys, but there’s nothing that looks obvious there. Commenting out the entire function just triggers a cascading error that requires a machine restart; so something is still very wrong.
Running with sound disabled in the configuration makes no difference.

So, for now, I’m going to give up on this. :-(

To recompile for ARMv7 compatibility, you need OSLib from SourceForge and make the following changes in MakeFile/r:

“Cflags =” needs “-APCS 3/32bit -L22-S22-L41” adding to the end
“ObjAsmflags =” needs “-APCS 3/32bit” appending to the end

Changes to make within ROsupport:

Search/Replace:

1. $_HAT” with “}”
2. “MOVS PC,R14” with “MOV PC,R14”
3. “MOVEQS PC,R14” with “MOVEQ PC,R14”
4. “MOVNES PC,R14” with “MOVNE PC,R14”

Fix the Page Zero access bugs by moving line 841:

LDR R1,=machinetype

Moving down to line 844:

1 LDR R1,=machinetype
STR R0,[R1]

Line 746:

LDR R1,=domuskey

Should read:

LDR R0,=domuskey

Prevent it from corrupting the LinearHandler Workspace pointer:

Change lines 1022..1028 from:

LDR R2,[R2]
CMP R2,#0
LDRNE R1,=timplayer_code
MOVNE R0,#1
LDRNE R1,[R1]
MOVNE R2,#0
SWINE &60145 ; XSound_LinearHandler

to:

LDR R3,[R2]
CMP R3,#0
MOVNE R0,#0
SWINE &60145 ; XSound_LinearHandler
CMP R3,#0
LDRNE R1,=timplayer_code
MOVNE R0,#1
LDRNE R1,[R1]
SWINE &60145 ; XSound_LinearHandler

Change lines 1218..1220 from:

3 MOV R0,#1
ADRL R1,go_vfill16
MOV R2,#0
SWI &60145 ; XSound_LinearHandler

to:

3 MOV R0,#0
SWI &60145 ; XSound_LinearHandler
MOV R0,#1
ADRL R1,go_vfill16
SWI &60145 ; XSound_LinearHandler