Cromemco dazzler replica project

[Hugo Holden]

Fantastic stuff! I'm curious about the process of using Picture IT - I'm not familiar with it.. are you basically tracing over an original layout image? And then cutting and pasting things like pads, etc? My tactic has been to download whatever I can get my hands on into photoshop, convert to B/W, and then clean up with manual brush work. I did that to recreate an SWTPC PPG joystick PCB, using just the parts layout diagram from their manual (all they supplied) to 'reverse engineer' it.

Basically I use the original board track layout from the book image or from a photo of the pcb. If you look at the bottom of page 3 in this article, you can see an image of drawing over a photo (without the grid) on a pcb, this is why the tracks look red in color:

www.worldphaco.com/uploads/Personalityreplica..pdf

If the board photo is not taken square on aspect (often the case), I use Photo Studio 4 to fix that as it has an aspect ratio corrector for a tilted image. But I find Picture IT much easier for general drawing , so I use that rather than PSP4.

Using the transparency option I place a 2.54mm grid over that, so I can see both images at the same time and align this with the IC pads. I m most cases the original designers laid these boards out on a 2.54mm grid and sometimes even the vias fall on regular places between these, but that is somewhat variable. Then I trace over that. Also it is a matter of having everything in proportion. The IC footprints effectively generate the scale and the board perimeter must be specified.

If you look at the attached image of another board, you can see how a 2.54 mm grid is helpful as it can also be used to specify the board perimeter if that is a multiple of 2.54mm.

Those Dazzler images were very close to Cromemco's faded ones. But one important thing, for an S-100 card is the exact board perimeter geometry and the position of the fingers must be bang on. It was found when my images (essentially Cromemco's touched up images) were overlaid on the standard s-100 board image, the position of the fingers were not exactly correct, this was a small error in Cromemco's foil diagram geometry. So that got corrected before the boards were made.

Also, something that gets overlooked sometimes when you see projects where pcb's have edge connectors designed to plug into a socket, for example S-100 boards or SOL personality modules etc, it is important that the leading edge of the pcb toward the fingers has an initial taper and that the corners of the rectangular edge of the pcb projection with the fingers are slightly rounded, to assist & guide the entry of the card edge into the socket with minimal initial force. This is kinder to the socket otherwise there is a high initial force and an abrupt entry into the socket, which doesn't sound very romantic either. This extra machining is more work for the pcb maker of course, adding to the price, which might be why some pcb quotes look cheaper too, the Devil is in the detail. I also use mx-3 to lubricate the edge connectors & sockets to avoid wear on all my s-100 boards & SOL-20 sockets, PET GPIB connector etc.

Like I say its all very old school image drawing, but it works.

There was a thread recently where Gerbers were made from my .jpg images in my RM-65 video card article, that was a fun one, being a compact 4 layer board and trying to figure out the two internal layers. Maybe if we found out how that was done, what process was used to make the Gerbers, it could be helpful. I'm not sure where that thread is right now.

 

[wperko]

Hi,

It would be nice to have a webpage that contained all the files for all the Processor Technology boards and kits.

That is high resolution board images, schematics for EagleCAD, KiCAD, EasyEDA and the board files along with BOM.XLS and Pick'nPlace files.

IF I can get the files and documentation, I can add it all to my website and archive it in a couple of public archive sites online (WayBack and Archive.org) and probably the S100Computer website too to minimize loss of the info.

As a friend is working on new DAZZLER software (reverse engineering the original stuff) I can also add his documentation and files on the website too.

 

[hmb]

Hi,

Maybe you could contact LD Electronics and ask for a copy of all the related files and share them here? I talked to a couple of friends that said LD Electronics hasn't responded to their emails either.

If you or your friends are interested in buying the boards from LD Electronics, email george at ldelectronics.com.au - George has responded to all my inquiries regarding my interest in purchasing these boards.

 

[daver2]

>>> As a friend is working on new DAZZLER software (reverse engineering the original stuff) I can also add his documentation and files on the website too.

I am working on some software libraries for the Dazzler (slowly though). It may be good to talk to your friend and join forces...

Dave

 

[wperko]

Hi,

I'll send the link to this page to my friend "John", but it will be up to him if he wants to connect.

 

[Eudimorphodon]

The renewed activity on this thread has me wondering again about the possibility of programming my perpetually-under-construction homebrew video processor to partially emulate the Dazzler, although without some work the results wouldn't be particularly "Dazzling" as said board only does monochrome video... and to do the mono high-res video of the Dazzler in the correct aspect ratio I'll need to see if I can tweak my microprogramming to do interlaced video. But at least I might be able to spit out some dithered dot patterns as a proof of concept.

Just to confirm something that confused me for a few minutes looking at the diagrams in the documentation... the Dazzler's memory map is such that in the high-resolution modes (64x64 color and 128x128 mono) the second half of each scanline is offset in memory 512 bytes from the first half? That's... interesting, to be sure. I think I have an idea how to handle that. But... man, the memory to pixel mapping of the Dazzler is pretty arcane, especially in the high-res mono mode.

Did a little digging around and I found this Github repository with a beautifully detailed and commented version of the assembly source code for the famous Kaleidoscope program for the Dazzler, it would be awesome if more of the demo programs for it could be made available in such an accessible format. If I'm crazy enough to go through with trying this attempt at emulating it I'm going to have to re-assemble the program to reside at a very non-standard ORG for the hardware I'm interfacing to.

 

[Hugo Holden]

Eudi said : " ... the Dazzler's memory map is such that in the high-resolution modes (64x64 color and 128x128 mono) the second half of each scanline is offset in memory 512 bytes from the first half? That's... interesting, to be sure. I think I have an idea how to handle that. But... man, the memory to pixel mapping of the Dazzler is pretty arcane, especially in the high-res mono mode".

Hugo replies : Yes, tricky for me, I mentioned this in my article and in post #40. To get a 2k image of Che into memory, derived from a .bmp I had to process it and make it and load it in 4 separate 512 byte blocks. Give my limited programming ability I found that very difficult, but I never give up, so I got there in the end. I know Daver2 is working on a plan where it will be possible to convert common image formats into Dazzler images , all in one go, and that will be a very nice tool for Dazzler owners to have. From the article this was one of the difficult parts to deal with that "arcane" byte format: CMPF3.COM was a tricky program. The first 4 pixels of the first line from the SF (source file) are examined and a partial byte (4 bits D0,D1,D4,D5) for the TF (target file) 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.

 

[Eudimorphodon]

It'd be pretty easy to bang together a simple Python program to do the image conversion, but something that runs on the original hardware will definitely be more of a pain in the neck. The high-res mode is pretty reminiscent of the "semigraphics" modes of things like the TRS-80 or S-100 cards from Poly or SSM, but it's using all 8 bits for the dots instead of six and has the characters lying on their side. (IE, it's essentially like a 32x32 text mode of all graphics characters... except of course because of the weird memory mapping it's really four 16x16 text mode displays... head properly hurting now.)

I wonder if there's much software that uses the low-resolution 32x32 color/64x64 mono modes. Only being 16 "characters" wide makes for a freakishly low memory clock...

 

[Hugo Holden]

It'd be pretty easy to bang together a simple Python program to do the image conversion, but something that runs on the original hardware will definitely be more of a pain in the neck.

But, if it is for a still frame image at least, the whole thing could be done in the modern computer and the final image byte file sent to the SOL or other S-100 computer, via the serial port to the computer's RAM, it could be a simple .ENT file for the SOL.

If it is a program with moving graphics/sprites etc, altering the RAM content that the Dazzler reads, that would have to run inside the vintage S-100 computer and be a lot more elaborate and probably both 8080 and Z80 compatible code. Probably a slow moving creation could be done in BASIC.

 

[daver2]

The Dazzler library I am working on is written in Z80 assembly code (so it will run on a Cromemco ZPU).

The DAZINIT function takes a mode 'number', the address of the start of memory to be used by the card image and the default colour/brightness bits (if the selected mode uses these). This function does all of the internal 'magic' to initialise the card. A separate register holds the address of an 'n' byte structure that the library can use to hold internal state information. This address is passed to all of the other functions.

A number of 'wrapper' functions are provided to deal with the hardware (for example DAZODD and DAZEVEN to wait for the ODD or EVEN line respectively).

The main function (DAZPLOT) will plot a single point on the screen (irrespective of the configured mode) - with the colour or bit state being specified. This is what I am working on at the moment - and I am trying to optimise it to be as fast as possible.

Once I have got DAZPLOT working, I can then start work on the line drawing algorithms. These will come in three different 'flavours' for speed - HORIZONTAL LINE (DY=0), VERTICAL LINE (DX=0), and a generalised algorithm (where both DX<>0 and DY<>0). The latter will be much slower than the former two.

I can then work on shapes such as BOX and BLOCK using the fast versions of the line algorithm.

After that, it then depends upon what we want to do with the library... Sprites, text fonts, ...

I will be supplying the source code, so it can be assembled and linked with the user's program. If using a 'sensible' linker - it may be possible to only include those functions that are actually used by the user's program. Of course, on a Cromemco, we could load the library into a dedicated bank of memory and switch it in on demand. This would save space in the user program executable and would have a smaller memory footprint - at the expense of the memory in the bank.

Many years ago, I wrote a sprite control program for the BBC microcomputer in 6502 assembly for school children to design their own games (rather than just playing them at the computer club we ran). It was amazing what could be done with that library. I can't quite remember now whether there was any hardware assistance for the sprites in the BBC microcomputer - but I don't think there was. I'll try and dig out the program if I can find it...

Dave

 

[Hugo Holden]

Many years ago, I wrote a sprite control program for the BBC microcomputer in 6502 assembly for school children to design their own games (rather than just playing them at the computer club we ran). It was amazing what could be done with that library. I can't quite remember now whether there was any hardware assistance for the sprites in the BBC microcomputer - but I don't think there was. I'll try and dig out the program if I can find it...

Dave

That is very cool !

 

[daver2]

It was amazing how quickly teenagers pick-up technical things once you get them interested...

After a little training - they had sprites moving all over the place at the next meeting for the games they were writing!

I have been working on my dazzler library a bit this afternoon. I have sorted out the first part of the pixel address function quite neatly. Most of the effort is done once in DAZINIT with DAZPLOT using test and mask bytes computed by DAZINIT.

Now I am working on the best way to do the 2 bits or 8 bits per screen byte code... I am slowly seeing the light ...

I was thinking about sprites and games etc. for the dazzler. Perhaps you could do some tests for me with your equipment?

I suspect the dazzler should be able to very quickly switch from one screen buffer to another.

By waiting for the end of frame state (bit D6 transitioning from HIGH to LOW in port 0Eh) it should be possible to then switch the start address in port 0Eh and for the dazzler to instantaneously switch from one buffer to the next without glitching.

If this is the case, we should be able to perform animation by using off-screen memory (hidden buffers) and switching them to the user during the end of frame period.

You should be able to test this by setting up multiple buffers (with different contents) and switching them appropriately.

Dave

 

[Eudimorphodon]

By waiting for the end of frame state (bit D6 transitioning from HIGH to LOW in port 0Eh) it should be possible to then switch the start address in port 0Eh and for the dazzler to instantaneously switch from one buffer to the next without glitching.

If this is the case, we should be able to perform animation by using off-screen memory (hidden buffers) and switching them to the user during the end of frame period.

FWIW, that won't work on that CPLD-based Dazzler recreation that's been mentioned a few times because it doesn't actually do DMA like the original does. (It has the register to move it around in the memory map, but it drags its own memory buffer around with it.)

 

[daver2]

I am writing my library for either a real Dazzler or Hugo's 'real' recreation.

It will be interesting to see how hard we can push the Cromemco Dazzler to the limits of what is possible!

It is a useful piece of information though that there are incompatibilities between the real and CPLD recreation though.

Dave

 

[Hugo Holden]

It is a useful piece of information though that there are incompatibilities between the real and CPLD recreation though.

Dave

It has been my experience that recreations of complex vintage 74 series logic hardware, except in very specific simple cases of gate array replications with programmable logic etc , doesn't match the original perfectly. This is even the case in a system where no software is running. A good example of this is Atari's Arcade Pong with 65 TTL IC's and 42 ball velocity vectors. Even Atari themselves didn't replicate it accurately when they compressed the design down into a single LSI IC for home Pong. That game was not as good. In short it was an inferior replication. In addition, coded Pong's (every I have tried) don't beat the detail and performance of the original game, especially with the encoding of the 42 ball velocity vectors.

It took me a while to figure out why all the copies and clones of Pongs were not as good as the Arcade Pong pcb. The reason became obvious after a while. Atari did not publish an operating theory for their schematic, and it is not at all self evident from brief inspection either. It was not until after a very large amount of work, I performed & published the detailed circuit analysis on Arcade Pong, that all the information became available, especially on the function of the very clever vertical velocity & horizontal velocity encoders. Then it could be cloned in a way that does replicate the original game play function (though I have not seen this done exactly yet). Given that all the TTL's for original Arcade Pong are still available, I couldn't see the point of replicating it with modern devices, which often go obsolete and harder to get than the old TTL's ! Also it can be shrunk in physical size further using SOIC package logic IC's and the mini Pong board layout I designed.

I think the same applies to modern replications or recreations old complex computer hardware, like the Dazzler. It really requires an extensive circuit analysis & timing diagrams of the original work and its internal sub-systems, to get a proper replication not just a "facsimile" of the original output on a VDU. But of course if anyone goes this far, after a while, just like Arcade Pong, it will become obvious if you really want "the real thing" the only way to get it, is to build it with the original parts & design. Though I'm not opposed to removing the occasional hardware bug as I did for Pong, it had 6 bugs, one of them was a "Ghost in the Machine" bug, and we have seen a few of these lately in PET computers.

www.worldphaco.com/uploads/ARCADE_MINI-PONG.pdf

 

[Eudimorphodon]

I think the same applies to modern replications or recreations old complex computer hardware, like the Dazzler. It really requires an extensive circuit analysis & timing diagrams of the original work and its internal sub-systems, to get a proper replication not just a "facsimile" of the original output on a VDU.

The difference in this case is not a mistake, it's intentional; the design of the "Dazzler II" substitutes a dedicated dual-ported memory buffer chip for the DMA circuitry in order to make the card less picky about the S-100 computer it's plugged into. (The original Dazzler card is apparently quite picky about what memory cards it will work with, the documentation pretty much says flat out it won't work with dynamic memory cards, as well as CPU cards and other details.) Again, it tries to replicate the *behavior* of the DMA system by remapping where in memory its dedicated buffer is mapped, but it basically just "snoops" on memory reads and duplicates them into the buffer, it's never actually pausing the system and reading the real values from the system memory.

In judging whether or not this was a reasonable design decision I think a valid question is whether any of the "original" software for the Dazzler made use of this idea of paging through memory instead of just picking a location for the framebuffer and pounding away at it, and if so, how commonly was that functionality used? Clearly it would make sense if someone was doing some kind of animation software for the Dazzler, but for an arcade game or kaleidoscope program it wouldn't really come into play.

Editorializing, I think there's definitely room in the Dazzler design for modernizing it in somewhat more compatible ways. To me an obvious angle to take would be to integrate Dazzler-compatible output circuitry into a 32-128Kbyte SRAM memory card that'd replace (or at least supplement) whatever RAM card you have in your Altair or SOL-20; this would eliminate memory card compatibility problems and potentially much simplify the DMA circuitry. Lacking something that radical I'd at least say there'd be value in substituting a SRAM for that unobtainium shift register it uses as buffer memory. Since the Dazzler was designed to work with "random" combinations of CPU and memory cards I don't see that there's likely to be anything about this setup that's as "timing critical" as a Pong machine.

 

[Hugo Holden]

Lacking something that radical I'd at least say there'd be value in substituting a SRAM for that unobtainium shift register it uses as buffer memory. Since the Dazzler was designed to work with "random" combinations of CPU and memory cards I don't see that there's likely to be anything about this setup that's as "timing critical" as a Pong machine.

I found a compatible modern quad shift register that should work, mentioned in my article, it requires an adapter though, as although it is functionally compatible it is not a pin for pin match. One option would be to change the pcb tracks on the original Dazzler board to accommodate it, though I decided to keep that original.

The timing considerations can come into play depending on what software was running and how demanding that was. It could go either way with a case of software running on a replica and not on the original or around the other way, possibly, unless everything in the replica was spot on. One point I was getting at is that there is much more to a good replica than meets the eye, and that information has to be acquired from very thorough study, analysis and testing of the original design. It is best to have the actual original hardware to study with the scope too. That is where all the work is, or should be. But many replicas get created because the original hardware is rare, expensive and not on hand.

It is important that the computer's memory that the Dazzler hijacks with DMA is SRAM, it was specified in the manual, the refreshes of DRAM upset the the proceedings. All types of SRAM S-100 memory cards I have tried work with it. This was one way they saved money with the Dazzler (and they were well out of pcb space for more chips too, though the chips could have been pushed closer together) was to not have it carrying its own video memory. On the other hand, other S-100 video cards of the era, such as the Matrox ALT-256, ALT-512 and the Compupro Spectrum board, all carried their own video RAM chips. But as I recall the they had to be slotted into the host computer's address map anyway, deactivating the host memory over that range is required, so the total amount of available memory was not increased, so not a lot was gained. Curiously too, in the case of the ALT256, once you wrote data into its video memory, you could not read the bytes back out, though they changed that in the ALT512.

 

[Eudimorphodon]

I found a compatible modern quad shift register that should work, mentioned in my article, it requires an adapter though, as although it is functionally compatible it is not a pin for pin match. One option would be to change the pcb tracks on the original Dazzler board to accommodate it, though I decided to keep that original.

Digikey lists the 74HCT7731 as obsolete and unavailable, Mouser doesn't list it at all, Rochester Electronics claims they can get it but the minimum order is 132 of them. (Which is a strangely specific number.) Even checked AliExpress, no hits. So... really, that doesn't seem to be much help.

I think you could emulate this part pretty easily with a GAL and a small SRAM, but of course that definitely wouldn't be "original".

The timing considerations can come into play depending on what software was running and how demanding that was. It could go either way with a case of software running on a replica and not on the original or around the other way, possibly, unless everything in the replica was spot on.

I know this is maybe me being a little thick, but I'm a little puzzled where a "timing problem" would emerge in a Dazzler clone if you changed the exact mechanics of the pixel output chain. I mean... I guess if you really obsessively kept your eye on the registers that indicate end of frame and did some calculations it might *sort* of be possible to "race the beam" with a Dazzler, but I'm not sure why you would. Maybe you could switch between resolution settings or color/BW partially through a frame? I'd be really interested to know if anyone ever did that; I'd think the resulting program would be *extremely* picky about having to run on hardware almost precisely matching the original. (Meaning the CPU card and other details of the system; speed would be pretty critical here.)

(If someone wants to write a program that does race the beam in a Dazzler it'd definitely be interesting to see.)

On the other hand, other S-100 video cards of the era, such as the Matrox ALT-256, ALT-512 and the Compupro Spectrum board, all carried their own video RAM chips. But as I recall the they had to be slotted into the host computer's address map anyway, deactivating the host memory over that range is required, so the total amount of available memory was not increased, so not a lot was gained.

So far as I can tell both the Matrox cards were programmed via I/O ports. (IE, you stuck pixel coordinates into a couple registers, and then set the pixel value.) Which means they didn't interfere with main memory at all. The Compupro board, yes, looked to the computer like it was an 8K SRAM board except it also happened to be able to stuff video out the other side. (Which essentially makes it like what we generally think of a video card today, IE, something like an IBM CGA board.)

Anyway, that's really kind of beside the point of why I suggested why it wouldn't be a *terrible* idea to integrate a Dazzler work-alike into a memory card; it was all about just sidestepping the potential compatibility and reliability issues with original boards. Modern SRAM is much faster than the old stuff, so it instead of relying on razor-thin timing margins and fairly complex DMA circuitry to drive other RAM cards you'd have carte blanche to "cycle steal" however you wanted from your captive local memory.

(The main win I'm thinking of here is you could ditch the whole "cache" stage entirely and just implement it mostly like a normal video card. But of course this wouldn't technically be a "replica" of the Dazzler, so... you know, different strokes for different folks.)

 

[Hugo Holden]

Eudi:

I bought these 74HCT7731's on ebay in the past from this seller, 5pcs for $24 USD:

Lot of 5 pcs 74HCT7731N NOS | eBay

Find many great new & used options and get the best deals for Lot of 5 pcs 74HCT7731N NOS at the best online prices at eBay!

www.ebay.com.au

Yes I was referring to just the Spectrum board, with the way it substituted in for system RAM.

Also I found out something interesting about the Dazzler, which I would never have found out without an actual board to experiment with and to display images & test. Cromemco used a non standard (non NTSC compatible) weighting of Red Green & Blue to create a grey scale. I only found this out because I had a good look at the color encoder design, it was not immediately obvious. So if the original image was derived from an NTSC color image and displayed in monochrome, the grey scale is way off. However, interestingly, for color images, because of the high color saturation, this design anomaly is not very obvious. It was a curious error or oversight, since the idea behind that Dazzler was at least an attempt to gain compatibility with a color interlaced NTSC system. Apparently it had been used in the Television industry to help with weather map presentation. I decided not to modify that though and keep it original. A full emulation of the original would have to consider its design anomalies as well and decide to replicate them or not, but you would have to know they were there. The other thing is that the sync generator doesn't include equalizing pulses around the vertical sync, so there is a small interlace (line pairing error) which you could regard as a "defect" or "adding to the charm".

 

[Eudimorphodon]

bought these 74HCT7731's on ebay in the past from this seller, 5pcs for $24 USD:

The same listing is on American eBay so... yeah, I guess there are 45 of these in a warehouse in Israel. That doesn't really negate the point that it's a really hard to find part.