Grant Searle's Terminal (plus required CTS mod to 68B50 serial board)

[Steve Baines]

Hi Kids,
So, I built a terminal using Grant Searle's monitor and keyboard design (at http://searle.hostei.com/grant/MonitorKeyboard/index.html) which uses a couple of ATMEGA328P chips - one to generate the display, one to handle the serial interfacing, plus a small USB keyboard, a cheap USB to PS/2 converter, and an old B/W 5.5" TV.

The whole setup looks like this:


Works great, is nice and compact-ish, and means that I can use the RC2014 without having to get either a laptop or a PiZero involved (both of which feel wrong to me, since they are both so vastly more powerful than the RC2014).

Plus, CRTs are ace. :-)

I did however have to make a small modification to the RC2014 68B50 serial board.
With the original RC2014 board, I was getting results like this:


Basically, the RC2014 was squirting out characters faster than the terminal could display them, and characters were getting lost.

The terminal has a pin labelled /RTS which needs to be connected to the CTS pin on the 68B50.
When the terminal buffer is almost full, /RTS goes high to indicate that we need to stop sending it data.
When the CTS pin on the 68B50 is high, it pauses transmission.  So connecting them forces the RC2014 to slow down if it is in danger of overloading the terminal.

The only problem is that on the RC2014 card, the CTS pin is wired direct to ground.
On the plus side, there is an unused pin (6) on the 'FTDI' header.

So, I modified the board so that instead of the CTS pin going to ground, it instead went like this:

CTS ----- 2k2 ----+------- PIN6 'FTDI'
                        |
                       33k
                        |
                     GND

I then connected pin 6 to the /RTS line on the terminal, and then got:


Perfect!

The 2k2 resistor is in there because the Tx, Rx, and RTS lines all have one, so I assume it is some needed protection?

The 33k resistor to ground is to provide a weak pull down, so that if nothing is connected to pin 6, CTS will be pulled down, to allow transmission as it always used to.
When the pin is driven externally, this resistor simply causes a small additional current which is easily overridden.


The physical modification goes like this:
1. Lift pin 24 (CTS) of 63B50 so it is no longer connected to ground via the PCB, and trim it.
2. Solder a 2k2 resistor directly to it, and the other end to a wire which wraps around top of the board...



... to the back:

3. Solder the other end of the wire to the (unused) pin 6 of the FTDI header.
4. Carefully solder a 33k resistor between pin 6 and pin 1 (GND) of the FTDI header.
5. There is no step 5. :-)


It would be great if future revisions of the serial board included this mod, as it will be needed whenever talking to a terminal which is slower than the RC2014.
Note that with the mod installed, if you'd rather have the legacy behaviour of missing serial characters rather than slowing down the RC2014, all you need to do
is unplug from pin 6, and the 33k pull-down will do the rest.

Hope this is of interest / help to others!

   Cheers - Steve

[Scott Lawrence]

Excellent work on so many levels! :D

I need to make the terminal... i've got a bunch of 328p's around...

-s

--
You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+unsubscribe@googlegroups.com.
To post to this group, send email to rc201...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/a83a7e64-52a0-41e1-ae23-c262b576f530%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Scott Lawrence
yor...@gmail.com

[Steve Baines]

On Friday, May 19, 2017 at 7:24:51 PM UTC+1, Scott Lawrence wrote:

Excellent work on so many levels! :D

Thanks, but Grant Searle did all the hard work!

[Scott Lawrence]

I meant on your build and tracking down the handshaking circuit mod, etc.  

-s

--
You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+unsubscribe@googlegroups.com.
To post to this group, send email to rc201...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/4adf8419-0fb3-4060-9e76-bd7e4145f4cb%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Scott Lawrence
yor...@gmail.com

[Thomas Riesen]

Hi Steve

Well done!!!

I have problems to get my terminal working. What type of connection
do you use between the two ATmega's? 4Bit, 8Bit, I2C?

How do you set the fusebits for the rail to rail clock?

Regards
Thomas

[Steve Baines]

Hi Thomas,

On Saturday, May 20, 2017 at 10:46:11 PM UTC+1, Thomas Riesen wrote:

Hi Steve

Well done!!!

Thanks.
 

I have problems to get my terminal working. What type of connection
do you use between the two ATmega's? 4Bit, 8Bit, I2C?

How do you set the fusebits for the rail to rail clock?

I used the 8 bit connection.
I used an USBAsp interface dongle to do the programming.
The AVRdude commands that I used to flash the firmware and then set the fusebits were:

For the video chip:
> avrdude -c usbasp -P usb -p m328p -u -U flash:w:SBCVideo.hex
> avrdude -c usbasp -P usb -p m328p -u -U lfuse:w:0xf7:m -U hfuse:w:0xd9:m -U efuse:w:0xff:m

For the interface chip:
> avrdude -c usbasp -P usb -p m328p -u -U flash:w:SBCInterface_328.hex
> avrdude -c usbasp -P usb -p m328p -u -U lfuse:w:0xff:m -U hfuse:w:0xd9:m -U efuse:w:0xff:m

The fuse values are on http://searle.hostei.com/grant/MonitorKeyboard/index.html,
from where the hex files were downloaded.

Hope that helps!
Figuring out the right command line for avrdude took most of an evening of googling...
 

Regards
Thomas

   Cheers - Steve

[Steve Baines]

One other thing - at first it would run for a few seconds, then the display would 'smear' then collapse (hard to describe, but if you see it you'll know what I mean).
This seemed to be due to my power supply voltage being a little low (not enough headroom in the supply to the voltage reg).
I'm _guessing_ that the rail-to-rail clock thingy was sensitive to this, but it may have been the ATMEGA328P generally.

Anyway, upping the supply voltage so that the vreg was giving out a solid 5V seemed to fix it.

[Martin Giese]

Sorry for digging this up from the vault.  But I just built my Grant Searle terminal :-)  so let me share my experience for posterity.

I had trouble with the rail-to-rail clock.  On pin 10 the scope showed that the signal didn’t go quite low enough, and that made the shift register misbehave.  Probably would have worked with an HC shift register rather than HCT.  Anyway, I ended up using the clock from pin 9 instead of 10, and that works.  A more foolproof design would be to generate the 16MHz for the shift register and the AVR using an external oscillator circuit, rather than relying on the AVR’s oscillator.

The other thing is that my keyboard hangs when I press Caps Lock, or more specifically, after the code tries to change the keyboard LEDs.  I disabled the LED changing for the time being.  I suspect that my PS/2 keyboard wants a different command sequence.  Will have to investigate.

I think I’ll use one of the available pins on the keyboard/serial AVR to generate a reset signal when the user presse Ctrl+Alt+Del or some such.

I’m also thinking of making a variation on this theme using a 40 pin ATmega1284 for the display part that has enough RAM (8k) for a 320x200px graphics display.  Like Steve was saying, it feels like less of a cheat than using a Pico or ESP32 etc.

[Phil G]

Not quite on topic but relevant I think - just to say that the Geoff Graham ASCII terminal works superbly. I've used it in various guises, full & partial, always good.
https://geoffg.net/terminal.html

[Martin Giese]

Aha, with a PIC32.  Nice, thanks for the link!

[Justin Skists]

Indeed. It's nice to see terminals that aren't Pico based.

Justin

--

You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.

To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/rc2014-z80/692e791b-2161-4a3f-8018-28c9e3937d53n%40googlegroups.com.

[Robert Porter]

Completely off topic, I apologize... But I have several (5-ish) bare boards for Geoff's Colour MaxiMite 2 if anyone wants one I'd be happy to mail it to them provided the postage isn't too outrageous. It uses a Core-H7 module which might be hard to find. Not sure... Haven't looked for one in a few years. I think it's a CMM2 gen 1? board. I think the gen 2 had the chip on it already. With these, they're on a separate module that mounts to the board. I'm in the US btw. Might have a few of the resistor arrays (for VGA output) too. 

Rob

To view this discussion, visit https://groups.google.com/d/msgid/rc2014-z80/e04b32c1-c321-4eac-a2cb-6638b2d4fc67%40gmail.com.

[Bill Shen]

There are also VGA terminals based on Propeller or CPLD.  I think it is also possible to build a VGA graphic terminal with a fast 6502.

Bill

[Martin Giese]

I’m still fighting to get the keyboard LEDs to light up.  Tried with both Grant Searle’s code and the example from the Arduino library PS2KeyAdvanced (hacked to use pin change interrupts).

What seems to happen is that when the controller sends the two byte sequence 0xED <led-flags>, the keyboard sends an acknowledge (0xFA) after the first byte, but an error code (0xFC) after the second one.  It then hangs.

This is the keyboard I’m using.

https://www.aliexpress.com/item/1005006599888480.html

Has anybody encountered a similar problem? Does it ring any bells?

Things to still try out: 1. get my hands on another PS/2 keyboard.  2. try this one on a PC.

[Lionel Peterson]

I like this PIC-based terminal available on Etsy - I know it's based on a popular design available in many places, but it's a good, solid build

 https://www.etsy.com/listing/1797851841/legacy-pixels-ascii-vt-100-compatible

I've built it as a kit a couple times, very straight-forward build, worked first time every time. (The link is to a pre-built version)

Ken

On Dec 30, 2024, at 12:12, Justin Skists <j.sk...@gmail.com> wrote:



To view this discussion, visit https://groups.google.com/d/msgid/rc2014-z80/e04b32c1-c321-4eac-a2cb-6638b2d4fc67%40gmail.com.

[Martin Giese]

Lionel, that seems to be the Geoff Graham design that Phil was referring to.

Martin

[Lionel Peterson]

OK, then I'm +1 for the Geoff Graham design.

I'm no good at 3D printing, but a VESA Mount sled or case for that board would be great, so I can tuck the circuit board behind flat panel monitor.. anyone know of one?

Ken

On Jan 1, 2025, at 10:52, Martin Giese <mabar...@gmail.com> wrote:

Lionel, that seems to be the Geoff Graham design that Phil was referring to.

To view this discussion, visit https://groups.google.com/d/msgid/rc2014-z80/a20e90f4-9e54-4547-90aa-a7aa2fb29d53n%40googlegroups.com.

[Harry Speer]

The Legacy Pixels that is on Etsy is also on Ebay. FWIW. Looks like same identical product at both locations.  See the ebay here:    https://www.ebay.com/itm/225010233671  I'll probably buy one once I get to that stage. It may be cheaper than a PCI-Express x1 RS-232 Serial Port Card.  Actually I think both. HSS

[Guido Santer]

Hi.

That's the missing part for my RC2014. Is anybody aware or ready boards to order?

Is there a way to connect the bus between the serial i/o/Keyboard/Video stuff to the RCBus? That would speed up things i guess, but the BIOS would need a driver for those, right?

I really would like to see some Kits for a "RCBus Video Out Board" and "RCBus Keyboard Board" in the future. So the serial port would be free and the RC2014 would be usable without a Terminal.

The Grant Searle solutions seems to be the only 80x25 Chars solution outputting on CVBS. All other solutions only output less characters on CVBS or use VGA.

[Gary S]

https://thehighnibble.com/vt132/

[Tadeusz Pycio]

https://thehighnibble.com/vt132/

Also, I think an ANSI colour termianal built on ESP32 with the FabGL library is one of the cheaper and also the best option. There is an open source version of this module available on GitHub. Pictured is a fork of it which uses more readily available parts. 

[S P Dixon]

May I immodestly chuck my own TMSEMU3 into the mix?

It can now start in 80-col colour serial terminal mode, switchable (automatically, via software or by physical jumper / switch) into graphic TMS emulation mode, now easily jumperable to MSX, Einstein or Colecovision ports. It has the convenience of HDMI and I supply assembled and tested.

I did wonder whether 48 lines was too many (I prefer a 'taller' font) but its 80 x 48 seems to be spot on for Ladislau's Pool, which I love. 

https://www.tindie.com/products/shieladixon/tmsemu3-graphics-card-designed-for-rc2014/

Shiela

To view this discussion, visit https://groups.google.com/d/msgid/rc2014-z80/38cbd538-2c3c-4581-a862-0316b7ea850fn%40googlegroups.com.

[Martin Giese]

So many possibilities 8-)

A FabGL-based terminal is also on my bucket list.  VGA-to-perfboard breakouts are already there waiting.  What bugs me a little bit is that the ESP32 can emulate an 8086 PC running MSDOS in its spare time while it’s producing the video output.  What do I need the Z80 for?  Retro-computing can be weird at times.

Guido, I think you’re asking about solutions that don’t go via the serial port.  In that respect, Shiela’s TMS emulator, or for that matter a solution using an actual TMS9981 (if you can get your hands on one) would be the way to go. E.g., Langston’s https://github.com/jblang/TMS9918A

You talk to the Video chip through some I/O ports.  This is the way it was done in the MSX computers for instance, so it’s definitely "retro compliant."

I don’t know if anybody ever made a design for the RC2014 that uses part of the RAM address space for video.  That would be very retro indeed.  Even more so if you use the poor CPU to send bytes to the video output, as was done in the ZX81 I think.  If some hardware is supposed to address the video ram and generate the video signal, that would probably be tricky on an RC2014 because that hardware would need to take control of the bus while rendering video.  Or use dual port video ram which would require more complicated address decoding.

Martin

PS: for the time being I’m still happy with my Grant-style terminal.  The only thing that really bugs me is that the cursor replaces the character at the spot, or alternates with it when blinking.  But at 640 px/line, there is simply no room in the 8 clock cycles available to push out data to check for the cursor position and invert the bits.  Possible solutions: 1. a part with more RAM, put the whole font in RAM, use character #0 or some such, redefined to be the inverted character under the cursor. 2. forget about the top 128 characters and replace them by inverted versions of the first 128 characters.  3. overclock AVR to 32MHz, have 16 clock cycles per 8 pixels. Votes?

[Martin Giese]

Oh, just checked. The ZX80/ZX81 video logic was actually a lot more creative than the CPU sending out the bits.  Another great explanation by Grant Searle: http://searle.x10host.com/zx80/zx80.html

[Spencer Owen]

"I don’t know if anybody ever made a design for the RC2014 that uses part of the RAM address space for video.  That would be very retro indeed"

The Video Beast does that (https://feertech.com/microbeast/videobeast.html) sitting in 16k of memory. This fits in well with the Classic II / Mini II memory map, so would be fairly trivial from a hardware perspective. From a software perspective, though, a Classic II or Mini II are probably not in the best position to take advantage of all of that graphic power.

Spencer (deliberately not promoting the new serial module on z80kits that would solve other issues on RomWBW machines which need more serial ports) 

[Bill Shen]

I just received the updated VGARC pc board that can accommodate Z80 on RC2014 bus or 68K/6502 on RC6502 bus by moving a set of jumpers.  This is a shared I/O memory design with 4K of dual port RAM on Z80's I/O space where 3K is character memory (64 cols X 48 rows) and 1K is font memory (128 8x8 fonts).  Every character and font are directly mapped to 4K I/O space, so it is fairly easy and fast to manipulate the screen characters and associated fonts.  Wayne Warthen has incorporated VGARC in RomWBW, so RomWBW can auto detect the display and PS2 keyboard at boot time and reconfigure the user interface accordingly.  The RC2014 serial ports are not involved in console I/O and available for other tasks such as transferring files using XMODEM.

Regarding beam racing, I have a 6502 design that use 6502 as a VGA controller pushing pixels out at 25.175MHz.  6502 is running at 25.175MHz, but 90% of its time is driving the 640x480 VGA display.  It has time to do other tasks during vertical retrace, but it is effectively a 2MHz 6502.  Z80 can also be reliably overclocked to 25 MHz, so I am also thinking about the same idea for Z80.
Bill

[Tadeusz Pycio]

At the moment, it is a big problem to get still working chips for video generation, so one has to make do with what is available today. Of course, it is possible to emulate old graphics chips with FPGAs or powerful processors that are up to the task. Looking at the parts used there, is it still retro? I believe it is. Ubiquitous devices are definitely more powerful than our 8-bit computers. No one wonders, for example, about a Serial-USB converter that incorporates a 32-bit RISC-V or ARM in new designs, SD and CF cards are a powerful computer that surpasses the Z80. However, the terminal module on the ESP32 or RP Pico is a separate device that is only included on the RC2014/RCBus backplane for convenience. Its performance is needed for video signal generation and ANSI emulation. It is anyway a less ‘modern’ solution to a multi-core PC which is capable of emulating a dozen of our computers simultaneously.