REV 3 - REV 5 - The beginning (ST536)

[exxos]

@ijor is there any signal I can tap into that you know of, which will determine if the MMU is doing a video or a CPU RAM access ?

I can only think at the moment that my memory accesses misaligned. Ironically, the more high-speed CPU cycles there is, the worse this problem seems to get and the memory speed run slower ! :stars:

I suspect what is possibly happening is that the CPU is trying to do a misaligned memory access, where it probably falls for arguments sake, "mid way" through the CPUs memory "time slot". So then the MMU likely cannot serve the request because there simply isn't time, it then serves the video access, then serves the CPU RAM request.. So basically it just added a bunch of delays...

It's a bit of a roadblock because I don't think there is really any way around this problem more than clock switching which just so happens to solve the problems anyway.. But that creates other problems :lol: :roll:

The only way I can think of, is if there is some way to determine when the CPU can actually start a aligned ST memory access by tapping into some other signal... If I could actually prove that is the problem, It at least it would be a step forward !

[ijor]

@ijor is there any signal I can tap into that you know of, which will determine if the MMU is doing a video or a CPU RAM access ?

Tap for checking with the scope, or to connect to the CPLD?

LOAD is asserted when MMU perform a video RAM access. RAM (from GLUE to MMU) is asserted when the CPU (or Blitter) is accessing RAM. But RAM is asserted during the whole bus cycle, including the video RAM access that it is interleaved by MMU. RDAT is asserted when the CPU (or Blitter) performs a RAM Read access. WDAT on a Write Ram access.

I have to go now. I will elaborate about the rest later.

[exxos]

Tap for checking with the scope, or to connect to the CPLD?

Both really.. but I don't think its that anymore now :roll:

its bizarre. even with clock switching.. if I keep 50mhz on for longer, like before or after a ST bus cycle, the scores drop.. the more 50mhz clocks.. the slower ths scores get.. It's baffling.

I have to sample DTACK at 120ns else it won't boot. The speed up STram, I would have to sample it earlier, but it just does not work. I can sometimes get away with 110ns to 130ns but that seems to be the window. Anything else and wont boot up.

I did think a few days ago that may be I'm sampling DTACK to late, but only because the next bus cycle gets trashed because to fast.. But I added all sorts of delays in everything and it made no difference in the end. If that was true I should be able to have sampled it earlier but it still didn't work.

Use the same DTACK sampling logic on the clock switching front and it did not make it slower or faster so the timing would appear to be correct. At least from what I have tested so far. But if the CPU is running constant 50 MHz I just end up with 92% STram speed. With clock switching its 116%. I'm specifically saying STram is faster, it could be just simply the GB6 loops are running faster, or more efficiently. But I don't really see how because TTram speed is always the same.

Even try disabling BUSRT on clock switching.. Make no difference.. cache off knocked off a few % as expected. But theres nothing else to turn off. Its still faster than constant 50mhz.

With clock switching and even 10ms to 30ns jitter on the 8mhz clock its still fine. But I guess the CPU running at 8mhz is "close enough" not to show up this slowdown issue. Probably found 100 different ways to make it run even slower but haven't yet figured out what the slowdown issue is. I can only really assume that it's just a fluke that the original CPU just happened to work slightly more efficiently than even the CPU running at 50 MHz :shrug: or I am completely missing a piece of the puzzle somewhere. But I think I just simply hit the limits of what this system is capable of now.

[ijor]

I have to sample DTACK at 120ns else it won't boot. The speed up STram, I would have to sample it earlier, but it just does not work. I can sometimes get away with 110ns to 130ns but that seems to be the window.

This is quite tricky. You are sampling a signal generated on the ST internal clock, it seems you delay it in using the 100 MHz clock, and finally it will be latched by the CPU at 50 MHz. You must be very careful.

Note that the timing is quite different when you consider a read access vs a write access. And of course, it depends if you are accessing RAM, ROM or I/O. Conceivable you could use different DTACK delays, but there is a risk of complicating things even more. Take in mind that just because it works in one machine, it doesn't mean it will work in every case. There are so many components that could alter the exact timing. This is one of the problems of working asynchronously.

But if the CPU is running constant 50 MHz I just end up with 92% STram speed.

This is conceivable, depending on how the phasing is aligned, an extra wait state could be generated. But it is very difficult to be sure what is really happening without seeing some logic analyzer traces ...

I am completely missing a piece of the puzzle somewhere.

I think this is the wrong approach. This is not really a "puzzle" that you have to solve using just cleverness. You have to use boring methodical debugging and analysis techniques. IMHO you have to perform timing analysis, simulations, take LA traces, etc. These all take time and preparation, and if you are not familiar with them, there is a learning curve. But, paraphrasing the Mandalorian, this the way ...

[exxos]

EXP4 firmware is out.

https://www.exxosforum.co.uk/atari/last/ST536/index.htm

The pull-up resistor on BGACK and 330R on the CPU clock are the main mods to do when flashing EXP4.

While there are a lot of mods it really depends on version board as there are rather a few out there now. The in-line resistor mods solve bad ringing on the signals. Generally these do not cause massive issues but can cause intermittent resets. So I suggest doing the basic stuff before getting more complicated. And please for the love of God don't try doing these delicate mods unless you are good at soldering and have a good magnifier ! Because if you screw it up the board is basically a brick !

EXP4 has been tested on my H5C1. DOTT, GB6, IDE, TT & STram tests all pass for ~24 hours constant run.

I'm not spending any more time on this project for the foreseeable future now. It's in the hands of the community if they purchase a board and help with testing from this point forward.

[olivier.jan]

Hopefully I will be testing next week, just received the resistors and waiting for the PGA socket to arrive any day now. So hopefully I will be able to test in H5 first and if successful in a Mega 4.

[exxos]

@PhilC's ST536 arrived yesterday. So had a quick look at it..

Long story short, it would not even try to boot up with the EXP4 firmware. The only change I made was removing the speed select register from a output pin to the CPU clock so I could monitor if the CPU clock was even running.. That change alone and it sprung into life and works fine now :shrug: I think the congested routing is the evil voodoo part in all this currently..

I was looking at the TTram score as it seemed to drop 1%to 827% .. also oddly the int-div seems lower.. but anyway..

IMG_4571.JPG

I added some clock switching filtering, now its back up to 828% but now other tests now running slower :pullhair:

IMG_4570.JPG

After some other tweaks..

IMG_4572.JPG

Now TTram is a alltime high at just a tick under 900% :WTF: I am not expecting this to be stable.. I need to run YAARTTT on that next.. though it has ran GB6 fully and ROM runs from TTram as well..

It seems part of the problems I have been having was because I had to redo the clock switching code which used a lot more registers, which made the design a lot more complicated, and the compiler had trouble fitting it all in.. So I did some optimisations there to reduce its FF count.. and that seems to have helped no end as well.

Capture.PNG

It seems once the macro cells usage gets above 820%, it really starts to struggle to fit everything in.

EDIT:

I think it's exactly the same problem that Microsoft Word has...

[Darklord]

Truth... :lol:

[exxos]

TF536

IMG_4579.JPG

IMG_4580.JPG

ST536

IMG_4581.JPG

IMG_4582.JPG

:shrug: Somebody translate for me ! :lol:

[exxos]

I've had the ST536 plugged into my H5 for a while now , while testing flashyclock etc.. But it seems to have developed a odd fault :roll:

Once it is powered up and running, it will work fine all day.. But then if I power off and power on again is very intermittent of it actually locks up just after it says checking ROM CRC. Other times it gets to ST & TTram tests and shows random corruption.

I reflowed the CPU socket and head pins and PLD. To no avail.

Even more bizarre is that if I run the ROM at 8mhz, it doesn't even try to boot up :WTF:

I tried some different firmware revisions and made no ones either. So not sure where this fault is coming from. I tried a normal 58K DIP CPU in the same socket and booted fine. I've tried putting pressure on various parts of the board but with it being intermittent it is difficult to tell if there is a bad connection somewhere or not.

:sigh:

Will do a quick video on this as its bonkers..