68k details

[Bruce Abbott]

Originally Posted by plasmab

With a bit of digging i found that the BBC B (designed in 1981) had these guys in them ...

https://pdf1.alldatasheet.com/datash...M4164B-10.html

They are 100ns and BBC almost maxed the ram out by having the CPU use the ram on one half of the clock and the VIDPROC use it on the other. It was a 2Mhz clock...

At the time it was cutting edge technology...

BBC Micro

To use the CPU at full speed (2 MHz) required the memory system to be capable of performing four million access cycles per second. Hitachi was the only company, at the time, that made a DRAM that went that fast. So for the prototype the only four 4816s in the country got hand-carried by the rep.

And yet the BBC micro had sucky graphics, wasting half the colors and using too much precious RAM. Then they totally borked it on the Electron by only having a 4 bit data bus!

Another thing to consider is that 'working the RAM twice as fast' probably means tighter timing constraints and less flexibility. Would the Amiga's Blitter and Copper have worked reliably with the bus running as fast as possible? Probably not, or at least not without a more complex design (read too expensive and too late to capture the market). In practice despite the 'inefficiency' of not pushing its DRAM to the max, the Amiga still runs rings around the BBC.

[grond]

What should the 68000 have achieved with a faster mem interface? The 68000 is fully synchronous. If the mem interface had been twice as fast, the CPU would have had to be clocked at 16 MHz which was simply impossible at the time. It's not like the ALU is starved by slow mem. The fact that the 68000 does not access the RAM faster but never idles already proves this. Caches to decouple a fast CPU core from slow mem were simply impossible in 1979. And in the case of the 68000 we have a slow CPU with fast RAM. There simply was no bottleneck. The memory interface is fast enough for the CPU. It might be worth looking at the 68008 which according to your theory should have been able to be just as fast as the 68000 at half the buswidth (and failed at that).

[plasmab]

Originally Posted by roondar

According to the datasheet, that chip does 4 bits per access. Which should mean that 16 bits require four accesses. That would result in these chips (running at 70ns) delivering 16 bits in 280ns.

This number happens to fit almost exactly with the Chip RAM bus speed on the Amiga, which just so happens to be one 16 bits access per 280(ish) ns. In case you wonder why that number isn't 560ns, well the Blitter/Video Chip/etc can all access the bus at a rate of 280ns/16 bits.

In all honesty these results don't surprise me much, I had kind of figured that the 70ns number was probably true, but not telling the whole story. And the data sheet confirms this.

This demonstrates a serious lack of any kind of understanding. Sure the chip is 4 bit. You just use 4 of them in parallel. Which is what the Amiga does. I’m not even responding after this because you are trolling for the sake of it.

BBC Micro: 500/2 = 250ns per RAM access
Amiga: 560/2 = 280ns per RAM access*

'Working RAM twice as hard'. Right.

*) The Amiga/Atari ST have video chips too. The 68000 only accesses memory during half of the 560ns period...

Again wrong. The 68000 (at 7mhz) takes 560ns to fetch and then another 560ns to execute. The chipset gets the second 560ns. Odd vs even cycles.

It’s in the Amiga manual and it’s also something I’ve measured. The Amiga doesn’t do 2 access per timing slot. Only one. Hey why don’t we ask someone who builds accelerators for the Amiga..

http://amigadev.elowar.com/read/ADCD.../node02D4.html

I can stick all these machines on my LA and do a video of this actually. I’m getting sick of arguing about fact here.

Originally Posted by Bruce Abbott

At the time it was cutting edge technology...

BBC MicroAnd yet the BBC micro had sucky graphics, wasting half the colors and using too much precious RAM. Then they totally borked it on the Electron by only having a 4 bit data bus!

I dont really use machines. I just see how fast I can make them sweat.

Another thing to consider is that 'working the RAM twice as fast' probably means tighter timing constraints and less flexibility. Would the Amiga's Blitter and Copper have worked reliably with the bus running as fast as possible? Probably not, or at least not without a more complex design (read too expensive and too late to capture the market). In practice despite the 'inefficiency' of not pushing its DRAM to the max, the Amiga still runs rings around the BBC.

Yes this would have been fine but a genuine consideration. But you need to have looked at the timing diagrams. Some people on this forum are keen to point out that they've disassembled megabytes of 68000 code etc. I've generated hundreds of thousands of timing diagrams and measured these buses with 96 Channel Logic analysers. I've implemented 68000/6502 and ARM based computers inside FPGAs. Designed and built Amiga 020/030 accelerators and written the code to marshall this onto the old 68000 bus. I've also generated ~200 hours of videos on the subject.

[ross]

Originally Posted by plasmab

Again wrong. The 68000 (at 7mhz) takes 560ns to fetch and then another 560ns to execute. The chipset gets the second 560ns. Odd vs even cycles.

You have doubled the times here

The unified internal bus is at 280 ns, interleaved between CPU and chipset.

[plasmab]

Originally Posted by ross

You have doubled the times here

The unified internal bus is at 280 ns, interleaved between CPU and chipset.

Not seeing that on the scope but I will measure again later.

[meynaf]

The bus is 280ns, but the 68000 probably just takes 2 clocks to fetch (that's indeed 560ns), and then 2 clocks to execute.

[plasmab]

Originally Posted by meynaf

The bus is 280ns, but the 68000 probably just takes 2 clocks to fetch (that's indeed 560ns), and then 2 clocks to execute.

Does it manage most instruction executes in 2 clocks? (ignore cases where it needs to write back to memory). Also ignore ALU things like shifts.

Also is there no decode stage? Later CPUs took a clock cycle to decode.

EDIT: For the record i think the Amiga designers got the best out of what they were working with. My beef is with the CPU bus interface. It could have been 2 x as fast without any fuss whatsoever.

[ross]

Originally Posted by plasmab

Not seeing that on the scope but I will measure again later.

Is simple math: take a PAL hline of 64us.
The chipset split-up this time in 227 C2 slots (280ns each one) for a total raw of 908 (227x4) potential hres pixels (these are not all visible but this is another matter).
So you need 4 pixels issued every 280ns for a resolution of 640+overscan pixels.
But if you want more colours you need to fetch more planes.
This is maxed out at 16 colours (the famous 4planesx640x256 resolution).
With this you saturate the time usable by the chipset on the bus.
4 planes x 4 pixels are 16 bits to fetch in 280ns

[EDIT: Of course if the chipset saturate the bus, there is no time for the 68k to fetch instructions..
but if you use half of previous values (4planex320x256 resolution) you can have maximum for both contender]

Or look at it another way: an instruction for 68k requires 4 minimum cycles to execute.
At 7Mz 1 cycle lasts 140ns, of which 2 occupying the bus (280ns) for the fetch and the others 2 for internal operation.

[roondar]

Originally Posted by plasmab

This demonstrates a serious lack of any kind of understanding. Sure the chip is 4 bit. You just use 4 of them in parallel. Which is what the Amiga does. I’m not even responding after this because you are trolling for the sake of it.

I stand corrected on this issue, but I didn’t say this to troll you, I said this, because I also read the HRM. And the HRM does say exactly how long a memory access cycle is, and it really does say 280ns (I’ll show the quote below) - which I then erroneously divided by 70ns to get to the 4 bits.

It just seemed to fit, that is all.

I’m truly sorry if you feel I was/am trolling, this is seriously not my intent. Even though I do lack knowledge of memory chips, as you point out.

Again wrong. The 68000 (at 7mhz) takes 560ns to fetch and then another 560ns to execute. The chipset gets the second 560ns. Odd vs even cycles.

It’s in the Amiga manual and it’s also something I’ve measured. The Amiga doesn’t do 2 access per timing slot. Only one. Hey why don’t we ask someone who builds accelerators for the Amiga..

http://amigadev.elowar.com/read/ADCD.../node02D4.html

I can stick all these machines on my LA and do a video of this actually. I’m getting sick of arguing about fact here.

I am very sorry, but that is just not correct. The Amiga has 227,5 memory accesses per 63 microseconds. The HRM explains this here: http://amigadev.elowar.com/read/ADCD.../node012B.html

Originally Posted by Amiga HRM

During a horizontal scan line (about 63 microseconds), there are 227.5
"color clocks", or memory access cycles. A memory cycle is approximately
280 ns in duration. The total of 227.5 cycles per horizontal line
includes both display time and non-display time. Of this total time, 226
cycles are available to be allocated to the various devices that need
memory access.

This is where I got the 280ns figure from. It fits the math as well, 63ms/227,5=276ns.

The image you’ve shared actually confirms this as it runs from 0 to $E0, which is 224, but the 0th cycle is shown to start after a memory refresh cycle so the total there is 226.

Again, I’m sorry you considered my lack of knowledge on RAM chips to be trolling you, this was not my intent. I admit I don’t know much about them, but I do know a little bit about the Amiga architecture, though admittedly primarily from a programmers perspective.

[plasmab]

Originally Posted by ross

Is simple math: take a PAL hline of 64us.
The chipset split-up this time in 227 C2 slots (280ns each one) for a total raw of 908 (227x4) potential hres pixels (these are not all visible but this is another matter).
So you need 4 pixels issued every 280ns for a resolution of 640+overscan pixels.
But if you want more colours you need to fetch more planes.
This is maxed out at 16 colours (the famous 4planesx640x256 resolution).
With this you saturate the time usable by the chipset on the bus.
4 planes x 4 pixels are 16 bits to fetch in 280ns

Or look at it another way: an instruction for 68k requires 4 minimum cycles to execute.
At 7Mz 1 cycle lasts 140ns, of which 2 occupying the bus (280ns) for the fetch and the others 2 for internal operation.

Its 4 cycles for a CPU fetch. Then the CPU has to execute. The CPU isnt pipelined so it doesnt fetch while executing unfortunately. So probably 6 (i thought 8 actually) is the minimum clock cycles per instruction. It probably ends up being 8 because it cant fetch again until 2 cycles later.

[plasmab]

Originally Posted by roondar

I stand corrected on this issue, but I didn’t say this to troll you, I said this, because I also read the HRM. And the HRM does say exactly how long a memory access cycle is, and it really does say 280ns (I’ll show the quote below) - which I then erroneously divided by 70ns to get to the 4 bits.

It just seemed to fit, that is all.

I’m truly sorry if you feel I was/am trolling, this is seriously not my intent. Even though I do lack knowledge of memory chips, as you point out.



I am very sorry, but that is just not correct. The Amiga has 227,5 memory accesses per 63 microseconds. The HRM explains this here: http://amigadev.elowar.com/read/ADCD.../node012B.html



This is where I got the 280ns figure from. It fits the math as well, 63ms/227,5=276ns.

The image you’ve shared actually confirms this as it runs from 0 to $E0, which is 224, but the 0th cycle is shown to start after a memory refresh cycle so the total there is 226.

Again, I’m sorry you considered my lack of knowledge on RAM chips to be trolling you, this was not my intent. I admit I don’t know much about them, but I do know a little bit about the Amiga architecture, though admittedly primarily from a programmers perspective.

Apology accepted. However I intend to measure this for my own sanity. I have seen the CPUs regularly skip cycles because the motherboard didnt give it DTACK. Either its a resync operation or im going mad.

[meynaf]

Originally Posted by plasmab

Does it manage most instruction executes in 2 clocks? (ignore cases where it needs to write back to memory). Also ignore ALU things like shifts.

Also is there no decode stage? Later CPUs took a clock cycle to decode.

I don't know much on the inner workings of the cpu. What i know is that the fastest instruction is 4 cycles on 68000, and that the chipmem bus is available 1 cycle out of 2 at 3.5Mhz.

[roondar]

Originally Posted by plasmab

Its 4 cycles for a CPU fetch. Then the CPU has to execute. The CPU isnt pipelined so it doesnt fetch while executing unfortunately. So probably 6 (i thought 8 actually) is the minimum clock cycles per instruction. It probably ends up being 8 because it cant fetch again until 2 cycles later.

I’m sorry, but that is not correct. As you can see on the subpages of this site (http://oldwww.nvg.ntnu.no/amiga/MC68...000timing.HTML), the minimum is actually 4 cycles for a instruction altogether.

For example, move.w dn,dn takes 4 cycles, as does tst dn or addq #,dn.

[ross]

Originally Posted by meynaf

The bus is 280ns, but the 68000 probably just takes 2 clocks to fetch (that's indeed 560ns), and then 2 clocks to execute.

Right, but 2 clocks are 280ns

[ross]

Originally Posted by plasmab

Its 4 cycles for a CPU fetch. Then the CPU has to execute. The CPU isnt pipelined so it doesnt fetch while executing unfortunately. So probably 6 (i thought 8 actually) is the minimum clock cycles per instruction. It probably ends up being 8 because it cant fetch again until 2 cycles later.

You are wrong, but I will not question more about the thing.
Mathematics and logic can not be refuted

[plasmab]

Originally Posted by roondar

I’m sorry, but that is not correct. As you can see on the subpages of this site (http://oldwww.nvg.ntnu.no/amiga/MC68...000timing.HTML), the minimum is actually 4 cycles for a instruction altogether.

For example, move.w dn,dn takes 4 cycles, as does tst dn or addq #,dn.

Not disputing here but this is odd. How a CPU (at least pre 1990) works is usually FETCH->DECODE->EXECUTE.

Now some CPUS (take arm as an example) pipeline...

CYCLE
1 FETCH1
2 FETCH2 DECODE1
3 FETCH3 DECODE2 EXECUTE3

However the 68000 doesnt do this. And we know it takes 4 clocks to do Fetch.

So i am simply confused about the decode/execute part.

[meynaf]

Originally Posted by ross

Right, but 2 clocks are 280ns

Oops Seems i need to really wake up this morning

So what happens ?
It may need 2 clocks to fetch. That's 2x140ns.
Then 2 clocks to execute simple ALU ops. Again 2x140ns.
Total 4 clocks for e.g. simple 16-bit ADD.
And it can do 1 mem access every 4x140ns, meaning min 4 clocks per code word and per data word.
Am I right ? Probably not

But why would i care anyway, not being coding for 68000 anymore ?
68030 timings might be more interesting to study (at least for me).

[plasmab]

Originally Posted by ross

Right, but 2 clocks are 280ns

The plain 68000 needs 4 clocks to fetch. Says so in the manual. It spends S0/S1 asleep doing nothing. Asserts AS in S2.. and samples DTACK in S5 before latching the data in S7.

EDIT: It has 8 states which count from 0 on every edge of the clock.



This is a write opps. you get the idea though.

[meynaf]

Originally Posted by plasmab

Not disputing here but this is odd. How a CPU (at least pre 1990) works is usually FETCH->DECODE->EXECUTE.

Now some CPUS (take arm as an example) pipeline...

CYCLE
1 FETCH1
2 FETCH2 DECODE1
3 FETCH3 DECODE2 EXECUTE3

However the 68000 doesnt do this. And we know it takes 4 clocks to do Fetch.

So i am simply confused about the decode/execute part.

Keep in mind the 68000 is a microcode monster. So things are probably not as simple as it may look.

If it takes 4 clocks to fetch, then there is perhaps some kind of parallelism inside the cpu. It does some operation while next one is being fetched (68000 does have a prefetch queue).

[plasmab]

Originally Posted by meynaf

Keep in mind the 68000 is a microcode monster. So things are probably not as simple as it may look.

If it takes 4 clocks to fetch, then there is perhaps some kind of parallelism inside the cpu. It does some operation while next one is being fetched (68000 does have a prefetch queue).

Must be something like this happening. Perhaps it actually happens I the S0/S1 time.