6502.org Forum Projects Code Documents Tools Forum
It is currently Sun Nov 24, 2024 2:45 am

View unanswered posts | View active topics


Board index » 6502.org Users Forum » Nostalgia

All times are UTC




Post new topic Reply to topic  Page 1 of 1
  [ 11 posts ] 
  Previous topic | Next topic 
Author Message
BB8
PostPosted: Wed Nov 18, 2020 10:04 pm 
Offline
User avatar

Joined: Sun Nov 01, 2020 10:36 am
Posts: 37
Location: Tatooine
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?
Top
 Profile  
Reply with quote  
barrym95838
PostPosted: Wed Nov 18, 2020 10:10 pm 
Offline
User avatar

Joined: Sun Jun 30, 2013 10:26 pm
Posts: 1949
Location: Sacramento, CA, USA
Someone just wanted to be extra sure? :P

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

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)
Top
 Profile  
Reply with quote  
GARTHWILSON
PostPosted: Wed Nov 18, 2020 11:03 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8546
Location: Southern California
It's a common mistake, along with CLI right before RTI which could in rare circumstances cause trouble.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?
Top
 Profile  
Reply with quote  
JimBoyd
PostPosted: Thu Nov 19, 2020 2:53 am 
Offline

Joined: Fri May 05, 2017 9:27 pm
Posts: 895
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.]
Top
 Profile  
Reply with quote  
BigDumbDinosaur
PostPosted: Thu Nov 19, 2020 7:04 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8514
Location: Midwestern USA
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.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Last edited by BigDumbDinosaur on Tue Jun 29, 2021 7:20 pm, edited 1 time in total.

Top
 Profile  
Reply with quote  
cjs
PostPosted: Thu Nov 19, 2020 7:31 am 
Offline
User avatar

Joined: Sat Dec 01, 2018 1:53 pm
Posts: 730
Location: Tokyo, Japan
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. :-)

_________________
Curt J. Sampson - github.com/0cjs
Top
 Profile  
Reply with quote  
BigDumbDinosaur
PostPosted: Thu Nov 19, 2020 6:51 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8514
Location: Midwestern USA
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.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!
Top
 Profile  
Reply with quote  
BigEd
PostPosted: Thu Nov 19, 2020 7:52 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10986
Location: England
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.
Top
 Profile  
Reply with quote  
BigDumbDinosaur
PostPosted: Fri Nov 20, 2020 8:25 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8514
Location: Midwestern USA
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.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!
Top
 Profile  
Reply with quote  
enso
PostPosted: Tue Jun 29, 2021 6:53 pm 
Offline
User avatar

Joined: Sat Sep 29, 2012 10:15 pm
Posts: 904
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?

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut


Top
 Profile  
Reply with quote  
BigDumbDinosaur
PostPosted: Tue Jun 29, 2021 7:35 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8514
Location: Midwestern USA
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. :D

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!
Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  Page 1 of 1
  [ 11 posts ] 

Board index » 6502.org Users Forum » Nostalgia

All times are UTC


Who is online

Users browsing this forum: No registered users and 38 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
6502.org is an ongoing project by Mike Naberezny and contributors.