ST536 STE EDITION

[dml]

If you don't have fancy litz wire you can always use solder wick for a ground strap :p although it's getting expensive too, in quantities bigger than a gnat.

[exxos]

If you don't have fancy litz wire you can always use solder wick for a ground strap :p although it's getting expensive too, in quantities bigger than a gnat.

Good point :) I used thick speaker wire on my other test board :P

[exxos]

ahhhhh

Previous benchmark viewtopic.php?p=129281#p129281

The problem was AS and DTACK are synced based on the re-created 8MHz clock. This means the ST bus cycles get skewed / delayed causing the slowdowns and stability issues.

So I've used the original clock instead now... no problems with clock phase and the speeds are up :D

IMG_3334.JPG

Now to see what's broken at 50MHz :lol: :fire: :hide: :fire:

[dml]

:yay2:

[exxos]

Blitter was unhappy because of my BG changes, but thats now fixed :) This is now 50MHz.. some speed up on ROM as well.

IMG_3336.JPG

As this is a firmware built from the ground up (kinda) I will start a new firmware section for these soon..

EDIT:

8MHz firmware is up. Nothing but 8MHz going on there. @Badwolf This be the most basic firmware which likely be worth you trying out.

[Badwolf]

@Badwolf I've sent you a new firmware (untested) with the whole patch module ripped out. Tough I've not been able to replicate that problem myself here yet.

Good news! This firmware is the best I've had yet, I think.

It does not have any reset issues (the autoboot remains firmly in my sights as a problem area) and is able to run DOTT happily. I also no longer need to jumper the CDIS line to run several of my test games, so I guess the firmware I did all my demos on was allowing STRAM to be cached and going back to inhibiting that dynamically has solved that problem.

Oddly I ran into problems with F1GP still -- this is the one that needed MMUDIS to be jumpered, but doing so on this occasion doesn't seem sufficient. It's struggling with disc accesses a bit. Perhaps I need to clean the jumper, but no more time to test today.

I think, in light of these latest tests, a set of compatibility registers are no longer really needed and would just be a nice to have (if cache is no longer a problem then disabling MMU would be the only real use case. TT-RAM was shown to be a red herring early on). So I'd say if that's still causing problems, drop it.

I'll try to run some soak tests tomorrow but I'm away for a couple of weeks from the weekend. Do you want this board sent over before I depart?

BW

[Badwolf]

8MHz firmware is up. Nothing but 8MHz going on there. @Badwolf This be the most basic firmware which likely be worth you trying out.

Unless there's anything you specifically want testing here, I think the no autoboot firmware fixed my reset issue.

BW

[exxos]

@Badwolf great there's some progress.

What configuration are you running DOTT? plain system? MAPROM? BLTFIX? BLITTER on or off? Booting from resolution? IDE or DMA etc If it's 206 that's going to be a epic problem now...

I still can't run it here. I'm using my new 50mhz firmware and DOTT just resets in 206. The new firmware is nothing much past a stock cpu at this point. It doesn't run from ultrasatan or IDE in 206.

Probably no use sending me your board at this point. I think the AB code isn't doing what I think because of what I found earlier today that the 8mhz clock is causing a huge clock skew. So I suspect when the AB code runs, it's actually corrupting the next bus cycle.

EDIT
viewtopic.php?p=127966#p127966
Looks like I had DOTT running in 206 at some point :shrug:

Even a stock CPU 8mhz... No TTram, No AB etc. About as basic as can get... DOTT just resets on loading. Boots fine in EMUTOS.

[exxos]

I did some more testing with DOTT. Basically runs fine in EMUTOS. My 206, it just resets when loading, or with BLTFIX & MAPROM, it just locks up on a corrupted black screen.

Long story short, vanilla 206 it works fine. So this means something is balked on my build of TOS :( but I have no idea what because all I really did was enable the cache clear code from TOS306. Its pretty much otherwise identical I think.

I've tried with blitter turned off and on, with desktop cache on and off, and nothing makes any odds.

So unless someone steps up and figures out the problem, I'm afraid that problem will just have to remain.

[Badwolf]

@Badwolf great there's some progress.

What configuration are you running DOTT? plain system? MAPROM? BLTFIX? BLITTER on or off? Booting from resolution? IDE or DMA etc If it's 206 that's going to be a epic problem now...

That was tested with EmuTOS 1.3 as shipped, no AUTOs or ACCs running off IDE with ASCI DMA present, but not employed. Starting from ST-LOW.

Blitter will be off in the VDI by default (EmuTOS + AltRAM). I never use BLITFIX or MAPROM in real life.

Unfortunately I put together my IDE SD card after the 144 board became stable for me, so I felt no need to go to all the effort to set up HDDriver-supporting partitions. It now means it's useless for testing outside of EmuTOS.

Perhaps I can transplant my Falcon's IDE card which does have HDDriver compatible partitions on it and run off that for ExxTOS testing.

BW