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