|
|
11.3.2 FX-Board
Falcon-FX Board Important note for the users of BlowUP030 or other screen enhancement software together with FX: When the Falcons own 32MHz Pixelclock is used, this only works correct, if no acceleration is activated. When the Falcon is switched to 36MHz (via the FX-CPX) this clock is also used for display output. This means that the values, BlowUP gives you for the horizontal and vertical frequencies are wrong. To calculate the correct numbers you have to multiply BlowUPs values by 1.125 (i.e. 36/32). At 40MHz you have to multiply by 1.25 (40/32). Example: You have the Falcon set to 40MHz system clock and you are using the internal pixel clock of originally 32MHz. BlowUP tells you that you have 40kHz (vert) and 76Hz (hor). In reality you have 50kHz and 96Hz. If you have a fixed frequency monitor or an older multiscan monitor you have to pay attention to this!
Picture 1 - FX-Board in Falcon F030
Positive side-effect: In 256 and 65536 colors you can achieve higher refreshrates through the faster system clock! The large number of different clock patches that can be found in the falcon, often causes uncertainties when installing the FX accelerator. For better understanding this is a rough plan of the interestingarea:
| = central source of 16MHz-CPU-clockt
R from COMBEL U56
(1) (2) R = R217
| | |
R216 R221 :
| | :
:......:.....:
:
|
R222
|
(3)
.:. means: invisible conducting connection
(1) leads to expansion slot
(2) leads to DMA-chip and to the FPU
(3) leads to the CPU
In all clock patch variations at least the resistors R216/R221 are removed and an 74F04 or 74F08 is installed instead. For that on/two wire(s) lead from R217 or the lower connections of R216/R221 to the clockpatch.
With Version 1 AND FPU installed:
Picture 2 - 4Mb Simm Modul
Annotations to using Cubase Audio. * CAF seems to be using only ST-RAM as sample memory, no matter how the program flags are set. Steinberg told us that these bahaviour, which had once a good reason, but which is forgotten meanwhile (see Douglas Adams), will be removed in the next update of Cubase Audio. If you set CAFs program flags to TT-Run and TT-Malloc, at least the program itself is being load into FX-RAM. If you move all the AUTO-folder programs and accessories into FX-RAM this will give you about 3.5MB of free ST RAM, which should be sufficient in most cases. * In very rare cases (we haven't been able to see any particular reason, and it hasen't happened lately anyway) it is possible that Cubases loses its left audio channel when operating with 50MHz DSP clock or that strange audio-problems or even crashes occur. If this happens to you, maybe you should solder the DSP clock wire to the cut end of L102: +----------------> DSP
|
O-----HHHHHH--+- --O
L102
Picture 3 - DSP with Clock from FX-Board
With that modification the DSP will always run with the system clock, i.e. 32, 36 or 40MHz. That way the DSP remains faster than the CPU (which is the main reason for DSP acceleration) but no channels are lost any more. * On our test-falcon Cubase works fine with all CPU clock settings (i.e. also with 40MHz CPU). Georg Acher/BlowUP 03.07.95/11.11.95
With some Falcons (mostly main board revision C/D) problems with the DMA system can (not necessarily) arise. This can be noticed as SCSI and sound problems. The following solution for the problem should work: - Without FPU: There is a wire from the upper connection of R221 to the clockpatch-IC 74F04 or 74F08. Remove this wire from the IC and solder it to the upper connection of R217 (same point where the yellow wire of FX is connected!) Result should be a connection between R221/upper pad to R217/lower pad. - With FPU: Here a wire leads from 74F04/74F08 directly to the DMA chip. Remove this from the 74F04/08 and connect it to the upper pad of R217 (where also the yellow wire is connected). Result should be a connection between R217/upper pad and DMA chip. Should the problems remain (especially with 40MHz CPU clock) the following change could help: - Re-establish the connection R221/upper to 74F04/08 or DMA-chip to 74F04/08. (i.e. remove the patch we just recommended :-) ) - With/without FPU: There is a wire from the LOWER connection of R221 to 74F04/08. Remove this wire from R221 and solder it to the upper connection of R217. (yellow wire) For the interested: All these modifications are changing the timing of the DMA chip's clock. This is the most crucial part of the Falcon design, so changing the Falcons timing (as accelerators do) creates problems mostly at this part... Georg Acher / BlowUP 11.08.95
Annotations to Falcon Speed:
The starting program doesn't recognize the additionally available
memory. So despite of 8MB FX-RAM only 2.4MB are useable.
Should anybody out there have the source-code of the driver ( ;-) ) itshouldn't be too difficult to change the fixed screen memory from ramtop to ST-RAM... Annotation to Linux:
Thanks to Michael Harwerth (Michael_Harwerth@hg.maus.de) there is a patch for the boot loader, so that Linux recognizes the FX RAM.
/usr/src/linux-0.9.11/tools/atari/bootstrap.c Sat Sep 9 09:45:14 1995
+++ bootstrap.c Sun Oct 15 07:30:18 1995
@@ -248,6 +248,7 @@
int load_to_stram = 0;
char *ramdisk_name, *kernel_name, *memptr;
u_long ST_ramsize, TT_ramsize, memreq;
+ u_long TT_ramstart, fx_cookie, fx_memsize;
u_long cpu_type, fpu_type, mch_type, mint;
struct exec kexec;
u_long start_mem, mem_size, rd_size, text_offset;
@@ -383,14 +384,25 @@
if (!test_medusa()) {
TT_ramsize = 0;
+ TT_ramstart = TT_RAM_BASE;
+ /* check if FX card is present */
+ if(getcookie("BPFX",&fx_cookie)!=-1)
+ {
+ /* Yep. Get its size and addresses and adjust
+ ramtop and TT_ramstart */
+ fx_cookie += 8;
+ fx_memsize = *((u_long *)fx_cookie);
+ TT_ramstart = *phystop;
+ *ramtop = TT_ramstart + fx_memsize;
+ }
if (!ignore_ttram && *ramtop) {
/* the 'ramtop' variable at 0x05a4 is not
* officially documented. We use it anyway
* because it is the only way to get the TTram size. * (It is zero if there is no TTram.)
*/
- bi.memory[i].addr = TT_RAM_BASE;
- bi.memory[i].size = (*ramtop - TT_RAM_BASE) & ~(MB - 1);
+ bi.memory[i].addr = TT_ramstart;
+ bi.memory[i].size = (*ramtop - TT_ramstart) & ~(MB - 1);
TT_ramsize = bi.memory[i].size / MB;
i++;
printf("TT-RAM: %ld Mb; ", TT_ramsize);
In newer versions of the boot loader this should already be
implemented.
Georg Acher/BlowUP 11.11.95
MiNT and the FX-RAM...
For unknown reasons MiNT only works together with FX-RAM when
memory protection (MINTNP.PRG) is OFF
Georg Acher/BlowUP 29.06.95
Hint to use the NOVA graphics card with FX:
Because of a minor design flaw (no open collector exit of the
expand signal) of the NOVA-adaptercard, the NOVA won't work together
with FX under certain circumstances (e.g. higher temperatures):
After launch of FXDRIVE.PRG the machine crashes and you can see
random pixels on the screen. We strongly recommend not to work so, as
even with seemingly undisturbed operation, most heavy errors and data
losses are likely to happen.
To remove this problem the following patch of the NOVA adapter is
necessary:
A Schottky-Diode BAT41 (or similar) has to be inserted into the
expand signal, which is marked in the following sketch:
U=Expand-connection on the lower side
O=Expand-connection on the upper side
V=Contact between upper and lower side
*=Connecting pin
--------------------------------------------------------------+
* 50pin-connector * * * * * * * * * * * * * * * * * * * * * |
|
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * |<-Pin 49
U |
U |
U |
VUUUUUUUUUUUUUUUUUUUUUUU |
O X |
..OOOOOOOOOOOOOOOOOOOOOOOOOO |
|
|
Separate the connection on the lower side (U) at the position X.
Then solder the diode BAT41 with the anode at pin 49 and the
cathode (dark ring) at V.
Then it should look that way:
--------------------------------------------------------------+
* 50pin-connector * * * * * * * * * * * * * * * * * * * * * |
|
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * |<-Pin 49
Cathode Anode /U |
__________|/|___________/U |
| |\| U |
|VUUUUUUUUU UUUUUUUUU |
O |
..OOOOOOOOOOOOOOOOOOOOOOOOOO |
|
Here the description and solution of some problems that can (but
not must) occur with FX.
Because this is a lot of text, it could be wise to print it out.
- General instability also at 16MHz
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
- Maybe the DSP doesn't like the 50MHz clock.
Solution: The clock wire that leads to the DSP has to be connected
at the right (hanging in the air) side of L102. Then the DSP gets the
system clock (32/36/40MHz).
- Maybe the main clock of 32MHz (taken out of the falcon) is a bit
Solution: Dissolder the red wire at the right pin of L102 and
connect it (with a longer wire) with the right lower connection of the
32MHz oscillator near the DSP. This is the source of the connection
which has to be separated for the DSP accelerator.
- Shorten all wires as far as possible.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
- Different setting of the 123I-buttons in the CPX.
- Since V1.1: Setting DM2 in the CPX.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
- FPU-problems:
- FPU fails already at 32/36 MHz:
- FPU fails at 40MHz system clock:
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
- IDE-Problems:
Solution (in V1.01):
Other solution:
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
- RAM/SIMM problems:
- If FXDRIVE announces no or too few memory at boot time, check
the
- If FXDRIVE announces defective SIMMs, the error message gives a
hint
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
- SCSI/DMA/Sound problems:
Solution:
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
- Heat problems and resulting instability
By a too strong rise of CPU temperature the critical phase
relation
Possible solution:
Georg Acher / BlowUP 11.11.95
The following features are not yet implemented in the current
version of FX:
- Pagemode
- Switching the DSP-accelerator from 32 to 50 MHz
- EMS (more than 10MB FX-RAM)
* Important:
* Should you have problems with your IDE hard disk at 36/40MHz CPU
* Such an accelerator is a quite critical thing, even more so if
it is
Should you have such a Falcon tell us the board revision and
serial number
* Although the FX-RAM is installed as 'Alternate-RAM' into TOS,
there is
* The whole FX-hardware is being defined through the contents of
Georg Acher/BlowUP 05.07.95
Optional hardware change to increase CPU write access speed:
This change was invented in the last minute, therefore is not
included
A 15cm wire has to be soldered from a pin of the FX controller
chip to a pin of U63.
To find the soldering spot on the FX card, here a small drawing.
The right pin is marked with a 'o' and a '^' below.
FX-card from below:
| | | | | acelleration plug
| | | | |
+-------------------------------------------+
| |
| #### |
| #### |
| . . . . . . . . . . . #### |
| . . . . . . . . . . . . . #### |
| . . . . #### |
| . . . . #### |
| . . Socket pins . . #### |
| . . . . #### |
| . . . . #### |
| . . . . #### |
| . . . . #### |
| . . . . #### |
| . . . . #### |
| . . . . . . . . . . . . . #### |
| . . . o . . . . . . . #### |
| ^ M #### |
| M MM #### |
| MMMMMMMMMMMMMMMMMMMMMMM #### |
| MMMMMMMMMMMMMMMMMMMM |
ground-connection
The wire is lead from the marked FX pin to pin 19 of
U63.
1
| 9 | | | | | | | | |
---------------------------------
| |
] U63 |
| |
---------------------------------
| | | | | | | | | | |
Short explanation:
The Falcon logic in U63/U68 speeds down the 68030-accesses to
68000 speed, i.e. one bus cycle always lasts four clock cycles.
Through our wire this logic is circumvented and the 68030 being told,
that it can end the bus cycle. That way an FX access can last only 3
clock cycles. That (at the moment) only happens at write accesses,
because (depending on RAM type) during read accesses correct data
could not be present at the data bus and the 68030 gets invalid data.
Attention:
Georg Acher / BlowUP 20.11.95
Description of the enclosed utilities (if not already in the
manual)
SETSPEED.TTP
TOS program for shells, as FXCPX, only commandline orientated.
Sets the acellerator:
Call:
setspeed [-h] [-CPUSPEED] [-t] [-FLAGS] [-DFLAGS]
no arguments: ouput the CPU-Speed
CPUSPEED: 16, 18, 20, 32, 36, 40
-t: Takes over default values from the .FXB-file but not from the
FXCPX (i.e. not the values you saved from the CPX).
Without -t you have to give the 123/DM1/DM2 settings.
FLAGS: [1][2][3][I]
DFLAGS: D1 D2 D12
E.g.: setspeed -40 -12I -D2
setspeed -36 -t (takes default values).
setspeed -20
Hints + Tips about the FX-Board: Georg Archer
(c) BlowUP - München.
Copyright © Robert Schaffner (support@doitarchive.de) Letzte Aktualisierung am 23. Dezember 2003 |
|
|
