• Please review our updated Terms and Rules here

Pettester versions and manuals?

SiriusHardware

Veteran Member
Joined
Feb 15, 2014
Messages
815
Location
UK
Probably a question for Daver2, whose fine work this test firmware is.

I'm involved in a PET thread on another forum, the owner has a Tynemouth Software ROM / RAM gizmo sourced from TFW8B. It looks like the Gizmo has some version of Pettester available as an option but its behaviour on the second test (page 0 / page 1 RAM) is not as described in the manual for Pettester V4, where a no-fault condition should (I think) show 256 * G , 256 dots, 256 * G, 256 dots. Instead the screen is filled with 'G'. Is there an archive of manuals for the earlier versions of Pettester? (if there is a V4, it follows that there must have been three earlier versions).
 
It could also be Eudi’s original (none CRTC) or dave_m’s ‘hacked’ version for the CRTC - as opposed to mine if course.

Yes, my code and manuals are still on my google drive. Happy to send you a link, but it will have to be in the evening as I am just off to work now.

If it is my code, I will tell you a simple way to find out if you can dump the content. Within the first few bytes of the code should be an ASCII ‘V’ followed by a byte indicating the version number. At the end of the code should be my name (also in ASCII). You can look at the latest V4 source code for the exact structure if you wish.

Dave
 
Unfortunately the machine and myself are more than 150 miles apart, so I can't physically examine what's in the Gizmo myself. The owner did have an Eprom with your V4 test code in it which was a great help during diagnosis of the original swathe of faults on the machine. It has since worked for quite a while before now developing a new fault with the RAM (or RAM support circuitry) and unfortunately he now isn't able to find the test EPROM. I may just have to make him another one and send it over to him (he doesn't have a device programmer).
 
>>> Unfortunately the machine and myself are more than 150 miles apart.

Remote fixing - but still closer than the two sides of the pond...

Version 1 - https://drive.google.com/drive/folders/1wn0ecWjNXjtsC_zbszVoQaRllrvCY279?usp=sharing.
Version 2 - https://drive.google.com/drive/folders/1Dm6njIq7SXCHIls5lr-MvDt46mDApLt4?usp=sharing.
Version 3 (Beta) - https://drive.google.com/drive/folders/1WzFTMV9-w29-FlxsheKB9NAY2XYqNUR6?usp=sharing.
Version 4 - https://drive.google.com/drive/folders/1fyLbr1kcG98a2FDOMo1H5pj9lIdJpHcx?usp=sharing.

Versions 1 and 2 don't have any documentation I am afraid. But the (commented) source code and listing files are available.

Dave
 
Only just made it back here, busy evening, thanks for posting those links which I will try to get to tomorrow. The documentation for V4 (the only one I have seen so far) is excellent by the way, too often - and I have been guilty of this myself - people write utilities but then don't document them very well, but your doc for V4 of Pettester is really good.

Thanks for providing the firmware, it's one of the best tools to have for a nearly working machine, (one which can run code as long as the code does not try to use RAM).
 
My "mantra" is that the job's done when the paperwork is complete and the mess has all been tidied up!

In my business I see too many 'starters' and not a lot of 'finishers'. I like to finish job's off properly.

>>> Thanks for providing the firmware.

Not a problem. It was nice to write some 6502 code again after such a long time.

Dave
 
I think in this case the test routine is cycling between the VDU system test and the page 0 / page 1 test, but the page 0 / page 1 test is showing a screen full of 'B' with the real RAM enabled and a screen full of 'G' with the RAM/ROM gadget's onboard RAM selected. I think it's just not the latest version, or certainly not the latest version of Daver2's code. I am unavoidably sidetracked over the Easter period but beyond then I think I will just send the gent another Pettester V4 EPROM because we know where we are with that version, for which, as I mentioned, there is a well written manual.
 
That version sounds like Eudi's original code and not mine.

Yep. In defense of the original version's limitations, it was actually the first piece of 6502 assembly I ever wrote, and I did it with the hard assumption that every speck of RAM in the machine was bad so the only working space available was the three 8-bit registers. ;)

(Basically it's a slightly more feature-ful substitute for a NOP generator. But... hey, a screen full of B's on the memory cycle certainly tells you something, IE, almost any more elaborate 6502 code isn't going to work because your zero page and stack are DOA.)
 
(Basically it's a slightly more feature-ful substitute for a NOP generator. But... hey, a screen full of B's on the memory cycle certainly tells you something, IE, almost any more elaborate 6502 code isn't going to work because your zero page and stack are DOA.)

Does this mean that Daver2's V4 code won't work on the machine Sirius is helping to investigate as it displays a screen full Bs?

Alan
 
Last edited:
My recollection is that Daver2’s code at some point in its loop tests the zero page memory and if it’s good can move on to its more sophisticated functions? Assuming the zero page memory really is bad then you’ll be limited to whatever it can do without RAM, which may not be much more than mine.

The test loop mine executes exercises the address bus (and data lines) of the machine doing what it does so running it while poking around with a logic probe or oscilloscope is really its primary purpose. If you’re getting solid “B”’s you either have very bad RAM chips or the support logic is blown up. What model PET is this?
 
My PETTESTER code makes the same initial assumption in that the RAM is bad until proven otherwise.

Once pages 0 and 1 of memory have been demonstrated to be good, I can use them to run more comprehensive tests.

So, yes, you can use my code on a machine full of B's to start with...

If in doubt, read the manual!

Dave
 
AJ (Alan) is familiar with the machine I'm talking about, having been heavily involved in the epic battle to get it going originally. At the final count something like a quarter of all of the logic ICs had failed, along with the video RAM. but amazingly, the main system RAM was OK the whole time.

...And now it has developed a RAM fault. :)
 
Last edited:
The machine I wrote the first version of PETTESTER for had all kinds of stuff wrong with it, but ironically most of it wasn’t dead ICs. The real fun was rotted out traces; it was actually a miracle the test ROM worked because the ROM sockets down the line from the F000 position had a broken address line…
 
Some machines just keep on giving!

Sometimes the only way is to write some noddy code in an EPROM.

One of my (first) Z80 tests on a NASCOM 2 is an EPROM filled with 0x76 (HALT) instructions. When you turn the power on - the HALT LED should illuminate...

Dave
 
My PET has static RAM and my understanding of the way in which dynamic RAM PETs work is sketchy to say the least so please forgive me if I ask a couple of dumb questions. If the testers we've been discussing indicate a problem with pages 0 and 1 of memory doesn't this point to a problem with a particular RAM chip (or supporting logic chip)? If not, why not or are we really looking at multiple RAM chip failure?

Alan
 
My "mantra" is that the job's done when the paperwork is complete and the mess has all been tidied up!

In my business I see too many 'starters' and not a lot of 'finishers'. I like to finish job's off properly.



Dave

I agree with this entirely.

It is one thing to do a job, or a repair, for oneself and make it work to your own satisfaction. It is a completely different thing to document it well enough so that it has any chance of helping others. In other words as Dave says, finish the job properly.

I have seen a lot of "solutions" for either repairs, diagnostics, or projects published on the net, be it on Github, or You-tube & elsewhere, but often the associated documentation is so poor that you would need a crystal ball to make any use of it.

It may well be that the designer, or programmer, did actually know what they were doing, but if they did, that is no help in conveying the information to another party without the extra effort.

This is why I like Daver2's Pettester, because it has a proper manual, that is detailed enough to make sense of it.

I have seen other good examples of this before. One would be Martin Eberhard's ME5204 vintage ROM programmer. Not only is the hardware and the firmware properly documented, but the support manual is extensive & accurate.

These sorts of solutions such as Daver2 and Martin provide exhibit the qualities of true leaders in the field. A professional approach, being able to convey ideas to others and explain them in a way that can be understood, even by a beginner.

One thing that it pays to remember is, if you read some technical description and it doesn't seem to make any sense, it is likely that the person who wrote it didn't fully understand the problem.

Also you can have some description with information that is plausible and makes sense, but if there is missing information, you only get a part of the story.

A good example of this is the Wikipedia page on the supposed solutions to the Tic Tac Toe game. What is there is basically ok, but the problem is, the information that is "not there". They do not differentiate between the player who starts first and the one who starts second, which completely changes the required solution algorithm if a machine was set up to play a human and the game alternately started with the human or machine starting first, as it must do, to be fair, because the starting player has a significant advantage. They refer just to the "player" in the suggested game rules. So it all looks simple, until you delve in a little deeper and find out it is more complicated.
 
Last edited:
Back
Top