Well... Maybe ageing Atari fans. I believe the Atari BASIC floating point system used the decimal mode you speak of. Nobody else seems to have (allegedly (so that makes it alright (hey brackets within brackets))).

I've used decimal mode quite a bit over the years, and still do. POC's firmware includes a binary to ASCII conversion function and in it is a binary to BCD intermediate step.

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

Actually $FFD2 is called CHROUT, which is also known the the "print character" routine. The reason why we used the jump table is that many of the routines (like CHROUT) would use whatever device was currently assigned. So, CHROUT might be printing to the display, but it could also be printing elsewhere. Some of the jump table vectors pointed at RAM as well, doing things like jmp ($xxxx) using a RAM based vector so that the vector could be easily replaced.

It depended on which documentation you were were reading. The C-128 developers' documentation that I received in late 1985 referred to it as BSOUT and the corresponding input function as BASIN. As that was documentation produced by Fred Bowen and company, who developed the C-128's kernel, I have to say that BSOUT would have been correct. Also note that Mapping the Commodore 128 (Otis Cowper) refers to that function as BSOUT.

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

It was called CHROUT prior to the 128. Not sure why they changed it.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

I occasionally saw references to it as BSOUT prior to the advent of the C-128. At one time, I had a copy of the MADS 64 source code, thanks to Fred Bowen of Commodore, and recall that $FFD2 was labeled BSOUT. MADS 64 predated the C-128, so there must have been some sort of "disagreement" going on within the ranks of the Commodore software group. Ditto for BASIN vs. CHRIN. Also, I saw CKOUT vs. CHKOUT, CKIN vs. CHKIN, and a few others.

In my POC firmware, I use PUTCHx for output and GETCHx for input, where x is channel A or B.

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

I just thought of another sneaky incompatibility. This one is dependent on the hardware to which it's fitted.

These really modern implementations of the 6502 are MUCH faster than their NMOS variants so may cause problems with signal integrity in some cases. I've seen overshoot, reflections and ground bounce issues on circuitry before.