Image Capture on the TI 99/4A Computer
This is not a new project which was initially started in 2015, but it was never well documented and I was not very happy with the end result at that time. I picked it up again last month and made significant improvements with some guidance from Tursi, so here it is.
Image capture has not been attempted previously on the TI 99/4A computer even though most other contemporary computers did have such a facility developed for them. While I realize that nowadays it's not really necessary since one could snap any picture with a digital camera, process it using Tursi's Convert9918 program (http://www.harmlessl...n/onesoft.cgi?2) and transfer it to the computer, there is still something special about doing this directly on the TI.
The first challenge was figuring out which capture camera to use, with the major requirement being ease of interfacing and good documentation as well as low cost, and I ended up settling on the Raspberry Pi camera. It has a large amount of support available online and is very easy to work with. Of course this entailed using a Raspberry Pi SBC as well, but I already had a couple of spare ones, namely model B, lying around, and they are dirt cheap anyway.
A standard bitmap image on the TI has a resolution of 256x192 pixels, or a total of just over 49,000 pixels. With that many data points to transmit to the TI, I opted to use the TI's parallel port (PIO) for ease of access and processing. One of the issues encountered at this point was the fact that the Raspberry Pi does not have a parallel port, so the solution was to simulate one by commissioning 8 GPIO pins on the board to act as a bidirectional 8-bit parallel port via software. Another issue related to the fact that the Raspberry Pi operates at 3.3V whereas the TI operates at 5V, therefore requiring the use of an interface between the two in order to convert the voltages back and forth and avoid frying the Raspberry Pi. The interface also allowed the gating of information to and from the TI.
Here's the schematic:
The idea here is that the Rpi camera will capture a raw RGB image at a resolution of 256x192 pixels, which produces 3 bytes of information per pixel, one for each red, green and blue colors. Obviously that's a massive amount of information, and so I had the Rpi compress the three bytes into one, taking advantage of the fact that the blue color is poorly perceived by the human eye. In the final scheme, one byte per pixel was produced, with 3 bits for red, 3 bits for green and 2 bits for blue, which was then transmitted to the TI one byte at a time.
Here's the initial breadboarded prototype:
I experienced a significant amount of noise with that prototype, likely related to the mass of wires required, but I was confident that the design was sound, so I bit the bullet and decided to create a double sided PCB for the project. This was the first time I had attempted to create a double sided PCB, and the end result was barely satisfactory, although it did require a lot of nursing to correct for missed vias and broken traces.
The general protocol for data transmission from the Raspberry Pi to the TI was as follows:
-Both handshake output lines start LOW
-TI polls the RPI handshake line, waiting for HIGH
-RPI sets the data port pins with valid data
-RPI then sets its handshake output HIGH to indicate data is available on the port
-RPI then polls the TI's handshake output, waiting for HIGH
-When TI see the RPI handshake high, it reads the data byte from the data pins
-TI then sets its output HIGH as an acknowledge
-TI then polls the RPI handshake line, waiting for LOW
-RPI sees the TI pin go HIGH, and releases its handshake (sets it LOW). RPI is now free to go process the next byte
-TI see the RPI line go LOW, and sets it's handshake LOW. TI is now free to process the byte.
-This process resumes at the top.
On the TI side, I initially used an extremely primitive method of processing the image where I averaged the values of the RGB colors for each row of 8 pixels after decompressing the received bytes and chose the closest color from the TI's palette to assign to that entire row. If you recall, the TI can only assign a single foreground and a single background color to each row of 8 pixels due to the limitations of the 9918 video display processor. For black and white, I used the same method of RGB averaging, but then selected a threshold between white and black that gave the best image. Needless to say that the results were less than stellar...
And this was where things stood for the next 3 years, until I decided recently to revisit the project. I contacted Tursi regarding the algorithms he used for his Convert9918 PC program, and he was kind enough to give me all the information needed for me to revamp the image processing program on the TI. I decided to skip color processing at this time given that it would have been very intensive from a processing and memory standpoint and would make for a very long image display time, although I might re-visit this at some point in the future.
Black and white
Obviously a major improvement! The whole image transfer process takes about 45 seconds, which is pretty reasonable. Source file for the half-tone program below
Disk image with all the source and compiled files (E/A option 3): TIVISION.dsk (180KB)
Here's a video of the entire project. Another fun one
- peterfleeman likes this