• Please review our updated Terms and Rules here

Adding Text display and keyboard for a homebrew Z80 CPM computer

Eudimorphodon said:
You were actually able to lay hands on them for that cheap? That's a fraction of what I was able to find for similar on AliExpress. (And digikey wants like $14 each for them, it's ridiculous.)
Click to expand...

Yes, I think I bought 25 pcs for $2 each, and they worked just fine. I used it for the first version of dual ported VGA display card as well as for multiprocessor Z80 designs. It is one of my building blocks. I just placed order for 25 more.
Bill
 
I recently got fake SRAMs from UTsource. I've also gotten low grade defective voltage regulators.

I did get good NSC800 processors and various other parts.

Not real sure about them. Never quite sure what I buy will be good. Still i go back...
 
The only fake/bad chips I’ve ever bought were RAMs, so I have to admit I’m kind of gun shy about buying from an iffy source for those.
 
UTSource is fairly reliable, but I did have fake Z80 from them. They are good with refunding, but the important thing is to test them soon after receiving.
Bill
 
So back to your BIOS implementation. I have the Superbrain source code (including hidden BIOS, reverse engineered) which manages the screen, with a limited set of escape sequence processing, via a 8350 CTRC and a CRT8002 video generator. The code is a bit weird thanks to the needs of the CRTC, but the main observation is that it is quite big and steals quite a bit of TPA to function.

In other words, functionally you'd be better off with a discrete (internal) terminal implementation, which was also done back in the day (example, Philips P2000C which has a separate terminal board connected to the processor board by a bog standard serial port, all internal to the case).
 
Thanks for that insight to the implementation of escape sequence. That's what I'm afraid of. Beside the software task of getting it done, I'm afraid it will eat into TPA significantly, at least for CP/M2.2. Could you tell me how big is the escape sequence routine?

I may seriously consider a dual Z80 approach where the second Z80 is programmable by the primary Z80 and acts as a terminal, but accessible as I/O ports without the hardware overhead of serial ports on both Z80.
Bill
 
Plasmo said:
Thanks for that insight to the implementation of escape sequence. That's what I'm afraid of. Beside the software task of getting it done, I'm afraid it will eat into TPA significantly, at least for CP/M2.2. Could you tell me how big is the escape sequence routine?

I may seriously consider a dual Z80 approach where the second Z80 is programmable by the primary Z80 and acts as a terminal, but accessible as I/O ports without the hardware overhead of serial ports on both Z80.
Bill
Click to expand...

..or uses shared/dual-ported memory...
 
If you have a memory paging mechanism it would of course be possible to put the terminal code in an alternate memory space and swap it in and out as needed to lower the impact on the TPA. Some machines with memory mapped video paged the frame buffer itself in and out. (I don’t know off the top of my head any machines that used 16 bit port addresses instead; my vague recollection is that’s not entirely kosher for S-100?)
 
Eudimorphodon said:
If you have a memory paging mechanism it would of course be possible to put the terminal code in an alternate memory space and swap it in and out as needed to lower the impact on the TPA. Some machines with memory mapped video paged the frame buffer itself in and out. (I don’t know off the top of my head any machines that used 16 bit port addresses instead; my vague recollection is that’s not entirely kosher for S-100?)
Click to expand...

A nice, simple solution. The Kaypro (just one example) does just that for the entire "meat" of the BIOS. It does require you to carve-out part of memory for variables/data used by the routines, and that memory needs to be preserved during CP/M boot (or you probably suffer a video glitch when CP/M re-initializes). Kaypro CP/M did that by creating a "63K" CP/M instead of 64K, reserving the top 1K for ROM BIOS use. Some "terminals" used fancy schemes to separate the video RAM and still allow CPU access (without video disturbance), but dual-ported RAM is probably the easiest. The Kaypro used custom LSI logic to build the support circuitry for the SY6545 CRT controller (an enhanced 6845), but today one would use a CPLD.
 
I may seriously consider a dual Z80 approach where the second Z80 is programmable by the primary Z80 and acts as a terminal, but accessible as I/O ports without the hardware overhead of serial ports on both Z80.
Click to expand...
If you're thinking of a second Z80 then you may want to look at the SD Systems VDB-8024 board which is described <here> along with it's manual. This was a popular S100 board that used an embedded Z80 as a video I/O processor via a single I/O port and had various CTL codes to manipulate the display.
 
durgadas311 said:
Some "terminals" used fancy schemes to separate the video RAM and still allow CPU access (without video disturbance), but dual-ported RAM is probably the easiest.
Click to expand...

That's why home computer makers loved the 6502 so much; if you were willing to slave the CPU speed to the memory access requirements of video refresh its predictable 50/50 bus duty cycle gave you hitless memory arbitration for free.
 
Eudimorphodon said:
If you have a memory paging mechanism it would of course be possible to put the terminal code in an alternate memory space and swap it in and out as needed to lower the impact on the TPA. Some machines with memory mapped video paged the frame buffer itself in and out. (I don’t know off the top of my head any machines that used 16 bit port addresses instead; my vague recollection is that’s not entirely kosher for S-100?)
Click to expand...

The RAM is 128K divided into 4 banks of 32K, so in CP/M3 environment I can certainly bank away the cursor handling routine to save TPA. However, there also is the non-trivial task of writing the cursor handling routine. I've already written limited cursor routine to take care of carriage return/line feed, display of the cursor and scrolling (my hardware is too primitive to have hardware blinking cursor and hardware scrolling). working with escape sequences probably won't be that easy by comparison.

I've grown quite fond of the 16-bit I/O addressing. Manipulating cursor is nothing more than setting up the correct values for reg B and C and write with OUT (C),A or read with IN A,(C).
Bill
 
Dwight Elvey said:
It really depends on which escape sequences you intend to support. Most software is relatively limited.
Dwight
Click to expand...

You may be right. I looked more into ANSI escape sequence. The cursor control seems simple to do. I've already done scrolling and clear screen functions. I probably can test it with a few CP/M screen-orientated software like WordStar, ZDE and call it good enough.
Bill
 
Plasmo said:
You may be right. I looked more into ANSI escape sequence. The cursor control seems simple to do. I've already done scrolling and clear screen functions. I probably can test it with a few CP/M screen-orientated software like WordStar, ZDE and call it good enough.
Bill
Click to expand...

Other than common text functions like home, clear screen, CRLF and scroll. Locating to an XY is about all that is need, that I can think of.
Dwight
 
Regarding UTsource, I agree..Test to confirm ok, and complain when parts are defective. UTsource did a partial refund in my case.
 
Plasmo said:
Thanks for that insight to the implementation of escape sequence. That's what I'm afraid of. Beside the software task of getting it done, I'm afraid it will eat into TPA significantly, at least for CP/M2.2. Could you tell me how big is the escape sequence routine?
Click to expand...

Hi Bill

The Superbrain HBIOS comprises of four routines - INIT (sets up the hardware on soft/warm boot), CRTIN (read the keyboard; implements key mapping), CRTOUT (manages the display, incorporates escape handling) and DISK (service routines for the disk I/O processor). If we ignore DISK it is 967 bytes long. INIT is also setting up the screen and it has the screen refresh ISR that the CRTC requires, plus you'll need BIOS code to read your keyboard, so I think it is about right for the purposes of planning.

The following escape sequences are implemented:

  • Set cursor position (x,y)
  • Erase to end of line
  • Erase to end of screen
  • Disable escape sequence processing (shows escape sequences instead of acting on them)
  • Re-enable escape sequence processing
  • Home cursor
  • Cursor forward
  • Ring bell
  • Tab
  • Cursor up
  • Clear screen
  • Cursor back

Cursor down can be done with a return character ^N I think.

As you can see it is pretty basic.

Cheers
JonB
 
Last edited:
Thank you for the valuable feedback. I've already done a few cursor routines and have about 860 bytes of free memory. So I may be able to implement most of Superbrain's escape sequences. Is that set of escape sequences sufficient to run WordStar?
Bill
 
Yes, but it doesn't implement scroll down which impacts performance. Scroll up is done by the <CARRIAGE RETURN> processing.

Regarding the SB BIOS source code.. it's split in two. One part is the publicly disseminated BIOS code that Intertec shared with the machine. The other is the "hidden BIOS" for which there is no official source that I could find. This HBIOS contains the initialisation, disk and console handling service routines. I reverse engineered it, partially, and have a sort of half assed commented listing. You're welcome to a copy, but it probably won't help you unless you are using the same CRTC as the Superbrain. Besides, it's more fun writing the code yourself.
 
FYI, RETURN is ^M and sends the cursor to the left edge of the screen (same line). LINE FEED (^J) is the traditional/simple cursor-down function. But many terminal types define a cursor down ESC sequence, which you probably also need to handle.
 
You must log in or register to reply here.
Back
Top