Q: ZX8301 effect on memory bandwidth?

[ppe]

Hi there,

having read this article I got curious about the effect of ZX8301 on memory access latency. As background for discussion, consider replacing (in a special case where the result is known to fit in a word):

Code: Select all

         mulu #10,d0

with

Code: Select all

         move.w   d0,d1
         asl.w    #3,d0
         add.w    d1,d0
         add.w    d1,d0

My assembly language skills are not that great so this might be a bit contrived example, sorry about that but I wanted to bring up the point of clock periods vs number of memory accesses. In this case, if I read the 68000 family user manual correct, with an 8-bit bus the cost of these instructions is as follows. The former is 54 clock cycles and a total of 4 memory read cycles. The latter is 40 clock cycles and a total of 8 memory read cycles. Which one is faster? I'd assume that the latter implementation is faster... but what if memory read cycles take longer (more clocks) than on paper in the CPU manual? Worst case scenario is that one might end up in a situation where the 8 reads vs 4 reads from memory override the benefit of 40 clocks vs 54 clocks.

I tried searching the forums and among Nasta's fabulous articles on the inner workings of the QL there are several clues that while the ZX8301 reads video RAM it makes the cpu wait. This seems to be the case on other machines as well. From the article quoted above:

For instance, the Macintosh's 68000 runs at 7.8 MHz, but it can't always operate at this speed because the screen is memory-mapped and "steals" some memory cycles. Thus, the effective speed of the Macintosh is about 6 MHz, but only memory cycles are slowed down -- CPU cycles are unaffected.

Does anyone know what the total "average" slowdown effect of this mechanism for memory accesses is on the QL?

Kind regards,
Petri

[tofro]

Petri,

you can easily test that yourself:

Run the same program with the unexpanded QL and it will suffer "memory contention".

Run the same program on an expanded (with "external" memory) QL and it will (most probably) not.

Digital Precision have done some comparisons like that way back in the past and documented the results in the Turbo Manual:

Code: Select all

Timing (S) Expansion system
 -----------------------------------------
33            Standard 128K QL
32.5         QUANTA 512K DIY project
27            Simplex Data 512K (1986)
22            Miracle Expanderam 256K
22            PCML 256K
22            MEDIC 512K
22            Inpho-link 512K (internal) 
22            Italiana 512K (internal)
19            Miracle Expanderam 512K
19            Sandy SuperQboard V 1.17
17.3         Simplex Data 256K (1985)
17.3         CST RAM Plus 512K
17            CST THOR 512K internal board
17            The same program in EPROM

As you can see, running in uncontended memory can make a program nearly twice as fast.
What you can also see is that internal expansions are way slower than external ones and that there is quite a bit of difference between expansions of different make.
Regards,
Tobias

[tofro]

And just for the sake of completeness:

Code: Select all

Timing (S) Expansion system
 -----------------------------------------
0            QPC2 v4.01 on Apple MacBook

Tobias

[ppe]

Hi Tobias,

many thanks, those are very interesting benchmarks! It's quite surprising that the differences are so big. I don't yet understand exactly happens on the bus and control lines - which memory accesses are slowed down by ZX8301 and exactly when. I had the (obviously wrong!) impression that the ZX8301 would need to access the video ram at a fixed rate hence slowing down the average memory access latency uniformly regardless of total memory size. I.e. every x nanoseconds the ZX8301 needs to fetch data from video ram and while it's doing that the cpu will not be able to access ram at all. There is obviously some trickery here that I need to study more closely to understand. It seems that (among many other things) the mechanics of how the ULA reads the video memory are not clear to me

Petri

[1024MAK]

The display system of the QL only "halts" the CPU when the ZX8301 needs to fetch display data (from the on board RAM) and the CPU is trying to read or write to the on board original RAM.

The display system does not affect CPU memory accesses to the ROMs or any additional RAM (plug in expansion RAM).

Mark

[ppe]

The display system of the QL only "halts" the CPU when the ZX8301 needs to fetch display data (from the on board RAM) and the CPU is trying to read or write to the on board original RAM.

Thank you Mark, that makes sense! In other words, parallel memory access can happen when ZX8301 is reading video ram and at the same time the cpu is accessing expansion ram. Looking at the circuit diagram, and with Tobias' and your help, the pieces of the puzzle start to fall in place...

[1024MAK]

Yes

The data bus has a 74LS245 (IC21) bi-directional buffer chip that separates the section for the on-board RAM from the rest of the data bus (which connects to the CPU, the ROM and the expansion connector).

Mark

[ppe]

The data bus has a 74LS245 (IC21) bi-directional buffer chip

Interestingly enough, at least in my copy of the service manual, IC21 seems to be mislabeled on the circuit diagram as 74LS257. The parts list correctly states that it is a 74LS245.

[Dave]

Could you post the code that was used and the circumstances under which it was executed? That way, I can post benchmarks for GC, SGC, and my expansions as they get further along in development.

I'm also very curious as to the differences between the various brands of expansion that affected their speeds, considering they all worked in the same basic way.

I am happy the Sandy card gave a good showing. Hats off to the CST folks though!

[tofro]

Dave,

the code is printed in the Turbo Manual
http://www.dilwyn.me.uk/docs/ebooks/QL% ... oodwin.pdf
relatively close to the end (search for "Memory Speed Test).
It's only 5 lines of Basic(that actually contain a machine code program and a bug )

Corrected version here:

Code: Select all

100 ram=RESPR(16): RESTORE 140
110 FOR p=ram TO ram+14 STEP 2: READ x: POKE_W p,x 
125 t=DATE: CALL ram
130 PRINT "Test complete in ";DATE-t;" seconds."
140 DATA 28771,29439,20937,-2,20936,-8,28672,20085

Tobias