Thank you @charlesap ! I've managed to pop out to the stores today and get an extra sd card for oberon experiments. From our first experiments it seems a lot is already working - at least the CPU is executing PROM code and the little use that the the boot code makes of main memory seems to work correctly enough to load the kernel (although I am not sure it will have loaded into core correctly - maybe the cache access is okay, but the main ram access is not, etc.)
What would be ideal is to have a mini-monitor to access the system over serial and inspect some stuff "from the inside". Maybe this already exists in some form for embedded use.
leds in boot loader 80H cold boot 81H load Oberon from serial 82H load Oberon from CF 84H transfer from boot loader to Oberon leds in Oberon 21H garbage collector mark phase 23H garbage collector restore files 27H garbage collector scan phase 20H garbage collector ends C0H+w Trap w br Jörg
Hello Jörg, D7+D2 is 84H, not 82H. (D0=1H, D1=2H, D2=4H, D3=8H, D4=10H, D5=20H, D6=40H, D7=80H) If reading from RAM or writing to RAM were totally broken, it would not get that far. One possible reason (just a guess) would be if RAM reading as data works, but reading as code would not. Since at that point a RAM instruction is executed for the first time (before it was all in ROM). But as for most memory problems, it could be many other things as well. Regards Michael
@pnru_gitlab @emard I have created a new disk image based on the www.projectoberon.com sources, only adding some more LED output in the inner core boot process.
Here's a zip file of a disk image that you should be able to directly write to an SD card: https://github.com/io-core/io/blob/main/images/ledboot.img.zip ... this image has the Oberon partition at the correct offset but I did not bother to format the first part with a FAT partition. It boots on my ulx3s with the earlier Oberon .bit file.
Here's the meaning of the LEDs on booting:
LEDs: 7------- In BootLoad Firmware
LEDs: 7-----1- In BootLoad Firmware
LEDs: 7----2-- In BootLoad Firmware
LEDs: -------0 Control transferred to Modules
LEDs: ------1- Control transferred to Files
LEDs: -----2-- Control transferred to Kernel
LEDs: ----3--- In Kernel - Temporary Trap installed
LEDs: ---4---- In Kernel - Stack and heap origins and limits configured
LEDs: --5----- Kernel SecMap initialized, control transferred to FileDir
LEDs: -6------ Directory traversal complete
LEDs: 7------- Sectors marked, control transferred to Modules which has loaded Oberon.
LEDs: -------- Icons are defined, display subsystem initialized, ready to load System.
LEDs: --5----0 GC in the Oberon Loop
LEDs: --5---10 GC in the Oberon Loop
LEDs: --5--210 GC in the Oberon Loop
If there is an early trap before the system introduces a nicer printing trap the leds will fast-blink now with the trap value (0-7).
If the system gets an error trying to load modules after the boot loader successfully loads the kernel (which Oberon needs to actually display graphics and text to the screen) then this code fast-blinks bit zero.
The Oberon source code modified with the LED output is here:
Well, fixing all clock cycles other than I/O or PROM being memory cycles improved things. With the new disk image I now get:
SD CMD = 510008004cff i = 90 SD CMD = 7a00000000ff SD CMD = 510008004dff i = 91 leds=00000084 leds=00000001 leds=00000002 leds=00000004 leds=00000020 memory bug!
in simulation. The leds= values are hex. So we get to "control transferred to the Kernel" before we go wrong. And we go wrong before there is a memory bug (i.e. cache output != shadow sram output).
reposting from discord: Has anyone found a good simulation model for the IS45S16160G sdram? (ideally verilog)
Very simplistic, but these worked for me:
The Cortex one does single word reads/writes with CL=3, the Oberonstation one does burst reads/writes with CL=3.
@emard @charlesap OK, thinking about the address bus stability with a fresh mind this morning lead to a minimal, 2 line fix to the RISC5 core and now it seems to work (in simulation) as it should. It continues to led=0x40, "Directory traversal complete" when te simulation time (200ms) ran out.
Will do a longer run, but it seems we are there on the simulation side.