REV 3 - REV 5 - The beginning (ST536)

[Badwolf]

Sorry for wasting your time @terriblefire @Badwolf ...

Not at all here, chief. It's good to follow a diagnosis and see different techniques.

Does the rest of your AltRAM pass now, or just the lower bits?

Cheers,

BW.

[exxos]

The ram tests fine but only shows to 1F not 5.. But doesn't really matter right now . it passes tests fine and I've ran GB6 from it.

Currently got slightly sidetracked as it has a issue where it doesn't boot up .. If I leave it for like 30 seconds it then does boot up and works fine.... At 25mhz it doesn't have that problem,

My first thought is maybe GLUE when it decodes access zero, it's not releasing DTACK fast enough so the CPU trips up. So when I've woke up a bit, I'm going to try using DTACK as a clock, so in the first several bus cycles, it uses a much slower DTACK loop so it doesn't double read DTACK., but I don't get why it would work fine otherwise. Would seem odd that DTACK would be kept low for longer, but GLUE is doing that which is known screwy anyway. MMU would be doing DTACK for RAM, so that's my logic to it all..

[Badwolf]

The ram tests fine but only shows to 1F not 5.. But doesn't really matter right now . it passes tests fine and I've ran GB6 from it.

I wouldn't ignore that, TBH. That sounds bad. What does YAARTTT say when you give it the full 'M' range from 1000000 to 5000000 without fastram.prg?

Worth checking the two BANK lines? They map to the highest two bits in the 330.

Currently got slightly sidetracked as it has a issue where it doesn't boot up .. If I leave it for like 30 seconds it then does boot up and works fine.... At 25mhz it doesn't have that problem,

My first thought is maybe GLUE when it decodes access zero, its not releasing DTACK fast enough so the CPU trips up. So when I've woke up a bit, I'm going to try using DTACK as a clock, so in the first several bus cycles, it uses a much slower DTACK loop so it doesn't double read DTACK., but I don't get why it would work fine otherwise. Would seem odd that DTACK would be kept low for longer , but GLUE is doing that which is known screwy anyway. MMU would be doing DTACK for RAM, so that's my logic to it all..

I have seen a similar symptoms, usually after programming the CPLD but occasionally it'll only half boot and I'll have to shut down for 10 seconds or so before it'll go through things properly. I'd assumed this was the CPLD retaining some state for a period after power-down.

Our boards have a lot in common but GLUE isn't one of them.

One thing I found really handy for this is EmuTOS in ROM. It gets to text-on-the-screen much much faster than TOS4 (so probably TOS2?) and the disc seek check is almost instant. When this happens for me EmuTOS will show its version string and access the drive, but not get to the welcome screen. TOS will just show black screen.

BW.

[exxos]

I wouldn't ignore that, TBH. That sounds bad. What does YAARTTT say when you give it the full 'M' range from 1000000 to 5000000 without fastram.prg?

When investigate more later when I solve this reset issue.

Worth checking the two BANK lines? They map to the highest two bits in the 330.

I resolded it lots of times, I think that is what actually cause this problem, but at least is not failing in those 16 MB blocks now..

I have seen a similar symptoms, usually after programming the CPLD but occasionally it'll only half boot and I'll have to shut down for 10 seconds or so before it'll go through things properly. I'd assumed this was the CPLD retaining some state for a period after power-down.

Our boards have a lot in common but GLUE isn't one of them.

One thing I found really handy for this is EmuTOS in ROM. It gets to text-on-the-screen much much faster than TOS4 (so probably TOS2?) and the disc seek check is almost instant. When this happens for me EmuTOS will show its version string and access the drive, but not get to the welcome screen. TOS will just show black screen.

I get the Atari fuji logo up at boot, so thats all I really need to know anyway at this point.

I remember GLUE being incredibly sulky if you try and do any bus access without it knowing about it... As might first thought was just isolate ST_AS so GLUE simply does not see address zero being accessed and not issue DTACK at all, but then it just does not boot up at all :roll:

What I am not sure if glue will try and decode lower TTram addresses as well... As with 23 zeros, it would think it is literally addressed zero, not higher up in the RAM range, so I assumed there would be some conflict there as well... So it is like I am in a no-win situation somehow :roll:

in my SEC code, I ran reset through some flip-flops to make sure it was stable before starting the CPU up, that is not so easy on the 536 as reset is not routed via the PLD :(

[Badwolf]

Worth checking the two BANK lines? They map to the highest two bits in the 330.

I resolded it lots of times, I think that is what actually cause this problem, but at least is not failing in those 16 MB blocks now..

10... to 1F... is the first 16MB block.

I remember GLUE being incredibly sulky if you try and do any bus access without it knowing about it... As might first thought was just isolate ST_AS so GLUE simply does not see address zero being accessed and not issue DTACK at all, but then it just does not boot up at all :roll:

GLUE *must not* see any access off-board. The ST AS line shouldn't be going low at all when accessing your external ROM or the external AltRAM.

The stock firmware will make sure the ST's AS line is gated when AltRAM is accessed, you need to make sure its also gated with your ROMCE line.

If it's failing when gated with ROMCE, then there's something else amiss and that's where to look.

BW.

[exxos]

Talking to @Badwolf about some related stuff made me realise that the ROM was on the MB not the TF536 (currently) And that I had not been taking into account the bus isolator delays... So in effect I have to run ROM 20ns slower to compensate..

Now it is starting to boot up a little bit better, but I see odd corruption on the screen while it is "stuck" in reset.. Currently not sure why it is doing that... But when the corruption stops the machine boots up normally and works fine...

[Badwolf]

Is that a video sync issue? It kind of looks like the old rolling-screen TV then there's a resync and all's good.

Reach round the back and play with your vertical hold pot! :P

BW

[exxos]

Reach round the back and play with your vertical hold pot! :P

:lol: :chairsmack:


It seems it is stuck in some odd reset loop.. RESET is pulsing up and down like a madman, but there is no bus error or anything.. So that will explain the corruption as normally when you press reset you get corruption on screen for a second anyway.

[exxos]

I think I might have figured it out..

Something does not like to slow rise edge of the reset signal...


BEFORE

IMG_6355.JPG

AFTER 1K ADDED

IMG_6356.JPG

EDIT:

Going back to ROM delays... EG 2 = 20ns delay... It just simply looks like I am hitting the 50Mhz speed of the CPU as faster ROM speeds are not increase in speed...

Code: Select all

//1 no boot
//2 297%
//3 297%
//4 257%  
//5 257% 
//6 113%

EDIT2:

@Badwolf Testing 1F00000 to 2F00000 it passes fine for a few seconds then starts chucking out errors... So for whatever reason there is just bad RAM... But when I build up the next version of the board, that problem will probably go away anyway..

[exxos]

So maprom was still not working :roll: But I managed to find the code which allocates the lower RAM variables to fast ram and delete it out, I also limited the TT RAM to 16 MB as my board as ram problems...

And finally now runs!!

IMG_6358.JPG

ROM speed has jumped from just under 300% to almost 800% !

EDIT:

Oddly would have expected the GEM related scores to be a lot higher considering 32 bit ROM access :shrug: