Thursday, January 1, 2015

35 Colors On NTSC

Some time ago, I played with a "flicker" technique on the CoCo that alternated screens between a 9-color (8 + black) "Semi-Graphics" mode and a 4-color "Color Graphics" mode on the VDG.  I combined that with a technique for teasing 8 on-screen colors out of the 4-color mode, giving a combined effect of 44 on-screen colors!  I then used this technique as the basis for showing puzzle pictures in Sluzzle, and there was much rejoicing...

Not long after that, I conceived of a similar technique that might solve at least a few of the problems with the 44 color technique at the cost of reducing the palette size a bit.  I let that sit dormant for a while, until I decided to play with it a bit during my 2014 year-end break.  Below I will describe the 35 color technique for those interested in hearing more.

Problems Abound

The main problem with the 44 color "flicker" technique is, of course, the flicker.  The mode toggles between the two base video modes (SG24 and G6C) at the vertical refresh rate (60 Hz on NTSC machines, 50 Hz on PAL machines).  This produces a noticeable flicker effect on the displayed screen, but unfortunately this is inherent to any "flicker" technique -- sorry!

The bigger problem with the 44 color technique is that it uses the aforementioned technique to get 8 on-screen colors from the 4-color modes of the VDG.  This is achieved by switching the colorset select (i.e. CSS) input to the VDG while a line is being drawn on the screen!  This changes between the two 4-color palettes as much as 8 times per line, doubling the amount of available colors on the screen.  (This 8 color technique is also used in the CoCo version of the Imagic game Dragonfire.)  Unfortunately the extra colors come at the cost of eating-up all of the available CPU while the 4- (now 8-)color screen is being drawn.

The other big problem with the 44 color technique is that only one of the base modes offers the (non-)color black.  Since the observed color at a given position is the average of the colors at that position on the two base screens, then no position will ever be observed as fully black.  Although the available dark blue is a workable substitute in many case, the lack of a true black is a big handicap for the 44 color technique.

Another Option

If we accept that we will only get 4 on-screen colors from the 4-color base screen, then we could free-up more CPU time while that screen is displayed.  This would allow more time for implementing a game, playing background music, or whatever else.  But what about black pixels?

It turns out that on NTSC CoCos (and Dragons), there is another option.  Due to how an NTSC video signal encodes color (and how the CoCo video circuit is implemented), the black and white 256x192 VDG mode (G6R) is effectively a 128x192 4-color mode offering black, white, "blue" (cyan?), and "red" (orange?) pixels.  This mode was very popular for commercial games on the Coco, and it is similar to using 4 of the 6 available colors in the high-res video mode of the Apple II.

So now we can use a "flicker" technique to alternate between the G6R (i.e. PMODE4) "artifact color" mode and a Semi-Graphics mode.  Since the G6R mode also offers black and white, both of those colors are still available when using the "flicker" technique!  I will show the available palette below.

Semi-Graphics Palette
G6R "artifact color" Palette
Combined "Flicker" Palette
Issues Remain

As you can see, this technique yields a nice range of usable colors from the VDG.  It does, of course, still have a perceivable "flicker" on the screen.  Also, the technique is limited to being used on NTSC displays.  Of course, the G6R mode can be used as a 2-color mode on PAL machines -- by ignoring the "artifact" colors, this could also be viewed as a 17 color technique...

Sticking with the NTSC world, there is one other problem.  Anyone familiar with the use of "artifact" colors on the CoCo will know that the patterns corresponding to "blue" and "red" switch at random between resets.  That is why so many CoCo games have an introductory screen with a message like "reset until this is blue".  Any program using the 35 color technique described above will need to address the same issue.

Finally, I am seeing some distortion to the colors near the top of the display.  I have not yet determined why that is happening, and it might relate to something else I am doing -- YMMV.  I'm going to downplay this distortion for now, as I believe it is likely caused by something outside the core of the technique described herein.

44 Color Me
35 Color Me
Nevertheless, I am getting decent results in my picture conversions using this 35 color technique.  The availability of a true black makes a huge difference, and that largely compensates for the ~20% smaller color palette available versus the 44 color technique.  With a lot more CPU time available, this technique could be useful for any number of programs on the CoCo including games.

I'm not planning to do anything more with this technique right now, but I hope someone else finds it useful.  I'm happy to consult with anyone that wants to try to make use of it.  In any case, be sure to stay tuned... :-)

Sunday, February 2, 2014

Working Keyboard

The end of the Retrochallenge event freed me to work a bit on spiffing-up my Micro Chroma 68 project.  Still not happy with the keyboard hack, I looked in earnest at how I might fix things...

Keyboard Adapter One-Shot Timer Circuit
One Shot

My earlier experiences with the PS/2 keyboard adapter and my own hack to make it work with the Micro Chroma 68 suggested that either the adapter was not generating a strobe signal at all or that the TVBug software was just missing it.  The former seemed unlikely, so I set about to address the latter issue.

Mike Willegal's documentation for the keyboard adapter tells me that the adapter should be generating an 125 microsecond pulse for every keystroke.  That translates to a little more than 100 CPU cyles during the strobe signal.  But since the strobe signal is not generating an interrupt, those 100 cycles may not be enough for TVBug to see the strobe if it happens to be doing something else.

To address this, I fed the strobe signal from the adapter to a 555 timer circuit configured as a one-shot timer.  This allowed me to send a longer strobe to the Micro Chroma 68 after a keystroke.  Experimenting a bit led me to use a 470 kΩ resistor and 0.1 μF capacitor, resulting in a pulse width of 47 milliseconds -- quite a bit longer than what the adapter was generating!  These values give me very reliable and pleasant keyboard entry, with no need for a magic "repeat the last key" button... :-)

Grounded Out

The Micro Chroma 68 keyboard interface also has provisions for 4 directional keys and a "Home" key.  I guess these allow for moving the cursor around on the screen, but I'm not sure I see the usefulness.  Anyway, letting them float was resulting in some random cursor movement as can be seen in some of my videos posted previously.  While mucking with the keyboard interface, I took the opportunity to ground all of those signals.  This also resulted in a much more pleasant TVBug experience.

Happy Camper

So, that is one less nagging problem with my Micro Chroma 68 build!  As long as I restrain myself from typing more than 20 characters per second (which would be 240 words per minute), the keyboard is quite usable.  With the new modifications I was able to reenter my flashing "Retrochallenge Rulez!" program much more easily than before.

Anyway, it looks like the Retrochallenge event was extended until midnight GMT today.  I wanted to get this posted so that my entry gets full consideration... :-)  But in all seriousness, I do hope and expect to keep poking at this one a bit more for a little while longer.  So, as always...stay tuned!

Friday, January 31, 2014

Final Lap

The end of the month is here, and with it the end of the Retrochallenge Winter Warmup for 2014.  Despite a few setbacks and unresolved issues, this has been a good one for me!  But before I declare my contest entry complete, I should at least get some code running on this thing... :-)

The Micro Chroma 68 Expressing Enthusiasm
Some Assembly Required

The TVBug monitor on the Micro Chroma 68 board only provides for loading machine language programs.  So, the first step is to find an assembler for the Motorola 6800 family of processors that runs under my Linux development environment.  There are a number of options for this, although it seems that not all assemblers are created equalWe must be cautious...

In the days of yore, Motorola operated a "freeware" BBS.  This BBS was originally available by modem, and later over the Internet as an FTP site.  Some of the files there included source code for assemblers targeting the full range of Motorola's CPUs, including the 6800.  Alas, the site is no more and it is now difficult to find even an old archive of it.  If anyone knows of such an archive, please leave that info as a comment on this blog -- that site needs to be preserved!

Fortunately, others found those tools useful as well.  While the unadulterated sources are difficult to find, a variety of slightly modified versions are available from a number of places.  So for now, I will be using the as0 assembler from the "masm" package.  It is a simple tool, but it more then fills the need at hand.

Manual Code Entry In TVBug
Hands-On Programming

The Micro Chroma 68 is already limited in its accessibility for loading programs, providing only an audio cassette interface and the video/keyboard console.  Since I still have not received those magic capacitors for the audio interface, I am limited to just the console for loading programs.  The keyboard adapter I am using has a provision for input through a serial port instead of the PS/2 keyboard.  But with the continuing "repeated characters" problem, manual intervention is still required.

Undaunted, I wrote a small program to put a message on the screen and assembled it with the assembler mentioned above.  The assembler outputs an S-record file by default, but I also had it generate a listing file.  That file had the hexadecimal values for all of the opcodes and data for my program, allowing me to enter them into the TVBug monitor manually.  The process was a bit tedious, but it was manageable for the small program in question.

Flash In The Pan

The original program merely cleared the display and wrote a new message to the screen.  At the end of the program, I simply inserted a busy loop to keep my display on the screen rather than returning to TVBug.  This worked fine, but didn't have quite enough sizzle for the end of the project.  I checked the schematics and found that the video timing signals from the VDG are available for the CPU to read on the Micro Chroma 68.  So, I changed the end of the program to spin in a loop that counted those timing signals and periodically changed the display's color set between the green and orange options -- exciting! ;-)

While changing the end of the program, I was faced with a problem.  I had structured the code such that adding new code at the end would force me to reenter a significant amount of data in memory.  My inherent laziness kicked-in and found another option -- I just jumped over the data and added new code at the end.  Maybe this sheds some light on why "spaghetti code" was so prevalent and accepted back in the early days of computing?  Or, maybe I am just a horrible coder...

Thus ends my entry for the Retrochallenge Winter Warmup 2014 event.  I hope that all of you have enjoyed reading about it as much as I have enjoyed doing it!  A few problems remain, and ultimately I would like to do something a bit more useful (or at least something more interesting) with the Micro Chroma 68 in the future.  I can't help but think that it would look right at home mounted inside of an arcade cabinet...hmmm...

Well, anyway...if you want to find-out what happens in the future then you'll just have to stay tuned!

Sunday, January 26, 2014

Two Steps Forward

My Micro Chroma 68 project is still in need of a solution for keyboard input.  The original (and long-term) plan is to use the Radio Shack ASCII-encoded keyboard, but that isn't working at the moment.  Until that gets fixed, I'll have to find some other option.  Fortunately, others have already faced this sort of problem and at least one of their solutions is available...

PS/2 -> ASCII Keyboard Adapter
Problem Solved?

The Micro Chroma 68 was roughly contemporary with the Apple I, and both used the same sort of ASCII-encoded keyboard.  While original Apple I kits are as rare as hen's teeth, replica kits are available and many people have built them.  These Apple I builders have faced the same sort of keyboard problem that I am facing.  So what do they do for keyboards?

At least one person solved the issue by using a microcontroller to drive a (somewhat) modern PS/2-style keyboard on one side and the ASCII-encoded interface on the other.  Even better, such a kit is available for sale!  I bought one and quickly built it.  Initial testing even suggested that it was working...

Close-Up Look At The Dead Bug Hack
Dead Bug

Despite initial impressions of success, I soon discovered a problem -- when pressing a single key multiple times, only the first keystroke was recognized by the Micro Chroma 68!  This is at least inconvenient and it could be crippling for entering data into the monitor program.  What might be causing this?

The ASCII-encoded interface was at best a 'de facto' standard and at worst it was no standard at all.  Such interfaces typically had 7 data signals and one strobe signal that signified when the data was valid.  But, the polarity of those signals and the timing of the strobe could vary between implementations.  The fact that any keys were being read by at all suggested that the data line polarity of the keyboard adapter matched the expectations of the Micro Chroma 68.  But what about the strobe signal?

The documentation for the PS/2 -> ASCII adapter indicated that the strobe signal goes high to signify that the keyboard data is valid.  Checking the source code for the Micro Chroma 68's TVBug monitor revealed that it was expecting the strobe signal to go low to indicate valid data.  I could not visualize how this might account for the observed loss of repeated keystrokes, but it seemed worthwhile to at least make the interface match the expected behavior.

I found a 74-series inverter chip in my parts stash and added it to the PS/2 -> ASCII adapter circuit using a 'dead bug' style of construction.  The hardware functions just as expected, and I verified that all of the connections were correct.  Unfortunately, instead of the Micro Chroma 68 only accepting single keystrokes it then didn't see any keystrokes at all...

Yet Another Hack...
Make It Work

Obviously, that was unacceptable.  But, simply putting things back like before was only marginally better.  So, what to do?

When first observing the "no repeated keys" problem, I did some poking around and found that I could get the Micro Chroma 68 to accept a repeated key if I used a probe to drive the strobe line myself.  As I indicated above, I have verified the connection between the microcontroller on the keyboard adapter and the strobe line on the Micro Chroma 68 parallel keyboard input.  So, I'm at a bit of a loss for why driving the signal manually works...

I can only figure that the Micro Chroma 68 is somehow missing the strobe signal.  I may be able to correct that with a one-shot timer, or there may be some other problem that I'm not yet seeing.  In the meantime, I have inserted a momentary push-button switch in series with the strobe line.  This allows me to manually drive the strobe line when I need to repeat a keystroke, so at least I can get around the problem in the short-run.

Once again I am left with an imperfect solution.  In the long-term I hope to have a more polished result, but for now I'm just trying to get each thing working well enough to make the next step possible.  I guess that is a bit like life, or parenting, or something... :-)

Anyhow, now I've got a mostly working Micro Chroma 68 board (sans audio cassette storage interface), I've got a way to view its video output (via a hack on a satellite board), and I've got a way to put information into the machine (with an extra step for repeating keystrokes).  I may be limping a bit, but I think I can make it across the finish line!

Now I suppose I have to brush-up on 6800 assembly language and figure-out how to write a little program to run for the end of the contest.  I've got some big distractions coming this week, so don't expect too much!  But until then, please do stay tuned...

Thursday, January 23, 2014

Keep It Clean

When last we left our daring hero, the Micro Chroma 68 board was just barely showing some signs of life.  The video output was stable, but the garbled mess on the screen was a telltale sign that something was still wrong with the circuit...

Micro Chroma 68 Display
By The Book

The manual for the Micro Chroma 68 board has some simple procedures defined for debugging a non-functioning board.  The first step, of course, is simply to check your work:  check power and ground connections; ensure that parts are installed correctly; and, check for shorted or open connections on the board itself.  I completed those checks, yet the problem persisted.  Fortunately, the next round of testing was more fruitful.

The manual described a few simple and temporary modifications to make to the circuit.  These modifications hold the CPU in reset while forcing the address decode circuitry to select the ROM chip.  This puts predictable values on the address and data lines, allowing for some simple testing with a voltmeter.  These tests showed that the CPU was behaving correctly, but that the data bus held the wrong value.  Further testing showed that while the CPU was driving the address bus correctly, the ROM was seeing the wrong values on its address lines.

Ancient Anti-Static Foam
Baked-On Gunk

More checking continued to show the proper connections on the board between the CPU socket and the ROM socket.  Digging deeper revealed that the disconnect was between the CPU socket and the pins on the CPU itself!  This is a new (or NOS) socket, and it shows no sign of being worn-out.  So, what was happening?

The CPU is one of the chips that were original parts included in the box of the Micro Chroma 68 kit.  The chips were inserted into a block of anti-static foam which served to contain the chips and to protect their pins from damage, and there they sat for roughly 35 years.  When I removed the chips from this foam, I noticed that some bits of the foam stuck to the pins of the chips.  I scraped the visible bits of foam away and gave it no more thought until I witnessed the results of the testing described above.

I acquired some parts cleaner from a local electronics retailer and used it to clean the pins of the chips that were included with the Micro Chroma 68 kit.  After this cleaning and closer visual inspection, I was satisfied that the chips were clean and serviceable.  I re-installed the chips and repeated the tests described above.  Some of the pins now properly reflected the state of the address bus, but to my chagrin some of them were still incorrect.

Strangest Electronics Tool Ever
File It Away

After some thought, I decided on a more aggressive strategy for cleaning the pins of the chips in question.  Using some small hobby files, I filed the pins until they were slightly shiny.  I then hit them again with the parts cleaner, just to remove any remaining filings.  I re-installed the chips onto the board, and another round of testing showed correct values for the address and data lines at both the ROM and the CPU.  Then I removed the test hacks to the reset line and the ROM address decoding, and I powered-up the board.  The picture at the top of this entry shows the result -- the TVBug sign-on message and an apparently working Micro Chroma 68 board!

So, where does that leave things?  I still need a keyboard solution to allow for input -- more on that in the next post, most likely.  I'm also still missing a couple of capacitor values related to the audio cassette interface for storing programs -- hopefully they will arrive soon!  Finally, it would be nice to see at least one program running on the board by the end of the month.  I'm not sure if I can solve all of these issues between now and then, but I might be able to keep things interesting in the meantime.  I hope you will stay tuned!

Sunday, January 19, 2014

A Few Things Amiss

This weekend brought me a bit more time for working on my Micro Chroma 68 build.  A few more parts have arrived, and I found an alternative for an important one that was still missing.  The board is showing some signs of life, but perhaps just barely so...

Garbled Output on the Micro Chroma 68

I had collected most of the parts required for this build over time, and I ordered the remaining parts during the first week of January.  Unfortunately, there are still parts that have not arrived.  I received two of the missing capacitor values this week, but I am still missing three more.  Two of the missing capacitors are only used in the audio cassette storage interface, so they aren't required for board bring-up.  Unfortunately, the missing parts also include one of the capacitors in the clock circuit.  So, the board has not been testable until recently.

The missing clock circuit part is a 50 pF capacitor.  While poking around in my parts stash, I found a bag of 47 pF capacitors.  The Micro Chroma 68 kit instructions specifically mention the use of a 47 pF capacitor as a substitute for that part.  Since that capacitor is mated with a variable capacitor on the other end of the crystal, the clock can still be tuned to the proper frequency.  I installed the capacitor, tuned the clock using the frequency counter feature of my oscilloscope, and moved onto getting a video display!

Perfboard MC1372 Circuit

The Micro Chroma 68 board is designed to provide an RF signal for feeding a TV through its antenna connection.  As I mentioned in an earlier post, I attempted to hack the circuit to disable the RF signal generation and to just output a composite video signal.  Alas, I don't seem to have understood the MC1372 datasheet as the device was not generating any video output at all.

I went back to the drawing board and built a new MC1372 circuit based on a schematic in the MC6847 datasheet.  The new circuit was similar to the hack I had attempted, but different in a few details.  I built it on a piece of perfboard, and used some wires to plug it into the MC1372 socket on the Micro Chroma 68 motherboard.  Thankfully, this circuit worked to provide the video output in the picture at the top of this entry.


Of course, it doesn't take a lot of expertise to deduce that the screen output pictured above isn't exactly what the board should be producing.  I would have expected to see a sign-on message from the Micro Chroma 68's built-in monitor software, TVBug.  The garbled mess on the screen certainly suggests that something is wrong.

Letting the board sit there and run sometimes results in some screen characters getting changed, and fiddling with the reset button or the break key has some effects that offer tantalizing clues that at least something is working on the board.  Removing the video memory results in a more uniform pattern on the screen, suggesting that the 6847 is able to read the video memory.  So, there are some signs of life on the board even if the current state is far from perfect.

It isn't clear to me what the problems are with my Micro Chroma 68, but these clues suggest that the fix could be as simple as replacing a bad chip or fixing a short-circuit or a cold solder joint.  Finding the answers will require a combination of deductive reasoning based on observations and methodical inspection and testing of the board itself.  There is no telling how long that might take, but please do stay tuned! :-)

Sunday, January 12, 2014

Rapid Advance

The Micro Chroma 68 build is making good progress!  My schedule aligned on Saturday such that I had several hours which I could fill with the smell of melted metal.  So far the only casualties are a spool of solder and the worn-out tip of my soldering iron... :-)

Progress on Micro Chroma 68 Construction

Progress Report

With most of the required parts in hand, it was easy to make progress on construction.  In particular, I had been waiting on the various IC sockets to arrive.  It is standard practice when assembling a PCB to install the sockets first.  Sockets have lots of pins, and it is easiest to get them installed properly when there is nothing else on the board to prevent them from laying flat while being soldered.  Other parts that lay flat (like resistors and diodes) are typically next in line, followed by capacitors and special items like crystals, connectors, and switches.

I now have the IC sockets, resistors, diodes, and capacitors installed in the Micro Chroma 68 board, with exceptions for the RF tank circuit (discussed below) and the handful of parts which I still don't have.  This includes a handful of oddly valued capacitors, and one socket that I overlooked when ordering the rest.  It should be simple to install those parts as they get here.  As long as they arrive on time, those parts should pose no barrier to completing construction.

Imperfect Fit for C5 and R2

I have been pleased at the availability of some of the less common parts required for the build.  Between surplus electronics providers and various auction sellers, I have been able to locate usable options for every required part so far.  Unfortunately, it can be difficult to find the exactly correct footprint for every part.  In particular, I had to do some creative bending of the leads on both the potentiometers and the adjustable capacitor in order to fit the holes on the PCB.  This isn't uncommon or unexpected -- I'm just glad that the pins were long enough to reach!  Of course, doing this probably gives the vapors to all of those "period correct" Apple I replica kit builders... ;-)

Engineering Opportunity

One part that I made no attempt to find is the variable inductor that forms part of the tank circuit for the RF modulator.  This part is unnecessary because I don't intend to have RF output for the video.  Such a circuit was useful back in the days when the only way to use an unmodified TV as a monitor was by building a tiny TV transmitter into your device.  But nowadays simple composite video is a widely available option, and it will generally provide a much higher quality display as well.

Fortunately, the Motorola MC1372 part used in the RF modulator circuit can be configured to produce just the composite video without the RF modulation.  As detailed in the datasheet for that part, this mostly requires replacement of the RF tank circuit with a single diode.  The devil is in the details, of course.  But I intend to work-out those details and find a way to hack the PCB in order to produce composite video instead of the RF output.

Other than the video output hack, the board is almost ready for some limited testing.  Unfortunately, one of the missing capacitors is part of the clock circuit.  So while I can do some limited testing for shorts/opens and the like, I can't do much to test the functioning of the CPU or VDG or anything else in the system that needs the clock to function.  The waiting game continues, so like me you will just have to stay tuned...