> On May 23, 2015, at 10:28, Steven Hirsch <snhir...@gmail.com> wrote:
> 
> On Sat, 23 May 2015, Chris Osborn wrote:
> 
>> 
>> On May 23, 2015, at 8:24 AM, Mark J. Blair <n...@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 <a...@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 <jk...@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 <a...@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 <n...@nf6x.net>
http://www.nf6x.net/

Reply via email to