ST536 STE EDITION

[PhilC]

@exxos will try as soon as I can. This weekend has ended up much busier than I expected.

[exxos]

I don't know if I have a bad connection or there is something else going on now.. Because if I run ROM at stock speed 8MHz, TTram is unstable. But if I run ROM slightly faster, it seems to work fine :roll:

EDIT:

I think part of the problem is the SDRAM buffers have a 10ns OE delay time. if I "hardwire them" to ON, its way more stable. Though these are faster buffers then TF used already..

[exxos]

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.

[exxos]

I seem to have it a very perplexing problem :roll:

I decode ROM space and boot vectors and issue ROM_CE on the STE536 ROM. This must work as it well boots up to desktop etc.

HOWEVER, DTACK is being read from the motherboard issued DTACK. If I ignore that DTACK, it doesn't boot.

HOWEVER, if I issue DTACK from my code, it still doesn't boot up.

It only ever boots when I actually disable my PLD DTACK code. When it shouldn't matter if the ST issues DTACK AND my PLD issues DTACK as the CPU at 8MHz won't care for some time later anyway.

So I'm actually scratching my head somewhat now.

USE ST DTACK = fine
USER PLD DTACK = not fine.

Even if I don't delay PLD DTACK, basically DTACK = ROM_CE.. its likely what the ST does anyway..

The PLD DTACK code must work as IDE uses the same code. I just have a AND caluse so if IDE_ACCESS & ROM_DTACK kinda thing. So should be fine.. but nope..

:dizzy:

EDIT:

Even though ROM runs at 8MHz currently , issuing PLD DTACK doesn't work... BUT if I force the CPU to 8mhz all the time, it then works!! So something is tripping up somewhere :roll:

[exxos]

Okay so riddle me this one then for you Verilog wizards out there...

This does not work...

TOSCE is just TOS206 decoding (which works) but even replacing it with 1'b'0 makes no odds.

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;

Now DTACK is STE's DTACK. CPU running at 8mhz. So it shouldn't care about a 10ns delay on it.

So I can only assume the flip-flop isn't doing what I think it's supposed to be doing :shrug:

EDIT:

I think its not helping because AS was missing from TOSCE :roll: I can run both PLD and STE DTACK together, but PLD driven DTACK alone still isn't happy. Maybe the STE *has* to see ROM access for some reason.. odd..

[stephen_usher]

Beware that it seems at least some Verilog compilers "optimise" out some functions because it knows better. There was a discussion about this (and workarounds) in the Atari PiStorm Discord a while ago. I can't remember what had to be done to stop the compiler removing a whole section of stuff to do with a pin. Some sort of directive or other.

[exxos]

I wouldn't be surprised at all with compilers, I don't really trust them...

The STe seems to be unhappy unless I wait for DTACK from the STE itself before doing something. Simply setting ROM_CE and DTACK as a clocked delay isn't working (the STFM didn't care). But if I ignore the STE DTACK, everything breaks.

So possibly the STE is holding off DTACK for some reason. Maybe other BG cycles or something but I haven't been able to find a "trigger" for it all yet.

[exxos]

Best ROM access speed I can get.

IMG_3118.JPG

But the STE V1 booster (even running GB6 in STram) still outperforms the 030 :roll:

ste32mhz.jpg

EDIT:

For the keen eyed, integer division and TT RAM test seem a little slower because of the loading of BLTFIX :shrug: EMUTOS shows the "correct" scores.

MAPROM doesn't seem happy for some reason either.

[exxos]

With MAPROM

IMG_3119.JPG

I tried running YAARTTT with maprom and it locked up after a few tests. Trying again without MAPROM and it's just started it's second pass...

[exxos]

Left it running overnight with TOS206 without MAPROM.

IMG_3120.JPG

So is not like the TT ram is unstable at this point....

EDIT:

Now its morning and its locking up for no reason now.. :roll: