[Coco] [coco3] upscan video converter

[John R. Hogerhuis]

On Sat, 2005-07-16 at 01:26 -0400, RJRTTY at aol.com wrote:
>        Attached is a diagram of  the basic configuration for the upscan
> converter I'm building and I present it here for your approval/rejection/
> vilification/ridicule/etc... given the recent flame activity on the list 
> lately
> I'm hoping for the best.  :)
> 
>         The converter will consist of the Avelogic AL875  high speed
> ADC to digitize the RGB video output of the coco3.   From there,
> the digital video is input to the Averlogic AL250 upscan converter.
> This will transform the digital signal back into an analog video
> signal with a scan frequency of 31 Khz compatible with all
> SVGA capable monitors.     The board signals will be line locked
> with an ICS1523 programmable video clock synthesizer and line
> delay.
> 
>        On board programming functions will be performed by the
> ATMEL ATtiny12 microcontroller.    The three above video
> chips are programmable via an I2C interface.  The ATtiny12
> microcontroller will be programmed itself to interact with
> the I2C bus.


I definitely think you are doing the right thing adding a
microcontroller to the mix, rather than the battery/cassette stuff
discussed at some point.

This makes a more versatile device: you can think a little bigger and
add support for other vintage platforms just by adding cables, and
reprogramming the microcontroller, no design changes.

>         One function of the ATtiny12 will be hardware and
> power up resets.    Whenever there is a hardware reset, the
> microcontroller will set the registers of the three video chips to
> coco3 specific default values.    The converter will do a hardware
> reset with the push of the reset button on the enclosure or when
> directed to do so by software command on the I2C bus.
> A power up reset will also result in having all registers
> either set to coco3 specific default values or to a list of
> programmable values depending on the choice of the user on
> power being initially applied to the converter.
> A "simulated" power up can be also be performed
> by software command on the I2C bus.
> 

It was an intereting hack w/out the uC, but with the uC, Why keep the
I2C bus stuff around? Since the uC is doing it anyway, this seems
superfluous. If anything, I'd rather see a RS232 header on the PCB for
connecting up and reprogramming firmware on the uC, or just getting
status.

I guess it doesn't really impact anything though.

>         Another function of the controller includes a software controlled
> standby power down of the monitor.
> 

Nice.

>          I have sent a proto type of the converter to Torsten Dittel for
> evaluation of the Averlogic video chips and use with PAL systems.
> The use of the coco3 RGB video cable to transmit I2C signals was
> his idea and represents a great contribution to the project.    The use
> of the ATMEL ATtiny12 controller was also the idea of someone
> on this list tho I cant remember thier name at the moment.  Sorry.
> 

I don't know... I think I was one of the first to suggest a uC versus
the cassette port, but someone else suggested the ATMEL.

>         One regret I have is I could not find a way to power the
> converter without using a wall-wart that did not involve opening the coco3
> enclosure and modifying the motherboard.

A necessary evil. I suppose you could increase the COGS slightly by
adding a AA or 9V battery holder. But you would still want to have the
wall wart connector for home use.

>    Also, I have constructed
> the input cable with the audio signal enabled.   This means I will
> provide a sound output port on the converter.   Should I include an amplifier
> and speaker?

Doesn't the sound come out the coco's rca audio jack? The user could
always hook that to a good cheap PC computer speaker if they wanted.

Maybe just put a jack the same size as standard PC computer speakers.
Then you could use whatever (amplified) speaker you like.

>          Someone also suggested I provide an output port for the I2C
> bus in the converter for use with  external I2C devices.    Is there
> any interest in this?
> 

It doesn't fit the device really. I'm a big believer in one-device
one-function. The coco already has lots of I/O connection possibilties.


>          So there it is.     Maybe somebody knows something I have
> missed.      If so, let's hear it.    I have become quiet proficient at
> using the PC board software I got from the PCB manufacturer so I expect
> to come up with a more compact and cost effective design this time around.
> All tho my first try at it was good enough to evaluate the concept.
> 
>          One more thing.     What do we call this device.    Anybody got a 
> catchy name?
> 

coco specific:

CocoVGA
ColorVGA
Cocomon
CocoMatch
CocoScan
Cocovega
XCoco

weird generic:

Upmon
RetroMon
ProMon
Neumon (Seinfeld fans?)
NeutroVGA
ReVGA
Remon


If you like one you are welcome to it, but I'd suggest doing a google
search as a poor man's trademark search.

-- John.