exxos's Atari, Amiga & retro forum

exxos wrote: ↑Wed Jan 08, 2020 9:37 pm Measuring /AS(top) vs /WDAT(bottom) there is ~100ns delay between the 2.

I do not get why that delay is even there in the first place.. In terms of writing to RAM, it would mean the DRAM would not get the data from the CPU until 100ns later ( plus the delay of the LS244 buffers).

So I swapped out the 120ns DRAMs for 100ns ones to make things easier..

This benchmark is basically the original (baseline test)


This benchmark is with a separate delay on ST_RAM WRITE DTACK. basically 4x 50MHz clocks ~ 80ns.

Now if we assume 20ns delay on the LS244 ( will likely be a bit quicker but I am building in some margin of error into this figure anyway) we end up with 100ns! if I take away 20 ns, the machine just turned into a crash generator, because basically it is running the RAM at 80ns.

Basically mean, assuming a delay of 100ns on the MMU, plus 20 on the buffers (120ns) and a 8MHz cycle time of 250ns, this means the DRAM would have to be (250ns - 120ns) 130ns or faster. Now I have seen 150ns chips so likely it's doable. Basically the figures do generally work out as expected. I would assume RAM slower than 150 ns was never fitted in the ST range ?

So what the heck is this all about ? basically I am trying to speed up RAM access without overclocking the MMU. In terms of Write cycles, the CPU databus simply goes through the LS244 buffers to the DRAM, MMU really does not have anything to do with speed at that point.

The above benchmarks may not look very interesting, but it proves the point that ram access does appear to be speeding up.. The RAM speed test would likely show any speed improvement until we hit double speed of 200%. This is basically because we cannot fit 2 RAM accesses in the same time frame unless the RAM is running at 200% speeds. So what I assume is happening is that the RAM cycle completes slightly early, and it is able to start a ROM cycle sooner, which is slightly increasing the scores in the benchmarks.

The problem is this odd 100ns delay. Because the MMU is controlling who has access to RAM, we cannot simply bypass it, as it may actually need to be there at some point because of shifter accesses to RAM.So it looks like I may have hit a brick wall with this direction

EDIT:
Part of the delay on write might be down to the delayed RW on the 68000 itself.. so need to look into that timing as well ...

EDIT2:
I also tried speeding up the RAM READ, ended up as 7 clocks delay ( 120ns). Most scores went up about 2%. Int-div was the largest one which jumped to 512% from 506%.

I thought I would do some tracing on the clocks vs WDAT and RDAT vs the 2MHz clock..

So I guess this explains some things..


WDAT / RDAT are in sync with the 2MHz clock. Which must be the clock used to determine if the CPU gets RAM time or not. But because of all the wakeupstates, I think this is throwing things out all over the place.

The CPU will set /AS low and request RAM, but its gotta wait for the 2MHz clock, which can't really be in sync with the 8MHz clock I guess I could generate a new 2MHz clock, but likely that would knock onto screwing something else up anyway. The only other possible thought would be to bypass the MMU's buffer control lines and re-generate them in the PLD instead

EDIT:
So my brain has gone to sleep I think. The CPU can set /AS low at any point in the 2MHz cycle, basically random. And the MMU is not going to give access to RAM until the 2 MHz signal goes high. As soon as it does go high, the MMU enables the buffers, so basically we might as well say no delays there other than the buffer itself and DRAM speed.

So with 2MHz cycle time being 500ns. Thats 250ns HI & 250ns low. CPU at 8MHz has a cycle time of 250ns, so it can *just* do a RAM access in that time slot. In theory, 100ns RAM with a CPU running 50Mhz, it should already be accessing RAM at double speed at least. As 100ns x 2 = 200ns, and we have a 250ns "window" to access RAM. So why is RAM access not behaving ?

EDIT2:

Currently I have on RAM delays with 100ns RAM:
READ: 7 x 20ns = 140ns
WRITE: 4x20ns = 80ns

I tested 2MHz vs WDAT and only see it going low once This is with a 7 clocks elay (140ns) on both read and write.

I even checked RDAT , still 156ns cycle time. I don't see RDAT follow immediately after WDAT either. Really its about 31ns to slow. So 100ns - 31 = 69ns (or 70ns RAM speed) to get the cycle to fit it seems Even so, whats stopping the next RAM cycle from starting anyway

EDIT3:
I put back 80ns WRITE time, and the scope shows 120ns now. oddly RDAT now reads 200ns.

I've been thinking its likely the DRAM RAS/CAS which are likely in a internal state machine in the MMU causing trouble. I was reading through this document about the DRAM operation https://compas.cs.stonybrook.edu/~nhona ... dramop.pdf Where basically the address line inputs to the RAM seem to be multiplexed based on RAS & CAS. These timings will be hardwired into the MMU. So even though the buffers and CPU can run at much higher speeds, the MMU is simply not going to access the data on the RAM any faster without overclocking the MMU itself.

The only possible workaround would be to use SRAM. This would also entail building new logic to control the buffers. Scoping out some signals on the MMU, it seems that the /DEV pin is active when accessing the floppy, and /RAM is active when accessing the RAM, and I would assume /DMA is active when accessing bus masters such as the blitter. However I don't actually understand why there is even three signals for this as an signal would surely be enough to determine if the shifter is accessing the bus, or everything else such as CPU, or blitter. Though as the MMU is also controlling RAM for video, however it is translating counters to a RAM address would likely be working against me in trying to just have a simple SRAM and setup

So we are basically back to building a new MMU in order to speed up RAM access,But with no solid diagram to even work from it is just a dead end I was looking for alternative ways of speeding up RAM instead of overclocking the MMU as it has various issues with wakeup states interfering with various timings. Though it seems the over clock is probably the only alternative to trying to build a new MMU

EDIT:

I think trying the suska MMU core is the next step. if it works "out of the box" Should allow is to increase ram speed a lot easier.

Crappy video of the first test run of software switching on the SEC booster

After switching several times the machine locks up, but at least the concept is working so far





..And yes I used flashy clock software to control the SEC booster as to lazy to start a new app


EDIT:

Clock switching is a lot better now. Simulation shows this... I can't get my scope to lock onto anything but the 50mhz to 8mhz cycle

Its like the SEC Booster and H4 were designed to be together

Icky wrote: ↑Sat Jan 11, 2020 2:25 pm Its like the SEC Booster and H4 were designed to be together

Almost

Now that looks good to me.

Is that the correct socket to put it in or can it go into any of them?

PhilC wrote: ↑Sat Jan 11, 2020 3:08 pm Now that looks good to me.

Is that the correct socket to put it in or can it go into any of them?

It can go in any of them. Just remember to take out the PLCC CPU

@Icky Reported ultrasatan isn't working with the SEC booster. I know this *was* working. So I tried the newer metal boxed US and the machine didn't reset. With the older plastic box one, the machine reset and even loaded the drivers, but each drive access the screen went grey. There seems to be more of a problem with TOS206 than 104, so I need to look into all this next as it was working last time I tried it all..

Same firmware in both?