Standalone RC2014 RomWBW computers

[Bill Shen]

This topic is continuation of the off-topic discussion on "SC126 strangeness".  The new topic has three components:

1. RC2014 hardware (obviously since this is the RC2014 forum),
2. standalone capability exemplified by pi-zero and pi-pico VGA terminals, and
3. RomWBW as the umbrella software for various combinations of RC2014 & clone hardware and evolving video/keyboard boards.  

The best known example of a standalone RC2014 RomWBW computer is RC2014Zed with Pi Pico VGA board.

While RC2014 clone are evolving rapidly, I'm particularly interested in RomWBW's evolution to accommodate various video/keyboard hardware.  Wayne Warthen, the author of RomWBW, has been extremely supportive of new RC2014 hardware and has expressed an interest supporting modularized video and keyboard products.  I see this as an opportunity to bring the video capability close to RC2014--fast direct bus connection instead of over-the-serial-output therefore much more responsive video display.  Separate keyboard interface can also accommodate many different types of keyboard available on the market.

I love to hear about others' video and keyboard products and hope to discuss them in this post.  My contribution to this discussion is the VGARC board which is a monochrome VGA text and PS2 keyboard interface designed in 2019 but ever since I've struggled to get it integrated into my own CP/M, never mind that of RomWBW.  I can really use some help!

Carrying over the previous discussion, I'm delighted to hear from Wayne that PS2 software should be addressed in a separate bank; this should give it enough room to grow.

I thought mapping video RAM to Z80's I/O space is the easy part.  The 4K video RAM has default 8-bit I/O addresses of $20 to $2C.  It is addressed using out (c),a or in a,(c) instruction with regC contains most significant 4 addresses of 4K RAM and regB contains the least significant 8 addresses.  For an example:
    ld c,20h
    ld b,0
    out (c),a
will write regA to first row, first column of the video display.  If b=63 (decimal) for above case, it goes to the last column (column 63) of first row; if b=64, it goes to first column of 2nd row.  You can read back the content of video RAM using in a,(c).  If you look at VGARC schematic closely, you can see the video RAM addresses are swapped such that Z80's A8-A15 are connected to video RAM's A0-A7 while Z80's A0-A3 are connected to video RAM's A8-A11.  This way 4K video RAM's I/O addresses are mapped to 16 contiguous addresses of Z80's 8-bit I/O space, and regBC pair can addresses any location in the 4K video RAM with regB contains the least 8 significant addresses and regC contains the 4 most significant addresses.  Z80's OTDR and OTIR instructions can be used to transfer block of video data.

In the meantime I have works to do.  VGARC has been revised and I've moved on to other video designs.  I need to return back to VGARC and build up a couple board and check them out in a RC2014 Zed clone.
  Bill

[Alan Cox]

> I thought mapping video RAM to Z80's I/O space is the easy part. The 4K video RAM has default 8-bit I/O addresses of $20 to $2C. It is addressed using out (c),a or in a,(c) instruction with regC contains most significant 4 addresses of 4K RAM and regB contains the least significant 8 addresses.

For the video cards my only attempt so far the new EF9345 card is
offboard RAM so just occupies a pair of 8bit ports at 0x44/46.

Keyboard wise the PS/2 card occupies 60/64 (as on a PC so it can be
used with the 80C188 card), and the bitbang keyboard uses 0xBB and
provides various things on that port.

The matrix keyboard for using stuff like ZX81 keyboard mats is a 16bit
card and uses xxFF for read only where for a typical matrix you read
FEFF FDFF FBFF F7FF EFFF etc to send a matrix line low and read back
the result. 00 is not usually useful so you can use it with a Z180
with I/O at C0-FF.

I've actually been using 16bit I/O with a few cards without problems.
The QUART lives on xxBA as it has a lot of I/O ports. The shared
memory bus interconnector uses a 1K range over 4 I/O ports. The bus
extender buffers a second backplane and makes all the cards on that
backplane at port XX appear to be at port XXYY on the main bus (where
YY is configurable). So only 8bit cards can be put behind the buffer.

I've also got a 2S1P card on the kicad drawing board that uses
2F8/3F8/378 for obvious reasons.

Most of the non Z80 cards cannot generate 16bit I/O addresses. The Z8
can, the 68008 can and the 80C188 can. The others have I/O as a 256
byte memory window, or just (8085 for example) don't generate 16bit
I/O cycles.

As an aside - supporting 16bit I/O does actually mean it would be
possible to use C0-FF on a Z180 by just forcing "8bit" I/O to 0x01xx
by default. Does have a performance cost though.

Downside is I/O is slower than memory. A video card that can shadow
main memory (or ROM banks) is faster than an I/O port one. Not that I
imagine it matters with a 4K RAM device.

Alan

[Wayne Warthen]

On Thu, Jan 19, 2023 at 6:17 AM Bill Shen <coinst...@gmail.com> wrote:

I thought mapping video RAM to Z80's I/O space is the easy part.  The 4K video RAM has default 8-bit I/O addresses of $20 to $2C.  It is addressed using out (c),a or in a,(c) instruction with regC contains most significant 4 addresses of 4K RAM and regB contains the least significant 8 addresses.  For an example:
    ld c,20h
    ld b,0
    out (c),a
will write regA to first row, first column of the video display.  If b=63 (decimal) for above case, it goes to the last column (column 63) of first row; if b=64, it goes to first column of 2nd row.  You can read back the content of video RAM using in a,(c).  If you look at VGARC schematic closely, you can see the video RAM addresses are swapped such that Z80's A8-A15 are connected to video RAM's A0-A7 while Z80's A0-A3 are connected to video RAM's A8-A11.  This way 4K video RAM's I/O addresses are mapped to 16 contiguous addresses of Z80's 8-bit I/O space, and regBC pair can addresses any location in the 4K video RAM with regB contains the least 8 significant addresses and regC contains the 4 most significant addresses.  Z80's OTDR and OTIR instructions can be used to transfer block of video data.

OK, this explanation helps a lot.  This will not conflict with other RomWBW components.  Good.

The ability to use OTIR and OTDR is very cool.

In the meantime I have works to do.  VGARC has been revised and I've moved on to other video designs.  I need to return back to VGARC and build up a couple board and check them out in a RC2014 Zed clone.

Don't rush. 😀 I'm way behind on everything right now.

-Wayne

[Bill Shen]

The revised VGARC is working properly.  This is an example of possible standalone RC2014 RomWBW computer with VGARC.  The cards are (front to back) VGARC, 512KRAM/ROM, SIO2, Z80, CF on a RC2014 Back Plane 8.   RomWBW is the standard RC2014 configuration.  I am working on several demonstration CP/M programs to show the capabilities of VGARC.  I'll post them in the next few days.
  Bill
Edit, want to clarify that this currently is a standalone computer with the help of Pi Pico VGA.  I like to see an updated RomWBW that interfaces to VGA terminal and PS2 keyboard through VGARC board.

[Wayne Warthen]

On Saturday, January 21, 2023 at 4:47:14 AM UTC-8 Bill Shen wrote:

The revised VGARC is working properly.  This is an example of possible standalone RC2014 RomWBW computer with VGARC.  The cards are (front to back) VGARC, 512KRAM/ROM, SIO2, Z80, CF on a RC2014 Back Plane 8.   RomWBW is the standard RC2014 configuration.  I am working on several demonstration CP/M programs to show the capabilities of VGARC.  I'll post them in the next few days.
  Bill
Edit, want to clarify that this currently is a standalone computer with the help of Pi Pico VGA.  I like to see an updated RomWBW that interfaces to VGA terminal and PS2 keyboard through VGARC board.

Looks great Bill.  I think RomWBW  just needs a video and keyboard driver to fully support it.  I will gladly work on the drivers, but will need some time to get caught up.  Your demo programs will probably be very helpful.

-Wayne

[Bill Shen]

I'm also not quite ready to release VGARC design.  The graphic generation still have strange artifacts at corners (darn those corner cases!) and I just realize VGARC's I/O addresses, 0x20-0x2F, conflicted with PPIDE, so I changed it to 0x40-0x4F.  The PS2 keyboard registers are still 0xF4 for data and 0xF5 for status, I hope there are no conflicts with existing RC2014 boards.  Programming the demos are helpful in finding design issues.  Attached is animated GIF of three demo CP/M programs loaded in RomWBW and executed in quick succession.  The first two seconds is a program displaying a static banner, followed by second program that tears down the banner one column at a time, and last is Game of Life--Gosper glider gun.  The demo codes (banner.asm, matrix_scrnsvr.asm, life_glider48x64.asm) are attached.  These three programs only show the VGA portion of the hardware.  I'm working on a buggy version of CP/M that takes input from either PS2 keyboard or TeraTerm terminal and displays output on both VGA monitor and TeraTerm terminal.  It may never be ready for prime time, but does show VGARC's potential supporting standalone operation.  I'll make a demo and include the code when it stops crashing intermittently.
  Bill

[Bill Shen]

The demo GIF is too large for Google Forum, I'm cutting it down and re-post.

[Alan Cox]

On Sun, 22 Jan 2023 at 14:39, Bill Shen <coinst...@gmail.com> wrote:
>
> I'm also not quite ready to release VGARC design. The graphic generation still have strange artifacts at corners (darn those corner cases!) and I just realize VGARC's I/O addresses, 0x20-0x2F, conflicted with PPIDE, so I changed it to 0x40-0x4F. The PS2 keyboard registers are still 0xF4 for data and 0xF5 for status, I hope there are no conflicts with existing RC2014 boards. Programming the demos are helpful in finding design issues. Attached is animated GIF of three demo CP/M programs loaded in RomWBW and executed in quick succession. The first two seconds is a program displaying a static banner, followed by second program that tears down the banner one column at a time, and last is Game of Life--Gosper glider gun. The demo codes (banner.asm, matrix_scrnsvr.asm, life_glider48x64.asm) are attached. These three programs only show the VGA portion of the hardware. I'm working on a buggy version of CP/M that takes input from either PS2 keyboard or TeraTerm terminal and displays output on both VGA monitor and TeraTerm terminal. It may never be ready for prime time, but does show VGARC's potential supporting standalone operation. I'll make a demo and include the code when it stops crashing intermittently.

40-4F clashes with the floppy and FPU card

Right now
0x0X is usually free (although it might have GPIO on it and is being
discussed for console switches) and
some people have Z80 DMA there
0x1X is CF
0x2X is PPIDE or second CF
0x3X is MMU on non 512K
0x4X is all sorts of stuff including 48 being the standard floppy DCR
0x5X is the standard floppy (free with my floppy card but that doesn't
help most people)
0x6X is PS/2 PIO, SD, GPIO and AY-3-8910 for Z180 (as can't use Dx)
0x7X is MMU
0x8X is SIO, CTC etc
0x9X is TMS9918A (and mirror of CF in low half)
0xAX is UART
0xBX is all sorts of stuff in small chunks
0xCX is RTC
0xDX is sound on Z80
0xEx seems to mostly be non Z80 UART
0xFX has oddments in it mostly at 0xFC-FF

Cx-Fx can't be used with the Z180 unless either you play games though

For the 0x4X range 48 is the floppy DOR, 42/43 seem to be the usual
FPU addresses

[Bill Shen]

It's hard to find 16 contiguous I/O addresses in RC2014 world!  I should make it jumperable, who know, people may be interested in multiple VGA monitors.  VGARC does need a default base address and  I/O addresses 0x0-F are intriguing.  RomWBW put data out to 0x0 when powering up so VGARC mapped to 0x0 may have diagnostic values, but RomWBW may also write data to 0x0 during normal operations so that can mess up first row of the screen, unless we turn that into a "feature" and called it "system status" line.  ;-)

I changed VGARC's I/O addresses to 0x0-0xF, loaded the font table and pressed reset button to boot RomWBW.  Photo "RomWBW_bootscreen" shows what's written to 0x0 when booting.  I noticed RomWBW put 0x2 and 0x4 when executing various CP/M commands.  Hopefully that can be disabled.

I need to re-read the post about "digital I/O input at startup", but if it only fiddled with 0x0 during startup, I don't think it is an issue with VGARC.

With the font table loaded, this small CP/M program will display photo "font_table"
   org 100h
   xor a
spin:
   out (0),a
   inc a
   jr nz,spin
   ret

Useful little program, I renamed it 'chkfont.com'.
  Bill

[Wayne Warthen]

On Sunday, January 22, 2023 at 11:41:02 AM UTC-8 Bill Shen wrote:

I changed VGARC's I/O addresses to 0x0-0xF, loaded the font table and pressed reset button to boot RomWBW.  Photo "RomWBW_bootscreen" shows what's written to 0x0 when booting.  I noticed RomWBW put 0x2 and 0x4 when executing various CP/M commands.  Hopefully that can be disabled.

Yes, RomWBW uses the LEDs at port 0x00 during normal operation to display disk activity.  The first 8 disk units are mapped to the 8 LEDs such that the corresponding LED is lit when the disk unit is active.   Yes, it is possible to disable the writes to 0x00.  It is indeed difficult to find any available I/O space in the RC2014 family.

Thanks,

Wayne

[Mark T]

You could try using a single IO address and then the high 8 address lines to select each of the 16 addresses. Alan has used that trick a few times.

[Mark T]

Sorry, just realised you are already using the high address lines for the video ram addressing.

[Phillip Stevens]

On Monday, 23 January 2023, Alan wrote:

On Sun, 22 Jan 2023, Bill wrote:
I'm also not quite ready to release VGARC design. The graphic generation still have strange artifacts at corners (darn those corner cases!) and I just realize VGARC's I/O addresses, 0x20-0x2F, conflicted with PPIDE, so I changed it to 0x40-0x4F. The PS2 keyboard registers are still 0xF4 for data and 0xF5 for status, I hope there are no conflicts with existing RC2014 boards.

40-4F clashes with the floppy and FPU card

For the 0x4X range 48 is the floppy DOR, 42/43 seem to be the usual FPU addresses

Yes. The AM9511A (I8231) APU Module uses 0x42/0x43 by default. Although there are plenty of other ports it could use too. So it wouldn't be too hard to reconfigure things if someone was building a system with a video card.

Having these defaults just means that the MS Basic ROMs with APU enabled will work out of the box, which might make it a bit easier for most people. Post Chinese NY break I will have a revised APU Module PCB for 2023 available.

Cheers, Phillip

[Alan Cox]

Do you have enough macro-cells to make the page latch so it could be
two ports say

XX40 - transfer to lower
41 - set the upper bits

[Bill Shen]

The CPLD is about 80% utilized so there should be room for indirect addressing scheme.  I thought I/O locations 0x0-0xF are suitable?  I like to reserve the remaining CPLD for a couple hardware features: hardware scrolling, and hardware cursor.  Without hardware scroll, I need the direct access capability to move 3K block of data quickly.  I also thought about 2nd 4K dual-port RAM for color attributes, but that'll take even more contiguous I/O space unless I have a gating logic directing access to either color attributes or video texts.

This is where I/O mapping may be abandon in favor of banked memory access which also have the advantage of an unified VGARC design for 6502, 68K, and Zx80.

Of course we can also think about banked I/O access.  Shocking--64K of native I/O space is not enough so now I'm even considering banked I/O!  Something to be said for Z280 which has 16meg I/O space!
  Bill

[Bill Shen]

I have implemented hardware cursor and hardware scroll in the CPLD.

Hardware cursor is a 8-pixel long, 2-pixel wide underscore below a character.  There are 128  display characters from 0x0 to 0x7F.  Underscore for corresponding character is displayed when bit 8 of a character is set.  e.g., 0x33 is "3", but 0xB3 is "3".  Software can blink the cursor by alternatively writing 0x33 and 0xB3.  It turned out the hardware cursor circuitry was easy to do.

Hardware scrolling circuit was a lot harder to do.  I almost gave up on the idea, but ultimately I have a 6-bit write-only register at PS2 status register location of 0xF5.  Writing 0 set screen to no scrolling (reset value is 0); writing 1-47 scroll the screen 1 line to 47 lines, respectively.  Attached video shows the screen scrolled from 1-47 lines and stop at no scroll.

Now I'm ready to check out the video/PS2 hardware with a version of CP/M that takes input from PS2 keyboard as well as the console serial port and sends output to both VGA monitor and the console.

I think it is easy to write Tetri and Space Invader games for this hardware; screen editor seems a natural fit as well.

  Bill

[Alan Cox]

Hardware cursor is a 8-pixel long, 2-pixel wide underscore below a character.  There are 128  display characters from 0x0 to 0x7F.  Underscore for corresponding character is displayed when bit 8 of a character is set.  e.g., 0x33 is "3", but 0xB3 is "3".  Software can blink the cursor by alternatively writing 0x33 and 0xB3.  It turned out the hardware cursor circuitry was easy to do.

Inverse might be better. Not so much about cursor style but a full byte inverse means that you've

got 128 characters plus inverses which if you load the right font is 2 x 4 blocks giving you a bitmap resolution of 128x192 or 256x96 which is actually better than some of the early home micros 8)

Having programmed similar hardware I think that if you can write the screen without flicker and load the graphics characters without flicker as I assume is possible then a lot of game stuff ought to work fine. Certainly good enough for Elite 8). 

Given a vblank int to sync off you can probably also chase the scan (especially with Z180 DMA ;)). You'd need the CPU clocked with a divder from the VGA clock to do real fun stuff reliably I suspect - stuff like changing the row as it is scanned so you can get a better resolution 8)

Alan

[Bill Shen]

Inverse is easy to do, it is a matter of XOR the pixel bit stream with bit 8 of the character.  I see what you meant that 128 block fonts can be doubled to 256 with inverse, enough to do all permutation of 2x4 blocks.  My character is 8x8 pixels, so 2x4 pixel size may be weird, but it is worth a try.

VGARC can load fonts and write characters any time without flickering.  I like to think that can be exploited for interesting games, but I have no game programming experience at all.  The vertical scrolling circuitry is also applicable to horizontal scroll, so I imagine XY panning is also do-able.  

I'm looking at petscii animation and thinking that should be easy to do if only I'm better at manipulating video images, or if I can find existing video-to-petscii conversion software for 64x48 screen size.

I have overclocked 6502 to 25.175MHz and did a brute force beam racing on 640x480 VGA.  Recently I was successful overclocking 6502 to 36MHz so I should be able to race 800x600 SVGA.  Z80 can run at 25MHz easily and POP instruction can fetch 16-bit data in 10 clocks, so I thought about beam racing with Z80 as well, but haven't done anything.
  Bill

[Bill Shen]

I have a CP/M program (cpmvgarc.com) running inside RomWBW CP/M environment that replaces existing CCP/BDOS/BIOS with a new BIOS that use PS2 keyboard and VGA text output.  it also initialize VGA's font lookup table.  It uses the same disk definition so existing CP/M files are accessible.  cpmvgarc still interfaces to the existing serial console so I can add/update files using xmodem.  It works with many CP/M programs, but programs using escape sequences for cursor movement (e.g., ZDE) does not work.  I'm not sure how programs like ZDE and WordStar dealt with different kind of terminals, perhaps the same method can be extended to support VGARC?

Current setup is Z80 at 7.37MHz, SIO2, CF, 512K RAM/ROM, and VGARC on RC2014 backplane8.  I'm glad to have hardware scroll function otherwise manually moving video memory up one row at 7.37MHz is noticeably slow.

I attached the source for cpmvgarc.com.  
  Bill
PS, I've adopted Alan Cox's suggestion of inverse video for characters greater than 127 so I can play with 2x4 blocks.  It is rather fun, but aspect ratio is off by a factor of 2.

[Wayne Warthen]

On Thursday, February 9, 2023 at 5:53:45 AM UTC-8 Bill Shen wrote:

I have a CP/M program (cpmvgarc.com) running inside RomWBW CP/M environment that replaces existing CCP/BDOS/BIOS with a new BIOS that use PS2 keyboard and VGA text output.  it also initialize VGA's font lookup table.  It uses the same disk definition so existing CP/M files are accessible.  cpmvgarc still interfaces to the existing serial console so I can add/update files using xmodem.  It works with many CP/M programs, but programs using escape sequences for cursor movement (e.g., ZDE) does not work.  I'm not sure how programs like ZDE and WordStar dealt with different kind of terminals, perhaps the same method can be extended to support VGARC?

This looks really good Bill.  Not sure about ZDE, but there were modified versions of WordStar that shipped with systems that had built-in terminals.  I have a Visual Technologies V1050 that has such a custom version of WordStar included.  ZDE has source code, so you could potentially modify that, but I have never seen WordStar source.  RomWBW implements a software layer with ANSI/VT-100 emulation between video display hardware and CP/M character I/O.  A VGARC driver in RomWBW will inherit this automatically.  I will take a look at your code since it probably forms the basis of a driver for RomWBW, but I won't be able to work on the driver for a bit.  I'm deep into finalizing RomWBW for a new (long overdue) stable release.

-Wayne

[Mark T]

For wordstar I think there was a configuration program to select the control codes used. Not sure if I remember correctly but I think it patched the wordstar executable file. Its been a long time and many braincells died or replaced since then so I might not be remembering correctly.

[Wayne Warthen]

On Thursday, February 9, 2023 at 10:08:47 AM UTC-8 Mark T wrote:

For wordstar I think there was a configuration program to select the control codes used. Not sure if I remember correctly but I think it patched the wordstar executable file. Its been a long time and many braincells died or replaced since then so I might not be remembering correctly.

Yes, that is absolutely correct.  The WordStar disk image in RomWBW has all of that.  I assumed that Bill wanted to integrate his hardware directly with the VGARC, but the other approach is to add a terminal emulation layer that is compatible with WordStar escape sequences.

-Wayne

[Bill Shen]

It is a complete mystery to me how screen-based CP/M software dealt with large assortments of terminals before cursor controls were standardized.  There must be an assortment of helper software that users can configured to run with their particular brand of terminals.  My fear is the interface protocol was proprietary and never published.  I suppose if every one of these screen-based software can interface to VT100, then I don't need to know the proprietary interface, just work with VT100 protocol and convert it back to memory mapped video screen positions.  But what a waste of computer resource--all that serial escape sequence to position cursor when hardware can do it easily with direct memory mapping.  Oh well.

Please take your time, Wayne.  You are way better than me dealing with system level programming.  In the meantime I'll do more demo programs to check out the hardware.  Let me know when you are ready so I can ship a board your way.  BTW, the homepage for VGARC is here.  I have a section on Theory of Operation where I attempt to explain how this thing works and how to interface to it from programmer's point of view.

I have high hope for this board; beside RC2014 Zed/Pro/Mini, I expect it to work with a number of my own hardware (did quite a bit of testing with ZRC already) as well as other's such as Steve Cousin's SC114, SC108.
  Bill

[kurt....@web.de]

Hello Bill,

I count myself among the users of a Z80 system
SC114, 24a (Z80 20Mhz) karlab 2020, SC126 and some other boards on Basic R2014 I soldered with a lot of fun and all worked immediately.

What should I write. Good job by the suppliers and lucky for me.

I think the development of the VGARC is good.
As I explained above, I need a kit VGARC.

Please consider that the mass of users is not on the level of Wayne, Bill, Philipp and Stephen and some more.

Wherein the term mass in the RC80 range (new consideration) too
put into perspective.

Few CPM users are still active in Germany in the GABY Forum.

One last thing.
Unfortunately, in many forums about retro computers, mostly hardware and software, games from the old days are collected. Software development with BASCOM, SBASIC, COBOL 80 less.
why? STM* , Raspberry Pi, Arduino etc. is in the century.

I've noticed that some compilers are rarely used or reported. Software and hardware are closely related.
Let's call it SBASIC, COBOL 80, FORTRAN 80, TURBO Pascal. Nobody knows KSAM80?
BASCOM, MBASIC and C are used more often.
I like to deal with this compiler and above compiler..

OK, a lot around. Where can I get a kit VGARC?
I'll mention the kits from Steve Cousins. That's how I imagine it.

Greetings from the Rhine

Kurt

This is my favorite Z80

[Alan Cox]

On Fri, 10 Feb 2023 at 01:32, Bill Shen <coinst...@gmail.com> wrote:
>
> It is a complete mystery to me how screen-based CP/M software dealt with large assortments of terminals before cursor controls were standardized. There must be an assortment of helper software that users can configured to run with their particular brand of terminals. My fear is the interface protocol was proprietary and never published. I suppose if every one of these screen-based software can interface to VT100, then I don't need to know the proprietary interface, just work with VT100 protocol and convert it back to memory mapped video screen positions. But what a waste of computer resource--all that serial escape sequence to position cursor when hardware can do it easily with direct memory mapping. Oh well.

Most systems emulated adm3a, vt52 or later, sometimes vt100. It was a
problem - but not as big as you might think. Printers were at least as
bad if not worse.

- In earlier CP/M days all the disk formats were gloriously
incompatible so you'd generally not buy XYZ for CP/M but you bought a
disk in the format your machine could read, which was generally
pre-configured
- A lot of screen based software had a page in the manual that told
you where to ddt in the video strings with examples. Usually they'd
have a patch area low down. That was normal tech user understanding
level, and business users would be working through suppliers who did
it for them.
- Better apps had a configuration program (eg for Wordstar) that did
the patching in human-speak. Wordstar actually came as an install
package, not the way you find it today on CP/M installs.

It did become more of a problem later when disk formats got a bit more
sane and common, and machines more accessible - but things like the
Zsystem formalized the interface for terminal strings and some of the
banked bioses could flip between terminal emulations. Even then a lot
of software was still sold pre-configured for the common machine
types.

There were other tricks too - like loading a CP/M resident program
that patched the BIOS vectors and translated adm3a into whatever
weirdness your vendor inflicted on you and adm3a.

Doing it directly causes a whole replacement raft of problems, as the
8086 folks found out rather quickly when bypassing the BIOS
- Video might be character or bitmap based
- The size varies
- The font map varies
- The memory layout of many devices was 'interesting'
- There are a million different ways to lay out bitmaps
- You may or may not be able to access video memory all the time without noise
- Video memory is banked and page differently in different systems

which in practice very rapidly became "IBM PC with MDA, CGA or bust"

[Pellatonian]

"It is a complete mystery to me how screen-based CP/M software dealt with large assortments of terminals before cursor controls were standardized."

Back around 1983/84 I bought used my first 8" enclosure with a pair of Shugarts installed. In one of them I found a diskette with the WordMaster release files. It included 4 or 5 snippets of code implementing the key mapping of the function keys for various commonly used serial terminals. You would assemble the appropriate snippet with ASM and merge it with the main WM.COM using ddt, then SAVE xx WM52.COM, for example.

I still use the same WM for all my code editing on CP/M systems.

[Bill Shen]

Oh what a mess!  I guess the chaotic CP/M world was setting up to be replaced by big, established IBM with brand computer systems.  I lived through the CP/M time, even had (still have) a S100 Z80 system, but was too busy designing embedded computers which had no keyboard/monitor/disk/printer, so here I am, retracing the CP/M revolution 40 years later.  OK, so the takeaway here is no cohesive solution and expecting every software to do screen functions differently.  Interfacing at VT52 level may turn out to be the best solution after all.

Regarding VGARC kits; it is too early and I still need to do testings on a number of my own hardware and Steve Cousin's SC114/108/126.  VGARC rev1 is also too difficult to assemble with QFP100 CPLD, so it is likely to be redesigned as PLCC84.  I'm not certain how it will work with different brands of VGA monitor and PS2 keyboards (I'm using Dell keyboard), so I'm not offering kits right now.  I am building up all 10 pc boards, saving 5 for myself, reserving one for Wayne W., and giving away the rest for people (in USA) willing to test it.  
  Bill

[Bill Shen]

Alan had mentioned using bit 7 of characters as inverse video bit and effectively double the number of fonts, specifically all permutations of 2x4 graphical fonts.  Hardware-wise, it is simple--just exclusive-OR bit 7 with pixel output stream, but mapping graphic to resulting 2x4 fonts and dealing with aspect ratio are more difficult.  Here is the 256 2x4 block fonts:

The screen resolution is 256x96, but the blocks are twice the height to width, it needs to display graphic that's 256x192 but with half the resolution in vertical direction, i.e., display every horizontal pixels but sampling every other vertical lines.  So this is what I got 256x96 (top pic) vs original 256x192 (bottom pic).  



Not so good, but I should try animation next because our eyes have wonderful ways of merging crude images into quality video.
  Bill

[Alan Cox]

On Fri, 10 Feb 2023 at 14:55, Bill Shen <coinst...@gmail.com> wrote:

Alan had mentioned using bit 7 of characters as inverse video bit and effectively double the number of fonts, specifically all permutations of 2x4 graphical fonts.  Hardware-wise, it is simple--just exclusive-OR bit 7 with pixel output stream, but mapping graphic to resulting 2x4 fonts and dealing with aspect ratio are more difficult.  Here is the 256 2x4 block fonts:

The screen resolution is 256x96, but the blocks are twice the height to width, it needs to display graphic that's 256x192 but with half the resolution in vertical direction, i.e., display every horizontal pixels but sampling every other vertical lines.  So this is what I got 256x96 (top pic) vs original 256x192 (bottom pic).  

Not so good, but I should try animation next because our eyes have wonderful ways of merging crude images into quality video.

That would have been state of the art 8)

For a line drawing I'd possibly also the logical or of the two pixels rather than sampling only half.

I am sure it'll look fine with Bad Apple.  Heck Zaxxon on the TRS80 model 1 was lower resolution than that (128 x 48)

https://www.youtube.com/watch?v=2QtX5RPb8Tc&t=81s

[Bill Shen]

I'm still adding features to the VGARC board.

So far both VGA and PS2 interface do not require interrupt.  Everything is based on polling. 
*  Video works through dual-port RAM so data can be written anytime.  It is not necessary to wait for blanking period to write. 
*  PS2 inputs are slow so by driving PS2 clock line low when a keystroke is received and not yet read, I force PS2 keyboard to buffer the remaining key strokes until VGARC reads the one that's in the receiving buffer.

Having said all that, there is this nice 60Hz vertical sync for interrupt generation and long video blanking period to do something (I don't know what at this moment).  The CPLD is 90% filled, but it doesn't take much logic to enable interrupt, show interrupt source status, and clear a particular interrupt.  So I can't resist and added an interrupt enable bit at d[6] of PS2 status register (0=disable, 1=interrupt asserted when video blanked).  d[7] of the PS2 status register shows the vertical blanking status (1=video blanked, 0=video active).  Writing "1" to d[7] of PS2 status register clear the interrupt generated by the assertion of current video blanking.  These set of features enable/disable interrupt, identify the source of interrupt, and clear interrupt source without disabling subsequent interrupts.

Unfortunately VGARC's clock is synchronous to Z80 clock, otherwise I may be able to predict the exact location of the VGA "beam" and possibly do something interesting.  Hmm, I do have Z80ALL with Z80 operating at 25.175MHz synchronous to VGA timing, but that's a different topic.
  Bill

[Bill Shen]

I meant to say in last paragraph that " Unfortunately VGARC's clock is asynchronous to Z80 clock..."