WimpTracker Sept 1992

Having a go at running ‘WimpTracker’ from Sep 1992.
Anyone here know how to create a music file – with it?

Seems to play a file ok using RO 5.23 (26 Jan 2017)/Emulator.

But on the Iyonix/high vector version – I get in the zeropain file:-

ldr r4,[r3,#20] (r3= &6E)

Is &82 something special?

Also after a while playing a file for a minute or so – a error (as below) pops up:-
Some more digging is required me-thinks?

PC &20000018 -
r14 = &20000012

By the way – the Iyonix sound output seems quite quiet without a extra amplifier -
what is the max-volume command? forgotten :-(

What does this arm code do?
ie ^
STMDB R13!,{R1-R12,R14}^

Note to self: if reading in the car, pay attention!

STMDB R13!,{R1-R12,R14}^

I thought ^ with STM implied user mode registers stored … but unpredictable in user & system modes? Or is that out of date?

As Martin says, it will store the USR mode registers from a privileged mode (not USR or SYS). That is to say storing R13 and R14 will store R13_usr and R14_usr and not whatever banked registers apply to the current mode.
LDM^ is the logical inverse of this.

[online via my phone and GPRS/EDGE as 3G won’t pass stone walls – it’s highly reminiscent of the days of dial up!]

With ref to A5000/RO 3.1

Is &01F04000 address special?

I believe that was the address of the sound workspace (channel control blocks, etc.).

For RISC OS 5 you should be able to get the address from OS_ReadSysInfo 6 item 68 (although I’ve got no idea if the internal structure is the same – I guess it will depend on what WimpTracker is trying to do with it)

Thanks for your help – doesn’t seem to anything special at that address with respect with RS RO3.1.

Found a mistake that I have made in WimpTracker module :-(

Briefly tested now – on the Iyonix – now plays a tune.

ref the below :-

STMDB   R13!,{R0}
MRS     R0,CPSR
BIC     R0,R0,#%10000111   -&87
ORR     R0,R0,#%10000010   -&82
MSR     CPSR_c,R0
LDMIA   R13!,{R0}   Caution: uses banked register.

r0 gets flaged as a error – is there a way around this – without using NOP.

r0 gets flaged as a error – is there a way around this – without using NOP.

What are you using and what exactly was the message?

I’ve built that bit of code using BASIC. No messages at all.

I built it with objasm and it warns me that using a load/save multiple on a single register is inefficient.

Your code appears to be setting IRQ mode and disabling interrupts. What mode are you entered in? I ask this because if you write R0 to R13_svc and then reload it from R13_irq… that’s not gonna work! You’ll have an extra word on the SVC stack and one too few on the IRQ stack in that case. Could lead to some really weird crashes…

Here’s a clumsy way to preserve a variable across a mode change without corrupting anything:

STR     R1, [R13, #-4]!    ; stash R1 to the stack
ADR     R1, tempstash      ; get a pointer to temp word store
STR     R0, [R1]           ; stash R0 there
LDR     R1, [R13], #4      ; pull R1 back off the stack

MRS     R0,CPSR            ; read PSR into R0
BIC     R0,R0,#%10000111   ; clear IRQ and lower order mode bits
ORR     R0,R0,#%10000010   ; set IRQ flag and IRQ mode
MSR     CPSR_c,R0          ; push new control bits back into PSR
                           ; processor may change to IRQ mode

ADR     R0, tempstash      ; set R0 to point to temp word
LDR     R0, [R0]           ; load value into itself

[...]

.tempstash
DCD     0

Untested, of course. ;-) But that ought to preserve R0 regardless of whatever R13 may be or become.
An easier way is to follow APCS and just expect R0-R3 to be trashable. ;-) But, yeah, that’s harder to retrofit.

BTW, you might want to clear the lower four bits in the BIC. Just because it doesn’t do anything now doesn’t mean that ARM work make it have meaning some time in the future.

Thanks Rick -for your info.
Running the module through ARMalyser – gives the error.

Taking up your suggestion of saving the flags – it seems the prog is in IRQ already – I had thought it would have been SVC – so point taken about r13_svc.

Hmm – why not just use swi OS_IntOff/swi OS_IntOn instead!
Seems to work.

Those swi’s seems to switch off/on one of the interupts.