[hatari-devel] DSP - CPU synchro : EkoSystem, LostBlubb and Watership (and probably some other)
laurent.sallafranque at arkea.com
Thu Jan 20 13:53:26 CET 2011
I've spent some time yesterday to try to understand better the problem.
I think the problem is related to the timers used.
1) The DSP and the 68030 emulation are not the problem.
The Demos run perfectly from the beginning to the end at 32 Mhz.
All processors' instructions are correctly emulated (both with old and new UAE core for the 68030 and DSP).
2) The DSP can execute instructions from 3 inputs :
- DSP_RUN which is synchronized by the 68030
- DSP Host interface (via the Host interrupt and the host transmit/receive) connected to the 68030
- DSP SSI interface (connected to the crossbar)
DSP_Run works for a certain amount of cycles.
If 68030 runs at 8 Mhz, NOP = 4 cycles, and DSP executes 4*2 DSP cycles instructions
If 68030 runs at 16 Mhz, NOP = 4 cycles, and DSP executes 4*2 DSP cycles instructions
If 68030 runs at 32 Mhz, NOP = 4 cycles, and DSP executes 4*2 DSP cycles instructions
So, I think here, that the DSP doesn't run at 32 Mhz, but at 2 times cpu cycles.
Host interface (HI):
68030 can send datas via the HI port (addresses FFFFA205, FFFFA206 and FFFFA207). FFFFA204 is unused but can be void written.
These datas are sent immediately to the DSP at full speed (real HI runs at 8 MHZ, I've tested this and it didn't change anything)
When byte FFFFA207 is written, the data is transferred into the DSP and DSP can read it.
Byte FFFFA202 gives the state of the transmitter and the receiver (empty/full or ready)
Byte FFFFA205 is the Interrupt vector register. 68030 can tell the DSP to interrupt it's current work and run into an interrupt. Current work resumes at the end of the interrupt.
All the Host interface is driven by the 68030 (in "cycle" mode).
In general, programs test FFFFA202 to know the state of the transmitter/receiver before sending/reading datas.
Those how don't do it may encounter problems (eg. bound3.prg, rot3dbmp).
The problems with these programs can be explained by a default in cycles computing or by "bad time" interrupts from the Interrupt vector register.
The SSI interface:
Exchanges between DSP and Falcon are made via the crossbar. This can be:
For DSP record :
microphone -> DSP record
DMA play -> DSP record
PSG sound -> DSP entrance (yes ;))
For DSP play :
DSP play -> audio out
DSP play -> DMA record
Crossbar frequency is constant, and computed with the crossbar frequency (25 or 32 Mhz), sound quality (from 8 to 41 Khz), number of tracks (from 1 to 8 for the falcon) and mono/stereo sound.
Datas transferred from crossbar to DSP or from DSP to crossbar generate an interrupt into the DSP
The crossbar frequency is computed like this in the crossbar :
/* Calculate 25 Mhz clock cycles */
cyclesClk = ((double)CPU_FREQ / Crossbar_DetectSampleRate(25)) / (double)(crossbar.playTracks) / 2.0;
crossbar.clock25_cycles = (int)(cyclesClk);
crossbar.clock25_cycles_decimal = (int)((cyclesClk - (double)(crossbar.clock25_cycles)) * (double)DECIMAL_PRECISION);
/* Calculate 32 Mhz clock cycles */
cyclesClk = ((double)CPU_FREQ / Crossbar_DetectSampleRate(32)) / (double)(crossbar.playTracks) / 2.0;
crossbar.clock32_cycles = (int)(cyclesClk);
crossbar.clock32_cycles_decimal = (int)((cyclesClk - (double)(crossbar.clock32_cycles)) * (double)DECIMAL_PRECISION);
It is computed with CPU_FREQ (which is a 8 Mhz constant value) to give an amount of CYCLES for cyc_int (CROSSBAR_INTERRUPT_25 and CROSSBAR_INTERRUPT_32).
Isn't there a problem between the "68030 clock" and the "crossbar" clock ?
Is it true that DSP doesn't run at 32 Mhz in hatari but at 2x 68030 cycles ?
Is the crossbar conversion between frequency and cycles is correct ?
Do the 68030 cycles and the crossbar "cycles" mean the same thing ?
Ce message et toutes les pieces jointes (ci-apres le "message") sont
confidentiels et etablis a l'intention exclusive de ses destinataires.
Toute utilisation ou diffusion non autorisee est interdite. Tout
message etant susceptible d'alteration, l'emetteur decline toute
responsabilite au titre de ce message s'il a ete altere, deforme ou
This message and any attachments (the "message") are confidential and
intended solely for the addressees. Any unauthorised use or
dissemination is prohibited. As e-mails are susceptible to alteration,
the issuer shall not be liable for the message if altered, changed
More information about the hatari-devel