• Please review our updated Terms and Rules here

Adding a serial LCD screen to the KIM-1

C

ClassicHasClass

Veteran Member
Joined
Mar 22, 2013
Messages
1,813
Location
(not so) sunny (No) So Cal
With a serial bitbanger routine, you can set up something like a Matrix Orbital LK204-25 and still keep the 20mA current loop interface free. It can be run off the existing power supply and just a couple RRIOT lines.

oldvcr.blogspot.com

What the KIM-1 really needs is an LCD screen

Giving the 1976 1K RAM, 1MHz 6502-based KIM-1 single-board computer bubble memory storage was all well and good, but the basic unit is stil...
oldvcr.blogspot.com oldvcr.blogspot.com
 
Great project.

I agree, I think both the KIM-1 and the AIM-65 deserve a better display, though comparing the AIM-65 they did better than the KIM-1 with the original display.

Any method to add a better display (while still keeping the computer original as possible) has to be a great idea.

I managed it two ways with the AIM-65. One was to replicate the RM-65 video card, to feed a standard composite video input VDU. More recently another very good result was obtained with Rockwell's ACIA card instead, feeding a Terminal, with a small program making the Terminal just behave as a video display only and not otherwise influencing the function of the AIM-65. A standard serial link (the AIM 65 has to be in TTY mode) is not like this. I did not know this was possible before until I found the program hidden in the ACIA Card's manual.
 
Last edited:
I'm really thinking I want to buy one of the bitmapped ones and see how that works out.

I thought of your ACIA card while I was working on this, especially since the serial sender routine I wrote is output-only, and that would help input a great deal. Separately I'm thinking about making a clone for my own AIM-65 because of exactly what you say: it becomes a side-car video display. That sounds really handy.
 
A parallel character LCD can be driven in 4 bit mode with as few as 6 i/o lines. You can also get serial/uart displays or even i2c displays and bit bang i2c. using 2 i/o lines.
 
alank2 said:
A parallel character LCD can be driven in 4 bit mode with as few as 6 i/o lines. You can also get serial/uart displays or even i2c displays and bit bang i2c. using 2 i/o lines.
Click to expand...

The serial/UART displays you talk of, I have not seen these;

Are these an LCD Screen that act as an RS-232 display terminal were you can set some Baud rate, 7/8 bits, stop, parity etc ? or do they require additional electronics & programming to work ?

Can you post a link to such a screen ?

If that flat screen already existed it could be put in an enclosure with the RM-65 ACIA & adapter card with a cable & edge connector to make a "plug on VDU" for the AIM65 (and probably a KIM too). Then the really neat thing would be to find a way to put that tiny Rockwell display program (which is operated by the F1 & F2 keys) somewhere in ROM.
 
alank2 said:
You can also get serial/uart displays or even i2c displays and bit bang i2c. using 2 i/o lines.
Click to expand...

I guess it must be said that those really dirt cheap (around $2 a board) i2c OLED screen modules have a small downside in that they only handle graphics; if you bit-banged one on a KIM you'd have to have your driver include character bitmaps. They do have hardware scrolling and other tricks, though, so you wouldn't necessarily have to keep in RAM a full copy of what's in the video memory on the display. (For instance, scrolling wouldn't necessarily need to involve re-sending the whole display, you could order the hardware to scroll the whole screen up 8 pixels and then wipe out the last line to be overwritten with the new characters.)

That said, the Matrix Orbital display in the article costs $70 (ouch!!!!) and is based on an Atmega164P CPU. Considering those little i2c displays cost $2 and you can get an Arduino Nano knockoff for $5 (and for this application there's no real need that it be an Atmega board, a cheaper Bluepill or whatever should also work fine) if you want to offload the pixel generation from the KIM that's definitely an option.
 
Yes, that is what I am talking about a tiny backpack type board that converts a parallel type LCD into a serial one. I think the i2c interfaces are the same, some type of add on pcb. The question really is what is convenient for the KIM-1 to interface with.
 
Seven bucks on Amazon, 20x4 LCD with I2C backpack:

here

It must be noted, still, that though this type of LCD has a character generator it’s still going to need a somewhat more elaborate driver than one like the Matrix Orbital that basically has a terminal emulator in its microcontroller.
 
I found this baby terminal VT-69:


It says less than $100.

Does anyone one the forum have experience with this ? It looks like a very nice build in the photo, not so sure about the one in the video.
 
Last edited:
Eudimorphodon said:
Seven bucks on Amazon, 20x4 LCD with I2C backpack:

here

It must be noted, still, that though this type of LCD has a character generator it’s still going to need a somewhat more elaborate driver than one like the Matrix Orbital that basically has a terminal emulator in its microcontroller.
Click to expand...

The Matrix Orbital devices are definitely not cheap (even this older NOS one was $40), but they are easy. I doubt I would have gotten everything into the RRIOT RAM if I had to write a longer driver, and yeah, it's basically a tiny little serial terminal. I've been pretty pleased with it.

Also, bitbanging RS-232 seems simpler. I've done less with I2C, but my understanding (tell me if I'm wrong) is that you need both clock and data lines. I imagine you could dispense with the input lines by just pretending everything you send worked and ignoring the ACK bits, but I can send to this device with just a single output line. Matrix Orbital even sells TTL-compatible versions now, so I wouldn't even need the level shifter.
 
ClassicHasClass said:
Matrix Orbital even sells TTL-compatible versions now, so I wouldn't even need the level shifter.
Click to expand...

This is where using an Arduino Nano or something as glue between any old i2c panel and the KIM starts looking like a pretty good idea. You'll get TTL serial for free for the KIM interface, and there will be a ton of GPIO left over to drive a keypad or something if you want to. The Arduino demo sketches for the LCD drivers generally demonstrate them digesting serial input and tossing stuff up on the screen, so most of the code you need is already there.
 
While we are on the topic of screens, I have a screen related question about scrolling.

I had imagined these systems might work, by keeping the video RAM address corresponding to each physical display screen location as a constant, and moving characters to a different address and location, but clearly this is not how scrolling works. The location on the screen is moved but not the character's address in the video RAM.

I have noticed with a particular video card I am working with (RM-65 video card on an AIM-20), in some mode say 72 column by 22 row, they quote the video RAM address starting at 9000h. So I can write a character to the first screen location here, top left of screen, and then to the last location at 962Fh at the lower right as expected.

However, once the screen has been scrolled the RAM location 9000h and the character there vanishes off the screen top. The last location and character displayed keeps its address identity, but it moves to a different location on the screen display, so the effect of the scroll is to move the video RAM address frame to a higher (earlier) place on the physical screen.

Also new higher range addresses, that were not initially available, become available, greater than 962Fh and a character can be displayed on the lower part of the screen, but not enough to support a whole new screen full of characters, for example the new allowable addresses do not go above 97FFh.

Regardless of "who" scrolled the screen, be it the AIM-65 monitor, or doing it in BASIC, I have not discovered a way yet to "un-scroll the screen" once it has been scrolled and re-associate the first and last screen character addresses of 9000h and 962Fh with the top left and the bottom right of the CRT display screen. Homing the cursor makes no difference nor does clearing the screen.

So the question is:

In the case where the scrolling is not bi-directional, is there a way to reset the scroll system to its initial state, like it is when the computer boots ? Or do you simply have to keep scrolling until the frame of addresses on the screen comes around to the starting point again, if indeed it does, but there seems to be insufficient video RAM for that to happen ?
 
Last edited:
Are we still talking about a HD44780 type parallel LCD? Download an HD44780 datasheet and see what it has to say about scrolling. It has been awhile for me looking at them, but I do think there was some sort of register that would control a basic scrolling effect (maybe just left to right?). The parallel interface does have the ability to read as well as write, so instead of having a buffer to remember what is on the screen on the computer, one could literally read one LCD display location and then write it to another thereby creating scrolling. My 6 I/O pins above does not include reading, that would have the R/W pin tied for writing only, so you would need a 7th I/O pin to read back too.
 
alank2 said:
Are we still talking about a HD44780 type parallel LCD? Download an HD44780 datasheet and see what it has to say about scrolling. It has been awhile for me looking at them, but I do think there was some sort of register that would control a basic scrolling effect (maybe just left to right?). The parallel interface does have the ability to read as well as write, so instead of having a buffer to remember what is on the screen on the computer, one could literally read one LCD display location and then write it to another thereby creating scrolling. My 6 I/O pins above does not include reading, that would have the R/W pin tied for writing only, so you would need a 7th I/O pin to read back too.
Click to expand...
The question about scrolling was a general vintage computer one, not related to LCD screens, but a composite video driven screen, typically where a shift register loaded with the Video Ram data via the character generator Ic clocks out the serial data. I probably should have put it on a separate post.

It is just that I don't know how the firmware for the scrolling works in these systems, and it appears that each character keeps its same address in the video ram, when it is put there, but the start of the read from the ram is shifted to move the character/s up the screen.

And the thing is, once it has happened once, I'm not sure where the data bytes are that keep track of it (are they in hardware or memory), so as to be able to re-set it, if there is a scroll and I want to get rid of it and un-scroll it. I imagine somewhere there is a scroll counter.

Does anybody have a reference to a document that explains, in these traditional vintage computer setups that generate composite video, how the scrolling works ?
 
Hugo Holden said:
Does anybody have a reference to a document that explains, in these traditional vintage computer setups that generate composite video, how the scrolling works ?
Click to expand...

I went Googling for the particular video card you have, and the most productive hit appears to be your PDF article about it. The short answer here is what you’re dealing with is a memory-mapped system built around a Rockwell 6545 (Motorola 6845 work-alike) and the firmware for it is set up to do hardware scrolling, per the datasheet, by incrementing the video start address stored in registers R12 and R13:


Basically what the firmware is doing is when you flip the machine on it’s setting the memory address for the HOME position to the ‘zero’ point in the available video memory; this means, on power-up, that yes, the first byte of the video memory buffer corresponds to the upper left character on the screen, and the start of each subsequent line is 40/80/whatever bytes deeper in, etc. And if the firmware of this card just kept this statically set then scrolling would work like you initially thought, IE, you’d have to use a software routine to block-move lines of characters forward in the video buffer, therefore having to rewrite the whole screen for every scroll…

Instead what’s going on here is when you need to scroll the screen the firmware is just updating R12/R13 in the CRTC with an address 40/80/whatever bytes higher, marching the “home” position forward, and also, crucially, updating pointers in the video driver so it knows where the right positions are for screen updates. Now the obvious question comes up: how can this work when the video card only has 2K or whatever of video RAM? Well, the answer in this case is likely that only 11 of the 14 possible address lines for the CRTC are implemented, so as you change the starting address the forward the video addresses will effectively “wrap around” somewhere in the middle of the screen. This will work fine, the CRTC itself certainly doesn’t care, it just means the video driver is going to have to be smart enough to understand that, for instance, if the video start address is near the end of the CRTC’s physical memory buffer you might be writing most of the screen contents into addresses that from the CPU’s point of view are lower than the start address.

Anyway, this kind of thing is far from universal. Most simple home computers with “hardwired” video circuitry, like a Commodore PET or TRS-80, don’t bother with scroll registers. (It’s not unknown, though… I think the processor tech VDM-1 and its descendant SOL-20 video systems have them, albeit a lot simpler/cruder than the CRTC has.) And plenty of machines that *do* have CRTCs don’t bother with hardware scrolling. It was honestly kind of a technical cul-de-sac, most microcomputers are fast enough that software scrolling isn’t a deal-breaker and it saves a lot of hassle.
 
Hugo Holden said:
The question about scrolling was a general vintage computer one, not related to LCD screens, but a composite video driven screen, typically where a shift register loaded with the Video Ram data via the character generator Ic clocks out the serial data. I probably should have put it on a separate post.

It is just that I don't know how the firmware for the scrolling works in these systems, and it appears that each character keeps its same address in the video ram, when it is put there, but the start of the read from the ram is shifted to move the character/s up the screen.

And the thing is, once it has happened once, I'm not sure where the data bytes are that keep track of it (are they in hardware or memory), so as to be able to re-set it, if there is a scroll and I want to get rid of it and un-scroll it. I imagine somewhere there is a scroll counter.

Does anybody have a reference to a document that explains, in these traditional vintage computer setups that generate composite video, how the scrolling works ?
Click to expand...
Depends on the video display controller used. My early swtpc video board (percom electric window) uses the CRT5027 controller, and my similar mid 70s Motorola Exorciser system video boards use the 6845 controller. Both video display controllers use memory mapped display memory and incorporate registers that define what character memory location is displayed after the vertical sync, so characters in memory stay put but displayed screen location can be changed.
See app note for discussion.

Conversely, the video system used in my Motorola TV chroma system uses the 6847 text/graphics video display generator instead. Also memory mapped display memory, but 6847 lacks the positional display registers of the 6845 so the monitor routines for scrolling actually must actually move character bytes in display memory to alter their displayed location.
 
Eudimorphodon said:
Anyway, this kind of thing is far from universal. Most simple home computers with “hardwired” video circuitry, like a Commodore PET or TRS-80, don’t bother with scroll registers. (It’s not unknown, though… I think the processor tech VDM-1 and its descendant SOL-20 video systems have them, albeit a lot simpler/cruder than the CRTC has.) And plenty of machines that *do* have CRTCs don’t bother with hardware scrolling. It was honestly kind of a technical cul-de-sac, most microcomputers are fast enough that software scrolling isn’t a deal-breaker and it saves a lot of hassle.
Click to expand...
Thanks!

It is clear that the scrolling function is built into the 6545 CRTC IC on the RM-65 video card, but as yet I have not been able to figure out how to modify its registers to undo a scroll , if it has occurred. I will keep working on it.
 
You must log in or register to reply here.
Back
Top