Re: Replace the 9010A base with an IBM Parallel port?
Well it is an interesting idea but base (9005, 9010A, 9020 & 9100) units are not too difficult to buy yet (compared to certain pods). I don't think there would be much profit motive, unless someone was to reproduce the pods also. Anyone remember the RATBOX project. Don't get me wrong John (or anyone else), I'd love to see the project move forward, but I'd rather see progress on the Z8002 interface now which is non existant versus work on a "available" unit replacement. Does anyone have a DUMP of the PROM in the Z8002 interface for a CAT Box? Kev
Looking over the requirements and commands for the pod, I think it is "possible" to use the parallel port to handle data transfer and handshaking. There are only a few interface lines "MainStat" (MS), "PodStat" (PS), "Reset" (R), "Sync" (S), and "Power Fail" (PF). And 8 data lines...
Now most of these lines are run through a 6520 (similar if not identical to a 6821 PIA), thus the data lines and control lines MS, PS, PF and R all come out of the PIA. Thus NONE of these are very fast at all! I strongly suspect the ECC Parallel port can handle them, now there remains, Sync, and I don't know how fast it runs, but it is for timing the Probe and Probe Signature generator and is not used anywhere else. Perhaps we can ignore it for now....it appears to run at 1/2 the pod Z80 write speed, but I'll have to check that further.
So, we need some bright person to handle the software, the hardware looks like, well just a jumper cable with some power (+5, +12 and -5) and the -5 could be created with a simple 555 driving a small negative bridge recitifer. Looks like minimal current, in fact as far as I can see (at least for the Z80 pod) the -5 is only to bias the voltage sense circuit.
Comments? Is ANYONE interested in this? I'mm not getting a lot of feedback on these ideas I'm chucking out into the void...
John :-#)#
Ah, but the base is so sssllloooowwwwwwww. I figure running the pods from the port will get a much faster operation, plus the programming could be much easier. I'd like to download RAM test code to the UUT, but to do that with the current configuration means figuring it out on the IBM, then porting it to the base after writing a program, then run the base and see what happens. Seems that cutting out a few intermediate steps would be worth the development time. Think, ROM signature/checksums in a few seconds, FAST RAM tests, ability to leap buildings with a single...well not that. I'm finding we are using the 9010 more and more in my shop, and anything that increases the speed of tests and setup is well worth it to me. Perhaps the question I should be asking folks is "How many here actually are USING the 9010 in their day-to-day lives?" I mean if it is just a hobby for everyone else then I'll work on it on my own for our shops benefit, but if any others also do the same sort of thing (board repairs), then let's work together to make this a more useful device. John :-#)# At 09:55 PM 25/02/2002 -0500, Kev wrote:
Well it is an interesting idea but base (9005, 9010A, 9020 & 9100) units are not too difficult to buy yet (compared to certain pods).
I don't think there would be much profit motive, unless someone was to reproduce the pods also.
Anyone remember the RATBOX project.
Don't get me wrong John (or anyone else), I'd love to see the project move forward, but I'd rather see progress on the Z8002 interface now which is non existant versus work on a "available" unit replacement.
Does anyone have a DUMP of the PROM in the Z8002 interface for a CAT Box?
Kev
Looking over the requirements and commands for the pod, I think it is "possible" to use the parallel port to handle data transfer and handshaking. There are only a few interface lines "MainStat" (MS), "PodStat" (PS), "Reset" (R), "Sync" (S), and "Power Fail" (PF). And 8 data lines...
Now most of these lines are run through a 6520 (similar if not identical to a 6821 PIA), thus the data lines and control lines MS, PS, PF and R all come out of the PIA. Thus NONE of these are very fast at all! I strongly suspect the ECC Parallel port can handle them, now there remains, Sync, and I don't know how fast it runs, but it is for timing the Probe and Probe Signature generator and is not used anywhere else. Perhaps we can ignore it for now....it appears to run at 1/2 the pod Z80 write speed, but I'll have to check that further.
So, we need some bright person to handle the software, the hardware looks like, well just a jumper cable with some power (+5, +12 and -5) and the -5 could be created with a simple 555 driving a small negative bridge recitifer. Looks like minimal current, in fact as far as I can see (at least for the Z80 pod) the -5 is only to bias the voltage sense circuit.
Comments? Is ANYONE interested in this? I'mm not getting a lot of feedback on these ideas I'm chucking out into the void...
John :-#)#
I don't think there would be much profit motive, unless someone was to reproduce the pods also.
Ah, but the base is so sssllloooowwwwwwww....
Just for my own trivia, riddle me this: If it is so slow, and saved time would = $$, how much would it be worth, to you (John), to have the system ported to the PC? I use the 9000 system frequently. I don't find it particularly slow. In fact I find the slowest part is how long it takes me to translate the test results (not obtain them). It could be faster, but I tend to agree with Kevin; is it worth it... You can download test code to UUT ram today, quickly enough by using the tape drive. Plus you only have to "figure it out" on one platform. BTW, it does sound like a fun project, but I have to wonder if it is the best place to put what little time we have. -Mark
Ah, but the base is so sssllloooowwwwwwww....
I use the 9000 system frequently. I don't find it particularly slow. In fact I find the slowest part is how long it takes me to translate the test results (not obtain them).
Yes I agree things are slow, especially in the world of every quickening mouse click rates. But if you consider that compared to dragging out some other tool, pulling chips & reading them in EPROM reader etc.... you are miles ahead with the Fluke already. Yes I'm interested in what makes a pod a quick test version. I'd like to see faster ROM/RAM reads. As to Mark's comment, I belive the solution is a "canned" test program for your particular board, like the Galaga & Asteroids programs. You don't need to scratch around & look up memory maps or Fluke checksums. This is my current struggle, documenting good working boards and then if I ever get the time write test programs. Rereading Johns message, I think that is part of his problem too. Once you have the communication software running (rksic.exe), dropping in a canned program is pretty quick & then you are running test. Writing & compiling a program that works properly takes time. Everyone would be faster with more canned programs....removes the thinking aspect. Kev
What I'm trying to do is to simplify the operation so my regular techs can use the machine without quite a bit of training. Maybe I'm not too swift, but it seems to take a long time to learn how to use the pods effectively, I'm looking to make it a more script based, follow the flow-chart way of fixing. I am writing test procedures as it is, but am frustrated by the lack of information on how to insert assembler routines etc. We see quite a variety of boards as it is, and getting the signatures for each is time consuming the 1st time. Fluke could have done a MUCH better job of explaining their programming system...but the examples they give, plus the scripts one the archive site have made it much easier to write fresh stuff. Currently I'm working on a System 80 test script that will exercise the entire board and should give results down to the individual failed IC. this is taking Lots of time.... Still looking for someone with a Z80-QT pod... John :-#)# At 08:38 PM 25/02/2002 -0600, Mark Shostak wrote:
I don't think there would be much profit motive, unless someone was to reproduce the pods also.
Ah, but the base is so sssllloooowwwwwwww....
Just for my own trivia, riddle me this:
If it is so slow, and saved time would = $$, how much would it be worth, to you (John), to have the system ported to the PC?
I use the 9000 system frequently. I don't find it particularly slow. In fact I find the slowest part is how long it takes me to translate the test results (not obtain them). It could be faster, but I tend to agree with Kevin; is it worth it...
You can download test code to UUT ram today, quickly enough by using the tape drive. Plus you only have to "figure it out" on one platform.
BTW, it does sound like a fun project, but I have to wonder if it is the best place to put what little time we have.
-Mark
Yes I agree. I pulled out DK Jr boards last night to work on them for the first time with a Fluke, I had to drag out a memory map & run a Auto Learn (10 minute break there). And given that I didn't have a known working board to start with I'm really in the hole. The sound generator is well documented as are the I/O but it still will take some time to scratch out the basis for a Script....which leads to the next question. The Asteroids script is nice but the Interface screen exceeds the display. Do we want to adapt a "protocol" for Inteface Such as 1 = ROM checksums 2 = RAM etc....? But then this compiled information / scripts is a valuable timesaver & can give you a competitive edge over your competition so why give it away for free? I don't know about you guys but I've got so much potential work staring at me that I'll never see the end of it no matter how efficient/fast I was and I know I would not be taking work away from anyone else (here or otherwise). Kev
What I'm trying to do is to simplify the operation so my regular techs can use the machine without quite a bit of training. Maybe I'm not too swift, but it seems to take a long time to learn how to use the pods effectively, I'm looking to make it a more script based, follow the flow-chart way of fixing. I am writing test procedures as it is, but am frustrated by the lack of information on how to insert assembler routines etc. We see quite a variety of boards as it is, and getting the signatures for each is time consuming the 1st time.
well, the main reason for the 'IBM Fluke' idea, was with an open source program (which is what I plan to do if it ever becomes reality) extra options not in the original fluke could be added - for instance the 9010 has a mask for ram tests, useful where the colour map ram is only 4 bits for instance, this could very easily be done in software. other ideas were to allow 'templates' for boards to be created, detailing memory maps, rom signatures, page mechanisms (to allow all pages to be checked) etc. - for building the original (simple) templates it would be fairly easy to add an option for mame to create them (at least ram/rom checksums (multiple where various bootlegs exist) other advantages include reading roms direct to files on the PC, using built in ROMIDENT to identify roms - basically, anything you lot can think of! I have a bid on an 8088 pod (which I can;t check, becuase my stupid microsoft based internet connection just decided to drop the line and the wife is now on the phone!) which I am hoping to use to test the communication protocol without risk to my more useful pods (z80 and 68000) if anyone has info on the connections etc, then it will all be appreciated and may help the idea become reality oh, and the other reason for the idea, when I go anywhere to look at arcade stuff, I always take the laptop and the eprom programmer, so if I can drive the pod from the laptop, I don;t need to take the fluke too!
Looking over the architecture of the Fluke it appears that one could build a small interface box that would allow the use of the probe as well as the pod. One also would want the SYNC function to enable the scope, but that would be trivial on the Parallel port interface. Just need a BNC connector is all, I think! Having a probe to enable a Guided Fault test routine is a great plus. Of course, one could use a simple interface for a Serial Port as well, and one could still use the probe's I/O features... An old (or not so old) notebook computer that is a complete test fixture/burner is quite intriguing...sell your bases now while they are still worth something ;-) John :-#)# At 07:37 PM 26/02/2002 +0000, Mike Coates wrote:
well, the main reason for the 'IBM Fluke' idea, was with an open source program (which is what I plan to do if it ever becomes reality) extra options not in the original fluke could be added - for instance the 9010 has a mask for ram tests, useful where the colour map ram is only 4 bits for instance, this could very easily be done in software. other ideas were to allow 'templates' for boards to be created, detailing memory maps, rom signatures, page mechanisms (to allow all pages to be checked) etc. - for building the original (simple) templates it would be fairly easy to add an option for mame to create them (at least ram/rom checksums (multiple where various bootlegs exist)
other advantages include reading roms direct to files on the PC, using built in ROMIDENT to identify roms - basically, anything you lot can think of!
I have a bid on an 8088 pod (which I can;t check, becuase my stupid microsoft based internet connection just decided to drop the line and the wife is now on the phone!) which I am hoping to use to test the communication protocol without risk to my more useful pods (z80 and 68000)
if anyone has info on the connections etc, then it will all be appreciated and may help the idea become reality
oh, and the other reason for the idea, when I go anywhere to look at arcade stuff, I always take the laptop and the eprom programmer, so if I can drive the pod from the laptop, I don;t need to take the fluke too!
Having a probe to enable a Guided Fault test routine is a great plus. Of course, one could use a simple interface for a Serial Port as well, and one could still use the probe's I/O features...
An old (or not so old) notebook computer that is a complete test fixture/burner is quite intriguing...sell your bases now while they are still worth something ;-)
And, with some speech synth s/w, I can see it now: "John, Please replace the AE35 AVG Controller, it appears to be inoperative." Followed some time later by: "What are you doing John? John? Why are you removing my G08 outputs? Stop... John. Stop. ...Daisy, Daisy...". Oy --- Automated test would be nice. With the existing h/w (i.e. Fluke + pods + tape or serial), all that is required is script developement. For what we're discussing here, there is h/w development, s/w development AND script development. Again, it sounds fun and it would be nice to have, but can the effort be justified by the return? The people who can do this type of thing, can alreay fix the boards fairly fast as it is. I don't see the ROI. So what's the motivation? All I see is "fun", but that motivation dies quickly when the real drudgery hits. -Mark
The motivation is, how to keep these old boards running with a minimum of time invested. We get up to five boards a day in for repairs and anything I can do to improve the throughput (about a month behind currently) would be a plus. That's my motivation...not 2001 (very cute though, ROTFL). I think that combining the pods with the modern computer would be a useful addition to the techs bench. There are still LOTs of these out in the real world as well you know....many of them are fixing things other than old video games. I suspect that so many of them turn up for auction is the frustration with the time curve of using them effectively. It is just an intellectual toy, fun, but is it worth the time? I still think it is, but I can't write software effectively....but I'm going to keep poking at it in my spare time...one needs a hobby after all... Perhaps porting Fredric's code to the IBM is the best solution...not an enormous amount of time, and a few new cool tricks. John :-#)# At 03:40 AM 27/02/2002 -0600, Mark Shostak wrote:
Having a probe to enable a Guided Fault test routine is a great plus. Of course, one could use a simple interface for a Serial Port as well, and one could still use the probe's I/O features...
An old (or not so old) notebook computer that is a complete test fixture/burner is quite intriguing...sell your bases now while they are still worth something ;-)
And, with some speech synth s/w, I can see it now:
"John, Please replace the AE35 AVG Controller, it appears to be inoperative."
Followed some time later by:
"What are you doing John? John? Why are you removing my G08 outputs? Stop... John. Stop. ...Daisy, Daisy...".
Oy
---
Automated test would be nice. With the existing h/w (i.e. Fluke + pods + tape or serial), all that is required is script developement. For what we're discussing here, there is h/w development, s/w development AND script development.
Again, it sounds fun and it would be nice to have, but can the effort be justified by the return?
The people who can do this type of thing, can alreay fix the boards fairly fast as it is.
I don't see the ROI. So what's the motivation? All I see is "fun", but that motivation dies quickly when the real drudgery hits.
-Mark
I think that combining the pods with the modern computer would be a useful addition to the techs bench. There are still LOTs of these out in the real
Agreed, but I'm not the guy to build it either....
world as well you know....many of them are fixing things other than old video games. I suspect that so many of them turn up for auction is the frustration with the time curve of using them effectively.
Hmm, I wonder about this. I found some fluke stuff in aviation repair shops but I too wonder how many people really use these things. It seems that most of the units are sitting on test equipment resellers shelves still trying to be sold for a PREMIUM. Guess they are waiting on the modern computer replacement too.
It is just an intellectual toy, fun, but is it worth the time? I still think it is, but I can't write software effectively....but I'm going to keep poking at it in my spare time...one needs a hobby after all...
Perhaps porting Fredric's code to the IBM is the best solution...not an enormous amount of time, and a few new cool tricks.
Agreed. If I could just get that Freq Counter function going (I haven't heard from Fredric, has anyone lately?). I'm still a excited about modifing the existing scripts (ex Asteroids -> Battlezone) and writing a script for Donkey Kong essentially copying the existing script formats. Kev
I have chatted with Fredric about porting the code over and he is going to help me with the original BASIC compiler software (he's getting permission to send me a copy) so I can figure out the structure to enable it to be ported to something like Liberty BASIC... John :-#)# At 08:31 AM 27/02/2002 -0500, Kev wrote:
I think that combining the pods with the modern computer would be a useful addition to the techs bench. There are still LOTs of these out in the real
Agreed, but I'm not the guy to build it either....
world as well you know....many of them are fixing things other than old video games. I suspect that so many of them turn up for auction is the frustration with the time curve of using them effectively.
Hmm, I wonder about this. I found some fluke stuff in aviation repair shops but I too wonder how many people really use these things. It seems that most of the units are sitting on test equipment resellers shelves still trying to be sold for a PREMIUM. Guess they are waiting on the modern computer replacement too.
It is just an intellectual toy, fun, but is it worth the time? I still think it is, but I can't write software effectively....but I'm going to keep poking at it in my spare time...one needs a hobby after all...
Perhaps porting Fredric's code to the IBM is the best solution...not an enormous amount of time, and a few new cool tricks.
Agreed. If I could just get that Freq Counter function going (I haven't heard from Fredric, has anyone lately?).
I'm still a excited about modifing the existing scripts (ex Asteroids -> Battlezone) and writing a script for Donkey Kong essentially copying the existing script formats.
Kev
Well I reckon the idea of replicating the 9010a base unit with a PC is cool. If you reckon it'll pay for itself in reduced testing time then you have a great excuse to have some fun doing it! I have ideas to replace the whole lot with a home made computer running a H64180 processor (supercharged 12MHz Z80), an LCD dot-matrix screen and a multi-tasking Forth operating system, as I used to design and program them for a living. That's what I call fun! However, I've wanted to do that for about 4 years, since having a CatBOX to play with for a year, so it's a long term project. I hope you do do it, as it's my hobby as well and it's gives me something to talk about to Mike Coates et al when we meet up :-) Cheers, Phillip Eaton
-----Original Message----- From: owner-techtoolslist@www.flippers.com [mailto:owner-techtoolslist@www.flippers.com]On Behalf Of John Robertson Sent: 27 February 2002 16:38 To: Kev; techToolsList@flippers.com Subject: Re: Replace the 9010A base with an IBM Parallel port?
I have chatted with Fredric about porting the code over and he is going to help me with the original BASIC compiler software (he's getting permission to send me a copy) so I can figure out the structure to enable it to be ported to something like Liberty BASIC...
John :-#)#
At 08:31 AM 27/02/2002 -0500, Kev wrote:
I think that combining the pods with the modern computer would be a useful addition to the techs bench. There are still LOTs of these out in the real
Agreed, but I'm not the guy to build it either....
world as well you know....many of them are fixing things other than old video games. I suspect that so many of them turn up for auction is the frustration with the time curve of using them effectively.
Hmm, I wonder about this. I found some fluke stuff in aviation repair shops but I too wonder how many people really use these things. It seems that most of the units are sitting on test equipment resellers shelves still trying to be sold for a PREMIUM. Guess they are waiting on the modern computer replacement too.
It is just an intellectual toy, fun, but is it worth the time? I still think it is, but I can't write software effectively....but I'm going to keep poking at it in my spare time...one needs a hobby after all...
Perhaps porting Fredric's code to the IBM is the best solution...not an enormous amount of time, and a few new cool tricks.
Agreed. If I could just get that Freq Counter function going (I haven't heard from Fredric, has anyone lately?).
I'm still a excited about modifing the existing scripts (ex Asteroids -> Battlezone) and writing a script for Donkey Kong essentially copying the existing script formats.
Kev
I am ordering a copy of the Z80-QT manual. $23US from Fluke. Will post a PDF. It seems they are dropping the 9010 support soon.......... John :-#)#
Hmm, interesting results...I've decided to go with just a single READ command and that come back with essentially 5 bytes. The problem is the first 3 are NOT consistent (at least I haven't figure them out yet, however the last two are the actual data at the location and a STOP (00). Oh, and if you do a REPEAT you get two additional different results. The first REPEAT after a new read gives you a one byte less of info, but still with the data and stop, and the second and any subsequent REPEATS ALWAYS is following three bytes "05 data 00" I assume the 05 is sent to the pod and it replies with the data and 00. Thus 05 means "read same location" Note that MAINSTAT goes Low about 50 us before PODSTAT and it rises midway through PODSTAT (about 150us I think, but this SoftLA has no grid or scale). So if you are collecting data you MUST read from a different location each time... Here is a listing of my results for a few locations and see if you can figure out the pattern Read @ Location Data Stop 0000 AA = 00 23 00 AA 00 (result) 0101 FE = 00 21 00 FE 00 0200 EF = 01 35 02 00 EF 00(result - a little longer this time...) 0300 EF = 00 26 03 EF 00 8000 EF = 02 26 80 EF 00 C000 FF = 80 26 C0 FF 00 F800 FF = C0 26 F8 FF 00 FC00 8E = F8 26 FC 8E 00 FC05 8D = FC 16 05 8D 00 FCEE EE = 05 16 CC EE 00 0200 EF = CC 35 02 EF 00 (same length as others now...) 0000 AA = 00 23 00 AA 00 Now I'll try some writes: Write @ Location Data (results) 0000 55 = 00 03 55 00 0100 AA = 55 25 01 AA 00 0200 AA = CC 23 02 AA 00 8000 44 = CC 23 80 44 00 EF08 11 = 0C 33 EF 08 11 00 (longer) Well, that's all for tonight, I'm getting tired... John :-#()#
Read @ Location Data Softla results (Start byte, command byte, high address, low address, data read, Stop)
0208 FF = 00 35 02 08 FF 00 0505 EF = 99 35 05 05 EF 00 1050 FF = 13 35 10 50 FF 00 FE55 31 = 00 35 FE 55 31 00 Got it! the first data byte seems to grab the pods attention, often a 00, but perhaps (?) not that important, but it certainly looks like a Clean (no other read action in front) Read is "35" then the address and the resulting data. It appears that multiple reads change the communication with the pod in the sense that if you take two reads (different locations) in a row the command string is different. Stay tuned this evening when I dig into more reads and test the writes. John :-#)#
0000 AA = 00 23 00 AA 00 (result) 0101 FE = 00 21 00 FE 00 0200 EF = 01 35 02 00 EF 00(result - a little longer this time...) 0300 EF = 00 26 03 EF 00 8000 EF = 02 26 80 EF 00 C000 FF = 80 26 C0 FF 00 F800 FF = C0 26 F8 FF 00 FC00 8E = F8 26 FC 8E 00 FC05 8D = FC 16 05 8D 00 FCEE EE = 05 16 CC EE 00 0200 EF = CC 35 02 EF 00 (same length as others now...) 0000 AA = 00 23 00 AA 00
Now I'll try some writes: Write @ Location Data (results) 0000 55 = 00 03 55 00 0100 AA = 55 25 01 AA 00 0200 AA = CC 23 02 AA 00 8000 44 = CC 23 80 44 00 EF08 11 = 0C 33 EF 08 11 00 (longer)
Well, that's all for tonight, I'm getting tired...
John :-#()#
I just got hold of one of these compact logic analysers (thats a joke - it's massive!) - does anyone have any information / manuals etc for it cheers p.s. by the time I get it working john would have sorted all the pod communication stuff!
More results: Great, when you do a First READ on the pod, you get a RESET to the pod, and a bunch of chatter: READ FE55 = 31: 30 35 REAL LONG PAUSE ... RESET AB 36 38 30 32 20 20 PAUSE FOR (about) TWO CYCLES(2P) 24 01 00 00 00 00 00 00 FF FF (P) (P) (P) 00 00 00 00 (P) FF FF FF FE (P) 00 00 08 00 30 (P) 4D 52 20 20 20 20 P P P P 48 41 4C 54 20 20 P P P 0E 00 06 30 00 LONG PAUSE HERE.....PERHAPS 10 TIME UNITS THEN 30 35 55 31 00 Now I'll try to do some more reads...This is exactly the order as entered... Read @ Location Data Softla results (Start byte, command byte, high address, low address, data read, Stop) N MP MP MP MP MP ( N means no handshaking, M is MAINSTAT & P is PODSTAT) 4567 FF = 5A 35 45 67 FF 00 89AB FF = 53 35 89 AB FF 00 0001 00 = AB 35 00 01 00 00 Write @ Loc. Data N MP MP MP MP 0101 AA = 01 23 01 AA 00 MP 2055 56 = AA 33 20 55 56 00 0101 43 = 56 33 01 01 43 00 Read... N MP MP MP MP MP 2055 FF = 43 35 20 55 FF 00 F808 FF = 55 35 F8 08 FF 00 F9AB FF = 08 35 F9 AB FF 00 FDEA FC = AB 35 FD EA FC 00 I think I now see the pattern for reads/writes. The first byte is the LAST DATA, note that the timing for that is such that MAINSTAT and PODSTAT have done nothing until the second byte. I suspect the 1st data byte is there for the REPEAT function...so lets try that... Repeat... N MP MP MP FDEA FC = EA 05 FC 00 Repeat... FDEA FC = 05 05 FC 00 Repeat... FDEA FC = 05 05 FC 00 OK, for REPEAT the first Byte (again before M or Podstat) is 1st the last data,then the last instruction. Now lets try a write again... Write... N MP MP MP MP MP 0123 45 = 05 33 01 23 45 00 0123 66 = 45 03 66 00 (much shorter for a second write to the same address!) Thus 03 is "Same Address Write" Read... N MP MP MP MP 0124 00 = 66 15 24 00 00 (hmmm looks like "15" is read increment(?) to next byte. let's test... 0125 00 = 24 15 25 00 00 (now lets skip a few...) 012F 00 = 25 15 2F 00 00 (and a few more...) 0138 00 = 2F 15 38 00 00 (lets shift up a little ways...) 0238 FF = 38 25 02 FF 00 (interesting...seems to latch the 38, ok, lets change both a bit) 0339 EF = 02 35 03 39 EF 00 (OK, it caught that, "35" might mean "new address read") I think the pattern that is coming out is something close to this X3 = write, X5 = read, if X = 0 then same address, if X = 1, then same address high byte, if X = 2 then latch low address byte, if X = 3 new address bytes. Yes, this looks right so far... TIMING The very first byte is BEFORE you get any handshaking...then you get MAINSTAT, then shortly after you get PODSTAT which ends just after MAINSTAT ends, then the remaining handshaking has POD end with MAIN. Boy I wish this had time marks... John :-#)# ...:56 AM 05/03/2002 -0800, John Robertson wrote:
Read @ Location Data Softla results (Start byte, command byte, high address, low address, data read, Stop)
0208 FF = 00 35 02 08 FF 00 0505 EF = 99 35 05 05 EF 00 1050 FF = 13 35 10 50 FF 00 FE55 31 = 00 35 FE 55 31 00
Got it! the first data byte seems to grab the pods attention, often a 00, but perhaps (?) not that important, but it certainly looks like a Clean (no other read action in front) Read is "35" then the address and the resulting data. It appears that multiple reads change the communication with the pod in the sense that if you take two reads (different locations) in a row the command string is different. Stay tuned this evening when I dig into more reads and test the writes.
John :-#)#
0000 AA = 00 23 00 AA 00 (result) 0101 FE = 00 21 00 FE 00 0200 EF = 01 35 02 00 EF 00(result - a little longer this time...) 0300 EF = 00 26 03 EF 00 8000 EF = 02 26 80 EF 00 C000 FF = 80 26 C0 FF 00 F800 FF = C0 26 F8 FF 00 FC00 8E = F8 26 FC 8E 00 FC05 8D = FC 16 05 8D 00 FCEE EE = 05 16 CC EE 00 0200 EF = CC 35 02 EF 00 (same length as others now...) 0000 AA = 00 23 00 AA 00
Now I'll try some writes: Write @ Location Data (results) 0000 55 = 00 03 55 00 0100 AA = 55 25 01 AA 00 0200 AA = CC 23 02 AA 00 8000 44 = CC 23 80 44 00 EF08 11 = 0C 33 EF 08 11 00 (longer)
Well, that's all for tonight, I'm getting tired...
John :-#()#
Thanks to John for posting those other Troubleshooters (you have all I have....), in the 1983 16 page one it discusses the Quick Tes (page 5). It sounds as if the quick RAM test is simply a loading of a RAM TEST program into ram space that is then run from there, rather than interaction between the Fluke & UUT? So does that mean the QT version is just a different ROM? Kev
No, it is not simply loading a binary code onto the game board, you CALL the Quick Test by using the code 3xxxxxxxx yy, where the "3" (or is it "2" ?) defines the QT call, and then you define if it is a QT RAM or QT ROM of QT I/O (I think I/O). This is well covered in the 68000 manual. The Galaga script in the Fluke Scripts archive has the command "include Z80.POD", which has some setup code for the Z80QT pod (as far as I can tell), but the script will NOT work with either the Z80 or the Z80A/A (faster) pods. You have to change the script to do the correct RAM area on Galaga. I will let mine out as it is still work-in-progress in the next few days... Note in the Galaga script the call for a ROM CHECKSUM (looks like it is only 2 digits) as well as a more thorough RAM test if the QT RQM fails. Nice script! I mucked it around to handle Pac-Man, Ms and Clones with a simple menu John :-#)# At 01:26 PM 26/02/2002 -0500, Kev wrote:
Thanks to John for posting those other Troubleshooters (you have all I have....), in the 1983 16 page one it discusses the Quick Tes (page 5).
It sounds as if the quick RAM test is simply a loading of a RAM TEST program into ram space that is then run from there, rather than interaction between the Fluke & UUT?
So does that mean the QT version is just a different ROM?
Kev
participants (6)
-
John Robertson -
John Robertson -
Kev -
Mark Shostak -
Mike Coates -
Phillip Eaton