Re: Double Speed?
Posted: Fri Dec 26, 2008 10:05 pm
Thanks!
The Dragon Archive Forums
http://archive.worldofdragon.org/phpBB3/
http://archive.worldofdragon.org/phpBB3/viewtopic.php?f=5&t=42
I haven't had time to test your programs, but my D32 dislikes the double speed poke. It will run for a short while before crashing but I never timed it, nor did I work out if the crashing is time or temperature related.zephyr wrote:Does the warm-up change the behaviour of anyone else's Dragon in the same way?
I also have a D32 that behaves like this. It works perfectly at &HFFD7 and &HFFD9 until it gets to normal operating temp. When its been running for around 30 minutes or so, it crashes as soon as you press enter after typing in POKE65495,0.Alastair wrote:I haven't had time to test your programs, but my D32 dislikes the double speed poke. It will run for a short while before crashing but I never timed it, nor did I work out if the crashing is time or temperature related.zephyr wrote:Does the warm-up change the behaviour of anyone else's Dragon in the same way?
Followed by a note about later SAMs maybe supporting more.When using Map Type "TY = 1", only the "Slow" MPU rate may be used.
Code: Select all
10 FORI=&H380 TO &H39F:READA$:POKEI,VAL("&H"+A$):NEXT
20 POKE118,50:EXEC&H380
30 DATA 1A,50,30,8D,00,04,BF,01,0D,39,B6,FF,02,0A,76,26,0C,BE,01,12,30,01,BF,01,12,86,32,97,76,7E,AF,D9
40 POKE65495,0:POKE65497,0
50 CLS:TIMER=0:POKE118,50:FORI=1TO10000
60 PRINT"QWERTY"
70 NEXT:S=TIMER
80 POKE65496,0:POKE65494,0
90 PRINT"RUNNING TIME:";S/60
Code: Select all
10 PCLEAR5:S=PEEK(&HBC)*256
20 CLS:POKE65495,0:POKE65497,0
30 FORI=0TO6144:POKES+I,PEEK(&H8000+I):NEXT
40 FORI=0TO6144:IFPEEK(S+I)<>PEEK(&H8000+I)THEN POKE65496,0:POKE65494,0:PRINT"ERROR AT $";HEX$(S+I):END ELSE NEXT
50 IF X<0 THEN X=X+1:GOTO30
60 POKE65496,0:POKE65494,0
70 PRINT"NO ERRORS"
Well, to refresh you only need access each row on a RAM within the refresh time - in general, interpreting BASIC does access lots of sequential addresses, so that might just be enough. Sound commands will sit in ROM playing the sound for a while (possibly using a couple of addresses in zero page for counters), which might push it over the edge. There might be other commands that take long enough sitting in ROM to do the same, but can't think of one offhand.zephyr wrote: IMO these tests have proven without doubt, that despite what it says in the technical specs, RAM refresh must be happening in &HFFD9 double speed mode.
I wonder why the production of sound in double speed mode always crashes the computer?