@charlesap If there are no interrupts, then the "l1: jmp l1" loop is probably an error condition. I did notice that it switches all leds off just before entering the loop (it gets to 0x84 before). Where, after the boot load, does it continue (I mean at the source level) ?
In simulation I am running a plain sram in parallel with the cache/sdram to verify all data reads, so I am reasonably certain that it is not a memory bug. Maybe I did something wrong on the I/O side.
@emard Well, that seems to be a lot of good news: If it gets to D7+D2 (0x84 in the simulation run) it has loaded the Oberon kernel from the SD card. From simulation I know that there are a dozen or so reads/writes between the cache and sdram, so if it gets there in all likelihood the new burst sdram controller is working with real h/w. How about the video, did that generate a stable signal?
My simulation run switches off all LEDs (after D7+D2) before entering the endless loop, so there is a difference there to be explored.
I know very little about Oberon - the closest I got to Niklaus Wirth's work was reading the Pascal User Manual and Report over and over in the seventies. We need the input from the Oberoners to understand what the various LED codes mean. @charlesap and others, feel free to comment!
ERROR: Unable to place cell 'video.vram.mem.0.8.0', no Bels remaining of type 'DP16KD'
Yes, this a simple start with 96KB of shadow block ram and 85F only.
Once that works (and the rest of Oberon, of course), we can refine. I'm thinking to roughly follow the design of the Fleaohm one, but with a few simplifications: (i) use a dual ported buffer bram, but merely 512 bytes (will be rounded up to one 18Kb block); (ii) switch the sdram controller between servicing the cache and the video circuit; (iii) fetch 256 bytes (2 lines of b/w pixels) - same as a cache line; (iv) at every time, 256 bytes in the bram are being read by the display circuit and the other 256 are being refilled - these switch roles every two lines; (v) add a "flush" feature to the cache.
@emard I have just discovered that I have the switches wrong. I have them at zero, the Fleaohm version has them at one:
Maybe we should hook this to the ulx3s switches - at least the bottom 6 ones.
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