Double Speed?

[zephyr]

Thanks!

[Alastair]

Does the warm-up change the behaviour of anyone else's Dragon in the same way?

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]

Does the warm-up change the behaviour of anyone else's Dragon in the same way?

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.

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.

[admin]

For those of you wondering why the speed of the CPU was limited you have
to remember that the design originated with Motorola back around 1979 or 1980.
Fast RAM was expensive at that time and the design was to be for a cheap
personal computer. Complex clock circuity, multiple clock sources,
and high clock speeds, all would have been expensive to implement at that time.

Early CoCos couldn't handle the high speed POKEs at all.
I was lucky that my CoCo 1 (Rev E board?) did.
I could only go a minute or so before the machine locked up with the RAM
refresh disabled. Since the Dragon came later, it's RAM can probably go for
longer periods without refresh.

Now, an easy solution would be to pull the DRAM from the
machine, insert the SAM into an intermediate circuit board that substitutes
SRAM instead. (SRAM adapters have been made for other systems).
CoCo 1's had the chips socketed. Most later machines didn't so easy would be
a relative term depending on your machine.

A free alternative is to run a timer routine that re-enables the RAM refresh periodically.

[sixxie]

The thing is though, the "high speed poke" that typically crashed old machines was the one to put it into address-dependent mode. Refresh still happens in that mode, and yet still old D32s (and CoCos it seems) crashed.

[sixxie]

Curio:

SAM data sheet says:

When using Map Type "TY = 1", only the "Slow" MPU rate may be used.

Followed by a note about later SAMs maybe supporting more.

Testing on my D64 in 64K BASIC mode (so TY = 1) AD mode does indeed not work, but FAST mode does. Simple test: EXEC into 64K BASIC then POKE 65497,0 and see the screen mess up.

How I found out? By writing hacky cheaty code that simply swapped map types assuming it would drop the CPU back into SLOW mode. All fine under emulation, but curiously lacking coherent video on a real Dragon - and I'd gone to all that effort making sure any data I manipulated while FAST was in the lower 32K too!

[zephyr]

I have noticed that the two Dragon 32's in my collection that run at double speed for long periods without problems have OKI RAM chips installed. One has 8 x OKI M3732L-20RS, and the other has 2 x OKI M3732L-15RS and 6 x OKI M3732H-20RS chips. Both Dragons seem to run very cool, and the one with 8 x OKI M3732L-20RS RAM chips will run at double (&HFFD9) speed for an unbelievable maximum time of around 20 minutes. According to technical specs, it shouldn't really be possible for a Dragon (or CoCo) to run a program for more than a couple of minutes at double speed because there's no RAM refresh.

[sixxie]

Hmm, some RAM chips required 12V supplies back then and some didn't - I wonder if that's the difference?

Looking at the schematics, the Siemens board has a constant -12V link, and the OKI looks selectable - depends on the type of chip used.

Would certainly change the power requirements, which could definitely have an effect on temperature.

[zephyr]

I have been doing some more testing at double speed...

I ran the following program for nine hours without any problems whatsoever. I changed the count in the for next loop from 100000 to 5661000 to set the program up for its nine hour marathon. It ran for exactly nine hours and exited from double speed with a final displayed time of 541.25 minutes. The machine seemed to run cool and does not seem any worse for wear after its nine hour marathon. The machine code part of this program modifies the timer to return the time in seconds.

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

I also ran this program for two hours without any errors being reported. I changed the test in line 50 from X<0 to X<114 to make it run the two hours testing time.

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"

Both of these test programs were run on a a very early issue Dragon 32 that normally crashes a few seconds after entering the &HFFD9 double speed mode. Interestingly, although these programs will run for hours without problems, if you add a lengthy PLAY or SOUND command to them, it always results in a crashed computer.

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?

[sixxie]

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?

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.

Just guessin'. Would need an oscilloscope or logic analyser to see for sure.