exxos's Atari, Amiga & retro forum

Well, it wasn't the BIOS version! Pretty much the same with v7. Will wait now for the replacement WDC chip and see if that makes a difference. Lots of things I need to rule out still, including a bad CD ROM drive.

dalek wrote: 11 Jun 2019 03:48 So $E900000 is where the CDTV/A570 DMAC essentially hardcodes itself but also where the SPI port on the TF534 is hardcoded. When I get a chance I'll do a test by disabling the SPI port in the firmware and see if it gets any further.

Possibly. But this is fixed in the 2.3 roms AFAIK. The SPI port cannot be assigned anywhere but E90000 because its the first 64K autoconfig device. The CD drive will just get given the next slot up.

Also could be issues with CFGOUT not being connected, meaning we might need two separate runs of autoconfig...

Nah nothing to do with this. Its all software related. Older stuff expecting the CDTV/A370 to be the only autoconfig device. Also alot of older stuff doesnt allocate the correct ram for the job and will assign 32bit fastram for DMA buffers.

EDIT: the only way to avoid the SPI port getting E90000 is to disable it completely.

I can confirm it doesn't seem to like to coexist with the A2091 in my setups. Tried against 2 x rev 6.2 boards and a rev 4.x board. It' not a big deal, I will probably source another IDE interface for this 2000 and fit alongside my A2630 and use the 534 in another Amiga I think. I ruled out cache, A2091 BIOS ver, and SCSI IC version too. Only reason I am posting this is to help others wondering if they can use an A2091 with it (you can for RAM, but SCSI seems to hang on boot if autoboot enabled - but system will boot when there are no SCSI drives connected).

Just and update: still not working, might be more to this than originally thought.

So just a reminder my specific case is: TF534 in an A500 Rev 6, 1MB chip, A570 CD-ROM drive. There are a lot of similarities to the CDTV but there are differences too.

FIRST ISSUE: Black Screen when TF534 connected

EDIT: Most of this I think is wrong - must have just been dumb luck that it worked
EDIT: When I say black screen, usually this means RESET is also held low
I have managed to (EDIT: SOMETIMES) get past this by erasing the RAM CPLD and modifying the BUS CPLD code to send all autoconfig address access at E80000 to the Amiga side (not the 030 side) as follows:
(excuse my verilog, I'm just learning as I go EDIT: ^^ not correct but good enough to prove the point)

After trying lots of things like moving the SPI address, disabling SPI altogether, disabling autoconfig altogether I wasn't making any progress. The only way I could ever sometimes get it to start was to prevent the BUS CPLD from handling E80000 access.

I believe this is because the on-board A570/CDTV ROM is waiting for it's own autoconfig of DMAC to happen and it never does.

There is some historical info here: https://web.archive.org/web/20081120085 ... nical.html

The interesting part is:

So my long term hope is to find a way to deterime when DMAC has finished configuring and then run the 030 side autoconfig to get the RAM (with SPI disabled or moved to EA0000). I'd also be happy with non-autoconfig RAM if needs be.

There is a spare pin on the RAM CPLD so worst case I could connect DMAC CONFIG_OUT to this pin, but I would prefer not running extra wires if there is a way around it.

At least now I know the 030 works with the A570 and that autoconfig hardware/software is an issue I can focus on.

SECOND ISSUE: CD Drive Doesn't work

So Stephen kindly reversed the driver here: https://github.com/terriblefire/cdtv.device

I was able to change the AllocateMem function to use CHIP instead of PUBLIC RAM by changing a line:
I recompiled the ROM as follows using romtool and byteswapped the image using Keir's kickconv for my programmer

CDTV owners will need to also split the ROM in two (kickconv can do this).

Now I tested this _without_ the TF534 and the CD drive works fine.
When I test _with_ the TF534, using the no-autoconfig process above, the CD drive STILL doesn't work :/

So I'm thinking for the CD drive issue:

- the allocating memory in Non-DMA Fast RAM is not the only problem, as the CD drive still doesn't work even with the TF534 and no fast mem
- I probably need to look over the memory map and driver a bit more and see if there are other issues with memory addresses that the TF534 should send to the Amiga side in this configuration.
- someone with a CDTV might be able to test this and we can compare results


So no success as yet, might have just opened a can of worms. Oh well, at least my TF330 is good enough 99% of the time and I'm learning as I go :)

GadgetUK164 wrote: 15 Oct 2019 14:18 I can confirm it doesn't seem to like to coexist with the A2091 in my setups. Tried against 2 x rev 6.2 boards and a rev 4.x board. It' not a big deal, I will probably source another IDE interface for this 2000 and fit alongside my A2630 and use the 534 in another Amiga I think. I ruled out cache, A2091 BIOS ver, and SCSI IC version too. Only reason I am posting this is to help others wondering if they can use an A2091 with it (you can for RAM, but SCSI seems to hang on boot if autoboot enabled - but system will boot when there are no SCSI drives connected).

I am jumping in late to the conversation, so excuse me if I am assuming youre talking about TF534 with an A2091....

But are you referring to using the TF534 with A2091? Because I have that exact set up, and it works perfectly. I have a CDROM attached to the A2091 and there is a 2min, 43 sec delay before it boots. But to correct this, I have set the jumper on the A2091 to DIS to disable the boot rom, and I move a file into the EXPANSION folder in HD0: when I need to boot with CDROM. I believe this is because Im running v6.6 ROM in the A2091 and that ROM is not fantastic.

Other than that 2min, 43 sec delay time, the TF534 works perfectly with the A2091 with 2MB onboard. I also recently added a BSC Multiface3 card and still everything works sweet.

So I've done some more troubleshooting on part 1 of my problem with the A570+TF534 combo. Most of what I wrote above is garbage :D

Symptom 1: black screen

My testing is done with the RAM CPLD erased to prevent autoconfig issues.

Reset is held low for approx 20 seconds then goes high. Screen stays black.

At that time, /BGACK is high, but /BG, /BR, /AS and /DTACK are all asserted low. At the edge connector, /OVR is also low if that makes a difference. I don't have a DSO or LA to get timings.

It's like the A570/DMAC is waiting to set /BGACK low but some condition is preventing it from deciding to do so. Either that or we miss it. P4-1 of the manual describes it in detail.

Matze's code may have some clues as it handles DMA and the CDTV. But it's all foreign to me and I need to do a bit of study.

I also found the A570 Production Release Documentation.pdf via a1k.org, in case delving in to the FPGA logic is needed.

Symptom 2: A570 FPGA gets hot (autoconfig issue)
When the RAM CPLD is programmed, the FPGA gets hot - I think DMAC is locked up. I think I can easily resolve this by doing the TF534 autoconfig after the A570 autoconfig (and/or by using a spare pin to read the DMAC /CONFIGOUT). But to get that far I need to resolve the black screen issue above.

Symptom 3: CD Drive doesn't work
I'm not going to look at this any further until I can work around the above two issues. Hopefully the custom ROM process above is enough.

And for the A2091 issue - I haven't looked at it. I have confirmed that waiting more than 3+ minutes for the A570 to do something doesn't change anything. So it's going to be a different issue (on board scsi.device driver related probably).

So unless I buy a logic analyser, or get lucky trying random things, I don't think this is going to get very far any time soon :/

Your issue is pretty simple. The OS is allocating 32 bit fastram for the buffers which don’t work with this device.

The reason it works when you defer the autoconfig is because the OS is then using chipram for buffers.

I’ve explained this 8 or 9 times now

It's not even getting that far. I'm certain it's some bus timing issue.

_occasionally_ if the stars align it will boot (with the RAM cpld erased) and I can see the CD0: drive in sysinfo. Though 99 times out of 100 it's stuck with /BG /BR low and /BGACK high.

There is no 32 bit fast ram to allocate in the config I am testing!

Probably related to BGACK/BR/BG timing.

BR doesn’t go through the CPLD and @exxos thinks that might be critical.

Pretty sure this board will never be perfect with bus arb.

On the ST at least, the GLUE gets sulky if all the busgrant stuff isn't in sync. Normally pass BR via a 8MHz clocked FF to slow it down and make sure CPU_AS & DTACK is high before passes BG to the system.