Re: [Oberon] PO2013 - SD Image Tool
That would be expected behavior if the switches, when closed, grounded the connecting pins. --- thomas.kral@email.cz wrote: From: Tomas Kral <thomas.kral@email.cz> To: oberon@lists.inf.ethz.ch Subject: Re: [Oberon] PO2013 - SD Image Tool Date: Sat, 23 May 2020 11:24:09 +0200 Hi, Some progress made. This is truly blank system. 7| Watch Modules space (bytes) 47296 9 % Heap speace 0 0 % Disk sectors 1 0 % Switches: swi0 = 0 , swi1 = 1 Time 285507~ EDIT On the board sw0 is on, while sw1 is off, is this a typo in Oberon0 code?
Hi John,
Disk sectors 1 0 % Switches: swi0 = 0 , swi1 = 1
That would be expected behavior if the switches, when closed, grounded the connecting pins.
That was my first thought too but I looked at the schematic and the IO is pulled up by a single resistor on the other side of the bit switches. It is indeed a typo in what I assume is Andreas' code: MODULE Oberon0; (*Oberon-0 command interpreter / AP 15.5.20 Extended Oberon*) ... IF SYSTEM.BIT(swi, 0) THEN RS232.Send(ORD("0")) ELSE RS232.Send(ORD("1")) END ; ... (https://github.com/andreaspirklbauer/Oberon-extended/blob/master/Sources/Obe...) Cheers, Paul
Hi, My build now works and boots. I was getting trap(4) LED=11000100 1 - array index 2 - type guard 3 - overflow 4 - access via NIL pointer <== is this one 5 - illegal proc 6 - division by 0 7 - assertion I new the code went as far as.. MODULE Oberon BEGIN OpenDisplay(DW DIV 8 * 5, DW DIV 8 * 3, DH); ... END Oberon. Would you believe that Oberon needs some fonts? -- Tomas Kral <thomas.kral@email.cz>
Am 23.05.2020 um 14:04 schrieb Tomas Kral:
Would you believe that Oberon needs some fonts?
If you want to boot Oberon without any fonts on disk, you can use this module here: https://github.com/schierlm/Oberon2013Modifications/blob/master/MinimalFonts... it has only one font which is used for everything, but it is embedded in the compiled .rsc file. Regards, Michael
Hi, Trying to compress my first build. $ hd RISC5.FS | tail 0008ef90 03 00 29 04 02 00 00 e9 00 00 29 44 f8 ff ff e9 |..).......)D....| 0008efa0 0a 00 00 e9 00 00 00 40 10 00 c0 8d 28 00 d0 a0 |.......@....(...| 0008efb0 04 00 e0 80 4c 2f 21 d1 38 00 00 80 10 00 e0 81 |....L/!.8.......| 0008efc0 01 00 08 00 18 00 e0 a0 03 00 00 e7 14 00 e0 80 |................| 0008efd0 00 00 00 90 1c 00 e0 b0 bc ff ff e7 18 00 e0 80 |................| 0008efe0 00 00 e0 8f 40 00 e8 4e 0f 00 00 c7 1c 00 e9 4e |....@..N.......N| 0008eff0 00 00 e0 af 04 00 e0 a0 08 00 e0 a1 10 00 c0 8d |................| 0008f000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 04000000 I may need to add 0x00 padding to align on 1K boundary, right? Last sector used? $ echo $(( (0x8f000 + 1023) / 1024 )) -- Tomas Kral <thomas.kral@email.cz>
Hi, Trying to compress my first build. $ hd RISC5.FS | tail 0008eff0 00 00 e0 af 04 00 e0 a0 08 00 e0 a1 10 00 c0 8d |................| 0008f000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 04000000 I may need to add 0x00 padding to align on 1K boundary, right? Last sector used? $ echo $(( (0x8f000 + 1023) / 1024 )) EDIT I am about to do this. $ dd if=RISC5.FS of=RISC5cmpr.FS bs=1k count=572 -- Tomas Kral <thomas.kral@email.cz>
Hi Tomas,
Trying to compress [the disk image of] my first build. ... 0008eff0 00 00 e0 af 04 00 e0 a0 08 00 e0 a1 10 00 c0 8d |................| 0008f000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
Just an observation: that last sector seems to have truncated code in it, code would normally end with a RISC5 B LNK (0C700000F) instruction. Maybe ok if this was garbage in memory, before a buffer was re-used for something else.
I may need to add 0x00 padding to align on 1K boundary, right?
No need if the file is always written in multiples of 1K. A virtual machine would probably do that if it's emulating Kernel.PutSector.
Last sector used?
$ echo $(( (0x8f000 + 1023) / 1024 ))
EDIT I am about to do this. $ dd if=RISC5.FS of=RISC5cmpr.FS bs=1k count=572
That seems ok but fiddly and error-prone. As Michael said, try zipping or gzipping both images and see if it's worth the extra effort of truncation, especially if it's just a backup. A better way might be to find the last allocated sector while the system is still running: Kernel.AllocSector takes a hint, and returns the next free sector after the hint, as a way of reducing fragmentation. This feature could be abused to get a map of allocated sectors. Cheers, Paul
Hi Paul,
Just an observation: that last sector seems to have truncated code in it, code would normally end with a RISC5 B LNK (0C700000F) instruction. Maybe ok if this was garbage in memory, before a buffer was re-used for something else.
Note taken. Cannot really tell, but OBERON.FS on uSD was blanked first, before I copied files over. System rebooted, as it does some sector housekeeping at start. Then truncated before first blank 1024 block. 0C700000F = big endian 0f0000c7 ??? Also I seem obsessed with OBERON.FS compression it cannot let go yet :-) I was warned. Paul, actually, didn't you do the same with your original image back in 2014? -- Tomas Kral <thomas.kral@email.cz>
Hi Tomas,
... rebooted, as it does some sector housekeeping at start.
This housekeeping code (FileDir.Init) is indeed what to study if you want to compress things further. It walks the directory recursively to find out what directory sectors are in use; and then for each file in the directory it reads the file header to find out what file sectors are in use. This builds the complete sector allocation map at the beginning of an Oberon session. Any sectors created during the session which are not linked to a named file in the directory are intentionally lost on shutdown. That is, temporary files in Oberon are simply files created without a name.
Also I seem obsessed with OBERON.FS compression it cannot let go yet :-)
Each directory sector can be further compressed if it is not full, as DirPage.m tells you the number of actually-used entries. (But each directory page except the root will be at least half-full.) But even if you wanted to send this data over a slow serial link, for example, it would still be much faster to send the individual files and let the filesystem be built on the RISC5. You don't need to send the directory sectors at all that way.
Then truncated before first blank 1024 block. ...didn't you do the same with your original image back in 2014?
If you mean I didn't truncate it at all, that's correct, see the reference to the original message I recently posted. Because the large amount of repetitive data compresses very well with standard utilities. Cheers, Paul
Hi, Anyway. Here are results of my efforts, sharing my build here. Is rather minimal, and a lot of it happened thanks to advice here in and off the forum. And a few parts even against it. https://github.com/tcat-qldom/Oberon-colour -- Tomas Kral <thomas.kral@email.cz>
Hi, Anyway. Here are results of my efforts, sharing my build here. Is rather minimal, and a lot of it happened thanks to advice here in and off the forum. And a few parts even against it :-) https://github.com/tcat-qldom/Oberon-colour -- Tomas Kral <thomas.kral@email.cz>
Hello Tomas, Am 23.05.2020 um 19:49 schrieb Tomas Kral:
Anyway. Here are results of my efforts, sharing my build here. Is rather minimal, and a lot of it happened thanks to advice here in and off the forum. And a few parts even against it :-)
Thank you for sharing, it runs well in my emulator (the b/w version out of the box, the color version needs a bit of patching the switches and offsets). But most of the stuff shown on the screenshot (apart from the ticking clock) I cannot find in the disk image. Trying to compile anything (like your Band example) on the system is hard, as no symbol files are included, and also no source code to recreate them. Also, there are some .Mod files included, but not the ones changed by you? Perhaps I am missing something obvious... Last but not least, you provide the Bitstream file for programming an FPGA. As far as I know, the format is specific for each FPGA model, but you do not write which FPGA model you used/tested it with. And the "supported hardware" does not make it any clearer, as if I am not mistaken the original board used a Spartan-3 and the Pipistrello uses a Spartan-6 (I did not check the others but probably they use different FPGAs as well). Don't be scared by my e-mail, see it as a way you can improve your project page :) Regards, Michael
Hi Michael, Thank you, all very good points. Glad someone has tried it out at last.
(like your Band example)
Band and map just hinted in the PROCEDURE text, encouraging some hand coding. The image is stripped to a minimum. Seems my current obsession. As I did not change interfaces to PO2013 (System.Compact excl.), it would be interesting to see, user code can import from original symbols. Possible? I may provide DEFINITION Modules plus symbols and improve with the next push, to demonstrate that.
FPGA. As far as I know, the format is specific for each FPGA model,
Absolutely, you are right, I did not realise. I wished to make a h/w reference to PO2013 specification. Now thinking what it really means? FPGA, RISC5, 1MB SRAM, 8 Switches, 8 LEDs, SPI, PS/2, VGA, nRF24L01, ... The synthesis is for Pepino LX9 board (Xylinx Spartan6, 1BM SRAM). Need to change in README.md wording. In this case, I like the idea of having two files, instead of a development trunk. Please note other repos of mine share source. -- Tomas Kral <thomas.kral@email.cz>
On Sun, 24 May 2020 13:28:39 +0200 Michael Schierl <schierlm@gmx.de> wrote:
Don't be scared by my e-mail, see it as a way you can improve
Not perfect, but improved. Symbols for Inner/Outer core provided along with definitions. Please note *.Def in System.Tool, next to *.Mod Should now work with hinted code examples. I was surprised the RISC5.FS runs emulated. Curious about SW[0..7] in your emulator, possible? -- Tomas Kral <thomas.kral@email.cz>
Hello Tomas, Am 25.05.2020 um 14:22 schrieb Tomas Kral:
I was surprised the RISC5.FS runs emulated.
Why not? If it runs on the real thing, it should run in an emulator, too. That's why it is called emulator.
Curious about SW[0..7] in your emulator, possible?
The switches are hardcoded to 0. That's why I needed to patch and recompile the emulator to toggle the switches (as well as the boot ROM as your 16 color mode uses a different memory layout than the 16 color mode implemented by my emulator). My plans were to patch the display offset in Display.Mod to make it run in unchanged emulator, but that plan needed to be scrapped as no source code for Display.Mod is available and I do not want to disassemble and binary patch the .rsc file. On the other hand, there are not that many interesting features (yet) to make that particular image interesting for me :) Regards, Michael
Modules.Load("System", Mod); Mod := NIL;
and then Mod := NIL ???
The assignment Mod := NIL is just to make sure that the garbage collector doesn’t mistakenly use Oberon.Mod as a root of a “graph" to be traversed.
How about this, BEGIN Init; Load("Oberon", M); LED(res); REPEAT UNTIL FALSE (*only if load fails*) END Modules. No M := NIL assignment? -- Tomas Kral <thomas.kral@email.cz>
You will/should NEVER reach the code after Load(„Oberon“, M) as the last statement of Oberon calls the main loop (REPEAT ... UNTIL FALSE) without any exit Jörg
Am 02.06.2020 um 18:18 schrieb Tomas Kral <thomas.kral@email.cz>:
Modules.Load("System", Mod); Mod := NIL;
and then Mod := NIL ???
The assignment Mod := NIL is just to make sure that the garbage collector doesn’t mistakenly use Oberon.Mod as a root of a “graph" to be traversed.
How about this,
BEGIN Init; Load("Oberon", M); LED(res); REPEAT UNTIL FALSE (*only if load fails*) END Modules.
No M := NIL assignment?
-- Tomas Kral <thomas.kral@email.cz> -- Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon
On Sat, 23 May 2020 04:00:14 -0700 "John R. Strohm" <strohm@airmail.net> wrote:
That would be expected behavior if the switches, when closed, grounded the connecting pins.
I believe is a typo. IF SYSTEM.BIT(swi, 0) THEN RS232.Send(ORD("0")) ELSE RS232.Send(ORD("1")) END ; Mu argument IF TRUE THEN Send(ORD("1")) -- Tomas Kral <thomas.kral@email.cz>
Hi Tomas,
I believe is a typo.
IF SYSTEM.BIT(swi, 0) THEN RS232.Send(ORD("0")) ELSE RS232.Send(ORD("1")) END ;
Mu argument IF TRUE THEN Send(ORD("1"))
Right. It's actually a very easy kind of mistake to make when programming, the brain goes something like OK, I'll put the IF and ELSE clauses in a logical/aesthetic order, and then it forgets to go back and negate the expression. :) Cheers, Paul
participants (5)
-
Joerg -
John R. Strohm -
Michael Schierl -
Paul Reed -
Tomas Kral