65Org16.x Dev. Board V1.1 using a Spartan 6 XC6SLX9-3TQG144

ElEctric_EyE · Post by **ElEctric_EyE** » Tue Nov 29, 2011 9:27 pm

Today, I made some progress...

Besides just clearing the TFT screen with the 65Org16 Core successfully @40MHz(TFT&FPGA)!. I've previously mentioned I was only able to run @24MHz max also noticed 110mV noise on the RESET circuit. I've since added an external 1K pull-up resistor and this NHD640x480TFT is working at a more normal 40MHz max with the Spartan 6.

I've modified the 8bit PLTCHR routine I previously posted above to work with the 65Org16. This validates in my mind that this 16bit mod'd Core even works. I had some small doubts, very small, but all of the errors I've found so far have been my own programming errors. I am still modifying the ATTBUTE routine for some extra features of 16bits. But using the original ATTBUTE with the 16bit PLTCHR routine below, I have successfully used the 16bit CLRSCR and 16bit PLTCHR to plot different sizes of the 2 different character sets.

Sorry about the indentation discrepancy. I am a newbie to PSPAD text editor.

Code: Select all

PLTCHR		  PHA		         ;Plot Character Subroutine variable (1-7) H and V size
		        TYA		         ;save all reg's
		        PHA
		        TXA
		        PHA 		
            LDA #$2C	     ;Prepare TFT to Plot
		        STA DCOM
		      
CACALC      SEC	
            LDA CHR
            SBC #$20       ;first 32 ascii characters "undefined"
            BCS nnull
            LDA #$00		  ;make undefined char's a defined zero
nnull       ASL A
		        ASL A		
		        ASL A		      ;multiply character by 8 to get char pointer
			      CLC
			      ADC CHRVECL	  ;add pointer to base either CA00 (C64) or CD00(3x5)
			      STA CHRVECL
ninc		    LDY #$00	    ;vertical bit count
loop7		    LDX YWIDTH	
loop4		    TXA
		        PHA

		        CLC
		        LDX #$00	     ;horizontal bit count
		        LDA (CHRVECL),y	;character data addr, $FFFFCA00(c64) or $FFFFCD00(3x5)
			      ASL A		        ;
			      ASL A		        ;
			      ASL A		        ;
			      ASL A		        ;
			      ASL A		        ;
			      ASL A		        ;
			      ASL A		        ;
			      ASL A		        ;shift out upper 8 bits, don't care for 8-bit byte character font
loop5		    ASL A		        ;Shift left
		        BCC nonpxl	   ;branch on 'blank' bit
pxl2		    PHA		         ;save character data
		        TXA
		        PHA
		        LDX XWIDTH	
xwp		      LDA TMPCOL1	
		        STA DDAT	     ;plot RED pixel TFT data
		        LDA TMPCOL2	
		        STA DDAT	     ;plot GREEN pixel TFT data
		        LDA TMPCOL3	
		        STA DDAT        ;plot BLUE pixel TFT data
		        DEX
		        BNE xwp
		        PLA
		        TAX
		        PLA
		        INX
		        CPX CHRXLEN	
		        BNE loop5	      ;test for horizontal max
		        JMP next
		
nonpxl		  PHA		           ;save character data
		        TXA
		        PHA
		        LDX XWIDTH
xwnp		    LDA SCRCOL1	
		        STA DDAT	       ;plot RED "blank" pixel TFT data
		        LDA SCRCOL2	
		        STA DDAT	       ;plot GREEN "blank" pixel TFT data
		        LDA SCRCOL3 
		        STA DDAT         ;plot BLUE "blank" pixel TFT data
		        DEX
		        BNE xwnp
		        PLA
		        TAX
		        PLA		           ;reload character data to accumulator
		        INX		
		        CPX CHRXLEN	
		        BNE loop5	
		
next		    PLA		
		        TAX
		        DEX		
		        BNE loop4	
		        INY		
		        CPY CHRYLEN       ;test for vertical max
		        BNE loop7	
		
		        PLA		
		        TAX
		        PLA		
		        TAY
		        PLA		;reload all reg's
		        RTS

teamtempest · Post by **teamtempest** » Wed Nov 30, 2011 6:29 am

Here's another crack at that plot routine. There are some changes that would need to be made to the set attribute routine to work with this version, but I hope those would be more-or-less self-evident.

A couple of the finer points:

- the check for 'clearing' is made here instead of the attribute routine and simply plots the first character pattern, which I assume is always a space char (all blank anyway)
- I got took out indirect addressing because a sixteen bit index register is already large enough to cover the address range of the character ROM (is it a ROM? - the character patterns in memory, anyway). Attribute setup just stores the low 16 bits of base address of the charset in use. Absolute addressing takes care of the high 16 bits
- after a char row pattern is shifted to the high eight bits I set a bit to its 'immediate right' that acts as a sentinel (value also set by the attribute routine). No index register or memory location is needed to track when all the bits of the pattern are done; instead the Z-flag does that

Code: Select all

PLTCHR PHA             ; Plot Character Subroutine variable (1-7) H and V size 
       TYA             ; save all reg's 
       PHA 
       TXA 
       PHA        

       LDA #$2C        ; Prepare TFT to Plot 
       STA DCOM 

CACALC LDA PE		; clearing all pixels ?
       BEQ pltspc	; b:yes, plot space character (first in every charset)
       SEC    		
       LDA CHR
       CMP #127+1	; an ascii char ?
       BCS plotspc	; b: no (could be $0080 - $FFFF, don't know)
       SBC #$20-1	; first 32 ascii characters "undefined" 
       BCS nnull 	; original char $20 - $7F now $00 - $5F (96 possible chars)
pltspc LDA #$00        ; make undefined char's a defined zero (space character)
nnull  ASL A           ; * 2
       ASL A           ; * 4
       ASL A           ; * 8 
       ADC CHRBASE     ; add pointer to base either CA00 (C64)  or CD00(3x5) (carry clear)
       TAY

       LDA PATHGT	; pattern rows either 8(c64) or 5(3x5)
       STA PATROW

loop7  LDA PLTHGT	; plot row repeat count (1-7)
       STA PIXROW
loop4  LDA $FFFF0000,y	; $FFFFCA00(c64) or $FFFFCD00(3x5) 
       ASL A          	; 
       ASL A           ; 
       ASL A           ; 
       ASL A           ; 
       ASL A           ; 
       ASL A           ; 
       ASL A           ; 
       ASL A           ; shift out upper 8 bits, don't care for 8-bit byte character font 
       ORA SENTINEL	; $0080 (C64) or $0800 (3x5)

       ASL A           ; get a pixel
loop5  PHA		; save remaining pixel row data
       LDX PLTWID	; plot column repeat count (1-7) (same as PLTHGT?)
       BCC xwnp        ; b: clear ('blank')

xwp    LDA PIXCOL1    
       STA DDAT        ; plot RED pixel TFT data 
       LDA PIXCOL2    
       STA DDAT        ; plot GREEN pixel TFT data 
       LDA PIXCOL3    
       STA DDAT        ; plot BLUE pixel TFT data 
       DEX 
       BNE xwp
       BEQ nxtpix	; b: forced
       
xwnp   LDA SCRCOL1    
       STA DDAT        ; plot RED "blank" pixel TFT data 
       LDA SCRCOL2    
       STA DDAT        ; plot GREEN "blank" pixel TFT data 
       LDA SCRCOL3 
       STA DDAT        ; plot BLUE "blank" pixel TFT data 
       DEX 
       BNE xwnp

nxtpix PLA		; get pixel row data back
       ASL		; another pixel to plot ?
       BNE loop5	; b: yes (sentinel still hasn't shifted out)
       
       DEC PIXROW	; repeat this row ?
       BNE loop4	; b: yes

       INY
       DEC PATROW	; another pattern row to plot ?
       BNE loop7	; b: yes
      
       PLA       
       TAX 
       PLA       
       TAY 
       PLA      	;reload all reg's 
       RTS

ElEctric_EyE · Post by **ElEctric_EyE** » Wed Nov 30, 2011 12:45 pm

Excellent I see and understand a few of your changes. I sorta knew I didn't need indirect indexed as I wasn't changing the high address pointer, but I couldn't think of how to do it at that moment. Thanks for pointing that and some other things out. I'll try it out this morning. Your method uses 3 more variables? PIXROW, PATROW, and SENTINEL. I can use my XWIDTH and YWIDTH, for your PATHGT and PLTHGT/PLTWID. The variable width and height are the same.
I'll try it out, but will at least take your pointers on the 1st half of the code. Thanks TT!

ElEctric_EyE · Post by **ElEctric_EyE** » Wed Nov 30, 2011 3:16 pm

I like how you used the value in SENTINEL as a counter. I'm going to use your entire modification, except including PE. I've quickly tested both fonts, sizes 1,2&4 and it works nicely! Thanks again!

The only problem I see is how you implement the PE into the PLTCHR to clear a character using a space. For example, if PXLCOL1,2,3=yellow, and SCRCOL1,2,3=blue, then when attempting to clear a character, instead of clearing it, there would be a yellow space on a blue background.

So I have removed that, and instead let the ATTBUTE routine manipulate TMPCOL1,2,3 to equal either PXLCOL1,2,3 or SCRCOL1,2,3. I'll post the 16bit version of the ATTBUTE routine when I get it done, hopefully soon.

BTW, I do see why you did this, I think. In order to not call ATTBUTE each and every time just to set a PE (plot or clear)...

What I need to do is incorporate some or most of ATTBUTE into the PLTCHR routine, using a 16bit register and test the individual 16bit settings everytime PLTCHR is called.

Code: Select all

PLTCHR PHA             ; Plot Character Subroutine variable (1-7) H and V size 
       TYA             ; save all reg's 
       PHA 
       TXA 
       PHA        

       LDA #$2C        ; Prepare TFT to Plot 
       STA DCOM 

CACALC SEC           
       LDA CHR 
       CMP #127+1      ; an ascii char ? 
       BCS pltspc      ; b: no (could be $0080 - $FFFF, don't know) 
       SBC #$20-1      ; first 32 ascii characters "undefined" 
       BCS nnull       ; original char $20 - $7F now $00 - $5F (96 possible chars) 
pltspc LDA #$00        ; make undefined char's a defined zero (space character) 
nnull  ASL A           ; * 2 
       ASL A           ; * 4 
       ASL A           ; * 8 
       ADC CHRBASE     ; add pointer to base either CA00 (C64)  or CD00(3x5) (carry clear) 
       TAY 

       LDA CHRYLEN     ; pattern rows either 8(c64) or 5(3x5) 
       STA PATROW 

loop7  LDA XWIDTH      ; plot row repeat count (1-7) 
       STA PIXROW 
loop4  LDA $FFFF0000,Y ; $FFFFCA00(c64) or $FFFFCD00(3x5) 
       ASL A           ; 
       ASL A           ; 
       ASL A           ; 
       ASL A           ; 
       ASL A           ; 
       ASL A           ; 
       ASL A           ; 
       ASL A           ; shift out upper 8 bits, don't care for 8-bit byte character font 
       ORA SENTINEL    ; $0080 (C64) or $0800 (3x5) 

       ASL A           ; get a pixel 
loop5  PHA             ; save remaining pixel row data 
       LDX YWIDTH      ; plot column repeat count (1-7) (same as PLTHGT?) 
       BCC xwnp        ; b: clear ('blank') 

xwp    LDA TMPCOL1    
       STA DDAT        ; plot RED pixel TFT data 
       LDA TMPCOL2    
       STA DDAT        ; plot GREEN pixel TFT data 
       LDA TMPCOL3    
       STA DDAT        ; plot BLUE pixel TFT data 
       DEX 
       BNE xwp 
       BEQ nxtpix      ; b: forced 
        
xwnp   LDA SCRCOL1    
       STA DDAT        ; plot RED "blank" pixel TFT data 
       LDA SCRCOL2    
       STA DDAT        ; plot GREEN "blank" pixel TFT data 
       LDA SCRCOL3 
       STA DDAT        ; plot BLUE "blank" pixel TFT data 
       DEX 
       BNE xwnp 

nxtpix PLA             ; get pixel row data back 
       ASL A           ; another pixel to plot ? 
       BNE loop5       ; b: yes (sentinel still hasn't shifted out) 
        
       DEC PIXROW      ; repeat this row ? 
       BNE loop4       ; b: yes 

       INY 
       DEC PATROW      ; another pattern row to plot ? 
       BNE loop7       ; b: yes 
      
       PLA        
       TAX 
       PLA        
       TAY 
       PLA             ;reload all reg's 
       RTS

teamtempest · Post by **teamtempest** » Thu Dec 01, 2011 2:50 am

Glad you like it!

I confess I don't quite understand this:

Quote:

For example, if PXLCOL1,2,3=yellow, and SCRCOL1,2,3=blue, then when attempting to clear a character, instead of clearing it, there would be a yellow space on a blue background.

I think of a monochrome 'space' char as 'all pixels backround color' and the pattern for describing that as all zero bits in every row. If that's the case on your system, then I would expect that every shift of a bit from that pattern into the carry flag would clear it. If so, the code should branch to 'xwnp' every time through the loop, always skipping 'xwp'.

But you know your hardware better than I do, and it doesn't really make a noticeable difference in the run time of the PLTCHR routine either way.

Mmm, and this part I wrote:

Code: Select all

CACALC SEC            
       LDA CHR 
       CMP #127+1      ; an ascii char ?

Well that's just silly because there's no need to set the carry before doing a CMP, and I shouldn't have put that SEC there. It should be just:

Code: Select all

CACALC LDA CHR
       CMP #127+1

You're right that I used a few more memory locations than you did. I did that to save space and time in the routine itself. However this does have the drawback of making it less amenable to being 're-entrant', and therefore less suitable to a multi-tasking environment.

Which was not really a problem with a 64K environment, where most programs could more-or-less count on having the whole machine to themselves. I do wonder a bit if that's a reasonable expectation in a 4GB environment.

ElEctric_EyE · Post by **ElEctric_EyE** » Tue Dec 06, 2011 12:26 am

teamtempest wrote:

...I think of a monochrome 'space' char as 'all pixels backround color' and the pattern for describing that as all zero bits in every row...

Ah, but this is not a monochrome display as I send three bytes (only 6 bits are used for each) to define 1 color of 65K. Many thanks for your help refining my 8bit plot routine for the 65Org16!

This completes my character out routine, with the possibility of some simple graphics like line, box, etc. for a "coolness" effect.

Tomorrow, I work on implementing the PS2 core once again, should be no problem. If it works, as in my wirewrapped 6502SoC project, then I will have my character in routine and I will be focusing on the software side of things, in fact I already have been trying to decide on 1 of 3 original 6502 Monitors originally made for the Commodore 64...

ElEctric_EyE · Post by **ElEctric_EyE** » Tue Dec 13, 2011 4:56 pm

Got the keyboard section working!

Also, I received the 800x480 TFT back yesterday. It was fully tested by the fine folks at NewHavenDisplay and was found to have no problems. Most likely my pullup resistor for the RESn was too high @4.7K, we shall see. So I will try to interface to it again since it has the touchscreen I would like to take advantage of, not to mention the resolution is better.

ElEctric_EyE · Post by **ElEctric_EyE** » Tue Dec 13, 2011 7:33 pm

ElEctric_EyE wrote:

... Most likely my pullup resistor for the RESn was too high @4.7K, we shall see. So I will try to interface to it again since it has the touchscreen I would like to take advantage of, not to mention the resolution is better.

This appears to have been the problem. My RESn pullup was not strong enough for the 800x480TFT, although it was good enough for the 640x480TFT... As suggested by a DS1818 datasheet footnote, "3. A 1 k external pull-up resistor may be required in some applications for proper operation of the
microprocessor reset control circuit.", I've used a 1.2K pullup and the display is working consistently @40MHz E signal.

BigEd · Post by **BigEd** » Thu Dec 15, 2011 5:45 pm

Hi EEye, to summarize your dev board progress: you have got 65Org16 code running, but only from block RAM, not yet from external RAM. Is that right?

Cheers
Ed

ElEctric_EyE · Post by **ElEctric_EyE** » Thu Dec 15, 2011 7:18 pm

Correct... I wish I could make quicker progress. But the progress I have made I can say it is solid.

BigEd · Post by **BigEd** » Thu Dec 15, 2011 10:37 pm

No, no criticism intended - my own progress isn't fast. I was just wondering what we've managed to do so far with the core. It seems we've both had it working on silicon - spartan 3 and 6 - with various peripherals, but not yet with external memories. (I've previously had the extra difficulty of only having an 8-bit wide memory available, but now I've got 16-bit wide I might get somewhere with that. I do need to figure out the DDR interface.)

Cheers
Ed

ElEctric_EyE · Post by **ElEctric_EyE** » Fri Dec 16, 2011 2:03 am

BigEd wrote:

No, no criticism intended - my own progress isn't fast. I was just wondering what we've managed to do so far with the core. It seems we've both had it working on silicon - spartan 3 and 6 - with various peripherals, but not yet with external memories. (I've previously had the extra difficulty of only having an 8-bit wide memory available, but now I've got 16-bit wide I might get somewhere with that. I do need to figure out the DDR interface.)

Cheers
Ed

Good luck with the DDR core. That's some unventured territory!

In a way, the TFT I am working with can be considered external memory although it is being written to in a successive manner, i.e. one sets a beginning and ending address then sends the 3 consecutive 8bit data to define the color of each pixel. O2, A0, CSn, RWn, and D0-D7 are all used just as if a typical SRAM would be used. O2 is going through a DDR FF. All other signals through a regular FF.

This devboard is setup for an SDRAM though, not DDR. I was hoping to take advantage of Arlet's SDRAM core...

I would like to have some sort of "OS" in the form of an assembler/dissembler present first though, at least 8bit to start with. That way I don't have to keep reprogramming the FPGA PROM.

BigEd · Post by **BigEd** » Fri Dec 16, 2011 10:17 am

Yes, getting a monitor program working is very worthwhile. Whatever progress we make on hardware, we still have lots to do on software as well.

(Edit: I think my DDR problem is easier than it would be for you, because my spartan6 is a BGA type which allows use of a memory controller block. I'm hoping I can borrow chunks of tactics from the supplied examples.)

Please could you put your dev board parts list/BOM in a post here? (Preferably text, not screen grab, so it's searchable. Ideally the head post of this thread or a new thread, so we don't need to look through 17 pages!)

Cheers
Ed

Edit: good point about the LCD peripheral. It means we've had success with on-FPGA and off-FPGA memory-mapped peripherals.

ElEctric_EyE · Post by **ElEctric_EyE** » Fri Dec 16, 2011 9:37 pm

BigEd wrote:

...Please could you put your dev board parts list/BOM in a post here? (Preferably text, not screen grab, so it's searchable. Ideally the head post of this thread...

I need to update it, and I'll post it at the header next few days...

BigEd · Post by **BigEd** » Fri Dec 16, 2011 9:44 pm

That would be great - thanks!