Page 4 of 19
Posted: Tue Nov 29, 2011 9:27 pm
by ElEctric_EyE
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
Posted: Wed Nov 30, 2011 6:29 am
by teamtempest
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
Posted: Wed Nov 30, 2011 12:45 pm
by ElEctric_EyE
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!
Posted: Wed Nov 30, 2011 3:16 pm
by ElEctric_EyE
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
Posted: Thu Dec 01, 2011 2:50 am
by teamtempest
Glad you like it!
I confess I don't quite understand this:
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:
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.
Posted: Tue Dec 06, 2011 12:26 am
by ElEctric_EyE
...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...
Posted: Tue Dec 13, 2011 4:56 pm
by ElEctric_EyE
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.
Posted: Tue Dec 13, 2011 7:33 pm
by ElEctric_EyE
... 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.
Posted: Thu Dec 15, 2011 5:45 pm
by BigEd
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
Posted: Thu Dec 15, 2011 7:18 pm
by ElEctric_EyE
Correct... I wish I could make quicker progress. But the progress I have made I can say it is solid.
Posted: Thu Dec 15, 2011 10:37 pm
by BigEd
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
Posted: Fri Dec 16, 2011 2:03 am
by ElEctric_EyE
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.
Posted: Fri Dec 16, 2011 10:17 am
by BigEd
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.
Posted: Fri Dec 16, 2011 9:37 pm
by ElEctric_EyE
...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...
Posted: Fri Dec 16, 2011 9:44 pm
by BigEd
That would be great - thanks!