Slow DSP investigation with DFB1

[pakman]

Holger, @pakman (pakman with a K not a C)

And by the way "Parkman" is also wrong..
(Maybe I should better change my name to PAKman, since it refers to the PAK68/3 published in the german ct magazine back in 1994).

We can ask for permission to ship programmed gals with DFB1Xs, but I've not heard back from him for a long time. I hope he's OK.

Permission granted!

[viking272]

Permission granted!

Amazing, thank you!

[exxos]

Permission granted!

[viking272]

Its not on sale on my store.. Partly because I can't find any GALs. I've got the Atmel ones in my mouser basket but i had given up trying to program them as the power down pin was always enabled. But I've got a different programmer now. So worth another try.

Hi @exxos
Did you manage to test your different programmer?
Just wondering if it got around the power down pin issue?
Is the u68 GAL socketed or a solder job?

[exxos]

Did you manage to test your different programmer?
Just wondering if it got around the power down pin issue

I haven't got any chips to test yet.. They are in my mouser basket but I'm not ready to do the order yet

[charon030]

Nembench results when accessing ST RAM (MByte/s):

Code: Select all

  ┌───────────────────────────────────┬────────┬────────┬──────┐
  │               Test                │ DFB1X  │  CT2   │  Δ   │                                                                                                                        
  ├───────────────────────────────────┼────────┼────────┼──────┤
  │ Linear 32bit read ST-RAM          │  5.297 │ 10.240 │ +93% │
  ├───────────────────────────────────┼────────┼────────┼──────┤
  │ Linear 32bit write ST-RAM         │  6.406 │ 11.477 │ +79% │
  ├───────────────────────────────────┼────────┼────────┼──────┤
  │ Linear 32bit copy ST-RAM          │  3.209 │  5.738 │ +79% │
  ├───────────────────────────────────┼────────┼────────┼──────┤
  │ Linear 16bit read ST-RAM          │  4.890 │  9.256 │ +89% │
  ├───────────────────────────────────┼────────┼────────┼──────┤
  │ Linear 16bit write ST-RAM         │  5.779 │ 11.497 │ +99% │
  ├───────────────────────────────────┼────────┼────────┼──────┤
  │ Linear 16bit copy ST-RAM          │  2.066 │  3.828 │ +85% │
  ├───────────────────────────────────┼────────┼────────┼──────┤
  │ Linear 8bit read ST-RAM           │  4.190 │  6.660 │ +59% │
  ├───────────────────────────────────┼────────┼────────┼──────┤
  │ Linear 8bit write ST-RAM          │  2.894 │  5.748 │ +99% │
  ├───────────────────────────────────┼────────┼────────┼──────┤
  │ Linear 8bit copy ST-RAM           │  1.034 │  1.914 │ +85% │

TL;DR version:
- ST-RAM: about 1.6x - 2.0x faster on CT2

I wonder whether the faster ST-RAM accesses are only related to bus-overclocking.
At least for the CT60, Rodolphe emphasized that the ST-RAM write accesses are carried out in 3 instead of 4 clock cycles. https://mikrosk.github.io/ct60tos/ct60/ ... hs_eng.htm
Maybe that trick was already done on the CT2? Or maybe the CT2 did not toggle the CPU clock between 50 MHz and 16 MHz for ST-RAM accesses but sampled the Falcon bus at 50 MHz?

[mikro]

I wonder whether the faster ST-RAM accesses are only related to bus-overclocking.

I'm almost sure that this isn't the case. Of course it helps but it isn't the whole story. I have got another Falcon with a Phantom@25 MHz so if I find time to switch the setups (I've got other things to try there, too) I can re-measure this again. I'll make a TODO note.

[Badwolf]

I wonder whether the faster ST-RAM accesses are only related to bus-overclocking.

I'm almost sure that this isn't the case. Of course it helps but it isn't the whole story. I have got another Falcon with a Phantom@25 MHz so if I find time to switch the setups (I've got other things to try there, too) I can re-measure this again. I'll make a TODO note.

I hadn't quite clocked those were Nembench results so kind of missed them.

ST-RAM runs at a fixed speed with a proportion of it being used for video memory so assuming the same screen resolution was used between tests then I'd only expect a percent or two difference here or there as the instructions to carry out the tests are read and executed faster (if the instructions all fit in the cache then even even less).

*Unless*, for example, the bus runs faster (faster ST-RAM is kind of the point of that) or the CPU's spending more time executing from its cache at 50MHz.

My suspicion is that both these things are true here. I don't know much about the architecture of CT2, but I suspect it's not switching down (that's the elegant way to do things after all), meaning any cached instructions run faster.

If NEMBENCH is clever and is able to block all that out (I'm sure it's clever enough, I'm not sure if it's part of the design to do so or whether the effects of cache are what it's interested in), then the chances are you're seeing the effects of the bus speeder. 25MHz vs 16MHz is +160%.

CT2 (ignoring any bus speeding) is faster than DFB1. Known and accepted. It takes direct control of the bus rather than going through the bus arbitration dance and doing the whole 'pretending to be a 68000' thing.

BW