RISC OS on the Raspberry Pi

Jess, I don’t know why you’re so anti-BB wrt display stuff

I don’t have a monitor that the BB could run natively. That is why it is a non starter for me.

However the point I was trying to make was that no one solution is best overall.

If you have a suitable 1920 × 1080 monitor (or perhaps if 1024×768 is what you require) the BB would be a far better option than the Pi.

If you need very fast disk I/O then nothing will beat the Iyonix.

In my situation a Pi or Panda might be better than my Iyonix, but the Pi is cheap enough to buy to play with.

I’m not sure why you feel the need to be on the defensive though, because surely once Pi RISC OS is a reality, won’t the Arm Mini get a cheaper lower powered brother (with better display abilities)?

(deleted rant about 1280×1024@60hz and higher being available in R-Comp MDFs/disc/OS)

I have to agree that I’m testing some stunning screens for use in the future, so Steffen’s certainly on the right track, although without the necessary stability in other products, I think there’s still plenty of life in BB still.

Aha! I found a public document which describes the DWC_OTG USB registers… it’s in the datasheet for the Ralink RT3052 router chip (pp130-179). That looks mostly like a cut and paste from Synopsys documentation.

Regarding GPL – please can people note that while it is a much more permissive licence than many, it is not a free licence as it is only compatible with itself and requires further revisions and associated code to also be relicenced as GPL. That does not fit my definition of “free”.

To this degree, one could argue that it is only marginally “free-er” (or, perhaps, “less restrictive”) than the current RISC OS licence; and while some might see Castle’s licence as a problem, the GPL also presents a different set of problems…

Best wishes,

Rick.

Aha! I found a public document which describes the DWC_OTG USB registers

Excellent – that means (I assume) that we now have documentation for the USB chip on the Pi at last.

Excellent – that means (I assume) that we now have documentation for the USB chip on the Pi at last.

49 pages sounds way short, to be full or enough documentation for USB hardware. Theo says “describes the DWC_OTG USB registers” So sounds like a start for public availability of documentation.

I could probably rig up a NIC off the GPIO actually. Possibly hook up a Digilent “PMOD” NIC or wire it up to one of my FPGA Boards that already has a NIC.

Would multiple interfaces be possible?

If GPIO were faster than the USB interface*, then a combi SATA, NIC and PS2 interface (and widget?) ought to provide a working system, but still be useful when USB works.

RISC OS supports multiple NICs’ This is how I got network drivers in EtherGEP working. The idea here would be to provide an open source SPI driver that developers could tweak the basics to get things moving. I’d like to see a generic SPI filesystem driver. I’ve never written a filesystem module, only network.

I hadn’t heard of SPI before, but it appears to be a serial exansion bus, with quite a large range of speed.

Am I right in thinking you are suggesting a basic system for the bus, allowing people to write drivers for periferals?

Would this also (potentially) work on older hardware via the serial port?

I think SPI uses around 3.3V levels (as in the cheap’n’dirty way to bit bash SD cards). Serial is…something like +/- 9V (or so, depends on implementation, I’ve seen +/- 5V to +/- 14V).

I hadn’t heard of SPI before, but it appears to be a serial exansion bus, with quite a large range of speed.

Am I right in thinking you are suggesting a basic system for the bus, allowing people to write drivers for periferals?

Would this also (potentially) work on older hardware via the serial port?

No. There is no point in putting a basic system for the bus in place as its so simple (essentially its like writing a register to a card). I’d planned to write a driver where someone wanting to get something up and working on their new system could simply rewrite/repoint the code that writes to the GPIO ports so suit their particular hardware. They could then hook up their hardware to that GPIO port and bring up the rest of the operating system. This way they would have a working IO while the HAL was developed and eventually replace the SPI functions with USB/Native hardware on the machine. The idea here is to enable fast bringup of new boards.

I’ll need to have a think about how to implement a simple keyboard/mouse interface over the GPIO. I dont think PS2 would work too well without external components. However a small CPLD would likely be enough.

Note i dont really care too much about performace here.

Re: Raspberry Pi disc image proposals

Director, Spr2Png, IClear, PtrCopy, Shanghai(Dave Chapman version), NapoleonII

Re: Raspberry Pi disc image proposals

Director, Spr2Png, IClear, PtrCopy, Shanghai(Dave Chapman version), NapoleonII

Spr2Png is not ARM7 safe and relied on a CLib bug now fixed. Not included
!Director – works after a fashion but has issues.Included for now but may be withdrawn for user download only (with warning).
IClear – included
PtrCopy – not found on web, may not be ARMv7 safe
Shanhai – not found on web, may not be ARMv7 safe
NapoleonII – included.

!Director – works after a fashion but has issues

I noticed two issues. It has to be started with alignment exceptions off and the very usefull feature menu click on window title bar (which shows a filesystem path) doesn’t work at all.
Adjust click at a disc icon at the iconbar does work.

I noticed two issues.

It also causes an exception when you Quit it.

The VFP can be enabled from supervisor mode by setting the SVC and user enable bits for coprocessors 10 and 11 then setting the EN bit using the fmxr instruction to control register fpexc with bit 30 set.

On the 21st I checked in some code that will allow the VFPSupport module to run on the Pi, so you should now be using that instead of enabling VFP manually. Just bear in mind that there isn’t any actual “VFP support code” yet, so if you use the coprocessor outside of “RunFast” mode (IIRC disabling default NaN mode or flush to zero will do this) then you’ll get aborts whenever it encounters some maths it thinks it can’t handle in hardware.

I’m trying to format a 1TB USB drive for use with RISC OS, I’ve tried multiple partitions and a single partition of FAT32 and that doesn’t seem to work. I also tried to use !HForm and it detects the size of the Disc in MB, but then just hangs indefinately, ESC exits out as expected.
I’ve formatted a USB stick (2GB I think) with !HForm that works fine, and my other USB sticks work fine.
Was just wondering if anyone knew the likely reason for the failure, is it the disc size or the disc type that is more likely?

Slightly off topic, but the reason I’m using RISC OS is to get back into C programming on RISC OS – I started in computing this way (well actually 6502 on a BBC B, oh yes! I like pain). Is there any kind of quick reference for using the compiler (in my case the linker). I can write the code OK, and it compiles, but getting the linker preferences right is a pain, and the header files don’t seem to be helpful – or maybe I’m not translating them right for the GUI interface?
FYI i mean the ROOL Compiler not GCC – I could use gcc and I would probably have it working, but for me it just seems wrong on RISC OS to use GCC, and tcp/ip socket programming in BASIC is just wrong (can you do it?)

In January, Dave Higton wrote:

Note that SwiftJPEG fails on JPEGs from some common sources, with an “Outside file at line nnn” error. Andrew Hodgkinson is the maintainer. I reported the fault last Autumn, but Andrew said at the time he was busy

This is finally fixed.

http://pond.org.uk/swiftjpeg/

Malcolm:

RISC OS can only currently access the first 256 GB of any disc, irrespective of how it’s formatted. As standard, RISC OS also requires that FAT16 and FAT32 discs are 2 GB or less: the third-party utility Fat32FS can work around this limit, but the 256 GB limit still applies even then.

I think it should be possible to use HForm to format the first quarter of a 1 TB drive to FileCore format. You do need to override the number of cylinders it suggests in order to ensure you don’t go over 256 GB – HForm doesn’t check this for you.

Does CDFaker work on the R-Pi? If it does, could it be included in the distro perhaps? Could be useful to people wanting to install the ROOL tools.

Fat32FS can work around this limit, but the 256 GB limit still applies even then.

I was under the impression fat32fs used a workaround for that limitation.

(It also supports partitions, but only one at a time)

Why is 256 GB for a non-filecore disc the limit? What am I missing?

Fat32FS works with 1 TB drives IIRC, but has to fake partitions for SCSIFS to achieve this, because it uses SCSIFS filecore sector ops. If it used 16 byte SCSI Read Ops, it could address a lot more sectors.

I was under the impression that Fat32FS hooked into the stack at the SCSIFS_SectorDiscOp level. This is only able to access 2^29 sectors (the top three bits being used for the drive number), which equates to 256 GB, assuming 512-byte sectors. It seems some people are using the slightly questionable pseudo-partition support in SCSIFS to get around that, but those partitions are still limited to 256 GB for the same reason, and come at the cost of eating up precious extra drive numbers (4+4 drives really isn’t enough).

There is no improvement at present if you use SCSIFS_DiscOp64 – internally, FileCore converts these to the same 3+29-bit sector offset as is exposed by the SectorDiscOp API. I’m sure this has been gone over before in various threads. What is needed is for FileCore to work on 64-bit disc addresses internally, and to offer client filing systems the chance to receive their disc addresses in 64-bit form at the low-level interface.

Ben:
HForm hangs completely, it doesn’t give me an option to specify cylinders, it just shows the disc size then sits with a flashing cursor…I left it for an hour and nothing.

Anyway I managed to get my disc working using formatting the disc with 32bit Fat, I think the default is 16 bit for mkfs.vfat.
It see’s the full disc anyway, so that’s good.
I’m going to try creating a riscos partition type ad I believe?
Then try formating that on riscos….see if that works, maybe it’s just reading the disc cylinders that causes hform to barf, and the rest is OK.

Ben: Well, not sure what problems I was having before.
I think this is down to the previous Pi firmware, it did seem to cause some crashes I hadn’t seen before in GrapeVine.
Also seeing the format option for hard discs in the menu was strange, as thinking back I never had that option on my A3000. I had to use a special formatting program.
I tried various combinations of partitions and mkfs.vfat and all seem to work perfectly.
So it formats the full 1TB, no issues as yet.

WPB: CDFaker works fine on the Pi, I used it to install the tools before the USB stick arrived!