PDA

View Full Version : Fantasy CGA redesign



reenigne
April 17th, 2012, 02:21 PM
I've spent a long time (probably way too long) staring at the schematics for the IBM CGA cards for one reason or another, and doing so has given me an idea for a sort of game. I'm not sure if there's anybody out there other than me who would be interested in playing it but if there is I'm sure this is the best place to find them.

The game is this: you have time travelled back to 1980 and find yourself working on Don Estridge's team at IBM, and your job is to design the CGA card. Knowing what you know now, how would you design it differently to make it more versatile for the games programmers who will write software targetting it? You still have the same constraints:

It has to support the same RGBI and composite monitors.
It has to have a 320x200 4 colour all-points addressable mode.
It has to have a 640x200 2 colour all-points addressable mode.
It has to have 40x25 and 80x25 text modes with the same colours, font and attributes.
The flashing text and cursor have to flash at the same rates.
Text must not blink when the cursor is on.
It has to have 16KB of DRAM.
It has to be based around a 6845 CRTC.
It has to fit on a standard full-length ISA card.
It has to include light pen support.
You can't increase the cost.
You have to continue to use the same TTL discrete logic chips used in the original card - no ULA/PAL or anything like that (74-series TTL chips that were available in 1980 but weren't actually used on the CGA are also allowed).
It can't conflict with any of the other memory addresses or IO ports used by the original PC.

Software compatibility isn't necessary (remember no CGA software has been written yet!)

I haven't been able to find a 1980-era price list for 74xx/74Sxx/74LSxx logic chips, but for the purposes of the game the absolute prices aren't really important, only the ratios between them. I'm sure the chips used to be more expensive back then but the price ratios probably haven't changed too much so here (http://www.reenigne.org/misc/ttl_prices.txt)'s the modern prices for large quantities of the nearest available equivalents.

Here are some possible changes, roughly in order of least to most difficult:

Modify the wait state so it's between 0 and 6 CPU cycles instead of between 3 and 8 CPU cycles as it currently is.
Change the CGA character ROM from this (http://www.reenigne.org/misc/cga_rom.png) to this (http://www.reenigne.org/misc/cga_rom_alternate.png), replacing the third quarter (the unused "thin font") with some patterns which are useful for "graphics in text mode", and make it selectable from software (perhaps repurposing the palette register bits that have no effect in text mode). This would make the 160x100x16 mode much more flexible, becoming a pseudo-640x100x16 mode and a pseudo-320x200x16 mode depending on whether the top or bottom half of the characters are being used. These modes aren't all-points-addressable (there isn't enough RAM for that) - each 8-pixel by 2-scanline block can only have 2 different colours in it, so they would suffer from "attribute clash" like a Commodore 64 or ZX Spectrum. This change would also make many thousands of extra colours possible with a composite monitor.
Add an option (perhaps reusing the +BLINK mode bit) to not ignore the CRTC's MA12 line in graphics modes. In combination with some CRTC tricks, this makes it possible to implement a linear memory layout instead of the normal interlaced layout.
Add an option to ignore the RA0 bit in graphics modes, making possible modes like 640x100x2 and 320x100x4 with 2 memory pages.
Fix the color burst in 80-column text mode - just requires making the color burst pulse a fixed length instead of being gated by the HSYNC pulse from the CRTC.
Allow interlaced modes to work by starting the vsync pulse start when the CRTC says it starts instead of waiting for the next hsync pulse. This means we have to count for 171 lclk periods instead of 3 scanline periods to determine where the vsync pulse ends (since we need a 3-scanline sync pulse and the CRTC generates a 16-scanline one) so we'd probably need an 8-bit counter.
Get rid of the wait state on CGA writes altogether by caching writes until CGA RAM is available.
Allow combining graphics modes with +HRES (160 bytes per line) yielding 1280 column 2 colour and 640 column 4 colour modes (albeit with a reduced viewport or splitscreen since there isn't enough RAM for these modes at full screen). This is *almost* possible with current CGA, but the bytes are not latched at the correct times due to the circuitry that eliminates snow in graphics modes. Also to get 1280 columns you'd need to get rid of the 14.318MHz pixel latch, which might destabilize the image too much (1280 columns isn't terribly useful to start with because of the dot pitches of the available monitors).
Make the palette fully adjustable in 640x200x2 and 320x200x4 modes (i.e. have 16 bits of palette registers instead of 6) so CGA games don't all have the same ugly green/red/yellow or cyan/magenta/white palettes. In the alternate universe where this change had been made, most CGA games would look dramatically better!
Allow a 160x200x16 all-points addressable mode (i.e. add a 4-bit pixel sequencer). Combined with some of the other changes this could also yield a 320x100x16 mode and reduced-viewport or splitscreen 320-column 16-colour modes.
Make the palette fully adjustable in 16-colour modes (i.e. have 64 bits of palette registers) allowing for all sorts of fun palette animation tricks. Probably not possible with existing CGA parts but maybe with a 7489 or similar?
Eliminate snow altogether during writes. This is actually very hard because there just isn't the memory bandwidth in +HRES mode to retrieve bytes fast enough for the screen and also allow the CPU access. One way might be to store up all the writes and then perform them during the horizontal blanking period. Eliminating snow during reads would require making the CPU wait until the end of the scanline, and probably isn't worth it.


Steve Wozniak was famous for being able to do amazing things with very small amounts of discrete logic - I wonder what the CGA would be able to do if he had designed it.

Any suggestions for good ways to achieve any of these changes? Or other changes that you'd want to make to the card?

eeguru
April 17th, 2012, 03:01 PM
I'm pretty sure most of the early video cards on PCs used early synthesized ASICs. Outputting a single video mode would be complex but straight forward using discrete logic. However supporting all the video modes available in CGA for memory fetch & refresh, text/palette lookups, and frame clocking in discrete logic would be a really big board.

What is a more interesting project in my mind, although a bit impractical for a hobbyist, would be to take a modern PLD synthesis tool like Synplify Pro and impose upon it a target logic architecture made from commodity 74xx chips and no routing constraints rather than a macro cell and routing design from a given PLD vendor. That way you could code a CGA design at a logic equivalency level and it would synthesis the schematic for you. I suppose one could attempt to write a custom logic fitter using Icarus to parse the HDL into a truth table and some creative coding on the backend.

reenigne
April 17th, 2012, 03:46 PM
supporting all the video modes available in CGA for memory fetch & refresh, text/palette lookups, and frame clocking in discrete logic would be a really big board.

And yet IBM's designers managed to do it with 59 74xx chips on a (full length) ISA card! Here's the schematic. (http://www.retroarchive.org/dos/docs/ibm_techref_v202_3.pdf) The frame clocking is done by a special chip (the MC6845 CRTC - basically counters for character, address, scanline and row and comparators to generate sync pulses) but all the rest is discrete logic.

The Acorn, Sinclair ZX81/Spectrum, Amstrad, Commodore VIC/C64 and later PC standards like PCjr and EGA all used ULAs/PALs/ASICs of some sort. I think the machines which used discrete logic were just Apple I/II, Commodore PET, Sinclair ZX80 and IBM CGA/MDA. I'm sure others will correct me and/or expand those lists though.


What is a more interesting project in my mind, although a bit impractical for a hobbyist, would be to take a modern PLD synthesis tool like Synplify Pro and impose upon it a target logic architecture made from commodity 74xx chips and no routing constraints rather than a macro cell and routing design from a given PLD vendor.

That's fascinating - I would never have guessed that it would be possible for PLD synthesis software to be able to target discrete TTL logic chips! That would sort of take some of the fun out of my game, if I could get the computer to play it... Though I suppose there would still be some fun in trying to think of new features and seeing what can be synthesized given the constraints.

vwestlife
April 17th, 2012, 04:43 PM
Change the CGA character ROM from this (http://www.reenigne.org/misc/cga_rom.png) to this (http://www.reenigne.org/misc/cga_rom_alternate.png), replacing the third quarter (the unused "thin font") with some patterns which are useful for "graphics in text mode"
The thin font actually did have one legitimate use: to allow the difference between normal and high-intensity text to be distinguished on a truly monochrome (not grayscale) display, such as the 1-bit 640x200 LCD panel used by most early laptops. I think my Toshiba T1100FD does it backwards: normal = thick font and "bright/hi-int." = thin font, but nonetheless it can and does use a combination of both fonts on the screen simultaneously. I believe IBM's own PC Convertible does it this way as well.


Make the palette fully adjustable in 640x200x2 and 320x200x4 modes (i.e. have 16 bits of palette registers instead of 6) so CGA games don't all have the same ugly green/red/yellow or cyan/magenta/white palettes. In the alternate universe where this change had been made, most CGA games would look dramatically better!

This is the most realistic item on your entire list, because virtually every other computer in the '80s did it that way. It really makes you wonder if the CGA's two palettes started out as two suggestions of a "safe starting point" palette to use as a default, and somewhere along the line "default palette" in the design notes got mis-translated into "mandatory palette"!

It also would be nice to let the border color in graphics mode be changed independently of the background color, like the way it is in text mode, instead of having it always the same the background color -- and also the ability to change the background and border colors in hi-res 640x200 graphics mode, for that matter. Anyone who's used an Apple IIGS will know that simply being able to individually set the foreground, background, and border colors will suddenly make a monochrome display mode (e.g. Apple's text mode) become a lot more appealing on a color monitor!

Chuck(G)
April 17th, 2012, 04:57 PM
Use the NEC 7220 CRTC instead of the 6845. For what could have been, take a look at the NEC APC (http://www.old-computers.com/museum/computer.asp?c=333), which was a contemporary of the 5150.

reenigne
April 17th, 2012, 06:48 PM
The thin font actually did have one legitimate use: to allow the difference between normal and high-intensity text to be distinguished on a truly monochrome (not grayscale) display, such as the 1-bit 640x200 LCD panel used by most early laptops. I think my Toshiba T1100FD does it backwards: normal = thick font and "bright/hi-int." = thin font, but nonetheless it can and does use a combination of both fonts on the screen simultaneously. I believe IBM's own PC Convertible does it this way as well.

Neither of those used the IBM CGA/MDA character ROM though - the Toshiba wouldn't have used IBM proprietary ROMs and the I don't see the character ROM inside the PC Convertible. (http://www.scrapmetalforum.com/showthread.php/7448-Vintage-IBM-5140-PC-Convertible)

I'm guessing that it was made that way because IBM thought they might need a thicker font for composite than for RGB (or vice-versa) but then realized otherwise when it was completed. Or maybe they wanted to delay choosing which font looked best until the hardware was up and working, and the schedules were such that they needed to get the ROMs made early.


This is the most realistic item on your entire list, because virtually every other computer in the '80s did it that way.

I think all those other colour machines used ULAs/PALs/ASICs though - the only discrete TTL colour machines were the Apple II and IBM CGA, neither of which had a full set of palette registers. These palette registers are probably quite a natural fit for ULAs because there's lots of flip-flops hanging around that you can use for the palette RAM, whereas with discrete logic you needed quite a few chips for each register (the flip-flop array itself plus CPU addressing logic and logic to decide what to do with the output).


It really makes you wonder if the CGA's two palettes started out as two suggestions of a "safe starting point" palette to use as a default, and somewhere along the line "default palette" in the design notes got mis-translated into "mandatory palette"!

My theory on the origin of the palettes is this: you've got two data bits from the video RAM and you need to transform that into four bits (R, G, B and I) from the output, but you also want to be able to use all 16 possible colours. The simplest thing you can do is to connect the two data bits to two of the output bits and connect the other two output bits to register bits. Given that the eye is better at distinguishing changes in red and green than in blue or brightness, those two are the obvious output bits to connect up to the data bits. That gives you four possible palettes: black/green/red/brown, blue/cyan/magenta/grey, dark grey/light green/light red/yellow and light blue/light cyan/light magenta/light grey, which are the same as the 4 main CGA palettes except for colour 0. I'm guessing that to maximize contrast they wanted to allow that to always be made black.

That doesn't explain why they added the colour select register at all though. I guess they liked using 74LS174s for the registers for some reason, but ran out of bits in the mode select register for all the features they wanted, so added a second register and then discovered that they had 4 spare bits that they could use to complete define a colour which could be used in various places: the foreground in 640x200x2 mode, colour 0 and the border in 320x200x4 mode and the border in text mode. They may have wanted to allow emulation of green, amber and white screens in 640x200x2 mode, and that was the easiest and most flexible way to accomplish that. They may also have wanted to be able to change the border colour in software for debugging purposes (like democoders later did to visualize how many rasterlines a particular piece of code took to run), and the colour select register would have enabled that too.

What's most mysterious to me, though, is why disabling the color burst bit in 320x200x4 mode changes the palette to cyan/red/white (i.e. forces blue on for two of the colours). Perhaps because the green/red/yellow palette wouldn't have worked very well on a monochrome composite monitor since all those three colours end up at the same shade of grey with the original CGA, so they forced yellow to become white in that configuration.


It also would be nice to let the border color in graphics mode be changed independently of the background color, like the way it is in text mode, instead of having it always the same the background color -- and also the ability to change the background and border colors in hi-res 640x200 graphics mode, for that matter. Anyone who's used an Apple IIGS will know that simply being able to individually set the foreground, background, and border colors will suddenly make a monochrome display mode (e.g. Apple's text mode) become a lot more appealing on a color monitor!

Ooo yes, good thinking - that's definitely one for the list.

reenigne
April 17th, 2012, 07:10 PM
Use the NEC 7220 CRTC instead of the 6845. For what could have been, take a look at the NEC APC (http://www.old-computers.com/museum/computer.asp?c=333), which was a contemporary of the 5150.

Wow, hardware commands to draw circles! This was truly a chip that was ahead of its time. The APC didn't appear until 1982 though so I'm guessing the 7220 wasn't around in 1980 when IBM started work on the CGA.

k2x4b524[
April 17th, 2012, 07:42 PM
Why couldn't this fantasy CGA redesign turn into another homebrew project? One that truly maxes out CGA while keeping it functional on the CGA monitors? With the updated chips out there, perhaps a faster one could be designed, one with more hardware capability?

reenigne
April 17th, 2012, 08:33 PM
Why couldn't this fantasy CGA redesign turn into another homebrew project? One that truly maxes out CGA while keeping it functional on the CGA monitors? With the updated chips out there, perhaps a faster one could be designed, one with more hardware capability?

It certainly could. Though I think it would be more interesting to use 1980 technology instead of modern chips, otherwise it's not enough of a challenge - you'd just end up with something like a clone EGA card with a composite output.

I might even build such a CGA card myself if I come up with a good design, but it'll probably be a while as I have lots of other projects on the boil.

Chuck(G)
April 17th, 2012, 08:51 PM
Wow, hardware commands to draw circles! This was truly a chip that was ahead of its time. The APC didn't appear until 1982 though so I'm guessing the 7220 wasn't around in 1980 when IBM started work on the CGA.

I can't say for certain. The whole thing was part of a cross-licensing affair that involved the 8272/uPD765 and some other chips between NEC and Intel. The Intel part number for the 7220 was the 82720--and it's in the 1984 Intel databook, so Intel surely knew about it when the PC was being worked on. The APC came out at nearly the same time as the PC.

k2x4b524[
April 17th, 2012, 09:06 PM
True, you'd have to use the 1980's chips, or, make a whole new CGA card with updated components, it could be a card that switched from ega to cga with a toggle switch, like some of the later mono/cga cards did *i have one*


It certainly could. Though I think it would be more interesting to use 1980 technology instead of modern chips, otherwise it's not enough of a challenge - you'd just end up with something like a clone EGA card with a composite output.

I might even build such a CGA card myself if I come up with a good design, but it'll probably be a while as I have lots of other projects on the boil.

reenigne
April 17th, 2012, 09:15 PM
I can't say for certain. The whole thing was part of a cross-licensing affair that involved the 8272/uPD765 and some other chips between NEC and Intel. The Intel part number for the 7220 was the 82720--and it's in the 1984 Intel databook, so Intel surely knew about it when the PC was being worked on. The APC came out at nearly the same time as the PC.

NEC were probably designing the APC and the 7220 at the same time though, and would probably have delayed the former if the latter wasn't finished in time, whereas IBM would not have wanted to risk slipping the PC launch by designing it around a part that wasn't available yet. The second-sourcing thing sounds like something that NEC/Intel might have been doing in order to sell to IBM though. I guess after the PC took off, CGA software compatibility would have been a concern, so IBM went in the PGC and EGA directions instead.

Chuck(G)
April 17th, 2012, 09:18 PM
Consider the color on the AT&T 6300. More lines, finer resolution--and possible to upgrade by adding a board--and it uses the 6845.

NobodyIsHere
April 18th, 2012, 02:24 AM
Use the NEC 7220 CRTC instead of the 6845. For what could have been, take a look at the NEC APC (http://www.old-computers.com/museum/computer.asp?c=333), which was a contemporary of the 5150.

Hi,
One of the N8VEM projects was to design a NEC uPD7220 based video card. It took a while but you can see it works well. The board has many fewer chips than a CGA but I think is very capable. It is purely bitmapped graphics although I have seen designs for uPD7220 which had both text and graphics modes. It is a shame the uPD7220 never took off since it is *much* more capable than the MC6845.

The schematic, PCB layout, KiCAD design files, software, photos and other information are on the N8VEM wiki in the ECB folder.

Thanks!

Andrew Lynch

reenigne
April 18th, 2012, 10:59 AM
Consider the color on the AT&T 6300. More lines, finer resolution--and possible to upgrade by adding a board--and it uses the 6845.

The AT&T 6300 came along about 3 years after the PC though, and had twice the video RAM of a CGA. In 1981 putting 32K on the video card probably would have been prohibitive. Does the AT&T 6300 use discrete logic or an ASIC for its video generation?

JohnElliott
April 19th, 2012, 01:06 PM
Neither of those used the IBM CGA/MDA character ROM though - the Toshiba wouldn't have used IBM proprietary ROMs and the I don't see the character ROM inside the PC Convertible. (http://www.scrapmetalforum.com/showthread.php/7448-Vintage-IBM-5140-PC-Convertible)

The Convertible's video controller doesn't use a font ROM at all; the font is generated from an extra bank of RAM, which is loaded by the motherboard BIOS (or DISPLAY.SYS).

Chuck(G)
April 19th, 2012, 01:25 PM
The AT&T 6300 came along about 3 years after the PC though, and had twice the video RAM of a CGA. In 1981 putting 32K on the video card probably would have been prohibitive. Does the AT&T 6300 use discrete logic or an ASIC for its video generation?

Sold in 1983, actually, so make that 2 years. No ASICs on the display board. A couple of HALs, but that wasn't special even in 1980. And it uses VGA-compatible scan rates.

reenigne
April 19th, 2012, 01:59 PM
And it uses VGA-compatible scan rates.

Are you sure about that? I thought its 400 line mode was interlaced, and the 6845 (at least the Motorola one) couldn't cope very well with VGA scan rates, having a maximum character clock of 2.5MHz.

Chuck(G)
April 19th, 2012, 03:14 PM
Are you sure about that? I thought its 400 line mode was interlaced, and the 6845 (at least the Motorola one) couldn't cope very well with VGA scan rates, having a maximum character clock of 2.5MHz.

Nope, I run a VGA LCD monitor off of mine, as I have only the M24 monochrome monitor. Works just fine. See here (http://www.olivettim24.hadesnet.org/) for connector details. I get only 8 colors, as the video output is RGBI. One of these days, I'll fix that up to get the full 16.

A lot of people sell the 80's Olivetti systems short. There was some very nice engineering there.

Eudimorphodon
April 20th, 2012, 08:22 AM
A lot of people sell the 80's Olivetti systems short. There was some very nice engineering there.

As a random aside, last time I went to a swap meet someone was selling a SAMS ComputerFacts folio for the AT&T 6300. I considered buying it just to see if anyone here wanted it, but ended up deciding against it. Maybe that was a mistake.

So far as the "Fantasy CGA redesign" goes, I heartily second the idea of making the palette fully adjustable. It would add hardly anything in the way of hardware cost, and the *absolutely horrible* set of colors available in the 320x200 mode always seemed to me the biggest single flaw of CGA. Soft-loadable text-mode character sets might have been nice as well, although I'm not sure how you'd be able to do that without adding a bank of SRAM to the card.

One point, though, about the 16k RAM limit: Referencing a July 1980 issue of "80 Microcomputing" it looks like a set of 16k DRAM chips was retailing for about a hundred bucks in mid-1980. By next year, still prior to the PC's official unveiling, that was down to about $45. That doesn't really seem that cost-prohibitive in the grand scheme of things. The CGA card retailed for $300; it seems like one might be able to make a case that upping the RAM to 32k to support a full 16 color 320x200 mode (and possibly also offering 640x400 monochrome high-res, either progressive or interlaced depending on the monitor connected) and upping the price to $400-$450 would have been a reasonable trade-off.

Perhaps in this alternate universe IBM could have dispensed with the separate MDA/5151 combination and simply sold the same video card with two different monitor choices: an NTSC-scan-rate color unit like the 5153, with which the video card would have behaved essentially like Plantronics ColorPlus or PCjr/Tandy graphics, and a 400-line non-interlaced monochrome monitor that enabled an alternate 8x16 high-definition character set for text modes and supported a high-res 640x400 mono graphics mode. No need for a Hercules card. Yay!

reenigne
April 20th, 2012, 08:57 AM
One point, though, about the 16k RAM limit: Referencing a July 1980 issue of "80 Microcomputing" it looks like a set of 16k DRAM chips was retailing for about a hundred bucks in mid-1980. By next year, still prior to the PC's official unveiling, that was down to about $45. That doesn't really seem that cost-prohibitive in the grand scheme of things.

Very interesting. I wonder if IBM limited the CGA to 16K to avoid competing with other (later?) graphics cards rather than because of the RAM cost. Upping it to 32K would have required more than just the cost of the DRAM chips themselves though - there would have to be additional logic to control the extra chips.

Also, not all DRAM is equal - the CGA card used 2118-4 chips instead of the 4116 chips used on the PC system board. I'm not 100% sure but I think this is because the 2118s were faster - the CGA needed to be able to read or write a byte every 279ns but the corresponding figure for system memory is three times that (838ns). I have no idea how much difference that would have made to the price in 1980 though.

Eudimorphodon
April 20th, 2012, 10:09 AM
Also, not all DRAM is equal - the CGA card used 2118-4 chips instead of the 4116 chips used on the PC system board. I'm not 100% sure but I think this is because the 2118s were faster - the CGA needed to be able to read or write a byte every 279ns but the corresponding figure for system memory is three times that (838ns). I have no idea how much difference that would have made to the price in 1980 though.

A close look at a picture of an IBM CGA card on eBay showed a unit sporting Mostek 4516-12 chips, which are 16k DRAMs with a 120ns cycle time. Googling enough found me the datasheet for an *M2118-4*, which is apparently a mil-spec version of the 2118-12 and has identical timing specs, so... I'm not sure what's up with Intel's labelling. In any case, comparing the datasheets to that of a plain-jane TMS4116 the cycle times for a given NS rating are about the same. The difference is that the chips used on the CGA card are single-supply 5v-only chips while 4116s used the three voltage +12/+5/-5 setup. (The Mostek data sheet actually calls out "pinout compatibility with the 4164" as a feature.) I imagine one would have to dig a little to find out what the cost of those were relative to 4116s but speed isn't why they were used. (Undoubtedly the reason had to do with power consumption.)

As to the cost of supporting chips, I doubt that would amount to much. This is oversimplifying it a bit, but it seems to me that if one used a 16 bit wide arrangement for the additional memory all you'd need is a twice-as-wide shift register on the output side and an even/odd byte-to-word selector on the bus (which could be basically free. Or... maybe you could insert a two-byte buffer to collate writes of successive bytes into word-size accesses. That *could* possibly help somewhat reduce snow? I suppose you'd have to have some mechanism to determine whether two successive writes were consecutive, though, so... scratch that.). The memory access speeds for resolutions of double the resolution/double the color would be the same as the otherwise corresponding mode on CGA.

Chuck(G)
April 20th, 2012, 10:26 AM
Cost for 2116/2117/2118/4116 etc. around 1980 wasn't predictable. The US, prompted by SIA, was in a trade squabble with Japan over 16K parts and getting parts in any quantity at all became more of a matter of who you knew had parts. Prices surged terrifically. I recall that our Intel sales guy asked if we'd be happy with 8K DRAMs for our prototypes. 8K? I'd never heard of them, but anything was better than nothing.

It turns out that Intel wasn't having spectacular yields on their 16K parts, so they took those that tested fault-free in one half or the other and relabeled them as 2109-x, where if x was even, you pulled an address line high, or low if it was odd.

Desparate times--trucks were hijacked, parts cribs were burgled--a very interesting time. Mostly because of stupid trade actions.

Japanese DRAMs at the time really were much better than the US variety. I think it was Mostek who accused the Japanese of "quality dumping"--selling better parts in the US than the US could afford to sell!

Eudimorphodon
April 20th, 2012, 12:13 PM
I recall that our Intel sales guy asked if we'd be happy with 8K DRAMs for our prototypes. 8K? I'd never heard of them, but anything was better than nothing...

When restoring a dynamic-RAM-board PET I actually encountered some of those magical 8K DRAMs, labelled as 4108s. Likewise I'd never heard of such a thing before seeing them with my own eyes.

I'm actually curious in that case whether *all* the 4108s were actually "half-bad" 4116s or if Commodore "needed" so many of them of them (to fulfil their requirement of having 8k in one bank so they could punch holes through the empty bank to prevent end-user upgrades) that at least some percentage might have been completely good 4116 dies.

Chuck(G)
April 20th, 2012, 01:13 PM
Well, I have an S-100 board that I mostly populated with 2109s that tested in that particular application all-good and they ran as 2117s just fine. I haven't revisited them in 20 years, but maybe I should one of these years...

k2x4b524[
April 20th, 2012, 01:30 PM
Since we've got the high-res mono, why not just beat hercules to the punch and develop the support on card? That way we get the souped up cga AND built in herc support?

digger
January 8th, 2013, 06:58 AM
Since this topic is letting us go wild with our creativity anyway, here's a crazy idea:

How about adding support for PCjr graphics modes such as 320x200x16 and 640x200x4 to such a card? I know that the Video Gate Array was based on shared video, but it's mapped to the standard B8000 area. Putting 128KB of video memory on said fantasy/alternate-universe CGA card would be cheating, but what if this card would have a gimmick where it would "sit between" the memory sockets of the first 128KB of on-board memory and the RAM chips? So this card would go into an 8-bit ISA slot, have empty memory sockets of the same type that go into a standard IBM PC that could take up to 128KB of regular IBM PC RAM. It would also have a ribbon cable attached to the card which would then connect to the RAM sockets of the motherboard.

The card would come without RAM when bought, keeping it cheap, and people installing such a card would be instructed to remove the first 128KB of memory from the motherboard, place the removed RAM chips in the sockets on the card, and then attach the ribbon cable coming out of the card into the vacated RAM sockets on the motherboard.

For 8086-based clones, such as the Olivetti M24 and AT&T 6300, a special version could be developed that would support a 16-bit memory bus, and would fit in the proprietary 16-bit expansion slots on those models.

And while we're designing such a CGA+ card anyway, we might as well throw in three-voice audio compatibility, which would install in a similar way: people would have to disconnect the wires from the internal speakers, connect them to input pins on the sound card, and then either connect the output of the card to the existing internal speaker, or use an external audio output on the back of such a card. That would pretty much complete after-market game-mode PCjr and Tandy 1000 compatibility.

Would this be too crazy an idea? And would this be "cheating", in the sense that such a card would have to be feasable with the same technology and hardware budget available to IBM back when they designed the original CGA card? Shipping the card without memory and letting people reuse part of the RAM on their motherboards would keep the card cheap enough to remain within that budget, right?

Or would this be too complicated to implement, or are there perhaps other technical hurdles that I've missed?

vwestlife
January 8th, 2013, 07:32 AM
Of course, IBM's answer to those who wanted improved CGA video was to sell them a 64K EGA card and a 5153 CGA monitor. That way you would get snow-free text mode and full 16-color 320x200 and 640x200 graphics.

reenigne
January 8th, 2013, 08:04 AM
I know that the Video Gate Array was based on shared video, but it's mapped to the standard B8000 area. Putting 128KB of video memory on said fantasy/alternate-universe CGA card would be cheating, but what if this card would have a gimmick where it would "sit between" the memory sockets of the first 128KB of on-board memory and the RAM chips? So this card would go into an 8-bit ISA slot, have empty memory sockets of the same type that go into a standard IBM PC that could take up to 128KB of regular IBM PC RAM. It would also have a ribbon cable attached to the card which would then connect to the RAM sockets of the motherboard.

That is a really interesting idea and definitely within the spirit of the game (assuming you can figure out a way to do it without the ULA). I suspect the main objection would be that the original CGA card worked just fine even with the low-end 5150s that came with just 16KB of system RAM, but obviously you would need more than that to use this redesigned card (and, if you had a 32KB floppy machine, for example, adding the CGA card would mean you could no longer use the floppy drives). So it might not have fulfilled the design requirements for that reason.

The ribbon cable might not be necessary - I can imagine just having sockets for the RAM chips on the CGA card that the RAM chips you take off the motherboard would fit in to, and any RAM not in use for video would be available as system RAM just as if it was on an expansion card.

You'd also have to make sure that the system RAM is suitable for use as video RAM - in particular the access times. CGA needs an access time of 559ns (1 character period in 80-column text mode) but system RAM needs an access time of 838ns (4 CPU cycles). I'm not sure if that's the only reason that the CGA card used different RAM chips than the (16-64KB) 5150. Refresh time might also be an issue - the CGA card uses the CRTC accesses for DRAM refresh and the system board uses DMA, so that complicates things too.

digger
January 8th, 2013, 08:25 AM
The ribbon cable might not be necessary - I can imagine just having sockets for the RAM chips on the CGA card that the RAM chips you take off the motherboard would fit in to, and any RAM not in use for video would be available as system RAM just as if it was on an expansion card.


Yeah, I thought about that too, but since the original PCjr actually uses the first 128KB of system RAM as shared video memory, at first I wasn't sure if it would be compatible without such a ribbon-cable hack, since add-in memory on ISA cards always gets added on top of existing system RAM (or isn't that necessarily true?).

However, the shared memory is always mapped to base address B8000 and up anyway, and, according to this archived Usenet post (http://newsgroups.derkeiler.com/Archive/Comp/comp.sys.tandy/2009-03/msg00041.html), the Tandy 1000 in fact places the shared video memory on top of whatever RAM upgrade that is added to it, while managing to maintain compatibility with PCjr graphics modes. So I guess you'd be right: a ribbon cable might indeed not be necessary. Simply having sockets on the card to accommodate 128KB of RAM chips taken out of the motherboard might suffice.

In that case, an optional feature could be implemented where people willing to buy additional RAM chips could leave the full 640KB in the motherboard, and add RAM chips to the card, which would then map the memory directly to B8000, without having to share any memory in the 640KB region. Of course at that point, we'd be potentially cheating again, with the card having its own dedicated memory, but at least people would have the choice. ;-)

reenigne
January 8th, 2013, 10:31 AM
add-in memory on ISA cards always gets added on top of existing system RAM (or isn't that necessarily true?).

It's not true - ISA cards can implement whatever addresses they decode, and system board RAM addresses correspond to particular RAM banks. So you could certainly unplug the lowest bank of RAM and plug in an ISA card which implements it. Memory cards of that ere had DIP switches or jumpers to set which addresses the card should map to.

Eudimorphodon
January 8th, 2013, 12:19 PM
I suppose something that cuts to the heart of this thread would be the question: What is the goal? Is it to improve the CGA's competency as a gaming platform, or to provide better "business oriented" graphics? If it's the former the biggest things I can think of that might help without breaking the budget (or necessarily requiring more video RAM) would probably be:

1: Programmable raster interrupts. You could do this with a simple counter.

2: "Tile Mode" graphics. (IE, redefinable character sets, with the option of pointing the hardware at different character tables for different areas of the screen or allowing characters in sizes other than 8x8.) This would require clever programming of the CRTC and a few small hardware modifications to the pixel generation hardware but I don't think it would "cost" much.

3: An arbitrary RGBI pallette register that can be reloaded on a per region/per scanline basis. (See item #1.)

4: Per-region or scanline video mode swapping. (Also see item #1.)

5: More/better "chunky" low-res modes. (Like an official 16 color 160x200 framebuffer mode, or an "official" semigraphic mode that's more easily mixed with text characters.)

Item #1 would allow for both snow prevention (only redraw the whole screen during the vertical blanking period without having to waste time polling the CRTC register) and would facilitate getting more colors onscreen at once via pallette swapping tricks. Apparently there were at least a few games that used pallette swapping on CGA by polling the CRTC and then using a very precise timing loops, but said tricks break easily. Interrupts would make them much easier.

Item #2 would have allowed games to use the fast character-based techniques used by systems like the VIC-20 (and to some extent most home computers) to be used instead of/in addition to the standard interlaced framebuffer. Character graphics aren't as good as sprites and certainly have their limitations but for a certain class of programs they work really well.

Item #3's already been discussed, but it is worth emphasizing that it should have been pretty cheap to include. One 16 "nibble" SRAM chip/buffer and a couple latches and you're good to go.

Item 4: I'm not sure how practical it would be to include this on a CRTC-based card, I'm trying to think of a CRTC-based system that *did* allow it. Think of how machines like the C64, Atari 800 series and Apple IIgs allow for a different character or graphics modes to be mixed on the same screen. The latter two machines included video ASICs which allowed this to happen without CPU involvement, but to do it with the VIC-II in the C64 you used the programmable raster interrupt. *IF* it were possible on the fly to rewrite the CRTC registers at regular intervals during the horizontal blanking period using a raster interrupt then you could pull off some fun tricks like using a colorful low-resolution framebuffer mode for the 2/3rds of the display and using a real text mode for the remainder, both saving RAM and possibly providing support for smooth playfield scrolling (by adjusting the starting point in RAM for the framebuffer or text data when writing the CRTC registers.)

Item 5: Doable with some more fairly minor changes to the pixel generation hardware. The "semigraphics" idea may be moot if you added the support for user-defined character sets.

The unspoken #6 would be "sprites", but obviously that gets into la-la land unless we're willing to assume that IBM was interested enough in the project to cook a custom chip, which they quite clearly weren't. (The Atari 800's ANTIC and CTIA chips existed back in 1979 so it certainly would have been possible for them to do it.) The CGA card is actually sort of notable for its sheer chip count even by 1981's standards.

If the goal is better "business" graphics then it all goes back to wanting more VRAM.

reenigne
January 8th, 2013, 12:58 PM
Item #1 would allow for both snow prevention (only redraw the whole screen during the vertical blanking period without having to waste time polling the CRTC register) and would facilitate getting more colors onscreen at once via pallette swapping tricks. Apparently there were at least a few games that used pallette swapping on CGA by polling the CRTC and then using a very precise timing loops, but said tricks break easily. Interrupts would make them much easier.

It is actually quite possible to do this with the PIT already on CGA (assuming that the CGA/CRTC clock and PIT clock are derived from a common timebase, and I don't know of any CGA implementations for which this isn't true). You can use the status register to figure out where you are on the screen and then program the PIT frequency for 1 frame - the CGA frame is 912*262 pixels, and each PIT tick is exactly 12 pixels, so you can program the PIT count to 19912 for 1 interrupt per frame. Subdivisions of that are also possible as 19912 = 2*2*2*19*131.

This is in fact how the palette change for California Games worked, but there was a bug in the "am I on a genuine CGA" test routine which made it much more fragile than it really needed to be - the programmers forgot or didn't know that the default mode for PIT channel 0 is 3 (square wave generator) and that in this mode the PIT counts down twice as fast, so they weren't doing the test they thought they were (which was the wrong test anyway) - see http://www.reenigne.org/blog/geeky-video-timing-stuff/ for details.

The same trick can be used to switch between high/low resolution graphics modes, and even between graphics modes and 40-column text mode (with some CRTC reprogramming to get the right character row height). 80-column text mode uses a different CRTC clock, though, so that's a whole different ballgame.

digger
January 11th, 2013, 11:38 AM
Could support for smooth scrolling have been implemented smartly and cheaply in an alternative CGA design?

reenigne
January 11th, 2013, 12:10 PM
Could support for smooth scrolling have been implemented smartly and cheaply in an alternative CGA design?

We can't do much better than the CGA already does in that respect while still being based around the 6845 CRTC. The 6845 does actually have facilities for hardware scrolling which (for reasons I've never quite understood) was very rarely used (I think Super Zaxxon used it, I don't know of any others). The 6845 only allows scrolling with a resolution of 1 character, though (so, 8 scanlines in text modes, 2 scanlines in graphics modes, 1 character width in text modes, 16 pixels horizontally in high-res graphics mode or 8 pixels horizontally in low-res graphics mode).

To get perfect smooth scrolling, you also need to be able to change the position of the sync pulses relative to the image data to 1-pixel resolution, horizontally and vertically. The VGA (and EGA?) have facilities for this but the 6845 doesn't. With some CRTC tweaks you can probably do smooth scrolling vertically with 1 pixel resolution, but 1 pixel horizontal scrolling is impossible as you can't change the CRTC input clock except between 1 text character width in 80-column mode and 1 text character width in 40-column mode.

digger
January 24th, 2013, 01:02 PM
Here's an idea of what would have made the design of the original CGA card better: what if IBM had allowed the option of a memory RAM upgrade? Ship the system with 16KB of RAM on the graphics card, but allow it to be upgraded later through the addition of RAM chips into empty sockets, thereby increasing the memory to for instance 32KB, which would then enable such extra stuff such as 16 color graphics modes?

Yes, I know, from a business standpoint, it would be less attractive, since it would remove an incentive for customers to just upgrade to EGA or VGA later.. But IBM already offered the flexibility for customers to upgrade their system RAM, so allowing the same flexibility w.r.t. graphics memory wouldn't be that far-fetched.

reenigne
January 24th, 2013, 02:22 PM
Here's an idea of what would have made the design of the original CGA card better: what if IBM had allowed the option of a memory RAM upgrade?

That's a really nice idea! I think it would have been extremely easy to add such sockets to allow more pages of video data in existing modes (which is nice for games and animation). Allowing different video modes is also a matter of adding more pixel sequencers, which is not impossible but might have been just difficult enough to warrant doing it in a ULA instead of with discrete logic, yielding the EGA.

Anonymous Coward
January 24th, 2013, 03:37 PM
How about some piggy backed RAM chips ala AT style. :D

chjmartin2
January 25th, 2013, 09:23 PM
From the original:

"Make the palette fully adjustable in 640x200x2 and 320x200x4 modes (i.e. have 16 bits of palette registers instead of 6) so CGA games don't all have the same ugly green/red/yellow or cyan/magenta/white palettes. In the alternate universe where this change had been made, most CGA games would look dramatically better!"

You know, since I read this I haven't been able to stop thinking about it. There has to be an open port that could be captured and used to control a daughter board of some kind that would allow the 4 color mode to be remapped to any of the 16 colors. I don't understand the hardware enough, but you could cheat and have an LPT adapter that you would route the output signal to and put a programmable color shifter. You could set it to a screen mode, have a power circuit process the CGA signal. The cool part is that you would have to use a digital controller to modify an analog controller - without modern chips you couldn't digitize the input signal. Building the analog notch filters wouldn't be that hard, or, some type of voltage multiplier might work. Hmmmm.... LPT is fast enough because you wouldn't change the colors on the fly. Somewhat cheating, but, it would have been possible to implement back in the day, does not require modification of the CGA board and could be easily reproduced and provided for others to share.

e-CGA adapter :)

reenigne
January 25th, 2013, 10:52 PM
You know, since I read this I haven't been able to stop thinking about it. There has to be an open port that could be captured and used to control a daughter board of some kind that would allow the 4 color mode to be remapped to any of the 16 colors. I don't understand the hardware enough, but you could cheat and have an LPT adapter that you would route the output signal to and put a programmable color shifter.

It could be done, though the easiest way (except from an installation point of view) would probably be easier to cut some traces on the CGA card and add some chips to create the additional palette memory.

An external device could be made that modified the digital output, but trying to modify the analog composite output in this way wouldn't really work - the colour signals are ambiguous by that point, so you wouldn't be able to tell if a bit of cyan was actually cyan or an artifact of the placement of other pixels.

Plasma
January 25th, 2013, 10:54 PM
CGA output is digital. ;)

Would be even cooler if you could program your little device with color remapping for each scanline. Then you could use all 16 colors on one screen.

chjmartin2
January 26th, 2013, 12:09 PM
CGA output is digital. ;)

Would be even cooler if you could program your little device with color remapping for each scanline. Then you could use all 16 colors on one screen.

Well... That would require a lot of timing and I cannot see my way down that path. The fact that CGA is digital makes the challenge much easier. An LPT port adapter with a 9 pin input and output and a programmable bit remapper is all it would take. Hmmmmm. I may know enough to be dangerous... Hmmm. I wish my darn computer didn't need a floppy disk to boot. I need a new 8 bit SCSI controller. I am so stalled.

reenigne
January 27th, 2013, 05:20 AM
Well... That would require a lot of timing and I cannot see my way down that path.

Actually, it would't - you can just count the number of hsync pulses since the last vsync pulse - if you're intercepting the CGA signal anyway, that should be pretty easy. Though of course you'd have to have much more storage to have a separate palette for each scanline.


I wish my darn computer didn't need a floppy disk to boot.

I really should get around to putting my Arduino 5150/5160 keyboard port quick boot device into a form that other people can use. The code is on my github (https://github.com/reenigne/reenigne/tree/master/8088/arduino_keyboard) but I haven't sorted out the schematic properly and it's not very well documented yet.

rorypoole
May 9th, 2017, 04:30 PM
I'm pretty sure most of the early video cards on PCs used early synthesized ASICs. Outputting a single video mode would be complex but straight forward using discrete logic. However supporting all the video modes available in CGA for memory fetch & refresh, text/palette lookups, and frame clocking in discrete logic would be a really big board.

What is a more interesting project in my mind, although a bit impractical for a hobbyist, would be to take a modern PLD synthesis tool like Synplify Pro and impose upon it a target logic architecture made from commodity 74xx chips and no routing constraints rather than a macro cell and routing design from a given PLD vendor. That way you could code a CGA design at a logic equivalency level and it would synthesis the schematic for you. I suppose one could attempt to write a custom logic fitter using Icarus to parse the HDL into a truth table and some creative coding on the backend.
What about using two PCBs sandwiched together? like the IBM pga graphics card and others, but put the hot ram on the daughter board for better cooling, that gives you much more space, could go to 3 boards if you used slot one, why stick to 16k why not more? Or the option for more ram later?