6502.org http://forum.6502.org/ |
|
65Org16.x Dev. Board V1.1 using a Spartan 6 XC6SLX9-3TQG144 http://forum.6502.org/viewtopic.php?f=10&t=1978 |
Page 4 of 19 |
Author: | ElEctric_EyE [ Tue Nov 22, 2011 6:17 pm ] |
Post subject: | |
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... |
Author: | ElEctric_EyE [ Tue Nov 22, 2011 6:24 pm ] |
Post subject: | |
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. |
Author: | ElEctric_EyE [ Tue Nov 22, 2011 8:05 pm ] |
Post subject: | |
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. |
Author: | ElEctric_EyE [ Tue Nov 22, 2011 9:31 pm ] |
Post subject: | |
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... |
Author: | ElEctric_EyE [ Wed Nov 23, 2011 4:22 pm ] |
Post subject: | |
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... |
Author: | ElEctric_EyE [ Wed Nov 23, 2011 6:09 pm ] |
Post subject: | |
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 |
Author: | ElEctric_EyE [ Sat Nov 26, 2011 8:34 pm ] |
Post subject: | |
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. |
Author: | ElEctric_EyE [ Tue Nov 29, 2011 12:50 am ] |
Post subject: | |
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. |
Author: | GARTHWILSON [ Tue Nov 29, 2011 3:26 am ] |
Post subject: | |
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. |
Author: | ElEctric_EyE [ Tue Nov 29, 2011 12:34 pm ] |
Post subject: | |
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 |
Author: | Arlet [ Tue Nov 29, 2011 4:33 pm ] |
Post subject: | |
With 32 bit operands, and a 32 bit address space, at least you could get rid of absolute and absolute-indexed modes. |
Author: | kc5tja [ Tue Nov 29, 2011 6:26 pm ] |
Post subject: | |
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. |
Author: | BigEd [ Tue Nov 29, 2011 8:00 pm ] |
Post subject: | |
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 |
Author: | ElEctric_EyE [ Tue Nov 29, 2011 8:06 pm ] |
Post subject: | |
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! |
Author: | ElEctric_EyE [ Tue Nov 29, 2011 9:27 pm ] |
Post subject: | |
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 |
Page 4 of 19 | All times are UTC |
Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |