Pi 3 bugs

Hopper, on the other hand, wanted a 320×256 graphics mode

Hopper attempts to run in MODE 13 which may not be available, that is dependent on the configured MonitorType.

configure MonitorType 0

or

co. mon. 0

That works immediately, no reboot. Hopper plays now. All is good until attempting to exit the game, which dumps one at a garbaged desktop. One is then stuck in a “This screen mode is unsuitable for displaying the desktop” situation. At an F12 prompt MonitorType needs to be reconfigured to EDID or Auto to enable a normal reboot.

… Hopper plays now. All is good until attempting to exit the game, which dumps one at a garbaged desktop.

I have previously got programs requiring a specific screen mode parameter to work seamlessly by adding a command to change parameters in the !Run file before the !RunImage is launched, and a command to revert these changes at the end of the !Run file when the !RunImage is quit.

Whether that would work in this case I know not!

The particular case I remember was IconLab by Graham Crow, a program which simplifies the chore of keeping track of icon numbers during program development by “capturing” a window from the screen as a sprite and labelling its icons, but which needed to work in a 256 colour mode.

I merely added appropriate WimpMode commands to the !Run file as described above.

Some untested advice: Adding ‘disable_mode_changes’ to CMDLINE/TXT in the Loader partition and loading the AnyMode module (http://www.pi-star.co.uk/anymode/) should stop all mode-related worries at the expense of a little bit of speed. (Untested as my Pi hasn’t been updated for a while now)

This, plus setting my default hdmi_mode, got all the video modes working, and I seem to have also had better luck with Hopper and the low-mode BBC BASIC graphics.

I do need to set the resolution on the desktop after boot each time, and setting up the CMOS stuff as described here did not appear to stick the results. Is this a side effect of AnyMode?

Are you running the latest release of ADFFS, currently 2.60? Page Zero accesses by ADFFS were switched to legal OS calls, once Jeffrey added some OS extensions for Adrian and myself. As for games themselves, I’ve fixed most Page Zero accesses by correcting the bugs in the code, in the game boot scripts.

The filename was ADFFS209/ZIP, so I’m going to guess “nope”.

Just patch incompatible software with PatchSWP. And enjoy.
bq. Almost everything I tried works here.

That fixed AlienBlaster, Mednafen, and xu4. xu4 did however continue self-destructing every time I did a PackMan operation because it thinks it depends on the not-presently-existing UnixLib package.

OpenSSH was only half-fixed; ssh itself would work, but scp, rsync, and sftp would fail with mysterious error messages involving the socketpair call (sftp) or hang on any network operation (scp and rsync). PuTTY ports I found were old and exploded with illegal instruction errors even after PatchSWP ran. Maybe I was looking in the wrong place.

The PlingStore was declared by PatchSWP to have SWP instructions but to be unpatchable.

My issues with asasm ultimately stemmed from not putting whitespace in front of my AREA directive.

With the exception of not being able to transfer files off my Pi3, I am now well on my way.

PuTTY ports I found were old and exploded with illegal instruction errors even after PatchSWP ran. Maybe I was looking in the wrong place.

Try ARMv7 Fast mode.

The PlingStore was declared by PatchSWP to have SWP instructions but to be unpatchable.

Works perfectly here without any patch.

Most of the other things I tried to install via PackMan didn’t work. AlienBlaster and Mednafen both hung the same way PackMan did pre-patch; xu4 said I needed a better UnixLib; Curl wanted CACertificates and couldn’t determine that “CaCertificates” was that thing. It worked anyway, but from that point onward trying to do anything with PackMan slipped in a command to uninstall Curl.

I’ve fixed the Curl packages so it depends on “CaCertificates”. If you upgrade Curl it should hopefully stop PackMan trying to uninstall it all the time.

I also had a look at xu4 and can get it to build, but it won’t run. I’ll have another go soon. I believe the original source for AlienBlaster has changed location and possibly been updated so the build in the GCCSDK recipe to build it needs to be fixed before I can create a new package for that.

As I’ve said before, if there is any particular packages from the autobuilder that don’t work on the Raspberry Pi 3 I can always try a rebuild and upload the results.

Curl package works fine now, so that’s great.

I actually did get xu4 to run with PatchSWP, but I think it requires UnixHome and a heftier memory slice than the default to actually run.

The package that’s causing me the most trouble right now is actually OpenSSH. PatchSWP works for ssh itself and ssh-keygen, but scp remains a disaster. I’m not sure how much of that is just the build/configure setup, though. Running it normally produces the error

File ‘$.local.scratch.atm26.riscos.gccsdk.env.bin.ssh’ not found

which implies it’s inherited some unusable default from the build system for its SSH location. That can be addressed with the -S option, but doing that results in a process hang and occasionally also causes the Task Window to crash and the Raspberry Pi logo in the lower right to vanish, with a message like

Internal error: abort on data transfer at &FC0164E0

This usually wedges the system so hard I have to pull the plug. sftp is better-behaved but still seems incomplete; it terminates immediately with the message

socketpair: Protocol not supported

scp (or some similarly effective method of transferring files securely over the network) is really the biggest blocker for me at this point; it doesn’t help me if I can do the work on the system if I can’t get it off again afterwards! My current workarounds are copying files to the loader directory or copy-pasting giant chunks of Base64-encoded data into a Nettle window, and neither is exactly ideal.