If you just look at the chroma, no. It's going to be closer to 100-150 "pixels" (more like blobs/smears). However, if you just like at luma (brightness), you can get 360 pixels, or even 720 pixels on a modern flatscreen TV/monitor.

Thankfully, when there's enough luma contrast, our brain doesn't notice the low chroma resolution.

I've just made a first version of a text screen generator. It's only black and white right now. It uses an 8x8 font, and is set for 720x288 resolution, of which only 640 pixels per line are used to get 80 chars per line. I'm using the CS4954 progressive mode, and sending identical even/odd fields. This reduces vertical resolution, but produces a much more stable image. Two block RAMs are used. One to hold the text screen, and the other one holding 256 bitmaps for the 8x8 font. An additional block RAM could be used to implement foreground/background color attributes. It's also possible to retrieve the text screen from SDRAM, but that requires some work on the SDRAM module.

Picture taken from TV. Even though you can't clearly see the individual pixels, the letters themselves are quite readable.



Edit: unfortunately, part of the 640 pixels are in the overscan area, and they aren't visible on my TV. Including a small border, I can get about 74 characters on a row.

Ah - I thought perhaps you'd already done this with your picture last Sunday
viewtopic.php?p=18437#18437

No, that was a very old picture, from when I just got my Spartan-3 starter kit. It's 640x480 resolution from a VGA interface, displayed on a real monitor (albeit an older CRT one), so the image is much sharper.

Added a green border, and took a picture of the whole screen. The border is fixed for now, but the goal is add a few programmable registers to set size and offset of the visible area, the border color, and the number of rows/columns of the text display.

Maybe look at the 6545 CRTC register set. That allows you flexible timing and would be compatible/understandable and docs and code would already be there.... No need to reinvent the wheel

André

This is up to Arlet or anyone else for that matter using the V1.1 Devboard. I have made the board with provisions to use a 6845 Verilog core (BigEd has pointed it out first). This means of course monochrome graphics. There is the ability to mix VSYNC+HSYNC+PIXELDATA on the V1.1 Devboard. I have provisions for 2 5K trimpots for VSYNC/HSYNC with PIXELDATA straight in for Composite Out.
But Arlet is working with color here so unless we use offboard videoDAC's, a 'standard' 6545 HDL core is not available for comparison.

I had never looked at the 6545, so after the suggestion I downloaded the datasheets. While I agree it's a nice idea to stick to a standard, I think the 6545 (or 6845) is a bit too limiting for what I had in mind.

I noticed a mistake in my text screen last night. There are more characters on the screen than will fit in the 2048 char block RAM, so the last couple of lines of text are identical to the first couple of lines. Since I don't want to allocate more than 1 block RAM, I'll have to reduce the amount of text on the screen. One way to do that is to put a small amount of space between the rows and/or columns. This will also increase legibility (but will mess up the semi-graphics characters)

No problem with not using the 6545/6845. It has been used in early PC graphics cards as well though.

And by using for example a wider data bus you can extend the feature set (e.g. reading multiple bytes per cclk cycle for more characters - this has been used in the Commodore PET for example to enable 80 columns with 1 MHz.)

you can even set it up for hi-res graphics, but the memory map quickly becomes complicated. though.

On the other hand, a 6545 core is available that can be (hopefully easily) extended to wider registers, thus having enough coordinate bits to support hi res graphics out of the box... and no need to create something from scratch (although that can be interesting...)

Sorry, I'm babbling, never mind :-)

André

Babbling is good here!. I like the 6845 Core as well. No doubt it can be extended for higher monochrome resolution. Maybe high speed 'scope or machine language monitor, namely Bruce's C'mon for 65Org16. Maybe I can work on this angle for the alternate out on Jumper 3 for composite out.

Actually, for me, the process of design is the most fun part. I don't really have any plans for when it's finished

I also like to try out new ideas. For instance, the BBC Micro had a Teletext screen mode (Mode 7). This is a special text mode which supports different text colors, but without sacrificing memory for per-character attribute bits (which would double the memory requirements). Instead, control characters where placed on the screen. They would all look like spaces, but would change the color of the text following it. The disadvantage is that you always need a space between different color text or graphics.

So, I was thinking about designing a mode where you can still put embedded control characters on the text screen, but they would be skipped by the video generator. So, you could have "<red>Hello<blue>World", and have it show up as "HelloWorld", where the first word would be red, and the second one blue, without a space inbetween. Instead of treating the screen memory as a 2-D grid of characters, the screen memory would be a 1-dimensional stream. However, once you treat the text as a stream, you can also use a proportional font, or insert other kinds of graphical elements, or move the cursor around. All of this would happen without a complete bitmap of the screen, so you could do this in limited memory, such as a 2KB block RAM. At every screen refresh, the hardware would be "racing the beam" to generate the entire screen dynamically.

First attempt with new "stream based" text display is successful. The stream is a single text string stored in block RAM (so it's limited to 2048 bytes right now). The stream consists of ASCII data mixed with control characters. Right now, the only supported control characters are carriage return <CR>, line feed <LF>, and the zero byte to indicate the end of the string.

As a test, I have loaded the stream memory with the string " <LF>Hello<CR><LF> World", and this is what it looks like:



The display that you see is rendered real-time based on the string contents, so if the 6502 modifies the string, the changes show up right away on the screen. I'm still using the 8x8 font, but now stretched out to 16x8 to make it more readable. As a next step, I'll try to add some color changes. Beeb owners may recognize the font...

Edit: Added some control codes to change the text color. I picked 8 random colors, but in theory you can have many more, even at the same time. For this version, I just picked some arbitrary control codes, but the rendering engine could be modified to understand the ANSI color codes for example.

I don't mean to sidetrack your progress, but I've been thinking.
Back here you said the performance of the SDRAM used for random access would be similar to a 6502 running at 14MHz. How about if we used synchronous RAM? The ones I've been looking at are very fast and have a common pinout from 512Kx18 up to 4MBx18 in a 100-pin QFP and range from $14 to $140 for those sizes.

I'm still planning to make a cache for the SDRAM, so it should be much faster in typical cases. Also, you'd probably want to use some separate block RAMs for cache, zero page and frequently executed and/or time critical parts of the code.

By the way, my next goal is to modify my text rendering engine to support a proportional font.

A text rendering engine! Awesome. Something you are doing in Verilog vs. what I did in 65Org16, 'cept mine was dedicated for TFT. I like it!

My mind continues to ponder a RAM board to keep up pace with a 100 MHz .b core and the onboard SDRAM is perfect for video experimentation, but...
We will run out of room in the internal BRAM eventually. I'm one step away from committing to develop a stackable board using Cypress 'pass through' 250MHz synchronous RAM. As many will fit on both sides of the board, same size as the DevBoard. They'll be designed for the max 4Mx18 size IC's, but can fit the many smaller devices Cypress has, in order to accomodate a budget. Plus all these RAM styles can be located within the 4GB memory space.

I can make 3 boards for $100 then just spend $15 for 1 IC for a test...