Double Speed?

[zephyr]

Thanks for the feedback Ciaran! This morning at 4.00 am I started program one from above with a for next count of 8806000 for 14 hours. It exited exactly on time this evening at 6.00 pm with a final displayed time of 844.56 minutes. After the test, without switching off the computer I loaded Flipper and let it run in demo mode for a while just to make sure that the Dragon was functioning correctly after such a long test. The Dragon functioned perfectly and seems to be 100% stable.

Well, to refresh you only need access each row on a RAM within the refresh time -

When you say "access", do you mean read/write, or will just reading from RAM do the job?

- in general, interpreting BASIC does access lots of sequential addresses, so that might just be enough.

Well, as there's definitely RAM refresh happening, this would seem to be the most probable explanation for now. I will write a small machine code program to test the theory.

BTW, do you happen to know the opcode for the HCF instruction?

[sixxie]

The Dragon functioned perfectly and seems to be 100% stable.

Excellent dedication to testing there! It's good (and very reassuring) information.

Well, to refresh you only need access each row on a RAM within the refresh time -

When you say "access", do you mean read/write, or will just reading from RAM do the job?

I think even a read is fine: by selecting the row, it gets refreshed.

BTW, do you happen to know the opcode for the HCF instruction?

Heh, no. I did stumble across an instruction that just reset the machine while looking into that sort of thing as a kid. http://www.burgins.com/m6809.html suggests it's $3E.

[zephyr]

Heh, no. I did stumble across an instruction that just reset the machine while looking into that sort of thing as a kid. http://www.burgins.com/m6809.html suggests it's $3E.

I know about that one, and it can be handy as it can save some code, but its not always available under emulation.

I have found information on the internet that reports the 6809 HCF opcode as being $DD or $D9, which are in fact the opcodes for STD and ADCB.

The instruction makes the processor enter a mode intended for manufacturing testing, in which it continuously performs random-access memory read cycles from successive memory addresses, with no intervening instruction fetches. Effectively the address bus becomes a counter allowing the operation of all address lines to be quickly verified. Once the processor has entered this test mode, it is not responsive to interrupts, so normal operation can only be restored by a reset.

[admin]

Theres a couple of games out there that patched the reset vector to issue this instruction if anybody pressed the reset button in an attempt to prevent hacking.... didn't work as we just wrote a custom loader routine to get the game into RAM and then mess with it !!

[zephyr]

Theres a couple of games out there that patched the reset vector to issue this instruction if anybody pressed the reset button in an attempt to prevent hacking.... didn't work as we just wrote a custom loader routine to get the game into RAM and then mess with it !!

Fun Days!

Do you remember the games, or the opcode for the HCF instruction?

[zephyr]

OK, here's my double speed machine code test...

We now have a 100% machine code program running for nearly 22 minutes before exiting. This first program ran OK for the full 22 minutes, but failed to return to BASIC. After pressing the reset button, I loaded Encoder and dissasembled the memory to find that the actual machine code program had survived intact. For the second run, I just typed "EXEC&H5000" from the command prompt. Same result.

Code: Select all

10 'M/C DOUBLE SPEED TEST #1
20 FORI=&H5000 TO &H5040:READA$:POKEI,VAL("&H"+A$):NEXT
30 CLS:INPUT"START TEST (Y/N)";K$
40 IF K$="Y"THEN EXEC&H5000 ELSE IFK$="N"THEN END ELSE 30
50 CLS:PRINT"TEST COMPLETE":END
60 DATA 1A,50,FE,1,D,30,8D,0,2C,BF,1,D,8E,0,1,BF,1,12,7F,FF,D7,7F,FF,D9,1C,AF,8E,4,0,ED,81,8C,6,0,26,F9,FC,1,12,26,F1,1A,50,7F,FF,D8,7F,FF,D6,FF,1,D,39,B6,FF,2,BE,1,12,30,1,BF,1,12,3B

The dissasembled machine code...

Code: Select all

5000   1A 50     ORCC #$50
                 (SET I,F)
5002   FE 010D   LDU  >$010D
5005   30 8D002C LEAX $5035,PCR
5009   BF 010D   STX  >$010D
500C   8E 0001   LDX  #$0001
500F   BF 0112   STX  >$0112
5012   7F FFD7   CLR  >$FFD7
5015   7F FFD9   CLR  >$FFD9
5018   1C AF     ANDCC#$AF
                 (CLR I,F)
501A   8E 0400   LDX  #$0400
501D   ED 81     STD  ,X++
501F   8C 0600   CMPX #$0600
5022   26 F9     BNE  $501D
5024   FC 0112   LDD  >$0112
5027   26 F1     BNE  $501A
5029   1A 50     ORCC #$50
                 (SET I,F)
502B   7F FFD8   CLR  >$FFD8
502E   7F FFD6   CLR  >$FFD6
5031   FF 010D   STU  >$010D
5034   39        RTS  
5035   B6 FF02   LDA  >$FF02
5038   BE 0112   LDX  >$0112
503B   30 01     LEAX 1,X
503D   BF 0112   STX  >$0112
5040   3B        RTI  

I then made a slight modification to the program so that it does a cold restart of BASIC after running the test. This second program worked five times in a row without problems. Each time just typing "EXEC&H5000" to restart the test. It finally froze the machine on the sixth attempt.

Code: Select all

10 'M/C DOUBLE SPEED TEST #2
20 FORI=&H5000 TO &H503E:READA$:POKEI,VAL("&H"+A$):NEXT
30 CLS:INPUT"START TEST (Y/N)";K$
40 IF K$="Y" THEN EXEC&H5000 ELSE IF K$="N" THEN END ELSE 30
50 DATA 1A,50,30,8D,0,2D,BF,1,D,8E,0,1,BF,1,12,7F,FF,D7,7F,FF,D9,1C,AF,8E,4,0,ED,81,8C,6,0,26,F9,FC,1,12,26,F1,1A,50,7F,FF,D8,7F,FF,D6,F,71,7E,B3,B4,B6,FF,2,BE,1,12,30,1,BF,1,12,3B

The dissasembled machine code...

Code: Select all

5000   1A 50     ORCC #$50
                 (SET I,F)
5002   30 8D002D LEAX $5033,PCR
5006   BF 010D   STX  >$010D
5009   8E 0001   LDX  #$0001
500C   BF 0112   STX  >$0112
500F   7F FFD7   CLR  >$FFD7
5012   7F FFD9   CLR  >$FFD9
5015   1C AF     ANDCC#$AF
                 (CLR I,F)
5017   8E 0400   LDX  #$0400
501A   ED 81     STD  ,X++
501C   8C 0600   CMPX #$0600
501F   26 F9     BNE  $501A
5021   FC 0112   LDD  >$0112
5024   26 F1     BNE  $5017
5026   1A 50     ORCC #$50
                 (SET I,F)
5028   7F FFD8   CLR  >$FFD8
502B   7F FFD6   CLR  >$FFD6
502E   0F 71     CLR  <$71
5030   7E B3B4   JMP  >$B3B4
5033   B6 FF02   LDA  >$FF02
5036   BE 0112   LDX  >$0112
5039   30 01     LEAX 1,X
503B   BF 0112   STX  >$0112
503E   3B        RTI  

[JamesD]

A small machine program will actually never fail in double speed mode. The RAM accesses from running it causes the RAM to refresh.
When you tried to return to basic, other RAM pages not accessed had become corrupted which is why it locked up.
The only reason the program that does a cold start might fail is if the code that doesn't get run until the end is on another page. At least that's the only thing I can think of.

There is a letter to the editor in the Rainbow magazine where a subscriber is trying to use the high speed poke (65495,0) and replaced all the chips and it still didn't work. After examining signals with an oscilloscope, he found some clock signals had long and out of spec rise and fall times. After removing two capacitors the machine ran fine with the high speed poke. He lists the capacitors in the coco, they would be different on the Dragon but someone should be able to locate them if they are there. Another possible reason a machine doesn't work with this poke is a slow ROM chip. If a few bucks were saved then that is a real possibility.

Here is the section that talks about it:
http://cocomag.dyndns.org/TheRainbow/82 ... -art-3.jpg

Or you can go to this site to read the entire March 1982 issue:
http://cocomag.dyndns.org/TheRainbow.shtml

The author of the letter also mentions an earlier letter where he asked about these capacitors but I'm not sure what issue. He may mention what board revision he has. I had a rev E (if I remember right) purchased in '82, and it worked with the high speed poke out of the box. I'm guessing he would have an earlier board if you want to look up the schematics.

If you really want to use the 65497 POKE without RAM ever corrupting you could buy a 64K SRAM, add a latch to capture the upper byte of the address from the buss and an inverter to invert the RAS line to trigger the latch (at least I think that's the circuit). Static RAM doesn't need refresh.

[JamesD]

BTW, if you want to run almost continously in the poke 65497,0 double speed mode there may be a fairly simple solution.
IF the TOF interrupt is still being generated then you could create an interrupt handler that counts interrupts, after a given time, drops the speed back down for 1 interrupt cycle and then returns the machine to high speed mode and starts the count over. If you just used a byte for the counter it would refresh about every 5 seconds. With a 16 bit counter you can play with it. There would need to be some sort of USR routines to control it from BASIC if you don't do all assembly.
<edit>
An alternative would be to manually refresh each DRAM page. You could read a byte from each page in the interrupt handler. By reading from a different page each interrupt you could refresh all the memory with fewer clock cycles wasted. Now... anyone know the size of the pages?
Anyway... one page is refreshed per interrupt... at least in theory. All 32K RAM in RAM+ROM mode is refreshed every 2 to 3 seconds if a page is 256 bytes, twice as long if a page is 128 bytes, and in under twelve seconds if a page is 64 bytes. At least if my math is correct. That *should* work on all machines.
It also doesn't touch the current poke setting but you'd probably have to call the current interrupt handler instead of RTI at the end so BASIC still works ok.

Code: Select all

Interrupt
 pshs a,x
;clear interrupt in place of this text
 ldx refreshaddress
 lda ,x
; sta ,x   ; may be needed... not sure
 leax #pagesize,x
 cmpx #ROMAddress
 bmi @exit
 ldx #0
@exit
 stx refreshaddress
 puls a,x
 rti

[zephyr]

Thanks for the feedback JamesD! I actually tried something very similar to this some time ago but the results were not very promising. I'll see if I can find the source code...

[zephyr]

I didn't find the original source code, but here's a disassembly of the test program. Change the value of 'LDA #$0C' to speed up/slow down RAM refresh.

Code: Select all

0380   1A 50     ORCC #$50
                 (SET I,F)
0382   30 8D0010 LEAX $0396,PCR
0386   BC 010D   CMPX >$010D
0389   27 0A     BEQ  $0395
038B   FE 010D   LDU  >$010D
038E   EF 8D0020 STU  $03B2,PCR
0392   BF 010D   STX  >$010D
0395   39        RTS  
0396   86 0C     LDA  #$0C
0398   9E 76     LDX  <$76
039A   EE 84     LDU  ,X
039C 10AE 02     LDY  2,X
039F   EF 81     STU  ,X++
03A1 10AF 81     STY  ,X++
03A4   4A        DECA 
03A5   26 F3     BNE  $039A
03A7   8C 7FFE   CMPX #$7FFE
03AA   23 03     BLS  $03AF
03AC   8E 0000   LDX  #$0000
03AF   9F 76     STX  <$76
03B1   7E 0000   JMP  >$9D3D