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 wrote: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.
How to run the Dragon at double speed
Re: How to run the Dragon at double speed
Re: How to run the Dragon at double speed
The Color64 has an 68B09. There is performance change on machines with different processors ?
Daniel
Daniel
Re: How to run the Dragon at double speed
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).
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).
Re: How to run the Dragon at double speed
Some interesting information here from John Kowalski (Sock Master) over at the CoCo Forums.
Sock Master wrote: 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.
Re: How to run the Dragon at double speed
More interesting information posted by John Linville in reply to the previous quote from Sock Master at the CoCo Forums.
John Linville wrote: 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?
Re: How to run the Dragon at double speed
I wonder if this is correctly emulated by any of the current CoCo/Dragon emulators?Sock Master wrote: 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.
Re: How to run the Dragon at double speed
Sock Master wrote: 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.
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.John Linville wrote: Regarding the full double speed poke, I actually use that in Fahrfall to get the extra cycles during the vblank.
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
- Attachments
-
- VB1TEST.zip
- (1.76 KiB) Downloaded 325 times
Re: How to run the Dragon at double speed
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.
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.
Re: How to run the Dragon at double speed
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.zephyr wrote:Sock Master wrote: 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.
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.
Re: How to run the Dragon at double speed
Unless you wanted to do a super-fast ROM to RAM copy.sixxie wrote: And theoretically, if S were pointing into ROM, the push and pull instructions could trigger it too, but that's not terribly useful...
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