I'm not familiar with the 2002, however you might be able to use another pod to do the job. It has multiplexed address and data lines, right? So find a CPU pod that has those and wire it to that layout... John :-#)# At 09:17 AM 02/04/2002 -0500, Kev wrote:

Anyone dive into using the Fluke on Pole Position yet?

For Pole Position 2 from the Z80

I've got

ROM

7H = E1D6 7F = B5F0

RAM

3000-37FF (Battery Backed) 8000-83BF 7J/7K 2149s note 83c0-83ff is for sound.

What are the other areas that come up as RAM?

Ex 4000-407f, 4100-417F etc?

Anyone tackle a device to read ROM/RAM from the Z8002 sockets yet?

Thanks, Kev

One of my 'other' hobbies :) collecting old computers and resurrecting them may be able to help out. I have some old CPM machines, and Kaypro, Osborne, etc. and a custom setup PC with hardware, software and drive able to read, copy and backup old single, double and high density 5 1/4 inch disks in numerous formats. There are an astounding number of formats and data types on 5 1/4 inch disks. Let me know if you'd like me to give it a try, I'm in Australia but a small parcel is only a few dollars airmail. Contact me on marcwolf123@yahoo.com if you like. Best regards, Marc ----- Original Message ----- From: "Kev" <KKlopp@erols.com> To: "Matthew Rossiter" <matt@veriosc.com>; "TechToolsList@flippers. com" <TechToolsList@flippers.com> Sent: Friday, March 29, 2002 10:02 AM Subject: Re: Fluke compiler software

Hmm, according to the manual the disk could be for IBM, Kaypro, CPM or the Fluke 1720. Possible that the disk is for some format that wouldn't match IBM?

I personally have not had much luck with the compiler by Mr Rice, nor any response to request for assistance. The brightest point for me in the Rice compiler is the frequency counter function, and I cannot get it to work. Another cavet that worries me, Rice acknowledges bugs that probably won't get fixed. But I have heard that Mr Rice is working on porting his compiler to a newer platform and hopefully it will be available for us to use.

If you want to use the RKSIC compiler & have a 232 port running to your 9010A you can toy with some of the scripts John has on the FTP.

I've been working on a bare bones script to use as a guideline for developing arcade game test programs. Its about due for another posting to the newsgroup & I'll probably send a copy to the FTP site too. Just ask if you need a copy before I post it.

Thanks, Kev

...

I wasn't able to read the disk because it said it couldn't recognize any file system. How important is this software to you guys? If you *really* want it - maybe I can try some data recovery software or locate the

software

...

from someone else.

I guess you guys have been using http://www.linkline.com/personal/frice/f9010.zip this, by Fredric Rice right? Is it working out ok? I'll probably start messing with it tonight to see how well it works.

Matt

Which compiler? Freds or the Fluke issued one? We've got Delphi in the office & my boss was a big Delphi fan but is quickly becoming a C++ convert. Thanks, Kev

I have started on doing a windows version of this compiler, but I'm converting it to Delphi (since I hate visual basic, and thats about the

only

kid on the block nowadays) - there's also the option for someone to load it across into Kylix when I've finished and create a linux/unix version too! (in case anyone here is a linux junkie)

the first version will have the compiler and text editor as a windows program, when this works OK, I'll look at putting the comms stuff into the same program so everything is in one place.

I'm about 20% of the way through the basic code at the moment, getting rid of the GOTO's and converting the syntax to pascal.

more reports when it gets to doing something

RKSIC does have an option to set up the port. I forget the number. For some reason I could not get 9600 8-n-1 to work but I did manage to get 4800 running. Johns' idea of the PC replacement for the base should eliminate those speed concerns and then coupled with a 8255 card or similar controllable I/O card will make a powerful test tool. Kev

The one thing I don't like about the fluke compiler is I don't think

there's

any way to change the com port settings. Maybe I'm wrong. The baud rate is defaulted to 2400. That's pretty dang slooow. Maybe someone can change that.

Matt

-----Original Message----- From: owner-techtoolslist@www.flippers.com [mailto:owner-techtoolslist@www.flippers.com]On Behalf Of Kev Sent: Wednesday, April 03, 2002 1:08 PM To: Mike Coates; TechToolsList@flippers.com Subject: Re: Fluke compiler software

Which compiler? Freds or the Fluke issued one?

We've got Delphi in the office & my boss was a big Delphi fan but is quickly becoming a C++ convert.

Thanks, Kev

...

I have started on doing a windows version of this compiler, but I'm converting it to Delphi (since I hate visual basic, and thats about the

only

...

kid on the block nowadays) - there's also the option for someone to load it across into Kylix when I've finished and create a linux/unix version too! (in case anyone here is a linux junkie)

the first version will have the compiler and text editor as a windows program, when this works OK, I'll look at putting the comms stuff into the same program so everything is in one place.

I'm about 20% of the way through the basic code at the moment, getting rid of the GOTO's and converting the syntax to pascal.

more reports when it gets to doing something

Urk....I can help with finding the memory map for the fluke and helping figure out the hardware side, but I am NOT a code jockey.

Neil's MZ80 emulator can be found at: ftp://ftp.synthcom.com/pub/emulators/cpu/makez80.zip

So anyone want to help? Fame and riches abound! If not then perhaps a few evenings of headaches...one or the other. The 9010A roms are up on ftp.flippers.com/Fluke I have joined them into a contiguous block.

Why emulate the 9010A at all? The reason to emulate an actual device's microprocessor and hardware is to utilize its software with 0 changes. 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! 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.

Yes the idea is to figure out how to communicate with the PODs & emulate what the base does, not necesarily emulate the base. Well, thats what I thought from the initial talks, but then when the focus was shifted to emulating 6520's and Z80's, it seemed to drift...

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. I have 2 9100's. Its a FAR more advanced system, especially when coupled with all the extra physical hardware testing. I have a really nice automated setup for testing the 6532's on Gottlieb Sys80 boards. I can clip a 6502 pod "over top" the micro, and run test code to exersize the 6532 I/O ports, reading all 40 pins state, real time, using the 9100 I/O adaptors.

If we are going to emulate ANY Fluke hardware, the 9100 makes far more sense. Its 68000 based, with OS/9 running as a simple RTOS. Fluke has some really powerful software included with the system, including a trace diagnosis system that follows a decision tree.

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. I agree. I just don't see what you even "get" in the end by emulating the 9010A exactly. Figuring out the communication between the base and the pod is not dependant on getting a emulated 9010A setup on a PC.

I don't consider this feature-creep at all. Just a better direction, in my opinion.

Yes! That is what I'm looking forward to, a powerful PC based tester. My thoughts were use a 8255 controller to do something similar to what the 9100 is able to do. Thats similar to what the Gottlieb Sys3 test fixture is (I have one of those as well.) It has a 48 port I/O ISA card that installs in the PC, and a "buffer box" that has the higher capacity drives, and adaptors for all the various connectors. Its a neat system too. Makes a great DMD test station too, rather than having to use one of my working machines.

I would be happy to take pictures of my 9100 setups if anyone is interested. One is a 9100FT, with just the main unit (5MB hard drive based), and a few option cards installed. The other is a 9100A, with the optional programming station (includes an external keyboard and monitor), plus lots of various I/O modules for testing 40, 28, 20, 18, 16, 14 pin I/C's, as well as other probe options. Its slick.

True, once we can ding the 9000 pods from a PC then the world is open, emulate the 9100, custom software etc. Exactly.

How hard would it be for someone to emulate a 9100? Doesn't it have a boatload of I/O? The physical items are the difficult part. Each I/O unit is another "pod".

I have a 9100 as well, just never turned it on.

I have three, but I don't use them since I don't have any way of backing up the OS. Did anyone ever track down a copy of that utility that was supposedly going to be circulated? Sorry if it's already been discussed, I'm only skimming due to time constraints... Alex ---- http://www.elektronforge.com ayeckley@elektronforge.com

as you say, the actual command codes are the problem areas, you had started to get somewhere earlier on - but from my experience trying to understand that mish-mash of code that drives the fluke is not going to be easy. I actually started on a 'fluke 9010' driver for mame, the display looks fairly simple, it basically sends ascii to one port, presumably with some extra commands to clear it. whether the parallel port is fast enough is something I do not know, but I do know that you can access it from windows 2000 professional etc, as long as you install a device driver. I used one when I did the software for the willem eprom programmer, so that bit at least is solved! I won an 8088 pod in a recent auction, and will start the hardware based side of the experiments when I have that in my hands, I can't afford to risk damaging my z80 or 68000 pods. (as far as I know, there was only one or two arcade games that used 8088's, and I own none of them!) Once it's known how to control the pod, and we can discover if the old LPT port is up to the job, then we can write an open source fluke controller program that can be extended to include 9100 commands and indeed anything else we can think of - basic templates for testing boards could be generated from mame, ram areas, rom areas, checksums, etc - they may not be spot on, but it should cut down the time required to create a test program for any board. part of the reasoning behind the windows version of the fluke compiler (fredericks one anyway - is source available for the proper fluke one too ?) is that if thats understood, then supporting most of the commands should be possible for the fluke replacement too. just out of interest, did anyone have the disks for the 9100 in a format that can be looked at on a PC, because the 68000 code may be better structured than the z80 code I have so far. (well, it can't possibly be worse!)

The interface board IS the same as the Z80/Z80-AA, but the QT main board is a bit different...there is a 6114 RAM, 2764 ROM, a PAL, and some hardware...no PIA, the interfacing is all down with discrete components. The clock speed of the CPU is 8Mhz by the way... So...I guess if we read the ROM someone will have to take a look at the PAL to see if they can read it as well...I have a PAL reader (if not secured)...it's a P16L8A. John :-#)#