Cromemco dazzler replica project

[Hugo Holden]

Out of curiosity, do you have any software that runs in the 4x resolution B&W mode? I'm wondering what the 128x128 pixel mode looks like. (Did anything actually use it?) Mainly I'm wondering about both modes... is the active video field 256 lines out of the possible 262 in height? I imagine a fair bit of it must get cut off in the overscan on a typical CRT, which leaves me wondering what the "effective" on-screen pixel resolution is. In color 64x64 mode are the color pixels three pixels tall (192 lines) or four (256)? I assume it must double-scan the 128x128 in the 4x mode... or is that rendered as just a "letterboxed" strip?

Since you mentioned the Matrox ALT-256... is there much software out there for that? I was kind of wondering if I might be able to emulate it without too much trouble with the video processor idea I've been working on. According to the manual it works by setting individual pixels by receiving X/Y/on-off coordinates via I/O ports, there's no "direct memory access"? Is there any delay in this process with the card, or can the CPU ram pixels in at full speed with no wait states?

In the x4 mode the size of the image stays roughly the same size, it doesn't go letter box looking. I will make an image file for that and take a photo.In this mode you can selectively deactivate R, G & B, and this is used to help the initial setup of two of the potentiometers on the board.

The image doesn't extend near the full raster width or height, there is a good gap around it on the monitor I'm using which has the usual small amount of raster overscan.

Yes, in the ALT-256 you cannot get the image data out of its RAM after you put it there. But in the ALT-512 you can, there is a register to do it. For that I had to write a program to extract it and save it to a disk file. Matrox did make an elaborate program called MTXgragh, but I have not assembled and tested it yet. Here is the article I wrote on the 256 and 512, I'm doing the same thing for the Dazzler:

http://worldphaco.com/uploads/MATROX_ALT256.pdf

 

[Eudimorphodon]

In the x4 mode the size of the image stays roughly the same size, it doesn't go letter box looking. I will make an image file for that and take a photo.In this mode you can selectively deactivate R, G & B, and this is used to help the initial setup of two of the potentiometers on the board.

The image doesn't extend near the full raster width or height, there is a good gap around it on the monitor I'm using which has the usual small amount of raster overscan.

Yeah, I noticed it didn't look like it was getting cut off vertically, which is why I was guessing it must use 3-line tall blocks in the 64x64 mode for 192 vertical total, but that left me scratching my head what they would be doing for 128x128. (You're not using a PAL version of the Dazzler, right?)

The TRS-80/VDB-1-ish video board I'm working should also be able to do 256 and 512 pixel wide graphics without a whole lot of hassle; I'm was intending to look into some kind of page-flipping so I could page through the graphics memory in the same 1k window as text, or some other direct-access scheme, but when I saw how simple the ALT-256's interface was it got me wondering if it'd be worth adding the option to emulate pixel access like that.

 

[Hugo Holden]

More to report on the Dazzler project.

I managed to get the Dazzler Kscope program into high memory inside a spare ROM left over from the Sol with three brains project. So now it is there along with some other favorite programs. There is MTEST, The walking man, MWIPE, TRAIN and now the Dazzler K scope running at address DC00H (I have one rom left to put something else interesting in). The MWIPE program is a version of MTEST where I modified it to load the memory between any address range, with a chosen byte. That way I can easily erase or fill blocks of memory, or all of it, with the same byte.

Also I have determined that the F3342DC IC is a suitable shift register substitute for the rarer TMS part, as was shown in the PE article. I wondered because its a lower frequency rated part than the TMS3417, but looking at the actual clock frequency in this case, it appears to be around 1.8MHZ and the F3342DC is 2MHz rated. (I think 5MHz rating for the TMS3417)

I have attached more images of the K. Scope. To stop the program I just reset the Sol (upper case & repeat), that also resets the dazzler boards and turns them off, but the image bytes at that moment remain in ram. Then to switch the Dazzler back on to see the ram image I just manually enter using the Solos EN at 0100H:

3E 81 D3 0E 3E 30 D3 0F C3 04 C0 / & enter. Then just type EX 0100. This tiny program switches the Dazzler back on in the same mode and returns to Solos and it then just displays the still image, so I could take the photo.

 

[Hugo Holden]

Further to report. I didn't have much luck setting the two R & G color phase controls according to the Cromemco manual. Ideally when they are right, there is a correct white balance and the R,G,B,CY,Maj, and yellow look normal.

So I wrote a simple test pattern into memory (using the MWIPE utility) and it made it much easier to set the controls for the correct colors (color phase). They made a fairly simple circuit with inductors and gates to get the phase shift required for red & green with respect to blue.. The R & B and magenta look good, but the G, yellow and cyan a little desaturated. The levels for the color amplitude mix are set by fixed resistor, so later I might tweak these values a little.

 

[Corey986]

I have a question... what RAM cards are you using in your Sol-20? I never could get my original Dazzler working on my Sol-20 with the 16KRA and 32KRA dynamic RAM cards but it works fine on my Altair which has a couple of static 4K MITS RAM cards.

 

[Hugo Holden]

I have a question... what RAM cards are you using in your Sol-20? I never could get my original Dazzler working on my Sol-20 with the 16KRA and 32KRA dynamic RAM cards but it works fine on my Altair which has a couple of static 4K MITS RAM cards.

It says in the Cromemco Dazzler manual that the Dazzler requires fast static memory with an access time of one microsecond or faster. I'm using a SCP-110A 64k static ram card configured for 48k.

Dynamic ram doesn't work because of the internal refresh activities delaying the proceedings (I believe)

In addition, I mentioned on post #8, there could be another issue, I noted that with some early revisions of the Dazzler they may possibly have used the PRDY connection on the S-100 bus by looking at the track work (foils) on earlier boards. It turns out in the SOL-20, this can cause a conflict (or at least it did with a Matrox graphics card I have in the sol) because in the Sol they drive that line high & low with a driver IC and the outputs conflict if a card tries to use that line too, so it needs to be swapped over to the XRDY line that achieves the same result without a conflict. The revision of the Dazzler I made (Rev C) doesn't use PRDY.

 

[Hugo Holden]

I have been writing some programs to get test patterns out of the Dazzler. Its trickier than it looks because in the 2048 mode the addresses result from four adjacent 512 blocks and its not a progressive address sequence.

In any case what surprised me was that the luminance levels assigned to the colors are not NTSC standard. In order of decreasing luminance Cromemco made it White, cyan, magenta,blue,yellow, green,red and the next level down from that is low intensity white, then the low intensity versions of the same colors. I labelled them with the byte values, each byte codes two adjacent pixels in this mode (same mode as the K scope program operates in) . In monochrome mode, the grey scale steps look pretty good.

I made a standard NTSC style color sequence which is white ,yellow, cyan, green,magenta, red & blue of just the high intensity colors. It looks pretty good considering the luminance levels are non standard (as seen on the scope recording right hand photo)

In the monochrome mode, they still leave the color burst there, it is usually standard in TV engineering to switch that off so the TV set's color killer activates. Also the burst is a non-standard length wider than usual (This was noted in the past by Martin Eberhard, there is a diagram on the Deramp website about it), but that has no effect on the color rendition.

Also, normally for an NTSC color encoder, it is fundamentally a system of suppressed carrier modulation of the color subcarrier with the phase (with respect to the burst) giving the color and the amplitude the color saturation. For example on a black or white part of the image signal, there would/should no significant color carrier. In Cromemco's system, cobbled together from some logic gates and L-C phase shift networks built around logic gates, it results in chroma carrier over the white and black areas. Still, having said that, for the simplicity of that part of the circuit, it works amazingly well and is pretty impressive because of that simplicity. On the other hand two MC1496 balanced modulator IC's make a good encoder and they were around at the time.

Oddly also the video output is 52 Ohms, not the typical 75 seen in video systems and when terminated into 75R has a high level , but that is easily adjusted with a resistor on the pcb.

I also posted a test pattern of what standard NTSC video looks like, colors with respect to the grey scale on a typical TV set.

 

[Hugo Holden]

.......In addition I have just discovered this afternoon something very interesting.

On the net and youtube there are some "simulations" or demonstrations of the Dazzler running the Kscope problem in "modern hardware" and viewed on a digital monitor in an RGBI mode.

The result is nowhere near the same as the original hardware, with its unique non standard version of luminance weighting on the color values and run on a composite analog video monitor.

The "simulations" or running the code on modern reproductions or with RGB outputs are not nearly as captivating.The sharp definition between the pixels makes it look more stark and less blended and the color levels don't match the original display.

Oddly I have experienced this before. The original Pong arcade game (with 66 TTL ICs not dissimilar to the Dazzler's 72 IC's) was unique. Every computer generated version of it I have seen, was not the same as the real game, either in the way it looked, or the exact way it played. There are many subtle details of course, in that case a non interlaced scan and even the persistence of the CRT's phosphor played a part in the appearance of the moving "ball". (The Dazzler is an interlaced scan).

So there is in fact no replacement for the original Dazzler hardware (if you want to experience the original performance) running on the original display unit (a color TV or color CRT monitor with composite color inputs).

What you see "regenerated" for a display on a modern VDU by the simulators or modern hardware with different color weighting is just a facsimile of the real experience of the Dazzler's unique hardware, especially in the color encoder area.

 

[Hugo Holden]

Investigating this more : The unusual Dazzler luminance levels of the RGB come about due to the choice of the color mixing resistors. In a standard color system, the relative levels are Red = 0.3, Green = 0.59 and Blue = 0.11. This was done in the NTSC televsion system because of the relative brightness of the different hues.

However, looking at the Dazzler schematic with the 15k,30k and 62k mixing resistors, their luninance or Y mix, on account of those values is; Red = 0.14, Green = 0.28 and blue = 0.58. Which are about right in the three proportions but not standard. Its why Cyan for example has the next highest luminace level to white (as seen on the test pattern, on the left, post #27) I wonder why they did this, or if maybe it was an error ? For example if you started with a color picture file, that had a standard weighting, compressed it and loaded it to display by the Dazzler, it would be incorrect in grey scale displayed in monochrome modes. The colors would have to be altered to get a correct grey scale.

This means that if the R,G,B signals, intensity signal and syncs where extracted from the Dazzler card directly, to drive an RGB monitor, the resulting images would look a little different than on a composite monitor.

(One interesting "trick" in their sub-carrier color encoder, to get the correct phase for blue with respect to the burst and their is no adjustment for this, they simply inverted the the sub-carrier with a gate, and relied on the gate propagation delay to shift it later, so then they could get away with just the two adjustments for R & G that used the L-C network and inverter gates. But it didn't shift it exactly to blue, it looks just a tad purple on the test pattern. Its possible the propagation delay in the individual IC14 could affect this )

 

[Hugo Holden]

Further work has shown that regardless of the arrangement of the Luminance mix (the relative proportions of the R,B &G added to make white), due to the fact that the colors are highly saturated, there is not a huge difference to see in a color image. Its only when you switch the card into the monochrome mode, it becomes obvious that something is badly wrong with the luminance mix.

Essentially, it appears that Cromemco switched their three resistors around. The overall proportions are correct, of the resistors relative to each other, but they are assigned to the wrong color.

Probably nobody noticed this, as in RGB versions of a Dazzler there would be no issue, and on the composite out, the color image is little different regardless of the assignments due to the heavy color saturation.

I switched the 3 resistors around to give standard NTSC luminance levels, and this fixes the grey scale issue, going from a standard color test pattern sequence, to a monochrome image. So, R9 gets changed to 62k, R11 to 15k and R10 to 30k, to get 0.57G, 0.14B and 0.29R, practically identical to that of the NTSC system.

(In the test pattern image I assigned the 8th bar top right as low level white, like the first bar on the lower left, otherwise it could be black).

It is hard to think why this wasn't spotted before, but maybe since most people using the Dazzler were into color images, it was never noticed.

I have attached a picture that shows the abnormal grey scale produced with the resistors as Cromemco had them and a diagram to show how the ratios come about. I had to blur the images because of the patterning effect with the digital camera vs the CRT image.

The output amplifier in on the card acts analogously to an op amp (due to the NFB to its input) and its input acts as an inverting input, with a virtual earth to mix all signals without them affecting each other.

 

[Gary C]

Fascinating stuff and an interesting read.

 

[Hugo Holden]

Fascinating stuff and an interesting read.

Thanks.

With all the technical talk I realized I had not posted a picture of the completed PCB's. The edge connector and all the pads & vias are gold plated.

The IC sockets are all gold plated American Augat machine pin types. I was not happy with the sockets I could get here. I used a blue sockets for the interconnect socket, these are a dual wipe gold plated pin type (fairly rare now).

I had to make a tool to assemble the 16 way crimp connector for the interconnect ribbon cable, so its thin flat pins don't get damaged when its pressed together.

Back on the topic of the luminance order or mix Cromemco chose to use (if it was not a slip up) clearly they did it so that the byte value (or nibble for each pixel) that coded the white to grey to black level, reduced evenly with the value of the byte. So that FF is white and 00 black and reducing greys in between. But of course like this, if you display a color image in monochrome mode on a composite monitor (by selecting the card to monochrome or by setting the TV to monochrome) the grey levels are incorrect at least according to NTSC standards.

 

[Hugo Holden]

Also, I can see the attraction for programming monochrome images where the magnitude of the nibble controlling the pixel is proportional to the pixel brightness, as Cromemco had it, with their luminance resistor choices.

But they could have got the best of both worlds. In their normal picture mode, the pixel is coded (just considering a nibble) MSB...>...LSB as I,B,G,R where I is the intensity. On the other hand if they had used I,G,R,B for that, then they would have got the best of both worlds, because the grey scale would have conformed to the magnitude of the nibble and the color's luminance levels would have matched up with the NTSC standard too and the RGB output (if there was one) would match up with a composite output.

 

[Old_hitech]

Hugo, The cards look great. I'm curious how they fit in your Sol-20. Can you show a picture of the cards in your Sol-20?

 

[Hugo Holden]

Hugo, The cards look great. I'm curious how they fit in your Sol-20. Can you show a picture of the cards in your Sol-20?

They just sit directly on top of each other in any two of the slots. I don't have a photo on hand, I will get one at some point. Currently I have my SCP-110A memory card in the bottom slot closest to the mobo, my N* disk drive card above that, the two Dazzler cards above that and on top the ROM card I made with the handy programs in it. On these dazzler boards I used preset potentiometers with the adjustment facing rear. Also, on the pcb design I moved the video output connector pins a little away from the board edge to avoid the plastic slides in the SOL. The Dazzler boards are standard S-100 card perimeter geometry.

 

[Hugo Holden]

I have attached a couple of diagrams.

If Cromemco had assigned the colors to the memory bytes (or nibble differently) and changed the luminance resistor array around then in the monochrome mode, their grey scale still would have had an increasing level with respect to the nibble magnitude and, if they had a color image, that was derived from an NTSC image, it would have the correct grey scale.

The diagram shows how to alter the resistor array and switch around the RGB connections to achieve this.

Probably though, there was not too much of an interest in displaying a color image correctly in monochrome mode (though that might have been forced on a user if they didn't have a color monitor) .

I'm not proposing that anyone would modify Dazzler boards to achieve this, after all that would be like trying to change history. But it interests me that they didn't have it this way in the first place. It seems to have escaped their attention that in the NTSC system (and after all they were trying to generate an NTSC compatible signal) that Green has a higher luminance level than Red which has a higher level than Blue. So if they also wanted the shades of grey where the increasing value of the nibble that controlled the pixel resulted in increasing intensity, the color order that they assigned to the memory bytes, needed to be different.

 

[wperko]

Hi, Is there a place to get the gerber files for the DAZZLER board, or where we can buy a blank board, or buy a tested and ready to go DAZZLER board?

I want a true to the original DAZZLER board for my Altair 8800c computer to test new software being developed by another guy who currently is remaining anonymous.

 

[Hugo Holden]

Hi, Is there a place to get the gerber files for the DAZZLER board, or where we can buy a blank board, or buy a tested and ready to go DAZZLER board?

I want a true to the original DAZZLER board for my Altair 8800c computer to test new software being developed by another guy who currently is remaining anonymous.

I only have the .jpg images I drew, but LD Electronics here in AU (a pcb maker) has the Gerbers and they will make the pcb's for any customers that require them. All the IC's are very easy to get, except the TMS3417 or F3342DC Shift Register. As I mentioned in my article the 74HCT7731 could be made to work I think with some re-wiring.

Here is a link to the final draft of the article I did on the Dazzler:

https://www.worldphaco.com/uploads/THE_WORLD_FAMOUS_CROMEMCO_DAZZLER.pdf

 

[wperko]

Hi,

Cool, I snagged the PDF to archive ... nice article.

 

[Hugo Holden]

Hi,

Cool, I snagged the PDF to archive ... nice article.

As you will see in the article, I had some fun making the file to display the 4x resolution image mode of Che Guevara. It required quite a lot of "byte juggling" from the original bitmap image. But I am not much of a programmer (I do hardware), it probably would have been much quicker with an experienced programmer on the case doing it in C.
Here is a remark about one of the trickier parts of it (for me at least) (SF = source file, TF= target file):

The first 4 pixels of the first line from the SF are examined and a partial byte (4 bits D0,D1,D4,D5) for the TF is created by masking operations on the first 4 bytes. Then the address of the SF is altered to the next line of bytes to create the final 4 bits, D2,D3,D6,D7, of the byte under construction for the TF. When one byte of the TF is made from examination of 8 bytes from the SF, the SF addresses are moved on to examine the next 8 bytes of the SF and create another byte for the TF.