FirefoxNotes

From DaphneWiki

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)."

"Here's a link to a set of Firefox schematics I was referring to [he links to the DLP schematics, 2nd printing]... keep in mind that some used two Audio Reg IIs ... these schematics show the Atari switching power supply (yuck) as the power supply being used.

Pages two and three show the wiring diagram (kind of stinks having the schematic split, but we'll have to deal with it). Along the top of page two, to the right, you'll see the 5V ... that's the output of the power supply.

Now jump to pages 8 and 9. These are the regulators on board the Firefox boardset. There are linear regulators on the main PCB ... the +15V and -31V being dropped down to +12V, +5VR (not to be confused with the 5V that powers all the digital stuff), -5V, and a 2.5V reference. They use linear regulators to do this (i.e. the 7812, 7805, and 7905). The 2.5V is created using a resistor divider.

If you look to the right, you'll see pins 2, B, 21, and Y on the edge connector. Those are the 5V inputs from the power supply that drive the main logic PCB.

You'll see on the graphics PCB that it expects a 5V input too. Don't worry about the "SENSE" signal for now ... that's simply a feedback signal to the power supply that allows the power supply to boost itself if there is a voltage drop (and this is also part of the reason why high current games have charred edge connectors smile emoticon ... as a trace begins to heat up, it becomes a resistor of sorts ... the resistor causes a voltage drop, the sense signal boosts the voltage, etc, if something is *really* wrong, this can run away and burn stuff up ... there's a far better description of this effect elsewhere on the internet smile emoticon ).

Now I see where we both might be butting heads Matthew smile emoticon ... the NTSC demodulator board does regulate one of its 10V on board supplies down to 5V (see pages 44 and 45). They call this node "+5V source" it is the output of a 7805 regulator. This regulator can only supply 5V @ 1A. I think they use this in the NTSC demodulation to keep it isolated from the 'digital' 5V used on the logic and graphics PCBs.

So, overall, you *have* to have an external 5V supply to power up the complete Firefox boardset. That's what I did.

If you are powering JUST the NTSC demodulator (much like what's being done in this thread), you do not need the 5V supply as that is generated onboard from the 15V supply smile emoticon.

Make sense? smile emoticon

Now go get to work on more stuff for Dexter tongue emoticon smile emoticon! Ed Beeler really wants to see Starrider support so that he can reliably run it in his arcade smile emoticon. Starrider only seems to work depending on the phase of the moon and the number of steps taken to it before sitting on it (I've played it a couple of times ... slick game when its working)."

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

Personal tools