New CT60 Boot ROM 1.05

Discuss CT60/CT63, CTPCI, SuperVidel and EtherNAT hardware here.

Moderators: Mug UK, [ProToS], moondog/.tSCc., lp, Moderator Team

mikro
Hardware Guru
Hardware Guru
Posts: 2491
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: New CT60 Boot ROM 1.05

Post by mikro »

Instream once wrote to me:

Several years ago I was investigating random freezes of the falcon that only seemed to happen when using SV blitter interrupts in our games. There were hundreds of such interrupts per frame, and the freeze randomly happened after a minute or a few hours, I measured the CT60 bus using our oscilloscope on and off for about two years without finding the real cause. All bus signals looked correct up until the freeze. Our only clue is that there is something wrong in the CT60 ABE or SDR code, so they randomly cause the freeze when certain interrupt bus cycle conditions occur, possibly when the I6 expansion port interrupt collides with motherboard interrupts. Eventually we implemented a blitter queue in the SV instead so we got rid of the hundreds of blitter interrupts per frame. After that our games are much more stable.

Also, Rodolphe's assessment of the situation: The INT circuit is very poor/simple on SDR... doesn't give much hope that everything is 100% debugged. ;)

I managed to get them SDR source code but of course, it's complete charity from their side to look into it & debug it. But you can ask them nicely, sure. ;)

As for CT60e vs CT60, there's no reason why it should be CT60e specific. Even if it were, it only means that some interrupt again arrives a few nanoseconds sooner/later. Look at my setup - I have a CT60e+SV and one of the images (B, IIRC) works for me. You have a CT60e+SV and none of them works for leech.

leech: if you have time, please try to follow my "test" here: https://www.atari-forum.com/viewtopic.p ... 20#p366620 ... interestingly, that Wait demo is another weird SV test case.

The code in question is a routine for measuring Videl's running frequency using VBL, Timer B & Timer C. If I replaced these:

https://github.com/mikrosk/ct60tos/blob ... el2.S#L562
https://github.com/mikrosk/ct60tos/blob ... el2.S#L568
https://github.com/mikrosk/ct60tos/blob ... el2.S#L575

with two NOPs (i.e. the size of the image didn't change), the image miraculously started working for me. So clearly, it wasn't about some unaligned memory but the precise time when CPU wanted to access those Videl registers. So what we did was to move those a bit later (or sooner, can't remember) and voila, everything worked.

So a real workaround here could be that we provide a boot image with these checks disabled (or reprogrammed in another way so it wouldn't use all three interrupts at once).
Rustynutt
Atari God
Atari God
Posts: 1441
Joined: Wed Mar 21, 2012 7:38 am
Location: Oregon

Re: New CT60 Boot ROM 1.05

Post by Rustynutt »

Thanks Mikro, very detailed, and appreciated.
User avatar
leech
Atari God
Atari God
Posts: 1382
Joined: Tue Dec 01, 2015 3:26 pm

Re: New CT60 Boot ROM 1.05

Post by leech »

mikro wrote: Mon Nov 23, 2020 9:13 pm Instream once wrote to me:

Several years ago I was investigating random freezes of the falcon that only seemed to happen when using SV blitter interrupts in our games. There were hundreds of such interrupts per frame, and the freeze randomly happened after a minute or a few hours, I measured the CT60 bus using our oscilloscope on and off for about two years without finding the real cause. All bus signals looked correct up until the freeze. Our only clue is that there is something wrong in the CT60 ABE or SDR code, so they randomly cause the freeze when certain interrupt bus cycle conditions occur, possibly when the I6 expansion port interrupt collides with motherboard interrupts. Eventually we implemented a blitter queue in the SV instead so we got rid of the hundreds of blitter interrupts per frame. After that our games are much more stable.

Also, Rodolphe's assessment of the situation: The INT circuit is very poor/simple on SDR... doesn't give much hope that everything is 100% debugged. ;)

I managed to get them SDR source code but of course, it's complete charity from their side to look into it & debug it. But you can ask them nicely, sure. ;)

As for CT60e vs CT60, there's no reason why it should be CT60e specific. Even if it were, it only means that some interrupt again arrives a few nanoseconds sooner/later. Look at my setup - I have a CT60e+SV and one of the images (B, IIRC) works for me. You have a CT60e+SV and none of them works for leech.

leech: if you have time, please try to follow my "test" here: https://www.atari-forum.com/viewtopic.p ... 20#p366620 ... interestingly, that Wait demo is another weird SV test case.

The code in question is a routine for measuring Videl's running frequency using VBL, Timer B & Timer C. If I replaced these:

https://github.com/mikrosk/ct60tos/blob ... el2.S#L562
https://github.com/mikrosk/ct60tos/blob ... el2.S#L568
https://github.com/mikrosk/ct60tos/blob ... el2.S#L575

with two NOPs (i.e. the size of the image didn't change), the image miraculously started working for me. So clearly, it wasn't about some unaligned memory but the precise time when CPU wanted to access those Videl registers. So what we did was to move those a bit later (or sooner, can't remember) and voila, everything worked.

So a real workaround here could be that we provide a boot image with these checks disabled (or reprogrammed in another way so it wouldn't use all three interrupts at once).
I have run the Wait demo, and it locked with the music looping, but haven't gone further down that rabbit hole yet. I did notice that the ABE and SDR on mine were blank when I first started up that program (pre-flash) and so I flashed it with the 7 set of strings, as I think the CT60e is supposed to be rev7 (I think I figured that out correctly). So that's what they're set to now. Weird thing is when I had booted into TOS, it had said my NVRAM was blank, and needed to be initialized (I thought I fixed that by desoldering that bastard years ago and putting in one of Exxos' adapters...) Anyhow, seems to still have clock info (unless I'm getting that from the cosmosex).

Falcon is a weird mutant machine to begin with, and with the CT60e+SV+CosmosEx, even more so.
Atari 8Bits: 800xl, 600xl, XEGS, 800, 130xe, 130xe (VBXE, U1MB, Stereo POKEY)
Atari STs: 1040STf (broken shifter), 1040STe, Mega STe, TT030, Falcon (CT60e, SuperVidel)
TXG/MNX
Captain Atari
Captain Atari
Posts: 218
Joined: Fri Oct 24, 2003 10:05 am

Re: New CT60 Boot ROM 1.05

Post by TXG/MNX »

Hi

I have a falcon with ct60e here with tos 1.03c that I wanty to upgrade to tos 1.05

ABESDR.prg shows

ABE:---- 0xFFFFFFFF
SDR:---- 0xFFFFFFFF

ESC: Quit
F5: Set IDs to AB5M and SD5E
F7: Set IDs to AB7F and SD7D

What should I do leave it on 0xFFFFFFFF or use F5 and F7 ? My 1.3c board runs ok ith the 0xFFFFFFFF setting.

Secondly which TOS must I use A or B Or C ?

And must I flash it in 030 or 060 mode ?

Any help would be great.
stormy
Atari God
Atari God
Posts: 1093
Joined: Tue Jan 26, 2016 12:39 pm

Re: New CT60 Boot ROM 1.05

Post by stormy »

There is a readme in the download which tells you A/B/C, it is to do with the pci expansion. You can flash in either mode, I did mine in 030 but was told 060 will be fine. I didn't set any ABE/SDR with mine, as my original got lost in a previous flash.
Rustynutt
Atari God
Atari God
Posts: 1441
Joined: Wed Mar 21, 2012 7:38 am
Location: Oregon

Re: New CT60 Boot ROM 1.05

Post by Rustynutt »

AIRC, 1.05 provides that as a token option, to enter whichever files are loaded. So next time (or owner) you are "reminded" :)
Of course, one could always set it wrong, but don't think it actually affects functionality.
My understanding anyway, and usually 10% right.
If you flash CT TOS 1.03, from "factory", you lose the original information.
When you flash CT TOS 1.05, you have the option to enter which version of SDR you flashed.
If you flash 1.03, you lose the info from 1.05.
If you flash back to 1.05, you must re-enter the file names again.
Sound right?
mikro
Hardware Guru
Hardware Guru
Posts: 2491
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: New CT60 Boot ROM 1.05

Post by mikro »

It's just a value written to CT60's flash memory.

You can modify it either with the original flash tool (running on Falcon + JTAG cable) while updating ABE/SDR or write directly using Insane's BIOS.

It's purely a cosmetic thing.
User avatar
wongck
Ultimate Atarian
Ultimate Atarian
Posts: 13155
Joined: Sat May 03, 2008 2:09 pm
Location: Far East
Contact:

Re: New CT60 Boot ROM 1.05

Post by wongck »

it is always good to write it in as a reminder of what was flashed.
some years later you will forget.... and try to do something and find out it will not work... just like me in the case of trying out USB several years back.
My Stuff: FB/Falcon CT63 CTPCI ATI RTL8139 USB 512MB 30GB HDD CF HxC_SD/ TT030 68882 4+32MB 520MB Nova/ 520STFM 4MB Tos206 SCSI
Shared SCSI Bus:ScsiLink ethernet, 9GB HDD,SD-reader @ http://phsw.atari.org
My Atari stuff that are no longer for sale due to them over 30 years old - click here for list
patjomki
Atari maniac
Atari maniac
Posts: 76
Joined: Fri Mar 09, 2007 11:34 pm

Re: New CT60 Boot ROM 1.05

Post by patjomki »

patjomki wrote: Sun Dec 01, 2019 4:50 pm 2) floppy disk access lets the falcon crash in particular when I try to copy something to a floppy and it is write protected. The ATARI tells me that "Floppy Disk Drive A: is write protected, Cancel, Retry". If I press Cancel, the ATARI freezes, if I try Retry without removing the write protection the same alert box appears again and I can press Retry for several times until it freezes as well.

Do you think these problems will disappear with Boot ROM 1.05?
I have to quote myself. TOS hasn't been the problem but a tiny splodge of solder on the mainboard.

I was lucky to find an absolute expert in repairing Falcons. He found the error, removed the solder and voilà disk access works like expected.
Post Reply

Return to “CT60 / CT63 Area”