Raspberry Pi 3

It seems that the current Pi3 boot is 32 bit; or as somebody on another forum said – it is an ARMv8 running ARMv7 code optimised for ARMv6. ;-)

I figure it’s no big deal – that the operating system will take over and do what it wants regardless of how the machine booted?
Of more concern is that it currently appears to run slower than a Pi1. I’m guessing this will get sorted real soon.

Tried the PI3 with RO ( no luck, it does start but nothing works !sunfish, FTPc- in fact almost nothing)

The raspian linux distro works ok.
(I have it now behind my TV with openELEC but in system it says it reported to run at 600Mhz)

Have to wait a little bit longer for a more stable and/or better ROM.
By far not even close to the speed of my PandaBoard.

I’m still waiting for my Pi 3 to arrive.

However, I thought I’d read over the over clocking configuration as I understand that force_turbo is not working as it used to with the Pi 3:
force_turbo

Just wondered if anyone had tried ‘arm_freq_min’ which sets the minimum frequency when not forcing turbo?

in fact almost nothing

I would assume ZPP is at fault here, my version of ZAP also suffers.

My BASIC app seems to run fine.

in fact almost nothing

I would assume ZPP is at fault here, my version of ZAP also suffers.

Is it an abort on data transfer or an undefined instruction?

AODT → Probably zero page related (although I would have thought there’d be a fixed version of Zap by now)
Undefined instruction (or “Illegal instruction”) → Probably related to the SWP instruction no longer being supported. Pretty much any program which uses UnixLib will be affected by this

@Anthony: no change with arm_freq_min=1200…

StrongEd is working without any problems, not much else tested than my basic/assembler progi’s. I have a weird error (software integer division routine, not the new sdiv/udiv, those work okay) that doesn’t crash on RPI2 and IGEPv5, but does crash on the RPI3.

although I would have thought there’d be a fixed version of Zap by now

Unfortunately not. Zap fills the zero pain log with screeds of errors, even opening a blank document. Since I use the PandaBoard for all my ZPP checks, I have given up on Zap there and am trying to get to grips with StrongEd (rather a shock to the system after all the years with Zap – no offence intended Fred!).

Zap fills the zero pain log with screeds of errors

Version??????

Zap 1.48 (12 Jul 2015) tnk-11 seems OK here, not very extensively used it should be said. I don’t recall where this version came from, now isn’t that helpful!

P.S. Found it, search the forum why not. http://www.tankstage.co.uk/Software/ZeroZap.zip

http://www.tankstage.co.uk/Software/ZeroZap.zip works. I know, I use it.

Sorry chaps – I take that back. I thought I was using 1.48, tnk 11. It appears the PB was running a version that hadn’t upgraded properly. I screwed up somewhere, since all my other hardware is running 1.48, tnk 11.

Is it an abort on data transfer or an undefined instruction?

Yes :@)

AODT → Probably zero page related (although I would have thought there’d be a fixed version of Zap by now)

Most likely – I haven’t had time to look! – ah yes as others have pointed out! I must update it.

I would also like to confirm that I have Basalt running on it!

I’m setting up RO on a Pi 3 and am getting AODT’s from Zap whenever I try to edit a file other than type text. AODT is at 20BB5644 on Zap 1.48 tnk 11.

I’ve a modified CONFIG.TXT from a Pi 2 which was based on a recommendation by Chris Hall for modest upclocking. This contains:

fake_vsync_isr=1
framebuffer_swap=0
gpu_mem=64
arm_freq=1200
gpu_freq=300
core_freq=450
sdram_freq=450
arm_control=0×1000
init_emmc_clock=100000000
kernel=RISCOS.IMG
hdmi_force_hotplug=1
config_hdmi_boost=4
hdmi_force_hotplug=1
config_hdmi_boost=4
disable_overscan=1
hdmi_drive=2

Note that the ‘force_turbo=1’ command for the Pi 2 is removed. I checked the speed and it’s about two thirds the speed of a Pi 2 running at 1000MHz.

My impression is that CONFIG.TXT is being ignored for some reason – the wide borders are there, and it also forgets the clock settings in ‘Alarm’. I took the usual care editing CONFIG.TXT.

I think we’re very close to OK.

Considering I only found out about the Pi 3 last Monday, and only started on this late this morning, I’m greatly impressed by the efforts of all concerned. Thanks!

Note that the ‘force_turbo=1’ command for the Pi 2 is removed. I checked the speed and it’s about two thirds the speed of a Pi 2 running at 1000MHz.

To pursuade force_turbo=1 to work on the RPi3 avoid_warnings=2 is required. This is the “hurry up” bit from my CONFIG/TXT.

avoid_warnings=2
force_turbo=1
arm_freq=1200
core_freq=450
sdram_freq=450

See https://www.riscosopen.org/forum/forums/5/topics/3966

To pursuade force_turbo=1 to work on the RPi3 avoid_warnings=2 is required. This is the “hurry up” bit from my CONFIG/TXT.

That did the trick – as you say, it flies!

FWIW I’m still stuck with the Zap problems – I re-copied the version from my ARMX6 and there’s no change. Still ‘Edit’ works, so I’ll use that for now.

Thanks for your help

I am getting AODT at offset &32340 in module Zap when I try to run !Zap on the model 3 Pi. That is the latest version on plingstore 1.48.7 so I am having to resort to !Edit.

I find CONFIG.TXT works OK for me, with the values:

fake_vsync_isr=1
framebuffer_swap=0
gpu_mem=64
init_emmc_clock=100000000
#gpu_freq=300
#arm_control=0x1000
avoid_warnings=2
force_turbo=1
arm_freq=1200
core_freq=450
sdram_freq=450
kernel=RISCOS.IMG

I am getting AODT at offset &32340 in module Zap when I try to run !Zap on the model 3 Pi. That is the latest version on plingstore 1.48.7 so I am having to resort to !Edit.

PlingStore is a bit behind the times.

The latest is zero page fixed Zap 1.48 (12 Jul 2015) tnk-11 at http://www.tankstage.co.uk/Software/ZeroZap.zip There seems to be some doubt above about how good this version is on the Pi3. It makes it to the iconbar here and seems OK as briefly tested on editing files other than ‘text’. ZeroZap is just the main Zap module, there could possibly be assorted grief lurking in Zap’s mode modules.

As far as I can see !Zap does not use the SharedUnixLibrary, if so it shouldn’t be falling into that particular hole.

HTH.

FWIW I’m still stuck with the Zap problems – I re-copied the version from my ARMX6 and there’s no change. Still ‘Edit’ works, so I’ll use that for now.

I think you find StrongED works just fine.

If you’re a Zap devotee then the latest as listed by David above is worth testing.
If it still has issues then report them and use StrongED

If you’re a Zap devotee then the latest as listed by David above is worth testing.

That’s the one I’m reporting on. It has ‘ZeroZap’.

BTW I tested the Pi 3 processing a real-world 500GB data file and got the following results:

Interesting.

Interesting.

Confusing I call it.
What units are the numbers in? Could be speed eg MB/s, or time eg centiseconds, or something else.
I suspect that the discs being used are not identical?
How was the file processd? In bytes, or in blocks?
What were the processor speeds?

Confusing I call it.
What units are the numbers in? Could be speed eg MB/s, or time eg centiseconds, or something else.

Speed referenced to a standard Iyonix running uncrunched BBCBasic; I was actually testing crunched vs uncrunched software! Just think of them as ‘speed factors’, for want of a better description.

I suspect that the discs being used are not identical?

The Iyonix and ARMX6 are as supplied, using HDD and SSD respectively. They’re not clocked or adjusted in any way.

RPis 2 & 3 use ‘SanDisk’ 32GB ‘fit’ pen drives. Zero uses 16GB, same source/type.

How was the file processed? In bytes, or in blocks?

Not relevant. Identical software and files throughout.

What were the processor speeds?

Pi 2 settings are as recommended by C Hall – clocked to 1GHz. Pi 3 – please see the settings earlier in the thread.

Sorry about the confusion – I did consider adding %s, but thought that might be misleading.

I don’t think this test does justice to the real-world speed differences between the Iyo and Pi hardware. I haven’t tested a Pi3, but IME the Pi2 clocked at 1000/500/500 is considerably more than 20-30% faster than an Iyonix, based on the following tasks:

1. Rotate a 24MB Sprite in Photodesk (image cache 100000k) to 45deg., resize to fit, bi-cubic selected:
Iyonix 22 secs; Pi2 7 secs.

2. Render TFL Base-Map-master (London tube map) pdf (1412k) using GView @ 90dpi, colour depth as file:
Iyonix 110 secs; Pi 2 52 secs.

3. Load Artworks Apple into Artworks, zoom to 400% from 100%:
Iyonix 7 secs; Pi2 <2 secs.

4. Thump slideshow of 12 jpegs (+/- 4MB each), best dither, fit screen, step time = 0 secs:
Iyonix 32 secs from HD (same from RAM); Pi2 28 secs from USB memory stick (25 secs from RAM).

Subjectively the Pi2 @ 1000MHz feels roughly twice as quick as the Iyo (as it should, purely on clock speed); I would expect a Pi3 running at 1200MHz to be half as fast again.

‘*cache off’ on the RPi3 causes an ‘Internal error abort on data transfer’ to start filling the screen. Power off and on is needed to recover.

Try today’s ROM – I checked in a fix for that last night.

I was using a rom I built today. I just tried the one built overnight. That also causes a complete lock up.

Hmm, so I see. I wonder how long that’s been broken – both Pi 2 and 3 seem to be affected. The bug I fixed yesterday would have been causing a crash for all (high vector) models of Pi, but this looks to be a different issue, potentially DWCDriver related.