| Posted By
GeorgeHug
on 2021-11-30
13:24:16
|  Could someone run test software for me?
I'd like to understand how the 6551 transmit interrupts work, and would appreciate it if someone could run a couple of short test programs for me and report the results. The programs are here:
https://github.com/gbhug5a/My_CBM_stuff/tree/main/Plus4_IRQ_ACIA_error/IRQ_TEST
The .PRG files are there, and a .D64 image containing them.
These programs should be run on a Plus/4 with nothing inserted in the User Port. They count the number of ACIA interrupts which occur while transmitting 256 bytes at 2400 baud. The programs handle the interrupts differently, and I'm hoping they produce different results.
I don't have access to a Plus/4, and can't get any Plus/4 emulation software to emulate the 6551.
Thanks very much
George
|
|
Posted By
BSZ
on 2021-11-30
16:37:07
| Re: Could someone run test software for me?
I have a plus/4 handy. IRQTEST1 always prints 510. IRQTEST2 writes different values: 447, 456, 457, 452, 454, 453, ... Is this what you expected? 
|
|
Posted By
GeorgeHug
on 2021-11-30
17:20:52
| Re: Could someone run test software for me?
Thanks very much. 512 is what I was expecting from program 1, but I was hoping program 2 would be 256. The problem is that when the IRQ service routine writes a byte to the ACIA to transmit, the ACIA immediately triggers another interrupt. That's because the byte is immediately transferred to the shift register, which frees up the transmit data register again - so it interrupts again in case there's more to transmit.
So when the current routine is finished, the IRQ line has gone back low again, so the processor immediately goes back into another interation of the IRQ servicing routine. That second one acccomplishes nothing except to release the IRQ line because the processor has no opportunity to queue up another byte. (This is why in the real world coders use multi-byte transmit buffers.)
Program 2 turns off transmit interrupts before sending out the byte to the ACIA, and enables them again afterwards. I was hoping that if the interrupt was disabled at the time it should have been triggered, it would not be triggered at all. But apparently that's not how it works. I wonder though why it seems to work even occasionally as it appears to do.
Anyway, thanks very much for running the programs.
|
|
Posted By
BSZ
on 2021-11-30
19:12:18
| Re: Could someone run test software for me?
Sorry, I have never programmed a 6551 ACIA. But other integrated asynchronous serial controllers have been a lot. What you write above seems to be "normal functioning". If the transmit register is empty, an interrupt is generated. The interrupt routine loads new data into the transmit register or, if there is no new data, disables the interrupt generation. Does that logic not work here?
|
|
Posted By
GeorgeHug
on 2021-11-30
22:51:07
| Re: Could someone run test software for me?
Yes, the 6551 is working as it should, but it's not the 6551 that should turn off interrupts when there's nothing left to send. The IRQ servicing routine should do that. But the Plus/4 Kernal doesn't do that. It just lets the transmit interrupts flow at the byte rate (1920 times per second at 19,200 baud) even if nothing is going on.
The other major shortcoming is that the Kernal provides for a single byte transmit queue - literally the outgoing byte and a flag byte indicating there's a byte to send. So when that second interrupt is triggered, there's NEVER another byte to send. If there was even a 10-byte queue, the terminal software could keep it filled, and transmission would be continuous, with only one interrupt per byte, as God intended. So I thought I would fix what I can. I can't fix the buffer because there's no memory allocated to it. But maybe I can fix the other stuff in case some of the terminal software authors might want to fix their code.
If you're game, I may have a couple more test files to run tomorrow. Thanks very much for helping out.
|
|
Posted By
GeorgeHug
on 2021-12-01
09:28:43
| Re: Could someone run test software for me?
@BSZ, I've added two more test programs to the repo and the .d64. Program 3 is the same as program 2, but with some additional delay before and after writing the byte to the transmit data register. Program 4 is completely different. It reads the status register again after sending the byte out. So if the IRQ has been asserted again, that should clear it.
If you have time to run these tests, I would apprecaite it. I promise there won't be more.
https://github.com/gbhug5a/My_CBM_stuff/tree/main/Plus4_IRQ_ACIA_error/IRQ_TEST
|
|
Posted By
BSZ
on 2021-12-01
16:14:54
| Re: Could someone run test software for me?
IRQTEST3 prints 258 or 257. IRQTEST4 prints 492, 490, 491, 486, 495, ... It is strange that they are so different. Could this have something to do with the slow baud rate? Some ACIA's internal state is updated when a bit time expires. (Many CPU instructions can run during the bit time.)
|
|
Posted By
GeorgeHug
on 2021-12-01
18:38:02
| Re: Could someone run test software for me?
If you're sure you haven't reversed the results between 3 and 4, then what you got is the opposite of what I expected. irqtest4 reads the status register after the byte is sent. That's supposed to clear the new interrupt, but obviously it didn't. Well maybe the interrupt doesn't trigger for a while after the byte is sent. I just don't know.
Irqtest3 is the same as irqtest2, but with added delay. I'm surprised that seems to have worked when irqtest2 didn't. But now I don't know which way to go. I really don't want all that delay, but that's the only thing I've found so far that works.
Could you try running them with the chr$(26) in the Open command changed to chr$(30)? That would change 2400 baud to 9600 baud.
|
|
Posted By
GeorgeHug
on 2021-12-01
18:55:41
| Re: Could someone run test software for me?
I would also be curious if irqtest2 runs different at the higher baud rate.
|
|
Posted By
GeorgeHug
on 2021-12-02
10:06:17
| Re: Could someone run test software for me?
I think you were right about the baud rate affecting this. i went looking for datasheets, and in the Rockwell version of the 6551, they have a note that bit 4 of the status register (transmit) takes 1/16 of a bit period to update. I think that means triggering of the interrupt is also delayed by that time. That's why irqtest3 worked but irqtest2 didn't.
So instead of asking you to run these irqtest programs, I think the best option is for me to write a BASIC/ml program that tests various delays until the number of interrupts drops to about one per byte transmitted, and do that for 1200, 2400, 4800, 9600 and 19200 baud. Perhaps you could run that one instead of these irqtest programs.
I think the delay would look something like this:
lda $fd03 ;control register
and #$0f
eor #$0f
clc
adc #$00
tax
loop:
dex
bne loop
and I could change the delay by poking a new value into the ADC instruction. Then for each baud rate, the program would print what poked value dropped the number of interrupts to the right range, and that would tell me how much delay is needed. It may turn out that delay is needed only at higher baud rates. For lower rates, it may be quicker to just let the second interrupt take place.
Film at 11:00.
|
|
Posted By
MMS
on 2021-12-03
11:27:13
 | Re: Could someone run test software for me?
OFF
BTW when I read about the different C64 modems, there were one that was built around the 6551 (maybe it was the fastest ever made for C64 and C128, I do not remember the name). There was a long story about the development steps (and a lot of stories), and it was highlighjted, tthat 6551 gives you the option to use external oscillator, so you can significantly further increase the baud rate.
|
|
Posted By
BSZ
on 2021-12-03
16:07:39
| Re: Could someone run test software for me?
I loaded the files from the disk, if the filenames on the disk are correct, I didn't change them.
IRQTEST2 / 9600 BAUD prints 255. But! If any key pressed during the test, see higher numbers. (256, 271, ...)
IRQTEST3 / 9600 BAUD prints 255 / 256. (Without keypress. With keypress are higher.)
IRQTEST4 / 9600 BAUD prints 255. (Without keypress. With keypress are higher.)
It seems that this measurement is not reliable, the original KERNAL interrupt routine interferes.
If you create a new test, please help! My "every day use" plus/4 has a modified KERNAL. And the ACIA interrupt handling has been replaced.  The tests so far don't even run with it, I have to use an original machine for the test because of this. If the new test does not call the ACIA handler part of the original IT routine, then I can use the machine I'm used to. 
|
|
Posted By
GeorgeHug
on 2021-12-03
18:11:41
| Re: Could someone run test software for me?
@MMS, Yes, the 6551 opens up a lot of possibilities. In fact, you can actually run it faster than the computer can keep up with. Anyway, the +4 is still the only Commodore computer that doesn't bit-bang RS232. I don't think even the Amiga had an ACIA.
@BSZ, I really appreciate your help with the tests. With your results, I think we now know what's going on. There is a delay in triggering the second interrupt after a byte is written to the 6551, and the delay varies with the baud rate setting. This is confirmed by the fact that programs 2 and 4 do not work at 2400 baud, but do work at 9600 baud. The time taken by the processor instructions is enough to get past the short delay at 9600 baud, but not the longer delay at 2400 baud.
I'm still working on a program to determine how much delay is actually needed at each baud rate from 1200 through 19200, but, it will depend heavily on the standard kernal code. So I think it may be best if I ask Steven Combs (retroCombs on Youtube) to run it. He has unmodified NTSC Plus/4s to work with, and it would be less trouble for him to run the test.
I would say it is very encouraging that program 4 works at 9600 baud. That means at higher baud rates no delay loop is needed at all.
|
|
Posted By
GeorgeHug
on 2021-12-07
14:48:44
| Re: Could someone run test software for me?
I haven't been able to make contact with Steven Combs. If BSZ or anyone else would be willing to run the latest test program, I would appreciate it. It does require a stock Plus/4.
https://github.com/gbhug5a/My_CBM_stuff/tree/main/Plus4_IRQ_ACIA_error/IRQ_TEST
This one attempts to quantify the delay that occurs between writing a new byte to the transmit data register and the generation of a new interrupt by the 6551, and to see if the delay is dependent on the baud rate.
Thanks very much.
|
|
Posted By
BSZ
on 2021-12-07
17:50:46
| Re: Could someone run test software for me?
I looked at the DELAY2 test. The result:
?SYNTAX ERROR IN 170
Looking at this line:
170 FOR I = 0 TO 4: READ CONTROL(I):NEXT
My programming in BASIC is too old, but what is this? MS BASIC written for the 6502 CPU recognizes only two-character variable names. In the previous line, BAUD is still good as a BA variable, but CONTROL becomes a CONT statement + ROL string. But there are others like it elsewhere. I don't think this was the task to be tested, but we are watching!
|
|
Posted By
GeorgeHug
on 2021-12-07
22:44:15
| Re: Could someone run test software for me?
I apologize for that file. Everything about it was screwed up. I remembered 6502 assembler pretty well, but obviously not Commodore Basic.
I have re-written it using legal variable names, and have run it on VICE at least as far as I could, and there are now no Basic errors. The new "delay3" files are on the Github repo.
I think the program may take a while to run. The first half is with the screen blanked, and the second half with the screen restored.
Hope this version will run ok.
|
|
Posted By
BSZ
on 2021-12-08
16:23:58
| Re: Could someone run test software for me?
Results for 5 run:
BAUD...|...1st. .....|...2nd. ....|...3rd. .....|...4th. ....|...5th. ......
----------+------------+-----------+------------+-----------+-------------
19200...|...63 / 1...|...63 / 1...|...63 / 1...|...63 / 1...|...63 / 1...
09600...|...63 / 1...|...63 / 1...|...63 / 1...|...63 / 1...|...63 / 1...
04800...|...63 / 1...|...63 / 1...|...63 / 1...|...63 / 1...|...63 / 1...
02400...|...64 / 2...|...64 / 2...|...66 / 1...|...64 / 2...|...64 / 2...
01200...|...66 / 2...|...67 / 1...|...67 / 1...|...65 / 1...|...64 / 2...
19200...|...63 / 1...|...63 / 1...|...63 / 1...|...64 / 1...|...63 / 1...
09600...|...63 / 1...|...63 / 1...|...63 / 1...|...63 / 1...|...63 / 1...
04800...|...63 / 1...|...63 / 1...|...63 / 1...|...63 / 1...|...63 / 1...
02400...|...64 / 1...|...65 / 1...|...64 / 1...|...63 / 1...|...67 / 1...
01200...|...67 / 3...|...66 / 3...|...66 / 3...|...65 / 3...|...67 / 2...
----------+------------+-----------+------------+-----------+-------------
(I ran out of dots on my keyboard. ) Are these the numbers you were expecting?
|
|
Posted By
GeorgeHug
on 2021-12-08
16:50:37
| Re: Could someone run test software for me?
Thanks very much. Yes, I think the results show that the delay is indeed a function of the baud rate. And the results are better than I expected. My servicing routine is pretty complicated to begin with, with some built-in delay already, and it looks like it's only at 2400 baud and slower that any additional delay would be needed. Actually, at those rates, it may make better sense to just let the duplicate interrupt happen. I'll have to think about that.
I really appreciate your help. Now I think I'll be able to do the final version of my alternate ACIA servicing code, which should:
1. fix the "beq" bug in the receive routine
2. prevent the duplicate interrupts, at least at high speed
3. finesse the potential problem with bit 7 of the status register (although there's no indication of that in these results)
4. turn off transmit interrupts when there's nothing to send.
|
|
Posted By
GeorgeHug
on 2021-12-11
10:34:51
| Re: Could someone run test software for me?
BSZ, did you run the test on a PAL Plus/4? If so, I also need to find someone with an NTSC machine to run the test. The slower NTSC clock speed could give different results.
|
|
Posted By
gerliczer
on 2021-12-11
12:08:24
| Re: Could someone run test software for me?
NTSC clock speed is higher than PAL clock speed.
|
|
Posted By
MMS
on 2021-12-11
12:20:58
| Re: Could someone run test software for me?
As gerliczer said (taken from SVS Ultimate Map 2.1), but it depends on settings too
|
|
Posted By
GeorgeHug
on 2021-12-11
13:54:52
| Re: Could someone run test software for me?
Thanks very much for the chart. I don't understand it, but will study it. I assumed that since the crystal is faster on PAL, my code would execute faster. But my thinking was backwards. If my code produces enough delay running on PAL, then it will produce more than enough delay runniing on NTSC.
But, I thought I had tested the relevant possibilities by running the test with a normal screen and with a blanked screen (bit 4 of $FF06). However, even if only looking at the chart's top four entries and bottom four entries, I'm not sure I've done that. I will need to understand what $FF07 and $FF13 do. There appear to be some settings where NTSC runs faster than PAL.
|
|
Posted By
GeorgeHug
on 2021-12-11
14:19:20
| Re: Could someone run test software for me?
Ok, looking at the schematics, I see I was wrong about the setup. The crystal feeds the TED chip, not the processor. So the TED is what's changing the CPU speed, and it doesn't necessarily matter that the PAL crystal is faster than the NTSC. But I still need to figure out what gives me the fastest CPU speed, and make sure the delay is long enough using that.
|
|
Posted By
BSZ
on 2021-12-11
16:23:55
| Re: Could someone run test software for me?
@GeorgeHug: Yes, I run the tests on a PAL machine. I can also watch it on an NTSC machine if I need to. (I have to pack a lot for that. )
I do not fully understand the table. But yes, the NTSC machine is a bit faster. (PAL: 1.7734 / 0.8867 MHz vs. NTSC: 1.7897 / 0.8948 MHz.) But a PAL machine switched to NTSC is much faster! (2.2168 / 1.1084 MHz.)
|
|
Posted By
GeorgeHug
on 2021-12-12
16:35:39
| Re: Could someone run test software for me?
I've studied the table, and it basically comes down to the fact that the NTSC crystal is divided by 8, but the PAL crystal is divided by 10. That produces about the same "TED freq" values either way - so long as the crystal agrees with $FF07, both NTSC or both PAL. So I don't think there's a need to run my test program on an NTSC machine, There should be no material difference.
But @BSZ, I was wrong to say your results were what I expected. The test program runs the tests first with the screen blanked, which produces the highest CPU rate, then runs the tests again with the screen in its normal state, where the average CPU speed is considerably slower. So for any baud rate where a delay is needed, it should have taken more delay loops to get past the 6551 delay when the screen is blanked. But your results don't show any such consistent pattern, and in fact tend to show the opposite result.
I don't really know what's going on, but it appears that for 4800 baud and above, no delay is needed. So I am going to test bit 2 of the control register. If it is low then I will do 4 delay loops. If it is high I will branch around the delay altogether. Very slow baud rates, such as 300 baud, will also not get any delay, but at those rates I don't think it matters if there are extra interrrupts.
I'm going to finish this up, and re-write the Github page, and will post when I've finished. Thanks very much to everyone who had comments and suggestions, and particularly to @BSZ for doing the tests.
|
|
| |
Copyright © Plus/4 World Team, 2001-2024 |
