javaguy11...@gmail.com wrote:> Suggestions, links and code snippets are always welcome. And ofcourse> I am willing to share the end result with anyone that is interested. > This is a personal project. Nothing proprietary.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 http://vt100.net They seem to have a pretty good selection of old dec manuals online. Mark
Looking for dumb terminal software for 8 bit cpu
Started by ●January 2, 2005
Reply by ●January 2, 20052005-01-02
Reply by ●January 2, 20052005-01-02
javaguy11111@gmail.com wrote:> 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.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<maxx, return false, otherwise if wrap curx=0 and return true, otherwise restore curx to pre-incremented value incy(): increment cury by ystride if cury<maxy, return false, otherwise if scroll, restore cury to pre-incremented value and scroll-up otherwise cury=0 home(): curx=0, cury=0 cls(): store 0x20 at all locations, home() putch(char): puchxy(char), incx(), incy() cr(): curx=0 lf(): incy() handlechar(char): char==0xd: cr(), return char==0xa: lf(), return char==0x1a: cls(), return else: putch(char) -------------------------------------------------------------------------- Basically that's all there is to it; for a very basic terminal anyway. Noel
Reply by ●January 2, 20052005-01-02
On 2005-01-03, mhahn@hvc.rr.com <mhahn@hvc.rr.com> wrote:> 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.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 visi.com SET!!
Reply by ●January 3, 20052005-01-03
<javaguy11111@gmail.com> skrev i meddelandet news:1104699955.277881.284500@c13g2000cwb.googlegroups.com...> 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.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 This is a personal view which may or may not be share by my Employer Atmel Nordic AB
Reply by ●January 3, 20052005-01-03
> 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... >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 This is a personal view which may or may not be share by my Employer Atmel Nordic AB
Reply by ●January 4, 20052005-01-04
javaguy11111@gmail.com wrote:> 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?Do you know this yahoo group ? http://groups.yahoo.com/group/fpga-cpu/ There were few discussions about it already. And two working designs. One uses a z80, the other a mc6809 ...
Reply by ●January 4, 20052005-01-04
I had not seen that group before. Thanks for the info. E.S. wrote:> javaguy11111@gmail.com wrote: > > > 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 anythingthat I> > think will fit. Something written in c and compilable with sdccwould> > be ideal. > > > > Anyone have any suggestions? > > Do you know this yahoo group ? > http://groups.yahoo.com/group/fpga-cpu/ > > There were few discussions about it already. And two working designs. > One uses a z80, the other a mc6809 ...
