PDA

View Full Version : Killer POKE



JonB
July 16th, 2014, 05:10 AM
Hi all

I have just tried the KILLER POKE (POKE 59458,62) on my 3016 PET. It makes a huge difference to the performance of screen printing from BASIC and there is no snow whatsoever. Even when LISTing an entire program, I see no video artifacts.

Why would this be? If I'm writing to the screen RAM at the same time as it's being read by the video logic (or rather, altering it when not in the CRT's vertical retrace period), I would expect to see something..

The other question is, given that it's not a CRTC PET, is there any reason not to use it in my code?

Finally, what's the most commonly used technique for detecting a CRTC equipped PET? I'd like to put a safeguard round the KILLER POKE to prevent it being executed when running on a CRTC PET.

Incidentally, I read Andre Fachat's discussion of the killer poke but I didn't follow the finer points:

http://www.6502.org/users/andre/petindex/poke/index.html

Cheers

JonB

Roe
July 16th, 2014, 07:40 AM
Hi all

I have just tried the KILLER POKE (POKE 59458,62) on my 3016 PET. It makes a huge difference to the performance of screen printing from BASIC and there is no snow whatsoever. Even when LISTing an entire program, I see no video artifacts.

Why would this be? If I'm writing to the screen RAM at the same time as it's being read by the video logic (or rather, altering it when not in the CRT's vertical retrace period), I would expect to see something..


JonB

That's a very old trick for PET systems; I can't explain why there are no visual problems (snow, etc), but I used it way back when I was writing commercial software for CBM and PET systems. Back in the day, there were warnings that this could actually cause hardware problems, but I never had any difficulty.

KC9UDX
July 16th, 2014, 08:59 AM
It doesn't do anything on my 2001N-32. It does absolutely nothing, and I don't know why.

JonB
July 16th, 2014, 11:24 AM
Are you sure it's not got a CRTC chip inside?

If you read the link I posted, there's more detail about it. My PET is a 2001-N16 upgraded to 32k, so it should be the same as yours. I found the speed gain was really visible.

KC9UDX
July 16th, 2014, 11:56 AM
I'm positive there's no CRTC. Yes, it should be the same as yours.

I've tried several times, and not noticed any speed change or snow or flicker or anything. I don't remember enough about the memory map or the schematic; but someday I'll have get out the logic probe and see if there's a stuck bit.

dave_m
July 16th, 2014, 01:30 PM
I have just tried the KILLER POKE (POKE 59458,62) on my 3016 PET. It makes a huge difference to the performance of screen printing from BASIC and there is no snow whatsoever. Even when LISTing an entire program, I see no video artifacts.

Why would this be? If I'm writing to the screen RAM at the same time as it's being read by the video logic (or rather, altering it when not in the CRT's vertical retrace period), I would expect to see something..

Jon,
Only the first generation PETs had the snow problem. The newer boards had slightly faster RAM chips and could multiplex (share) the video RAM using the opposite phase of the 1 MHz clock. So there is no longer interference between CPU access to video RAM and RAM screen refresh.
-Dave

KC9UDX
July 16th, 2014, 08:15 PM
I took a video demonstrating the lack of change on my 2001N-32. I haven't any idea though how I could post that here.

I would be very interested to find out if someone could determine if mine runs as slow as one normally would if location 59458=30 or if mine runs as fast as one normally would if location 59458=62.

JonB
July 18th, 2014, 12:10 AM
@Dave: Thanks for that. It's nice to know I can speed my PET up without any nasty side effects. Actually, I saw a PET accelerator card on Andre Fachat's page that looked tasty. Hmmm, 10Mhz...

Anyway... What we need here is a test program so we can compare notes... I'll knock something up. Fill screen with characters a few times and time it. Execute KILLER POKE :D and rerun. Compare times. Something like that.

JonB
July 18th, 2014, 01:27 AM
OK, let's try this little program.

It fills a cleared screen with dots using a simple loop, issues the killer poke, then reruns the test and restores the register (turns killer poke off). Each test run is timed using the TI system variable, then it outputs results in seconds, %age time saved and how many times faster it is with the poke on. TI logs elapsed time in "jiffys" which as far as I can see are 1/60ths of a second.

Note: lines 35, 70 and 110 are printing CLEAR SCREEN, which is a single reverse "heart" character (RVS-SHIFT-S). I do this for each successive test run to be sure the number of times the screen must scroll are the same for each.

An interesting observation is that the first few lines of the initial screen fill appear to be slower than the subsequent lines. I wonder why..?



10 REM TEST THE KILLER POKE
15 REM *** DO NOT TRY ON CRTC PETS!! ***
20 OLD=PEEK(59458): REM STORE CURRENT VALUE
30 S=TI: REM STORE START TIME
35 PRINT "[RVS][HEART CHARACTER][RVS OFF]";: REM CLEAR SCREEN
37 FOR X=1 TO 1000: PRINT ".";: NEXT X
40 E1=TI-S: REM CALCULATE ELAPSED TIME IN JIFFYS
50 S=TI: REM STORE START TIME
60 POKE 59458,62: REM DO THE KILLER POKE
70 PRINT "[RVS][HEART CHARACTER][RVS OFF]";: REM CLEAR SCREEN
80 FOR X=1 TO 1000: PRINT ".";: NEXT X
90 E2=TI-S: REM CALCULATE ELAPSED TIME IN JIFFYS
100 POKE 59458,OLD: REM RESTORE THE REGISTER
110 PRINT "[RVS][HEART CHARACTER][RVS OFF]": REM CLEAR SCREEN
120 PRINT "SLOW :";E1/60;"S"
130 PRINT "FAST :";E2/60;"S"
140 PRINT "GAIN :";((E1-E2)/E1)*100;"%"
150 PRINT "APPROXIMATELY";INT(E1/E2);"FASTER"

Running this on my PET yields the following results:



SLOW : 10.3833333 S
FAST : 2.616666667 S
GAIN : 74.799558 %
APPROXIMATELY 3 TIMES FASTER

What are your results?

vwestlife
July 18th, 2014, 04:43 AM
Your program has two line 30s. :)

JonB
July 18th, 2014, 04:52 AM
Your program has two line 30s. :)

Well spotted; I have corrected it... "D'oh!"

KC9UDX
July 18th, 2014, 06:02 AM
It woulda ran just fine like that :D

A little tricky to enter it that way though.

KC9UDX
October 17th, 2014, 07:56 PM
I apologise for just now getting round to this, but here's the pudding:
21033
And, I corrected one small issue with your program:
21034

KC9UDX
October 17th, 2014, 07:59 PM
An interesting observation is that the first few lines of the initial screen fill appear to be slower than the subsequent lines. I wonder why..?

It probably isn't in this case, but the first thing I always suspect is garbage collection. That may be way off base though, from what I've been finding. I'm used to the C64, where garbage collection happens at the worst times and is very very noticeable. So far from what I find, the PET may not actually have this issue, at least not in BASIC 4.0.

KC9UDX
October 17th, 2014, 08:03 PM
I almost forgot, and this is important: What does location 59468 contain upon cold reset? On mine, it's 30.

Nice round numbers:
21035

fachat
November 5th, 2014, 02:35 AM
I think the first 3016 with small screens (9") were not susceptible. Only when the large screen (12") models came out - I _think_.

http://www.6502.org/users/andre/petindex/poke/index.html

André