6502.org

Thanks! I think an updated head post as a status summary, and a bloggy continuation of puzzles and progress, is a good format that works well.

(I suppose it's best to mention in a new post when you make an update to the head...)

Cheers
Ed

Back in V1.0 I had reported success using a PLL to generate the 12MHz, from the 100MHz main clock, for the MCP 2200 USB to UART IC. I can report the same success here. Currently I am using a DCM to generate the 40MHz (ratio of 2.5) for the O2, and a PLL to generate the 12MHz(ratio of 8.3333..). It was good foresight to provide the 100MHz at mutliple pins to the FPGA on this V1.1, as the tools did not allow me to use a common 100MHz clock for the DCM and PLL.

So now I am at the point of successful graphics with keyboard (which was abit challenging!) input, and the Microchip config utility recognizing the MCP2200. Continuing today, I will try to add Arlet's UART and try sending data from the PC to the TFT. I would like to try to send characters through the use of the br@y terminal on the PC running Windows 7, as well as binary files in the form of different sized bitmap files. The 'drivers' library is growing...

Success with the br@y terminal sending ascii data running at 115200baud! Seeing correct values when typing on the PC keyboard.

Now onto sending a .bmp file. The only info I need from the header is the width and height, then simply plot the RGB data... Will post a pic of success soon!

After this I would like to solder in the serial FLASH and start working with it next.

Actually, before sending a .bmp file I'm trying to send a .txt file to fill up the TFT with ascii characters.

Arlet or BigEd or anyone, how can I do this without enabling interrupts?

I'm reading the status register and it is not changing it's value from $60 when data is being received. Is there an easy mod to your code to change a status bit after a byte has been received?

A link to Arlet's UART code has beenposted here.

Thanks!

EDIT: Please ignore my request, I see there are provisions for this bit. I noticed a problem in my software. Sorry, still working on it.

Looks like the status register ought to have bit 7 set when there's a valid byte to read, until you have read it.

Unless maybe you haven't connected the 'sel' input correctly? Maybe worth a quick simulation.

Cheers
Ed

Right, thanks Ed. So close I am!

I can say ISE13.2 is a serious step forward for Xilinx. I've used only 1 project file to advance this far. Even though I get crash recovery warnings now and then, they do not impede progress and ISE seems to correct itself after I decline the recovery.

Just an observation before I sign off for today.

Spent some time on it tonight, after a long day at work...

I did notice after some trial and tribulation, that A0 was very close to being connected in the schematic, but the red square I recognized immediately and thought back to what BigEd said. A0 was not connected!!!!!!!!!!! ARG!
I know it was connected at some point. The value did flicker when I was typing during earlier testing ...

I now see $E0 on the status register when I type on the PC keyboard. I'll have 3 consecutive days to devote to progress starting next monday.

great! It's always good when head-scratching gives way to that Aha! moment. It's good to hear progress about your system coming to life too. I'm not managing to do very much at system level.

Cheers
Ed

Sorry to hear that. I know you are against schematics, so I won't say anymore about making a top_level schematic to join your Verilog together...

So today I did some more experimentation transmitting Windows .txt files and .bmp files. Not so much success on the .bmp files yet, but I only spent a little over an hour on it at the end of the day.

I've completed the .txt file receive and display to TFT and the speed of it is quite respectable (it works at 256K baud!, as fast as br@y terminal will go), even when 8x8pixel characters are used for 100columns x 60 rows. It was cool to see a license file from a program I use displayed correctly.
The point of this excercise isn't just do display characters, it's to make sure data is being sent correctly which I can visibly see, and also to gauge the plotting speed @40MHz.

So, just FYI, after checking for a keyin from the local keyboard, my subroutine checks for an ascii $02h (start of text)/$03h (end of text), if it doesn't see it, it goes on to check for a $0F (shift in) for a .bmp file and reads a couple critical data values from the header from specific locations using a counter. In the future, when transmitting straight binary code I think $11h (device control 1) would be ok to differentiate from the other 2 file systems. So a slight modification to the files that need to be be sent is necessary, to place these values using a Hex editor.

Tomorrow I hope to have the .bmp file receive subroutine successfully completed.

After some experimentation and some googling, I've decided to quit trying to send .bmp's to the TFT through the UART. The beginning of pixel data is actually at the end of the .bmp file and it's also in BGR format. When I was sending data, the pic was showing up upside down and the colors weren't right as the TFT is currently set up for RGB data.
It's not a big deal as there's really no need for graphics on the TFT as I am just using it to develop drivers, and I am confident the USB to UART section is functioning 100%.

Recently I was looking at the datasheet for the 8Mb FLASH and it's something I don't want to get into right now.

I think it's time to test out HESMON in the software section of this project...

The Memory Map is solidifying so I decided to add it to the header.

EDIT (1/17/12): Added a 16-bit pseudo-random number generator which I copied from here.

I've got the next stage of the software portion of the project squared away and ready to go. HESMON, the NMOS 6502 MLM made for the C-64, being readied for the 65Org16. Most likely I will fail, but I look at it like this: I am blazing some trails. Don't get me wrong, I have not tried it yet. It is just that laboring over another's code is just that: a labor, and not necessarily a labor of love. I like to focus on hardware when I tire of it...

So I have got my eye focused on I2C now. 3 of the 4 DS1085 Frequency Generators need to have their addresses changed as they all come from the factory with an identical default address. After I successfully program 1, I will solder in the next, reprogram, etc...

Not only does the 65Org16 communicate with the 4xDS1085s through I2C, more importantly it also programs the CS4954 video encoder registers through the same I2C bus. And less important, the touchscreen controller for the TFT. The 8Mb serial FLASH is on a separate SPI bus.

So my hardware goals are like this for the very near future:
1) Conquer the I2C core
2) Program the new I2C addresses for the DS1085s
3) Program the CS4954 registers through I2C, hook up a monitor and watch
4) Use the pRNG to send pixel data to the CS4954
~~may tire of hardware at this point and go back to HESMON. Also, hardware testing of the board will be near its final stages (I hope)
5) Experiment with the SDRAM sending data to the CS4954

So I ask now (maybe prematurely):
Does anyone have some of their precious time to add to the development of this board? If I try to do it alone, it will take at least another year...

I have 2 left, currently untouched, of the V1.1 I am currently working on. 1ea for BigEd & Arlet.
I can afford 3 more. 1 ea for Bitwise and TT for their efforts on the 65Org16 assemblers.
I will provide these at no charge, however not all boards will be fully populated. Not everyone needs a TFT FFC connector etc...

I can have more boards made and populated at cost for other interested parties.

I hope I am going about this the right way, forgive me if I am not!

Hi EEye
I'm afraid I have other things going on for the next few weeks at least.

To recap your situation so far: you have the 65Org16 with block RAMs, talking to a host over UART and with the TFT display working OK.

The block RAMs give 2 areas of 1k for zero page, 4k of stack, 8k intended for 'ROM' and another 16k intended for 'RAM'. (There's enough block RAM for 32k 16-bit words in the LX9.)

You have space on the board for a 16M-word SDRAM but that's not yet explored. (For me, this is the most interesting thing to bring up! Especially since, in the worst case, it might mean another board revision...)

To bring up the SDRAM, what do we need: a board with FPGA, UART and SDRAM? Bruce's eForth or any custom test program would be enough to find the RAM and report back - we don't need a full monitor. If the SDRAM is troublesome, we might need a decent scope or logic analyser (I don't have these - just a very slow scope.)

But to interface with the SDRAM at all, I think we need some verilog effort to build a working SDRAM interface... which means some serious learning curve.

(Once I get some time free for 65Org16 again, I must have a try with my avnet microboard: it really ought to work, and that would then be a platform for trying out some software, such as Bruce's recent port of eForth. This board lacks the flexibility and expandability of yours, but has some advantage for a quick bring-up of a large memory.)

Cheers
Ed

Since I already have previous experience with SDRAM on FPGA, I'll volunteer to bring up the SDRAM on this board, starting with a simple direct CPU <-> SDRAM interface using RDY for wait states. I'll be busy with other projects, but I'll find some time in the weekend.

Excellent! Thanks!