<EXEC> <YES> generally gets you going. I was thinking that it would be nice to have a text file (I was thinking Word Doc or PDF) that you could print out, 1 page that would tell you some basics to go along with the program. But then again I've been trying to champion the idea of a uniform "bare bones" program that everyone could use as sort of a standard. Press 1 for RAM Press 2 for ROM ..... Press 9 for RUN UUT etc... but if we can get anywhere on the 9100s I may just forget the 9010 (unless someone can dig up the cross compiler!). I thought my 232 cable was simpler, 4 wires but I cann't find my notes on that now. John, do we have a list archive? Would be handy (or just add a file to the FTP with this info as you compile it Marc). Third thought. Has anyone tried to tie pins 2 & 3 of the 232 plug together to make the 9010A "fault tolerant". I want to put a switch on my cable to do that, load the program, flip the switch & run the program. Or is there anyway to have the PC monitor output from the 9010A serially & send <CONT> on failures? Thanks, Kev -----Original Message----- From: Marc Alexander <marcwolf123@yahoo.com> To: TechToolsList@flippers.com <TechToolsList@flippers.com> Date: Monday, April 15, 2002 9:54 PM Subject: Fluke <> 232 cable, and what do I press :-)
I think the pinouts I saw archived below, though they may work?, could
cause
damage to the 9010A or com port on the PC, as the handshake lines are wired as two outputs shorted together. Measuring the unconnected pins on both units showed that 4-RTS and 20-DTR were live outputs out of the 9010A, so connecting them to outputs on the PC may cause some problems.
I just got mine working with this pinout:
DB9 Female to PC DB25 Female to 9010A 1 CD input 2 RX input ------------2 TX output 3 TX output------------3 RX input 4 DTR output--------------------\ 5 GND-------------------7 GND | 6 DSR input --------------------/ 7 RTS output----\ 8 CTS input ----/ 9 RI input 4 RTS output 20 DTR input
and it works at 2400,N,8,1 at least, obviously no hardware handshaking may limit the transfer speed, I will try higher. I just used the old Windows 3.11 Terminal program and sent the galaga.h file successfully.
Now the big question! What do I press to run the script/tests? I'm trowelling through PDF files but won't have time to read it all for a couple of days, and haven't found the right pages yet, arrghh :) I understand the script, just not how to run it all, and what to do with each test and failures, etc. Ahh, I just worked out some of it, EXEC, ENTER/YES, etc.. Any tips and steps anyone has would be great, examples of a board test and repair from turn-on to finish, anything.. I will put it into a 'Getting Started' doc, c'mon guys! :-)
Thanks,
Marc
----- Original Message ----- From: "Kev" <KKlopp@erols.com> To: <TechToolsList@flippers.com> Sent: Monday, February 11, 2002 4:21 AM Subject: Fluke <> 232
Okay I finally got my Fluke 9010A talking to the PC.
Cable is
DB9 <-> DB25
2 2 3 3 4 20 5 7 7 4
For some reason I can only get
7, E, 1, 9600 (or slower to work)
I can not get 8, N, 1 to work properly?
Kev
To UNSUBSCRIBE from techtoolslist, send a message with "UNSUBSCRIBE" in the message body to: techtoolslist-request@flippers.com. Please direct other questions, comments, or problems to jrr@flippers.com.
Kev, No real list archive, although I have saved all the messages going back to the start of the list... I get along just fine with a null modem setup and mine runs at 9600 baud. Marc, You can get a listing of the programs on the 9010 by pressing PROGRAM and then =, you will see the list of program numbers. You can run any single program by pressing PROGRAM and then the program number, with "0" being the most common (default) starting number for programs. I find that one can trouble shoot sections of the program by just running that program, for example I've been working on a dog of an Asteroids board and have been working on the script that is now up on the FTP site. Have found a number of minor issues and identified a signature test that if I can figure it out, might simplify the whole vector troubleshooting thing. I've given up on my current dog of a board though...someone else can take over this script for now. ftp.flippers.com/Fluke John :-#)# At 10:22 PM 15/04/2002 -0400, Kev wrote:
<EXEC> <YES>
generally gets you going.
I was thinking that it would be nice to have a text file (I was thinking Word Doc or PDF) that you could print out, 1 page that would tell you some basics to go along with the program.
But then again I've been trying to champion the idea of a uniform "bare bones" program that everyone could use as sort of a standard.
Press 1 for RAM Press 2 for ROM ..... Press 9 for RUN UUT etc...
but if we can get anywhere on the 9100s I may just forget the 9010 (unless someone can dig up the cross compiler!).
I thought my 232 cable was simpler, 4 wires but I cann't find my notes on that now.
John, do we have a list archive? Would be handy (or just add a file to the FTP with this info as you compile it Marc).
Third thought. Has anyone tried to tie pins 2 & 3 of the 232 plug together to make the 9010A "fault tolerant". I want to put a switch on my cable to do that, load the program, flip the switch & run the program. Or is there anyway to have the PC monitor output from the 9010A serially & send <CONT> on failures?
Thanks, Kev
-----Original Message----- From: Marc Alexander <marcwolf123@yahoo.com> To: TechToolsList@flippers.com <TechToolsList@flippers.com> Date: Monday, April 15, 2002 9:54 PM Subject: Fluke <> 232 cable, and what do I press :-)
I think the pinouts I saw archived below, though they may work?, could
cause
damage to the 9010A or com port on the PC, as the handshake lines are wired as two outputs shorted together. Measuring the unconnected pins on both units showed that 4-RTS and 20-DTR were live outputs out of the 9010A, so connecting them to outputs on the PC may cause some problems.
I just got mine working with this pinout:
DB9 Female to PC DB25 Female to 9010A 1 CD input 2 RX input ------------2 TX output 3 TX output------------3 RX input 4 DTR output--------------------\ 5 GND-------------------7 GND | 6 DSR input --------------------/ 7 RTS output----\ 8 CTS input ----/ 9 RI input 4 RTS output 20 DTR input
and it works at 2400,N,8,1 at least, obviously no hardware handshaking may limit the transfer speed, I will try higher. I just used the old Windows 3.11 Terminal program and sent the galaga.h file successfully.
Now the big question! What do I press to run the script/tests? I'm trowelling through PDF files but won't have time to read it all for a couple of days, and haven't found the right pages yet, arrghh :) I understand the script, just not how to run it all, and what to do with each test and failures, etc. Ahh, I just worked out some of it, EXEC, ENTER/YES, etc.. Any tips and steps anyone has would be great, examples of a board test and repair from turn-on to finish, anything.. I will put it into a 'Getting Started' doc, c'mon guys! :-)
Thanks,
Marc
----- Original Message ----- From: "Kev" <KKlopp@erols.com> To: <TechToolsList@flippers.com> Sent: Monday, February 11, 2002 4:21 AM Subject: Fluke <> 232
Okay I finally got my Fluke 9010A talking to the PC.
Cable is
DB9 <-> DB25
2 2 3 3 4 20 5 7 7 4
For some reason I can only get
7, E, 1, 9600 (or slower to work)
I can not get 8, N, 1 to work properly?
Kev
To UNSUBSCRIBE from techtoolslist, send a message with "UNSUBSCRIBE" in the message body to: techtoolslist-request@flippers.com. Please direct other questions, comments, or problems to jrr@flippers.com.
----- Original Message ----- From: "Kev" <KKlopp@erols.com>
<EXEC> <YES>
generally gets you going.
Thanks, I'm having fun trying it out now! I will make some notes of how I got started and what I found. I just did a ridiculous surgical wiring and soldering job on the Z80 pod 40 pin DIP target cable, it was bad just near where it went into the pod case, so I cut the whole cable off shorter, and peeled and stripped the whole thing and spliced it onto a new IDC connector that had a short cable coming out of it already. Now it works :) lots and lots of nice little heatshrink covered attached wires. I have an 8080 pod, and I expected the target 40pin dip cable to behave the same, so I swapped the perfect condition 8080 cable into the Z80 pod, and got a whole lot of intermittent errors (if I put it in loop it would toggle between fail and ok on some tests) It would pass the pod self test fine, but if I used the Z80 pod with the 8080 cable, it would give data errors in use on the board. Now I have some errors from the galaga script, even on a known good working (orig namco) board, I get errors like: ILLEGAL ADDRESS @ 300000-LOOP? ILLEGAL ADDRESS @ 303FFF-LOOP? ILLEGAL ADDRESS @ F0300D-LOOP? ... and so on, and some more after ram tests to begin (but ram tests ok after skipping errors) These start just after selecting which processor (0=4M), and the tests seem to continue ok after ignoring the errors with the CLEAR/NO button.
I was thinking that it would be nice to have a text file (I was thinking Word Doc or PDF) that you could print out, 1 page that would tell you some basics to go along with the program.
It might be nice to make up a template for program/comments text to put in the top of the .s file, and have it all in one place?
But then again I've been trying to champion the idea of a uniform "bare bones" program that everyone could use as sort of a standard.
Yes I've been saving them and intend to use it too, thanks for the great work.
Press 1 for RAM Press 2 for ROM ..... Press 9 for RUN UUT etc...
but if we can get anywhere on the 9100s I may just forget the 9010 (unless someone can dig up the cross compiler!).
I'd be surprised if the 9100's last that long really, with the non-standard drive interface, OS, old hard disks, they are going to rapidly become doorstops unless some major work is done to clone the OS and drives at least to keep them going. At least the 9010A's are easy to service and maintain. I've not heard of any 9100's here in Australia at all in my searching, and only a few 9010A's. I'm the only person here in the country that I know of with a 9010A even!
I thought my 232 cable was simpler, 4 wires but I cann't find my notes on that now.
Your notes and email are the one included below on the one I sent (here below too)
John, do we have a list archive? Would be handy (or just add a file to the FTP with this info as you compile it Marc).
ok.
Third thought. Has anyone tried to tie pins 2 & 3 of the 232 plug together to make the 9010A "fault tolerant". I want to put a switch on my cable to do that, load the program, flip the switch & run the program. Or is there anyway to have the PC monitor output from the 9010A serially & send <CONT> on failures?
I don't understand this feature yet? Thanks, Marc
-----Original Message----- From: Marc Alexander <marcwolf123@yahoo.com> To: TechToolsList@flippers.com <TechToolsList@flippers.com> Date: Monday, April 15, 2002 9:54 PM Subject: Fluke <> 232 cable, and what do I press :-)
I think the pinouts I saw archived below, though they may work?, could
cause
damage to the 9010A or com port on the PC, as the handshake lines are wired as two outputs shorted together. Measuring the unconnected pins on both units showed that 4-RTS and 20-DTR were live outputs out of the 9010A, so connecting them to outputs on the PC may cause some problems.
I just got mine working with this pinout:
DB9 Female to PC DB25 Female to 9010A 1 CD input 2 RX input ------------2 TX output 3 TX output------------3 RX input 4 DTR output--------------------\ 5 GND-------------------7 GND | 6 DSR input --------------------/ 7 RTS output----\ 8 CTS input ----/ 9 RI input 4 RTS output 20 DTR input
and it works at 2400,N,8,1 at least, obviously no hardware handshaking may limit the transfer speed, I will try higher. I just used the old Windows 3.11 Terminal program and sent the galaga.h file successfully.
Now the big question! What do I press to run the script/tests? I'm trowelling through PDF files but won't have time to read it all for a couple of days, and haven't found the right pages yet, arrghh :) I understand the script, just not how to run it all, and what to do with each test and failures, etc. Ahh, I just worked out some of it, EXEC, ENTER/YES, etc.. Any tips and steps anyone has would be great, examples of a board test and repair from turn-on to finish, anything.. I will put it into a 'Getting Started' doc, c'mon guys! :-)
Thanks,
Marc
----- Original Message ----- From: "Kev" <KKlopp@erols.com> To: <TechToolsList@flippers.com> Sent: Monday, February 11, 2002 4:21 AM Subject: Fluke <> 232
Okay I finally got my Fluke 9010A talking to the PC.
Cable is
DB9 <-> DB25
2 2 3 3 4 20 5 7 7 4
For some reason I can only get
7, E, 1, 9600 (or slower to work)
I can not get 8, N, 1 to work properly?
Kev
To UNSUBSCRIBE from techtoolslist, send a message with "UNSUBSCRIBE" in the message body to: techtoolslist-request@flippers.com. Please direct other questions, comments, or problems to jrr@flippers.com.
Now I have some errors from the galaga script, even on a known good
working (orig namco) board,
I get errors like: ILLEGAL ADDRESS @ 300000-LOOP? ILLEGAL ADDRESS @ 303FFF-LOOP? ILLEGAL ADDRESS @ F0300D-LOOP? ... and so on, and some more after ram tests to begin (but ram tests ok after skipping errors)
These start just after selecting which processor (0=4M), and the tests seem to continue ok after ignoring the errors with the CLEAR/NO button.
I'm not clear on this either. Are those scripts specific to the QT pod or can they apply to any??
I was thinking that it would be nice to have a text file (I was thinking Word Doc or PDF) that you could print out, 1 page that would tell you
some
basics to go along with the program.
It might be nice to make up a template for program/comments text to put in the top of the .s file, and have it all in one place?
Yes, probably best. Hopefully John's FTP site will be the difinitive collection of Fluke info.
I'd be surprised if the 9100's last that long really, with the non-standard drive interface, OS, old hard disks, they are going to rapidly become doorstops unless some major work is done to clone the OS and drives at least to keep them going. At least the 9010A's are easy to service and maintain.
I've not heard of any 9100's here in Australia at all in my searching, and only a few 9010A's. I'm the only person here in the country that I know of with a 9010A even!
About 6 months ago there were some pods on E-bay from Australia & I am sure there are more over there than you think. I think there are enough 9100 owners and the 9100 has enough additional capabilities that effort to either keep them going or intergrate them into a PC platform will eventually happen. My biggest hope is we can get some of the original design team to divulge enough info on these to maintain them.
Third thought. Has anyone tried to tie pins 2 & 3 of the 232 plug together to make the 9010A "fault tolerant". I want to put a switch on my cable to do that, load the program, flip the switch & run the program. Or is there anyway to have the PC monitor output from the 9010A serially & send <CONT> on failures?
I don't understand this feature yet?
You know how when the 9010A fails a test command <RAM SHORT @ 0-3FF> it stops? By tying pins 2 to 3 & adding additional code to test the state of the 232 port your program can be "fault tolerant". IE you could create a program that would let you go get a beer and when you got back it wouldn't be stopped at the first fault it found but could list every fault it found. The other problem I've noticed when coding I've strung a bunch of RAMs together & check each pair (2114s on Pole), but when it gives you an error message it just says RAM error at $4401, so now you've got to go back to the memory map & figure out which ram it is. Be nicer if it said VIDEO RAM 7F 8F BAD. This could be done with the 2/3 pin trick I think, but I believe only the 9020 can be connected to a PC and send entries back the the PC like that (unless perhaps someone could write a 232 port monitor program that would also send commands to keep the 9010 going after a fault, is this possible?). The trick is the Volume 2, number 2 of the Troubleshooters (I think?). Kev
Kev, The 3(or 2)XXXXXX are for the QT pod only. If you want to learn about this neat pod (I'll scan it eventually but it's a lot of pages), then read up on the Quick Test in the 68000 manual, the routines are very similar. As for the other docs, I'd like to ask Al Kossow if I can put his collection up there...The docs are also on the FLUKE CD set, if anyone doesn't have that set of training CD's we could plead with the transcriber to run off another set... As for the Troubleshooter booklets, I did scan in the compiled 1984 and 1985 set which has additional info not on the issues previously scanned in. Check the latest uploads to the FTP site (Sunday). I also received a copy of the docs for the FLUKE Utility Tapes which cover the Frequency Check program for the probe as well as Tape Merge and others. Does anyone know how to extract the BINARY portions of programs when they are sent to the 9010? This appears to be a problem with transferring the tapes to PC via the RS-232 port. Anyone have the Utility Tape and can transfer the programs to a PC file? John :-#)# At 10:07 AM 16/04/2002 -0400, Kev wrote:
Now I have some errors from the galaga script, even on a known good
working (orig namco) board,
I get errors like: ILLEGAL ADDRESS @ 300000-LOOP? ILLEGAL ADDRESS @ 303FFF-LOOP? ILLEGAL ADDRESS @ F0300D-LOOP? ... and so on, and some more after ram tests to begin (but ram tests ok after skipping errors)
These start just after selecting which processor (0=4M), and the tests seem to continue ok after ignoring the errors with the CLEAR/NO button.
I'm not clear on this either. Are those scripts specific to the QT pod or can they apply to any??
I was thinking that it would be nice to have a text file (I was thinking Word Doc or PDF) that you could print out, 1 page that would tell you
some
basics to go along with the program.
It might be nice to make up a template for program/comments text to put in the top of the .s file, and have it all in one place?
Yes, probably best. Hopefully John's FTP site will be the difinitive collection of Fluke info.
I'd be surprised if the 9100's last that long really, with the non-standard drive interface, OS, old hard disks, they are going to rapidly become doorstops unless some major work is done to clone the OS and drives at least to keep them going. At least the 9010A's are easy to service and maintain.
I've not heard of any 9100's here in Australia at all in my searching, and only a few 9010A's. I'm the only person here in the country that I know of with a 9010A even!
About 6 months ago there were some pods on E-bay from Australia & I am sure there are more over there than you think.
I think there are enough 9100 owners and the 9100 has enough additional capabilities that effort to either keep them going or intergrate them into a PC platform will eventually happen. My biggest hope is we can get some of the original design team to divulge enough info on these to maintain them.
Third thought. Has anyone tried to tie pins 2 & 3 of the 232 plug together to make the 9010A "fault tolerant". I want to put a switch on my cable to do that, load the program, flip the switch & run the program. Or is there anyway to have the PC monitor output from the 9010A serially & send <CONT> on failures?
I don't understand this feature yet?
You know how when the 9010A fails a test command <RAM SHORT @ 0-3FF> it stops?
By tying pins 2 to 3 & adding additional code to test the state of the 232 port your program can be "fault tolerant". IE you could create a program that would let you go get a beer and when you got back it wouldn't be stopped at the first fault it found but could list every fault it found.
The other problem I've noticed when coding I've strung a bunch of RAMs together & check each pair (2114s on Pole), but when it gives you an error message it just says RAM error at $4401, so now you've got to go back to the memory map & figure out which ram it is. Be nicer if it said VIDEO RAM 7F 8F BAD.
This could be done with the 2/3 pin trick I think, but I believe only the 9020 can be connected to a PC and send entries back the the PC like that (unless perhaps someone could write a 232 port monitor program that would also send commands to keep the 9010 going after a fault, is this possible?).
The trick is the Volume 2, number 2 of the Troubleshooters (I think?).
Kev
John/ List,
Kev, The 3(or 2)XXXXXX are for the QT pod only. If you want to learn about this neat pod (I'll scan it eventually but it's a lot of pages), then read up on the Quick Test in the 68000 manual, the routines are very similar.
Okay, devils advocate again, Which is faster a QT pod or a 9100/9100FT?
As for the Troubleshooter booklets, I did scan in the compiled 1984 and 1985 set which has additional info not on the issues previously scanned in. Check the latest uploads to the FTP site (Sunday).
Got those, thanks again!
I also received a copy of the docs for the FLUKE Utility Tapes which cover the Frequency Check program for the probe as well as Tape Merge and others.
Where are these? I've been going thru some of the code by hand but we all know how slow that is....
Does anyone know how to extract the BINARY portions of programs when they are sent to the 9010? This appears to be a problem with transferring the tapes to PC via the RS-232 port. Anyone have the Utility Tape and can transfer the programs to a PC file?
Isn't there a way to query the location of the file in program memory? Kev
Well, the fastest would be a QT pod on either the 9100 or 9010. See the QT pod does not depend on handshaking between the pod and it's host, rather it runs the tests between it and the UUT as commanded. The basic pods that are not QT all have to be told the address to go to, write that address, tell the base it's written that address, then the base tells it to read the address, the pod then reports what it read, then the base tells it to go to the next address and so on, as you can imagine this all takes a bit of time. The Quick Test is different - the base tells the pod to run the Quick Ram Test between addresses XXXX & YYYY and then the pod goes and does that AT CPU SPEED, then the pod reports back success or failure. If failure then you have to run a program to identify the location via the slower regular ram test. As stated in the 68000 manual and the Technical notes the Quick Test is about 20 times faster than the regular one... The problem I am trying to solve is when you load a program (with binary) via the tape drive into the Fluke, can you extract it via the RS-232 port or can you only do this process with the tape drive? John :-#)# Oh, and the question has arisen about how to subscribe/unsubscribe from the list: To do either you send email to "MajorDomo@flippers.com" and in the body you state either "Subscribe techtoolslist" or "Unsubscribe techtoolslist", note that the Subject is "" (Blank)... At 01:19 PM 16/04/2002 -0400, Kev wrote:
John/ List,
Kev, The 3(or 2)XXXXXX are for the QT pod only. If you want to learn about this neat pod (I'll scan it eventually but it's a lot of pages), then read up on the Quick Test in the 68000 manual, the routines are very similar.
Okay, devils advocate again, Which is faster a QT pod or a 9100/9100FT?
As for the Troubleshooter booklets, I did scan in the compiled 1984 and 1985 set which has additional info not on the issues previously scanned in. Check the latest uploads to the FTP site (Sunday).
Got those, thanks again!
I also received a copy of the docs for the FLUKE Utility Tapes which cover the Frequency Check program for the probe as well as Tape Merge and others.
Where are these? I've been going thru some of the code by hand but we all know how slow that is....
Does anyone know how to extract the BINARY portions of programs when they are sent to the 9010? This appears to be a problem with transferring the tapes to PC via the RS-232 port. Anyone have the Utility Tape and can transfer the programs to a PC file?
Isn't there a way to query the location of the file in program memory?
Kev
Firstly, thanks very much Kev and John for the info to get me started, I really appreciate it. Please note with my comments below I haven't hardly started reading the docs, just looking at scripts and ideas... Does anyone use the mame source code drivers memory map and hardware info to help with writing the scripts? I've been putting one together based on Kev's and the galaga.c mame driver to get started. So far I've done almost nothing but begin to add some comments in and the galaga memory map to the bottom, otherwise it is still the unedited V3 script from Kev. Do you use RKSIC.EXE or 9LC.EXE to compile it? or either? What are the pros and cons of each one? (I'm trying to work out what I can get away with with comments and script format)
Third thought. Has anyone tried to tie pins 2 & 3 of the 232 plug together to make the 9010A "fault tolerant". I want to put a switch on my cable to do that, load the program, flip the switch & run the program. Or is there anyway to have the PC monitor output from the 9010A serially & send <CONT> on failures? I don't understand this feature yet?
You know how when the 9010A fails a test command <RAM SHORT @ 0-3FF> it stops?
By tying pins 2 to 3 & adding additional code to test the state of the 232 port your program can be "fault tolerant". IE you could create a program that would let you go get a beer and when you got back it wouldn't be stopped at the first fault it found but could list every fault it found.
I see a SETUP MESSAGES code called SET-EXERCISE ERRORS? on the reference card that has this description: "Determines whether error messages and prompts for looping on errors are displayed" You could also use REG8 or REG9 to keep user entered script controls and counts: a) Have a user input yes/no to a "stop on errors" prompt at the start of the script, or is the setup code only allowed at the script start? b) Count the number of errors? and display it at the end of the tests if non-zero. If there were 8 tests, you could store a bit pattern in the register, and then report which tests failed at the end based on which bits were on. (if this thing will do the appropriate math on the register?)
The other problem I've noticed when coding I've strung a bunch of RAMs together & check each pair (2114s on Pole), but when it gives you an error message it just says RAM error at $4401, so now you've got to go back to the memory map & figure out which ram it is. Be nicer if it said VIDEO RAM 7F 8F BAD.
Isn't it possible to split the ram tests up into memory mapped pieces that match the chips or chip pairs? If there's a fault could it branch to a sub-test program that poked 0x00 and 0xFF into the failed address and reported the faulty read-back result? This would show which of the 4bit 2114's may be at fault. If the ram (or rom) test failed couldn't the script go to a sub-test that just poked that address only, continuously, so you could find the chip enable on the faulty ram/rom ? (or is that the looping function anyway :-) ) Cheers, Marc "9010A Galaga Script 1.txt" (missing attachment)
You are a programmer aren't you? I want you on my Pod to PC interface project team! (actually I'd like anyone on the team ;-) I use RKSIC, as it works in Windows, and by and large does everything needed. Still need to find out about transferring Binary programs via the RS-232 port... Al Kossow says it;s fine to copy his Fluke stuff to the archive, so I think I'll make up a page for it on my web site and provide the links for my FTP section, a little cleaner interface would be nice, eh? Now, does Mark (basementarcade)say it's OK to put any of his PDFs up as well? Anyone here familiar with version 1.94.4 of Majordomo? I need to set up an archive, and a digest... John :-#)# At 02:35 PM 17/04/2002 +1000, Marc Alexander wrote:
Firstly, thanks very much Kev and John for the info to get me started, I really appreciate it.
Please note with my comments below I haven't hardly started reading the docs, just looking at scripts and ideas...
Does anyone use the mame source code drivers memory map and hardware info to help with writing the scripts? I've been putting one together based on Kev's and the galaga.c mame driver to get started. So far I've done almost nothing but begin to add some comments in and the galaga memory map to the bottom, otherwise it is still the unedited V3 script from Kev.
Do you use RKSIC.EXE or 9LC.EXE to compile it? or either? What are the pros and cons of each one? (I'm trying to work out what I can get away with with comments and script format)
Third thought. Has anyone tried to tie pins 2 & 3 of the 232 plug together to make the 9010A "fault tolerant". I want to put a switch on my cable to do that, load the program, flip the switch & run the program. Or is there anyway to have the PC monitor output from the 9010A serially & send <CONT> on failures? I don't understand this feature yet?
You know how when the 9010A fails a test command <RAM SHORT @ 0-3FF> it stops?
By tying pins 2 to 3 & adding additional code to test the state of the 232 port your program can be "fault tolerant". IE you could create a program that would let you go get a beer and when you got back it wouldn't be stopped at the first fault it found but could list every fault it found.
I see a SETUP MESSAGES code called SET-EXERCISE ERRORS? on the reference card that has this description: "Determines whether error messages and prompts for looping on errors are displayed"
You could also use REG8 or REG9 to keep user entered script controls and counts: a) Have a user input yes/no to a "stop on errors" prompt at the start of the script, or is the setup code only allowed at the script start? b) Count the number of errors? and display it at the end of the tests if non-zero.
If there were 8 tests, you could store a bit pattern in the register, and then report which tests failed at the end based on which bits were on. (if this thing will do the appropriate math on the register?)
The other problem I've noticed when coding I've strung a bunch of RAMs together & check each pair (2114s on Pole), but when it gives you an error message it just says RAM error at $4401, so now you've got to go back to the memory map & figure out which ram it is. Be nicer if it said VIDEO RAM 7F 8F BAD.
Isn't it possible to split the ram tests up into memory mapped pieces that match the chips or chip pairs? If there's a fault could it branch to a sub-test program that poked 0x00 and 0xFF into the failed address and reported the faulty read-back result? This would show which of the 4bit 2114's may be at fault.
If the ram (or rom) test failed couldn't the script go to a sub-test that just poked that address only, continuously, so you could find the chip enable on the faulty ram/rom ? (or is that the looping function anyway :-) )
Cheers,
Marc
----- Original Message ----- From: "John Robertson" <jrr@flippers.com
You are a programmer aren't you? I want you on my Pod to PC interface project team! (actually I'd like anyone on the team ;-)
Yes I am, but I must apologise about not being able to work on the Pod to PC project at least at the moment :-(, I have many months of overloaded work to catch up on, and a young boy, wife, etc too that keep me pretty busy!
I use RKSIC, as it works in Windows, and by and large does everything needed. Still need to find out about transferring Binary programs via the RS-232 port...
RKSIC works for me except for the serial port comms, it hangs up on an attempted download, so I use another terminal program to send the .h file, after using RKSIC to compile it. (Win98SE, Dell Inspiron 5000 laptop) Cheers, Marc
needed. Still need to find out about transferring Binary programs via the RS-232 port...
The 9LC compiler manual seems to imply that you cannot transfer Binary programs. How does Fredericks compiler handle this? Kev
Are the probes for the 9010A compatible with the 9100 probes? I thought I read the 9100 probe has a yellow indicator also. Thanks, Kev
The manual for the 9100 shows the probe schematic, it is different than the regular probe, but should be able to be made into one of those probe bodies that show up every now and then. I found one for the logic probe that was used by the same folks that made the Cheap Squeak. I think I found the empty probe case on www.BGMicro.com or was it Jameco, I can't see it in the BG catalog now... John :-#)# At 01:59 PM 22/04/2002 -0400, Kev wrote:
Are the probes for the 9010A compatible with the 9100 probes?
I thought I read the 9100 probe has a yellow indicator also.
Thanks, Kev
I see now that the 9100 getting started & automated operations manuals are not online. Are these available? if not I'll see if I can get those & scan them as well. Reading thru some of the online manuals it does appear that the 9100 may be connected to a host PC via 232 and file transfer both directions is possible. Once a file in on the 9100 it can be converted from text to program. Is there any utilities for this? Is there any documented programs? Are floppies swapable between units/users? Thanks, Kev
No, they are different. The 9010 probe has a 9 pin connector and the 9100 probe has a 15 pin connector. The 9100 probe also has red, yellow and green indicators for signalling high, unknown/no reading or low signal at the tip. -Chris --- Kev <KKlopp@erols.com> wrote:
Are the probes for the 9010A compatible with the 9100 probes?
I thought I read the 9100 probe has a yellow indicator also.
Thanks, Kev
__________________________________________________ Do You Yahoo!? Yahoo! Games - play chess, backgammon, pool and more http://games.yahoo.com/
Does anyone use the mame source code drivers memory map and hardware info to help with writing the scripts?
No better resource that I know of. There are some gotchas in MAME but I haven't run into any problems yet.
Do you use RKSIC.EXE or 9LC.EXE to compile it? or either? What are the pros and cons of each one? (I'm trying to work out what I can get away with with comments and script format)
I use RKSIC.EXE, since it is has the transfer program too & I like some of the features.
I see a SETUP MESSAGES code called SET-EXERCISE ERRORS? on the reference card that has this description: "Determines whether error messages and prompts for looping on errors are displayed"
You could also use REG8 or REG9 to keep user entered script controls and counts: a) Have a user input yes/no to a "stop on errors" prompt at the start of the script, or is the setup code only allowed at the script start?
I don't know if you can do that or not? I belive that Set-Exercise errors is just a prompt to loop. I don't think you can supress error messages.
b) Count the number of errors? and display it at the end of the tests if non-zero.
If there were 8 tests, you could store a bit pattern in the register,
and
then report which tests failed at the end based on which bits were on. (if this thing will do the appropriate math on the register?)
Troubleshooter Volume 2 Number 1 2nd page has the 232 dongle & code approach.
The other problem I've noticed when coding I've strung a bunch of RAMs together & check each pair (2114s on Pole), but when it gives you an error message it just says RAM error at $4401, so now you've got to go back to the memory map & figure out which ram it is. Be nicer if it said VIDEO RAM 7F 8F BAD.
Isn't it possible to split the ram tests up into memory mapped pieces that match the chips or chip pairs?
Yes I generally do that, ROMs are checksumed by chip, RAM are checked by chip or block (2x2114s).
If there's a fault could it branch to a sub-test program that poked 0x00 and 0xFF into the failed address and reported the faulty read-back result? This would show which of the 4bit 2114's may be at fault.
The error message usually tells you what failure you have.
If the ram (or rom) test failed couldn't the script go to a sub-test that just poked that address only, continuously, so you could find the chip enable on the faulty ram/rom ? (or is that the looping function anyway :-) )
Yes you can do looping for that.
Okay, my trust old stackable Sears toolbox just dumped all its contents out on the street again today. I like the design of this box as it has 2 stackable tool trays & 1 deep compartment, flat top. I also liked that it has "lockable" clasp on the 2 sides. I've even shipped it before by zip tying the clasp shut & sticking a Fed Ex label on it. Problem is the plastic clasp have fatigued and don't stay latched securely (or it is possible to close it without it latching securely). Anyhow I'm looking for suggestions for a new portable tool box. It should be sealable (don't really want a lock or combination lock). It should be durable (I'd like to also be able to use it as a stool). It should be usable as carry on (I carry on trains). Thanks, Kev
Hi Kev, Thanks for all the info, I will try some of the tips and read the troubleshooting section next time I'm using the 9010A
From: "Kev" <KKlopp@erols.com>
Does anyone use the mame source code drivers memory map and hardware info to help with writing the scripts? No better resource that I know of. There are some gotchas in MAME but I haven't run into any problems yet.
ok great. I did a quick edit and changes to the original galaga.s script, to make it work on the standard Z80 pod, and the particular rom set I was using. Definitely some research and addition to all the tests will be required later especially to test out the sound and video hardware, the script only tests the cpu accessible memory space and pathways, and not the rest of the commonly faulty galaga problems on the bottom board or sound section :) Anyway here it is with the ROM's I used also. I have since discovered these roms are not quite the right ones for this orig. Namco Galaga board, they work fine except in attract mode the 'fighter captured' example the fighter is off to the left briefly when captured. Works perfectly in game play. I'd better type in my 'how to' notes before my memory goes away! Best regards, Marc "Galaga test script and reference roms.zip" (missing attachment)
Hi Marc, Oh, right, the Galaga script is written for the Z80QT (Quick Test) pod, that almost no-on has... The references to memory space above FFFF that are not the I/O (1XXXX) are all to do with extended fast tests that are included in that QT pod. I am hoping to get a pod lent to me so I can look into reproducing it. John :-#)# At 11:09 PM 16/04/2002 +1000, Marc Alexander wrote:
----- Original Message ----- From: "Kev" <KKlopp@erols.com>
<EXEC> <YES>
generally gets you going.
Thanks, I'm having fun trying it out now! I will make some notes of how I got started and what I found.
I just did a ridiculous surgical wiring and soldering job on the Z80 pod 40 pin DIP target cable, it was bad just near where it went into the pod case, so I cut the whole cable off shorter, and peeled and stripped the whole thing and spliced it onto a new IDC connector that had a short cable coming out of it already. Now it works :) lots and lots of nice little heatshrink covered attached wires.
I have an 8080 pod, and I expected the target 40pin dip cable to behave the same, so I swapped the perfect condition 8080 cable into the Z80 pod, and got a whole lot of intermittent errors (if I put it in loop it would toggle between fail and ok on some tests) It would pass the pod self test fine, but if I used the Z80 pod with the 8080 cable, it would give data errors in use on the board.
Now I have some errors from the galaga script, even on a known good working (orig namco) board, I get errors like: ILLEGAL ADDRESS @ 300000-LOOP? ILLEGAL ADDRESS @ 303FFF-LOOP? ILLEGAL ADDRESS @ F0300D-LOOP? ... and so on, and some more after ram tests to begin (but ram tests ok after skipping errors)
These start just after selecting which processor (0=4M), and the tests seem to continue ok after ignoring the errors with the CLEAR/NO button.
I was thinking that it would be nice to have a text file (I was thinking Word Doc or PDF) that you could print out, 1 page that would tell you some basics to go along with the program.
It might be nice to make up a template for program/comments text to put in the top of the .s file, and have it all in one place?
But then again I've been trying to champion the idea of a uniform "bare bones" program that everyone could use as sort of a standard.
Yes I've been saving them and intend to use it too, thanks for the great work.
Press 1 for RAM Press 2 for ROM ..... Press 9 for RUN UUT etc...
but if we can get anywhere on the 9100s I may just forget the 9010 (unless someone can dig up the cross compiler!).
I'd be surprised if the 9100's last that long really, with the non-standard drive interface, OS, old hard disks, they are going to rapidly become doorstops unless some major work is done to clone the OS and drives at least to keep them going. At least the 9010A's are easy to service and maintain.
I've not heard of any 9100's here in Australia at all in my searching, and only a few 9010A's. I'm the only person here in the country that I know of with a 9010A even!
I thought my 232 cable was simpler, 4 wires but I cann't find my notes on that now.
Your notes and email are the one included below on the one I sent (here below too)
John, do we have a list archive? Would be handy (or just add a file to the FTP with this info as you compile it Marc).
ok.
Third thought. Has anyone tried to tie pins 2 & 3 of the 232 plug together to make the 9010A "fault tolerant". I want to put a switch on my cable to do that, load the program, flip the switch & run the program. Or is there anyway to have the PC monitor output from the 9010A serially & send <CONT> on failures?
I don't understand this feature yet?
Thanks,
Marc ....
Is there more than one version of the 9100 OS? How about the firmware? Reason I ask, one of the casual list readers has a 2 9100s one that appears to be the last issue & appears to be military specific (?) that seems to be incompatible with the other earlier unit. Any insight? Thanks, Kev
participants (4)
-
Chris Loggans -
John Robertson -
Kev -
Marc Alexander