book: it was built port many resource. Hi Thank you for your support. I appreciate your most generous offer. Please forgive the public response on CCTALK. Sending email to your account always seems to respond with bounces. Here is the *notional* S-100 uPD7220 GDC design information http://n8vem-sbc.pbworks.com/w/browse/#view=ViewFolder&param=S-100%20uP… %20GDC Unfortunately I've had difficulty contacting you previously. In particular you've sent email and/or posted information on the SCSI to IDE/SD adapter project (unrelated to the NEC 7220 discussion) and the messages have all bounced even when sent from a non-YAHOO.COM email address (SBCGLOBAL.NET mail server). I would like to work with you on either or both of these projects but am unable to contact you. Would you please add my address (LYNCHAJ at YAHOO.COM) to your email whitelist or we could correspond in public on CCTALK or the N8VEM forums. Thanks and have a nice day! Andrew Lynch PS, I ordered a copy of the X11 book from Amazon. The price for a used paperback is quite reasonable.

rather the frame it. project, then port done have resources base <http://tinyurl.com/d3d-pipeline> Hi Richard! Thanks! I will look into your recommended book. I am not aware of any workstations that used the NEC 7220 GDC. There were some Multibus implementations of the chip so I suppose it is possible they exist. Many of the Intel 82720 and NEC uPD7220 boards were highly specialized niche products so it is entirely possible they exist but are not in common knowledge. http://www.multibus-international.com/int-intel-corp/sbx275 On a similar vein, I am aware of X Window(s) server for the VESA API for VGA boards. Most all VGA boards adhere to the VESA standard and provides quite a bit of portability although performance is generally fairly low. Would it be possible/feasible to create a VESA API for a NEC uPD7220A video board? In other words, is the VESA API inherently VGA MC6845 centric or is it hardware abstract enough to be ported to other video chips? At the N8VEM home brew computing project we already have a NEC uPD7220A board that works and has been debugged. However creating software for it has proven to be problematic. http://n8vem-sbc.pbworks.com/w/browse/#view=ViewFolder&param=ECB%20uPD7… 0GDC I am considering converting the above design to S-100 bus for a companion to the upcoming S-100 68K CPU board (final board due out later this summer) and the S-100 80386 CPU board (initial prototype boards just ordered). The N8VEM ECB uPD7220A board is a pure 16 color bitmap design. There is no explicit text character mode. The video memory is theoretically upgradeable to 256 colors by adding another 4 color planes. Since it uses a BT478 RAMDAC and VGA compatible dot-clock frequencies it can use 640x480 and 800x600 displays on regular VGA monitors. Thanks for your reply and comments. Thanks and have a nice day! Andrew Lynch

On 08/10/2012 12:59 PM, Andrew Lynch wrote: The biggest differs is the common PC version of VGA the memory is direct accessed (two ported) as stuffing bytes through the 6845 would be inceadibly slow. The Registers are only used to setup the scan rates and other timing parameters. That memory is up the C/D/E 16Kpaged in the upper part of the 1MB memory map. Now the real question is what OS will be used to support this as the 8088/8086 can only address 1MB and none of the LINUX versions fit on 8086 at all (minimum is 386). Also plan on a swap file, you will need room. Allison

Hi Can the PGC be built in a hobbyist friendly manner? Does it use custom chips or proprietary programmable logic? Would it fit on an S-100 board? Honestly I don't know too much about it. I'd need to see a schematic and a PCB to determine if it is suitable. The S-100 VGA and S-100 80386 CPU board PCBs are really pushing the envelope of our current technology choices. Thanks and have a nice day! Andrew Lynch

________________________________ From: Andrew Lynch <lynchaj at yahoo.com> Hi I did a quick look at the IBM PGC and it is enormous.? I doubt very much it is a viable option unless there were later models that were a lot more compact.? The original IBM PGC spans *three* ISA boards!? Even using modern DRAMs there is not practical way to fit it on to an S-100 board. C: Actually it occupies 2 ISA slots, and has a 3rd board between those (the CGA emulator). No I'd agree it's impractical to duplicate it's functionality in discrete logic for an s-100 board. And no there weren't later versions. But it is an interesting item that, while irrelevant to this post, uses a standard 8088 and a DAC that's similar to the one used in the IBM PS/2's. It would be interesting to compress all that glue into 1 or 2? asics. But that's defeating the purpose of implementing such a card based on it's almost exclusive use of off the shelf parts. ?I do have a miserably disorganized set of docs that includes the PGC, schematics even I believe. If you're interested, let me know. ?And next time I'd go multibus ;)

timing the flat try to Hi Al! Thanks! Yes, the NEC uPD7220 has a fundamentally different approach to graphics than the primitive MC6845 and derivatives (CGA, MGA, EGA, VGA, SVGA, etc). However, implementing an SVGA on the S-100 bus is a non-trivial exercise as well. We've done three iterations of a CL GD542x based (QFP-160) SVGA implementation prototypes that have gone essentially nowhere. Even completely disregarding the builder assembly concerns of SMT and even programmable logic devices -- even just finding a chipset that is compatible with the S-100 bus has proven to be extremely difficult. We've resorted to using the Propeller and even an FPGA (Spartan 3) based approach but none provide the low level VGA compatibility or even a usable bitmap graphics mode. The NEC uPD7220 readily adapts itself to the S-100 bus and provides a nice VGA monitor compatible bitmap. However it is completely non-VGA compatible and really is as different from the MC6845 derivative as can possibly exist. It uses a totally different approach down to the philosophical theory of design! If you or anyone else has some insight on how to implement a register compatible SVGA on the S-100 bus I am very willing to listen! Thanks and have a nice day! Andrew Lynch

video Hi! The goal for the S-100 VGA board is to make a register compatible SVGA that uses commonly available VGA monitors. The application would be an X server for the upcoming S-100 80386 CPU board. Also to provide a greater degree of PC/XT/AT compatibility for the S-100 80286, S-100 8086, and S-100 8088 CPU boards. Presumably, an S-100 SVGA board would also be usable by non-Intel x86 CPU boards as well but that is optional. If VGA is not viable then we need to explore other options to provide a bitmap display for the X server. The primary goal of the S-100 80386 CPU board project is to run a "modern sophisticated" operating system such as Linux and/or NetBSD. Both require a 32 bit ISA, an MMU, and a whole lot of RAM. Yes, you can run both without an X server but sooner or later you'll almost certainly want some sort of graphical interface because much current software assumes a GUI. Potentially any solution for the S-100 80386 could potentially be applied to the MC68040 SBC also currently in development. The technical specifications, such as they exist, are quite modest. IBM VGA register compatibility with 16 color, 800x600, 60 Hz refresh rate, and no preference for frame buffer. The closer to compatible with the stock IBM VGA the better. It does have to be "buildable" by hobbyists though so certain technologies are undesirable (SMT and programmable logic) or unacceptable (BGA). There is no preference for any particular chipset however it cannot rely on an undocumented BIOS which has proven to be the fatal flaw with the CLGD542x chipset (**please** someone prove me wrong and post a commented CL GD542x BIOS listing!) S-100 80386 http://n8vem-sbc.pbworks.com/w/browse/#view=ViewFolder&param=S-100%2080… 0CPU%20board S-100 SVGA http://n8vem-sbc.pbworks.com/w/browse/#view=ViewFolder&param=S-100%20VGA Further complicating matters is that all the "open source VGA" projects I am aware of have fizzled as well. This is a non-trivial problem and may not be solvable with a VGA chipset. Thus the interest in NEC uPD7220 as an alternative. http://hackaday.com/2012/06/05/open-source-graphics-card/ http://wacco.mveas.com/ http://wiki.opengraphics.org/tiki-index.php Thanks and have a nice day! Andrew Lynch

The the Hi Chuck! Yes, that's probably true assuming there is a 6845 clone that is fast enough. However a custom S-100 MC6845 video board that's not VGA compatible has the same lack of software problem as the S-100 uPD7220. I already have a known working ECB uPD7220 board that works great and is compatible with VGA monitors. Adapting it to the S-100 bus turns out to be a relatively easy problem since it is an IO port only design. It is very simple and it is essentially ready for prototype boards right now. What a VGA compatible design brings to the table is the installed base of legacy software for the PC. It would be much easier to adapt an existing PC Linux X11 implementation than to start from scratch with a completely new board. It looks like the former option may be our only choice though. I would think a X Window server without acceleration for the NEC uPD7220 would be about the same speed for a basic VGA. There is nothing I am aware of on the basic VGA that makes it particularly fast. Hardware BITBLT was not introduced until the VGA accelerators came along years later after the original VGA was introduced (1987 IIRC). Thanks and have a nice day! Andrew Lynch

on? <http://tinyurl.com/d3d-pipeline> Hi The plan is to run Linux or NetBSD on the S-100 80386 CPU board which would also be running the X window server. I've installed and run NetBSD on other obscure hardware and it is probably the easiest of the Un*x like OS to port so I am assuming we'll start with it. I just ordered the initial round of S-100 80386 CPU board prototypes this morning. These will only use memory and IO on the S-100 bus which hard limits the address space to 16 MB (24 bits). The next iteration and production boards will use a mezzanine or "over the top" connector for a DRAM board to get to 128/256/512 MB. We have to get the basic CPU working first though. Today I think I've discovered that there aren't any commented publicly available VGA BIOS sources *at all* which really terrifies me. It may be that the VGA approach is simply not viable on the S-100 bus if essential initialization source code is not available. I hope I am wrong though. However, we'll still have the backup plan to use other non-VGA compatible chips. Thanks and have a nice day! Andrew Lynch

the start work from without <http://tinyurl.com/d3d-pipeline> Hi I've ordered the book you recommended from Amazon. Yes, that's the plan. Start with NetBSD in console only mode. Build up some graphics primitives using the NEC 7220 and once there are enough start building the X server. That's good news that we can start with just those X primitives since certainly those can be written for the GDC. Performance is a secondary issue at this point. I recognize using a NEC 7220 in bitmap mode is not its strong suite. My hope is that some of the NEC 7220 graphics primitives can be used later to speed things along. It will never be fast though. However until the situation with the VGA chipset improves we are running out of options and need a buildable S-100 board that can display a bitmap. The initial prototype S-100 80386 CPU board is limited to the memory on the bus (16MB max). However this prototype is only intended to get the CPU core internals working. The real system memory will be on the RAM expander. It will have to be some sort of unique memory local bus since S-100 simply is not able to provide enough RAM to make this feasible. Hopefully once the RAM board is installed the X server performance will improve by doing some of the operations off screen. Thank you very much for your help. I appreciate it! Have a nice day! Andrew Lynch

On Fri, 10 Aug 2012 19:56:13 -0400 "Andrew Lynch" <LYNCHAJ at yahoo.com> wrote: If you go NetBSD: There are the wsfb(4) X-Server and the wsdisplay(4) / fbdev(4) frame buffer driver. I.e. if you write a kernel level framebuffer driver for your hardware, the X-Server will work out of the box. Unaccelerated of course. A wsdisplay(4) / fbdev(4) driver should be relatively simple. It will also solve the problem of text mode IO on a non-VGA console. So you are completely free to implement what ever graphics / framebuffer hardware you want. There is no need for a VGA compatible register set. -- \end{Jochen} \ref{http://www.unixag-kl.fh-kl.de/~jkunz/}

Yes...but - at least before XFree86 mucked it all up and the MIT X becaome Xorg and drank the XFree86 koolaid; I don't know about after that - the sample server (there is no "the X server", possibly unless your whole world is peecees running recent Linux or some such) had pretty good separation between the X server proper and the glue layer between it and the OS. If you have a moderate amount of RAM available (virtual or not) and are willing to do a little glue layer hackery, it's not that difficult to rip off the unixy interfaces and stick on whatever you've got. Unless what you've got is too restrictive to support what the server wants to do (for example, if you have something socket-like but nothing like select()/poll(), it will, um, be more difficult). /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

On 8/10/12 3:55 PM, Eric Smith wrote: Or flip the whole thing on its head and glue a PC104 SBC onto an S-100 card so you end up doing just an ISA - S100 adapter. http://www.wdlsystems.com/modperl/view_services.cgi?r=detail&prod_num=1… I didn't look very hard to see if there were any other modules under $100

It was. Or to be more preciese, it was used in the colour/graphics add-on board for the 'bow. The 7220 was also used in the VT240 terminal IIRC (which has a graphics system very like that of the 'bow colour card). And in the HH Tiger. But I susepct findign docuemtnation on those is a lot harder. -tony

On 2012-08-12 02:03, Chris Tofu wrote: zoom in on a virtual screen, The 7220 was not really fast. We made board back then, where we had one 7220 for every plane ( took us 8 for the 256 colors) and mixed the color later. Newer used any ***windowing system on it, was just GKS for a customer ...

On 08/12/2012 03:47 AM, Eric Smith wrote: As one of the product team for NEC at the time that's correct. One has to remember the introduction of the part in 1981 predates the IBM PC. The world at the time was 8bit busses (z80 common, 6502, or 8088 emerging). It had the needed bits for a dynamic ram interface for large arrays (megabit sized). Odddly at the time displays were also a limitation for both resolution as pixels per scan (video bandwidth) line and number of scan lines(limited by spot size and vertical scan systems). Also at the time the 64K Dram was a new and very expensive part plus it was not all that fast either. In fact the fastest ram was the 2147 (1kx4) and 2167 (16kx1) and they were scarce and expensive for the fastest 35ns part. te standard part was 55ns! Oddly the next generation of large displays (1024x1024 or color in that or larger) would all be handled by the cpu (32bit) to a memory map. That was the workstation era with the SPARC, MIPS, ARM, and VAX, CPUs. Intelligent display controllers were late 90s for common reappearance. I used to call on Cyron and a few of the other houses in the northeast that did high end graphics display systems. The boxes of the time were large, typically 6-12 VME or double height Multibus sized cards and many were full custom size boards with 2900 based hardware, and lots of DRAM. Allison

________________________________ From: Andrew Lynch <LYNCHAJ at yahoo.com> PS, BTW there are still plenty of the ECB uPD7220 GDC board PCBs left.? They are readily adapted to almost any microcomputer/embedded/vintage type system.? They work well and interface to standard VGA monitors. C: How much? And where are you getting all these 7220 chips from Andy? I think I have a total of 3 in my possession, and all are likely soldered to something.

Chris Tofu skrev 2012-08-13 03:31: I have a lot of 7220 chips, pulled from Nokia VT220 compatible terminals (Norsk Data ND-NOTIS terminals). The terminal was based on a 80186 CPU with a NEC D7220 AD chip and eight 4464 dram (256 kbyte). I haven't found any way to enable graphics mode on the terminals but I haven't made a decent trial yet. The screen seems to be monochrome only, no grey scale, so there seems to be plenty of memory for the graphics. I can sell tested NEC chips, terminal boards (digital part) or complete terminals to anyone interested. I always test the terminals before I scrap them to see that the chips are good. ... I got 60 terminals left and it is still too much, I will save the 20 best of the lot, the rest is going to be scrapped unless I can find someone who wants them. /G?ran

emu at e-bbes.com skrev 2012-08-15 08:10: I've only used it to connect to a ND-100 computer. So I haven't even tried to send random binary data. My friend that gave the terminals to me tried to remember the escape sequence they used, but he thought it was only a few terminals that had the software that enabled the graphics. So far I have only found one version of the software in the roms. (Only checking the checksum on the labels). When time permits I will do some more testing... and possibly disassembling the roms. Feels like a winter project. :-) /G?ran

On 08/11/2012 04:12 AM, emanuel stiebler wrote: Yes it was though I think the Rainbow used the Z80 as an IOT processor. The video was CGA level not VGA. Doing VGA video makes finding compatible monitors easier (CGA (9pin)went the way of the dodo). That does not require you to do VGA level video. VGA is video side timing issue not so much the bus side. But pushing a lot of bytes through the 7220 at about no less than 800NS per byte (likely 10 to 20x that) to move a megabyte is going to take 10s of seconds as it's all port IO and thats not all that fast. Each color plane needs to be 38400bytes, if you want 8BPP. That means at least three planes. to fill the memory the first time will have to move 115kb, at S100 8086 speeds thats likely to take a while, a long while. All the PC video above CGA was memory mapped as CPUs can read/write ram far faster than funnel everything though an IO port with status check. If you uyse 2 port ram then the 7220 primitives are useless, and all early the PC drivers did that in the CPU not the graphics board logic. Allison

________________________________ From: Tothwolf <tothwolf at concentric.net> On Mon, 13 Aug 2012, allison wrote: You actually can get LCD displays that accept CGA (and MDA) signals but they cost more than a typical VGA display. C: Can you provide specifics? I know of some older units that'll take EGA digital video.

________________________________ From: Tony Duell <ard at p850ug1.demon.co.uk> No it was not!. It was CGA (US TV, RS170) scan rates, but it was _analogue_ RGB, with sung-on-green. It was not TTL levels like CGA. C: Also not a huge big deal to convert rgb + v + h into composite/rs-170. There used to be chips that did just that, but I'm not sure if they're still being manufactured. The problem with the Rainbow might be the relatively high dot clock (800 pixels horizontal). I'm thinking you'd lose a lot of detail converting to rs-170. ?Anyone know of a chip/circuit that'll separate composite into r, g, b, combined sync? Actually, they are not hard to get in the UK, provided you don't mind having to spearate the sunc from the green signal. Most TVs -- even modern ones -- have at least one SCART socket with analogue RGB inpots, and most TVs over here can hadnle US scan rates. -tony C: A scan doubler would be the best thing for a bow w/o a color monitor. Double the vertical sync. I mean to start working on something like that. It turns out that you would need to store the signal before spitting it back out in half the time. When this stuff started to take shape in my head, Tony came along and reinforced that.