[Oberon] RISC.img format

[Tomas Kral]

Dear Paul,

I bought Pepino LX9 board recently. I am studying Project  Oberon 2013,
making my firsts steps. My earlier experience comes from Pascal and
Modula on ATARI-ST.

I asked a similar question about RISC.img format here, 
http://saanlima.com/forum/viewtopic.php?f=14&t=1280&sid=6771605d7bfdce198fa7d7cba611aab7

fdisk reports vfat and OBS partitons on my uSD card imaged with
RISC.img, size 256MB.

Having read chapters on file system - Files.Mod, FileDir.Mod,
I wish to know, if OBS partition grows somehow, so I can get more
sectors allocated on my 2GB uSD?

I also missed the point of media formating, as FileDir.Mod does not seem
to provide Format command in its ToolBox.

Many thanks.

-- 
Tomas Kral <thomas.kral at email.cz>


> 
> 
> Dear Oberoners,
> 
> I've been asked a couple of questions about the RISC.img SD-Card image
> downloadable from http://projectoberon.com for the FPGA RISC5 Oberon
> systems.  (If you can, please post questions publically rather than
> emailing me privately - otherwise I have to assume it's a private matter
> which is more time-consuming to deal with - if I can ever get to it - and
> doesn't benefit others.)
> 
> The RISC Oberon system boots from an SD-Card and uses it as its file
> system.  This filesystem is much simpler than common contemporary
> filesystems such as FAT, FAT32, NTFS, exFAT, EXT4 etc. and is not in any
> way compatible.  (On the original Ceres, the backup floppy disk format was
> very close to the FAT12 format, but with an altered directory to cope with
> long filenames, which were not in those days supported on FAT).
> 
> It would have been easy to make the RISC5 Oberon filesystem (including its
> reserved area for the bootfile) begin at offset 0 from the beginning of
> the SD-Card.  This would have dedicated the SD-Card to Oberon use, but
> simplified the bootloader.
> 
> Or alternatively, the Oberon filesystem could have perhaps been stored as
> a file in the FAT filesystem on the SD-Card, making it much more
> accessible to utilities running on other computers.  But this convenience
> would have come at a high cost: it would have made the bootloader much
> more complicated, and given many more possibilities for distracting
> problems in development.
> 
> In the end, it was decided to place the Oberon filesystem at a fixed
> offset from the beginning of the disk.  This was a trivial change to the
> bootloader, keeping it easily-understandable and within one block ram
> (BRAM) of the FPGA.
> 
> This meant that FAT-compatible data structures, and a reasonable-size and
> perhaps useful (256MB) FAT partition could still exist at the beginning of
> the disk.  If this FAT partition has nothing in it, it compresses very
> well and therefore does not significantly increase the RISC.img download
> time.
> 
> The MBR partition id for the Oberon filesystem was chosen as 0FFh, because
> the ids are historically rather a free-for-all and the filesystem is not
> exactly the same format as any that have gone before, even the ETH
> PC-based Oberon filesystems.  0FFh is clearly an arbitrary value, and also
> was only used by others for private data structures rather than for
> filesystems which were interoperable amongst systems.
> 
> Note that a lot of the motivation for this was defensive.  For example it
> makes it more difficult for the Oberon filesystem to be destroyed when the
> SD-Card is inserted in a Windows system.
> 
> When submitting some early additions to Peter de Wachter's RISC emulator
> 
> https://github.com/pdewacht/oberon-risc-emu
> 
> for emulated RS232 file transfer which he kindly incorporated, I also
> included a quick check on startup which allows the use of a disk image
> which only contains the Oberon file system (called .OBERON.FS in the
> Windows binary distribution of the emulator which I put on
> http://projectoberon.com).
> 
> This check is for the magic number 9B1EA38DH (FileDir.DirMark) which is at
> the beginning of the root directory sector.  Oberon uses a "parity" scheme
> for sector numbers, making all of them divisible by 29, so the first
> usable Oberon sector, number 29, begins at SD-Card sector offset 80002H. 
> This slightly odd value comes from the fact that SD-Cards have 512-byte
> sectors, but Oberon uses two of these (1K) for each Oberon sector, and
> that sector 0 is not used.
> 
> So if you are using a nice operating system and you know what you are
> doing (because it allows dangerous commands such as dd) you can extract
> the Oberon file system from the image with a command like (262145 = 40001H
> = 80002H * 512 DIV 1024)
> 
>   dd if=RISC.img of=.OBERON.FS  obs=1024 ibs=1024 skip=262145
> 
> and you can even (sudo) write it directly back to a real SD-Card with
> something like
> 
>   dd if=.OBERON.FS of=/dev/disk1 obs=1024 ibs=1024 seek=262145
> 
> The name .OBERON.FS was chosen to make it look like a system file, which
> would be totally destroyed if someone opened it and saved it with a text
> editor, for example.
> 
> Hope that's useful!
> Cheers,
> Paul
> 
> 
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
> 
> 
> 
>