Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!rutgers!cbmvax!cbmehq!cbmger!peterk From: peterk@cbmger.UUCP (Peter Kittel GERMANY) Newsgroups: comp.sys.amiga Subject: Re: Z machine et al Message-ID: <686@cbmger.UUCP> Date: 7 Jan 91 14:14:41 GMT References: <1029.2772FECD@weyr.FIDONET.ORG> <1990Dec23.084244.17796@ncsuvx.ncsu.edu> <1990Dec28.001940.25138@zorch.SF-Bay.ORG> Reply-To: peterk@cbmger.UUCP (Peter Kittel GERMANY) Organization: Commodore Bueromaschinen GmbH, West Germany Lines: 28 In article vinsci@nic.funet.fi (Leonard Norrgard) writes: > >Well, you could flip a bit and get a sudden speed increase, an order >of magnitude or so. Too bad they didn't flip that bit at the factory. >If you followed the output vector ($ffe4?) you could notice how it >busywaited for the CRT to finnish drawing the current frame before >updating screen RAM, just to avoid some very minor flicker near the >screen position updated. Hmm, are we talking PET 2001 or later models? For the 2001, you're sure right. But in the later 8032 (I think it was called Super PET in US), it was not necessary to wait for screen finish because the video RAM access was interleaved between CPU and 6545 CRT controller. (Each one had one half of the Phi2 phase, so it was 1000 ns cycles effective access, compare that to 500 or so ns stated by Dave for the A3000 :-) But I can't swear that they really took advantage of this in the ROM. Hmm, but when I look at that old demo (I can still run it here!), I think they did. Yes, back on the 2001 you only got it to flicker was with POKing to the screen memory, nearly not by PRINT (well, NEARLY: when you made a close loop printing and deleting the character at the home position, it also looked like bad flicker). I should state that I was not a system programmer in those days, just a (satisfied!) user. -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk