Terriblefire Accelerators

[PhilC]

That's good news as I'm very slowly building one to pop into a Mega 4.

[terriblefire]

That's good news as I'm very slowly building one to pop into a Mega 4.

Current status with the ST firmware..

The 030 does not like to format a floppy with identical firmware to the 020. I need to investigate but time is limited.

[rpineau]

IT's probably a cache issue. You should only allow caching for the RAM, TOS and eventually fastRam (AltRam).
This is the VHDL from the test we did on the 68020 board when we put a 68030 on it (via a small adapter) :

Code: Select all

	-- 68030 experimentation
	CIIN <= '1' when  (Address_bus >= x"00E00000" and Address_bus < x"00F00000") -- tos
				or (Address_bus >= x"FFE00000" and Address_bus < x"FFF00000") -- tos shadow
				or (Address_bus >= x"00000000" and Address_bus < x"00400000") -- ram
				or (Address_bus >= x"FF000000" and Address_bus < x"FF400000") -- ram shadow
				or (Address_bus >= x"01000000" and Address_bus < x"09000000") -- fast ram 128MB
			else '0';

[terriblefire]

IT's probably a cache issue. You should only allow caching for the RAM, TOS and eventually fastRam (AltRam).
This is the VHDL from the test we did on the 68020 board when we put a 68030 on it (via a small adapter) :

Code: Select all

	-- 68030 experimentation
	CIIN <= '1' when  (Address_bus >= x"00E00000" and Address_bus < x"00F00000") -- tos
				or (Address_bus >= x"FFE00000" and Address_bus < x"FFF00000") -- tos shadow
				or (Address_bus >= x"00000000" and Address_bus < x"00400000") -- ram
				or (Address_bus >= x"FF000000" and Address_bus < x"FF400000") -- ram shadow
				or (Address_bus >= x"01000000" and Address_bus < x"09000000") -- fast ram 128MB
			else '0';

Possibly. I have the CDIS jumper set though. So i dont think thats the issue here in this case. Caches were my first thought too.

In my code I also assert CIIN any time i access anything but the fast ram. My fast ram is from 0x40000000 to 0x403FFFFF

[rpineau]

Yep, with CDIS jumpered if it still fails it obviously not a cache issue.
The floppy uses the DMA so may be a BR/BG/BGACK issue with retaking the bus to quickly with DMA data lingering on the bus.
On our 68020 board we resync these (I assume you do the same) to the 8MHz clock.
If I think of something I'll post here.

[terriblefire]

I only allow BGACK to be sampled to the CPU when the CPU_AS and AMIGA_AS are the same value. which has the same effect.

If you havent seen my LA setup already checkout the YT channel. I can actually capture the DMA cycles at 500Mhz.

EDIT: The odd bit is this working with the same HDL code on the 020. Wonder if there is some difference in behaviour.

[8 Bit Dreams]

Hello,
Happy to see the story continues,
Still hope to design a CPU relocator with ribbon cable for my ST

[8 Bit Dreams]

Have updated info on my For Sale thread on Amibay regarding TF5XX cards

[terriblefire]

Excellent.

One thing worth mentioning with all the TF 030 cards on the ST.. they *read*from floppy fine. But write is broken. It doesn’t write a single sector correct.

I’ve yet to debug properly but at first I thought it was the 7416245 chip that cuts off the day bus from the 030 section. But the problem is identifical on the Tf530 which doesn’t have it.

All three TF53x versions have the same issue with cache disabled and identical code. The Tf520 works with the same code. It’s v odd.

[terriblefire]

Ok.. new board announcement. TF330 - New CD32 Board. Its an 030 with a buttload of RAM.

Specs to be discussed tomorrow.. but please speculate here

Capture.JPG (277.29 KiB) Viewed 8374 times