• Please review our updated Terms and Rules here

Killer POKE

JonB

JonB

Veteran Member
Joined
Jan 26, 2014
Messages
1,652
Location
South Herefordshire, UK
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
 
JonB said:
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
Click to expand...

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.
 
It doesn't do anything on my 2001N-32. It does absolutely nothing, and I don't know why.
 
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.
 
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.
 
JonB said:
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..
Click to expand...

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
 
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.
 
@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.
 
Last edited:
Test "killer" poke speed - a little proggie

Test "killer" poke speed - a little proggie

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..?

Code: 
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:

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

What are your results?
 
Last edited:
It woulda ran just fine like that :D

A little tricky to enter it that way though.
 
I apologise for just now getting round to this, but here's the pudding:
IMAG0936.jpg
And, I corrected one small issue with your program:
IMAG0937.jpg
 
JonB said:
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..?
Click to expand...

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.
 
I almost forgot, and this is important: What does location 59468 contain upon cold reset? On mine, it's 30.

Nice round numbers:
IMAG0944.jpg
 
Last edited:
You must log in or register to reply here.
Back
Top