I assume you mean the code fragment NEXT, which does a double indirect jump?
IIRC, after 20 years and no notes, the 6502 had a jump $4C and indirect jump
$6C. The register IP points to the location of the compiled pointer (CFA, code
field address) to the next machine code for either continued nesting of high
level words or execution in the case of a machine code word.
After considering several alternatives of a more brute force methods for
following the two step linkage, I tried the $6C indirect jump. The technique
was to place $6C immediately before the IP register which was at the very end
of the NEXT code itself. This one of the best or worst examples of self
modifying code, depending on your point of view.
Anyway, the NEXT code would bump the IP pointer (which itself was about 10
bytes ahead in line in NEXT) by two bytes and then encounter the $6C opcode and
do the indirect jump reaching the next section of machine code.
This would have been the end of the story except for a bug in the microcode of
the 6502. If the $6C operand ended in $FF the intermediate jump address was
stratddling a 256 byte page boundary. In this case the required internal carry
of fetching the destination address was not done internal to the 6502, so the
jump destination by off by 256 bytes!
I had personal communication with Chuck Peddle the 6502 designer about this.
For their own reasons Chuck and MOS Technology decided not to fix this bug.
Thus the bug has been carried forward to this day.
My solution was when compiling high level code to never locate the CFA (code
field address) of a high level Forth word on a page boundary. As a new word
definition was started, the CREATE word would precalculate the CFA location. If
it straddled a page one byte was skipped and then the word created. Worked fine
and is clearly shown in the fig-FORTH 6502 Installation Manual. Certainly this
test is not needed for non-6502 processors.
Another problem was there were about 6 unused opcodes in the address space. The
internal state machine would halt for them so the processor could lockup upon
bad code or bus noise. My products had to have a fail-safe timer to recover
which worked fine in many real-time controller applications.
As I recall, the missing carry affected all jumps, not just indirect.
Engineering is the art of making what you want from things you can get.
I'm surprised. What I used the 6502 for rarely involves indirect jumps,
yet I knew about and ran into the bug. Maybe it was with branches?
I still have an AIM-65 ans a SYM-1 I can fire up to see.
No, only indirect jumps.
-Gary Chanson (MS MVP for Windows SDK)
-Software Consultant (Embedded systems and Real Time Controls)
-War is the last resort of the incompetent.
Nope, just indirect jumps. In fact, that particular bug still lives on,
25 years later. The Mitsubishi (now Renesas) 740 series processors are
basically a 6502 derivative still used in embedded systems (my VCR
happens to have one) and the programming note says:
"Don't designate the last instruction of each page (XXFFh) as the
indirect address when using JMP instruction in the indirect addressing
for a more recent version of the manual with slightly less clear wording
on page 106.
If anyone has the full thread of this discussion, could they
please forward it to me.
Regretfully I came into the thread late, and have been unable
to retrieve the earlier posts.
Wally Daniels wrote:
> On Thu, 15 May 2003 22:12:38 +0200, liaM <lh...@email.com> wrote:
> Hello All,
> If anyone has the full thread of this discussion, could they
> please forward it to me.
> Regretfully I came into the thread late, and have been unable
> to retrieve the earlier posts.
> Many Thanks,
The question answered that began the thread was asked in _George Morrow
memorial and lunch_ thread.
IMO, it was a bad decision as it scared many users away from
what was, potentially, a very useful instruction. They should
have fixed the bug when they added the ROR instruction
(which early 6502's lacked).
> My solution was when compiling high level code to never locate the CFA
> field address) of a high level Forth word on a page boundary. As a new
> definition was started, the CREATE word would precalculate the CFA
> it straddled a page one byte was skipped and then the word created. Worked
> and is clearly shown in the fig-FORTH 6502 Installation Manual. Certainly
> test is not needed for non-6502 processors.
Indeed. However, it didn't help anyone generating a forth directly from
a 6502 assembly listing - every CFA had to be checked to ensure it never
cross pages - tedious!
64FORTH (Tom Zimmer) used a different approach. It got around
the bug (and the CREATE fix) by placing the address in a fixed place
in zero page e.g.
NEXT LDY #1
L816E JMP (TMP)
A disadvantage of this is that NEXT is longer and thus slower.
I believe Bill Mensch was the designer of the 6502. He still
maintains the 6502, and has fixed the bugs with the 65C02 processor.
He also created the 65C816 16-bit variant of the 6502. He currently
owns and runs Western Design Center, Inc.
New designs should not rely on the NMOS masks. The CMOS version of
the chip is fully backward compatible with the NMOS equivalents, plus
you get the benefit of bug fixes.
Samuel A. Falvo II
Most write-ups mention Peddle but it was probably a team
effort. As is usual with team efforts, just one person gets
named and that sticks.
> New designs should not rely on the NMOS masks. The CMOS version of
> the chip is fully backward compatible with the NMOS equivalents, plus
> you get the benefit of bug fixes.
Sadly the fixes came far too late, IMO. I don't think
the other 6502 second-sourcers (Rockwell, Synertek)
ever produced a bug-fixed CMOS variant themselves.