Re: Question about 65816

From: Ethan Dicks (
Date: 1998-07-09 13:44:09

> Ethan Dicks wrote:
> Yes, but IMHO the BRK instruction is slow. Together with getting the
> vector from the BRK address on the stack, then jumping to this address,
> with saving registers along the way (during the vector get) etc.
> This is _much_ slower than a simple jump table. 

Yes, it is.  It's a design tradeoff.  Keep in mind that we are talking about
operations that are executed rarely, even only once per execution, like opening
a file.  How many times does an assembler open the source file during a
compile?  If it takes 400 cycles vs. 450 or 500 cycles, is the user going to

If blindingly fast operation is important, then no, that BRK mechanism is
inappropriate.  If the ability to port to similar, but not identical
models of 6502 computers, then I still argue that it's a good way to go.

This inherent slowness in software interrupts is why we were all stuck with
the 8250 UART on PeeCees, BTW.  There were BIOS calls for most I/O, but
the applications bypassed the BIOS to bang the UART directly to get the
maximum speed out of the port on a 4.77 (and 8.0) Mhz processors.  With
all these applications that depended on the register set of the serial
ports, it was impossible to sell a serial card that didn't at least have
a compatibility mode with the 8250.  We had to wait until a working 16550
design his the streets (and software was updated to match) before speeds
much above 9600 baud were common.  No, I don't enjoy a 20 cycle delay on
an I/O call, but unless you are loading data one byte at a time (serial
I/O), it's an acceptable tradeoff.  For a block of disk data, it's a
trivial amount of delay, especially when you are talking about the IEC bus.
For a single byte, though, each and every byte, it does add up.

> <self-plug> And my relocatable file format easily allows 'late-binding',
> i.e. relocation of jump tables for example at load time </self-plug>

That is another way to go, if you have ROM support for another load
format.  "Back in the old days", we didn't have fancy a.out or ELF-
style load files on 8 bitters.  If we had, some things might have 
been easier, but they would certainly have been slower.

My suggestion was borne out of my efforts to port a complex program from
the C-64 to the PET.  I spent weeks poring over a disassembly of the C-64
and PET ROMs to match up Kernel routines.  I wrote Kernel stubs for the
PET port and stuffed them below $0800, where the main body of the C-64 code
never looked, anyway.  I compiled the C-64 version with real C-64 Kernel
addresses and the PET version with a combination of Kernel jump points
(for those few that matched, like $FFD2) and my own jump table to my own
Kernel stubs.  It mostly works.  The program is complex enough that it
is stomping on some zero page location that is used by the PET 4.0 ROM
routines for printing and I/O, but is unused on the C-64 by those same
kernel support routines.  If I ever get time to look into it, I'm considering
encapsulating all the code in my source as a way to eliminate stray
side-effects from the PET ROM code.  If I had an easy way to emulate
hardware breakpoints in VICE, I'd do it that way (i.e., jump to the
monitor if the PC is between $XXXX and $YYYY and location $00ZZ gets
written).  For the record, the program I've ported is the Zork Implementation
Program.  I was able to get the source to compile and run on the VICE
VIC-20 emulator (screen size), except for the status line being munged
on the narrow screen.  On the PET, Zork I plays, sort of, but Starcross
does not.  Strange characters appear on the screen in a very deterministic
way; I just have no way to track what pointer is getting hosed.


This message was sent through the cbm-hackers mailing list.
To unsubscribe: echo unsubscribe | mail

Archive generated by hypermail 2.1.1.