65C816 Handheld Planning

[GARTHWILSON]

Proxy wrote:

Ardis wrote:

Can the SPI interface handle 320x240 with 16-bit color at 60 frames per second? If so, I'd rather use that than the 18-bit parallel RGB LCD I'm currently using.

nope, sadly not. SPI is way too slow for that.
the Datasheet for the ILI9341 mentions that the maximum speed of the SPI interface is 10MHz, so transferring a whole frame of data will take ~122.8ms (~8 FPS).
when it comes to graphics you just need large bandwidths which means wide data buses or very high transfer speeds.

Note that that is a limitation of the ILI9341.  The SPI spec has no speed limits, and the last I saw, which was years ago, there were SPI devices that could handle an SPI clock of close to 200 MHz.

[gilhad]

Proxy wrote:

... datasheets being a bit too pessimistic.

Well, we are enthusiastic hobbyists, who goes "Wow, on my table (25 +/-2 C) with this one chip it works nearly all the time!", while manufacturer position is "per standard this and that I thereby claim and guarantee, that every single chip in full thermal range -40 to +85 C will every single time fullfill the paragraph 123.456 of the standard and will accept value anywhere from this point up as perfectly valid high input, under the risc of lawsuits" - so those ranges are usually where the manufacture is pretty sure, it would work in all conditions every time and rarely states much more, than standards, until it is selling point

[barnacle]

Exactly.

I have a commercial design which specifies a particular logic gate by manufacturer, exact part number with all the pre- and post-fixes. Not just the family and logic number... everything.

Other parts work, in testing. That part is guaranteed to. And I don't want to have to repair several hundred thousand a year when other parts fail.

Neil

p.s. to my knowledge, *none* of the devices have failed due to electronic failure. Mechanical failure, customer damage, water ingress, sure. But no electronic failures.

[Ardis]

Proxy wrote:

Ardis wrote:

Can the SPI interface handle 320x240 with 16-bit color at 60 frames per second? If so, I'd rather use that than the 18-bit parallel RGB LCD I'm currently using.

nope, sadly not. SPI is way too slow for that.
the Datasheet for the ILI9341 mentions that the maximum speed of the SPI interface is 10MHz, so transferring a whole frame of data will take ~122.8ms (~8 FPS).
when it comes to graphics you just need large bandwidths which means wide data buses or very high transfer speeds.
so like said if you want to actually get 60 FPS you have to use atleast the 8-bit parallel interface at pretty high speeds, or the 16/18-bit one at half the speed of the 8-bit interface.

Ardis wrote:

I'm trying to avoid relying on things that are too modern like a MicroSD card. I intend to have a flash memory chip to hold the firmware since I have a GQ-4X programmer already.

that's a bit of a confusing statement, µSD cards are almost 30 years old at this point, and both very cheap and easy to interface. you yourself wanted to use SPI for the display which has an equally if not more modern LCD controller on it, so why draw the line at storage?
and yea i would recommend using Flash chips for the boot code of the system. and if you give the CPU access to the ~WE pin on them you can have the CPU reprogram its own boot ROM, which can be risky but also pretty convienent as you then don't need use an external program to update the ROM.
though still having some form of storage would be a good idea, being able to load, store, and transfer files conveniently between your system and a PC can be very useful for software development.

Ardis wrote:

There will be voltage regulators changing voltage on things due to no combination of parts I'm looking at settling on a single voltage, so I suspect I'll have voltage lines for 1.8V (or whatever the FPGA needs), 3.3V and 5V going through the board.

what other parts do you have planned that would require up to 3 different voltages?
basically all FPGAs i know of can run at 1.8V-3.3V, the ILI9341 specifically needs 3.3V, cheap SRAM, Flash/ROM chips are also available for 3.3V, and the 65xx have a voltage range of 1.8V-5V.
so unless i'm missing something, you should be able to just run the whole system with only 3.3V.

Some of the SRAM and flash memory I was looking at was 3.3V, but I probably won't use them to keep the voltage lines simpler. Again, the only part that is set in stone here is the 65C816 at its heart. I'm trying to come up with a list of parts that meets my needs before making any purchases for this project. I'm trying to steer things more to a split 1.8V/5V setup with only the FPGA video chip being on the 1.8V, but 5V parts get harder and harder to find as time goes on.

There's a few reasons I want to lean away from the MicroSD card. Part of it is that I want it to function like a 16-bit handheld from the mid-to-late-90s. You didn't have electronics with their firmware on a removable microSD card. Maybe some high end cameras had them as storage, but not firmware. The other reason I'm leaning away from MicroSD is cost. A flash memory chip with more than enough storage for what I think the firmware will look like is maybe a dollar. The smallest MicroSD card I can buy from a reputable dealer/manufacturer? $4 before you factor in additional complexity, and possibly hardware, needed to take that serial data and read it into parallel data for the 65C816. I'd rather just keep everything on parallel storage. Early prototypes will be on a flash chip either in a DIP package or on a DIP adapter so I can remove it from my breadboard and slot it into my programmer for quick rewrites. Once I move onto PCB prototypes, I intend to have headers for reprogramming the firmware flash chip and the video FPGA if I don't put them in ZIF sockets.

If the ILI9341 is too slow to handle 320x240@60 FPS with 15 or 16-bit color, then I'll have to find a different LCD driver chip, I would assume. It sounds like my options are either purchasing one with a different driver or purchasing the display and driver separately so I have a suitable one in my project.

[Ardis]

Does anyone know if the ILI9341 would be able to handle the target of 16-bit color (65,536 colors) at 60 fps if all it's being sent is pixel color and a clock signal from the FPGA? If not, can someone show me how to tell which ones can so I can start looking for another LCD? I'm looking at other options now, especially after spotting a few cheaper 3.2" LCD that use different controller ICs and 3.5" ones that are decently priced if nothing else in the project pushes the budget.

ST7789V, ST7272A, HX8238 and HX8347A are the driver ICs on the screens I was looking at, but I'm not sure where to look to see which ones can handle the 60 FPS goal.

[Yuri]

GARTHWILSON wrote:

Proxy wrote:

Ardis wrote:

Can the SPI interface handle 320x240 with 16-bit color at 60 frames per second? If so, I'd rather use that than the 18-bit parallel RGB LCD I'm currently using.

nope, sadly not. SPI is way too slow for that.
the Datasheet for the ILI9341 mentions that the maximum speed of the SPI interface is 10MHz, so transferring a whole frame of data will take ~122.8ms (~8 FPS).
when it comes to graphics you just need large bandwidths which means wide data buses or very high transfer speeds.

Note that that is a limitation of the ILI9341.  The SPI spec has no speed limits, and the last I saw, which was years ago, there were SPI devices that could handle an SPI clock of close to 200 MHz.

The ILI9341 has a parallel data interface as well as SPI; you can use one or the other. I have successfully connected one of the prebuilt modules from AdaFruit to the 6502's data bus, the only extra component I needed was a '245 to actually put it's data lines into a tristate when my 6502 wasn't directly reading/writing to the device.

I haven't done any speed tests on it yet, but I was able to get it to respond to initialization commands and light up a pixel, w/o any fuss. I'm currently running my 6502 at about 6.3Mhz, the timing diagrams on the data sheet (if I'm reading them correctly, which I may not be) suggest it's happy to go up to about 12Mhz when being used in it's "8080 I/II" parallel mode.

The module I'm using

[Proxy]

Yuri wrote:

The ILI9341 has a parallel data interface as well as SPI; you can use one or the other.

that's exactly what i said, but Ardis specifically asked about the SPI interface after i mentioned that the ILI9341 had both because they wanted to avoid using a very wide interface (even though it also has an 8-bit wide interface which is a lot easier to deal with than the 18-bit one they mentioned and is highly recommended over SPI for HW/SW overhead reasons)

Yuri wrote:

The module I'm using

ey, i also linked to the same board from adafruit (or rather a similar variant)

[Yuri]

Proxy wrote:

Yuri wrote:

The ILI9341 has a parallel data interface as well as SPI; you can use one or the other.

that's exactly what i said, but Ardis specifically asked about the SPI interface after i mentioned that the ILI9341 had both because they wanted to avoid using a very wide interface (even though it also has an 8-bit wide interface which is a lot easier to deal with than the 18-bit one they mentioned and is highly recommended over SPI for HW/SW overhead reasons)

Yuri wrote:

The module I'm using

ey, i also linked to the same board from adafruit (or rather a similar variant)

Odd, not sure why you would want to constrain yourself to SPI if the parallel mode is easier to use and faster.

[Ardis]

Yuri wrote:

Proxy wrote:

Yuri wrote:

The ILI9341 has a parallel data interface as well as SPI; you can use one or the other.

that's exactly what i said, but Ardis specifically asked about the SPI interface after i mentioned that the ILI9341 had both because they wanted to avoid using a very wide interface (even though it also has an 8-bit wide interface which is a lot easier to deal with than the 18-bit one they mentioned and is highly recommended over SPI for HW/SW overhead reasons)

Yuri wrote:

The module I'm using

ey, i also linked to the same board from adafruit (or rather a similar variant)

Odd, not sure why you would want to constrain yourself to SPI if the parallel mode is easier to use and faster.

To be honest, I don't remember my reasons for preferring to use SPI outside of reducing the number of pins in use on the FPGA (keeping cost down) and possibly being under the impression (at the time) that SPI was the better interface.

If parallel can give me the color bit depth at the framerate I want (15-bit or 16-bit color at 60 FPS), then I'll go with it.

[Yuri]

Ardis wrote:

If parallel can give me the color bit depth at the framerate I want (15-bit or 16-bit color at 60 FPS), then I'll go with it.

The color depth shouldn't be any different between the two. The real difference is if you're going to be trying to send all the data down a serial interface or a parallel one.

That being said, at 320x240 @ (15)16/bpp @ 60 FPS, you're looking at around 9MiB/sec of data. That's going to be awfully close to the max of what SPI presumably can do. (But there's no standard, so estimates of the max throughput vary wildly it seems)

That's still a lot of bandwidth to shove down a parallel interface, but at least then the clock speed wouldn't need to be as high.

(Higher clock speed == more power consumption == less battery life? Something else to consider?)

[AndrewP]

Throwing out a couple of thoughts:

As you're using an 8bit data bus I'd imagine the fastest way to communicate with an LCD would be via that 8bit bus. I know I've seen LCD displays that use a parallel interface but it's not something I've ever looked into so they might be quite expensive or just not match the 816's architecture nicely.

I bring up speed because even 320x240x16bpp @ 60fps is lot of data for an '816 to handle unassisted.

Let's say you're running 14MHz at 320x200x8bpp. The '816 - using block move instructions - will just barely be able to draw an entire frame 30 times a second. Crossing to more than 320x200 (say 320x240x8) means that the video memory is going to be split over two banks. And that's adding more complicated calculations to a CPU that's already only barely keeping up.

All is not lost though. The 816's block move instruction takes 7 cycles per 8bit pixel whereas if you use a dedicated hardware blitter you could get that down to 2 (or even 1) cycles per pixel. You can also use a colour palette if you want to keep 16bit or even 24bit colour but also still keep a pixel width of only 8bits.

For a preliminary build I'd suggest 320x200x8 is a really good starting point.

Ardis wrote:

Makes the full 24-bit address bus of the 65C816 available to software developers (currently using the de-multiplex setup suggested in the 65C816 datasheet, but it might not be suitable for higher CPU speeds)

I wouldn't worry about the time it takes to capture the 816's bank address. Plenty of logic families have latches that have sub 10ns propagation times. I use LVC in a 3.3V setup but you could use AC or similar if you're running with a 5V setup. Probably AHC is what you're looking for if HC seems too slow.

Personally I fully intend to take Plasmo's 40MHz crown with an 50MHz '816 with the complete 24bit bus available. But that's just smack talk for now as I keep running into problems

[Yuri]

AndrewP wrote:

Personally I fully intend to take Plasmo's 40MHz crown with an 50MHz '816 with the complete 24bit bus available. But that's just smack talk for now as I keep running into problems

*wonders how the poor CPU doesn't just catch fire at that speed*

I'd like to do my own retro gaming system and I'm shooting for about the same resolution (320x240 @ 15bpp), however, my plan is to use an FPGA to develop something along the lines of an SNES PPU.

My sprites and tiles would likely all still use a single byte per pixel. (Being relatively small in size, I foresee a single byte for a whole title/sprite selecting a palette bank)

This of course all works well if you're sending the pixel data down a VGA interface. (I think the OP was suggesting maybe doing that? Not sure how that works in a small LCD form factor.)

Of course the other part of what made the SNES really shine was that it had several different buses and a lot of different DMA operations that would go on during the blanking intervals of the picture.

[barnacle]

Depending on your LCD you may not need to update the entire picture display in one burst: if it has its own ram on board, and therefore doesn't need an ongoing memory transfer across the bus, then you have the option of updating only what has changed between frames.

[AndrewP]

I had a brief look at the ILI9341 datasheet and it might not be a great fit for an address bus based CPU. It's not a bad fit but there's a bit of work that'll need to be done to interface it to the '816.

If it were me I would map it to two address XX:XXX0 and XX:XXX1 where address zero is the command pin low and address one is the command pin high (i.e. Address A0 tied to D/CX). I would tie the result of address decoding XX:XXX0 and XX:XXX1 to the ILI9341 chipselect CSX.

The problem signals are read (RCX) and write (WRX). Both are rising edge triggered and that means that write data has to be ready before WRX rises. If you already have the active low signals /WB and /RB generated from RWB then it might be enough to use the tail end of /WB as it goes high again. Read is also tricky because the data must be valid on the databus before PHI2 falls again and typically that would be at the tail end of /RB. Which means you can't use /RB for reading. You might have to invert it and use RB instead.

There's also the question of how to take the data that the ILI9341 is writing to the data bus off the data bus once a read is complete. You'll almost certainly need to put it behind a bus transceiver. Possibly something like 74xx543 registered bus transceiver might be more useful than the normal 74xx245 bus transceiver as the '543 could continue to hold data that the '816 has written after PHI2 has fallen. It looks like the ILI9341's write timing (i.e. how long the data has to be held on the bus for the ILI9341 to read it) is a bit to slow.

Finally there is the question of how - once all the hardware is setup - is software going to be written to write pixels to the ILI9341 fast?

Setting up the 'window' on the LCD for writing a (non-transparent) sprite is easy enough using the set column and set page commands. And the initial write command (which the documentation sometimes calls 'write' and sometimes calls 'write start') is fine. But how to optimally read from multiple contiguous addresses (the source pixels) and write them repeatedly to a single address (XX:XXX1)? The block move instructions can't help in this case.

Yuri wrote:

*wonders how the poor CPU doesn't just catch fire at that speed*

WDC have made a wonderfully efficient chip int the '816. Even at ridiculous clock speeds it barely draws any current. I may have completely misremembered but I think the CPU was only drawing 40mA at 36MHz. The rest of the board was ... not so frugal.

[Yuri]

AndrewP wrote:

I had a brief look at the ILI9341 datasheet and it might not be a great fit for an address bus based CPU. It's not a bad fit but there's a bit of work that'll need to be done to interface it to the '816.

If it were me I would map it to two address XX:XXX0 and XX:XXX1 where address zero is the command pin low and address one is the command pin high (i.e. Address A0 tied to D/CX). I would tie the result of address decoding XX:XXX0 and XX:XXX1 to the ILI9341 chipselect CSX.

This is effectively what I did on my setup.

Quote:

The problem signals are read (RCX) and write (WRX). Both are rising edge triggered and that means that write data has to be ready before WRX rises. If you already have the active low signals /WB and /RB generated from RWB then it might be enough to use the tail end of /WB as it goes high again. Read is also tricky because the data must be valid on the databus before PHI2 falls again and typically that would be at the tail end of /RB. Which means you can't use /RB for reading. You might have to invert it and use RB instead.

There's also the question of how to take the data that the ILI9341 is writing to the data bus off the data bus once a read is complete. You'll almost certainly need to put it behind a bus transceiver. Possibly something like 74xx543 registered bus transceiver might be more useful than the normal 74xx245 bus transceiver as the '543 could continue to hold data that the '816 has written after PHI2 has fallen. It looks like the ILI9341's write timing (i.e. how long the data has to be held on the bus for the ILI9341 to read it) is a bit to slow.

Interesting,

I had tried to contend with those issues myself, bending over trying to get a circuit that would get the timings right. On a lark I connected the RD/WR pins straight to my 139's PHI2 qualified RWb/WRb pins, and it just worked.....

I did need a 245 because for some strange reason it always wants to assert itself on the bus. Even when you aren't actively doing something with it.

Quote:

Finally there is the question of how - once all the hardware is setup - is software going to be written to write pixels to the ILI9341 fast?

I haven't admittedly gotten that far just yet; just drawing one pixel and checking to see if I can just initialize the thing. When I was going through the source code for how the Arduino driver sends commands to it I did notice a lot of extra delays (presumably to get the hardware timings right from the Arduino to the ILI9341)