• Please review our updated Terms and Rules here

CBM PET 3032 STRANGE BOOT

daver2 said:
Hugo,

To answer your questions.

1. Nivag's board just maps ROM and/or RAM either external (using the PETs) or internal. There is a data bus buffer involved (or similar) so the PETs data bus is isolated from the internal bus. The (previously working) test was with internal ROM and RAM. Flipping the RAM link over causes PET RAM to be used instead of internal.

2. The PETTESTERs DRAM test is a slightly modified MARCH-C memory test. By slightly modified I have added two tests. One to clear memory to all $00 and validate this. The other to preset memory to all $FF and to validate this. Technically, these tests are performed by the MARCH-C tests anyhow. The MARCH-C memory tests are a recognised high coverage test for dynamic RAM devices. The only thing that I am planning to add to these tests in Version 5 is an inherent 'delay' between the $00 and $FF writing and validating steps to ensure the DRAM refresh circuitry is performing it's job.

However, there is a slight 'niggle' with my MARCH-C test. It uses both page 0 RAM and the stack (page 1 RAM) and relies on this working... I have a (too simple) memory test for pages 0 and 1 of the RAM before I use them in anger. I have found that some marginal RAM failures can pass the simple tests but cause the full memory test to crash (or malfunction). This malfunctioning has already been observed on Desperado's PET (it was reporting address $01FF in error - but it never tests this address!).

I have found a more comprehensive (but simple) memory test that I can use for my pages 0 and 1 testing in Version 5.

Dave
Click to expand...

Yes, it is quite a different system.

Mine relies on dynamically deactivating the lower 1k or 2k (selectible) of DRAM and simultaneously activating a substitute SRAM to support BASIC, leaving the PET's CPU running normally and BASIC functioning. The firmware in my ROM, which is block moved into the functioning SRAM area, writes a checkerboard pattern and a reverse checkerboard pattern or any other chosen byte value, to test the DRAM, the latter can be useful tracking down defective DRAM.

Because of the delay it takes to do this, fill the memory (even with a machine language program), and then visually inspect the memory with the TIM, it also allows the refresh system (data retention) to be checked by default.

I did it this way because I stumbled across a vintage computer article with a program for DRAM checking, where there was a concern by the designers about a value in a memory cell changing, when an adjacent cell was written to, hence the reverse checkerboard pattern being needed. Though, they did not offer a scientific explanation as to how that could happen inside the IC, but it seemed plausible. So I thought I'd better pay attention to it. If there is one thing I have learnt about DRAM IC's, they are very complex devices and have a number of interesting failure modes and they rely on a lot of extra support circuitry that SRAM does not require.
 
Maybe i found the culprit for dram test stuck... Some time ago i had repaired this jumper that had open ed... The solder came off... Now i have repaired and dram test seems to be fine!
 

Attachments

  • 1679745856589..jpg
    1679745856589..jpg
    1.5 MB · Views: 7
  • 1679745873399..jpg
    1679745873399..jpg
    1.1 MB · Views: 6
Ok, so get some 20 (or so) successfull memory passes. That will give the DRAM a 'clean bill of health' and also (at the same time) make sure that your video glitches are not returning.

The more testing the machine gets, the more we will be convinced that the video issue has gone away...

After that, we can revert back to the PETTESTER and BASIC ROMs in the PET, and then (after that) swap the PETTESTER ROM back to the EDIT ROM.

Dave
 
Last edited:
Hugo,

My PETTESTER was written so that the only hardware that would be required would be a 2K EPROM to be swapped for a device that is guaranteed to be socketed in a PET. No more hardware was required. This means that a minimal amount of the PET logic needs to be operational (as described in my manual).

There are many more types of DRAM faults that can occur, some of them quite obscure. These are all documented (supported by a mathematical analysis) within the MARCH-C papers. I cross-reference to a document in either my PETTESTER user manual or source code. It might be worth a read?

Dave
 
Ok thanks! I don t understand because if i remove this jumper, dram test stucks!
 
Jumper C is a bery important jumper in the DRAM circuit.

Without jumper A or B or C made, one address line for the DRAM is not connected and, therefore, floating.

These jumpers select two types of 8K DRAM (jumpers A or B) or a 16K type of DRAM (jumper C).

Without jumper C, BA13 is not connected. The likely outcome from this will be 'carnage' as the DRAM will not be addressed correctly.

A further check (being added into Version 5) is a binary addressing test to also detect this behaviour... Although I am running out of space in a 2K EPROM!

If links are not correctly made, the PET will malfunction. Period...

Dave
 
Desperado,

When I got my Dynamic PET (32k), the jumpers had been hacked to pieces by a service person with the skills of Fred Flintstone.

So I removed them and fitted high quality Omron switches instead.

It pays to take a photo of them and put it in with your computer service manual, so the configuration is always there when you need it. So put this photo into your files.
 

Attachments

  • jumpers.jpg
    jumpers.jpg
    127.9 KB · Views: 7
When we get to it... We can test the PET ROMs by using the PETTESTER but we need to do some jumper moving to not test the substituted ROMs!

I will have to check but I think we also have the F800 version of PETTESTER so we can even test the E socket.

But I take it we are not there yet.

PS
Schematics for my board are linked from its Tindie page.
 
SSuper! After 24 dram passes, NO glitches and not freeze!! I love you all!!!
 
Ok,

So now you can do one of two things:

1. Remove Nivag's card and reinstall the CPU back in the socket. Install the PETTESTER ROM in UD8 and put the other PET ROMs back into the other ROM sockets (excluding the EDIT ROM of course, that is occupied by the PETTESTER ROM).

2. Reconfigure Nivag's card to run the PETTESTER internally and install all of the PET ROMs back into the PET machine (including the EDIT ROM).

The plan now is to make sure everything still runs OK and the ROM checksums are as expected and stable.

Dave
 
Not when we have got this bl**dy far!

Revert back to inserting Nivag's board and we will reconfigure the links.

The only thing we have now effectively done is to start using the PETs ROMs; so we backup to the last good step and retry that to make sure it works as it did last time (i.e. a lot of good PETTESTER passes) and then we move forwards from there...

Dave
 
You must log in or register to reply here.
Back
Top