Televisors!

This is just a short - scruffy post about Televisors. A friend of mine pointed me to the MUTR website which is selling minature Televisors and it set me thinking about variations on the theme. But first some information on the Televisor frame format.

Frame Format

There are variations on the Televisor format, but here's a summary of the MUTR one.

Frame rate is 12.5Hz.
There's 32 vertical scans so each scan is 400Hz.
The original doc specifying the minature Televisor specc'd the pixels frequency at 80 pixels per scan, so each pixel is at 25.6KHz.
Voltages are similar to composite TV: 1V peak-to-peak is normal. Sync is at 0V, black is at 0.3V, white is at 1.0V.
Frame sync is the entire 32nd scan - so the 32nd hole on the disc is used to check frame sync.
Line sync (here vertical sync) uses the bottom 7.5% of each scan, the bottom 6 pixels. So, there are 74 video pixels available.

That about sums it up, now for the ideas:

Visorpong

It should be possible, just using nearly the lowest MCU available ( e.g a PIC 12F509) running at 4MHz to implement pong, producing televisor video output. Here the PIC generates up to 78 pixels per scan; that's 32 clocks/pixel with 5.8 sync pixels. I worked out a basic output routine:

btfcc TMR0,0 ;(btfcs for odd pixels).

goto .-1

movf gGpio,w

btfsc 0x10+(pix/8),7-(pix&7)

addlw 1 ;bit 0=video signal.

movwf GPIO

Which takes 6+3n where n is the number of wait loops, so we have up to 26 c for computation; about 1872 overall. There's up to 10% jitter on pixel output. There's also 196 cycles available during sync.

Digital Televisor

Similarly a more highly-specced MCU, e.g. an AtTiny25 should be able to sample incoming Televisor video and control a real Televisor disc and output video onto it. This would greatly reduce the part count and the MCU would also be able to do automatic line and frame sync.

Televisor Simulation

You don't need a 75MHz Pentium to simulate a Televisor - a ZX Spectrum with an analog in would (just) be able to keep up with converting Televisor input onto its screen, my draft routine uses 75% of CPU converting samples into dithered bitmaps, here's the core of it:

in a,(sampler) ;10c?

out (sampleTrig),a ;start next sample (data is irrelevant). 21

add a

ld e,a

ld a,(de) ;first conversion sample.

inc e

ld (hl),a

inc h

ld a,(de) ;second conv sample.

ld (hl),a

inc h

I've been trying to think about how a VIC-20 could keep pace; running it in 16 chars x 20 lines with 4x2 VIC-20 pixels per real pixel, but my best basic routine so far would take 38cycles, about 20% too slow.