Re: PET 2001 fix Part 3 - RAM/ROM board etc.

From: André Fachat <afachat_at_gmx.de>
Date: Thu, 19 May 2011 20:46:13 +0200
Message-ID: <20110519184613.105880@gmx.net>
> If a line ends with ...ABCDEF, then the next line continues with DDEFGH...
> instead of GHIJ...

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é

References are from:
http://www.zimmers.net/anonftp/pub/cbm/schematics/computers/pet/2001/320008-3.gif



-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

       Message was sent through the cbm-hackers mailing list
Received on 2011-05-19 19:00:11

Archive generated by hypermail 2.2.0.