cpu20: "p c 1" vs "p r 1", rt11 and mini-unix

[Jay Jaeger]

I am just starting to test my unibone with the various .cmd scripts.  It had had old software, and Jeorg sent me info to update it, which seems to have worked.

But I have noticed an oddity.  Several of the command scripts in  ~/10.03_app_demo/5_applications/cpu have instructions or actually scripted commands to start the CPU running via "p c 1".   However, the software I have doesn't accept that, instead cpu20 is looking for "p r 1".

Example:  cpu20_hello_dl11.cmd

Is that just me?  Is my software messed up?

Also while XXDP boots and runs in my setup, rt11 gets started trying to run, but then gets hung up in some sort of loop.  mini-unix comes up with the "@" prompt, and upon entering the expected "rkmx<LF>" (where <LF> is a linefeed newline character) it prints out (very slowly) the AT&T banner stuff, but never issues the "login:" prompt.

(Note:  I have the Unibone in slot 1 of a 9 slot backplane, real terminator in slot 1, real memory in slot 8, Uniprobe in slot 9, with complete grant chain intact.  Memory size is 128kw, and the unibone "sz" command detects memory from 000000 to 757776 - 0x3DFFE (which allows for an 8K I/O page) so, more than an 11/20 could address, but the 11/20 *should* take any address with the highest bits on, and extend it to 764000 on up - and once started up with "p r 1" hello.cmd works OK.  The "tm" and "tr" commands work fine with the memory.

(I'm also going to try it with emulated memory to see what that does...)

JRJ

[Jay Jaeger]

Turned out that I had a very old SD card image - had not realized that they had moved over to a different github repository.

After that it works, although I find that the "p c 1" in the scripts doesn't work right, and I have to stop the CPU (with XXDP it had already stopped), and then I do  "m ll" (just in case), "p pc 0" "p start 1" and THEN "p c 1" works to start the boot process ("p start 1" *should" also do a bus INIT as well, but I don't know if it actually does.)

XXDP - works

Mini-Unix - works

RT11 - works

Yay!

JRJ

[Jay Jaeger]

Interestingly, in RT11, if I halt the cpu ("p h 1"), and then continue ("p c 1") it does not behave correctly.

(Also, in my previous note, "p start 1" should read "p s 1")

Also wondering why the emulation speed is set at 0.1 ?

JRJ

[Joerg Hoppe]

Hi,

> Turned out that I had a very old SD card image - had not realized that they
> had moved over to a different github repository.
>
> After that it works, although I find that the "p c 1" in the scripts
> doesn't work right, and I have to stop the CPU (with XXDP it had already
> stopped), and then I do "m ll" (just in case), "p pc 0" "p start 1" and
> THEN "p c 1" works to start the boot process ("p start 1" *should" also do
> a bus INIT as well, but I don't know if it actually does.)

Yes, rebooting the cpu20 is a bit cumbersome.
The power-on vector and INIT is not emulated correctly... but I'm
thankful for everything Angelo Papenhof has donated.

[Joerg Hoppe]

Hi,

> Interestingly, in RT11, if I halt the cpu ("p h 1"), and then continue ("p
> c 1") it does not behave correctly.

HALT on the virtual front panel is bistable, you need to do "p h 0" to
release.
CONT is momentary action.

Else HALT+CONT is single step:


halt_switch          h      1 writable   HALT switch: 1 = CPU stopped, 0
= CPU may run.
continue_switch      c      0                writable   CONT action
switch: 1 = CPU restart after HALT. CONT+HALT = single step.

>
> (Also, in my previous note, "p start 1" should read "p s 1")
>
> Also wondering why the emulation speed is set at 0.1 ?

To indicate the emulated CPU is so slow. It is much faster if all memory
is emulated and "p pmi 1"

pmi                  pmi 0                writable   Private Memory
Interconnect: CPU accesses memory internally, not over UNIBUS.


Joerg

[Joerg Hoppe]

Am 24.09.2022 um 23:47 schrieb Jay Jaeger:
> Turned out that I had a very old SD card image - had not realized that they
> had moved over to a different github repository.

That should not repeat .... the frozen UNIBUS-only repository  at
    https://github.com/j-hoppe/UniBone
is gone now.

The correct address is
    https://github.com/j-hoppe/QUniBone

Joerg