Page 11 of 26
Re: TF536 on the ST
Posted: 03 Aug 2020 13:21
by PhilC
@terriblefire thanks, no rush as I won't be able to test until tomorrow evening.
Re: TF536 on the ST
Posted: 03 Aug 2020 14:28
by Umberto1st
terriblefire wrote: 03 Aug 2020 13:18
bare with me while i try and get both atari and working from one set of code..
I noticed i still had the Amgia boot rom mapped at 0xf00000 which might explain corruptions. try this...
tf536r2_main_top_ATARI_FULL_PHASE_7_danger.zip
There is no way I could keep it straight. Other than the IDE and ASCI issues, it is rock solid. I have been pushing it. Less crashy than my CT63. Other than a few development glitches, it is some nice work. I'll try the new firmware this morning.
Re: TF536 on the ST
Posted: 03 Aug 2020 18:22
by Umberto1st
1. Emutos is booting without delay
2. IDE in Emutos is working. Formatted and booted off 16 gig compact flash, No auto boot off 32 gig card but does format and is readable and writable
3. No autoboot off TOS 2.06 even with INT tethered P10 ASCI to Pin 31 TF536 IDE port
4. Still Corrupted data off ASCI port
5. System crashes 3 or 4 min after cold boot(CORRECTION PROBABLY BAD CONNECTION IN 64 PIN SOCKET)
Re: TF536 on the ST
Posted: 03 Aug 2020 18:52
by terriblefire
Umberto1st wrote: 03 Aug 2020 18:22
1. Emutos is booting without delay
2. IDE in Emutos is working. Formatted and booted off 16 gig compact flash, No auto boot off 32 gig card but does format and is readable and writable
3. No autoboot off TOS 2.06 even with INT tethered P10 ASCI to Pin 31 TF536 IDE port
4. Still Corrupted data off ASCI port
5. System crashes 3 or 4 min after cold boot(CORRECTION PROBABLY BAD CONNECTION IN 64 PIN SOCKET)
I have no ACSI devices to test with so its not really going to be possible to debug that one. Not sure whats up with the IDE interface on plain tos.. perhaps its a 00F0xxxx vs FFF0xxxx thing
Re: TF536 on the ST
Posted: 03 Aug 2020 19:25
by Umberto1st
terriblefire wrote: 03 Aug 2020 18:52
I have no ACSI devices to test with so its not really going to be possible to debug that one. Not sure whats up with the IDE interface on plain tos.. perhaps its a 00F0xxxx vs FFF0xxxx thing
Would you be willing to debug if I sent you one (UltraSatan). It is the devise that most Atari users have and use
Re: TF536 on the ST
Posted: 03 Aug 2020 20:19
by terriblefire
This version is a bit better in EmuTOS
Re: TF536 on the ST
Posted: 04 Aug 2020 00:43
by Umberto1st
terriblefire wrote: 03 Aug 2020 20:19
This version is a bit better in EmuTOS
tf536r2_ATARI_2020_08_03.zip
Thanks I'm testing right now.
Initial thoughts are that it may not be the TF536 that is the problem with the DMA. I'm going to set up two more test systems , one stock and one with a TF536 and look at the timing of the DMA's with a logic Analyzer. Timing is really tight on reads/writes of commands and data over the dma. Some folks have had allot of problems with the Ultra Satan period.
This latest firmware seems stable but I cannot get MINT to work, and that include all the firmwares up to this date.
Re: TF536 on the ST
Posted: 04 Aug 2020 12:55
by terriblefire
I've been looking into why TOS 2.06 cannot read from IDE...
It looks like this code is never getting told the drive is ready.
Code: Select all
/*
* check for IDE ready, with timeout of ~5 sec
*
* Passed:
* d0.b = IDE drive unit #
*
* Returns: 0 - if drive is NOT ready
* 1 - if drive is ready
*/
/* 306de: 00e01ec2 */
/* 206de: 00e019f4 */
iderdy:
andi.b #$07,d0 /* mask off flags (if any) */
lsl.b #4,d0 /* shift unit # to place */
move.b d0,ide_headn /* select device */
#if (TOSVERSION >= 0x300) & (TOSVERSION < 0x400)
move.l #1000,d0 /* set up timer IDERDY */
add.l (_hz_200).w,d0
iderdy1:
btst #6,ide_stat2 /* status drive ready? */
bne.s iderdy2 /* yes, report ok */
#else
move.b #$50,d1 /* ready status */
move.l #1000,d0 /* set up timer IDERDY */
add.l (_hz_200).w,d0
iderdy1:
cmp.b ide_stat2,d1 /* is drive ready and not busy? */
beq.s iderdy2 /* if so, return with drive ready */
#endif
cmp.l (_hz_200).w,d0 /* timeout reached? */
bcc.s iderdy1 /* no, try again */
moveq.l #0,d0 /* report failure */
rts
iderdy2:
moveq.l #1,d0
rts
which when compiled looks like ..
Code: Select all
ROM:00E019F4 ideready:
ROM:00E019F4 andi.b #7,d0
ROM:00E019F8 lsl.b #4,d0
ROM:00E019FA move.b d0,($FFF00019).l
ROM:00E01A00 move.b #$50,d1
ROM:00E01A04 move.l #$3E8,d0
ROM:00E01A0A add.l ($4BA).w,d0
ROM:00E01A0E
ROM:00E01A0E iderdy1: ; CODE XREF: ideready+26↓j
ROM:00E01A0E cmp.b ($FFF00039).l,d1
ROM:00E01A14 beq.s iderdy2
ROM:00E01A16 cmp.l ($4BA).w,d0
ROM:00E01A1A bcc.s iderdy1
ROM:00E01A1C moveq #0,d0
ROM:00E01A1E rts
The drive always read 50B8 from FFF00039.
Its not even polling the MFP_GPIP for an interrupt.. times out before that.
Re: TF536 on the ST
Posted: 04 Aug 2020 13:16
by terriblefire
I think i have it...
The drive is returning $50xx which is status ready.. but the TF536 has Amiga style IDE and acks these with a DSACK1. Word ack... I wonder if its picking up the second byte of this because its an odd address and a byte read?
Re: TF536 on the ST
Posted: 04 Aug 2020 14:23
by Badwolf
Umberto1st wrote: 04 Aug 2020 00:43
Initial thoughts are that it may not be the TF536 that is the problem with the DMA. I'm going to set up two more test systems , one stock and one with a TF536 and look at the timing of the DMA's with a logic Analyzer. Timing is really tight on reads/writes of commands and data over the dma. Some folks have had allot of problems with the Ultra Satan period.
Not directly related to the topic at hand, but I've had a devil of a time getting DMA working on my Falcon board to the point that I've disabled the floppy and blitter in EmuTOS and decided to work on altram for a bit.
If you nail down the critical DMA timings for the ST would you be so good as to post them? It really might help my project too. On the face of it, I can't see why it's such an issue!
Thanks,
BW.