Commodore 64 NMI Service Routine begins with SEI

[BB8]

In the 65xx family when an interrupt is served, the I flag is set before starting the Service Routine.
In the Commodore 64, and in some of its related friends (the Vic20 and the C128), the NMI Service Routine starts with a SEI. Other Commodore machines don't have it.
(Actually these are the machines having the Restore key).
Apparently that Service Routine isn't called from anywhere else in the Rom.

Do you think there was a reason for it?

[barrym95838]

Someone just wanted to be extra sure?

Or, maybe the engineer saw it as a potential software JMP target in addition to its obvious hardware function? IDK ...

[GARTHWILSON]

It's a common mistake, along with CLI right before RTI which could in rare circumstances cause trouble.

[JimBoyd]

Odd. The regular Interrupt Service Routine does not start with SEI.
[Edit: I mean it's odd that the mistake was made in one routine and not the other.]

[BigDumbDinosaur]

BB8 wrote:

In the 65xx family when an interrupt is served, the I flag is set before starting the Service Routine.
In the Commodore 64, and in some of its related friends (the Vic20 and the C128), the NMI Service Routine starts with a SEI. Other Commodore machines don't have it.
(Actually these are the machines having the Restore key).
Apparently that Service Routine isn't called from anywhere else in the Rom.

Do you think there was a reason for it?

There is no reason for it, since as you noted, when any interrupt is serviced the I flag in SR is set after the MPU pushes PC and SR.

It's common knowledge that some of the Commodore kernels have extraneous instructions and outright logic errors. The aforementioned SEI at the start of the NMI handler is an example of the former case.

The fake RS-232 code in the C-64 and C-128 kernels has several logic errors that hamstring processing at speeds higher that 1200 bps and in some cases, cause dropped bits. The use of the timers in CIA #2 to act as bit rate generators adds to the woes. Many CIAs have errata that results in failure to generate a timer-B interrupt if the device's interrupt control register is read one or two Ø2 cycles before the interrupt is scheduled to hit. Since timer B is used to act as the bit rate generator for reception, a missed interrupt will result in one or more bits being missed and corresponding framing errors.

[cjs]

JimBoyd wrote:

Odd. The regular Interrupt Service Routine does not start with SEI.
[Edit: I mean it's odd that the mistake was made in one routine and not the other.]

Different authors? Lack of review of old code even after the same author had learned his lesson? Not wanting to re-assemble and shift things to fix a seemingly harmless error?*

I'm sure that there are plenty of minor errors that got stuck due to lack of desire to go through even very minor pain caused by fixing them. After all, the code you're looking at is called the KERNAL, rather than the kernel, because of one typo made by a documentation writer long ago.

----------
* Not actually entirely harmless, since I would bet that BBB and I are not the only two people who've wasted their time wondering if there was something we were missing in this. But hey, ask Jack Tramiel if he cares. :-)

[BigDumbDinosaur]

cjs wrote:

I'm sure that there are plenty of minor errors that got stuck due to lack of desire to go through even very minor pain caused by fixing them. After all, the code you're looking at is called the KERNAL, rather than the kernel, because of one typo made by a documentation writer long ago.

Given the politics that existed at Commodore in the Tramiel era, attracting and retaining good programming talent was problematic. Tramiel's only goals were computers shipped and dollars received. He wasn't about to let quality issues like a couple of insidious software bugs get in the way of those goals.

[BigEd]

One aspect of these sorts of 'why on earth didn't they fix that' questions, is that we don't see the 99 things (or the 999) things which the engineers did manage to fix, with their limited time, limited tools and limited budget: we only see the ones which didn't get cleared up. And in this case, it's a very small suboptimality which will barely be noticed. Maybe if they had a bit more time, or had to go around once more trimming bytes from code, they would have fixed it.

[BigDumbDinosaur]

BigEd wrote:

One aspect of these sorts of 'why on earth didn't they fix that' questions, is that we don't see the 99 things (or the 999) things which the engineers did manage to fix, with their limited time, limited tools and limited budget: we only see the ones which didn't get cleared up. And in this case, it's a very small suboptimality which will barely be noticed. Maybe if they had a bit more time, or had to go around once more trimming bytes from code, they would have fixed it.

One of the most infamous of the C-128 bugs was in the 1985 ROMs, in which the keyboard decoding table had an error that resulted in SHIFTed Q being the same as unSHIFTed Q. That same bug also affected the use of shift-lock. The 1986 ROMs fixed that little contretemps, along with some other bugs.

Both the C-64 and C-128 had numerous problems with the fake RS-232 kernel code that resulted in frequent errors, especially during CBAT. Part of it was cruddy code and the rest of it was due to the timer-B bug in CIA #2. That definitely was not a case of "suboptimality," as serial I/O was grossly unreliable. Use of an error-correcting protocol during file transfers was de rigueur and the C-128D struggled to run serial I/O at 2400 bps, even in 2 MHz "fast" mode.

During my development of the truck leasing package for multiplexed C-128Ds running on a Lt. Kernal disk subsystem, I was trying to make use of serial I/O to transfer code from my development system to the test system. The need for the serial link was because I didn't have a multiplexer at the time, so I could not link all the C-128Ds to a single drive. The C-128 kernel RS-232 code was simply too error-prone to be reliable and while using XMODEM to deal with the errors did work, communications was limited to 1200 bps, and the need to retransmit corrupted frames made the actual throughput even lower.

What I ended up doing was linking the serial shift registers in each computer's CIA #2 and rigged up a clocking circuit triggered by my development machine. A small program running in the cassette buffer on the development machine would read the hex file generated by the assembler and hand each byte to the CIA. One of the test machines would have a receiver program running in its cassette buffer to read the incoming data flow and write it into open file so it could later be loaded into RAM for testing. Eventually I added code on the receive side that would convert the hex data on the fly and stuff the bytes into RAM, eliminating the need to save the loader file.

BTW, my monkey-rigged serial "network" was good for about 32 KB/sec over a distance of 10 feet. Most file transfers occurred in a fraction of a second.

[enso]

BigDumbDinosaur wrote:

...Both the C-64 and C-128 had numerous problems with the fake RS-232 kernel code that resulted in frequent errors, especially during CBAT. ...

I am somewhat ignorant on the Commodore front... Could you explain why the code was 'fake', and what in the world is CBAT?

[BigDumbDinosaur]

enso wrote:

BigDumbDinosaur wrote:

...Both the C-64 and C-128 had numerous problems with the fake RS-232 kernel code that resulted in frequent errors, especially during CBAT. ...

I am somewhat ignorant on the Commodore front... Could you explain why the code was 'fake', and what in the world is CBAT?

Continuous Bi-directional Asynchronous Transmission. It's a term that refers to the most stressful operating conditions for asynchronous serial I/O. CBAT in the old machines with primitive UARTs was the acid test of how well the RS-232 functions were written, and how well the UART did its job.

As for Commodore's RS-232 code, we called it "fake" because it did in software what a real UART does in hardware. The VIC-20, C-64 and C-128 didn't have a UART, so an elaborate simulation of a 6551 was done in the operating system "kernal." In other words, it was fake.