CoCo2 64K and SAM

[Mr SQL]

Yes I agree, but I'll have to do some research on setting up a better test. Perhaps something like the test I posted but a version that loads and copies only to DRAM? I'm not sure on the Tandy but would I need to lower RAMTOP (or the ECB equivalent) and then do reads and writes to the DRAM above this for a baseline? Of course the Basic prg would still be in slower DRAM.

Yogi

If you're writing to the cart ROM area, I think you can do this at double speed with the 65495 poke even though you've got RAM there instead of ROM; the bottom 32K of CoCo RAM can be overclocked as well with poke 65497,0 and poke 65496,0 to turn it back off. These pokes double both ROM and RAM access, but SAM cannot keep up and the 6847 will display the Matrix for whatever duration you are over clocked.

[JamesD]

Yes I agree, but I'll have to do some research on setting up a better test. Perhaps something like the test I posted but a version that loads and copies only to DRAM? I'm not sure on the Tandy but would I need to lower RAMTOP (or the ECB equivalent) and then do reads and writes to the DRAM above this for a baseline? Of course the Basic prg would still be in slower DRAM.

Yogi

I'm wondering how much patching the BASIC ROM to move the Direct Page to this RAM would speed up execution over the standard double speed POKE.

You can disable internal address decoding so BASIC could be copied to RAM and patched.

[Van]

Hi MrSQL

 

 

If you're writing to the cart ROM area, I think you can do this at double speed with the 65495 poke even though you've got RAM there instead of ROM; the bottom 32K of CoCo RAM can be overclocked as well with poke 65497,0 and poke 65496,0 to turn it back off. These pokes double both ROM and RAM access, but SAM cannot keep up and the 6847 will display the Matrix for whatever duration you are over clocked.

Well so far haven't had any issues accessing this extended SRAM in the split speed mode. Just trying to pin down the speed advantages.

 

@ JamesD

 

 

I'm wondering how much patching the BASIC ROM to move the Direct Page to this RAM would speed up execution over the standard double speed POKE.
You can disable internal address decoding so BASIC could be copied to RAM and patched.

Interesting idea, somewhat like how the CoCo3's Basic is patched(?).Was/is there any hardware that used /SLENB? I've only seen it described briefly with no detail as to how it affects the system.

So far I haven't seen too great a speed up between DRAM and SRAM with just testing R/W accesses.

This afternoon I ran tests comparing the same code accessing DRAM and SRAM at normal and Split-Speed. The prg writes 256 bytes to mem, then does a block move loop of this page.

As expected both runs, one using DRAM and the other SRAM, at default speed were within a second or two of each other for 200 passes of the loop.

Using the Speed poke, the results were of course faster but the difference between DRAM access and SRAM for 200 passes only showed to be ~10sec.But keep in mind the 200 passes represent 51200 Peek/Poke pairs executed on the RAM.

 

200 page moves @ Default speed:

to $3E80 10:46

to $C000 10:43

200 page moves @ Split-Speed:

to $3E80 7:47

to $C000 7:36

So the major speed differences in the above tests are the Basic function running faster, and the differences between the DRAM access and SRAM access times is minor overall.

My conclusion is the real speed up will be seen when running code from the SRAM. Now to work out a ML routine to test with.

Yogi

[JamesD]

Ok, to speed up BASIC, we can try moving the direct page and the stack to the new SRAM.

Other BASIC settings could be altered so the former stack space could be used for variables and even variables might be moved to SRAM but I don't know what to change to do that.

 

This code hasn't even been assembled let alone tested but it will give you an idea of how the direct page and stack could be moved to SRAM.

I haven't coded for the 6809 in a long time so no promises the syntax of functionality is correct.

; copy direct page and system stack to SRAM expansion
	ORG $3f00

	DI				; disable interrupts

	; save the content of registers
	STD		tempd
	STY		tempy
	STX		tempx

	; copy content of direct page to new location
	LDX		#$0000
	LDY		#$e000
	LDB		#$ff
cpy1:
	LDA		,x+
	STA		,y+
	DEC		b
	BNE		cpy1
	
	LDA		$e0
	TFR		a,dp	; set the DP register
	
	; move system stack to new RAM
	STS		tempp	; save the stack pointer

	LDD		#$7fff	; top of stack space 
	; get stack size
	SBCB	tempp+1	; subtract stack pointer
	SBCA	tempp
	STD		temps	; save stack size
	LDD		#$feff	; top of RAM -256
	; get new stack pointer
	SBCB	temps+1
	SBCA	temps
	STD		tempp	;new stack pointer

	LDY		tempp	; destination address
	TSX				; get the current stack pointer as source
cpy2:
	LDA		,x+
	STA		,y+
	CMPX	#$8000	; top of BASIC stack?
	BNE		cpy2:

	LDS		tempp	; set new stack pointer
	
	
	; restore the content of registers
	LDD		tempd
	LDY		tempy
	LDX		tempx
	
	EI				; enable interrupts
	
	RTS				;exit
	
tempd	fdb	0
tempx	fdb	0
tempy	fdb	0
temps	fdb 0
tempp	fdb	0
	end
	

*edit*

We could also move the disk buffers to SRAM to free up more space for BASIC.

Edited August 5, 2015 by JamesD

[JamesD]

There may be a couple 6502 opcodes in there. Du-oh!

 

*edit*

Remove the DI and EI and replace them with these:

    ORCC   #%01010000    ; disable interrupts

    ANDCC  #%10101111    ; enable interrupts 

Edited August 5, 2015 by JamesD

[JamesD]

I'm looking at the direct page pointers that would need to be modified.
0021, 0023, 0027, 0074 and that's just what I've found so far.


*edit*
0021, top of stack may be the only one that needs changed but the other variables point higher than the stack so I don't know what BASIC will do if 0021 is a higher number than the others.
Insert this code before moving the direct page?

	LDD		#$fefe	; top of RAM -256 -1
	STD		$21		; tell BASIC where the new top of stack is.

Edited August 5, 2015 by JamesD

[JamesD]

So something like this:

; copy direct page and system stack to SRAM expansion
	ORG $3f00

	ORCC	#%01010000	; disable interrupts

	; save the content of registers
	STD		tempd
	STY		tempy
	STX		tempx

	
	; move system stack to new RAM
	STS		tempp	; save the stack pointer

	LDD		#$7fff	; top of stack space 
	; get stack size
	SBCB	tempp+1	; subtract stack pointer
	SBCA	tempp
	STD		temps	; save stack size
	LDD		#$fefe	; top of RAM -256 -1
	STD		$21		; tell BASIC where the new top of stack is.

	; get new stack pointer	
	SBCB	temps+1
	SBCA	temps
	STD		tempp	;new stack pointer

	LDY		tempp	; destination address
	TSX				; get the current stack pointer as source
cpy2:
	LDA		,x+
	STA		,y+
	CMPX	#$8000	; top of BASIC stack?
	BNE		cpy2:

	LDS		tempp	; set new stack pointer


	; copy content of direct page to new location
	LDX		#$0000
	LDY		#$e000
	LDB		#$ff
cpy1:
	LDA		,x+
	STA		,y+
	DEC		b
	BNE		cpy1
	
	LDA		$e0
	TFR		a,dp	; set the DP register
	
	
	
	; restore the content of registers
	LDD		tempd
	LDY		tempy
	LDX		tempx

	; set zero page info for stack	
	LDD		#$
	STD		$21
	
	
	
	ANDCC	#%10101111	; enable interrupts
	
	RTS				;exit
	
tempd	fdb	0
tempx	fdb	0
tempy	fdb	0
temps	fdb 0
tempp	fdb	0
	end
	 

Edited August 5, 2015 by JamesD

[Van]

Thanks JamesD. I'll dig into this, I find that reading source code is the best way for me to learn So far I haven't looked too hard at ECB's mem map so this is a very good entry point for me.

Yogi

[JamesD]

Thanks JamesD. I'll dig into this, I find that reading source code is the best way for me to learn So far I haven't looked too hard at ECB's mem map so this is a very good entry point for me.

Yogi

This might be of some use to you

http://www.lomont.org/Software/Misc/CoCo/Lomont_CoCoHardware.pdf

[Van]

This might be of some use to you

http://www.lomont.org/Software/Misc/CoCo/Lomont_CoCoHardware.pdf

Thanks, Yes A+ on that doc. I've had a local copy here for a few weeks as a goto ref. But up to now have been focused on HW issues mainly. Also got a copy of "500 Peeks, Pokes and Execs" (think that's the title) that I've skimmed thru a bit. Wish there was a "Compute's First( Second, Third...) book of the Tandy", read the Atari ones cover to cover many times BITD

Yogi

[JamesD]

...
	; set zero page info for stack	
	LDD		#$
	STD		$21
...	 

That part should be deleted.

[JamesD]

So, I'm looking at the Extended Color Basic Unraveled book and it appears to be different than Lamont's book.

Patching BASIC to move the DP register would be pretty simple since the DP register is only set in one location... which is different by basic version.
Just replace a line of code with a JSR to the address where the hidden MICROSOFT string is at the end of the SIN() table and put the replacement code there with an RTS at the end.

The code needed to modify the location of variables and the stack is easy enough, it's all set in one spot. I might need to dump the memory test and assume it's a 64K CoCo or shorten the memory test. But I haven't found where BASIC checks to see if the program has run out of space for lines yet.

Edited August 14, 2015 by JamesD

[JamesD]

Code to move the direct page to cart RAM.
I'll have to build a BASIC program that loads this before I can test it on the RAM cart.

Maybe a combination of Ahl's benchmark and this so I can benchmark before and after.

                      ; copy direct page and system stack to SRAM expansion
                                         ORG 	$3f00	
                                          		
 3F00 1A   50                            ORCC 	#%01010000	; disable interrupts
                                          		
                       ; save the content of registers
                       ; we can get away with using the stack because the content
                       ; of the stack will be moved as will the pointer
 3F02 34   36                            pshs 	a,b,x,y	
                                          		
                       ; copy content of direct page to new location
 3F04 8E   0000                          LDX 	#$0000	
 3F07 108E E000                          LDY 	#$e000	
 3F0B C6   FF                            LDB 	#$ff	
                       cpy1               		
 3F0D A6   80                            LDA 	,x+	
 3F0F A7   A0                            STA 	,y+	
 3F11 5A                                 DECB 		
 3F12 24   F9                            BCC 	cpy1	
                                          		
 3F14 96   E0                            LDA 	$e0	
 3F16 1F   8B                            TFR 	a,dp	; set the DP register

                       ; restore the content of registers
 3F18 35   36                            puls 	y,x,b,a	
                                          		
 3F1A 39                                 RTS 	;exit	
                                          		
              {$0000}                    end 		
[No Errors] 

[Van]

Too Cool! I've been kind of quite lately, been setting up a tool chain. So I'll test assemble this to make sure my setup is working

 

Yogi

[JamesD]

Too Cool! I've been kind of quite lately, been setting up a tool chain. So I'll test assemble this to make sure my setup is working

 

Yogi

I assembled it with ccasm but I didn't use any features unique to that assembler.

[Van]

I assembled it with ccasm but I didn't use any features unique to that assembler.

OK. I thought that I would try out some of the asm options in RainbowIDE to get a feel for it. I installed the trial ver, guessing that the nag screen is the only limit ( no time limit was mentioned). If Rainbow is limited/ unuseable will revert back to Notepad++ and CLI tools. Kind of used to this setup for 6502 and PIC stuff

Yogi

[JamesD]

OK. I thought that I would try out some of the asm options in RainbowIDE to get a feel for it. I installed the trial ver, guessing that the nag screen is the only limit ( no time limit was mentioned). If Rainbow is limited/ unuseable will revert back to Notepad++ and CLI tools. Kind of used to this setup for 6502 and PIC stuff

Yogi

I tried using the RainbowIDE years ago. Even paid for it.

There were some annoying bugs that never got fixed and then suddenly the author announced a new IDE and the problems I was having never got fixed.

 

I use Notepad++ and CLI tools now.

[Van]

I tried using the RainbowIDE years ago. Even paid for it.

There were some annoying bugs that never got fixed and then suddenly the author announced a new IDE and the problems I was having never got fixed.

 

I use Notepad++ and CLI tools now.

Oh well. Gotten used to NP++ and the NP Exec plug simplifies the build but was hoping for a more integrated setup. 'Grass is always greener' syndrome I guess

Messed around with JAC!'s plugin for Eclipse but without extending the coding it doesn't seem like there is an easy way (NP++ style) to add a 6809 assembler ( there's kind of a kluge way to re-direct the build, it seems). His plugin is a quite nice 6502 environment with lots of options, so the next Atari or C= thing I jump into, will use it.

Yogi

[JamesD]

FWIW, the Rainbow IDE editor seemed to work fine. It was the build function that gave me issues.