FirefoxNotes

From DaphneWiki

Revision as of 21:24, 1 June 2016 by Matt (Talk | contribs)
Jump to: navigation, search

Contents

Firefox

Schematics

The schematics designate pull-ups with a P'RXXX type designation.

For example, on schematics sheet 9B, the monitor sync section shows 11B. Here is how it looks on the actual PCB.

Ffx 11b.jpg

Monitor

Output

Schematics show two outputs, one for a monitor supporting separate positive H and V syncs (J205B), and one for a monitor with a single negative composite sync (J205A). The pin assignments for J205B are:

Pin Firefox Schematic Description
1 H H sync
2 J V sync
3 F Monitor ground (aka "VID RTN")
4 E Blue
5 C Green
6 D Red

NOTE : that this is the same pins as on a G07 monitor except the pin numbering is reversed (ie on the G07, pin 1 is red).

If you use composite sync, and it doesn't appear to sync properly, then make sure R240 (1k ohm) is installed on the Demodulator PCB. (from DLP archives)

Voltage Levels

Sync comes from a TTL chip (74LS04, U6 on the board).

R,G, and B values are around 0-5V. Using a real scope, the VPP for the "blue" wire was about 4.64V (just a random part of the attract mode).

In the following image, yellow is vsync (positive) and blue is the blue wire from the RGB output.

FFX VsyncandBlue.png

Sync signals

Sniffed from real hardware.

Distance between start of vsync was measured at 16.683, so it seems correct. Width of vsync pulse is measured to be 158-159uS (scope and logic analyzer as sources).

Ffx-sync-signals.png

Sync problems

From http://www.dragons-lair-project.com/community/forums/archives/default.asp?Action=View&MessageID=30314

Check/replace U6 (74LS04) on the Demodulator PCB.

Slow speech problems

(from http://www.dragons-lair-project.com/community/forums/archives/default.asp?Action=View&MessageID=40435&Archive=Yes&Keywords=firefox|sync )

> The PCB generated speech is very slow, like Jim Carrey doing his Slo-Mo act..

Make sure R101 is set correctly on the Demodulator PCB. Refer to the manual for setting the PLL Lock signal (I think the manual covers it). Use a frequency counter and make sure you measure stable 3.58MHz at TP22 and 14.318MHz on R230 (either end of it).

If you correct the sync problem and the speech is still slow then the cause is likely further down the circuit where the 14.318MHz is divided to 7.12MHz (on the Graphics PCB) before then going to the Main PCB.

Check the frequency on pin 2 of 3M (74LS163) on the Main PCB. You should measure 7.12MHz of at least 3Vpp. If not then follow the signal back to the GFX PCB then the Demodulator PCB (make sure the PLL is set correctly before doing anything).

If there is 7.12MHz on pin 2 of 3M then check the inverter/driver between pin 12 of 3M and the TMS5220 (pin 6 of 3H).

Laserdisc Interface

Data lines

All of the data lines have 220 ohm pull-ups and 330 ohm pull down resistors on them (on the firefox main PCB).

Reading from VP931

RDDSK' is tied to RDEN' via an LS244.

Reads are handled by an LS244 which becomes active when DREAD' goes low (and feeds into the DBA0-DBA7 data lines). DREAD' is the clock (pin 11) input for an LS74 (7H on the schematic). Clear' (pin 13) is held permanently high by a pull-up. Set' (pin 10) is tied to DSKREAD'. Q' (pin 8) is tied to RDDSK'.

DSKREAD' is 0x4218-1F (set up for disk read, write strobe for set up) DREAD' is 0x4105 (read status data from disc)

The process to read (from the ROM's perspective is):

  1. Write anything to DSKREAD' which causes RDDSK'/RDEN' to go low. (no read actually occurs at this point)
  2. Read from DREAD' which causes the LS244 to become active and send the VP931's data lines through to DBA0-DBA7. CPU will begin reading the bus while DREAD' is active, which is somewhere in the middle of the RDEN' pulse.
  3. Once the CPU's address lines change (by transitioning to the next CPU instruction), DREAD' will go high which will trigger the clock of the LS74 (7H, pin 11), which causes RDEN' to go high because the input to the flip flop is ground. The bus data needs to stay readable for 10ns after the CPU address changes (according to 6809E datasheet).

Writing to VP931

WRDSK' is tied to WREN' via an LS244.

Data is loaded (from DBB0-DBB7) into an LS374 via DSKLATCH'. It is then output via WRDSK' (which is tied to WREN'). Presumably, this means that WREN' may go low slightly before the data is valid (and being written to the bus) and may go high slightly before the data is invalid.

ROM/RAM diagnostic test

The ROM/RAM test will hold WREN' low which is of interest for Dexter development.

The "yoke" controller

According to switch test, the range for turning the controller left and right is 01 to FF. Rotated all the way to the left is 0.09V, all the way to the right is 4.99V (measured on real hardware). Tilting the handle forward and back has a range of 06 to FA. All the way forward is 0.15V, all the way back is 4.85V (measured on real hardware).

Power Supply

"Please, I beg you, having resurrected two Firefoxes from the dead over the years, PLEASE put a decent grade computer switching power supply in that!!! smile emoticon. By all means, repair and bulletproof your original supply for historical purposes ... however, Firefox, kind of like Pole Position, draws quite a bit of current from the 5V rail"

"OK ... I remember what I did now smile emoticon. Please understand that this was over 10 years ago smile emoticon.

I seemed to remember a few "exotic" voltages like 31V on the NTSC demodulator board when you asked about the 12V ... I only used the external switching supply for 5V. That's the heaviest load ... and that's what's most likely to die. The rest of the voltages draw very little current from the supply.

Just patch in a switching power supply with 5V to the 5V rail in the game and disconnect the 5Vs on your current supply. Make sure you tie the ground on the switching power supply to the ground on the power supply in your game.

The two I worked on were set up to use two ARIIs instead of that big ass switching power supply (my I, Robot had one of those ... they're horrible when they fail ... don't use them). I think those Atari switchers have pins for the output voltages vs. a molex style connector. If that's the case, you'll have to get a connector that plugs into that header and make an adaptor that way.

Another good "trick" is to use clips and clip additional 5V supplies to the test points on the PCB. The edge connector can and will get quite toasty since there isn't enough copper given the amount of current on that voltage rail. The additional connections help alleviate that congestion point. That should be done for any Atari game that draws a ton of current on the 5V rail (Pole Position, IRobot ... I'm sure there are others that I'm forgetting)."

From https://www.facebook.com/groups/1677337495815647/permalink/1756337031249026/?comment_id=1756362727913123&comment_tracking=%7B%22tn%22%3A%22R%22%7D

Personal tools