Double Speed?

[JamesD]

I'll have to take a look at that... it looks kinda long for what's needed.

All I know is that if you don't get the page size correct it won't refresh properly. If you go too long between refreshes... same thing.
I think the sta needs to be uncommented too. Seems to me writes recharge the DRAMs better and a read/write sure wouldn't hurt. As to where I picked up that bit of knowledge, I have no idea.
Maybe every address needs refreshed and you need to do several bytes at a time. Then I'd use D instead of A.

There's always the possibility that an occasional full refresh may still be needed, just not as often.

[zephyr]

All I know is that if you don't get the page size correct it won't refresh properly.

Didn't know that! I had assumed that so long as you were reading and writing from/to RAM that it would be refreshed.

If you go too long between refreshes... same thing.

Knew that one though...

OK, please write back when you have some corrected code, and I'll give it a try.

[JamesD]

All I know is that if you don't get the page size correct it won't refresh properly.

Didn't know that! I had assumed that so long as you were reading and writing from/to RAM that it would be refreshed.

If you read/write to all RAM repeatedly that should refresh it if you do it fast enough.
But the goal is to limit it to pages so less reading/writing is needed.
At least that's how I understood it. I'm not an EE guy so someone else may know better.
I think the page size is based on the size of RAM chips. The refresh has to hit all the RAM chips.

An obvious beginning place is repeatedly reading all RAM for an extended period of time. Then every other address.
If the first one works but not the 2nd then the only solution I can see is to enable the refresh periodically.
If the 2nd works... then it's a matter of doubling the step between locations until it doesn't work. That should tell us the page size.
Once we know the page size we can put it in an interrupt handler.
In the event the 1st method doesn't work, try reading and writing the data back to the same address.
If that doesn't work... periodically enable the refresh.

[zephyr]

I think that periodically enabling refresh is the best idea. I'll give it a try, and get back to you over the next few days.

[zephyr]

The IRQ is triggered 50 times every second on a standard UK PAL Dragon 32/64. Do you think that resetting the computer back to normal speed for 1/50th of every second would be good enough to keep the RAM refreshed?

[JamesD]

The IRQ is triggered 50 times every second on a standard UK PAL Dragon 32/64. Do you think that resetting the computer back to normal speed for 1/50th of every second would be good enough to keep the RAM refreshed?

I figured 1 time every 15 seconds or something like that would work. Machines can probably go longer than that but I figured be on the safe side and it will work on all machines. So... 1 interrupt period normal speed, 50 x 15 fast, repeat.

[sixxie]

Are you just trying to find out how much raw computing you can get out of a Dragon, despite corrupt display?

The SAM data sheet suggests that a complete refresh is performed by accessing 128 sequential addresses. Also I don't think you need writes: just accessing the appropriate addresses should be enough to get the transparent refresh behaviour.

Being in slow mode for 16 scanlines would seem to be enough if you were happy to let the SAM do it - or just ensure you're running some code from RAM that covers a block of 128 addresses often enough that you don't have to otherwise think about it?

[zephyr]

Thanks for the feedback! OK, Here's what I've come up with so far...

Here's the source code.

Code: Select all

10          ORG      $5000
20          ORCC     #$50
30          LEAX     RAMISR,PCR
40          CMPX     $10D
50          BEQ      BAS
60          LDU      $10D
70          STU      ROMISR+1,PCR
80          STX      $10D
90 BAS      RTS
100 RAMISR   LDA      $76
110          BNE      DSPEED
120          STA      $FFD8
130          LDA      $77
140          STA      $76
150          BRA      ROMISR
160 DSPEED   STA      $FFD9
170          DEC      $76
180 ROMISR   JMP      $9D3D

And here's a small BASIC program to test it.

Code: Select all

10 STARTMC=&H380
20 FORI=STARTMC TO STARTMC+40:READA$:POKEI,VAL("&H"+A$):NEXT
30 DATA 1A,50,30,8D,0,10,BC,1,D,27,A,FE,1,D,EF,8D,0,17,BF,1,D,39
40 DATA 96,76,26,9,B7,FF,D8,96,77,97,76,20,5,B7,FF,D9,A,76,7E
50 CLS:TIMER=0:FORI=1TO1000
60 PRINT"QWERTY"
70 NEXT:NS=TIMER
80 POKE&H77,49:POKE65495,0:POKE65497,0:EXEC STARTMC
90 CLS:TIMER=0:FORI=1TO1000
100 PRINT"QWERTY"
110 NEXT:DS=TIMER
120 POKE&H77,0:POKE65496,0:POKE65494,0
130 CLS:PRINT"RESULTS:"
140 PRINT"NORMAL SPEED =";NS/50
150 PRINT"DOUBLE SPEED =";DS/50

With this routine the Dragon gets 1/50th of a second to refresh the RAM. The time interval before each RAM refresh is set by changing the value at $77 (Dec 119). A value of decimal 50 would give one second intervals on a standard UK PAL Dragon32/64.

I'll test it sometime over the next few days and get back to you with the results.

Regards,
Steve

[zephyr]

The program above will also work OK on a CoCo with some slight modification.

You would need to change:-

Code: Select all

140 PRINT"NORMAL SPEED =";NS/50
150 PRINT"DOUBLE SPEED =";DS/50

to:-

Code: Select all

140 PRINT"NORMAL SPEED =";NS/60
150 PRINT"DOUBLE SPEED =";DS/60

You may also need to change the machine code start address from $0380. The memory from $02D9 to $03D8 is used by Dragon BASIC for the INPUT buffer. There should be no problems if this is the same for CoCo BASIC, unless you wanted to use INPUT with a long line of text.

[zephyr]

OK, I've done some pretty thorough testing, and the results are better than expected. First I ran the BASIC program and got the following times:

NORMAL SPEED = 11.32
DOUBLE SPEED = 5.68

I got the following times after changing the value in line 80 from 49 to 25:

NORMAL SPEED = 11.32
DOUBLE SPEED = 5.7

Great results!


Then I tried poking different values into 119 ($77) from the command prompt and found out that anything much over 60 causes the RAM refresh to fail. The next test was to poke 119 with my original default value of 49 and just leave the Dragon at the command prompt waiting for input. After that, I returned to the Dragon about every 10 - 15 minutes and typed in PLAY"CDEFGAB" a few times to check that it was still working OK. Finally after two hours I typed in POKE119,0 to disable the routine and checked that the BASIC program was still intact. There was no sign of any corruption on the text screen or in the BASIC program.

Now if only this routine could be emulated with hardware!