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

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!

ElEctric_EyE · Post by **ElEctric_EyE** » Sun Dec 18, 2011 12:44 am

No problem. I added it, but it is incomplete... Most of the data was from V1.0. I did try to update all the IC's.
Will update the formatting and listing as time permits.