A new game : Feedback required

Does someone have a valid set of bootcode.bin, fixup.dat and start.elf to share? The latest one just blank my screen, or blink, or crash the whole OS. My ROM is 07/Apr/2020. So I can easily switch to the latest one.

Does someone have a valid set of bootcode.bin, fixup.dat and start.elf to share? The latest one just blank my screen, or blink, or crash the whole OS.

I just tried the 20 April 2020 ROM in a Pi 3B with the latest firmware (12 May 2020) and it booted to the desktop – while I didn’t do a full functionality test it seemed to be working normally.

You did grab the actual bootloader files from GitHub, didn’t you? The index shows “bootloader.bin”, “fixup.dat” and “start.elf” but they lead to an HTML download page – you have to click through to reach the files themselves.

https://github.com/raspberrypi/firmware/blob/master/boot/bootcode.bin
https://github.com/raspberrypi/firmware/blob/master/boot/fixup.dat
https://github.com/raspberrypi/firmware/blob/master/boot/start.elf

Alternatively, firmware from 20 February 2020 is known to work on a Pi 3 (the link takes you to that day in history on GitHub – click through to reach the files).

You did grab the actual bootloader files from GitHub, didn’t you? The index shows “bootloader.bin”, “fixup.dat” and “start.elf” but they lead to an HTML download page – you have to click through to reach the files themselves.

Yes, I do. And they have major issues under RISC OS :)

Alternatively, firmware from 20 February 2020 is known to work on a Pi 3

Thanks. I’ll come back after some tests.

It works much better. Sometimes it crashes while booting if I power off + power on the Pi too fast. But 256 colours mode is now working :) This game is just great, but needs Alignment Exception off.

Glad you like it David. I’ll look into the allignment issue.

Is there a preffered norm going forward for alignment acceptions ?

Is there a preffered norm going forward for alignment acceptions ?

An amount of old RISC OS software used rotated loads, which doesn’t work on newer processors that can actually load from unaligned addresses.
Therefore, I think the norm (and what my machine is set as) is to raise an exception on an unaligned load. Because one cannot really be certain if a literal unaligned load is wanted, or is it was expecting to be able to do a rotated load. So whatever, fault it.

So what you are saying then Rick is it’s pretty much user preference.

So, out of curiosity, is there anything wrong with me putting some code into my projects to force a state of allignment acception, either on or off, as long as I restore the state back after.

That depends upon why you want to mess with the alignment settings. In order to support rotated loads? Won’t reliably work after ARMv5 (it’s an option on ARMv6). In order to support proper unaligned loads? Won’t reliably work prior to ARMv7 (it’s an option in ARMv6).

In short, whatever you’re trying to do with disabling the alignment exception, there’s a non negligible chance that it won’t work on a large enough number of machines to make it simply not worth doing.

So what you are saying then Rick is it’s pretty much user preference.

Not really, because your software will only work on some hardware. Use the ‘old style’ operation, and it will fail on ARMv7 and later; use the ‘new style’, and it won’t work on anything before that.

The current thinking, I believe, is that at some stage – once we’ve got all of the old software out of circulation, which could take a while – it might be feasible to turn exceptions off and use the new action when targeting ARMv7 and later platforms. We’re not there yet, though, given the number of reports of stuff raising the exceptions.

For third party software like your game, which could run on systems from a RiscPC onwards, don’t use unaligned loads and stores, and allow the user to leave alignment exceptions on.

So, out of curiosity, is there anything wrong with me putting some code into my projects to force a state of allignment acception, either on or off, as long as I restore the state back after.

What would be the point?

Having alignment exceptions off doesn’t magically make the code work as expected; it just ignores the fact that it might not have done what you expected. When writing third party software than can be used on all hardware platforms, you simply need to avoid unaligned loads and stores.

Oh, and fiddling with a user’s configuration is viewed as bad practice. What if your software crashes or the machine is turned off, and the setting is never restored as the user had it?

Okay Rick & Steve, I understand now the consequences wuth messing around. And thank you for bringing my attention to a nasty bug in my game I was never aware off :-). This is why it is important to have people play test as they will quite often turn up issues that you the programmer may not.

Thanks guys

Finally had a moment to sit down and try your game.

Bad news, I’m afraid.

The first thing was that it crashed immediately after the intro screen. However, following this topic I knew to turn alignment checking off as something was loading from an unaligned address. Just know that on roughly half of the available RISC OS machines, that won’t be doing what you think it is doing.

[ aside: I didn’t read the wall of text – it’s a little hard to read the part in the middle against that background (too bright, too much contrast) ]

This got me to the menu, which is laid out quite nicely, where the second problem presented itself. Entering my name was more akin to typing R R R R I I I C C K K K K, in other words hammering the key until the game noticed. I wondered if it was because my machine was in UTF-8 alphabet (due to something else the other day) but switching to Latin1 didn’t change anything. Typing “RICK” at normal speed might, if I’m lucky, get one letter to appear.

[ aside: on the other hand, the cursors are very sensitive and pressing quite often skips menu options. You might want to debounce that, or add in a delay so that tapping Up or Down only moves one menu entry at a time. ]

Which led on to the third problem. The game then immediately crashes. I have, thus far, not made it beyond that point.

And, a fourth problem. Try a few times and the game will abort at start with the message “Too many registered TimPlayer song handlers”. Thankfully the SWI TimPlayer_Configure accepts the magic value -1 to mean “unregister everything”, but it’s a pretty good demonstration of what Steve means about the game not restoring things as they were if/when the game crashes.

As for the show-stopper:

Internal error: abort on data transfer at &0000D330 at line               7
*ShowRegs
Register dump (stored at &20009BD0) is:
R0  = 0001676C R1  = 00016790 R2  = 00000000 R3  = 0001676C
R4  = 000001CA R5  = 0001676C R6  = 00000000 R7  = 00000FF9
R8  = 00000000 R9  = FFFFFFFF R10 = F7B96000 R11 = 000166F0
R12 = 00000000 R13 = 00207F18 R14 = 0000AFD0 R15 = 0000D330
Mode USR32 flags set: nZCvqjggggeAift        PSR = 60000110
*MemoryI PC -20 +40
0000D310 : 7... : E2899B37 : ADD     R9,R9,#&DC00
0000D314 : .... : E2899806 : ADD     R9,R9,#&00060000
0000D318 : .... : E5999008 : LDR     R9,[R9,#8]
0000D31C : .... : E3A07A01 : MOV     R7,#&1000          ; =4096
0000D320 : .pG. : E2477007 : SUB     R7,R7,#7
0000D324 : .P.. : E1A05003 : MOV     R5,R3
0000D328 : .... : E599601C : LDR     R6,[R9,#28]
0000D32C : ..V. : E1560007 : CMP     R6,R7
0000D330 < .... : 028F80AC : ADREQ   R8,&0000D3E4
0000D334 : .... : 02888CD2 : ADDEQ   R8,R8,#&D200
0000D338 : .... : 02888807 : ADDEQ   R8,R8,#&00070000
0000D33C : .... : 059838B0 : LDREQ   R3,[R8,#2224]
0000D340 : .... : 0B0011F8 : BLEQ    &00011B28
0000D344 : ..V. : E1560007 : CMP     R6,R7
0000D348 : .... : 05996020 : LDREQ   R6,[R9,#32]
0000D34C : .... : 03866A01 : ORREQ   R6,R6,#&1000       ; =4096
*

As you’re trying to load from R9+28 and R9 is &FFFFFFFF, I didn’t bother to debug any further. It looks as if you might be using a -1 flag which is being mistaken as an address?

I noticed, also, then when exiting the game, it briefly throws up a “WindowManager in use” error on the way out.

I hope this helps.

This is why it is important to have people play test as they will quite often turn up issues that you the programmer may not.

What machine do you use?

Addendum: I think the first task should be to remove the unaligned loads. If this is building some sort of data table that things later rely upon, who knows what sort of rubbish the processor might have been handing back?
If you later rely upon this bogus data, well, perhaps that’s the origin of the second crash.

Thanks Rick, once again you put quality time in for me.

The bug relative to the code dump above has been fixed. It wasn’t so much as a bug but data that was being sent there shouldn’t of been. My bad. Strange that it never cropped up before. I was simply trying to clear a linked list when the list was empty.

With regards to the unaligned loads. Your right, that has to be the priority. Its gonna be tricky. I spent aeons crafting my sprite plotter code to specifically avoid unaligned loads and writes. I manually rotate the data in registers and always, so I thought, write word aligned. Thats how I manage to get pixel scrolling but maintain word aligned reading and writing. I’m gonna have to have a long deep thought on this and how I’m going to approach it.

I know about the UI being a bit uh. Im more concerned about the main game since this is just an exercise in game design and making mistakes is how you learn your most valuable lessons.

Never seen the window manger error before. Stumped on that one. Its possibly a side effect of the other crash maybe.

You always help Rick, you did last time. I can’t fault you. I learnt a load of important stuff off you last time and I’m learning again this time. I won’t lie, it’s not always fun but it is important.

The only thing that I am aware of that could be accessing memory unaligned is my sprite plotter as said above but will check all my data and boy is there a ton of it.

I’m running a RPI 2 with RISC OS 5.24

The bug relative to the code dump above has been fixed.

Can you send me an updated RunImage so I can try playing the game?

I spent aeons crafting my sprite plotter code to specifically avoid unaligned loads and writes.

I can’t comment on specifics of your plotter, however looking at your call to OS_ScreenMode, it looks like you’re using 8bpp. Does the system not run sufficiently quickly if you use byte reads and writes?
I found that for my VIRUS! game (yes, shout it for maximum hamminess) I could keep up with a 75Hz framerate on my Pi2 plotting a couple of hundred sprites using plain ordinary SpriteOp – I had sketched out some rough ideas of how to write a custom sprite plotter in assembler, but it turned out that I just didn’t need to!

I’m gonna have to have a long deep thought on this and how I’m going to approach it.

What I did with Manga’s (dev code) scaling routine was to write a testbed in BASIC, which calls a function “PROCscale”. Then as I played around with the different behaviours, I copy-pasted the function as "PROCscale_one", "PROCscale_two" and so on. PROCscale would then call the one I wanted to see.
And the one that looked like it gave the best results? Was coded into Manga and is available for demonstration via a secret keypress. It’s not yet an option as the end result is still a little blurry and my grasp of maths means I’m going to have to have a good long think about what it is doing (and how to improve it). It’s already, to my eyes, better than the OS JPEG scaled plotter, but nowhere near as good as calling out to ChangeFSI…
Anyway, point is you can create a different sprite plotter to see how it behaves, and switch it in and out as you want for testing.

Never seen the window manger error before. Stumped on that one.

It may be because I’m running !Run directly from the command line (so I can get to debug if something happens). Unfortunately there are no embedded function names or anything, so it’s damn near impossible to see how/where the program exits. I did check, you don’t appear to be calling any Wimp SWIs so…?!?

I also ran the game in DDT (by prefixing two words at the start with SWI “OS_GetEnv” and MOV R13,R1 to set up the stack – runs fine like that without the BASIC loader) but DDT can either trace every single instruction executed (with its screen redraw going comically wrong) or it just says that the program finished.
It would be nice if there was a way for it to record the last ‘n’ branches, but I guess it’s more aimed at C (with a backtrace structure) than pure assembler.

When in the menu, what’s the Windows Logo keypress for?

I won’t lie, it’s not always fun but it is important.

Debugging is always a pain in the ass, and it’s the worst part of programming. Especially those elusive things that are difficult to figure out. But, when you spend the better part of four hours tracking down one specific bug and you finally nail that b**tard to the wall, it’s a massive sense of accomplishment. It’s like “I beat you”.

will check all my data and boy is there a ton of it.

Yeah… I noticed. ;-)

I’m running a RPI 2 with RISC OS 5.24

Original or later Pi2? If the original (ARMv7) then it’s basically the same as me. I’m running OS 5.23 but that shouldn’t make any difference.

Mmm… please tell me you don’t waste a second and a half doing nothing, because that’s an awful lot like what +&81A4 looks like it does!

Ah, I think I see what’s acting weird. You’re exiting by passing *DESKTOP to the CLI.

What you’ll want there instead of calling *Desktop is:

MVN    R0, #0   ; -1
SWI    "XWimp_CommandWindow"
SWI    "XOS_Exit"

[Oh, and I nuked that looong delay at exit. Much nicer! ;-)]

Argh! It’s quarter past ten already! Time to go brew some bow tie pasta and browse Netflix before entering Standby Mode…

@ Rick
The windows key does absolutely nothing on my machine in the menu so don’t know what you are saying Rick. I think My Pi2 is a later one. I didn’t get it straight away, was still using my Iyonix. Tried the bit of code above and makes no difference here. I’m also not getting a second and a half delay either.

Ive solved the alignment exceptions crash now so if anybody wants a new version shout out. I’ll take it that you do Rick.

Ive solved the alignment exceptions crash now so if anybody wants a new version shout out.

Yup – it’s what I suspected. The alignment issue was tripping up other stuff. The game now works, and oh my god do I suck.
High score so far, something like 8284. 50th place on the leaderboard? Six digits… :-/

so don’t know what you are saying Rick

My bad. It was late, I was tired. I misread the registers. &81 is the OS_Byte to call, not the key to look for. <facepalm>

I think My Pi2 is a later one

Easily enough to test. The Pi 2 v1.2 is an ARMv8 machine.

This should either reply “321” (earlier ARMv7 Pi2) or throw an exception (later ARMv8 Pi2).

DIM code% 32

FOR loop% = 0 TO 2 STEP 2
  P% = code%
  [ OPT  loop%

    ADR  R1, word
    MOV  R0, #123

    SWP  R0, R0, [R1]

    MOV  PC, R14

  .word
    DCD  321
  ]
NEXT

PRINT USR(code%)

Tried the bit of code above and makes no difference here.

That’s the point. It is supposed to return you cleanly to the desktop (no “Press Space…”) without the potential side effects of calling *Desktop.

Also, calling the X form SWI, it’ll work on machines where the Desktop isn’t available (Pico, for example).

I’m also not getting a second and a half delay either.

This is executed on exit:

81AC  MOV   R4,#&5A
81B0  MOV   R0,#&13
81B4  SWI   OS_Byte
81B8  SUBS  R4,R4,#1
81BC  BNE   &81B4

That looks to me like calling wait-for-VSync 90 times, which at 60fps is a second and a half.

Small bug report – enter a long player name (“Richard”). Delete and enter a shorter one (“Rick”). Go into the game. You’ll see “Rick” followed by three characters of essentially garbage. It’s either not tracking changes in string length, or not terminating when the string is shortened.

I still suck at it…

Ooh, pressing ‘Q’ dumps you straight back to the menu. Given its proximity to a key in use (‘A’), I would suggest making abort be something else (Esc?) or prompting the user.

Nice fluid motion with the aliens, and you know s*** is getting real when the screen fills up with moving laser pulses.

Is that big thing you’re supposed to be aiming for actually killable? It seems to hurry away before you can inflict any real sort of damage to it.

Sounds like your having fun, good. My high score is….well lets just say 6 figures :-). My PI2 is the earlier one Rick. Oh my, can’t believe I put a piece of code in like that. I’m ashamed. It was that long ago I’d forgotten. Didn’t notice the delay as my monitor takes a couple of seconds to re sync going from 640 × 480 back to 1920 × 1080. I know about the garbage Rick just haven’t got round to it, I’ve been more focused on trying to make the game something enjoyable to play, the reason for this post initially wanting play testers. Ive changed the Q to quit game to ESCAPE now. That big thing is probably the end of level boss. If his energy bar is not red then he will start to recharge if you don’t shoot him. If you only have a single shot you will grow a beard before you kill him. Get those pickups.

I’ve also fixed the garbage

My high score is….well lets just say 6 figures :-).

Yeah, I saw on the video. I also noticed, rather amusingly, that you’re so familiar with the game that you put yourself in position for things before they happen. :-)

My PI2 is the earlier one Rick.

Same as mine then.

Didn’t notice the delay as my monitor takes a couple of seconds to re sync going from 640 × 480 back to 1920 × 1080.

Ah, I have mine set to have the GPU fake everything to fit my monitor (1280×1024) so mode changes are instant. I did have it the other way but got fed up of the fact that modern monitors take longer to sync themselves than CRTs ever did…

Ive changed the Q to quit game to ESCAPE now.

Ah, that’ll be better. ;-)

That big thing is probably the end of level boss.

No, it’s the middle-of-level underling. The one that you just walk over. I had to watch your video to appreciate the scarab beetle at the end.

you will grow a beard before you kill him. Get those pickups.

I think you mean “I will die in a horrific fiery explosion” before I kill him. I did mention that I suck…

I’m still willing to test changes and revisions, but I’d better warn you that my replies and participation on this forum will be greatly restricted for the next few days.
Because Big Tractor meets flimsy phone line – not a good combination. Luckily though he’s yanked out everybody the vicinity (so he’ll have to put up with hassle from his children regarding on-line school work, a weekend without Netflix, etc etc). I have my phone, there’s 4G (outside), and it can be a hotspot. It’s what I’m using to write this right now. But in the house? Different proposition. Barely any connectivity.
Orange claims an engineer will visit on the evening of the 19th…

It is doubtful Rick whether I will continue with developing it. As good or bad as my code may be I made some design choices a while ago and since then I’ve taken the game in a better direction than originally planned and those choices are now a limiting factor without huge rewrites. Ive already shoehorned in some things and I really don’t think it is a good idea to continue along this path. My immediate plans will probably code 1 or 2 more simplistic games using the code from ELD to try to fully understand the limitations before I finally do the neccessary recoding of those core routines which in time will be the grounding of all my games, until the next game shows limitations and then I will repeat the cycle. Then I will code ELD3. I like shmups. I may add bits over time if I think it is a worthwhile addition or i’m doing something else that I think would fit nice in ELD. Who knows.

Out of curiosity Rick, what refresh rate was you playing ELD in.

It is doubtful Rick whether I will continue with developing it.

If I can have any influence whatsoever – please do. You’re so close to having a releasable game. It’s cool. It’s nippy. It’s addictive. It’s hard. But it’s also fun. Don’t give up when you’re this close!

and those choices are now a limiting factor without huge rewrites.

Okay, hands up who’s been there, done that.

<raises hand>

There are many times when designing stuff that early decisions turn out, in hindsight, not to be the best way. Even when planning out and making charts and flow diagrams (as opposed to just “writing something in the editor”), halfway along you’re like “well why the hell aren’t I doing this?” and then you realise that “this” means tearing out huge chunks of code and rewriting it.

Don’t fear this. It’s part of the learning process. Windows was rubbish until it’s third try. France is on its fifth republic. First attempts are bound to suck, it’s just how it is.

For your game, however, it may or may not be pleasing code but it is a fully working game that just needs some edges polished. You don’t need to rewrite stuff. What you have works. Save the rewrite for the sequel. :-)

Seriously, it’s good.

My refresh rate is 75Hz. No idea why as the monitor’s native refresh runs at 60Hz. I probably put the wrong number in the config.txt file and never bothered to change it. Oddly enough RISC OS itself reports the refresh as 57Hz, but a simple check (counting VSync in a second) shows that it really is 75Hz.

Hey – wait – is that why I get slaughtered before I make it to a five digit score? <fx: desperately grasping at straws>

Thank you Rick for your faith in me. Thumbs up. I will take some time to decide on what could be the best way forward and what I want to add, remove or change and how to implement. My main reason for being apprehensive about continuing is simply that I don’t want to keep " forcing " things in to play nicely with existing code as there is a real danger of introducing bugs which WILL be difficult to track hence my comment about rewriting huge amounts. If I can figure out a minimalistic way to rewrite a minimal number of things thus reducing the possibility of new bugs, I will consider moving forward. I understand that sometimes a rewrite of parts is a necessary evil, God knows I’ve done it enough with ELD and fixed a ton of bugs with it haha. You’ve already influenced me to fix a couple or so of bugs. Thanks. Keep pushing me if you want to.

Yes I would definately say the game is harder than it should be running at 75Hz. If you can run it at 60Hz it should prove to be more playable. There is an FPS counter built in, toggled using F1, if this helps.