risc pc stable release

Is there or has there been a stable working release from here that will work on a vanilla riscpc? I am interested in trying things out, and am loath to try downloads that just won’t work at all. Incidentally, also knowing that this is most likely the wrong place to ask, can anyone tell me why I can’t format a hdd bigger to anything more than 8gb in ro3.7? I have put a 120gb drive in and that’s as much as I can get out of it. I’ve trawled the net for answers and cant find a damn thing. Would any verion of 5 change that?

Is there or has there been a stable working release from here that will work on a vanilla riscpc?

Have you had a look at the IOMD thread and elsewhere on the site for the info you’re after? As for “stable”, I think the Iyonix build is the only one to be officially considered stable.

Incidentally… why I can’t format a hdd bigger to anything more than 8gb in ro3.7?

You could try searching the comp.sys.acorn.* newsgroups (if you’ve not already done so) and also asking on The Icon Bar.

I have put a 120gb drive in and that’s as much as I can get out of it.

RISC OS 5 for the BeagleBoard is usually used with SCSIFS, and there’s no problem using a harddisk with hundreds of gigabytes with that.

can anyone tell me why I can’t format a hdd bigger to anything more than 8gb in ro3.7? I have put a 120gb drive in and that’s as much as I can get out of it.

It sounds like you might be using the wrong version of HForm. According to riscos.info RISC OS 3.7 should work with drives/partitions up to 128GB (although you need to install a ROM patch or *configure ADFSBuffers 0 in order to reliably use anything over 2GB). Plus anything over a few GB will result in more and more space being wasted due to limitations in the disc format used by RISC OS 3.

I’d point you towards the copy of the RISC OS 3.7 HForm on ROL’s Acorn legacy FTP site, except that the site still seems to be a bit broken after their server outage over the weekend (all the links result in 403 errors). So instead of that you can try using ROOL’s copy of HForm from this page (I think it should work on RISC OS 3.7, but I’m not sure).

Using RISC OS 5 on your RiscPC would allow you to use a newer disc format (so you can use long filenames and partitions up to 256GB in size), and it wouldn’t require you to use the ROM patch or ADFSBuffers fix. But the big problem with using RISC OS 5 (apart from the RiscPC version not being guaranteed to be complete or stable) is that you’d still need to keep an old-format disc in the machine in order to perform the softload from. I’m also not sure what will happen when RISC OS 3.7 sees the new format disc (hopefully it will just ignore it instead of throwing up an error and preventing the softload from ocurring)

...RISC OS 3.7 HForm on ROL’s Acorn legacy FTP site, except that the site still seems to be a bit broken after their server outage over the weekend…

Now apparently working again!

Using RISC OS 5 on your RiscPC would allow you to use a newer disc format (so you can use long filenames and partitions up to 256GB in size),........you’d still need to keep an old-format disc in the machine in order to perform the softload from.

The problem is of course, that the Risc PC has a single IDE, and that would mean sacrificing the CD-ROM.

This is where partitions would be useful.

Dave Higton thinks it likely that an MSDOS style partition table can co-exist with a standard ADFS formatted area.

If so that would give the (future) possibility of a 3.7 system (with say 2G) as the first partition and and new format RO5 as a second partition. Presumably, RO 5 would look at the partition table and !boot from whichever partition was flagged to boot from, allowing two totally separate systems.

Dave Higton thinks it likely that an MSDOS style partition table can co-exist with a standard ADFS formatted area.

If so that would give the possibility of a 3.7 system (with say 2G) as the first partition and and new format RO5 as a second partition. Presumably, RO 5 would look at the partition table and !boot from whichever partition was flagged to boot from, allowing two totally separate systems.

That looks like a misinterpretation of what I wrote, unless you’re talking about some hypothetical date in the future where RISC OS can be installed on industry-standard partitions.

unless you’re talking about some hypothetical date in the future where RISC OS can be installed on industry-standard partitions.

That’s exactly what I mean (I have added the word future to my post to remove the ambiguity.)

As requested in this thread: https://www.riscosopen.org/forum/forums/5/topics/499

I think partition support will be very important in moving RO 5 to machines that ordinary users would use as their regular machine.

I think partition support will be very important in moving RO 5 to machines that ordinary users would use as their regular machine.

I’m inclined to agree with you.

Is it true to say that RISC OS only supports discs up to 256 GiB? I’m not really familiar with the situation. There are some 64 bit disc operations available, but I don’t think that overall we have support beyond 256 GiB.

The point of the question is that it seems to me that adding partition support is relatively easy: within whichever block addresses the medium, it is only necessary to add a sector offset (which will nowadays have to be 64 bits); the offset is central to all disc operations on that “drive” (partition). Then there is, of course, code to add to deal with a partition table. That has to be easier than defining a new disc format.

However, it still only allows us to use discs up to 2 TiB. There are already bigger discs.

Is it true to say that RISC OS only supports discs up to 256 GiB? I’m not really familiar with the situation. There are some 64 bit disc operations available, but I don’t think that overall we have support beyond 256 GiB

From posts I have read, it seems that 64 bit operations have been defined, but only mapped to the old operations.

However, I don’t know whether this applies to the offset too. (The impression I got from how fat32fs gets around the limit, is it doesn’t, but I am not a programmer, so that impression could easily be wrong.) **

The situation might be that it is just a partition size limit (which could be fixed).

• (edit) Jeff Doggett “worked around the limit by faking a partition offset” So the offset must be fully implemented on SCSIFS. How that relates to IDE drives on an Iyonix, may be a completely different matter.

However, it still only allows us to use discs up to 2 TiB. There are already bigger discs.

I’m not sure I would want to use a bigger disk via USB 2 (especially RISC OS USB at present) or PIO.

I’m not sure I would want to use a bigger disk via USB 2 (especially RISC OS USB at present) or PIO.

A lot of fuss is made about disc transfer speeds. Most of the time they bear no relation to the disc size. You just want a file, selected from a larger or smaller number of files on the disc, so disc size doesn’t matter. The occasion on which it does matter is when taking a complete backup. I don’t know about you, but when I do take a complete backup, I don’t just sit there waiting for it to finish.

PIO is pretty much dead these days. It only comes up in the context of RISC OS when talking about hardware some years old. I suspect that USB3 won’t be all that far in the future, even for the RISC OS community. (That’s just a guess based on the steady onward march of technology; I have no special insight.)

Is it true to say that RISC OS only supports discs up to 256 GiB? I’m not really familiar with the situation. There are some 64 bit disc operations available, but I don’t think that overall we have support beyond 256 GiB.

The 256GB is a limit imposed by the current FileCore API. When FileCore calls hardware drivers it passes the drive number and the disc address in the same register, so there’s only 29 bits available for the disc address. With 512 byte sectors that equates to a max partition size of 256GB. It’s possible there may also be a 256GB limit within the disc format itself, but I know practically nothing about how the disc format works.

From posts I have read, it seems that 64 bit operations have been defined, but only mapped to the old operations.

Yes, I believe that’s correct.

A lot of fuss is made about disc transfer speeds. Most of the time they bear no relation to the disc size. You just want a file, selected from a larger or smaller number of files on the disc, so disc size doesn’t matter.

But what use would a disk that big be on current RISC OS hardware? Storing big files for a media player is the main use I would find, so copy speed is important. (Not that I’m saying I wouldn’t want the support, just that a 2TB limit isn’t a bother until all new disks are bigger.)

PIO is pretty much dead these days. It only comes up in the context of RISC OS when talking about hardware some years old.

Such as the Iyonix? It is limited to PIO when accessing beyond 128GB. (Which would be another reason partitions would be useful – a fast one and a slow one)

Such as the Iyonix?

Exactly.