The TF330 is here

[terriblefire]

OK the basic ram checks are done.

firstramcheck.JPG (44.02 KiB) Viewed 3821 times

[8 Bit Dreams]

Wooow! That was fast!
What does TF330 card now? Is it booting with ram?

[terriblefire]

Wooow! That was fast!
What does TF330 card now? Is it booting with ram?

No it cant run code yet from fastram. Thats my next thing to fix. Its fine when probed from other ram.

[terriblefire]

I think i basically have an issue where a precharge is not issued between bus cycles.

[terriblefire]

Small update..

I got a bit bogged down with the 25/50Mhz switch code. I know its not the most essential thing but its one of those things i want to nail as early as possible. Plus I havent managed to get this card to run at all at 25Mhz which is frustrating because my LA rig has a 68030RC25 soldered into the breakout.. which means until i get that working I cant really move onto all the SDRAM fun.

I've tried out a different approach this time for going across the clock domains. Basically i want to sample the 14Mhz clock at 100Mhz and then use a different clock based on what memory is being accessed. I wondered if @rpineau has any thoughts on this? I want to go slow when AS20 (Motherboard) goes low and stay fast the rest of the time. The reason for this is because otherwise executing from cache will be with the slow cpu speed.

One thing to note is my 100Mhz, 50Mhz are 25Mhz clocks are related. but the 14Mhz clock is free running.

[exxos]

Do you really need to downclock when AS is low though ? If your holding off DTACK then it pretty much does the same job anyway.

[terriblefire]

Do you really need to downclock when AS is low though ? If your holding off DTACK then it pretty much does the same job anyway.

There is a very narrow response window to get CD32_DTACK to 030_DTACK...

I figured it might be cleaner to go the sampling route than all this ASYNC logic.. I'm open to any way that works reliably to be honest.

[exxos]

There is a very narrow response window to get CD32_DTACK to 030_DTACK...

How so ?

When DTACK goes low, the CPU obviosly needs to process it, so not sure how that would be a issue ?

When I look at DTACK, I add in waitstates onto it ( at 32mhz or whatever) and keep adding until the ST starts slowing down, like 80% speeds.. Then I start removing waitstates until the system is at 100% speeds again. That way, the CPU is stalled for a long as possible while DTACK is low. The ST will complete the cycle and all is happy.

Basically waiting until the last possible ns to issue DTACK to the CPU.. the ST doesn't know about this and just sees /AS go high and completes the cycle as normal.

If DTACK was to early, the ST would try and run at 110% speeds and basically crash. To slow and the ST starts another 8MHz DTACK cycle and the system "misses" its proper termination point and the machine runs at 80% speeds.

Trick is to study when DTACK is just about to go high in a normal cycle, then you have your waitstates timing to issue to the CPU. You avoid the CPU re-reading the same DTACK signal as well then as the ST will always termate the cycle faster than the CPU can start a new bus cycle.

[terriblefire]

There is a very narrow response window to get CD32_DTACK to 030_DTACK...

How so ?

When DTACK goes low, the CPU obviosly needs to process it, so not sure how that would be a issue ?

When I look at DTACK, I add in waitstates onto it ( at 32mhz or whatever) and keep adding until the ST starts slowing down, like 80% speeds.. Then I start removing waitstates until the system is at 100% speeds again. That way, the CPU is stalled for a long as possible while DTACK is low. The ST will complete the cycle and all is happy.

Basically waiting until the last possible ns to issue DTACK to the CPU.. the ST doesn't know about this and just sees /AS go high and completes the cycle as normal.

If DTACK was to early, the ST would try and run at 110% speeds and basically crash. To slow and the ST starts another 8MHz DTACK cycle and the system "misses" its proper termination point and the machine runs at 80% speeds.

Trick is to study when DTACK is just about to go high in a normal cycle, then you have your waitstates timing to issue to the CPU. You avoid the CPU re-reading the same DTACK signal as well then as the ST will always termate the cycle faster than the CPU can start a new bus cycle.

I agree. I've just found the CD32 very picky on this. Its actually been quite easy to get 50Mhz working. 25Mhz is not happy at all. I think its because 14.8Mhz and 25Mhz are too close together. You cant fit 2 fast cycles inside one slow cycle. Perhaps I should just fit an 80Mhz crystal instead and go with 40Mhz and be done with it.

EDIT: Amiga's dont do ARB and slow down BTW. They cycle overlap and crash. its a real PITA.

[exxos]

I agree. I've just found the CD32 very picky on this. Its actually been quite easy to get 50Mhz working. 25Mhz is not happy at all. I think its because 14.8Mhz and 25Mhz are too close together. You cant fit 2 fast cycles inside one slow cycle. Perhaps I should just fit an 80Mhz crystal instead and go with 40Mhz and be done with it.

EDIT: Amiga's dont do ARB and slow down BTW. They cycle overlap and crash. its a real PITA.

If your trying to fit 2 fast cycles inside a slower one, thats probably why slower speeds are not working. I half recall you talking to me about this before ? I think you was trying to run fast-ram cycles at the same time as "MB" cycles were happening ?

Even so, if clocks are out of sync its complicating matters as that fast clock timing is going to be a bit "hit and miss" in the lower clock domains timing.

EDIT: You probably would need a fast domain clock, I would guess 2.5 or 3x faster than the 14MHz clock to do 2 fast cycles inside a slower one. Probably like 42MHz would be needed to complete 2 full clocks reliable inside a 14MHz clocked cycle.