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

Garth,

You might have me confused with scotws who is doing Tali Forth on a 65R2D216 or some such. I was just riffing on his dictionary diagram because the idea of headerless code has some merit, to my Forth, which is PETTIL on a stock 6502 for the Commodore Pet.

If the symbol table consisted only of two fields,

2-byte CFA of the compiled code
Name field (length/flags byte, and the name itself)

Then there would never be any need to relocate anything! The entire symbol table could be CMOVEd elsewhere at will. It could even float above the dictionary (plus a suitable allocation for PAD.) HERE/PAD would start off being 6 pages (1.5K) away from the symbols, but as code gets added, the dictionary creeps closer and closer. When PAD gets within some arbitrary limit, maybe 3 pages away, the symbols would (magically) move back up to be 6 pages away from PAD again. The symbol table would become like a balloon on a string, and when compilation finishes, it could just float away. A few user variables would keep track of how close the block buffers are to the symbols, where the symbols are right now, what are the minimum and maximum lengths of the balloon string, and where is the top of the dictionary (HERE).

One of my favorite things about Forth is its "no bozos" approach to the development environment. Working in Forth can be pretty crashy at times. It's raw, unforgiving, and puts the responsibility for knowing what is going on squarely on the programmer. I am of course defending in advance against attacks on what a house of cards this setup appears to be.

The memory on a 32K PET could look something like this when PETTIL first loads:
$0000 zero page
$0100 stack page
$0200 cassette buffers and other crap
$0400 BASIC ("10 sys 1037" to kick things off)
$0500 Sweet16
$06BE Sweet16 extensions
$06ED user variables
$07E3 target-compiled PETTIL dictionary, just code (no name fields, no link fields)
$1486 HERE
$14D6 PAD
$1AD6 start of symbol table
$1AD6 CFA of EXECUTE
$1AD8 7, "EXECUTE"
$1AE0 CFA of I
$1AE2 1, "I"

... unused memory ...

$7A10 0000 (flag - no more blocks)
$7A12 BLOCK 2 data, also compressed
$7C61 start address of 2 BLOCK (say, $7A12)
$7C63 BLOCK 1 data, RLE-compressed
$7FFE start address of 1 BLOCK (say, $7C63)
-----
$8000 video memory (the screen)
$B000-$E7FF BASIC & Editor ROM
$E810 PIA1
$E820 PIA2
$E840 VIA
$F000 Kernel ROM
$FFFF end of address space

Just FYI, Tali Forth is now hosted on GitHub: https://github.com/scotws/TaliForth

For those working on their own STC Forths, present or future, here is a routine I have found myself using over and over again to store JSR/JMP/words in Forth words. Use by calling the routine with the address/word after it:
This costs an additional 12 clock ticks (JSR/RTS), but the space savings really add up. I'm still on the fence about a "compile JSR and TOS" routine, I don't think I'm using it enough yet to justify breaking it out.

Oh, and today is the one-year anniversary of Tali development. Yay!

Nice subroutine, Scot. And happy anniversary, btw! Here are a couple of tweaks to consider -- nothing earthshaking but it's always nice to have a choice of options. This:
... can be smaller and faster, as follows. Notice you don't need an '816 to have the benefit of doing 16-bit operations on-chip!


The other tweak is a little sneaky. It saves 4 cycles (and costs 2 bytes). This...
... can be replaced by this:
I don't see much of a downside except it requires the programmer to be wide awake! Making matters worse, I didn't bother to include comments.

cheers,
Jeff

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

You'd think I'd have gotten used to PLY by now. Thanks, I'll be changing that. The second one -- neat, but at the moment I'm having a phase of being concerned with size (I'm above my original 8K limit).

Do we have a topic somewhere with "cool things you can do with the 65c02 (but not the 6502)"?

Thanks!

I glanced at your GitHub source. You have a nice straightforward style, with a good balance of code, comments and whitespace, but I noticed several spots where you missed out on opportunities to save code bytes. Are you interested in any hints? If so, how far is too far for you (regarding grokability and structure) when it comes to space-saving tricks?

Mike B.

I'd be most grateful for any suggestions! I'm trying to put the emphasis on speed with Tali Forth (so a lot of the JSRs are "unrolled" into assembler), but I'd also like to stay under 8k because of the ROM chip size, so I'm having to balance stuff. Note I have a few more words to code (see TODO.txt) before I formally start optimization, but we're slowly getting there.

Again, please do comment on anything you see -- even if I decide not to include it, I'm sure to learn something!

That explains a lot of what I noticed, but not all of it. There are a few hard-core golfers around here, and I don't consider myself worthy of that label yet, but I'll give it a try when I get the chance.

Mike B.

Okay, I went through the first 1000 lines of your Tali-Forth.asm source, and saved you 87 bytes without any apparent side-effects, assuming that register Y is free for use by the primitives and TMPCNT and TMPADR aren't used to transmit data between primitives. Tali-Forth.asm is over 7000 lines long, so I could probably save you about 520 bytes more (by extrapolation) in that file alone. It's getting late here, and I have to get to work tomorrow, but you should get the idea of what I'm trying to do (these suggestions are untested).

In Tali-Forth.asm:

In f_toupper (saves 1 byte)
change:
to:

In f_strtoupper (saves 1 byte)
delete:
and change:
to:
In _parseword (saves 1 byte)
change:
to:

In _execute (saves 1 byte)
change:
to:
and change:
to:


In _compile (saves 1 byte)
change:
to:

In f_nib2asc (saves 14 bytes)
change:
to:
and delete:
at the end of the file (it was just a duplicate of the beginning of alphastr anyway).

In f_putchr (saves 7 bytes)
change:
to:

In f_prtzerostr (saves 7 bytes)
change:
to:

In f_getchr (saves 7 bytes)
change:
to:

In f_cmp16 (saves 2 bytes)
change:
to:

In fc_dovar (saves 10 bytes)
change:
to:

In a_plit (saves 4 bytes)
change:
to:

In a_lit (saves 2 bytes)
change:
to:

In a_quit (saves 2 bytes)
change:
to:

In a_dump (saves 27 bytes)
change:
to:

HTH,

Mike B.

[Edit: Made a few minor corrections.]
[Edit #2: I totally messed up a_plit ... I'll fix it later ... a_dump sure kicks butt, though, don't it?]
[Edit #3: I fixed a_plit ... I think.]
[Edit #4: ina -> inc , dea -> dec]

Wow! Thank you for all the work!

It turns out that the _doneexec change doesn't work that way with this assembler; I'll have to go back and figure that out differently, though, that is butt-ugly. Converting
before a BEQ is a trick I wasn't aware of. The same goes for using
to mask the next two bytes (BIT abs) either, but in this case I'm going to use another BRA instead because that's three cycles and BIT is four. Still, cool. Might be worth an assembler macro as SKIP. l_plit and l_lit I had already rewritten (now that I've discovered f_cmpljsr), so that's fine for the moment.

And yes, DUMP is pretty brilliant .

So it seems I need to make more use of Y and let the assembler handle more stuff. See, told you I'd learn a lot.

Thanks again -- code modified and pushed to master.

Y, Scot

I ran across the following article explaining the rationale for the $2C trick the Mike B. was recommending. The article is well written and provides a clear explanation why the programming trick of using BIT abs to skip over two bytes.

Since the 65C02 supports an unconditional branch, the benefit of the trick is not as pronounced. However, using BRA rel instead on BIT abs may save a clock cycle but it requires an extra byte.

As I was writing this post, I thought of a similar trick that may be used on a 65C02. There are a number of unimplemented instructions that operate as NOPs in the instruction set of a true 65C02 but that also advance the program counter past 1 or 2 arguments.

hoglet's recent post regarding Alan Daly's R65Cx2 core identifies a number of opcodes that operate as NOPs but also skip two bytes: $5C, $DC, $FC. Will need to test this behavior with the processor that you are using, but Klaus Dormann's 65C02 functional tests expects the behavior. Thus, I expect a 65C02 processor perform a NOP and then skip the next two bytes if any one of these three opcodes is used instead of the $2C opcode Mike B. suggested.

Therefore, one of these three opcodes will save a byte and have the same execution time as BRA rel.

_________________
Michael A.

This is a cool way to skip two bytes, no question. $2C (or similar) is used as an opcode, and the following two bytes are seen by the CPU as the accompanying operand. (In reality there's an instruction stashed in there, but it doesn't execute. In context of the preceding $2C it will be treated as an operand.) This trick is one cycle slower than a BRA but it's one byte shorter, thus conserving memory. It alters the flags, but that drawback can usually be tolerated.

A more serious drawback is that this trick can cause read-sensitive I/O registers (such as the 6522's Interrupt Flag Register) to suffer an erroneous change of state. For example, the sequence $2C, $12, $34 (BIT absolute $3412) -- where $12, $34 is the two bytes of code you hope to skip -- really does read from $3412 (or whatever). If that read touches a 6522 IFR, or any other read-sensitive I/O address, the result is a very nasty and hard-to-find bug. Because the bug is unlikely, lots of folks just ignore the risk. But it's usually pretty easy to assure yourself on the matter.

• you'll be OK if the target system does not include IO devices with read-sensitive registers (eg: Interrupt Flag Register)
• failing that, you'll be OK if the feature associated with the read-sensitive register is unused (eg: not using interrupts)
• failing that, you'll be OK if the bytes after the $2C, interpreted as an address, do not touch the read-sensitive register(s).

$2C (BIT absolute) is not the only option. Alternatives include $CD (CMP absolute), $EC (CPX absolute) and $CC (CPY absolute), but it all amounts to the same thing. All of these instructions use a two-bye operand, and none of them will modify CPU registers -- flags excepted.

Yes. On 65c02, $DC and $FC can be used for the skip-two-bytes trick. Unlike $2C (BIT absolute), they have the advantage of leaving the flags unaltered. But, unfortunately, the same warning applies. Although the 65c02 bills them as NOPs, opcodes $DC and $FC do produce a memory reference -- a read -- using absolute addressing mode (just as $2C does). They qualify as NOPs only because the result of the read is discarded. I describe the "Load And Discard" operation in more detail on my web site here.

BTW $5C could perhaps be used for the skip-two-bytes trick, but I see no advantage. And $5C is much slower.

cheers,
Jeff

ETA: On the subject of skipping one byte:

On the 'C02, opcodes $02, $22, $42, $62, $82, $C2, and $E2 all equate to "Load And Discard" but using immediate address mode. Unlike the absolute mode examples above, no extra memory reference is generated, so the caveat doesn't apply -- you may use these freely to skip over one byte of code. For 'C02 you can choose any of these opcodes; they all behave identically. Interestingly, on '816 $42 still has the same behavior, although it's been dubbed "WDM." But the skip one byte trick still works on '816 as long as you choose $42.

Formal documentation re the 'C02 NOPs is extremely scarce. The WDC datasheet lists the bytes and cycles but nothing more. In the excerpt below I highlighted the NOPs mentioned in this post.

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

As usual, Dr Jefyll has some excellent observations.

Since I implement all unused 65C02 opcodes for my 65C02-compatible processor cores as single cycle NOPs, it did not occur to me that the implied cycle to read/write a memory operand would actually be performed. This behavior is not likely to be visible to Klaus' 65C02 functional tests since any effects would be discarded. (Note: my processor core can support these behaviors with some minor updates to the microprogram, but I would not have implemented any read/write memory cycles; it just would not have occurred to me to do so because of the side effects that Jeff describes.)

I have not dug into hoglet's R65Cx2 core to see if it would perform the implied memory cycle; it certainly appears to perform no operation on the CPU registers as would be expected.

_________________
Michael A.