TF536 on the ST

[PhilC]

@terriblefire thanks, no rush as I won't be able to test until tomorrow evening.

[Umberto1st]

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.

[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)

[terriblefire]

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

[Umberto1st]

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

[terriblefire]

This version is a bit better in EmuTOS

tf536r2_ATARI_2020_08_03.zip

(15.32 KiB) Downloaded 187 times

[Umberto1st]

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.

[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.

[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?

[Badwolf]

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.