Looking for dumb terminal software for 8 bit cpu

I am working on using a Z80 core on an fpga for use as an on chip serial terminal. I have not had much success in finding anything that I think will fit. Something written in c and compilable with sdcc would be ideal.

Anyone have any suggestions?

Reply to
javaguy11111
Loading thread data ...

I don't really understand what you're looking for. 99% of the "work" in a dumb terminal is interfacing with the display controller chip, scanning the keyboard, and talking to the UART. You specify neither your display hardware nor your keyboard hardware nor your UART. So, we have to assume that the HW interfacing is done. If the HW interface stuff is indeed done, a dumb terminal only consists of about 6 lines of code:

while (1) { if (uartStatus.rxData) displayChar(uartData); if (keyPressed()) uartData = keyValue(); }

--
Grant Edwards                   grante             Yow!  Are you guys lined up
                                  at               for the METHADONE PROGRAM
 Click to see the full signature
Reply to
Grant Edwards

The rtl up this point consists of a z80 from opencores.org , memory, uart, keyboard and memory mapped text console. The while(1) is basically what I just got through testing when I saw your reply.

The fpga board I am using is a Xess with a XC3S1000 and does not have an onboard serial connection. It does have onboard keyboard and video connections.

Basically I am looking for code that would give me a vt100 or equivalent functionality. This part of the rtl will interface with an on chip or32 running ucLinux. I do not have enough available block ram to run a vga display, so I am running in text mode. Also just having a small onchip serial terminal could be useful for other projects.

Reply to
javaguy11111

You may have to create your own terminal emulator from scratch. It isn't hard. A simple one that supports clearing the screen, painting characters as any location on the screen, optional line/wrapping and scrolling should only take about day.

Noel

Reply to
Noel Henson

[...]

I second that. Porting something such as curses would be a mini-major (or major-mini) project.

Reply to
Bryan Hackney

It could help to have the following done in your hardware : simplifies code, and also improves performance.

** ClrScreen ** ClrEOL ** HW Cursor ** and maybe ScreenPage select, or long screen HW scroll, since you have a FPGA...

-jg

Reply to
Jim Granville

I went over some old code snippets and found one that occupies about 500 bytes. It was for a bit-mapped display with the character maps in ROM. It did support windowing, or rather, it supported terminal emulation (clearing, scrolling and line-wrapping) on non-overlapping regions of the displayed screen.

Since my display was bit-mapped, I didn't get the advantage of any hardware support. Surprizingly, performance wasn't too bad.

Noel

Reply to
Noel Henson

I currently have about 8K ram allocated for the Z80. I can bump it up to 32k if necessary, but I hope I will not need that much.

I was hoping I could avoid having to wade through a bunch of terminal specifications to create a working display. Probably what I will do is have the terminal print out any unrecognized escape codes in hex to reverse engineer any additional functionality I may need. I will also have to write a key scan code decoder as well.

I do not think speed will be a problem since I am currently running the Z80 at 25Mhz and can probably bump it up to 50Mhz if necessary. Of course it is possible I could bottleneck on video memory access, but I will worry about that if it becomes a problem.

Reply to
javaguy11111

Your speed should not be a problem. It sounds like you have enough program space as well. And don't worry about the keyscan routines, they are quite simple.

You'll need just a few simple routines to get going. If you like, it seems like the wonderful people on this thread are willing to advise. Need some help to get started?

Noel

Reply to
Noel Henson

Suggestions, links and code snippets are always welcome. And of course I am willing to share the end result with anyone that is interested. This is a personal project. Nothing proprietary.

Reply to
javaguy11111

course

I'd agree with the previous comments about this being pretty easy to do. About 10 years ago I did a proprietary vt100 emulator for a client that had a few keys, a small lcd display and a serial port. The whole thing was run off an 8 mHz 68hc11. If I owned the code (and could find it :-) ) I'd share it.

But you should be fine with a z80 core.

If you want to emulate one of the older terminals, the hardest part used to be finding the spec. I paid about $30 for a badly copied out of print manual, from DEC themselves. Now you can just surf to

formatting link
They seem to have a pretty good selection of old dec manuals online.

Mark

Reply to
mhahn

You'll need some variables and constants to handle the window. I'll assume that you won't be doing windowing.

1-bit flags -------------------------------------------------------------- wrap: line wrap scroll: scroll (instead of screen wrap) 8-bit variables ---------------------------------------------------------- curx: the x cursor cury: the y cursor cursor: the value of the character to use as the cursor

constants ---------------------------------------------------------------- basexy: physical address of the first character on the display maxx: characters per line maxy: lines per screen xstride: the char-to-char memory offset (in bytes, probably 1 or 2) ystride: the line-to-line memory offset (in bytes)

routines ----------------------------------------------------------------- putchxy(char): put a char at curx,cury incx(): increment curx by xstride if curx

Reply to
Noel Henson

And a vt100 is a smart terminal. A dumb terminal is an order of magnitude simpler.

--
Grant Edwards                   grante             Yow!  I know th'MAMBO!! I
                                  at               have a TWO-TONE CHEMISTRY
 Click to see the full signature
Reply to
Grant Edwards

skrev i meddelandet news: snipped-for-privacy@c13g2000cwb.googlegroups.com...

Or look for supply of the obsoleted TMP455 from National Semiconductor, which would have done what you want :-)

8032 core, and special H/W to drive a character mode 80 x 25 screen. Add memory and off you go.... Maybe not, no trace using google ;-)
--
Best Regards,
Ulf Samuelsson   ulf@a-t-m-e-l.com
 Click to see the full signature
Reply to
Ulf Samuelsson

If the terminal is not bit mapped,. then clearing a byte and doing a string move will do what you want on a Z80.

*p = 0; memcpy´(&p[1],&p[0],(ROWS * COLS)-1);

The memcpy is a single instruction on the Z80 in assembler. String move can also handle scroll and erase to end of line.

It is very nice if you have H/W support for blink though.

Have actually been thinking of this as an excellent application for the FPSLIC.

The AT94S10 FPSLIC is a very good part for this type of applicaiton. 25 MHz AVR processor (soon 40 MHz) Up to 16 kB x 8 Single port SRAM available to FPGA. In addition, you have plenty of 32 x 4 Dual Port RAMs which can be used to implement a line buffer.

The RAM would be used to store 80 x 24 characters with 2 bytes per character. The second byte is used for attributes. On top of that you have room for one or more character sets. Using a 5 x 7 character, you need an 8 x 8 bit image or 8 bytes. For 128 characters, you need 1 kB so you can have a few character maps inside. The AVR can change the character map by loading from the flash configurator inside the package. With a more advance 16 x 12 you need 24 bytes per character maps or 3 kB per maop and you have a max of 3 character maps at the same time.

In order to simplify things, you may want to have a linebuffer. A 96 x 16 memory can be implemented using 12 DPRAMs (80 x 16 used) On top of that you could add the H/W cursor using two additional DPRAMs A 32 x 8 memory would be used to generate a 16 x 16 image.

Each line would start with the linebuffer beeing fetched (during horizontal retrace). Then the output of the linebuffer.character together with the lower 3 bits of the linecounter would form the address to the character generator. linebuffer.attribute would be used to modify the bitmap, * adding underscore. * Blink is easy: A PWM timer clocked by VSYNC inverts the character when the PWM is high. XOR function * Inverse character is easy as well.

--
Best Regards,
Ulf Samuelsson   ulf@a-t-m-e-l.com
 Click to see the full signature
Reply to
Ulf Samuelsson

Do you know this yahoo group ?

formatting link

There were few discussions about it already. And two working designs. One uses a z80, the other a mc6809 ...

Reply to
E.S.

that I

would

Reply to
javaguy11111

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.