68k details

[Megol]

Originally Posted by plasmab

This is wrong (EDIT: Or at least partially wrong.. see below). Ram timings arent quoted in FPM times. How could they be before FPM was invented. Its a part of the random access time. The BBC used 100ns ram before 1984.

What exactly do you think is wrong? Page access isn't the same as _fast_ page access which came with FPM memory. Never claimed otherwise.

I just tried to find timing for a normal R/W cycle and a page mode R/W cycle.

Don't really dispute that I'm wrong which may be the case, spent just a little time and can have missed or misunderstood something. Not sure how useful the page mode accesses were as I didn't take the time to actually understand how it works - but those timings are in the datasheets so have to be somewhat useful.

[plasmab]

Originally Posted by Megol

What exactly do you think is wrong? Page access isn't the same as _fast_ page access which came with FPM memory. Never claimed otherwise.

I just tried to find timing for a normal R/W cycle and a page mode R/W cycle.

Don't really dispute that I'm wrong which may be the case, spent just a little time and can have missed or misunderstood something. Not sure how useful the page mode accesses were as I didn't take the time to actually understand how it works - but those timings are in the datasheets so have to be somewhat useful.

Page modes are about reading ram pages. I've never used a page mode ever. Ram times are always quoted as RAS to access. Until today i figured these pretty much equated to random access times.. Since you specify a complete address with a RAS->CAS cycle. I didnt realise that RAS precharge times could be so high. they're much lower on modern ram.

So the page mode is not part of the equation here. Its not used on the ram system i designed for the TF328 for example. In fact no Amiga that was ever produced used any kind of page mode. Its just normal DRAM.

[plasmab]

Here is the bare bones simplest possible way to access almost every DRAM every made..



You get other modes by specifying different things on the control pins at different times.

"Page mode DRAM is a minor modification to the first-generation DRAM IC interface which improved the performance of reads and writes to a row by avoiding the inefficiency of precharging and opening the same row repeatedly to access a different column. In Page mode DRAM, after a row was opened by holding RAS low, the row could be kept open, and multiple reads or writes could be performed to any of the columns in the row. Each column access was initiated by asserting CAS"

The Amiga does not use page mode.

[roondar]

This is very much off topic, but it seems to me that page mode RAM would be a pretty good idea for video purposes (video is almost all sequential accesses). Was it actually used that way?

I mean, looking at the 8 bit and most 16 bit computers it seems that most, if not all, of them didn't use page mode even for video. And yet it seems that using page mode sequential accesses for video might have come close to doubling RAM performance.

[plasmab]

Originally Posted by roondar

This is very much off topic, but it seems to me that page mode RAM would be a pretty good idea for video purposes (video is almost all sequential accesses). Was it actually used that way?

I mean, looking at the 8 bit and most 16 bit computers it seems that most, if not all, of them didn't use page mode even for video. And yet it seems that using page mode sequential accesses for video might have come close to doubling RAM performance.

It was damn good for that. And filling up instruction caches.

[litwr]

Thanks to everybody for so large amount of interesting information. Sorry I have little spare time now and I need it a lot to comprehend all this information. I am going to write a large reply someday but it can be only after some delay.
However I can show some my points now.
1) [mandelbrot] it requires fast fp multiplication. 6502 has a very good 8x8=16 bit table multiplication for about 25 cycles (the table size is 512 bytes), there is also 16x16 bit multiplication for about 196 cycles. I've made a Mandelbrot video for the BBC Micro program. The program is working during about 5 minutes but the video is accelerated. The speed and the GUI are very good. IMHO it is the best Mandelbrot in the 8-bit world.
- it is an animated GIF. I can also points BBC Micro and Amstrad CPC programs that can build Mandelbrot for the less than 30 seconds but the quality of those drawings are not too impressive.
2) [x86] There is another OS written completely in x86 assembly - https://en.wikipedia.org/wiki/KolibriOS - I have checked it and it works nice. They have ported GCC and a lot of other software to it... It is under GNU GPL.
3) I have add z80 part for my article - https://litwr.livejournal.com/1195.html.
4) [6502] This processor was made by a small startup team and its development was crushed by giants.
5) [6502 gfx] look at this demos [ Show youtube player ], [ Show youtube player ]...

[touko]

chris covell made a fractal engine demo for PCE/SGX hardware .
There is no video, but the .nfo he put on pouet .

http://www.pouet.net/prod_nfo.php?which=50005

[roondar]

That's interesting.... I did quite a bit of 6502 assembly a few years back and remember those fast 6502 multiply routines.
However, all the ones I know of (all table based) are much slower. In fact, I googled it to be sure and found a whole bunch of them here: http://codebase64.org/doku.php?id=base:6502_6510_maths

The fasted one listed was up to three times slower than the 25c you mentioned and had the following in it's comments:

; Fast 8bit * 8bit = 16bit multiply with 512 bytes tables
...
; by litwr (aka Vladimir Lidovski)with help of Urusergi 20151023
...
; Size: 64 bytes in code + 512 bytes in tables = 576 bytes
; Time: 56-79 cycles (67.5 on average)

While this is impressive for the 6502, it's not as impressive as you might think though when compared to the 68000. I can do 'fast' 16x16 multiplication on a 68000 for 38-70 cycles (average of 54) using no tables at all.

Just using the built in mulu command. Which also happens to be much faster than the 8086 equivalent as seen earlier in this thread
---

I do like the demo's you posted, the five minute Mandelbrot one is quite nice. Much, much faster than the non-optimized basic version I used on my C64

However, I just had to check how fast an A500/68000 would do this and so I've checked a single 'fast mandelbrot' program on the Amiga (not a demo, just a program run from Workbench - search on Aminet for MandelBlitz).

This took 47 seconds to draw that same basic image, at full quality. I love the 6502, it was the first CPU I programmed on. But the 68000? That's much faster at anything even remotely complex.

Originally Posted by touko

chris covell made a fractal engine demo for PCE/SGX hardware .
There is no video, but the .nfo he put on pouet .

http://www.pouet.net/prod_nfo.php?which=50005

Very cool, though I'm not sure a HU6820 can be called a 'normal' 6502.

Apart from being much newer and running very fast for a 6502 (something like 7MHz), there are some pretty significant changes to the architecture, including block transfers, new addressing modes and bit manipulation. When I called it 'basically a faster 6502 with a block move' on my website I got a number of e-mails of people telling me the differences where much bigger than I had anticipated.

[NorthWay]

Originally Posted by roondar

And yet it seems that using page mode sequential accesses for video might have come close to doubling RAM performance.

Check the BBC Electron memory and the ZX Spectrum video colour fetch.

[plasmab]

Unfortunately with the Amiga/68000s (and Atari ST) interleaved setup you end up not being able to take advantage of sequential fast access RAM. Because you never get to leave a row open.

With the 20/20 of hindsight it’s a silly bus design.

[patrik]

Originally Posted by plasmab

The Amiga does not use page mode.

Looks like the AGA chipset Amigas does, from the A1200 functional specification:

2.5.2	Lisa

Lisa is a new full custom design replacement for Denise implemented 
in 1.5um CMOS technology. In addition to a 32 bit Chip interface, Lisa 
improves video output to 24 bits of digital RGB video. Coupled with 
8Ons DRAM, Lisa can use double fetch cycles to obtain 64 bits of data 
in a single Chip bus cycle resulting in an overall four fold increase in 
Chip memory bandwidth for video.

2.5.4	AA Chip Set Feature Summary

32 bit wide data bus supports input of 32 bit wide bitplane data 
and allows the doubling of memory bandwidth. Additional 
doubling of bandwidth is achieved by using Fast Page Mode 
Ram. The same bandwidth enhancements are available for 
sprites. Also, the maximum number of bitplanes useable in all 
modes has increased to eight(8).

[plasmab]

Interesting. And it uses an 020 which has a much improved bus interface

[ross]

Originally Posted by plasmab

Interesting. And it uses an 020 which has a much improved bus interface

There is a register on AGA machine where you select CAS mode for RAM access (between 16/32 bit at time and single or double CAS).

With a typical 2x-x-x-x access you need 3x cycles to fetch 64bit (unfortunately abruptly stop the later 2 fast accesses due to the compatible switch between CPU and chipset).
So for a full cycle of 280ns you need (280/3) FPM RAM -> 80ns is more than enough.

[chb]

Originally Posted by plasmab

Unfortunately with the Amiga/68000s (and Atari ST) interleaved setup you end up not being able to take advantage of sequential fast access RAM. Because you never get to leave a row open.

With the 20/20 of hindsight it’s a silly bus design.

Well, not really. You could a) fit several sequential accesses in one slot if your mem is fast enough (like AGA's Lisa does, two 32-bit accesses) and b) it is not a strictly interleaved design, the CPU can take whatever is available and is not restricted to odd or even memory cycles, the blitter also, and bitplane dma can take every cycle anyway. That AGA performs a less-than-ideal memory access pattern is a different issue...

I guess using fast sequential access would have meant bigger on-chip buffers like the BPLXDAT registers, the blitter data registers and so on. You can see this on AGA for the display hardware, maybe the transistor budget was too tight on OCS.

[plasmab]

Originally Posted by chb

Well, not really. You could a) fit several sequential accesses in one slot if your mem is fast enough (like AGA's Lisa does, two 32-bit accesses) and b) it is not a strictly interleaved design, the CPU can take whatever is available and is not restricted to odd or even memory cycles, the blitter also, and bitplane dma can take every cycle anyway. That AGA performs a less-than-ideal memory access pattern is a different issue...



I guess using fast sequential access would have meant bigger on-chip buffers like the BPLXDAT registers, the blitter data registers and so on. You can see this on AGA for the display hardware, maybe the transistor budget was too tight on OCS.

But the clock you have only only gives 4 edges until it’s someone else’s turn. So that’s 2 accesses max. This is the point.

[plasmab]

Originally Posted by plasmab

But the clock you have only only gives 4 edges until it’s someone else’s turn. So that’s 2 accesses max. This is the point.

The 020 doesn’t have the silly bus. Sounds like AGA Amigas don’t do the interleaving stunt the same way. Probably because the silly bus is gone.

This is exactly what I think is silly and Commodore and Motorola seem to have fixed it in later systems.

020 asserts AS much earlier. S1 from memory.

[ross]

Originally Posted by plasmab

Sounds like AGA Amigas don’t do the interleaving stunt the same way. Probably because the silly bus is gone.

Nope, on Chip memory AGA Amiga does the same interleaving stunt.
Some advantages: 32bit fetch for processor (every 560ns, so 7Mbyte bandwidth vs 3,5Mbyte) and 64 bit fetch for video data (due to double CAS).
But the same 560ns, 2x280 interleaved.

AGA is a dummy patch..

EDIT: I've better read your sentence: in fact you say that they do the stunt, but they do it differently

[plasmab]

Indeed. The 020 doesn’t waste cycles so the chipset will be inserting waits.. as it should. It won’t wait accessing fastram though. The plain 68K would still access fastram like there was interleaved stuff going on.

This is the entire point.

[hooverphonique]

Originally Posted by plasmab

In fact no Amiga that was ever produced used any kind of page mode. Its just normal DRAM.

Actually, the A3000 with static column zip chips will take advantage of that. Those chips just support static column instead of static row (yes, I know that FPM normally refers to static row address, but in practice they both are page modes).

[plasmab]

Originally Posted by hooverphonique

Actually, the A3000 with static column zip chips will take advantage of that. Those chips just support static column instead of static row (yes, I know that FPM normally refers to static row address, but in practice they both are page modes).

Indeed. You just wire the address up backwards. Easy mode.

Didn’t think the A3000 did this. I saw a video interviewing Haynie and he mentioned it never made it in?

I’ve never owned an A3000