Flashy clock buyers interests

[ijor]

Also, but irrelevantly to what I said, clocking the SDRAM faster doesn't help at all with 68000. We don't have a burst mode or any kind of cache to fill!

What's the random column access time of an SDRAM chip at 133MHz versus my chip at 66MHz? I'll tell you: it's (virtually) the same.

Are you talking about latency, or about whole cycle time (tRC) ? That's two very different things. Latency in SDRAM is measured in cycles, not in time. So, for example, total latency from ACT command is 4 cycles. At 133 MHz that would be half the time than at 66 MHz (30ns vs 60ns). This is your critical timing since the CPU asserts AS until it latches the data bus.

Now, the command period (tRC) is 60ns in either case. That means you can't access two random locations at less than 60ns apart. So what? That's the time from one full 68K bus cycle to the next one, which takes 4 clock cycles. With a CPU clocked at 32 MHz it's 125 ns. So this timing is not really critical. Even with the CPU at 64 MHz, it is still ok.

I've said with ANY RAM, because of the way the 68k latches data after DTACK, there will come a point where you either have to optimise for a clock speed or accept you will never achieve your theoretical ram speed. SDRAM, SRAM, DRAM, manually assembled banks of flip flops.

Ah, you are saying that some RAM speed always goes to waste? (sorry for the misunderstanding) Yes, of course, well, unless you can use the RAM concurrently for something else. Not sure why you would care as long as it doesn't affect price significantly?

[Badwolf]

Are you talking about latency, or about whole cycle time (tRC) ?

I wasn't talking about either. It was you who suggested clocking faster would help -- this aside was pointing out it won't. Firstly because the effective speed of the memory only changes when the inefficacy becomes apparent (my actual point) and secondly because 66MHz matches tRCD, which is the limiting factor for back-to-back commands.

Ah, you are saying that some RAM speed always goes to waste? (sorry for the misunderstanding) Yes, of course, well, unless you can use the RAM concurrently for something else. Not sure why you would care as long as it doesn't affect price significantly?

Yes, exactly. And not just the (at least) 50% of the time the processor isn't in a bus cycle.

In short, if you want to maximise the efficiency of the memory operations you need to assert DTACK before the data is ready so that the CPU latches just as it becomes stable. Which means you need to know the frequency in advance (optimise for it) or be able to 'sniff' the CPU clock somehow.

But you're correct that it becomes purely academic as effective memory speed increases.

But @exxos, I'm sorry. This is absolutely ripe for one of these:-

Feel free to siphon this off to 'RAM Access Nerdery' or similar

BW

[ijor]

I wasn't talking about either. It was you who suggested clocking faster would help -- this aside was pointing out it won't. Firstly because the effective speed of the memory only changes when the inefficacy becomes apparent (my actual point) and secondly because 66MHz matches tRCD, which is the limiting factor for back-to-back commands.

No, this is not the limiting factor. The limiting factor is the latency. If the CPU is running at 16 MHz there is no problem. You can satisfy both timings (latency and cycle time) by clocking the SDRAM at 66 MHz. But when you start increasing the CPU speed, at certain point, you can't. If you speed up the CPU to say, 32 MHz, the tRC requirement is still fine, but the SDRAM latency at 66 MHz will kill you.

With a CPU clocked at 32 MHz, you have only ~78ns from AS (two and a half cycles). Subtract to this all the analog delays and you have less than 60ns. You can't make this with the SDRAM at 66 MHz and four cycles latency. You need to clock the SDRAM faster. The total cycle time (tRC) becomes a limiting factor only with a CPU at 64 MHz or faster.

This is why I was suggested increasing the SDRAM clock. You can double the CPU speed, probably even more than double, and still use the same cheap SDRAM.

But @exxos, I'm sorry. This is absolutely ripe for one of these:-
Feel free to siphon this off to 'RAM Access Nerdery' or similar

Yep, sorry about that. But to be honest, exxos started going (a bit) off topic himself

[Badwolf]

With a CPU clocked at 32 MHz, you have only ~78ns from AS (two and a half cycles). Subtract to this all the analog delays and you have less than 60ns. You can't make this with the SDRAM at 66 MHz and four cycles latency. You need to clock the SDRAM faster. The total cycle time (tRC) becomes a limiting factor only with a CPU at 64 MHz or faster.

Aha, wait -- I think I see what you're saying!

I've not really been worried about tRC -- I considered that simply falling out of tRCD being 15ns, but I think I get your point now. tRCD must be 15ns, but the two cycles after CMD_READ can be 7.5ns -- meaning overall the time from CMD_ACTIVE to data valid is shorter!

OK, yes, sorry. You're quite right. I hadn't taken that into account.

BW

[CeRiAl]

...
You guys are in the interested list. But I have not got documented if you want board with or without alt-ram. I am basically assuming people want the RAM as well. The RAM will add about £40 onto the cost. I need to add up all the parts for the actual " baseline" version yet. Probably be somewhere around the £70 mark but it's only a guess currently.

Of course if anyone got bored of waiting, or to expensive or does not want it any more etc, then let me know and I will remove you from the list.

I'd be still interested in the Flashy Clock, as my H5C1 build is finished (and I'm really happy with it! ).
I didn't update the thread about my build for quite a time, because I got distracted with real life, but I will do this soon, with some more photos and what I added to this beautiful thing - it's quite complete now (UltraSATAN internal, Roland RA-50 connected to MIDI - which is fully MT-32 compatible, etc.)!
I've played through quite a few games now since I finished it: practically all Sierra-SCI Games which support MT-32, like Space Quest 3, King's Quest, Leisure Suit Larry 2 & 3 - also Zak McKracken and I've tested some very special things like Monkey Island 1 and Monkey Island 2 (both the VGA-versions!), as well as Day of the Tentacle and Indiana Jones 4 (all possible with the ScummST-Port). I think it shows that I'm a big adventure-game enthusiast, and a former ScummVM-Developer

Hardware-wise, I've started a small side-project which turned out very well:
External HD-Floppy-Drive which can be used on both Amiga and Atari-ST: I made an adapter cable for this (DB23 to Atari-DIN-Floppy), to be able to use my internal original "big eject button" drive, and the Sony-HD-Floppy in an external brand-new Amiga-Floppy casing. As I also own an Amiga 1200, my idea was to make it multi-usable - which worked really nicely. It doesn't contain the needed mods for Amiga HD-usage yet, though.

So, back to the topic: I'd take a Flashy-Clock variant with RAM.

[Elethiomel]

Count me in too

[DoG]

with alt-ram thx.

[Steve]

@exxos Do you offer a kit version as well?

[exxos]

@exxos Do you offer a kit version as well?

It's unlikely to happen. It creates a lot of work to do variations on things, time, ordering parts, bagging them up, buying parts twice, writing guides etc etc. Ironically I should be charging more for kits because of the extra work involved. Main problem is you need the proper Atmel programmer and almost nobody has one.

[exxos]

I didn't update the thread about my build for quite a time, because I got distracted with real life, but I will do this soon, with some more photos and what I added to this beautiful thing - it's quite complete now (UltraSATAN internal, Roland RA-50 connected to MIDI - which is fully MT-32 compatible, etc.)!

That is great! I don't think anyone has used the internal US port yet. Look forward to your blog updates