exxos's Atari, Amiga & retro forum

Looking at the CPU clock in particular it seems it is rather bad.. (note they are driven from the 3.3V PLD!)



The SDRAM clock seems basically fine...


I tried FAST slew to see what would happen and TTram "vanished" totally.


I think the new boards are coming today but they have the old PLD fitted on them.. I may not have chance to change it until next week.. But those boards do have in-line termination with the clocks which I can experiment with better..

I suppose I could try experimenting with the 144 since the ROM speed up and some other bits has been removed. It might just FIT better..

exxos wrote: 05 May 2025 14:59 Does anyone know what would actually cause EMUTOS to reset during DOTT ?

Normally it chucks out a crash dump, but in my particular scenario this does not happen and its just like pressing the reset button at this point...

DOTT seems to reset sporadically. It's difficult to figure out any particular trigger for it.

Are you running from IDE?

Sporadic IDE-related resets were my original symptom.

Mine didn't do it when running from ACSI.

BW

Badwolf wrote: 06 May 2025 12:16 Are you running from IDE?
Sporadic IDE-related resets were my original symptom.
Mine didn't do it when running from ACSI.

Yeah IDE, Not tested ACSI yet. Though its locking up running YAARTTT anyway. It locked up during GB6 last night, but I did some tweaks and not done it since.

The main issue seems to stem from odd DTACK issues with ROM. So I am just running ROM at 8mhz and letting the STE do the DTACK as normal.

I think mostly now its termination on the CPU clock.. that brings me back to that 33pF cap again :) But I found quite a few little issues as I have been going along so I think it is the multiple load of problems.

Some TT RAM issues seem to stem from the delay introduced by the buffer enables. Its about 10ns. So its adding a delay before the SDRAM sees anything. I've shifted some timings so it "gains" 10ns.. seems way happier now.

I've put the 33pF cap back on the clock to see what happens and it looks a lot better...

exxos wrote: 05 May 2025 20:57 Okay so riddle me this one then for you Verilog wizards out there...

Code: Select all

FDCP ff_dtack1( .D(  DTACK ), .C( CLK100M ), .PRE( TOSCE ), .CLR( 1'b0 ), .Q( dtack_delay1 ) );
wire ROM_DTACK = dtack_delay1 | TOSCE;

BUT if I simply do this it does work

Code: Select all

wire ROM_DTACK = DTACK | TOSCE;

Can't see anything immediately wrong with your first code segment although TOSCE appears redundant in the flipflop to me. The delay is practically nothing as the first positive CLK100M edge would be a *maximum* of 10ns away.

Just be sure you've declared dtack_delay1 properly and things aren't simply vanishing into the aether.

BW

Badwolf wrote: 06 May 2025 13:33 Can't see anything immediately wrong with your first code segment although TOSCE appears redundant in the flipflop to me. The delay is practically nothing as the first positive CLK100M edge would be a *maximum* of 10ns away.
Just be sure you've declared dtack_delay1 properly and things aren't simply vanishing into the aether.

Yeah TOSCE is there in the rest of the FF chain. But even that as it is doesn't work. It doesn't make sense.

At one point if the STE decodes ROM and does DTACK (lets just assume DTACK follows /AS or close to it) When I issue my PLD DTACK at any point even 10ns after DTACK, it screws up and doesn't even try to boot up.

Similar that if I don't let the STE see ROM decoding at all, and issue my own DTACK, it also does not boot up.

It only works if I use the STE DTACK..

My only thought at the moment, is maybe the boot vector has to be done at 8MHz and something doesn't like it when its ran faster. But it wouldn't really explain me issuing my own DTACK basically in parallel with the STE one and it not working..

I did manage to push some extra speed out of the last night but I wasn't convinced it was working properly at that point, I do need to revisit that..

So currently I'm just using the STE generated DTACK for the ROM. I do the ROM decoding for the STE536 ROM in the PLD. But nothing else. Its not really a huge issue, just annoying as I cannot currently figure out what the hell is going on.

So I've stopped the STE seeing ROM access now, so it won't trigger DTACK. I generated my own DTACK signal in the PLD and its working. ROM speed dropped a bit even though 8MHz.

I've also added DTACK into the ROM decoding logic that it won't assert until the DTACK gone high, is make sure the previous cycle is completed before I attempt to start a new one..

I confirmed it would not be by disabling my own generated DTACK. So that seems fine. All boots up at 8MHz.

BUT same same problem as before that when I speed up the CPU it doesn't boot even though I have a ~70ns DTACK delay for ROM.

It's rather baffling. Considering the the one STE booster runs at 32MHz ROM speed just fine. Nothing special there. Just as DTACK timing sucks on the ST's, I can grab it quicker at 32MHz and gain the ROM speed, its very simple. But on the STE536.. its very sulky and no idea why currently :cry:

Ahhhhhhhhhhhh :lol: if I had a brain I would be dangerous! :D

So the 16bit bus isolator was synchronised to the 8MHz clock cycles. So it was never enabled in time for the faster CPU ROM speeds. :headbang:

This is EMUTOS.. so scores a "bit out" to normal, but shows over 400% ROM speed now!


:girldance: :cheer: :girldance: :cheer:

Don't forget to turn the bus on, exxos. :coffee:


















:hide:

BW

I need to fix the Blitter next :lol:

In case anyone is wondering, the Atari Fiji still appears even with the blitter "malfunctioning".


Blitter now happy :) and TOS206 GB6 test.


This is with blitter (still marginally slower than the V1 STE booster currently, but could be BLTFIX causing that)


and stock 104 (without blitter)


Now to see what I broke while fixing it.. :lol: