If using a subroutine call in your interrupt handler makes your code simpler then use one. If the extra cycles screws up your code then either lower the communications speed, add flow control, add buffers or increase the CPU frequency.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

All well and good—if those are viable options. This is the software analog of the "good, cheap and fast" trichotomy. You can have it good and cheap, but not fast. Or, you can have it cheap and fast, but not good. Or, you can have good and fast, but not cheap. Which matters most? In an interrupt service routine, I will always opt for good and fast, which means programming effort will not be cheap.

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

The string "bbs0" only appears once in the entire exectuable, within a data structure that appears to be a table of recognised instructions.

The BBSx part of said datastructure:


(new lines added by me for clarity).

Unfortunately I don't believe there's any smoking gun here.



And indeed as I discovered earlier, doing so seems to make it happy, but its just weird given: firstly, as you say, in this case it must always be page zero so there is no reason why should need to tell it that and secondly it works fine with all other BBSx, BBRx, SMBx and RMBx instructions that i've tried - its ONLY BBS0 that complains.

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.

Cool. I didn't actually expect you to humor me! And I hope you don't mind doing so; I admit I'm way out on a limb with this goofy idea!

The bytes you listed do roughly match what I vaguely imagined -- an array of data structures. I see each instance has twelve bytes (including four bytes for the mnemonic). And indeed the opcodes are in there, too, as predicted! For example, what prints as the character ÿ is really $FF (as per the notations I added above), and $FF is the opcode for BBS7. Likewise ï is $EF which is BBS6, ß is $DF which is BBS5, and so on...

... all except $8F aka BBS0 which is missing. I think there's a framing error in the way you've added the new-lines. Unexpectedly, the four bytes for the mnemonic appear at the end of each structure, not the beginning. For example I mentioned ÿ is $FF, which is the opcode for BBS7, and see how ÿ precedes the mnemonic bbs7? I'm afraid that at the end you listed some bytes which aren't part of the array, and at the beginning you omitted eight bytes which are.

It's easy to work backwards and predict what "should" be there. If the hex bytes 00, 2D, 00, 00, 00, 00, 01, 8F are prepended to your listing then the resulting pattern is consistent across all eight 12-byte structures. My goal was to see if that consistency is intact. But the anomaly, if any, would appear in the portion you accidentally omitted, so now I'm in suspense! Would you mind checking, please, to see if the pattern is intact?

-- Jeff

PS and slightly OT -- or maybe not:
while preparing this post I noticed I could copy and paste most of the unusual characters (the ¿ and the Ÿ and so on) without difficulty, but I wasn't able to copy and paste the character encoded by $8F (which is the opcode for our problematic BBR0). Probably there's a simple reason, although it's not known to me (7-bit ASCII is the only encoding I have a solid grasp on). But perhaps $8F's lack of pastability, or a closely related issue, has a bearing on the puzzle at hand. It may only be coincidence. But $8F stands out as a case of "one of these things is not like the others" -- and that aptly describes the BBS0 puzzle as well.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

I wouldn't be on this forum if I wasn't into goofy ideas!



The bytes before bbs0 are:



It appears to follow the pattern with one exception - the opcode is missing. Though that may be because I'm using a text editor rather than a hex editor, and 8F in Windows-1252 is either "unused" or the unusual control character <SS3>, depending on who you ask, so it may just not be showing up....

EDIT: changed my text editor's charset to ISO-8859-15 and, yep, <SS3> right where it should be.

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.

Alright, thanks. Just as an experiment, what happens if you take that out and put Ÿ in its place? IOW, replace the $8F with $9F (for example). I'm thinkin that, after that change, the assembler will henceforth assemble BBS1 when you ask for BBS0 (IOW it'll give the incorrect opcode)... but that should be the only effect!

If you discover it also eliminates the BBS0 error message which you were getting then we have a red-hot clue. Admittedly it makes no sense (or seems not to); it's a shot in the dark. I'm just tryna connect the dots, or at least see what dots can be connected... Foolin' around with the problem...

Edit: typo - BBS0 not BBR0

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

A little historical aside for the truly OCD in the audience.

The syntax for the BBx instructions has been implemented in several different ways, depending on the assembler. For example, using the BBS instruction, one could write:

Code:

BBS2 $80,$A604

or could write:

Code:

BBS 2,$80,$A604

or perhaps:

Code:

BBS #2,$80,$A604

Of the above, the first form is the implied syntax in the WDC 65C02 data sheet. I say "implied" because while the data sheet lists all the instruction mnemonics (listing BBS as BBS0, BBS1, BBS2, etc.) and available addressing modes, it doesn't actually describe the recommended 65C02 assembly language syntax.

The WDC syntax is not in agreement with that documented in chapter 17 of the Lance A. Leventhal book 6502 Assembly Language Programming (1986, revised from the 1979 edition), which is considered to be the standard reference work on the eight bit 6502 family. Leventhal got his 65C02 material from Leo Scanlon at Rockwell International, so I'm inclined to think that the second form is the "official" form, as it was Rockwell who added the BBx, RMB, SMB, TRB and TSB instructions to the 65C02.¹

The third form is the one that is accepted by the Kowalski assembler as valid syntax. In a way, it makes sense, since the bit number (2) is immediate data, not an address.

From the point of view of someone writing a 65C02 assembler, the second and third forms would be more inviting, since the three-character mnemonic size is unchanged, and parsing comma-separated operands is relatively easy to accomplish. Also, these forms are easy for the programmer to read. The first form, I would think, would complicate mnemonic parsing, since the three-character uniformity is not maintained. Although I have no plans to write a 65C02 assembler, if I did I'd go with the Kowalski form due to its readability in a program listing.

——————————————————————————————————————————
¹Rockwell used the 65C02 in a modem they developed, which is the likely reason they added BBx et al to the instruction set.

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

So, I've written some simple macros for the WDC compiler which allow you to use the second (Rockwell) syntax, and which also get around the BBS0 bug we've encountered by prefixing the address with < to force it to treat it as ZP.


Note that you must call them as "BBSx" rather than "BBS", etc. I did this because "RMB" clashes with a built-in macro.

I've not yet done the most recently suggested experiment in editing the executable, though I do intend to do so soon.

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.

Remember that BBS0 bug? Well, I just went back to do some more experimentation on it, and it seems to have fixed itself. I can no longer replicate the bug, even on the original codebase where the problem was. I am very confused.

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.

Hi
I was looking at this thread, looking for something else.
ISRs should be as short a possible in time, even if it takes more
space. In general, they should do the absolute minimum of calculation.
Like reading or writing a byte from/to a port:

Get the byte
update the pointer
possible overflow flag
done

Any other calculation or action with the byte do not belong in
an ISR. There is clearly no need for a JSR.
At most, there might be a test at the beginning to look for possible
multiple sources of the interrupt.
There should never be something, like converting an ascii letter to a
number in an ISR.
Dwight

_________________
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?

It is quite possible that you might have such a real time
system. If it was that critical, you should have used more than
one controller.
Using that much time in an interrupt is most likely poor initial design.
Dwight

_________________
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?

The most I ever did was to run 50 temperature PIDs and a control from a
keypad and LCD display.
It was for a 15 watt laser diode burn-in. Each diode had its own current
ramp and I'd correct the PID for the increased power as they heated up.
Lasers are funny, you have to limit the current when cold or they
wipe them selves out. As they heat up, you can increase the current
and it doesn't hurt them.
I was told that the efficiency drops of with temperature and they don't
lase as much.
Anyway, it was all run from a 2MHz Z80. It held the heat chucks to 0.2C.
It was a little tricky because you had to compensate for the additional
power of the diodes, either ramping up or down. I'd control the heat by
how many cycles of 60Hz I'd let into the heater. This would dither at each
step because the 60Hz steps were too course. You drop or add a cycle so
the average resolution was 1/10th of a cycle. The thermal inertia was enough
to average over the number of dithered cycles.
We used 1K RTDs rather than thermal couples. Thermal couples can't really be
calibrated because you can't recreate the thermal gradient on the wires
leading up to the heat chucks when they are removed from the heat chuck.
Platinum RTDs of the higher resistance are easier and they can be linearized
easier than thermal couples as well.
Dwight

As a general case you're 100% right and I totally agree, however in my original application there was virtually nothing for the program to do outside the ISR (the non-ISR code was just a three instruction flip-a-bit-and-loop) so it really didn't matter that I was doing all the work in the ISR.

For the Nimbot I am definitely going to be optimizing the ISRs hard, but at least one type of them is going to take a long time by definition as it is copying the frame buffer into the screen. To save cycles I've put one type of ISR on to the NMI pin instead; I don't envisage needing to disable this one but if I need to it can be disabled in the VIA so it being on the NMI pin isn't too much of a problem, and I save some cycles checking the source. I've also long since concluded that BRK on a 65C02 is far too much hassle to be worthwhile - I was trying to emulate the x86 INT <vector> syntax, and whilst you can do this, the amount of cycles required to decode work out if its a BRK and get the <vector> if it is just isn't worth it. BRK/COP are much more practical in the '816.

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.