Re: Apple 1 CFFA1 AND FORTH +

[David Schmenk <dschmenk@gmail.com>]

On Oct 31, 4:02 pm, "John B. Matthews" <nos...@nospam.invalid> wrote:
> In article
> <60a392ee-9147-417a-96e4-a80ee5b5f...@f33g2000yqh.googlegroups.com>,
>  David Schmenk <dschm...@gmail.com> wrote:
>
>
>
>
>
> > On Oct 16, 1:10 pm, David Schmenk <dschm...@gmail.com> wrote:
> > > On Oct 15, 4:35 pm, Nama <forums6...@mac.com> wrote:
>
> > > > On Oct 16, 7:35 am, Nama <forums6...@mac.com> wrote:
>
> > > > > My Obtronix A1 has 32k
>
> > > > Actually, let me just say that it does get it's 32k from the CFFA1's
> > > > SRAM, otherwise I think it's 8k on the A! board.
>
> > > OK, you have the same Obtronix that I have.  I will discuss this with
> > > Rich Dreher and see if he has any ideas. I'm out of contact for a
> > > couple of days so don't think I blew you off.
>
> > > Dave...
>
> > Phil & everyone else with an Obtronix-
>
> > I have been unable to figure out what the failure is.  I talked with
> > Rich Dreher about it, but he unfortunately sold his Obtronix
> > (presumably to fund the CFFA 3000).  I've added the old trace code
> > back into John Matthews' code and I watch the Obtronix run off into
> > the woods while traversing the linked list of vocabulary entries.
> > Works like a champ on the Replica1.  I can only speculate the DRAM
> > refresh is confusing the SRAM on the CFFA1 and causing spurious
> > values once in awhile.  I also have lock-ups with other large
> > programs on my Obtronix that I downloaded from Vince Briel's site -
> > including the figForth without CFFA1 support.  I even tried swapping
> > a 65C02 into my Obtronix and an old 6502 into my Replica1 without any
> > change in success/failure.  I really don't have any more ideas.
>
> Does working on some models and not others suggest a hardware fault?
>
> > However, if you have a Replica1, I've updated the release to 1.2.  It
> > only makes some small improvements to the memory footprint and file
> > I/O.
>
> For reference, the NAME macro was intended to catch a code field address
> (CFA) crossing a page boundary. IIUC, the link field represents the
> chain of pointers to the previous word, e.g.:
>
> ;    All code fields must avoid an address ending
> ;    $XXFF for the indirect jump at W-1 to operate (L54)!
> ...
> L22       NAME $83,'LIT' <-- name field
>           DW 00          <-- link field, null terminated
> LIT       DW *+2         <-- code field, points to PF
> ...                      <-- parameter field
> L35       NAME $84,'CLIT'
>           DW L22
> CLIT      DW *+2
> ...
> L75       NAME $87,'EXECUTE'
>           DW L35
> EXEC      DW *+2
>
> http://home.roadrunner.com/~jbmatthews/a2/prosource.html
>
> NAME: EDASM macro used by FDICT.S
>  DFB &1
>  DCI &2
>  IFEQ >*+3
>  LST ON
>  FAIL 2,'PFA=xxFF'
>  FIN
>
> --
> John B. Matthews
> trashgod at gmail dot com
> <http://sites.google.com/site/drjohnbmatthews>

Hi John-

I have indeed relied upon your macro to check for page crossings.
Yours is the only 6502 version that seems to explicitly check for it.
It's why I have stuck with your source and added back code, including
the trace feature.

So, I'm can only assume there is a hardware difference between the
Apple 1 clones and the functional replicas that is causing the
failure.  After switching the CPUs around, the only real difference in
design is in the RAM.  I even tried rebuilding the source to reside
above the 4K mark which would put it in the SRAM located on the CFFA1
card.  Of course zero page and the stack page would continue using the
DRAM memory.  Failure didn't change.  This has now taken more time
than I wanted to spend, so I am going to just write it off to hardware
incompatibility.  Too bad, because I really wanted that extra-retro
feel of plugging away at Forth on the Obtronix.

Dave...