fig-FORTH minutae
Bill Ragsdale
>on the 6502. What a feat (I think).
> Best wishes,
> liaM
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.
Best regards,
Bill Ragsdale
Figgie
liaM
Thanks for this absolutely remarkable piece of history !! Being
a (creative.. héhé) designer myself, I can feel the ripples of
the creative process peeling through the layers of the solution
of the implementation, like peeling an onion, no doubt, for the tears
of frustration.. but with a grand victorious victory over quirky
silicon as your just reward !
Really, congratulations, Bill. A beautiful piece of engineering.
liaM
Jerry Avins
As I recall, the missing carry affected all jumps, not just indirect.
Jerry
--
Engineering is the art of making what you want from things you can get.
ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ
Bill Ragsdale
$6C indirect jump had the carry problem.
Bill Ragsdale
Jerry Avins
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.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Gary Chanson
"Jerry Avins" <j...@ieee.org> wrote in message
news:3EC55C0D...@ieee.org...
> liaM wrote:
> >
> > Thanks for this absolutely remarkable piece of history !! Being
> > a (creative.. héhé) designer myself, I can feel the ripples of
> > the creative process peeling through the layers of the solution
> > of the implementation, like peeling an onion, no doubt, for the tears
> > of frustration.. but with a grand victorious victory over quirky
> > silicon as your just reward !
> >
> > Really, congratulations, Bill. A beautiful piece of engineering.
> >
> > liaM
>
> As I recall, the missing carry affected all jumps, not just indirect.
No, only indirect jumps.
--
-Gary Chanson (MS MVP for Windows SDK)
-Software Consultant (Embedded systems and Real Time Controls)
-gcha...@mvps.org
-War is the last resort of the incompetent.
Ed Beroset
> Bill Ragsdale wrote:
>
>>Not true.The 6502 $4C jump can have an operand across page boundaries. Only the
>>$6C indirect jump had the carry problem.
>>
>>Bill Ragsdale
>
>
> 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.
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
mode."
See http://www.renesas.com/avs/resource/japan/eng/pdf/mpumcu/e740sum.pdf
for a more recent version of the manual with slightly less clear wording
on page 106.
Ed
Wally Daniels
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,
Wally
714
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,
>
> Wally
>
The question answered that began the thread was asked in _George Morrow
memorial and lunch_ thread.
Ed
"Bill Ragsdale" <brag...@aol.com> wrote in message
news:20030515153546...@mb-m06.aol.com...
> >I'd love to hear the story how you worked out the forth inner threader
> >on the 6502. What a feat (I think).
> > Best wishes,
> > liaM
>
>
> 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.
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
(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.
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
LDA (IP),Y
STA W+1
DEY
LDA (IP),Y
STA W
LDA (W),Y
STA TMP
INY
LDA (W),Y
STA TMP+1
DEY
CLC
LDA IP
ADC #2
STA IP
BCC L816E
INC IP+1
L816E JMP (TMP)
A disadvantage of this is that NEXT is longer and thus slower.
Ed
Samuel A. Falvo II
> 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.
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
Ed
"Samuel A. Falvo II" <kc5...@arrl.net> wrote in message
news:c024a1ac.03060...@posting.google.com...
> brag...@aol.com (Bill Ragsdale) wrote in message
news:<20030515153546...@mb-m06.aol.com>...
> > 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.
>
> 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.
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.
Ed