Why the unusual frequency?

[MarkS]

I am working on a project with my Plus. The analog board is dead and while I do plan to fix it, I want to play around with a microcontroller. Anyway, One thing I'll need the microcontroller to do is read the video signal and convert the data to a VGA signal. I'm going to be using the Parallax Propeller microcontroller and it can generate a VGA signal natively. However, while doing research, I found that the video signal is 15.6672 MHz (the frequency of the oscillator). While the propeller runs at 80 MHz, sampling an odd frequency will be difficult, if not impossible. I can change the oscillator to 16 MHz rather easily, but I'm curious why Apple chose such an odd frequency in the first place. I know I've read the reason in the past, but I don't remember where and I don't remember why. If I were to swap out the oscillator, would it potentially damage the Mac? I doubt the .1664 MHz jump would hurt anything, but I want to make sure first.

While on the subject, I can get a 10MHz 68000. It might be interesting to upgrade the processor and the oscillator to 10 MHz...

 

[porter]

If I were to swap out the oscillator, would it potentially damage the Mac? I doubt the .1664 MHz jump would hurt anything, but I want to make sure first.

Serial comms, disk controller, localtalk all derive from the same clock as far as I know.

So if you don't want the Mac Plus to reliably read and write floppies....

 

[MarkS]

Everything derives from the same clock. The frequency from the oscillator is divided in half for the processor and further for other IC's. The full clock speed is fed to the video generator. I would imagine that everything would scale to the newer clock.

What was the reason behind the odd clock speed?

 

[Osgeld]

15.6+- khz is the time it takes to produce a single line on a NTSC tv, so the apple screen is probably really running at or near ntsc tv specs

Also it was very common in the 80's to use parts from tv's and radios, since they were the most common and most produced electronics at that time (the apple II uses a NTSC color burst crystal 3.58mhz)

 

[porter]

What was the reason behind the odd clock speed?

It divides evenly (ie by integer) to generate baud rates. But I imagine the pixel clock was an important reason, eg given the horizontal scan time, how many pixels you want to show etc.

 

[tomlee59]

15.6+- khz is the time it takes to produce a single line on a NTSC tv, so the apple screen is probably really running at or near ntsc tv specs
Also it was very common in the 80's to use parts from tv's and radios, since they were the most common and most produced electronics at that time (the apple II uses a NTSC color burst crystal 3.58mhz)

The master clock is 15.x MHz, which is not the same as the horizontal line rate (kHz). The latter works out to something like 22.x kHz in the monochrome compacts. The ~50% higher line frequency makes interfacing to an NTSC device very difficult.

The Plus does not use any frequency related to the NTSC subcarrier frequency. The clock frequency is a consequence of several compromises among screen resolution, CPU speed, and the need to support a standard set of baud rates.

 

[H3NRY]

Everything in a Plus runs off a single crystal which was chosen for compatibility with the SCC chip and standard baud rates. If you change the crystal, the Mac may beep and start, but everything (disk, serial ports, video, sound) will be off. Video, sound, and disk speed are DMA interleaved with the CPU, so all have to mesh. Horizontal sweep is 22.25KHz, much higher than NTSC video at 15.75KHz, which is one reason flyback transformers run hot. Frame rate is very high to avoid flicker and eye fatigue (Has to pass Andy Hertzfeld's potato chip test, where you stand across the room and eat a chip and see whether the screen flickers noticeably). Wikipedia has a good description of the Mac circuitry.

The Apple II uses a 14.31818MHz crystal (4x color burst) which gives it the ability to generate pseudo-color video on a TV.

 

[porter]

The Apple II uses a 14.31818MHz crystal (4x color burst) which gives it the ability to generate pseudo-color video on a TV.

And so did the original IBM PC, it divided the clock by three ( with a two to one mark to space ratio ) to give the familiar 4.77Mhz.

 

[Bunsen]

Interesting project MarkS. By coincidence, I've been reading the following similar projects in the last 24hrs:

Prop-6502 laptop

pPropQL020 and pPropQL

I think the "16MHz" quoted for the Plus is probably nominal (ie near enough) and is actually 15.6672MHz.

Have you considered taking your clock straight from the Mac's onboard oscillator? That way you know the two systems are in lockstep.

Is there some way of locking two separate oscillators together? Say, the Mac's at 15.6672 and yours at 62.668 (4x), if such an osc is available. Or dividing yours down by 4 and driving the Mac's osc socket from that signal?

If you can't find an exact match, you could try this adjustable osc:

LTC6903 1kHz-68MHz Serial Port Programmable Oscillator

 

[Gorgonops]

I think the "16MHz" quoted for the Plus is probably nominal (ie near enough) and is actually 15.6672MHz.Have you considered taking your clock straight from the Mac's onboard oscillator? That way you know the two systems are in lockstep.(...)

The specs for the Propeller microcontroller say "External Clock Speed: DC to 80 MHz ". That sort of implies you could lock onto an external oscillator. (The specs also say there's an on-chip PLL which can multiply the external clock by 1-16x, although enabling it limits maximum input clock to 8Mhz... although that may not be a problem. It sort of looks like the "standard" config for Propeller demo boards is a 5Mhz input clock. That times the 16x PLL multiplier results in the quoted "80Mhz" speed.)

According to this page, the 15.6672 MHz clock is the Mac Plus' pixel clock, which means that the RAM in the Mac needs to supply one monochrome pixel every .064 microseconds. Assuming you're working with 8 bit bytes that means something generating a screen like the Mac Plus is going to need to run at a little less then 2Mhz, as long as you have a shift register doing the pixels. So... my ignorant suggestion would be to tap the 7.8336 Mhz clock being supplied to the Mac Plus CPU and set your multiplier PLL to 8x, giving you a core speed of almost 64Mhz and thus lots of CPU time to play with the incoming monochrome bits. The only thing you'll need clocked at 15.6672 Mhz is the 8 bit serial-in/parallel-out shift register you'll read every four external clock cycles. (Fairchild MM74HC164, maybe?)

The thing that sort of worries me is that a standard Propeller has 32K of "hub ram" and a 512x342x1 display will take up about 22K of it, which rules out "double buffering" the input and the output. (IE, you're going to need a cog filling up that buffer at the Mac's input speed at the same time you have a cog(s) reading it and making a VGA display out of it. Maybe you could offset things by half a screen width or something to keep them from running into each other.) Timing is also going to be a problem because your clock speed is going to be "unusual", thus any sample VGA code you might borrow from is going to have to be adjusted. (This may not be a huge deal if you're driving a nice forgiving multiscan monitor, but it's something to keep in mind.)

Of course, I'm an idiot when it comes to electronics so take all these suggestions with a Borg Cube's worth of salt.

 

[MarkS]

I think the "16MHz" quoted for the Plus is probably nominal (ie near enough) and is actually 15.6672MHz

Oscillators with a 7.8336 frequency and its multiples are extremely hard to find. I found a 31.3344 MHz oscillator and will run the Prop off of that. I'l use the Prop's built-in PLL to double this frequency to 62.6688. The software written for the Prop is typically designed to work at or near 80 MHz. There is plenty of example code (called Objects) in the Propeller Object Library that will greatly simplify the coding of this. Not that the coding would be all that hard anyway. I'm also adding a USB keyboard to Mac keyboard converter as well as a USB mouse to Mac mouse converter. Each of those converters will have their own core.

 

[Gorgonops]

As noted, why not just tap the frequency straight off the motherboard? It's right there. But whatever works for you.

(And also, just have to ask... the specs for the propeller say "Clock Modes: (a) External crystal 4 -8 MHz (16 x PLL) ( B) Internal oscillator ~12 MHz or ~20 kHz © Direct drive". I assume you're going to be dividing down that 31.3344 Mhz input frequency if you're planning on using the PLL?)

 

[MarkS]

Sorry, I was writing my post while you made your post. Taking the signal off the board is an option, but then the two boards are physically locked together. I really don't want to do this if I can avoid it. The video processing on the Prop will be in software. I'll read read the H Sync, V Sync and video signal with three of the Prop's I/O pins. The actually processing will be going on inside the Prop. Essentially what I'll be doing is turning the Prop into an oscilloscope. The software will be reading the video input pins at a higher frequency than the Mac provides and acting appropriately when the video signals change from low to high or high to low. Basically, the video will be interpreted. A bitmap will be generated from the video signal and displayed with some simple VGA circuitry.

You are correct about the hub RAM, but that is a minor issue. It is trivial to add extra external RAM if needed. Also, the Prop has a 32K code limit and the code is stored on an external EEPROM. It is very common to use 64K or larger EEPROM's for the purpose of adding extra memory.

I was unaware that the PLL only works with frequencies under 8MHz. Thanks for the tip. This is trivial. I'll just use a shift register to divide the clock down to 7.8336 MHz to drive the Prop and use the 8x PLL.

 

[Gorgonops]

Heh. While doing a quick Google I happened to run into your thread on the Parallax.com forum, and it looks the last answer in that forum is basically what I was suggesting, other than referencing code that supposedly should be able to do the sampling without an external shift register.

If you were to follow that person's suggestion and make this a simple "scan doubler" (IE, essentially stretch the 512x342 display to 512x684 with a 44.5-ish khz horizontal scan rate) then I suppose it's worth pointing out that you don't even need to digitize the whole display. Two lines should be enough, since input and output will be operating in lockstep. (You'd read one line from the input, and then while reading the next line the output cog would display the previous line twice in the same amount of time.) Hypothetically this reduces your hub-RAM requirement to a whopping 128 bytes. (Or maybe a bit more, since you could simply scan the "front and back porches" as black pixels and use the Hsync pulse as an "end of line" signal. The longer Vsync pulse could be used to sync the the frames.) A scan-doubled display like that should work fine on a multisync CRT monitor and might be dead easy to program, but a VGA LCD monitor's scan converter might not like it. If you plan to convert to a more "standard" field/scan rate then you probably do need to grab the whole frame, or at least a good chunk of it, and distinguish the blanking intervals from the actual signal.

Out of curiosity, did you ever make any progress on your thread about using an FPGA and an LCD display?

 

[MarkS]

I'm probably going to have to grab the whole frame. The scan doubling sounds interesting, but it will be displayed on an LCD monitor. What I think I'm going to do is make the bitmap 1024x768, double the video input and center it vertically in the bitmap. This shouldn't be too hard and I'll need to add extra memory anyway, so that's not an issue. I'll just plot two pixels instead of one and plot two scanlines at a time. This will double the resolution which will be necessary anyway (512x342 is tiny on a large monitor) and make the bitmap a resolution that is more or less standard. Compatibility with different types of monitors is key here. I want to be able to plug in any type of contemporary VGA monitor and have this work. The best way to guarantee this is by displaying a bitmap. This, of course, comes with a speed and memory penalty, but it's not that bad. The amount of memory I'll need is cheap and even if I can only get 30 FPS, it is still more than fast enough.

Out of curiosity, did you ever make any progress on your thread about using an FPGA and an LCD display?

No, after doing quite a bit of research, it looked like I was getting in way over my head and I dropped the project. I'd like to play around with an FPGA at some point, but this isn't the project to learn FPGA programming. This project is the FPGA project simplified.

 

[Gorgonops]

Just again out of curiosity, what other projects have you done with a propeller? It doesn't look like it's actually *that* trivial to add high-speed external RAM to one. (Unless I'm misunderstanding the documentation/forum discussions on the matter it looks like you can dedicate I/O pins to bit-banging an external parallel RAM chip or bus but the Prop I doesn't natively support "memory operations" or DMA to such a setup. The source code for the 6502 laptop is *very* interesting reading...) Most (all) of the "high-res" video drivers I've seen referenced are tile based and the 32K internal RAM seems to be a fairly hard limit. Has anyone actually implemented a bigger-than-32K linear framebuffer driver before?

Unless you're supremely confident in your design and done video work before I'd probably aiming for the simple scandoubler as an "alpha" design and working upward from there, since it sounds like everything you need for the most part is already present inside the propeller. (It may well work fine on most newer LCDs anyway. I've had trouble before with elderly LCD monitors not working with "oddball-by-PC-standards" scan rates produced by Sun Workstations and whatnot, but newer monitors seem to have more flexible scalers and will manage to produce a usable image out of most any input.)

But, hey, if you're a Propeller God go for the gold.

 

[MarkS]

Propeller God? :lol: No. I've done one project with the Prop, a temperature controller for a reptile enclosure. It used a 4x20 character LCD and I had to write the driver for that. What surprised me was how easy everything was. It helps that Parallax has excellent documentation and a busy support forum. I'm looking at this as a challenge. Heck, if I wanted to go the easy route, I'd just fix the analog board. I expect to hit some walls, but that's no problem. This will be fun.

 

[H3NRY]

In 1985 Steve Beck wanted to be able to project a Mac's video with a standard TV projector. I built up a bunch of dual ported VRAM (parallel I/O and built-in shift register) with a state machine (PALs) to take Mac video and deserialize it, stuff it into the frame buffer RAM, and then read it out at 14.318174 MHz Apple II style as NTSC color composite. This had the side benefit of making MacPaint patterns into colors. Phat Ho reworked the circuit to add features and put some functions into software on a 6502. Beck-Tech sold a few of them as "Chromatrons". It would be a real rarity to find one of them - I doubt there were more than a dozen built.

 

[MarkS]

I hate to bring this back up, but I have a couple of questions I hope can be answered.

Since the frequency is related to baud rates and the serial ports are really all but useless now (at least for me anyway), what other effects would I see by bumping up the frequency? My biggest concern is screwing up the RTC. Would bumping it up to 8 MHz cause any sort of stability issues?