μKenbak-1 (and nanoKenbak-1) firmware/documentation inconsistency - CPU Speed

[fcpr...@gmail.com]

It's odd that I just discovered this, but regarding this paragraph in the firmware documentation:

Extension #7 CPU Speed -------------------------------------------------------
Pressing BitN+STOP sets the "CPU speed".  It sets the delay in milliseconds
added after each CPU cycle, equal to 2^N ms.  Thus b0+STOP sets the
delay to 1ms.  b7+STOP sets it to 128ms.  The delay is set to 1 at power on
and on CLR+STOR (Extension #3 Erase above) or if a program executes the
SysInfo instruction, 0360.

Actually, the firmware sets the delay to 0ms. at power on and on CLR+STORE, but to 1ms. if a program executes the SysInfo instruction. Thus, following any program that executes a SysInfo instruction, the next program(s) loaded/executed will run slower than full speed until a power cycle or CLR+STORE.

You can demonstrate this fairly simply:

1. Power on

2. STOP+BTN0

3. START (watch the rate at which BIT 7 of the counter blinks)

4. STOP

5. STOP+BTN3

6. START (watch the BCD clock run for a few seconds)

7. STOP

8. STOP+BTN0

9. START (BIT 7 of the counter now blinks slower than after power on)

I'm not quite sure why the SysInfo instruction and the Speed are interrelated in this way, but it means that any program that uses the SysInfo instruction is itself not running full speed. Just something to watch out for.

[Mark Wilson]

Ah I think I see what's going on. Well spotted!

Pretty sure the documentation for #7 has a typo, that should be "The delay is set to 0...".  Compare with the documentation for #3 which says "The CPU speed (BitN-STOP, Extension #7 below) is set to 0."

There's also a bug, where the SysInfo instruction handler (ExtendedCPU::OnNOOPExtension) calls config.SetCPUSpeed(0); which looks fine, but is actually for the BitN-STOP case, so sets the delay to 1^0ms=1ms not 0ms.

It should probably be config.m_iCycleDelayMilliseconds = 0;

Both issues present since Day 1 (Sept 2011!)

I believe my thinking here was that the front-panel slow-down method was a convenience when running "standard" programs, but if you were going non-standard (i.e. calling SysInfo) you were fully in charge.

I will update GitHub sometime.

M

[Vicente González]

Nice, I also noted it when I was writing my KenbakRuler Monitor, but decided to strictly keep all the functionality and behavior offered by Mark.

--
You received this message because you are subscribed to the Google Groups "uKenbak-1" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ukenbak-1+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ukenbak-1/e601764e-a9a7-49a8-8e95-4a7dc7fd51fan%40googlegroups.com.

[Mark Wilson]

FWIW, I've updated the repo to correct the typo and the bug.

[fcpr...@gmail.com]

OMG, my serial port adding machine program is now, I believe, FASTER than the Victor mechanical adding machine :)

And my serial port BlinkenLights is absolutely frenetic - it could pass for an ENIAC or an IBM 650 now!

Thanks Mark.

[Vicente González]

Wow, that's called support.

Thanks Mark,

Vicente

(Retired EE kind of  in love with the KENBAK-1)

To view this discussion on the web visit https://groups.google.com/d/msgid/ukenbak-1/2e784d47-2915-4e70-82e2-7aa80f7e2b86n%40googlegroups.com.