atari2600land's Blog

There are two separate tasks:

 

1. Hardware - make a PCB which will host the microcontroller and any other required components (like a voltage regulator to drop the +9V to +5V or +3.3V as required) which then replaces the PCB in an existing "cartridge". Size shouldn't be an issue as chips etc have gotten smaller over the years and the Microvision PCB looks fairly large.

 

2. Software - program the microcontroller to read the input from the keypad & dial and generate the output to the LCD controller and the speaker. Depending upon the microcontroller you use will determine what languages you will need to use. For the Parallax Propeller you would probably use assembly for the interface drivers and SPIN (a high level language similar to C, Pascal etc) for the game code.

 

Assuming you can get enough information about interfacing to the LCD controller, I don't see any reason the project wouldn't be possible given sufficient time, money & effort.

Weren't the Microvision carts actually the system itself (CPU and all)? You may as well make your own Pocket LCD system from Arduino parts and simulate the whole unit.

I e-mailed the two people you suggested. Still haven't heard back from either of them. But I suppose if the project is easy, then the problem could perhaps be in the LCD controller? I don't know why anyone has done this before, they had 30 years to do so. Is Microvision really that unpopular?

@theloon: Making a pocket system wouldn't be nearly as fun as saying "Look what I made: A Microvision homebrew!" I want to do this out of the love for the Microvision unit.

"Easy" is a relative term. I'd classify this more as "possible with significant TM&E".

 

I think also most people would look at the Microvision and see a very limited game system - 16x16 LCD (might be able to get 4 levels of grey), 4x3 button grid, paddle dial, speaker; and then compare that with the difficulty of creating new cartridges / games and arrive at the answer "too much effort to bother". But hey, that's not to say you can't do it. Just recognize that you're going to have to supply sufficient drive to do (nearly) everything yourself. (However, people have done amazing things as a "labor of love".)

I don't recall any grey scale, only on or off. I think if it had greyscale they would have used it for Connect Four.

@SpiceWare Depending upon the LCD controller it might be possible to drive the LCD refresh faster than the original game and generate grey like they do with pinball displays, i.e. black = 000, dark grey = 100, light grey = 110, white = 111 (where each bit is sent over 3 refresh cycles).

I think the main problem is how delicate the carts are. The CPU is on the cart!

I've looked at the MESS code and have a better idea of how the LCD controller works. It's basically a double 32 bit latch. CTRL5 latches the data, either from the 4 bit input (CTRL0-3) to the first 32 bit latch (auto incrementing the index) or from the first 32 bit latch to the output drivers. A high value on the row & column makes the pixel dark, which then decays to light over time. So there's no way to generate grey, or even a fast flicker. Should be able to do a slow strobe. CTRL4 controls which latch occurs.

 

Unfortunately, the MESS code doesn't indicate the input voltage level (would +3.3V be enough, or will you need a driver to boost the voltage) and the maximum "clock" rate (how fast can you change CTRL5), although you're somewhat limited by the decay rate.

The FAQ has some info, but it's not 100% clear.

 

The LCD driver chip is a 40 pin chip located in the Microvision base unit. The lines are Pwr, Gnd, 32 outputs to the LCD, 4 inputs from the microcomputer, strobe input and latch input. The LCD driver chip is very primitive. Screen contents must be latched 4 bits at a time, with a total of 8 packets making up one screen. After all 8 packets have been latched, they must be strobed in to complete one multiplex.

This matches my understanding of how the LCD controller works from the MESS code. 32 bits in, 4 bits at a time.

 

 

Up to 12 multiplex levels are possible; multiple levels are needed for moving objects to ensure adequate rise time. The trails left by moving objects were the result of the fact that falls times were much longer than rise times.

I get that the LCD pixels slowly turn off. The game can change a pixel to black via the controller, but there's no way (other than time) for the game to change the pixel to "white". But the multiplex levels confuse me somewhat. Does this mean that it requires multiple refreshes to change a pixel to black? Or how black the pixel is depends on how long the voltage is applied?

 

Finally, the voltage on the LCD must be inverted by turning the latch on, then toggling the strobe, and finally the shutting the latch off. The voltage must be inverted roughly 35 times per second, or the LCD glass will be etched with electrons.

This part confuses me. The MESS code has the output "strobe" as a latch high, strobe low to latch high, strobe high transition. But this "voltage/LCD must be inverted" is confusing. Maybe it's a bad translation. Using "refreshed" rather than "inverted" makes more sense. The "etched with electrons" worries me somewhat. I don't think there's any way to damage an LCD. Again, maybe this is just referencing the normal decay.

 

Internally, the 9V input voltage is dropped to 5V (reducable by the contrast knob to 3V). A square would turn on when 5V was applied, and off when below 1.67V was applied. To turn on a square, both the row and column would have to be on. So during the first refresh, the rows would be 1.67V - off and 5V - on, and the columns 3.3V - off and 0V - on. Voltages would be reserved during the next frame refresh. - R. J. Hoffberg

The MESS code says that both the row and column bits have to be on for the pixel to be changed to black, so these statements make some sense.

 

Net result - clarification is still required to better understand how the LCD & LCD controller works. Is it possible to generate grey by only setting a pixel every other refresh cycle? Are there requirements to invert the pixels beyond the row & column = 1 = black? A 35Hz refresh would require a 5kHz "clock", what's the upper limit? (I need to cycle count my driver to see how fast it is.)

Reading the Wikipedia articles on LCDs I think I finally understand the "inverting" statement. The LCD crystals react to voltage differences. The rows are a film on the top of the LCD and the columns a film on the bottom. A voltage difference between the two turns on the LCD. So to turn a pixel on the appropriate row is high and the column is low - or vice versa. What this is saying is it's important to reverse which is high periodically (e.g. 35Hz).

 

Now that I understand this better, I'll have to think about how to code this inverting into the driver.

I don't have my notes or data with me right now, but here's what I recall:

 

1. Send info for one (or more) rows (that will hold the same column data) (4 varying data bits pulse-latched 4 times, for 16 rows)

2. Send info for the column data for that/those row(s) (4 varying data bits pulse-latched 4 times, for 16 columns)

3. Send strobe pulse (I call this one the minor strobe)

4. Repeat the above 3 steps for a maximum of 12 times total (not sure why this limitation of 12 exists, but all the games seem to follow it - no game use more than 12 rows with distinct data on it at any single point in time). At this point you basically have one "frame" which should hold all the current screen information

5. Hold the latch active, send a strobe pulse, then release the latch (I call this one the major strobe)

6. Repeat all the above steps ad infinitum with new or the same data, as the gameplay prescribes

 

I don't recall the timing, order of the rows/columns data, or whether the system uses positive or negative pulses, but that is pretty easy to figure out.

 

If you look at the FAQ (http://www.handheldmuseum.com/MB/MicrovisionFAQ.txt for instance), you should be able to "translate" between my language and the FAQ's language.

 

/please don't ask why I know all of this, or why I have dozens of spare Microvision carts lying around... it's a secret.

Also, between step 5 and 6 is a delay... up to about 1/35 seconds, I guess.

Part of me thinks that hooking up the LCD controller inputs to a logic analyzer would be the best idea.