68k details

[plasmab]

Originally Posted by tolkien

So all amiga custom chips are not usefull and we should use only the cpu power to do all kind of things.

Don’t be absurd. Thats not what I said. I’m trying to point out that other systems take a different approach and achieve different results in different ways. If you look at the Archie and say “there is no scrolling” then you’re simply applying “amiga thinking” somewhere it doesn’t work.

I’m equally scathing of Archie people when they apply their thinking incorrectly to the Amiga.

[tolkien]

What is absurd is to say Amiga coders don't like to use their brains and stay happy.

[plasmab]

Originally Posted by tolkien

What is absurd is to say Amiga coders don't like to use their brains and stay happy.

Take your trolling elsewhere. I stand by what I said

[Megol]

Originally Posted by tolkien

So all amiga custom chips are not usefull and we should use only the cpu power to do all kind of things.

If using the processor is faster - yes. Which is how things already are, the chipset is reduced to a bottleneck for a c2p-converted 68060 rendered screen.

Originally Posted by plasmab

You still need a write the buffer in the first place though. You do the shift as you create the scene. You don’t render, read, shift, write. Like I say... if you use your brain up front the result is the same.

Nope. Even in an intensive side-scrolling shoot 'em up most of the screen doesn't change. Re-rendering everything is more CPU intensive than simply reading the frame-buffer and writing a shifted version of it.

The ARM was fast for its time but not that fast, the CPU also have to mix music/sound effects, do collision checking, draw sprites etc. These are things even faster machines with hardware scrolling can struggle with.

The Amiga way just means you don’t have to think.

Was ludicrous the first time you wrote it and equally so now.

[chb]

Originally Posted by grond

If the CPU does the scrolling, you need the required mem bandwidth to a) read the screen data, b) write it back and then c) read it through video DMA. If the video hardware can scroll by itself, you only need c). Three times less memory impact, I still think the Amiga way is quite clever.

and d) your code to move/bitwise scroll the data has also to come from memory, if there's no cache present. It's simply a waste of memory bandwidth for something that can be done with little effort in hardware.

I'd guess the ARM2 at 8 MHz in the A3000 would need about one memory access per pixel for load, store and instruction fetch for an 8 bit screen (if you use ldm/stm and ANDing/ORing the bits that go to the next longword), probably a bit more. Then you need 320*256*50*4 = minimum 16 MB/s bandwidth, plus display DMA bandwidth (ca. 4MB/s), leaving only 20% of the very nice 25.6 MB/s total bandwidth the system has. Now add objects, music and game logic...

And if you want to do parallax scrolling, it starts to look even more grim, even in 16 colors. I'm very sure that with CPU-only scrolling, you won't have a chance to do something like SOTB*, Jim Power, Mr Nutz or Agony on the Archie in 50 Hz.

*yes, I'm aware of Zarchos' demo, impressive, but still a lot missing.

[plasmab]

Originally Posted by Megol

Nope. Even in an intensive side-scrolling shoot 'em up most of the screen doesn't change. Re-rendering everything is more CPU intensive than simply reading the frame-buffer and writing a shifted version of it.

Fair point. I guess most games would just clean up where sprites where drawn over the background. I don’t have masses of experience with writing Archie games.

Was ludicrous the first time you wrote it and equally so now .

Not as ludicrous as saying that scrolling was tough on the Archie. That’s just ignorant (not saying it was you).

[zero]

Originally Posted by plasmab

The ARMv2 is plenty fast enough to update every frame.. and the barrel shifter makes pixel level scrolling free. see axis as an example game. Amiga coders want hardware way to do it. They don’t like to use their brain.

320x256x8 screen requires 8MB/sec to scroll at 50Hz. 4MB of reads, 4MB of writes.

Considering that the ARM was only running at 8MHz that seems to be impossible. It would have to average one byte per cycle, including instruction fetch overhead on a CPU with no cache.

The Amiga had a much better system. Hardware horizontal scroll support that only required you to draw new data just before it scrolled on to screen. A typical game using 16x16 tiles only had to draw one new tile per frame for a 1 pixel/frame scroll.

[roondar]

Originally Posted by plasmab

Not as ludicrous as saying that scrolling was tough on the Archie. That’s just ignorant (not saying it was you).

Considering you replied to my post with the 'brain' nonsense: I didn't actually say anything like that. The short version of what I said was that I didn't buy into there being a problem scrolling, as it shouldn't have any problems doing so considering the CPU/memory speed.

I'm honestly rather confused at how you could've even come remotely close to the conclusion that I said that scrolling on the Archimedes was tough.

[plasmab]

Originally Posted by zero

320x256x8 screen requires 8MB/sec to scroll at 50Hz. 4MB of reads, 4MB of writes.



Considering that the ARM was only running at 8MHz that seems to be impossible. It would have to average one byte per cycle, including instruction fetch overhead on a CPU with no cache.



The Amiga had a much better system. Hardware horizontal scroll support that only required you to draw new data just before it scrolled on to screen. A typical game using 16x16 tiles only had to draw one new tile per frame for a 1 pixel/frame scroll.

The Archie wasn’t locked at 8bpp depth. You could have down to 1 or 2 bits per pixel.

Also it wrote 32bits per cycle and the MEMC supports burst mode. So it was writing 4 bytes per word ( in a burst of 4 = 16 bytes in 4 clocks) . The overhead was LDM and STM which could read 14 words into the registers in one 32 bit instruction and write them back out in a single instruction l. Practically 12 was your limit though. So 2 instruction reads per 48 bytes transferred...

Correct my maths if I’m wrong here. You vastly underestimated the bandwidth of the Archie.

[roondar]

Originally Posted by zero

320x256x8 screen requires 8MB/sec to scroll at 50Hz. 4MB of reads, 4MB of writes.

Considering that the ARM was only running at 8MHz that seems to be impossible. It would have to average one byte per cycle, including instruction fetch overhead on a CPU with no cache.

The system and memory bus are fully 32 bit. It has a memory bandwidth of 32MB/sec (=4 bytes per cycle). It has plenty of bandwidth for this problem.

The Amiga had a much better system. Hardware horizontal scroll support that only required you to draw new data just before it scrolled on to screen. A typical game using 16x16 tiles only had to draw one new tile per frame for a 1 pixel/frame scroll.

The Amiga does have a better system for scrolling, because the graphics chip can do the fetch & shift in the same step (i.e. scrolling doesn't actually increase bandwidth requirements compared to just showing a non-moving picture). On the flipside, the Amiga has much less memory bandwidth to play with (OCS tops out at 7MB/second for the chipset and ~3.5MB/second for the CPU).

As for the ARM, the lesson here is: don't underestimate what you can do with that much raw bandwidth and a CPU that takes 1 or 2 cycles per instruction.

[plasmab]

Originally Posted by roondar

Considering you replied to my post with the 'brain' nonsense: I didn't actually say anything like that. The short version of what I said was that I didn't buy into there being a problem scrolling, as it shouldn't have any problems doing so considering the CPU/memory speed.

I'm honestly rather confused at how you could've even come remotely close to the conclusion that I said that scrolling on the Archimedes was tough.

You have my apologies then.

[chb]

Originally Posted by plasmab

The overhead was LDM and STM which could read 14 words into the registers in one 32 bit instruction and write them back out in a single instruction l. Practically 12 was your limit though. So 2 instruction reads per 48 bytes transferred...

Correct my maths if I’m wrong here. You vastly underestimated the bandwidth of the Archie.

Correct for raw transfer bandwidth, but for scrolling you cannot write 32 bit words to non-aligned addresses, so you need a) load with ldm, b) save the bits that will be shifted out of the longword (AND with mask) and shift them, c) shift by pixel size * scroll value, d) OR the saved bits + shifted bits from the previous longword, and e) write them back with stm.

You might be able to combine c) with d) or b), but stm and ldm do not support shifts. That's why I'd say at least 4 memory accesses per longword (2 data + 2 inst), a bit more because of stm/ldm overhead, or a bit more than 5 if you cannot combine the shift with some other instruction.

[chb]

Originally Posted by roondar

The system and memory bus are fully 32 bit. It has a memory bandwidth of 32MB/sec (=4 bytes per cycle). It has plenty of bandwidth for this problem.

AFAIK it's slightly less (25.6MB/s), as it's using page mode with a 2-1-1-1 pattern, but still a lot.

[grond]

Originally Posted by plasmab

. The overhead was LDM and STM which could read 14 words into the registers in one 32 bit instruction and write them back out in a single instruction l. Practically 12 was your limit though. So 2 instruction reads per 48 bytes transferred...

Correct my maths if I’m wrong here. You vastly underestimated the bandwidth of the Archie.

LDM and STM have no free barrel shifter and need 32 bits aligned addresses. You're welcome.

[plasmab]

If you ignore DMA and refresh cycles. I make that Archie could do approx 13Mb/sec with the CPU.

The raw speed is 8Mhz x 4 x 1/2 = is 16Mb/sec x 12/14.

Challenge the maths please. 12 cycles out of 14 are transferring data when you use LDM/STM

[roondar]

Originally Posted by chb

AFAIK it's slightly less (25.6MB/s), as it's using page mode with a 2-1-1-1 pattern, but still a lot.

I'm still going with: should be enough, really

Edit: if your scrolling figures above are accurate (i.e. having 20% or so of the total left after display & scrolling), you should still be able to do a game without real issues. Twenty percent of 25.6MB/s is still 5.12 MB/sec, which compares rather favourably with the Amiga's bandwidth after display DMA*.

And that is using 256 colour mode. The numbers get much better if choose fewer colours (say, 16 colours).

*) For a four bitplane 320x256 scrolling screen the OCS Amiga chipset would have about 4.7MB/sec left after display DMA (or about 2.3MB/sec for the CPU)

[plasmab]

Originally Posted by grond

LDM and STM have no free barrel shifter and need 32 bits aligned addresses. You're welcome.

This is true. I’d forgotten about that.

[chb]

Originally Posted by roondar

I'm still going with: should be enough, really

Edit: if your scrolling figures above are accurate (i.e. having 20% or so of the total left after display & scrolling), you should still be able to do a game without real issues. Twenty percent of 25.6MB/s is still 5.12 MB/sec, which compares rather favourably with the Amiga's bandwidth after display DMA*.

*) For a four bitplane 320x256 scrolling screen the Amiga chipset would have about 4.7MB/sec left after display DMA (or about 2.3MB/sec for the CPU)

True, but in my eyes it's not a design very well suited for scrolling if your system with 4x the bandwidth of the Amiga after display dma and scrolling is left with about the same bandwidth... not to speak about overscanned screens! (Yep, I'm comparing 4bpl to 8bit, not fair.)

[plasmab]

Unfortunately Frontier was never ported to the Archie. I did use the Tom Morten glFrontier code to try and get it working for ARM but the binary was too big to run on any Archie.

Unsure if this is indicative of the code denisity differences between ARM and 68000. Read into it what you want.

[touko]

I never mentioned the 68000, did I. Please compare the ARM of any generation to other contemporaneous RISC processors, not to the 68000.

In that sense i agree, but you also must take the price in account .
The others risc CPU,were way more expensive,and there was no risc CPU available for the mass .
In a PC, the ARM2 was the fastest .

The ARM was fast for its time but not that fast, the CPU also have to mix music/sound effects, do collision checking, draw sprites etc. These are things even faster machines with hardware scrolling can struggle with.

The ST has only a 68k, like the archimedes only has an ARM2(both at 8mhz), and it's easy to tell which is more powerful .