So I've busted out the old scope that was given to me many years ago. I've never used a scope before, so with the help of MikeS I think I have it somewhat calibrated. I've posted some videos showing the working board (top) compared to the non-working board (bottom). Presently I have only tested C5 pin 5, C9 pin 8, 9 and 11. I've posted video's here again: http://web.me.com/lord_philip/other_computers/20012.html Phil On May 21, 2011, at 11:45 AM, Philip Lord wrote: > Ok...I looked at the archived list here: > http://www.softwolves.com/arkiv/cbm-hackers/15/date.html > ...and found the message I missed (very strange indeed). > > Here they are if others have also missed them: > > > I admit I have to speculate a bit. The schematics of the PET clearly remind me of what's going on inside the 6545 (see for example here http://www.6502.org/users/andre/hwinfo/crtc/internals/index.html > where I've analyzed the CRTC internals). I immediately recognized the 74100 as the feedback register ... the purpose of this register is to store the memory address of the first character in the line. > > While displaying a line, the video circuitry first loads this memory address into the registers D6/D7, which get incremented every cycle. When 40 characters are shown, the "DIS ON" (from C5 in the horizontal timing circuitry) signals goes off, but the counter still counts on. > > The counter is reloaded with the DIS ON signal. I.e. every time a new raster line starts, the memory address counter is loaded new from the 74100 latch. If the latch would not be reloaded, the screen would show a single line over and over. > > The characters are made by using the same memory address, but selecting different raster lines addresses in the character ROM A2. > > Only if the three raster line counters (output of A1, input into the A2 6540 charrom) are all ones (7 = last rasterline of a character), AND the DIS ON signal is on (not sure about the exact timing though) the buffer 74100 is loaded with the next address (triggered via the C7 NAND - shown as OR with inverted inputs) - the last character address in the current line + 1, which is the first address in the following character line. This is how lines are counted in memory. > > In the current problem we see the following: > - the character lines still show 40 characters > - For each line, the character address is advanced only 36 characters. So the 4 last characters of a line are (somewhat) repeated in the first 4 characters of the next line > - It seems the first character of each line is repeated > - This happens per character line, not per raster line > > So the memory map in screen coordinates would be: > > 0 0 1 2 3 4 5 6 .... 35 36 37 38 > 36 36 37 38 39 ... > 72 72 73 74 ... > > As I said this happens per character line, which is interesting, as the "mixup" of memory addresses must happen each raster line. > > Now I see that the 74100 and D6/D7 counters actually loads the _upper_ 8 bits of the 10 bits video memory address. The lower two bits are handled by the D5 dual-JK-flipflop and the following multiplexer at D2. > > Looking at the fact that the lower two bits show a strange behaviour in the memory map: > > 00 00 01 10 11 00 ... > 00 00 01 10 11 00 ... > > my assumption is there is a spike in the DIS.ON line within one cycle after it becomes active that clears the lower two address bits (so the "00" is repeated). This would also explain the 36 character line length. Due to the repeat of the first cycle, the last character of a line has an address of 38, the one after that (which is stored in the latch(!)) has 39, which is binary 0000100111. Of that the upper 8 bits are stored in the latch for the next line, and the lower two (in the D5 flipflops) are cleared (as they are always 0 at the start of the line for 40 chars/line). So after clearing the lowest two bits is 00100100 = 36 - the starting memory location for the next line! > > So the summary is: look for a spike in the DIS.ON signal. Maybe even try to suppress it (temporarly) with a small capacitor to ground to see if the problem goes away. > > Why it is there I don't know. The signal is being produced by C5, a 74LS107. > > Hope this helps > André > > ____ > > Excellent analysis! > > I'd also gotten to the point of suspecting the DIS ON signal that loads the > latches and especially D5 since it holds the two low bits, but it hadn't > occurred to me that the first character is at offset 39 instead of 40 and > that resetting D5 effectively subtracts 3; brilliant! > > I was also trying (unsuccessfully) to find some logical fault that would > create an extra pulse on DIS ON, but maybe it is just a spike as you > suggest. > > It would be nice to know for what diagnostic procedure the TPs are > intended... > > Time for Philip to get out his 'scope and look at C5 pin5 (and compare to > the good PET). > > m > > > > > > On May 21, 2011, at 8:31 AM, Philip Lord wrote: > >> Hi again, >> It seems that I've haven't gotten a couple of emails in this thread. They contain the messages: >> >> "Excellent analysis!" >> >> and >> >> "So the summary is: look for a spike in the DIS.ON signal. Maybe even try >> to suppress it (temporarly) with a small capacitor to ground to see if the >> problem goes away." >> >> Sorry, I'm not sure who these mails came from, but unfortunately I never received them and only know of their existence from the response from André. Can someone send please forward the missing mails. >> >> Thanks again >> >> Phil >> >> >> On May 21, 2011, at 7:09 AM, André Fachat wrote: >> >>> >>> >>>> Excellent analysis! >>> >>> Thanks, that was a tricky one. I missed the important point only until I realized that the 74100 actually does NOT store the lowest two bits because it handles the upper 8 bits and not the lowest 8 bits of the 10 bit video memory address. >>> >>> I only hope it helps. I'm looking forward to the 'scope analysis. >>> >>> André >>> >>> -- >>> NEU: FreePhone - kostenlos mobil telefonieren! >>> Jetzt informieren: http://www.gmx.net/de/go/freephone >>> >>> Message was sent through the cbm-hackers mailing list >> > > > Message was sent through the cbm-hackers mailing list Message was sent through the cbm-hackers mailing listReceived on 2011-05-22 08:00:27
Archive generated by hypermail 2.2.0.