How to run the Dragon at double speed

[zephyr]

Nice!

Tested on the Color64 and follow the results:

POKE65495,0:POKE65497,0:PLAY"C":POKE65496,0:POKE65494,0 : Ok

POKE65495,0:POKE65497,0:PLAY"CDE":POKE65496,0:POKE65494,0 : OK

POKE65495,0:POKE65497,0:PLAY"CDEFGAB":POKE65496,0:POKE65494,0 : Come back, but the screen get poluted o some places with some strange characters.

POKE65495,0:POKE65497,0:SOUND1,50":POKE65496,0:POKE65494,0 : Come back, but the screen get poluted o some places with some strange characters.

POKE65495,0:POKE65497,0:SOUND1,100":POKE65496,0:POKE65494,0 : Screen garbled after execution have finished.
.
.
.
POKE65495,0:POKE65497,0:SOUND1,255":POKE65496,0:POKE65494,0 : Screen garbled after execution have finished.

Those results are pretty good. You can rest assured that a machine like that would always be super-stable when running at POKE65495,0 speed.

[Dantyr]

The Color64 has an 68B09. There is performance change on machines with different processors ?

Daniel

[zephyr]

It doesn't seem to make any difference to the double speed modes whether you have a 6809e (Rated at 1 Mhz max), 68A09e (Rated at 1.5 Mhz max), or 68B09e (Rated at 2 Mhz max). The only advantage of having the 68B09e fitted is knowing that it is not going to be stressed when the computer is running at double speed. Although over my 30 years of using the Dragon and CoCo computers, I have never seen a standard 6809e processor burned out after running at double speed (even after running for several days).

The price of 68B09e processors has been so cheap over the past few years that I have fitted them to all but a few of my CoCo/Dragon machines. I have fitted the far superior 63x09e processor to my other CoCo and Dragon machines (where the ROM chips were easily replaced for ones that were patched with 63x09e error trapping support).

[zephyr]

Some interesting information here from John Kowalski (Sock Master) over at the CoCo Forums.

Oh! - here's something cool that you in particular might find interesting/useful...
Did you know that in the 65495 'semifast' poke, the CPU will actually execute *some* operations faster even though it's running in RAM? Most dramatically, the MUL opcode.. it will execute in the equivalent of 7 normal cycles instead of it's usual 11.
And..... If we're going to be writing code that locks step with the screen anyway... You *can* use the 65497 'double speed' poke without causing any junk on the screen at all if you only enable it during the horizontal and vertical borders.

[zephyr]

More interesting information posted by John Linville in reply to the previous quote from Sock Master at the CoCo Forums.

Semifast poke -- interesting! I'll have to give some thought to understanding that...

Regarding the full double speed poke, I actually use that in Fahrfall to get the extra cycles during the vblank. But you are right, it should work just as well during the hblank if those extra cycles are needed. Maybe you or I should clue-in Simon about that for his 1-bit audio player?

[zephyr]

Did you know that in the 65495 'semifast' poke, the CPU will actually execute *some* operations faster even though it's running in RAM?

Semifast poke: It's because when the 6809 executes cycles that don't access memory, the address bus tri-states and is interpreted by the SAM as $FFFF (a ROM access). When the SAM sees two ROM accesses in a row, it'll run them both at double speed.
Unfortunately, just one non-memory cycle won't trigger a speedup - there have to be two or more in a row. So only *some* opcodes speed up in the semifast poke when run from RAM. I figure all the ones that do something pretty long internally - like TFR, EXG, MUL... There are others, but I haven't mapped this out. It would be handy to make a list of opcodes that run faster in semifast poke.

I wonder if this is correctly emulated by any of the current CoCo/Dragon emulators?

[zephyr]

And..... If we're going to be writing code that locks step with the screen anyway... You *can* use the 65497 'double speed' poke without causing any junk on the screen at all if you only enable it during the horizontal and vertical borders.

Regarding the full double speed poke, I actually use that in Fahrfall to get the extra cycles during the vblank.

I decided to try this little trick myself, and it worked perfectly first time. Full double speed (POKE65497,0) without losing the video display. The keyboard scan (checks for the break key being pressed) is the only part on the code that runs at normal speed. Here is a listing of my test code.

Code: Select all

10          ORG      $5000
20          ORCC     #$50
30 L1       LDA      $FF03
40          BMI      FAST
50          STA      $FFD8
60          LDA      #$FB
70          STA      $FF02
80          LDA      $FF00
90          ANDA     #$40
100          BNE      L1
110          RTS
120 FAST     STA      $FFD9
130          LDX      #$0400
140          LDA      ,X
150          INCA
160 L2       STA      ,X+
170          CMPX     #$05FF
180          BLS      L2
190          LDA      $FF02
200          BRA      L1

I have also attached a copy of the original source code (Encoder 09) and the assembled code in .CAS and .WAV format for anyone that would like to test this on their real CoCo or Dragon. I recommend using Audacity 1.2.6 to convert the included .WAV files to a real audio cassette recording.

[sixxie]

This trick (run double speed outside the active display area) is what I use in my horizontal scrolling demo (from here: http://www.6809.org.uk/dragon/demo/).

XRoar should be doing the right thing with address-dependent mode and sequential non-valid-memory-address cycles generally. It also simulates the extra delay when the SAM "re-interleaves" CPU and VDG access when transitioning from fast to slow cycles.

[sixxie]

I figure all the ones that do something pretty long internally - like TFR, EXG, MUL... There are others, but I haven't mapped this out. It would be handy to make a list of opcodes that run faster in semifast poke.

I think maybe three NVMAs in a row are required for any overall speedup, otherwise that reinterleaving I mentioned elongates the next cycle and it's as if all three ran slow.

Going through mc6809.c and finding all the places where NVMA_CYCLE appears three times in a row:

LBSR, EXG, TFR, MUL, BSR

Indexed modes: ",R++" ,"--R", "16,R", "D,R", "16,PCR"

And theoretically, if S were pointing into ROM, the push and pull instructions could trigger it too, but that's not terribly useful...

Also, maybe anything that accesses ROM or IO has a chance of a fast cycle in there, as there's usually at least one NVMA before the address itself is accessed.

[zephyr]

And theoretically, if S were pointing into ROM, the push and pull instructions could trigger it too, but that's not terribly useful...

Unless you wanted to do a super-fast ROM to RAM copy.

Code: Select all

10          ORG      $5000
20          ORCC     #$50
30          STS      <$76
40          LDA      #$FF
50          TFR      A,DP
60          STA      <$D7
70          LDS      #$8000
80 L1       STA      <$DE
90          PULS     D,X,Y,U
100          STA      <$DF
110          PSHS     D,X,Y,U
120          LEAS     8,S
130          CMPS     #$FF08
140          BLO      L1
150          STA      <$D6
160          CLRA
170          TFR      A,DP
180          LDS      <$76
190          RTS