William Levak wrote: > > Well, here are two perfect examples of the misinformation I have > mentioned. > > On Tue, 20 Apr 1999, Todd S Elliott wrote: > > > Please read Jim Butterfield's reply below to this thread. > > > Sorry to disagree. To recap the tech aspect: in early PET/CBM machines, > > > > Basic waited until "retrace time" before writing to the screen, so that > > there would not be a screen-snow problem. It did this by watching the > > retrace bit in the VIA chip (bit 5 at address $E840/59424). On earlier ... > > Commodore changed the design so that this could cause failure; after the > > design change, there were two TTL-level devices connected to each other, > > both trying to output different levels. There were indeed failures, and > > early users who rejoiced in the speedup now found that they were > > endangering their machines. > He probably means bit 6 at 59408. At any rate, that is the circuit that > was changed. This line was shared with the EOI line of the IEEE Sorry to disagree with you here. Have you had a look at what Jim is talking about? He is talking about VIA PB5, the "sync in" input. This pin is normally used as input and connected to the PIA#1, CB1 to generate the system interrupt. In earlier PETs (pre-CRTC) this signal came from the "master timing" electronics, where it was produced by a 74LS08 (C6 in the 2001 schematics on funet). This signal is also used in IC E9 (input to 74LS20) to blank the video signal on off-screen times. The signal itself, as I can see is not fed to the (analog) video (CRT i.e.) electronics. In normal operation C6 produces the signal that is 5v for screen active and 0v for off-screen. Now guess what this routine in the Basic 2 kernal (from a 3032) does (trace $ffd2 to output a blank character for example): .C:e6ea A8 TAY .C:e6eb AD 40 E8 LDA $E840 .C:e6ee 29 20 AND #$20 .C:e6f0 D0 F9 BNE $E6EB .C:e6f2 98 TYA .C:e6f3 A4 C6 LDY $C6 .C:e6f5 91 C4 STA ($C4),Y .C:e6f7 60 RTS This routine waits until the video is off-screen by waiting until VIA PB5 goes low. The "speed" poke now is to set PB5 to a low output. This way the kernal routine always thinks it is off-screen and never waits - boom, speedup! However already in this case we have an unhealthy situation: The 74LS08 drives the line high and low according to the timing, but the VIA always pulls the line low. Obviously the 74LS08 wins, because otherwise the screen would be blank anyway (due to E9), but probably only because a TTL input recognizes even 2.4V only as a logic 1. Now the upgrade to the CRTC PETs. A CRTC does not produce the video on signal - it is not needed: either there is VSYNC for the vertical flyback or there is DE (Display Enable) that also changes during horizontal flybacks. Now the newer PETs have the VIA PB5 and the PIA#1 CB1 connected to the VDRIVE (basically the VSYNC) signal, that toggles only once a frame (for the interrupt). So far so good. The problem is that in the "early model 8032" schematic on funet the VDRIVE signal is _directly_ fed into some _analog_ circuitry that directly handles 12V. In normal operation this is not a problem, because the signal arrives at the specs, with around 5V and 0V levels. Now consider the speed poke applied: The VIA always pulls the line low, reducing the voltage of the high level (which is the onscreen time here, not the flyback). I have not analyzed the analog circuitry, but I would not by default rule out that a video flyback electronics that is set to flyback for more than the few ms a frame can never go haywire. In newer PETs CBM has probably added a TTL receiver (probably even a Schmitt Trigger as I would) before the analog circuitry, which would prevent this situation, but I cannot confirm this because I have not found a newer PET CRT schematics on funet. I have no confirmed PET death as well, but _I_ think it's possible, so believe whatever you like :-) > any way. The remaining EOI remains as it was before except for being > disconnected from the display circuitry. Indeed. The EOI line used to blank the screen on the first PET boards (which gives an annoying flicker in the VICE emulator due to the many screen refreshs). This was done during scroll operations for example. > The TTL devices "trying to output different levels" simply do not exist. > Anyone can see this for themselves. The schematics are available at > http://www.funet.fi/pub/cbm/schematics/computers/pet/index.html So I did. > Well, Commodore did design that computer that could not be damaged by > software, but some people prefer to beleive otherwise, even when the > described faults bear no resemblence to the actual circuitry involved. Did you actually try setting VIA PB5 to low output? (I mean, I won't do it on my PET, but you said it will not damage your computer ;-) Andre -- Email address may be invalid. Use "fachat AT physik DOT tu-chemnitz DOT de" ------Fight SPAM - join CAUCE http://www.cauce.org------Thanks, spammers... Andre Fachat, Institute of physics, Technische Universität Chemnitz, FRG http://www.tu-chemnitz.de/~fachat - This message was sent through the cbm-hackers mailing list. To unsubscribe: echo unsubscribe | mail cbm-hackers-request@dot.tcm.hut.fi.
Archive generated by hypermail 2.1.1.