The clock frequencies listed are directly from the AD724 datasheet. I'm not sure why the other systems were different.
Anyone?
Daryl
SBC-3. Current status
You're right, the AD724 does seem to need a higher frequency for encoding PAL than NTSC, this seems to ge back to the AD722 as well. I did some digging, and it seems to be the color subcarrier frequency to use when encoding color by phase shift. Apparenly the NTSC uses 3579545Hz, while PAL uses 4433619Hz (I'd *really* like to know where they got those numbers from...). The thing is, the datasheet I found online (at http://www.analog.com/static/imported-f ... /AD724.pdf) mentions a slightly different frequency than you have for PAL (this is for pin 3, Fin, right?):
I think that what probably happened is that you wrote the "17" from the high freq, got distracted by something and then wrote the "43" from the low freq, so you ended up with 17.43 instead of 17.73.
Edit: OK, now I know where the difference between PAL and NTSC C64s and PAL and NTSC SBC3s lies. C64s derived their frequency from the time the electron beam from a CRT takes to scan a single scanline (AKA the CRT's horizontal frequency). For PAL, that is 15.625 KHz while for NTSC it's 15.734 KHz. That's why PAL C64s and Amigas were a tiny bit slower than NTSC ones. SBC3 on the other hand derives its system clock from the color subcarrier frequency, which is as above. However, this brings up a question: won't the composite sync pulses be at the wrong frequency for PAL?
Quote:
FSC clock or parallel-resonant crystal, or 4FSC clock input.
For NTSC: 3.579 545MHz or 14.318 180 MHz.
For PAL: 4.433 619 MHz or 17.734 480 MHz.
CMOS/TTL Logic Levels for subcarrier clocks.
For NTSC: 3.579 545MHz or 14.318 180 MHz.
For PAL: 4.433 619 MHz or 17.734 480 MHz.
CMOS/TTL Logic Levels for subcarrier clocks.
Edit: OK, now I know where the difference between PAL and NTSC C64s and PAL and NTSC SBC3s lies. C64s derived their frequency from the time the electron beam from a CRT takes to scan a single scanline (AKA the CRT's horizontal frequency). For PAL, that is 15.625 KHz while for NTSC it's 15.734 KHz. That's why PAL C64s and Amigas were a tiny bit slower than NTSC ones. SBC3 on the other hand derives its system clock from the color subcarrier frequency, which is as above. However, this brings up a question: won't the composite sync pulses be at the wrong frequency for PAL?
faybs wrote:
...The thing is, the datasheet I found online (at http://www.analog.com/static/imported-f ... /AD724.pdf) mentions a slightly different frequency than you have for PAL (this is for pin 3, Fin, right? ...
FSC clock or parallel-resonant crystal, or 4FSC clock input.
For NTSC: 3.579 545MHz or 14.318 180 MHz.
For PAL: 4.433 619 MHz or 17.734 480 MHz.
CMOS/TTL Logic Levels for subcarrier clocks.
FSC clock or parallel-resonant crystal, or 4FSC clock input.
For NTSC: 3.579 545MHz or 14.318 180 MHz.
For PAL: 4.433 619 MHz or 17.734 480 MHz.
CMOS/TTL Logic Levels for subcarrier clocks.
Daryl
8BIT wrote:
No, because I have two versions of firmware: one for NTSC and one for PAL. The system will not be able to switch between the two without changing the XC95108 firmware. There are not enough resources to load both sets of counters or an extra pin to act as the standard select pin.
Daryl
Daryl
As of 9-23-08:
The schematic is done.
The PCB is done (pending ATM8 testing).
The XC95108 is done.
The XC9572 is done.
The ATmega8 code is written but untested.
The OS is 80% done (waiting on the ATM8 code tests)
- Terminal I/O and RS-232 xmodem code will be finalized after ATM8 code testing is completed
The documentation will never be done (always more info to add)
Kit contents and costs have not been finalized.
Targeted completion: 10-5-2008
The schematic is done.
The PCB is done (pending ATM8 testing).
The XC95108 is done.
The XC9572 is done.
The ATmega8 code is written but untested.
The OS is 80% done (waiting on the ATM8 code tests)
- Terminal I/O and RS-232 xmodem code will be finalized after ATM8 code testing is completed
The documentation will never be done (always more info to add)
Kit contents and costs have not been finalized.
Targeted completion: 10-5-2008
I had to go back and add a crystal for the PAL version as there does not seem to be a 17.734 MHz TTL OSC out there. The PAL version will use a crystal for the AD724 and a 16 MHz TTL OSC for the system clock.
The ATM8 code is giving me trouble, but I think I've made progress.
As of 10-2-08:
The schematic was revised and is done.
The PCB was revised and is done (pending ATM8 testing).
The XC95108 is done (new PAL timing needs to be checked).
The XC9572 is done.
The ATmega8 code is being debugged.
The OS is 80% done (waiting on the ATM8 code completion)
- Terminal I/O and RS-232 xmodem code will be finalized after ATM8 code testing is completed
The documentation will never be done (always more info to add)
Kit contents and costs have not been finalized. I've requested info from those interested in the board... I'm still waiting for all to reply.
Also having some difficulty with our son's school and I've not been able to get as much free time as I had planned.
Targeted completion: 10-15-2008
The ATM8 code is giving me trouble, but I think I've made progress.
As of 10-2-08:
The schematic was revised and is done.
The PCB was revised and is done (pending ATM8 testing).
The XC95108 is done (new PAL timing needs to be checked).
The XC9572 is done.
The ATmega8 code is being debugged.
The OS is 80% done (waiting on the ATM8 code completion)
- Terminal I/O and RS-232 xmodem code will be finalized after ATM8 code testing is completed
The documentation will never be done (always more info to add)
Kit contents and costs have not been finalized. I've requested info from those interested in the board... I'm still waiting for all to reply.
Also having some difficulty with our son's school and I've not been able to get as much free time as I had planned.
Targeted completion: 10-15-2008
@8BIT
Sorry if this is a dumb suggestion, but wouldn't it be simpler if both the PAL and NTSC versions had the exact same schematic (with just the AD724 crystal being different), instead of the PAL version having an extra TTL clock gen?
Also, since you're changing stuff anyway
Any chance you could have the ATMega also get mouse input and use one of those over-and-under dual PS/2 sockets (eg http://shop.vetcosurplus.com/catalog/pr ... ts_id=6608)?
Sorry if this is a dumb suggestion, but wouldn't it be simpler if both the PAL and NTSC versions had the exact same schematic (with just the AD724 crystal being different), instead of the PAL version having an extra TTL clock gen?
Also, since you're changing stuff anyway
Any chance you could have the ATMega also get mouse input and use one of those over-and-under dual PS/2 sockets (eg http://shop.vetcosurplus.com/catalog/pr ... ts_id=6608)?faybs wrote:
@8BIT
Sorry if this is a dumb suggestion, but wouldn't it be simpler if both the PAL and NTSC versions had the exact same schematic (with just the AD724 crystal being different), instead of the PAL version having an extra TTL clock gen?
Sorry if this is a dumb suggestion, but wouldn't it be simpler if both the PAL and NTSC versions had the exact same schematic (with just the AD724 crystal being different), instead of the PAL version having an extra TTL clock gen?
So, the answer is yes, I could remove the ttl oscillator and design a crystal-based clock to provide a single clock to both AD724 and XC95108. However, at this point, will probably stick to current layout.
NTSC users will just use the ttl oscillator and leave the crystal and cap pads open. PAL users will use all three parts.
Quote:
Also, since you're changing stuff anyway Any chance you could have the ATMega also get mouse input and use one of those over-and-under dual PS/2 sockets (eg http://shop.vetcosurplus.com/catalog/pr ... ts_id=6608)?
Any chance you could have the ATMega also get mouse input and use one of those over-and-under dual PS/2 sockets (eg http://shop.vetcosurplus.com/catalog/pr ... ts_id=6608)?The board real estate is very tight. For now, I do have a few unused ports on the ATM8 extended to pads that could be used for future devices. Users could modify the ATM8 firmware to serve these devices.
I need to get the ATM8 running reliably before I look at adding any more to it.
Daryl
8BIT wrote:
It crossed my mind... however, clock design is not my strongest subject, and I like the fact that the ttl oscillators take care of all the issues for you. I also was thinking of the problems Kc5tja had with the 65816 clock made me want to avoid using a crystal.
So, the answer is yes, I could remove the ttl oscillator and design a crystal-based clock to provide a single clock to both AD724 and XC95108. However, at this point, will probably stick to current layout.
So, the answer is yes, I could remove the ttl oscillator and design a crystal-based clock to provide a single clock to both AD724 and XC95108. However, at this point, will probably stick to current layout.
faybs wrote:
Apparenly the NTSC uses 3579545Hz, while PAL uses 4433619Hz (I'd *really* like to know where they got those numbers from...).
The compromise was, at the time, to display two luma pixels per chroma pixel across a single scanline (this is why you get color artifacting on otherwise monochrome screens with early home computers. The Apple II computers exploited this tendency to fake a "color" screen using a high-resolution monochrome display! With creative use of color selection on the Commodore 64, one can synthesize colors not in the VIC-II's palette when operating in bitmapped mode or with sprites. This is why some games look better on older monitors than on newer, higher-bandwidth devices).
It happened that 455 luma dots were displayed per scanline. Thus, divided by two, we have 227.5 color dots. Multiply 227.5 color pixels per line by 15750 lines per second, and you come out more or less pretty close to 3579545Hz.
But, why constrained to 15750 lines per second? Because the TV rendered 525 scanlines, 30 times per second, or, 262.5 scanlines at 60fps. 262.5 * 60 = 15750 Hz. And with the frame rate tied to power-line frequency, it also means that relatively poorly engineered power supplies which put out a hot of hum in the supply rails won't cause picture distortion.
Actually, the values for color television are slightly off from their monochrome equivalents. This appears to be due to the strong desire to drive everything off of a single 5MHz crystal oscillator (see http://www.burnworld.com/dvd/primer/ntsc.htm), thus taking everything off of the power-line standard timebase. However, with the vast multitudes of monochrome TVs in existance, the closest fit to 15750Hz proved compulsory. 15734Hz was within monochrome's tolerances, and proved easily synthesizable. 227.5 color pixels times 15734Hz yields our now famous 3579545Hz color burst frequency.
The rest, as they say, is history.
8BIT wrote:
I'll post the updated board layout and schematic to my site this weekend
I have a question... I think that JP4 is a great idea, it can be used to implement interrupt controlled serial and PS/2 IO. However, if both JP3 and JP4 are closed, and VIA2 asserts its irq line (IRQ2) but the ATMega doesn't (or vice versa), won't that cause current to flow between VIA2 and the ATMega? I think that your reasoning was to let people decide if they want VIA2 interrupts or ATMega interrupts, but that's a sucky decision to have to make. If you'd rather not use a current limiting resistor to prevent signal distortion, I would like to humbly suggest an alternative: use a three-way jumper block, that connects VIA2's CB2 input to either J7 or the ATMega. You seem to have been leaning that way anyway with the addition of P16. If you do that, then you can also get rid of JP3, since it won't be needed any more.
I had included JP3 & JP4 to be used exclusive of one another. However, I like your idea of a 3 pin jumper. I spent a few minutes looking over the board and think it would be easier to use VIA1's CB2 as there's not room to add the needed traces near VIA2.
I'll leave P16 at VIA2's CB2 for future expansion or user choice.
Addition: I was able to remove JP3 & 4 and replace with a 3-pin JP3 to allow VIA1's CB2 to be sent to either J5 pin 12 or the ATM8's pin 28.
Pad P16 was left also.
Daryl
I'll leave P16 at VIA2's CB2 for future expansion or user choice.
Addition: I was able to remove JP3 & 4 and replace with a 3-pin JP3 to allow VIA1's CB2 to be sent to either J5 pin 12 or the ATM8's pin 28.
Pad P16 was left also.
Daryl