Re: Apple 1 CFFA1 AND FORTH +

[mwillegal <mike@willegal.net>]

DRAM refresh suspends the CPU clock, so should have no effect on reads
or writes on a real Apple 1, Obtronix or Mimeo.
I'm heavily engaged in another project at this time, but I'll try this
Forth port on a Mimeo, as soon as I get a chance.
In the meantime, a while back, I have put up a page with a memory test
that could be used to test the memory on any of these systems.

http://www.willegal.net/appleii/6502mem.htm

Regards,
Mike Willegal

On Nov 1, 12:41 am, David Schmenk <dschm...@gmail.com> wrote:
> 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...