Decadent Singularity
 
[Most Recent Entries] [Calendar View] [Friends View]

Saturday, September 9th, 2023

    Time Event
    1:37p
    RISC OS came with x86 emulator
    There was also an option for adding actual x86 CPU, which shared memory with ARM.
    It allowed running DOS and Windows 95/98/NT in a desktop window.
    Apparently it also routed floppy drive access to them.
    https://archive.org/details/pc-emulator-v-1.8-0484-162-issue-2-march-1992

    Current Mood: amused
    2:03p
    RISC OS Has No Registry
    How does it start and configure then?
    There is a BIOS ROM.
    Its job is to run the !Boot application.
    !Boot always resides in the core of the FS.
    BIOS also has basic flash/network/cdrom/floppy driver.
    So if you damaged your !Boot, you can easily recover.

    On simpler installation, without an external kernel, !Boot can be just a script or an executable, instead of a proper app.

    Now the root !Boot folder has another !Boot (can be an app or a script). That !Boot loads all drivers, starts desktop and does user login. The root boot also has !Run, which runs when the user clicks the root !Boot to configure OS (akin to Windows control panel, but a bit smarter and much more flexible).

    Each application also has its own !Boot, which can optionally be `seen` by the root !Boot, which registers all services and kernel modules associated with that application. That is how file associations and file icons gets registered, without cluttering the registry. Applications are also `seen` when the user enters their folder. Same way, newly connected devices designed to work with RISC OS can `hard-load` the application necessary to work with them. For example, GPU used to install its driver, so user wont have to do the installation.

    Major variables, like boot method, are saved to CMOS, and everything else gets saved under !Boot, inside config files, which user isn't supposed to edit (compared to Linux with its /etc). If some service needs startup configuration, it should install its configuration app under !Boot.

    File type can also have several apps associated with it, it all depends on which app is currently `seen` or `booted`.

    It also has a few funny convention on how to switch association, without changing file name. For example to debug existing executable, you change its type to DebImage, which passes it to a debugger. That is nice since it doesn't change the name of the executable, which is a thing many Unix programs depends upon (i.e. grep could behave differently depending on its symlink name) and you don't need to start a debugger separately (like I do currently with GDB).

    That is just one step before a semantic filesystem, or database filesystem, where each file can have multiple type tags or faces, depending on how it is used. These semantic filesystems are very good for modern LLM driven AIs, since they can easily look through thousands of files, as long as they are tagged properly.



    Current Mood: amused
    4:34p
    RISC OS running Windows
    Back in the day RISC OS offered the stuff Wine now does on Linux.



    Current Mood: amused
    4:47p
    In addition to paint App, RISC OS came with a vector editor
    It also worked with outline fonts and could shade interiors of the outlines in various ways.




    Current Mood: amused
    8:13p
    Nancy becomes an archeologist in early Assassin's Creed wannabe
    https://www.youtube.com/watch?v=c_y5V-xdZGY




    Current Mood: amused
    11:59p
    !Ankh
    Ok. I gave up running !Ankh as is.

    As I understand &ff8 files have no header and are loaded at &8000.
    Unsure about the relocatables though, but ankh's RunImage appear to have sensible ARM there.
    I read BASIC games can have inline ARM and machine code, which can be a nuisance.

    Ghidra only supports ARM4 (I guess Ankh uses ARM3).
    And I was unable to get IDA Pro working on win11.
    I don't remember if IDA had ARM3 disassembler.

    Anyway, now I need to get RPCEmu compiled and modified to do traces and breakpoints on CD access.
    This approach is kinda overkill, but I don't feel brave.

    Documentation states there should BLNV instructions (00 00 00 FB), if the executable is not compressed or relocatable, but instead there are movs (00 00 A1 E1)
    http://www.riscos.com/support/developers/prm/objectformat.html

    So apparently RISC OS C compiler produced non-conforming code?

    Also, I'm curious why they haven't introduced Thumb initially? Memory was still expensive in 1987, so instruction size is a thing even today today due to cache sizes.



    Current Mood: amused

    << Previous Day 2023/09/09
    [Calendar]
    Next Day >>

About LJ.Rossia.org