You are right about this routine not going any faster in ZP. However, copying data is common operation and in such case, you save bytes on setting the start and end address.

So the code

lda #<start
sta xxx_adr
lda #>start
sta xxx_adr+1
lda #<start
sta yyy_adr
lda #>start
sta yyy_adr+1

is four ...

If your code is in RAM, you can use self-modifying code very effectively.

Even if in ROM, it may be usefull to reserve some small area of zero page for copy routine.

loop:
lda xxxx,Y
sta yyyy,Y
dey
bne loop
rts

This effectively costs you just 6 bytes in ZP (as xxxx and yyyy would have to be ...

Here are some of my suggestions/questions.
Be warned, that me being not familiar with the DWARF system, they may not be very insightful :-)

Formal suggestions
------
The table "Chipset registers" start with row
31 Chipset Flag Always 1 Identifies chipset space

It would be more readable, if ...

I understand memory constraints very well. We are all on the same forum, after all

I just could not understand how that 'input evaluator' could be a feature. Now, compromise on the side of code size, that I can understand very well:-)

Rudla

In case of input, this is, i believe, very undesired 'feature'. Especially, if the expression evaluator in this case can reference variables.

For example:


>LIST

10 JOHN = 30
20 INPUT A
30 PRINT A

>RUN
?JOHN
30


This renders input almost useless.

Rudla

It's a feature.


Not really. Let ...

I've not looked at VTL in detail, but my TinyBasic does similar - mostly due to re-use of code, and (I suspect) some slop from an earlier incarnation of the IL (Intermediate Language) that TinyBasics are written in... So:

>LIST
10 INPUT A
20 PR A

>RUN
?1+2
3


In case of input, this is, i ...

ZX Spectrum Basic allowed using of expressions in DATA statements, which was sometimes quite handy.
Depending on how your code is organized, it can be even simpler, than allowing just constants.

Loops will probably benefit the most from this feature.

Two questions come to mind...

1) can you show us some code?
2) what is supposed to happen in case of buffer overrun?

I see, you do not call any jsr, even if it looks like you are prepared to do so. Does any call to JSR damage to output?
I suppose you do not have any debugging options on your machne, but maybe try to check some invariants in your code.

Like:

PLA
bmi BAD_VALUE
STA ACIA_DATA ; put character to ...

I posted similar table based routine in this thread:
http://forum.6502.org/viewtopic.php?f=2&t=7496
We can compare notes :-)
I like your approach because it also works with the 6502. Does it also deliver the correct results for the legal and illegal opcodes of the 65c02?

Currently it does not ...

I posted similar table based routine in this thread:

viewtopic.php?f=2&t=7496

We can compare notes

By 'normal' i meant having the code run and just stop at the specified address - as opposed to the breakpoint that is inserted after the single stepped instruction.

But you are right, Woz's method may be easily updated to support this, even if for the price of speed.

Interesting method, especially for debugging ROM... However, it works only for single stepping instructions. It doesn't provide support for 'normal' breakpoints, right?

You will probably also need to print a list of all currently defined breakpoints and allow clearing some of them.
The best option probably is to have a list of breakpoint addresses and search a breakpoint based on it's address. The same table will contain the code of the instruction you replaced ...