Armbook problem - no OS disk not formatted

Hi,

I’ve been porting my free Mutant Penguin game to the Armbook (full screen).
Unfortunately, I powered it down and I think corrupted the SD card put in the side – which I assume has RISC OS on it.

Does anyone know where I can get an image from so I can restore my Armbok to life?

Thanks,

Tony

There is a good chance you can recover files from the card by putting it in a card reader on another riscos machine.
The ROM updates from RComp come with a utility to restore on to a newly formatted sd card if need be. There’s info in the manual about how to get updates, otherwise best contact RComp direct to get access.

Thanks Will.
Much appreciated.

I think I’ve found the necessary information and am pushing cards into my ARM X6 card reader to see what I can do.
Then I expect I’ll probably create a backup card image, once I bring things back to life.

As and when I get the game to work I’ll add Mutant Penguin (armbook) as a separate build in the !Store for people to play.

Does it have to be a separate version? I wonder if it is possible to auto-detect current resolution and scale as appropriate or something?

Hi Andrew,
I hope you and all of your family are well.

It doesn’t have to be a separate build. I’ll try and roll it in to one version.

Do you have a recommendation on how to ID the host machine as an Armbook?

I only had to make a few changes basically:

• Do CLS and not try to call MODE (as MODE 1920,1080,32 fails as not avialable. So I think MODE support is not implemented yet).
• Turn off triple buffering
• Draw into a sprite of 800×600 pixels instead of a back buffer
• Plot and scale the sprite so it was full screen

I still have to fix the mouse pointer coordinate scaling.

how to ID the host machine as an Armbook?

Don’t do that. Check for the availability of each feature separately,

Don’t do that. Check for the availability of each feature separately,

Thinking on this – historically RO had limited variations of hardware but even then there was lots of reinventing the wheel with similar code in many apps/utilities. More recently the available variants have expanded.
Perhaps a single utility (to sit in the bootable OS) that did all the probing at boot time and stored the results where it could be quickly read by any app?
Presumably it would need to cater for updates when removable items are plugged in (or out)

Don’t do that. Check for the availability of each feature separately,

Sometimes, as this example (and numerous others) demonstrate, it is necessary to identify a machine to cater for non-standard quirks of said machine.

As the range of potential hardware and the level of support/features differ slightly, the need to identify particular machines particularly for programs the run outside the desktop increases.

I know that ROOL (and historically the entire community) are quite against machine probing. However in the case where something that runs on other machines needs particular tweaks to run on one, it is rather necessary to be able to easily and correctly identify “the one”.

Do you have a recommendation on how to ID the host machine as an Armbook?

Take a look at the modules. Usually there will be a platform specific thing, often as the video driver.
When I need to identify a Pi, I don’t bother probing the CPUID any more (waaaay too many), I just look to see if BCMVideo is present. If it is, it’s a Pi, end of.

that did all the probing at boot time and stored the results where it could be quickly read by any app?

This is really the sort of thing that OS_ReadSysInfo should be doing. You can see that there was a start on looking at supporting this sort of thing as ReadSysInfo, 2 provides for the presence/absence of the IOEB, the 82C710, and an LCD. ReadSysInfo, 3 take it a bit further giving a features mask of the combi-IO chip (IDE, floppy, parallel, serial ports, chip type).
The closest we have is ReadSysInfo, 9, 7 that returns a printable string describing the hardware platform.

What we need now is a simple extension to that call that can provide two integers. One giving the base platform type (as in RiscPC, emulator, Beagle, Pi…) and the second giving the platform revision. The OS knows it, the programmer should be able to access it if there is a need without buggering around poking in places applications have no right poking because the stewardship of the OS does not want “differences” to be highlighted, even when such highlighting is unavoidable.

Recent valid example? Right here where looking at using the hardware random number generator in the Pi. The base address of the hardware changed. There’s no call to read this base address. There’s no call to read what sort of Pi it is. There’s only probing the CPUID and making assumptions as to which processor it is. This, to my mind, is a far greater transgression than the OS having a call to accurately return the device ID.

What we need now is a simple extension to that call that can provide two integers.

You’re sounding like you have half a plan already.
The thing is you need spare time to do more. Extend existing or simply insert a “FeatureSet” module? It would need to be softloaded in the test phase anyway.

Of course if Nemo hadn’t been prodded into taking a long walk we’d have a finished item by Monday morning, or sooner.

No, I don’t have a plan. But it doesn’t make sense for an extension module to provide what the OS needs to know itself.

Sometimes, as this example (and numerous others) demonstrate, it is necessary to identify a machine to cater for non-standard quirks of said machine.

No. You need to identify what’s non-standard about the machine.

A simple OS_CheckModeValid call is all that’s needed to check if a given screen mode is supported. It will cope with the Armbook. It will cope with any future machines that get released. It will cope with anyone using a weird monitor that doesn’t support that resolution. It will cope with RiscPC’s with under 2MB of VRAM. And when the Armbook is improved to support more screen modes, it will react to that.

If you want to get more involved, OS_ScreenMode 2 can list all the modes which are supported, and your program can scan the list to look for an acceptable replacement.

Recent valid example? Right here where looking at using the hardware random number generator in the Pi. The base address of the hardware changed. There’s no call to read this base address. There’s no call to read what sort of Pi it is. There’s only probing the CPUID and making assumptions as to which processor it is. This, to my mind, is a far greater transgression than the OS having a call to accurately return the device ID.

The problem in that case is that there’s no call to read the base address of the RNG. The solution is to add that call, not to promote the use of code that will break if executed on the wrong machine.

Recent valid example? Right here where looking at using the hardware random number generator in the Pi.

The correct way to deal with that is request the OS be extended to provide the address.

Developers certainly shouldn’t be hardcoding for specific machines, unless they’re developing OS drivers – that’s simple common sense. With regard to the OP, the issue is using a fixed resolution – not the hardware its running on.

The solution is to add that call,

In that case, yes.

I wonder if the kernel shouldn’t have an RNG built in, a software implementation (perhaps equal to srand()?) using hardware where available.

not to promote the use of code that will break if executed on the wrong machine.

Now, if only there was some sort of way of identifying what “the wrong machine” is… ;-)

Thanks for all of the ideas.

Thanks Jeffrey. I will use OS_CheckModeValid. Then, if I am able to determine the current resolution, I can use the code which I have written to display the game via the sprite scaling method which I am using. This has the advantage of being forward compatible to other cases where the native resolution of the game is not available.

I should be able to get back to this in the evening when its dark (and I usually code).

Tony.

I wonder if the kernel shouldn’t have an RNG built in, a software implementation (perhaps equal to srand()?) using hardware where available.

It already does, if you type

*Dump random:

There’s also

*Dump zero:

Ah, macros for Source#Random:$, along with Zero and URandom built into the handler for System Devices.
I didn’t know that existed. Thanks!

I’m a little bit cautious at the minute. I’ve only run Hform once before to enlarge my Raspberru Pi’s disc.
https://www.riscosopen.org/wiki/documentation/show/Software%20information:%20HForm
I recovered my files form the pinebook sd card (Thanks again Will). As expected Verify reports “too many errors”. So not much hope there.
So I need ot use HForm to reformat the SD card to FileCore and then run the utilities to install the ROM etc.

Given I’m still a relative RISC OS newbie (6 years this year) I feel concerned I might somehow reformat my ARM X6 drive by mistake.
So it looks like from the manual page:

1) I launch HForm
2) insert the PineBook memory card into the ARM X6 card reader slot (This shows up as USB 0 on the dislpay)
2) Select M for a memory card
3) Then I get asked to format memory card 0-7

Unfortunately, I do not know which memory card number to use. If I guess incorrectly, I’m concerned I will reformat the system disc or one of the 2 SD cards installed in the ARM X6

Please would someone direct me if I should be selecting M or S and which number that I should select.

Thanks,

Tony

I think if it is a USB device, it might be ‘S’ (for SCSI)?

What I’d do is shut down all applications, copy HForm to RAMdisc, then dismount and physically remove the system disc. Ditto for any other SD cards. Don’t take chances on a weird UI (yes, HForm, I’m looking at you).

Glad you saved the files
M would be SDFS, as in the boot disk in a Raspberry Pi. For a USB reader it would be S for SCSI. If that’s the first device seen, then 0.
I don’t know what interfaces the ARM X6 uses for its SD cards and boot disc so I’m not going to say what to type for certain; But, going from RAM disc is the super safe approach (with other devices detached). On a PI it would be S and 0 (zero) in a card reader, although you can run from RAM disc and easily pop out the boot sd card and use that slot and choose M 0. Also, you can back out with Esc at any time, and it will ask you to confirm at the end.

Thanks Rick and Will.
I’ve ordered a little USB SD card reader which I think will work on the Pi. Then I will use the RAMDisk and the instructions you have both provided.

If I trash my Pi through my own finger failure, I can fix it up fairly quick.

Then I get asked to format memory card 0-7
Unfortunately, I do not know which memory card number to use. If I guess incorrectly, I’m concerned I will reformat the system disc or one of the 2 SD cards installed in the ARM X6

After typing the card 0-7 hform lists the size and make of the card, so unless you have them all the same it should be clear which is which… or press Esc like Will says.

After running HForm, the next step is to run !A64ROM-scsi0.

Two things to be aware of:

1. The program as supplied writes to SCSI::0. If your card reader presents the SD card as a different drive number, you will have to amend SCSIDrive% (line 10 of program) to suit.
2. There is no “Are you sure?” message – the ROM is written to the specified SCSI drive immediately.

On an ARMX6 the two SD cards are SDFS devices. The main SSD is a SCSI device. Hope this helps.
*status includes “FileSystem: SCSI” and “SDFSDrive 1”. I can’t see anything specifying the SCSI drive number to boot from, so I assume it’s the first found.
Plugging in a USB 4-slot card reader puts up SCSI::0 to SCSI::3, and the SSD changees to SCSI::4.
Adding a USB memory stick does nothing at this point. Removing both, then plugginf the stick in shows SCSI::0. The SSD remains on SCSI::4 throughout.
It looks as though writing to SCSI::0 might be safe.

On an ARMX6, the boot (ARMX6 OS) micro SD card slot on the motherboard is :1
So, :0 with SDFS is the other micro sd card slot on the board (the lower one, usually inwards facing).

The “in situ” programmer can be used to program SDFS::0

However, accessing that port on an ARMX6 can be tricky, since it is inside the case.

Instead, I use the ARMX6 front card reader. This presents as SCSI::0 which is why the SCSI0 programmer exists. That’s the one I use myself.

However, the “gotcha” bit is Hform, which (depending on version) lists the SSD as device 0 and the card reader as device 1. Note that this has changed in the latest version. The key is to pay close attention to the stated drive description and capacity, and make sure you press the appropriate key!

If using a blank/fresh card, I just look for the message “this disc doesn’t have an existing/valid Filecore format”. That’s a sign it is probably the right card/disc :)

Work has been very busy over the last kmonth, so I only just got back to this.

Thanks for all the help and suggestions. Still not got my Armbok running as yet.

I formatted the drive and I ran !A64ROM-scsi0. which reported success and now 12 MB of my SD card is used. However, there are no folders or files. Do I need to install something like Harddisk4 form ROOL? The other downloads contain tools etc, but not the standard applications. At least I didn’t find any.

I think maybe I should order a spare and then use that to provide files for my mostly empty card.

Then I can get on with some Armbook game porting.