daver2
10k Member
This is the problem with the complexity of the code within the 'full' set of Commodore BASIC ROMs...
Dave
Dave
Good observation, I guess the PC got sent there (vectored away as Daver2 described it). To get there though it could mean that the program code in the BASIC firmware is intermittently corrupting due to bad ROM's Or the firmware is ok, and something in the hardware corrupted the acquisition of the program code by the CPU, such as something interfering with the data bus, or improper ROM selection, sending the PC to low RAM memory where it acquired 00 there. Could there be defective DRAM in the stack area I wonder.Hugo, the CPU was incorrectly executing in low RAM when it got the break instruction. In Message # 773 the M/L Monitor output shows the Program Counter at address $02C3. The other registers including the Stack Pointer seem OK. That area of RAM holds system parameters and probably has a lot of zeros.
But as to why it was executing in RAM??
-dave_m
Maybe bad ram buffers sir Holden???I'm not familiar with the Pettester program enough to interpret what this means. Daver2 , Dave_m & Nivag would know. It might mean there is faulty DRAM or not, or possibly another fault that stopped the program executing.
As I mentioned, we don't know 100% for sure that this is the same fault that causes BASIC to fail and the PC to vector to low RAM. If it was bad DRAM in the stack area in the case of BASIC failing, in theory that should not cause the Pettester to lock up, unless the program code in the pettester used the stack and relied on that part of DRAM working, but that would be unlikely, when its task is to check the entire DRAM for defects.
I assume that the Romulan-Ramulator works by only using the RAM it carries itself and not any of the PET's DRAM to run its code ? If that is the case it does seem to be the ideal tool to find his fault and I agree with 3. But from what Daver2 said Eudi's UD9 tester should work.In short there seem to be three possible options in terms of eliminating DRAMs and ROMs from the equation:
1. Hugo's blanket ROM and RAM replacement approach with the desoldering/soldering risks assocociated with socketing RAM chips.
2. Dave's methodical approach which might not succeed because of the apparent number of variables involved.
3. Buy a ROMulan RAMulator as discussed several times earlier in the thread.
As a very satisfied user of the ROMulan RAMulator, option three is my favourite. It has the advantage of being capable of helping with future PETs as well.
Alan
I was wondering, even with a Romulating Ramulator, what if the CPU received an IRQ, say from the keyboard or I/O device elsewhere, perhaps malfunctioning, and saved the existing PC address in DRAM, later when it returned from the interrupt service routine, it could malfunction if the DRAM data storing the address was defective, sending the PC to no man's land ? Can the Romulan Ramulator prevent an event like that ? I guess it could if it disabled the IRQ which I guess it would, but if it did, wouldn't that disable the keyboard ?Yes the board has its own selectable (or not) RAM and user configurable ROM images. Dave's PETTester V4 and VOSSI utilities are built-in. There are a couple of similar boards available elsewhere but I've no experience of using them. Cost and availability are also factors to be considered of course.
Alan
Maybe time to change every ram ics???Yes - if you map the RAM and/or ROM internally.
The IRQ vector is stored in the top of the Kernel ROM ($Fxxx) along with the NMI and RESET vectors. A 'misbehaving' Kernel ROM could cause a random crash if the vector become corrupt. Map the Kernal ROM internally and the problem should go away.
Likewise for any return address stored on the hardware stack (in the range $0100 to $01FF). If page 0 ($0000 to $00FF) and page 1 - hardware stack - ($0100 to $01FF) is mapped internally, this should also be avoided.
Dave
Can i change ram buffers???It won't fix your problem...
Eudi's PETTESTER ROM won't run in UD9 - that tells me there is a high priority that the DRAM has nothing to do with your problem (unless there is some other interaction via the power rails or some other mechanism that I haven't thought about.
Dave
I think it is worth as we mentioned before , re-checking all the power supply rails on the scope for noise, not just for DC level on the meter.It won't fix your problem...
Eudi's PETTESTER ROM won't run in UD9 - that tells me there is a high priority that the DRAM has nothing to do with your problem (unless there is some other interaction via the power rails or some other mechanism that I haven't thought about.
Dave
I'm not sure about this, I guess anything is possible, but the buffer IC's are probably, on average, more reliable than the actual DRAM IC's. Though it would not hurt to scope the signals around them and make sure there are no anomalous logic levels especially on the R/W control lines.Maybe bad ram buffers sir Holden???
Ok thank you very much HugoDave_c78, don't un-solder any of the 4116 DRAM's yet. I am working on an idea to try to determine definitely, one way or the other, if the page 0 and page 1 memory locations looked after by the DRAM are defective, or not.
It just might take a day or three to see if the idea works.
It may take me a while, with the test I was thinking of.Ok thank you very much Hugo