[Oberon] A2 Repository
Bernhard.Treutwein at Verwaltung.Uni-Muenchen.DE
Tue Jul 2 16:08:53 CEST 2019
thanks for the invested time and work although the results are quite a bit disappointing.
@Felix: Any chances for recovery?
>From: Michael Schierl [mailto:schierlm at gmx.de]
>Sent: Saturday, June 29, 2019 10:10 PM
>To: oberon at lists.inf.ethz.ch
>Subject: Re: [Oberon] A2 Repository
>Am 20.06.2019 um 23:25 schrieb Michael Schierl:
>> When taking r7367 and using Heaps.Mod from r7366 (plus adding an empty
>> CheckAssignment* implementation), the system boots again. So, the triple
>> fault is likely caused by a change in Heaps.Mod.
>After some more investigation, it is only indirectly the case.
>The culprit is the variable "cardSet" introduced here:
>As a consequence, the size of the linked images increases by 128KB, and
>since the default OBL.Bin loader tries to load the linked image into
>conventional memory (640K ought to be enough for anybody), the image
>just got too large.
>> For r7409/r7412/r7461 there were many compile time errors I was not
>> quickly able to fix.
>Reason here was the change in
>that changed the namespaces to be separated by dashes instead of dots. I
>am unsure why this broke the Bios32 build but not the WinAOS build, but
>since this got fixed some revisions later, probably it is not important
>Anyway, when reverting this change (and also reverting the change how
>GetModuleSegmentedName is built), these versions compile and run again, too.
>Coming back to our main goal of recompiling a recent A2 version: The
>linked image of recent versions is a bit over 800KB, so I assume it is
>unrealistic to get this stripped (without breaking the system) to fit
>within 640KB. There seems to be a second Boot loader (OBLUnreal.Bin)
>available, which supposedly tries to avoid this limitation by switching
>to "Unreal mode" (also known as flat memory segment hack) and loading
>the image into extended memory instead.
>However, I was not able to make this bootloader boot (on VirtualBox, at
>least), neither when using a current version of A2 nor when using an old
>version that still boots fine with OBL.Bin.
>So I guess, to wrap this up, the issue with recent A2 native builds is
>that the linked image got too large for being loaded with OBL.Bin, and
>the alternative OBLUnreal.Bin does not work (on all hardware where
>OBL.Bin worked). Probably one could spend a lot of time finding the
>latest version that can get stripped down to fit into conventional
>memory, but I don't see a point in doing that myself.
>Other solutions could be to either implement a self-decompressing image
>(so it can be loaded with original OBL.bin; but even that might be "not
>enough" at some point) or add support for creating Multiboot or
>Multiboot2 images (and load them with a Multiboot-supporting bootloader,
>like SYSLINUX, ISOLINUX, PXELINUX or GRUB; disadvantage being that it is
>no longer possible to install A2 to an empty hard disk just from within
>A2). But both of them are a lot more work than I'd like to spend on this
>So I will stop my A2 endeavors here - since I also noticed that
>OberonGadgets apparently disappeared from later A2 versions, I'd
>probably stick with earlier versions anyway :D
More information about the Oberon