REV 3 - REV 5 - The beginning (ST536)

[Badwolf]

Now I have tried EMUTOS again, showing the same speed as TOS206 now ?1 :WTF: :dizzy:

I think it's time to take up golf!

BW

[exxos]

I think it's time to take up golf!

I definitely need to retire permanently that's for sure. Though I don't get how I managed to get EMUTOS up to those levels in the first place :cry:

[Badwolf]

I definitely need to retire permanently that's for sure. Though I don't get how I managed to get EMUTOS up to those levels in the first place :cry:

Kind of feels like you borked one of the timers at at some point, doesn't it? :D

Perhaps MAPROM from a cold start in the auto folder?

BW

[exxos]

Kind of feels like you borked one of the timers at at some point, doesn't it? :D

I did wonder that for not sure how the timer tick can be changed, but I don't know much about those things. But even so, it would have to be running at half the speed and it would have a side effect of making other tests double speed, not just select ones :shrug:

Perhaps MAPROM from a cold start in the auto folder?

I generally power of the machine in between tests to make sure it powers up from "cold" .

[exxos]

looking at my original results to the results I did yesterday...


"LAST YEAR"

NO_BLIT.jpg

"YESTERDAY"

IMG_0354.JPG

I was only really looking at the first result that is actually slower. But then looking at the VDI TEXT test, its 325% vs 363%. So the later results are faster in that respect.

I have a feeling I might be running the STE firmware, as I had to slow things down fractionally I think to get it to work. I think this could be down to the 2% RAM difference between the 2 tests. The evil caches might be playing a part as well. :shrug:

I have also removed the EMUTOS benchmark from my website as I have no idea how that benchmark came to be in existence.

[Badwolf]

looking at my original results to the results I did yesterday...

I was only really looking at the first result that is actually slower. But then looking at the VDI TEXT test, its 325% vs 363%. So the later results are faster in that respect.

Those are as near as damn it the same. The only thing that really matters is the ROM speed, integer speed and the pair of RAM speeds.

The danger of comparing EmuTOS across times is it's constantly being updated. Apart from for the pure interest of it, I'd stick to a known static OS if trying to measure hardware differences.

BW

[exxos]

As I've been looking into this (rev5) the past couple of weeks I thought I would post a progress report.

I have been running into DMA issues again. Though I now realise I had exactly the same problem with the SEC booster. but the problem seemed to "vanish" so I never thought anything of it again.


Basically this is a good and bad sector write to ultrasatan.

1.JPG

2.JPG

If you look at the second row down, you can see there is a "missing byte". Ironically this problem only surfaces with a -38 DMA. The problem does not show up with a IMP chip. Though I've generally suspected that those chips were marginally faster technology anyway.

When I was developing the SEC booster on a STFM. I attributed the problem due to noise on the longer A1 trace to the DMA. Adding some capacitance, or routing it through the PLD as I did at one point solved the problem.

I will make a wild speculation to what is going on. It is practically impossible to diagnose because I do not have a logic analyser for this work so I can only really continuously guess at it :roll: I think as A1 selects command or data register within the DMA, it is not selecting the correct register and ultimately causing it to "skip a byte". On the SEC booster a very small delay on A1 solved that problem. It is like the DMA does not latch the data in its registers until ( presumably glue) has finished releasing DTACK.

I don't know how the DMA is programmed. But I assume several writes to its registers to set up the sector count etc are done from the CPU first. Then I assume the CPU gets a bus request from GLUE where the DMA can take control of the bus and do the actual sector read or write. I think the actual sector is being written but obviously something has got shifted at some point.

I did try delaying writes to the ST bus totally, but it did not seem to help. The assumption was the CPU was writing to the DMA registers to fast. But it is also possible that is still happening because the clock switching will inherently not immediately switch anyway.

The current firmware on the website goes back to the original clock switching mythology. It only switches into high-speed on alt-ram access. This does cause a overall speed drop of around 50% on most tests, from 300% to 250% basically. If we ignore the DMA issue (use a IMP chip) then we can run at full speed with GB6 or FrontBench just fine. So likely this will just have to be the final code for a while.

I did try the IDE interface. But it is still not functioning and I really have no idea why. The interface is found but not the card. I double checked all the data lines were correct on the schematic and they seem so. But I really need to find the root cause of this DMA problem first..

Edit:

I have done a single 10ns delay on A1 to the DMA (reused the ACSI pin on the PLD and bodged wired to A1 on the DMA) and it now AutoBoot's from C: just fine. Though it is now looking up intermittently which I have to look into as well now :roll:

[PhilC]

Thanks for looking into these issues @exxos. The rev5 is a great improvement over the original tf536 on the Atari because of the inbuilt decoder, rom, etc. of course the original was great already :D

[exxos]

Thanks for looking into these issues @exxos. The rev5 is a great improvement over the original tf536 on the Atari because of the inbuilt decoder, rom, etc. of course the original was great already :D

:thumbup:


I have just realised something :roll: The whole premise of what I am currently trying to do is speed up ST_RAM access a bit to gain a few extra % in speed. But of course this is having a side effect of screwing up the DMA stuff. I think what I am basically doing is doing a "poor man's MAPROM" speed up on lower RAM variables. My faster RAM access in lower RAM is speeding up the scores but also because it is speeding up ST-RAM itself with it, that is what is screwing up things up.

So what I am doing is actually irrelevant because @agranlund's Original MAPROM diverts into alt-ram giving a huge speed gain anyway.

IMG_0468.JPG

Not really sure why @agranlund's Equivalent test is faster other than a couple % more on ST-RAM speed.

tt_relo1.jpg

The only time I saw 116% ST-RAM speed was when running the CPU at 50Mhz all the time. But that is the same problem as to what is screwing up the DMA :roll:

[exxos]

Is this right for IDE access assuming only 29 address bits ?

Code: Select all

wire ide_access = (({A[29:16]} != {14'h00F0}) & ({A[29:16]} != {14'hFFF0})) | ({A[7:6]} != {2'b00});

HD11 can find the IDE interface but not the card :roll: