Re: Fluke compiler software

John is working on this pretty much alone as far as I know so any help would
be great and any direction would be better than none.

Yes the idea is to figure out how to communicate with the PODs & emulate
what the base does, not necesarily emulate the base.

Heck if we are thinking emulating bases then why aren't we focused on the
bigger brother, 9100 series? I only know of one list reader that even has
one of these beast.

> However, you are still stuck with the limitations of the original
> device. So, while perhaps you could have a disk-load function for
> reading programs into the emulated 9010A's ram (rather than a tape
> device on the real hardware), you are still stuck with the same
> functions, the same display concept, the same model. The 9010A's
> software (or OS, if you will) is not so complex, powerful, or novel that
> it even needs to be preserved.
>
> Emulating a Z80 and the Fluke's entire hardware setup, only to get
> almost exactly what you started with (although on a PC, with a disk
> drive instead of tape) seems limiting and shortsighted, no? Perhaps
> *I* am missing the point of the project!
>

How many people out there SERIOUSLY use these Flukes? I use my almost
daily. I cann't imagine any one working from a tape drive. The 232 port is
the way to go. Has anyone played with a 9020 and GPIB? I'm seriously
considering playing with the suggested method of feedback via the 232 port
for fault tolerant programs.

> I would propose that instead, you emulate the operation of the 9010A
> only - which is what I thought John's idea was in the first place. You
> write a completely new piece of software, that knows how to interact
> with the pod, and, to reuse what 9010A scripts have been written (which
> really aren't so complex they couldn't be re-written anyway..), perhaps
> it could interpret the scripts, compiling them into its own internal
> form, and doing similar operations to what the 9010A would have. That
> scripting language could be greatly expanded, using real constructs, or
> just expand another language that already exists and has a following
> (perl, tcl, python, whatever...) Each of those could be extended to
> have the same "commands" that Fluke-script defined (READ @ 0010)... but
> it wouldn't be limited by that at all.
>

Well we need to know the basics first, and there is no know documentation on
the inner workings of the communication between the base & the pods. Once
this is know, documented & available we can then concentrate on which way to
go.

I belive it is also important to make steady progress rather than trying to
think of every enhancement we want and then build it. Just look at the
Arcade ICE or RatBox projects if you want to see what that thinking
produces.

Kev
Received on Thu Apr 04 07:40:40 2002