Double Speed?

[zephyr]

Some questions...

(1) Is it true that RAM refresh is disabled on Dragon/CoCo machines when running &HFFD9 mode?

(2) Can anyone please explain exactly why Dragon Data fitted 14.218 MHz crystals in some Dragon 32/64s resulting in a slower clock speed?

(3) Does anyone actually have a Dragon that will run continuously at &HFFD7 speed without problems?

[sixxie]

Some questions...

(1) Is it true that RAM refresh is disabled on Dragon/CoCo machines when running &HFFD9 mode?

According to the SAM data sheet, yes. Think of it in terms of the SAM having only two "slots" for RAM accesses - usually one goes to the CPU and one to the VDG. RAM refresh occurs during horizontal blanking when the VDG isn't using its slot.

In fast mode, the CPU takes both slots, with no convenient guaranteed time of no RAM access, so refresh can't occur.

In address-dependent mode the CPU is only sped up during ROM accesses, so the RAM will definitely still be available to refresh without conflict.

(2) Can anyone please explain exactly why Dragon Data fitted 14.218 MHz crystals in some Dragon 32/64s resulting in a slower clock speed?

Graham Kinns' reckons here that it reduces interference with the colour subcarrier, but it also happens that the ratio is nearly spot on that of NTSC to PAL line rate - very very close, but not exactly the same. Possibly some televisions benefited from the line rate being closer to PAL spec?

(3) Does anyone actually have a Dragon that will run continuously at &HFFD7 speed without problems?

I've only ever used Dragon 64s (bar a couple of plain 32 boards only ever hooked up briefly), and they never had a problem. I'm sure I've read that only earlier Dragon 32s actually crashed, but I can't remember why. Someone with more hardware nous could probably answer that better

[zephyr]

According to the SAM data sheet, yes. Think of it in terms of the SAM having only two "slots" for RAM accesses - usually one goes to the CPU and one to the VDG. RAM refresh occurs during horizontal blanking when the VDG isn't using its slot.

In fast mode, the CPU takes both slots, with no convenient guaranteed time of no RAM access, so refresh can't occur.

In address-dependent mode the CPU is only sped up during ROM accesses, so the RAM will definitely still be available to refresh without conflict.

So, the &HFFD9 mode can only be used for very short periods of time?

[zephyr]

Graham Kinns' reckons here that it reduces interference with the colour subcarrier, but it also happens that the ratio is nearly spot on that of NTSC to PAL line rate - very very close, but not exactly the same. Possibly some televisions benefited from the line rate being closer to PAL spec?

I'm hoping someone can explain for sure why Dragon Data did this.

I don't like the idea of slowing the CPU's clock speed. What's your opinion of this?

[sixxie]

So, the &HFFD9 mode can only be used for very short periods of time?

I guess so - for however long the RAM can go without refresh. Interesting thought though - you should definitely be alright for some short time into the vertical refresh - I think some experimentation is in order

I don't like the idea of slowing the CPU's clock speed. What's your opinion of this?

Well the part is rated at 1MHz, so it's already been slowed to 0.89Mhz. Another 0.006MHz probably doesn't make *much* difference.

In a game it makes even less difference: everything you do will be relative to the video signals anyway, and you'll have exactly as many CPU cycles per scanline (and thus cycles per frame) as before.

[zephyr]

I guess so - for however long the RAM can go without refresh. Interesting thought though - you should definitely be alright for some short time into the vertical refresh - I think some experimentation is in order

On my D32 the following BASIC program works perfectly for about 15 minutes. No crashes or corruption whatsoever until the computer gets warmed up, then it crashes on the second PLAY line.

10 POKE65495,0
20 POKE65497,0
30 PLAY"CDEFGAB"
40 PLAY"CDEFGAB"
50 POKE65496,0
60 PRINT "PRESS <BREAK> TO EXIT"
70 PRINT ""
80 FOR I=1TO5000:NEXT
90 GOTO 20


When the computer gets warmed up, I need to change the program as follows to get it to work without crashing.

10 POKE65495,0
20 POKE65497,0
30 PLAY"CDEFG"
50 POKE65496,0
60 PRINT "PRESS <BREAK> TO EXIT"
70 PRINT ""
80 FOR I=1TO5000:NEXT
90 GOTO 20

The latter program was tested for nearly 5 hours without crashes or any screen corruption. Any idea why the computer can't handle the first program when it gets warmed up?

[zephyr]

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

[sixxie]

Definitely getting away from things I actually know anything about now but I'll hazard a guess that capacitor self-discharge rate is temperature-dependent, and as your computer warms up, the discharge rate increases, so less time has to pass before the DRAM (which is just a matrix of capacitors) loses its information.

Perhaps when someone with a little more (read: some) elec-eng knowledge gets back from holidaying you can get a real answer to that one

[zephyr]

Perhaps when someone with a little more (read: some) elec-eng knowledge gets back from holidaying you can get a real answer to that one

I look forward to that time. Do any of your D64's behave in the same way when running my BASIC test program?

[sixxie]

I'm not around them right now, but can check next year.