8-bit Computer TV Channel Use

[Mark J. Blair]

> On May 23, 2015, at 10:28, Steven Hirsch <snhirsch at gmail.com> wrote:
> 
> On Sat, 23 May 2015, Chris Osborn wrote:
> 
>> 
>> On May 23, 2015, at 8:24 AM, Mark J. Blair <nf6x at nf6x.net> wrote:
>> 
>>> In the middle will be some FPGA to perform any necessary magic. I've been looking at a prohibitively expensive ($115) one that has enough dual-port RAM blocks to support a frame buffer.
> 
> Getting an acceptable combination of crisp 80-column text and proper color aliasing from a converter is decidedly non-trivial.

Even back in the day, I believe it involved swapping the cable between a monochrome monitor and a color one. I expect that this universal converter idea will require a way for the user to tell it whether they want color or monochrome video at the moment (and might as well let them choose what color phosphor to emulate). That way, an Apple II user who wishes to use modern displays could switch between 80 column mono mode for text or color mode for graphics, without swapping cables or displays.


>  I own one of just about every commercially available (and hobby) converters and precisely none of them provides a universal solution.  Some give great displays from an Amiga and suck for anything else.  Of my two (pricey) CVP CM-345S converters, only one provides useable display from an Apple IIGS.  My GBBS-8220 can occasionally be coaxed into giving a solid display from a Color Computer 3.  The list goes on...

Aha! I've heard Nth-hand accounts of trouble getting vintage computers to play with video converters, but you sound like one of the folks with firsthand experience.

> If transparent, tweak-free emulation of a classic CRT display were easily doable, it would have been done by now.

Agreed! I envision that the converter should have some sort of smarts to help it figure out what sort of input it sees, but even in the ideal case it'll probably need some capability for user tweaking or mode switching for corner cases.

> On May 23, 2015, at 10:41, tony duell <ard at p850ug1.demon.co.uk> wrote:
> 
> Problem with TINY parts is soldering them :-). The SAW filters I used (with a conventional tuner module) were
> round metal cans about 0.5" in diameter with 8 pins on IIRC a 0.1" spacing. Very easy to handle. If you are 
> designing something for others to build (even in principle, i.e. you are making it an open design) then using 
> impossible to handle parts is a bad thing if there are alternatives.

The SAW filters I used are small enough that my 46-year-old eyes have trouble seeing them without a magnifying glass. :) I do almost all of my soldering under a stereo microscope any more. But I can solder down to 0201 discretes that way, although I don't like going smaller than 0402. I don't have a lot of experience with hot air soldering yet, but it has become quite available to hobbyists, with hot air systems now available for around $100. The "Maker" movement has done a lot of good in the area of making surface mount soldering more approachable by Joe Random Hobbyist.

Now, one of the engineering problems I'd need to solve would be how FEW PCB layers I could get away with using that FPGA. 16+ layers is not uncommon for full die escape, but layer counts like that are far too expensive at the volumes this thing might sell in. Cell phones have high layer counts, but only because they sell in huge volumes.

I favor Xilinx FPGAs since they're what I use in my day job, and those are all BGAs. I would not offer this device as a kit in any case; I've helped Ian out doing rework for US FreHD customers, and even good old through-hole soldering can be hard for folks without a lot of experience. I'd rather design for automated assembly than spend a lot of time on tech support for kit builders who had trouble. With a BGA on it, the board's going through a reflow oven anyway.

> And IIRC US NTSC uses AM sound (Europe uses FM). I think you can forget about stereo sound, since
> I doubt any home computer had a stereo RF modulator.

No, I think it's FM. I recall listening to TV audio on my US FM tactical mil radios whose frequency coverage extended over the bottom 2-3 VHF TV channels, back before they turned off the analog broadcasts. I agree that stereo support isn't needed, as stereo TV post-dates the computers in question if I'm not mistaken. But if I do the final demod digitally in an FPGA, then adding AM support wouldn't be a big deal if needed.

> Be warned that there are many versions of PAL.

That sounds like a deep rabbit hole to fall down! It might result in a case of "if you want me to add support for the computers from your country, send me one so I can develop with it". But this is also a point in favor of using an FPGA: Fairly major architectural changes just look like firmware upgrades to the end user, who can remain blissfully ignorant of my development pain. :) If I use one of the Zynq chips (which I'm currently favoring), then upgrades can probably be as simple as swapping an SD card for the end user. Don't want to force people to buy a programming cable and download a 15 gig development platform!

> Evil thought (and I have not worked this out yet). You are going to be connecting the RF signal straight from
> the computer to this unit. Do you really need a _tuner_? You have essentially one strongish signal. What about
> an untuned receiver and demodulator? At VHF totally possible, UHF might be a lot harder...

That evil thought is definitely worth exploring! The thing I'd worry about is the strong local AM broadcast station getting in through the computer's lousy shielding and ruining the plan. I have a local AM station that confuses my MFJ antenna analyzer if I don't use a broadcast band blocking filter, or wait until they turn down the output power at 8PM.

> On May 23, 2015, at 10:45, Jochen Kunz <jkunz at unixag-kl.fh-kl.de> wrote:
> 
> Depending on your personal preference FPGAs can be an annoying fight  in
> an obscure HDL with proprietary tools running on Window$, or it can be
> lots of fun and new things to learn. :-)

Dealing with them is part of my day job, so maybe I'm a good person to tackle this one? :)

> On May 23, 2015, at 10:45, tony duell <ard at p850ug1.demon.co.uk> wrote:
> 
> 
> Given that the OP is planning on using an FPGA in his converter (not surpisingly), 
> is the solution to have different configuration files for different machines? So the 
> setup for an Apple ][ is optimised for its aliased colour, while that for a BBC micro
> handles 80 column text a bit better

I think that the Apple ][ application needs to handle both mono 80 column and color graphics as a user-selectable and easily-toggled option, since those machines were very commonly used with both mono and color monitors. Switching configuration files should be an available option, but I think that color vs. mono selection is important enough to get a mode switch in the standard configuration. I think that configuration file changing would be better for oddball cases that are so unlike standard NTSC or PAL that supporting them in the same design would make the architecture messy.


-- 
Mark J. Blair, NF6X <nf6x at nf6x.net>
http://www.nf6x.net/