Benchmarks 71B versus 48GX

[J-F Garnier]

(07-29-2020 08:40 PM)Jonathan Busby Wrote:  

(06-28-2020 07:35 AM)J-F Garnier Wrote:  It's has always been a mystery for me why the RSI is opcode 80810 and not just 8081. Maybe this additional fetched nibble gave more time for the RSI execution? I would be glad to get the opinion of people more expert than me in the Saturn chipsets.

Well, it seems you have found one of the many Saturn "opcode holes" I don't know why the RSI instruction was encoded as 0x80810 -- perhaps HP was planning on adding more opcodes in future Saturn chips but they never got around to it?

Anyway, I don't know about the HP-71B 1LF2 or 1LK7 CPUs, but on the Yorke Saturn it seems that invalid opcodes are just ignored. For example, the following code contains the invalid opcode 0x80811 . I̵f̵ ̵I̵ ̵a̵p̵p̵e̵n̵d̵ ̵a̵ ̵0̵x̵0̵4̵ ̵t̵o̵ ̵t̵h̵e̵ ̵o̵p̵c̵o̵d̵e̵ ̵t̵h̵e̵n̵ ̵t̵h̵e̵ ̵R̵4̵=̵A̵ ̵i̵n̵s̵t̵r̵u̵c̵t̵i̵o̵n̵ ̵i̵s̵ ̵e̵x̵e̵c̵u̵t̵e̵d̵ -- EDIT : Actually, I made an oopsie -- the above invalid opcode with just 0x04 appended is actually SETHEX. If I append 0x104 then it's R4=A , as demonstrated in the following code :
[..]

It demonstrates that the 0x80811 opcode is decoded, but it doesn't tell us if it is ignored or executed as RSI .
Maybe all 0x8081n opcodes are treated as RSI, i.e. the last nibble may be ignored since it doesn't carry any information.

I'm now wondering if the initial goal was actually to pass some information in that nibble for RSI, such as a mask for certain interrupt sources - something like a "RSI n" opcode.
I remember that the ON key interrupt line (IR15 I believe) was managed differently from the other interrupt lines.

Only someone of that era (1LK7 development for the 18C/28C) may still know. But it's now 35 years ago

J-F

[Jonathan Busby]

(07-30-2020 10:17 AM)J-F Garnier Wrote:  

(07-29-2020 08:40 PM)Jonathan Busby Wrote:  Well, it seems you have found one of the many Saturn "opcode holes" I don't know why the RSI instruction was encoded as 0x80810 -- perhaps HP was planning on adding more opcodes in future Saturn chips but they never got around to it?

Anyway, I don't know about the HP-71B 1LF2 or 1LK7 CPUs, but on the Yorke Saturn it seems that invalid opcodes are just ignored. For example, the following code contains the invalid opcode 0x80811 . I̵f̵ ̵I̵ ̵a̵p̵p̵e̵n̵d̵ ̵a̵ ̵0̵x̵0̵4̵ ̵t̵o̵ ̵t̵h̵e̵ ̵o̵p̵c̵o̵d̵e̵ ̵t̵h̵e̵n̵ ̵t̵h̵e̵ ̵R̵4̵=̵A̵ ̵i̵n̵s̵t̵r̵u̵c̵t̵i̵o̵n̵ ̵i̵s̵ ̵e̵x̵e̵c̵u̵t̵e̵d̵ -- EDIT : Actually, I made an oopsie -- the above invalid opcode with just 0x04 appended is actually SETHEX. If I append 0x104 then it's R4=A , as demonstrated in the following code :
[..]

It demonstrates that the 0x80811 opcode is decoded, but it doesn't tell us if it is ignored or executed as RSI .
Maybe all 0x8081n opcodes are treated as RSI, i.e. the last nibble may be ignored since it doesn't carry any information.

I'm now wondering if the initial goal was actually to pass some information in that nibble for RSI, such as a mask for certain interrupt sources - something like a "RSI n" opcode.
I remember that the ON key interrupt line (IR15 I believe) was managed differently from the other interrupt lines.

Only someone of that era (1LK7 development for the 18C/28C) may still know. But it's now 35 years ago

J-F

AFAIK, *all* the HP Saturn CPUs and SoCs support strictly *non-prioritized* interrupts. All RSI does is reset the keyboard state machine so that keys held down after software keyboard scanning ( with the eg. C=IN and OUT=C instructions ) has finished in the interrupt routine and which are generating a high logic level will cause the CPU to be immediately re-interrupted without said held-down keys having to go low and then high to generate an edge triggered interrupt after interrupt processing is re-enabled via an RTI. You are correct w.r.t. the ON key -- on the Yorke and Clarke SoCs it generates a non-maskable interrupt, assuming the CPU isn't in the interrupt routine, as no new interrupts can be generated there ( before an RTI ). As to whether the 0x80811 is "decoded", AFAIK, the CPU does read the invalid nibble but doesn't decode and execute the RSI instruction ( And the only way to really test this is quite hairy and involves overriding the interrupt handler ). There are many more opcode holes in the Clarke and Yorke Saturn CPUs and those don't seem to do anything. I wonder why Kinpo didn't use those opcode holes for new "virtual" Saturn instructions instead of using the BUSCx opcodes.

Regards,

Jonathan