6502.org • View topic - 65Org16.x Dev. Board V1.1 using a Spartan 6 XC6SLX9-3TQG144

View unanswered posts | View active topics

Board index » 6502.org Users Forum » Programmable Logic

All times are UTC

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

Page 4 of 19

[ 271 posts ]

Go to page Previous 1, 2, 3, 4, 5, 6, 7 ... 19 Next

Print view

Previous topic | Next topic

Author

Message

ElEctric_EyE

Post subject:

Posted: Tue Nov 22, 2011 6:17 pm

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA

Arlet wrote:

...if you want to clock external devices with the same clock as your internal clock, you need to bring that out with a DDR FF, and the rest of the signals with regular FFs.

Yes, I've done what you suggested and it appears to clear the screen MUCH faster than I've seen at similar 20MHz speeds on the Spartan 3. Maybe my timing was off using the Spartan 3?, more experimentation will tell. But at this point I am able to change colors from green to blue (for some reason not red, red is blue), by changing variables in my clear screen routine.

I'll have to do more testing, it is not 100% yet. I am changing some other variables now like the length of bytes it sends to the TFT, so it should clear everything on the screen down to the last controlled block of data, to ensure the correct amount of data is being sent. Still testing...

Also, for some reason, when I try to do a SIM of the project, it gets stuck in a loop and I cannot halt it. I have remembered to comment out the 'ifdef SIM' & 'endif' statements when trying to run a SIM. Still testing...

Top

ElEctric_EyE

Post subject:

Posted: Tue Nov 22, 2011 6:24 pm

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA

AH! Now I am in business with ISim! I forgot it does not synth the DCM without extra measures...

Also, Red data works. I must've forgot to update the ROM in my excitement.

Focusing on the amount of data being sent right now, seems to be exceeding the boundary of the display for some reason.

Top

ElEctric_EyE

Post subject:

Posted: Tue Nov 22, 2011 8:05 pm

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA

It is working correctly after all! My timing must have been off in my old designs when I was experimenting with the Spartan 3.

I've modified the 8-bit CLRSCR to be 16-bit now. The speed at which the TFT is clearing @20MHz is like when I had it running @38MHz! The TFT is actually rated @50MHz, but with the 7.5ns prop delay of the Spartan 3 it could only run @38MHz. I'm sure with the Spartan 6 I can run reliably @40MHz.

Just FYI, ISE13.2 Timespec is showing a delay of O2Internal @13.9ns and top speed of 71.9MHz, with a 4Kx16 zero page, 4Kx16 stack, and 16Kx16 ROM. No other cores are present yet.

Also, I tried hooking back up the reset line on the MCP2200 (USB to UART) without the USB cord plugged in providing power, and it does indeed fowl the Reset circuit. I will just tie it high with a pull-up and hope it works correctly when the time comes to test it.

Here's the new 16-bit TFT CLRSCR routine. I am unsure why I have to increase the 'Y' value to 5:

Code:

CLRSCR:   PHA
      TXA
      PHA
      TYA
      PHA
      LDA #$2A   ;set x address
      STA DCOM
      LDA #$00   ;start
      STA DDAT
      LDA #$00
      STA DDAT
      LDA #$02   ;end
      STA DDAT
      LDA #$7F
      STA DDAT
   
      LDA #$2B   ;set y address
      STA DCOM
      LDA #$00   ;start
      STA DDAT
      LDA #$00
      STA DDAT
      LDA #$01   ;end
      STA DDAT
      LDA #$DF
      STA DDAT
   
      LDA #$2C   ;prepare to send display data
      STA DCOM
      LDY #$05   ;4?x65536=640X480=307,200 pixels
AA:   LDX #$0000
AB:   LDA SCRCOL1
      STA DDAT
      LDA SCRCOL2
      STA DDAT
      LDA SCRCOL3
      STA DDAT
      DEX
      BNE AB
      DEY
      BNE AA
      PLA
      TAY
      PLA
      TAX
      PLA
DONE:      JMP DONE

My current list of immediate priorities:
1) Try to increase O2 to 40MHz.
2) Add back in Arlet's improvements for his 6502 core, 1 mod at a time and retest the 65Org16.b core.

Top

ElEctric_EyE

Post subject:

Posted: Tue Nov 22, 2011 9:31 pm

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA

While trying to approach higher speeds for O2, I noticed behavior would change when I put my finger close to the Reset button, which is on the opposite side of the DS1818. This is leading me, once again, to focus on the Reset circuit as correct operation was not observed above 24MHz... I guess I got lucky picking an arbitrary 20MHz starting point.

Right now I have no external pullup on the Reset line. Tomorrow I will experiment and add a 1K external pullup, as suggested on the DS1818 datasheet. Maybe retry connecting the unpowered MCP2200 Reset...

Top

ElEctric_EyE

Post subject:

Posted: Wed Nov 23, 2011 4:22 pm

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA

After adding a 1K pull-up and reconnecting the MCP2200 Reset, the system seems to run properly at ~28MHz max((100MHz/7)x2), anything faster and the TFT does not init properly...

Next I would like to add in the software that displays characters and add in Arlet's UART core, and the PS2 keyboard core. Then test 2 unidirectional terminals, the local keyboard plugged into the PS2, and the remote terminal from the PC going through the MCP2200 USB to UART utilizing the Br@y Terminal. I was able to get a 12.5MHz to the MCP clk, close enough, although the baud rate may be skewed abit. The Tx & Rx LEDs were lit...

Top

ElEctric_EyE

Post subject:

Posted: Wed Nov 23, 2011 6:09 pm

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA

This bit of software is what I have made, back in May 2011, for the 6502SoC to display a character with the PLTCHR routine when reading keypress data from the PS2 Core, no interrupts.
Before calling that routine however, I made it so that I had to preset some variables using the ATTBUTE routine. Neat graphics stuff, I really enjoyed writing it...

With 8 more bits available, using the 65Org16 as the processor, I look forward to do even more with this routine. I can definately use different X and Y sizes, which I had originally sacrificed for other bit settings. I see though, most free bits will be devoted to color.
Attribute Routine (Call 1st)

Code:

ATTBUTE   LDA chrattr   ;get color from bits 0,1,2,3
   AND #$0f   
   ASL
   ASL      ;multiple by 4 for easy indexing
   TAX
   LDA coltable,x
   STA pxlcol1
   INX
   LDA coltable,x
   STA pxlcol2
   INX
   LDA coltable,x
   STA pxlcol3
      
   LDA chrattr   ;check bits 4,5,6 for size
   AND #$70
   LSR
   LSR
   LSR
   LSR      ;make size 1x through 7x, no size 0!   
   STA xwidth
   STA ywidth
   
   LDA chrattr   ;check font bit 7, 1=C64 , 0=3x5
   AND #$80
   CMP #$80
   BEQ n64
   LDA #$08   ;C-64 8x8 Character set
   STA chrxlen
   STA chrylen
   LDA #$e0   ;starting @ $e000
   STA chrvecH
   JMP porc
n64   LDA #$04   ;3x5 character set
   STA chrxlen
   LDA #$05
   STA chrylen
   LDA #$e5   ;starting @ $e500
   STA chrvecH
   
porc    LDA PE      ;test PE for plot or clear
   BNE plot2
   LDA scrcol1
   STA tmpcol1
   LDA scrcol2
   STA tmpcol2
   LDA scrcol3
   STA tmpcol3
   RTS
plot2   LDA pxlcol1
   STA tmpcol1
   LDA pxlcol2
   STA tmpcol2
   LDA pxlcol3
   STA tmpcol3
   RTS

Plot Character (Call 2nd)

Code:

PLTCHR      LDA #$2c   ;PLTCHR
      STA dcom
      PHA      ;Plot Character Subroutine variable (1-7) H and V size
      TYA      ;save all reg's
      PHA
      TXA
      PHA       
      
CACALC      LDA chrvecH   ;CACALC Character Address Calculate Subroutine
      PHA
      CLC      
      LDA chr      
      LDY #$03   
shift3      ASL      ;multiply character by 8 to get char pointer LSB
      DEY      
      BNE shift3   
      STA chrvecL   
      CLC      
      LDA chr   
      LDY #$05   
shift4      LSR      
      DEY      
      BNE shift4   
      TAX      
      BEQ ninc   
cph2      INC chrvecH   
      DEX      
      BNE cph2   
ninc      LDY #$00   ;vertical bit count
loop7      LDX ywidth   
loop4      TXA
      PHA

      CLC
      LDX #$00   ;horizontal bit count
      LDA (chrvecL),y   ;character data addr, $E000(c64) or $E500(3x5)
loop5      ASL      ;Shift left
      BCC nonpxl   ;branch on no bit
pxl2      PHA      ;save character data
      TXA
      PHA
      LDX xwidth   
xwp      LDA tmpcol1   
      STA ddat   
      LDA tmpcol2   
      STA ddat   
      LDA tmpcol3   
      STA ddat
      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   ;load RED background color
      STA ddat   
      LDA scrcol2   ;load GREEN background color
      STA ddat   
      LDA scrcol3       ;load BLUE background color
      STA ddat
      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   
      BNE loop7   
      
      PLA      ;reset character pointers
      STA chrvecH   
      LDA #$00   
      STA chrvecL   
      PLA      
      TAX
      PLA      ;reload all reg's
      TAY
      PLA      
      RTS

Top

ElEctric_EyE

Post subject:

Posted: Sat Nov 26, 2011 8:34 pm

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA

I'm in the middle of converting the PLTCHR routine. Immediately I see I can dispose of the byte manipulations for the CACALC routine, where I have to multiply a character inputted by 8 in order to index the pixel data. With the 65Org16, I can multiply up to 8192 by 8 and not have to use indirect indexed mode. I won't be approaching anywhere near 8K here though. If I didn't need the precious block RAM, I would consider using a 16x16 character set. Maybe in time I could store it in FLASH, when I get the SPI core working.

EDIT: Also I see some corrections I need to make on the original 6502 PLTCHR routine.
First mistake at the very beginning, where an LDA/STA was erroneously done to the TFT register before pushing Accumulator, X, & Y values onto the stack.

Second mistake is using a BNE loop to do a x8 multiply in a graphics routine. It needs to be as fast as possible, so instead of the loop, I will do consecutive ASL, ASL, ASL.

Top

ElEctric_EyE

Post subject:

Posted: Tue Nov 29, 2011 12:50 am

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA

As I wrestle just abit with indexing issues (my brain slowly flexes into software mode...), converting my original code from 8bit data - 16bit address to 16bit data - 32bit addresses, it occurs to me why some people here on this forum are keen on a contiguous 32bit structure , i.e. 32bit data and address buses. There would be no need for indirect indexed mode, which while an asset for limited 8-bit machines, maybe also an asset for 16-bit machines, but unnecessary for 32-bit machines (assuming 4GB is enough addressable memory?).

I cannot pursue this right now, however I would like to pursue this 65Org32 Core in due course, based on BigEd's original mod of Arlet's NMOS 6502 Core, the mod's for 32bit operation should not be too difficult.

The reset/IRQ/NMI vectors would have to be adjusted for the 32bit structure optimally. Also, the upper 32bits of the 64bit address lines would have to be truncated, as there is no need for 2^64 memory yet. Also, eliminating all indirect indexed mode opcodes may actually speed up top speed of a 65Org32 Core...

In a software routine to plot pixels, if a 32-bit index register could be directly transferred to a 32-bit memory location, especially with a max of 4GB worth of pixels, I can see the value in it, most definately. This would cover a large resolution when sending "bytes" to a display of the sort I am working on currently.

Also, I am trying to find a thread where kc5tja had posted his thoughts about extending the 6502 architecture, and very astutely pointed out that for 16bit byte and 32bit bytes the 6502extended CPUs would waste a certain percentage of bits during translation... Still trying to find the link to that thread.

In the mean time, this in another interesting thread.

Top

GARTHWILSON

Post subject:

Posted: Tue Nov 29, 2011 3:26 am

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8432
Location: Southern California

It seems like you would still need indirect indexed addressing. I don't think of it being tied to the fact that the data bus and registers are only half the width of the address bus. It is especially helpful for accessing data whose location is not known until the time the program is running. I suspect André Fachat made much use of it in his GeckOS for 6502 with multithreading and dynamic memory management. Hopefully he will see this and speak up. It would be nice to not have the base address limited to a 256-byte page; and having 32-bit everything means all 4 gigawords of address space are in zero page, so to speak.

Top

ElEctric_EyE

Post subject:

Posted: Tue Nov 29, 2011 12:34 pm

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA

I see there would still need to be an indirect indexed mode (I'm done wrestling with this fact on a certain portion of my code, I realize I need it). But there would be an issue with indirect indexed if you truncate the upper 32 address bits and kept the NMI/RES/IRQ vectors @ $FFFFFFFA-$FFFFFFFF.
Maybe a program that didn't pay attention to this limitation would just wrap around the memory, which would be a tolerable side effect IMO.

EDIT: would not wouldn't

Last edited by ElEctric_EyE on Tue Nov 29, 2011 4:52 pm, edited 1 time in total.

Top

Arlet

Post subject:

Posted: Tue Nov 29, 2011 4:33 pm

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands

With 32 bit operands, and a 32 bit address space, at least you could get rid of absolute and absolute-indexed modes.

Top

kc5tja

Post subject:

Posted: Tue Nov 29, 2011 6:26 pm

Joined: Sat Jan 04, 2003 10:03 pm
Posts: 1706

GARTHWILSON wrote:

It seems like you would still need indirect indexed addressing.

Why?

Nearly all contemporary RISC processors make due with exactly two addressing modes: Ra+Rb and Ra+offset, of which Ra+offset is used far more often. Many RISC processors don't bother with implementing the Ra+Rb mode, such as MIPS.

The Ra+offset mode would translate into direct-page-indexed (e.g., dp.X or dp,Y) in the 65xx architecture. I'm curious to learn where the extra level of indirection would prove especially useful.

Top

BigEd

Post subject:

Posted: Tue Nov 29, 2011 8:00 pm

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10797
Location: England

I've started a new thread, as this seems like a good but separable discussion.

(Feel free to re-post in there, especially if my summary isn't adequate)

Cheers
Ed

Top

ElEctric_EyE

Post subject:

Posted: Tue Nov 29, 2011 8:06 pm

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA

Thanks for doing that Ed! I am about to post some progress on some code I previously posted, which I modified and successfully tested for the 65Org16 today, but also did not want to take away from a useful discussion of the 65Org32. Now we all can continue!

Top

ElEctric_EyE

Post subject:

Posted: Tue Nov 29, 2011 9:27 pm

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA

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:

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

Top

Page 4 of 19

[ 271 posts ]

Go to page Previous 1, 2, 3, 4, 5, 6, 7 ... 19 Next

Board index » 6502.org Users Forum » Programmable Logic

All times are UTC

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum