MC6845 video card idea

[E Hazen]

Hi Folks-  Thanks for letting me join.  I developed Z80 systems professionally for many years in the 1980s and have built a few Z80-based gadgets recently 

(see e.g. https://github.com/eshazen/retro-25).

Back on topic:  I'm about to take the plunge and set up an RC2014 system as I'd like a working Z80 development/toy system and don't want to re-invent it all.  I'd like a video card, so I can run things like WordStar and VEDIT in memory-mapped mode under CP/M.  But there doesn't seem to be a simple 24x80 capable text video card yet using period-appropriate technology.  I have an evolving design based on something I did 40 years ago.  Right now it's monochrome (one attribute bit which could support two colors), text only, 640x480 with 30x80 character cells 8x16 pixels each.  Problem is, no way it can fit on an RC2014 board.  It just about fits in 100x100mm.  So, my idea is to make two RC2014 boards in a sandwich with a board-to-board connector.  The attached illustrates the issues with a more-or-less complete complement of parts.

It would be "easy" to extend the design to support for example 640x480 16 color graphics but that would require more boards for the RAM.

What do people think?  (I always regret asking that in forums, be nice!)

[Randy Mongenel]

Welcome, Eric!

I think that's fantastic! I'm not sure I've seen a dual-card solution for RC2014 yet. There are some other video modules available that I'm assuming you've seen, and some pseudo modules like the BusRaider that can emulate video hardware with a Raspberry Pi on the bus.

There's also a huge long-card: https://www.cocoacrumbs.com/blog/2021-05-15-retro-vga-terminal_part_1/

Your idea looks pretty clean.

-Randy

--
You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/9d8a2b4f-b1e2-4021-a3c6-ce8806e1eb35n%40googlegroups.com.

[E Hazen]

Yes, I've seen now Koenraad's really nice color terminal

Here is what I am actually dreaming of.  An "RC2014 portable" with built-in VGA resolution
display.  I'd 3D print the case and have some sort of sturdy cover so I could carry it around.
Many details still missing...

[Koenraad Van Nieuwenhove]

There is another 6845 like (it uses a HD6445CP4J from Hitachi instead) based VGA board that you can take inspiration from:

    https://www.retrobrewcomputers.org/doku.php?id=boards:ecb:vga3:vga3

This is slightly smaller than mine (10 by 16 cm, thus 4 cm shorter) but it has no intelligence. Meaning it need a processor card to drive it (my board has its own Z180). But it could be memory mapped in a Z80 address space.

It also uses a period correct 8242 CPU for PS2 keyboard decoding but minus points are that it is a 4 layer board (more expensive) and a few GAL chips which need programming. It's still relatively large but I'm afraid you can't get it much smaller than this if one wants to use period correct chips.

Best regards,

Koen

[Alan Cox]

On Wed, 8 Sept 2021 at 15:03, E Hazen <erics...@gmail.com> wrote:

Back on topic:  I'm about to take the plunge and set up an RC2014 system as I'd like a working Z80 development/toy system and don't want to re-invent it all.  I'd like a video card, so I can run things like WordStar and VEDIT in memory-mapped mode under CP/M.  But there doesn't seem to be a simple 24x80 capable text video card yet using period-appropriate

The Thompson chips are joyously weird and horrible but can do 80 column RGB. The big problem of course is that composite bandwidth isn't good enough for 80 column. There is also a TMS9958 card for RC2014 which is a more modern chip but not hugely so. The 6545 can do VGA but it's even more complicated as you have to make the RAM 16bit wide as seen by the shifters.

technology.  I have an evolving design based on something I did 40 years ago.  Right now it's monochrome (one attribute bit which could support two colors), text only, 640x480 with 30x80 character cells 8x16 pixels each.  Problem is, no way it can fit on an RC2014 board.  It just about fits in 100x100mm.  So, my idea is to make two RC2014 boards in a sandwich with a board-to-board connector.  The attached illustrates the issues with a more-or-less complete complement of parts.

It would be "easy" to extend the design to support for example 640x480 16 color graphics but that would require more boards for the RAM.

You should be able to use a single 32K SRAM for 640x200 mono (320x200 4 colour, 160x200 160). The Amstrad CPC machines did this with a 6845 (or gate array clone thereof on all but the earliest). To keep it simple they also didn't bother with the character ROM stuff but ran entirely bitmapped.

What do people think?  (I always regret asking that in forums, be nice!)

Did you look at the 6545 as that has a ton of the needed glue on board for running with private video memory and writing through the 6545 to it so may reduce the chip count a lot.

Alan

[Andy Nicol]

Hi, Eric. I'm really looking forward to seeing this project take shape.

You might want to consider making a motherboard with video and bus, which would remove the constraints of size and layout.

Andy

[E Hazen]

Thanks for all the interest.  There are a bunch of good ideas out there. 

 
I would like to stick with VGA 640x480 standard timing to maximize monitor compatibility (I'm not interested in driving old TVs at NTSC rates).  For 8 pixel wide characters this requires a 3.15MHz character clock rate.  Original 6845s can't run this fast.  Solutions are to (a) use a faster compatible part (e.g. MB89321 or HD6845S) or (b) as Alan suggests launch 16 bits per character time (so the CRTC thinks it's 40 columns) and run the clock at half speed.

Option (a) requires difficult-to-source parts.  Option (b) requires more parts, but also opens the door to color/graphics more easily.

Some other good thoughts...

- Alan suggests a 6545, which allows the CRTC to handle memory access through a set of registers.    These are limited to AFAIK to 2.5MHz character rate, so would require the solution (b) above.  Not sure how the transparent mode would work with 16-bit wide memory, probably not very cleanly though this requires some study.

-  Koen's color terminal project is very inspiring, and honestly with a good terminal implementation the performance is probably the same as memory-mapped, but the parts count is pretty high.

-  Andy suggests a motherboard with video and bus.  Maybe video and backplane?

I'll keep thinking.  Luckily PCBs are dirt cheap now and if I socket all parts I can re-use freely.  So I'm thinking of a prototype which doesn't attempt to fit in RC2014 form factor but has a compatible bus connector to get things moving, then I can repackage in RC2014 cards.  I'm leaning towards the multi-byte per character memory so it can run with a stock MC6845 for parts availability.   

Back to the day job for a bit :)

[Koenraad Van Nieuwenhove]

Maybe I have a few other suggestions to explore:

• I don't think it would be too much work to extend my design with some extra RAM/ROM and a RC2014 bus and become a standalone CP/M computer with a memory mapped display. So the motherboard would in essence have video, CPU, RAM and ROM and some additional RC2014 bus connectors for expansion.
• Use a NEC uPD7220 graphics chip (the lowest 5MHz part easily drives 640 by 480 and 800 by 600 as well). If you want color then chip count will be high as well unfortunately but you would get some powerful graphics capabilities in return. I'm working on such a card and it finally starts working. The 7220 takes quite some power though (1.5 Watt) and becomes warm. Might not be the best choice if you want to run on batteries.
• Use modern solutions:
  • A 7 inch SSD1963 as is used in the Z20X computer. Rather cheap with a 800 by 480 resolution. Not that easy to program though (I wrote a blog post once about that) and it's rather slow. There is a huge amount of write operations to be done to just write one character to the screen. Every pixel needs 3 bytes. A 8 by 8 character needs 64 * 3 = 192 bytes to be written to the SSD1963.
  • Use a Gameduino 3X Dazzler. This outputs HDMI @ 1280x720 and is very powerful. But it needs an SPI interface. Isn't that easy to program neither. I'm currently working on an expansion card for the Z20X computer using this Gameduino to replace the SSD1963. That should be a better fit for the powerful eZ80.

For enclosure, maybe it could be an idea to find a not working TRS model 100? If it's broken it's not a shame to remove the internals, replace the old LCD with a modern colour LCD (can easily be found at AliExpress). There is a hackaday article that reminded me of that option. Based on your sketch it might be around the size you want.

Clockwork is also producing a small terminal like the model 100 (DevTerm). Might be interesting to see how they fit things together maybe.

Best regards,

Koen

[Keith Howell]

https://hackaday.io/project/177693-stebus-80x25-character-text

This provides an 80x25 monochrome terminal with just a 40-pin chip and a small SRAM chip.

You could put a 0.3" RAM chip under the socketed 40-pin chip.

Most of this board is bus buffers (which RC2014 omits) and decoding logic.

It uses the SMC 9153 chip which is period-appropriate but not easy to obtain.

I can't find any for sale on the net, but you might have better luck.

On Wed, 8 Sept 2021 at 15:03, E Hazen <erics...@gmail.com> wrote:

[E Hazen]

Interesting.  A quick search didn't even turn up a datasheet for the SMC 9153.  Does anyone have a pointer to it?

Ideally I would use a part which is readily available so others can build boards, thus my leaning to the standard MC6845.  However that requires either dual RAMs or a fancy scheme to grab two bytes per character clock.

Also I'd like to support the 640x480 non-interlaced timing of VGA so that commodity LCDs can be used.
Most "period correct" solutions go for NTCS or PAL timing, which doesn't work with most modern VGA LCDs.

These are of course all arbitrary choices on my part! 

[Ed Porter]

On 15/09/2021 15:40, E Hazen wrote:
> Interesting.  A quick search didn't even turn up a datasheet for the SMC
> 9153.  Does anyone have a pointer to it?

Page 401 of this 60M pdf:

http://bitsavers.org/components/standardMicrosystems/_dataBooks/1988_Standard_Microsystems_Components_Catalog.pdf

[E Hazen]

I'm giving up on the 6845 for now.  Too many parts!  As I mentioned in another thread, I have a working text console using an FPGA board, which is fun to play with.

Now I've started a NEC uPD7220 board!  This will deserve it's own thread if it gets working.  
First version is very simple... intended to run monochrome at up to about 800x600.
The 7220 was cool in it's day, and quite easy to use.  The main problem with it is that it can only (easily) run up to 40MHz pixel clocks which doesn't allow for any VESA-compatible resolutions about 800x600.  There is a "wide mode" where you load 32 bits out of the RAM each cycle but that involves a lot of extra chips.

Schematic attached is still not too optimized but it's close... pretty much follows the NEC manual schematic.
Also it won't fit on a single RC2014 board.  For the prototype I'll just make the board bigger, I think, but eventually
maybe a two-board stack?

This is how I spend my holiday breaks... furiously running KiCAD.  My wife just doesn't understand...

[Phil G]

I found the 6845 easy to use software wise but from a hardware perspective I always thought it was only half a video chip, leaving so much more to do externally, quite messy   ;)
For 'serial' video in a few projects I've used Geoff Grahams single-chip terminal, its very good, It can do 1M bps and can fill its PAL screen-buffer in under 9ms (over 100 frames/sec) 

Cheers

Phil

[Mircea Teletin]

Hi all, I've been watching this thread for a while. I too have given a lot of thought on this subject and I already made some efforts into making such a video interface, did the schematics, ordered PCBs and now all I have to do is find tome to write the firmware for the MCU driving it.

Meanwhile however... I was looking at some weird incomplete spectrum clones that I had laying around (by incomplete I mean missing case, bad keyboard but complete electronics).

I was thinking... if I remove the CPU from one such board... I could use it as a video card! Albeit only with a TV (could use one of that GBS converter that I also have laying around). They don't have the typical ULA chip but do the same thing with many discrete ICs.

I could use it at some sort of memory mapped device... join the bus from it to an RC2014 for example with some logic glue to be able to select which pages the CPU actually sees.

Added bonus, the video would be ZX Spectrum compatible.

What do you think about it?

--
You received this message because you are subscribed to a topic in the Google Groups "RC2014-Z80" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rc2014-z80/GL2yX4O5yOQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to rc2014-z80+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/ce2f44e5-a91c-40e5-85f5-c0b9e8d66432n%40googlegroups.com.

[Samuel Falvo II]

Hello,

I know you mention "period-accurate", but if you're willing to bend on that requirement a bit, please note that I have been working on a MOS 8563 compatible FPGA core called VDC-II.  https://hackaday.io/project/170581-vdc-ii

Disclaimer: the core isn't finished; but, as you can see from the pictures in the gallery and project logs, it's complete enough to usefully render a display.  It can handle VGA resolutions in text-mode, but not yet in graphics mode (one of the missing pieces I still have on the back-burner).  It also doesn't yet implement the hardware cursor.  But, it *does* support 512 characters like the 8563 did.

Development has been stagnant for about a year due to me changing jobs; but, I'm looking to completing its basic feature set (and implementing support for per-character-cell background colors) later this year.

[Alan Cox]

On Fri, 31 Dec 2021 at 14:36, 'Phil G' via RC2014-Z80 <rc201...@googlegroups.com> wrote:

I found the 6845 easy to use software wise but from a hardware perspective I always thought it was only half a video chip, leaving so much more to do externally, quite messy

On the bus side this is because it's designed for a motorola style bus sharing scheme. It combines with a 65xx/68xx processor to provide the DRAM refresh and video on the other half of the clock cycles and was originally designed so that it and the CPU ran off the same clock. The 6545 addressed this by adding some additional logic to support driving it as an I/O device with memory separated from the main system memory. Hooking up a 6545 is way easier although for VGA modes you need 16bit wide RAM and shifters so you need to mux the 16bit wide memory on the video side into two banks on the CPU side (eg by making A0 on the CPU bus the bank select)

The integrated option was the 6847, which again was designed to be nailed to a 68xx processor and run with the same clocks (as it does on the Tandy MC-10). On the 6800 it doesn't expect much but a RAM chip, modulator and a small bit of glue to sync it to the CPU, on the 6809 it was instead run with a 6883 (74LS785).

It can be driven with a bit of glue from a Z80 (eg the Vtech VZ200 systems from Hong Kong that were shipped under a bunch of brands - Seltron/Smart Alec/Salor/Texet/Dick Smith etc). If you don't mind noise on video updates the Z80 interface is really quite simple but you have to software handle vblank waits for update.

For a really simple video interface that would probably work out ok with a Z80 style bus take a look at https://www.waveguide.se/?article=bitmapped-video-interface

Note that you can simplify this design a lot further by replacing most of the counting logic with a EEPROM burned with a table of hsync/vsync/reset etc bits and clocked from the same base counter. The important trick is the latches and video timing so that the video writes don't interfere with the display. The same ought to work with a 6847 for the rest of it.

[Eric Hazen]

Hi Folks-

Yes, an FPGA is an attractive solution.  I have a working (for me) text console as I've mentioned elsewhere in the group.  It does enough ANSI to keep me happy.

See: https://github.com/eshazen/z80system for PCB designs / code.

It supports 80x40 text at 640x480 using standard VGA timing on a Xilinx
Artix-7 FPGA module (Digilent CMOD-A7).  At US$75 the module is a bit expensive.

For now I'm happy with this now that I have it packaged up in an RC2014 board
and I'm moving on to a 7220 graphics board (see another thread about this).

As everyone knows, for the most part it's about the journey, not the destination :)

--
You received this message because you are subscribed to a topic in the Google Groups "RC2014-Z80" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rc2014-z80/GL2yX4O5yOQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to rc2014-z80+...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/fd9d4a7e-c727-4125-881b-d243f386f5a9n%40googlegroups.com.

[stanton 510]

I'm planning on making my EP2 (Altera Cyclone II) FPGA 80x60 (640 x 480ish) compatible (once I get the system running smoothly)
It's got a 256 charset, but all re-definable (not colour though, as not enough RAM in the Cyclone 2 internally)
Doesn't use any system RAM, and is controlled purely via IO ports.

Regards,

Mack

[Keith Howell]

The manual has a link to the datasheet. Just click on the part in the parts list.

[Tom Storey]

Ive implemented a text mode video controller using a 128 macrocell CPLD, it fits and works in both an Altera EPM7128 and Atmel ATF1508AS with a few macrocells left over. Both of these parts work at 5V, and although not strictly period correct, they are a far sight cheaper than an FPGA module, even once an inexpensive programmer is thrown in.

720x400 resolution, 28.322MHz pixel clock, 70hz refresh, 80x25 text columns/rows (characters are 9x16 on screen), 16 colours with blinking text (or extended bg colours), and a hardware cursor - just like the old days of DOS.

Code (Verilog) is on github here: https://github.com/tomstorey/vga_crtc

Quick video demonstration (uninitialised VRAM contents so its very disco): https://photos.app.goo.gl/XXnGdRH4E2xMULy19

Ive got ideas to expand it a bit further (will need to break into 2 CPLDs) to provide some more video modes, including something closer to 640x400 which should make user definable fonts more useful (formatted as 8x16 on screen instead of 9x16), and also something like a 320x240 ish bitmapped graphical mode.

--

You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.

To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/CAHHe_nbonK4vcBVYHBmtM_Pb3u3shsMVgE29YPHgBzLP4sX3CQ%40mail.gmail.com.

[Alan Cox]

On Thu, 24 Mar 2022 at 02:37, Tom Storey <t...@snnap.net> wrote:

Ive implemented a text mode video controller using a 128 macrocell CPLD, it fits and works in both an Altera EPM7128 and Atmel ATF1508AS with a few macrocells left over. Both of these parts work at 5V, and although not strictly period correct, they are a far sight cheaper than an FPGA module, even once an inexpensive programmer is thrown in.

Nice and in many ways not that period incorrect for the 1980s - just back then it involved paying megabucks to have a custom wiring mask made for an uncommitted logic array.

Alan

[Rob Gowin]

Agreed, very nice. I've been working on a 68K SBC for which I was considering an HD6445CP as the CRTC, but will look into using this instead. One feature the HD6445 has is the ability to tristate its address bus during blanking, thus avoiding the need for a mux if the CPUs writes the video RAM only during blanking. I wonder if that feature would fit in the CPLD? (I'll give it a try at some point.) 

Also, would you mind stating the software license under which you make this code available. GPL, MIT, something else?

-- Rob 

[Tom Storey]

Hi Rob,

Licensing .. that's a good question. I've never had to stick a license on something before. I'll have a look into the various options and get back to you.

Tom

--

You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/3e5198a7-af08-4b0c-a20a-cbad05020ed9n%40googlegroups.com.

[Tom Storey]

To answer your other questions:

You could use the blanking or H/V sync outputs for the purpose of interrupt generation and bus tri-stating. There are no other dedicated outputs for those purposes, but with a few pins and macrocells to spare, it might be possible to create some more specific logic.

I'd gotten to the point where the bit position within the internal registers made the difference between the design fitting or not, so its quite a tight design as it is. :-)

That said, if you can find a source of EPM7160 CPLDs then you will open up a lot of breathing room to add extra features. Ive just had a target of 128MC because the EPM7128 and ATF1508AS are similar enough to be interchangeable (pin-pin compatible, and if you compile the design using Quartus you can then use a tool called pof2jed to produce a programming file for the Atmel part, which is what I did), and the Atmel part can still be bought new today from Mouser/RS/etc (when you can find stock of it at least). Sadly, Atmel never made a 160MC part.

Just beware when buying the Atmel parts, those ending in ASV are 3.3V parts and as far as I know they do not have any 5V tolerant inputs. Parts ending in AS are 5V native. Dont be fooled into thinking you found a bargain on the 128MC CPLDs. ;-)

Tom

--

You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/3e5198a7-af08-4b0c-a20a-cbad05020ed9n%40googlegroups.com.

[Tom Storey]

Hi Rob,

Ive decided to put the BSD 3 clause license on, which is, I understand, somewhat similar to MIT.

Ive also added a note in my readme file encouraging improvements to be upstreamed. :-)

Incidentally I have also been using this with a 68k system I have been building.

On Fri, 25 Mar 2022 at 03:29, Rob Gowin <robg...@gmail.com> wrote:

--

You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/3e5198a7-af08-4b0c-a20a-cbad05020ed9n%40googlegroups.com.

[Chris Swan]

Tom,

In addition to the license there are a few other things you might want to throw into the repo to complete the GitHub Community Standards Checklist. I just open sourced the archetype repo I use at work for that.

[Daniel]

Hello, did you succeed with your uPD7220 monochrome card? Can you post the final schematics?

[Koenraad Van Nieuwenhove]

Hi,

A few years ago I worked on a 7220 based board for the RC2014 bus. I just made the repository for this public and it can be found here: https://bitbucket.org/cocoacrumbs/vga_graphics_terminal_upd7220_v2/

It's not a finished project for a number of reasons. Demanding day job, shiny new projects, disappointment that the 7220 was actually slow (if you have e.g. 4 bit planes, then you need to issue the draw command 4 times, each for its own bit plane...), etc.

It's not fully tested but I did get the 7220 working at 640 by 480 resolution (which was an unexpected challenge as I explain in the readme file).

For those interested, I still have 4 PCB's left over. I can send them to those interested for the cost of a padded envelope and shipping.

--
You received this message because you are subscribed to a topic in the Google Groups "RC2014-Z80" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rc2014-z80/GL2yX4O5yOQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to rc2014-z80+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/21cc75e4-bce5-44cb-a1c3-7c0369efac78n%40googlegroups.com.

[Daniel]

Thank you for posting the latest progress, Koenraad.