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 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 ...

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 ...

>   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

<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

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!!

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

javaguy11...@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.

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

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.

javaguy11111@gmail.com wrote:

> 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.

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

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.