6502.org

that is some awesome progress!

but i think it's time for a test image, something complete you can throw at it that you know how it's supposed to look so you can see if it actually works as it should.

but before i can go into detail i kinda need to clearify how (i think) the drawing works.
basically you're throwing a 256x128px image at the screen, but only a 200x128px part of that is actually visible. (technically this means you could "easily" implement smooth horizontal scrolling)
so what you need is a Binary file that contains pixel data (1 bit per pixel) for a whole 256x128 image, so it lines up with the screen.

anways, to the process i went through to make this:
using GIMP i made an image 256x128, marked the 200px point so i know where the screen ends, and changed the mode to 1 bit indexed color mode. which only gives me Black and White but that is all i need.
i then drew this image: you can see the arrows in the corners, that is where i expect the visible screen to be.
I just threw random things at it to test basically everything you would ever want to throw on the screen. (aside from interactive/moving stuff)

I then exported the image as a XBM File. this basically takes the whole data of the image and converts it into a C compatible Array, with each line of 8 pixels (from top left to bottom right) being listed as a byte.
though note 2 important notes about that.
1. GIMP stores white pixels as 0, and black pixels as 1.
2. GIMP stores the byte in reverse order. so the order of the pixels on screen from left to right is: 0 1 2 3 4 5 6 7. and they get stored reversed to that as: 7 6 5 4 3 2 1 0

using that Array i extracted the pure data from it via Notepad++ and some search&replace functions (removing spaces, 0x-prefixes, commas, etc) and loaded that into my simulated VGA circuit
and this was the result: pretty good i'd say.

i also converted this image to a pure binary format. so that you can try it out yourself. (i hope your EEPROM programmer supports .BIN files, it should)
I actually made 2 files. one has just all bits in each byte in inverted order.
because i don't know the order that you put bits on the screen.
which do you do?
is the first bit (bit 0) of the byte drawn first on the screen, or is the last bit (bit 7) drawn first?
if it's the first bit you basically need to mirror all your text/letters/symbols that you want to display.

anyways, here the files:
bit 0 first
bit 7 first

This sounds like the sort of trouble that results when using a shift register with asynchronous load, such as the 74xx165. It's possible to reduce those symptoms, but doing so is a fussy business and you're unlikely to achieve 100% success. Of course, the results you're presently getting may be good enough, and I understand if you're reluctant to modify the circuit. But FYI others have recovered from this situation by switching to a '166 instead, as in this example. The goal is for each group of 8 pixels to seamlessly align with the neighboring groups (and with the left and right borders). Other synchronous load options include 74xx299.
-- Jeff

Thanks for your efforts. I've programmed your image in a ROM, and works as expected, see attached. There are a couple artifacts, that's because I'm using a defective ROM from ebay. Some addresses can't be reliable written to. But that means that I don't care much if I bend its pins during experimentation.
I am shifting bit 7 first. It just seems more natural to me to see the bits from MSB to LSB on the screen. Although I've gotten used to reading 8 bit values in reverse order while building my CPU...
I see. Dieter also uses a '166 on his D04 CRT/LCD controller. I've seem others do it with a 165 shift register and I now wonder how are they getting away with it. I could get the timing almost right by adjusting a pot in an RC network so I could not tell where the divisions between bytes were. But as you say, its fussy business and not very elegant. As I don't have any '166s at hand, and continuing with my approach of "trying to make progress during holidays with the parts at hand because I won't be able to do later...", extending the shift register with an external flip-flop clocked by the pixel clock makes everything work fine with no tricky adjustments. I may pop in a '166 later, this whole thing is "experimental" any way.

Juan

Some updates:

The video card is "finished" and working. I had to make a couple modifications here and there regarding RAM setup time, and now works as designed, fully asynchronously with respect to the CPU clock. I've just wrote a simple program that clears some of the screen and prints an "A", byte by byte. Running it at KHz clock speeds, writes to screen RAM can be seen in real time. At a MHz, I think it'll be fast enough.

Colours are hard-wired as of now. I may add a register that sets foreground and background colours for the whole screen or line by line. But that's just aesthetics. I'll add some proper, power, PS/2 and VGA connectors on the back (and leave some space for a DB-9) when they arrive, and then I can use a VGA cable instead of the mess of hanging wires I have now...

I now have to write subroutines for character output, scrolling and such. I thought about using PETSCII, but that would require 2K of ROM, and a look-up table to translate from ASCII. So I may use something like the ATASCII (https://en.wikipedia.org/wiki/ATASCII) character set, with printable characters matching ASCII, and "semi-graphic" characters on the control codes.

I'd like to write a machine-code monitor of some sort. With only 25 characters per line, showing an address followed by 8 bytes with spaces between them is impossible, unless I use 4x8 characters that is. One solution could be using alternating normal and inverse characters. So I have a use for those.

Just some thoughts. There is definitely a lot to be done.
Juan

Great progress, good to see it working!

about the character set, i would recommend just going with 7 bit ASCII, that would mean you only need 1k of ROM for the whole character set. at the expense of more characters.

i made this a while ago for my own video chip. it's completely ASCII compatible, but the special characters have been reused for some graphical symbols. now about the routines, i would recommend just having each character stored as 8 consecutive bytes in the ROM. it makes reading the character a lot easier.
another reason is that it works perfectly with the Binary Image i made of that character set!
i call it "Modified ASCII" or just "MASCII".
DROPBOX

it took me like an hour to convert that 1 bit image into that binary file.
but luckly i now got it in an inbetween format that is easier to convert. so if you want any changes i can somewhat quickly update the file.

and i'd say don't worry about color for now.
i think it's more important to have some code that easily allows you to put strings, numbers, etc on the screen.

but just as food for thought. instead of controlling the color for every line you could make it simplier by just having 1 byte every 8 lines to control the fore/background color the next 8 lines.
so that is aligns with the tiles, and is less effort for the CPU.

and if you really want to spend a lot of time, you could make a 25 byte array out of SN74x273's to have different colors for every character in a line, and every 8 lines it would read 25 additional bytes from RAM to update those for the following 8 lines. or maybe just control the foreground color and have a global background color per 8 lines, so you only need 12 8-bit registers instead of 25.
but i think that is going way above the scope of the project.

I've done just that! I've got the bitmap fonts from here: http://pelulamu.net/unscii/ . Some search and replace and off it goes on the program ROM. I've written a subroutine that looks up the character and prints it to the screen bases on an horizontal and vertical index. See attached.
Agreed. No colours as of now. No real need for them anyway.
Juan

damn now i feel kinda stupid for having wasted that hour when someone else already made a font.
oh well atleast you got something working, and i got a character set i can use in the future.

i guess now it's time for just plain old programming to get some functions going.
question is, how are they supposed to work.

personally i would make 2 basic functions, one that puts a single character on the screen and one that puts a whole string on the screen (null terminated).
both would have 3 input parameters, an X and Y coordinates and the character/pointer that is supposed to be displayed.
the coordinates align with 8x8 tiles, not pixels. so the top left corner would be X=0, Y=0, while the bottom right corner would be X=24, Y=15.
bonus points if the functions output the X and Y coordinates of where the next free space is.
so for example if you input into the string function X=0 and Y=0, with a string that is 10 characters long. the coordinates afterwards would be X=10 Y=0.
though it would need to wrap around once X goes from 24 to 25. same with Y at 15 to 16.

overall this would allow you to put text directly on the screen wherever you want.
and also put multiple characters/strings in sequence without having to calculate the next coordinates manually, as the functions already do that.

but those are just my 2 cents. how you do it in the end is up to you. and i'm interested how you gonna do/are doing it.

I almost drew a font myself. I even started writing a python program to help me with that, but thought that, as with most things, someone has to have done it before... Some times you only find out later. That happened a couple times during my CPU design.

I was thinking of doing precisely what you describe. I have already done so for the 40x4 character LCD. The subroutines seem simpler for the graphics card, as one doesn't have to deal with two separate displays in one, and character addresses not being continuous when changing lines...

This is the subroutine I used to get the "Hello world" on the screen. Its just a proof of concept that I wrote in 5 minutes, I have to write it properly, with a loop and such.

Juan

The Gigatron uses 5*8 fonts.

Just curious, what is the width of the cell on the Gigatron? 6?

Many of the characters are a full 5 pixels wide, so if the cell were 5x8 they would run together.

Will take look. I'll stick just to the first 128 ASCII characters as of now. But maybe I'll add more later.
That's what I was thinking. It seems to me that it uses a 6x8 cell. In fact, the font I'm using uses 4x8 characters with the ocasional 5x8. But there has to be room for space between letters of course. By sticking to 8x8 cells, code remains simple. I thought of implementing a font with 4x8 cells (as the VIC-20 40 column programs did), but it's less readable, and I won't be doing any word processing on this computer.

I've written some subroutines for scrolling and clearing the screen. Typing characters is fast enough, it keeps up just fine. I don't know when it goes through BASIC though. Scrolling the screen takes about half a second. That's near enough to what I was hoping. I think it's usable.
Juan

I haven't posted in a while... I've been really busy with this "online university" thing. In less than a month I will be able to work on this more regularly.

I left off with fonts and such, and not much has happened since then. I've written some screen subroutines, including one that scrolls the screen one character line up.
And that's when trouble begins. When scrolling (it does so upon pressing the enter key just for testing), some lines, dots and other creatures appear primarily (but not only) at the bottom of the screen and make their way up. It's not a software issue, I have made simplified subroutines, testing a line at a time etc, and it still happens. Should anyone be interested here is my scrolling subroutine:
Just to recap, my video card just "listens" to the address and data buses and copies RAM writes on certain addresses to its own RAM.
So those must be errors when writing or reading from "system" RAM. Either the RAM, the CPU or something in between is to blame. I made a couple programs that wrote patterns to memory and checked back, but I wasn't able to get it to fail that way.

So I cleared the screen and modified the scroll subroutine to check if the bytes read were 0 or not. If it read a non-zero byte, it just does so I get a pulse on the X register that I can probe with the scope (that's the good thing about ttl CPUs).
I then noticed that when taking the video card out, pulses became more frequent. The video card should only have an effect on power consumption, effectively dropping the 5V rail (it's the hungriest card of all). So I left it plugged in and lowered the voltage on my power supply. Sure enough, pulses became less frequent and eventually disappeared.
But now at lower voltages, the video card stops working properly, as expected. There is a "sweet spot" when both work, but that's no acceptable solution.

I had set my power supply to just under 6V, the drop in the leads resulting in about 5 V on the computer cards. When lowering it about 5.5 V, voltage on the computer is 4.4 V or so. RAM's recommended supply voltage is 4.5-5.5V.

I think this means that the errors are occurring during reads, as data on the bottom line of the screen is only written once at the start, but upon reading, it sometimes reads fine, sometimes doesn't. I have checked timing requirements and I think those are met with plenty of margin. I have swapped out the RAM for another identical one, and it makes no difference.

Whatever the cause is, RAM errors would explain the far less frequent "random resets" that I'm experiencing as well.

Any ideas are welcome. I may have to take out the logic analyzer to try and rule out the CPU...

Juan

Earlier in the thread we discussed power distribution and decoupling capacitors: are you confident you now have a good solid low-noise power distribution?

Whoa -- what?? It seems Ed's hunch was correct. I suggest you use thicker leads -- or shorter ones. (Or shorter and thicker.) And perhaps you can arrange things so the leads go directly or almost directly to the heaviest load -- the hungry video card.

I can't promise this'll fix the trouble you're having now, but it's bound to prove worthwhile sooner or later. Boosting the setting to 6V isn't a solution. Even though the power supply is regulated -- good, quiet power -- you'll still get ups and downs (noise) at the computer end because it is a dynamically changing load and it simply isn't very well attached to the regulated source.

-- Jeff