English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Asm / Hardware

 
 
Thread Tools
Old 31 October 2018, 13:03   #601
plasmab
Banned
plasmab's Avatar
 
Join Date: Sep 2016
Location: UK
Posts: 2,917
Quote:
Originally Posted by tolkien View Post
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.
plasmab is offline  
Old 31 October 2018, 13:08   #602
tolkien
AmigaMan

tolkien's Avatar
 
Join Date: Oct 2012
Location: Castro Urdiales/Spain
Posts: 535
What is absurd is to say Amiga coders don't like to use their brains and stay happy.
tolkien is offline  
Old 31 October 2018, 13:16   #603
plasmab
Banned
plasmab's Avatar
 
Join Date: Sep 2016
Location: UK
Posts: 2,917
Quote:
Originally Posted by tolkien View Post
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
plasmab is offline  
Old 31 October 2018, 15:22   #604
Megol
Registered User

Megol's Avatar
 
Join Date: May 2014
Location: inside the emulator
Posts: 368
Quote:
Originally Posted by tolkien View Post
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.
Quote:
Originally Posted by plasmab View Post
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.
Quote:
The Amiga way just means you don’t have to think.
Was ludicrous the first time you wrote it and equally so now.
Megol is offline  
Old 31 October 2018, 16:21   #605
chb
Registered User

 
Join Date: Dec 2014
Location: germany
Posts: 171
Quote:
Originally Posted by grond View Post
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.
chb is offline  
Old 31 October 2018, 16:37   #606
plasmab
Banned
plasmab's Avatar
 
Join Date: Sep 2016
Location: UK
Posts: 2,917
Quote:
Originally Posted by Megol View Post

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.


Quote:

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).
plasmab is offline  
Old 31 October 2018, 17:10   #607
zero
Registered User

 
Join Date: Jun 2016
Location: UK
Posts: 335
Quote:
Originally Posted by plasmab View Post
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.
zero is offline  
Old 31 October 2018, 17:13   #608
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,288
Quote:
Originally Posted by plasmab View Post
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.

Last edited by roondar; 31 October 2018 at 17:21.
roondar is offline  
Old 31 October 2018, 17:19   #609
plasmab
Banned
plasmab's Avatar
 
Join Date: Sep 2016
Location: UK
Posts: 2,917
68k details

Quote:
Originally Posted by zero View Post
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.
plasmab is offline  
Old 31 October 2018, 17:20   #610
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,288
Quote:
Originally Posted by zero View Post
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.

Quote:

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.

Last edited by roondar; 31 October 2018 at 17:25.
roondar is offline  
Old 31 October 2018, 17:22   #611
plasmab
Banned
plasmab's Avatar
 
Join Date: Sep 2016
Location: UK
Posts: 2,917
Quote:
Originally Posted by roondar View Post
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.
plasmab is offline  
Old 31 October 2018, 17:32   #612
chb
Registered User

 
Join Date: Dec 2014
Location: germany
Posts: 171
Quote:
Originally Posted by plasmab View Post
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.

Last edited by chb; 31 October 2018 at 17:38.
chb is offline  
Old 31 October 2018, 17:35   #613
chb
Registered User

 
Join Date: Dec 2014
Location: germany
Posts: 171
Quote:
Originally Posted by roondar View Post
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.
chb is offline  
Old 31 October 2018, 17:37   #614
grond
Registered User

 
Join Date: Jun 2015
Location: Germany
Posts: 638
Quote:
Originally Posted by plasmab View Post
. 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.
grond is offline  
Old 31 October 2018, 17:44   #615
plasmab
Banned
plasmab's Avatar
 
Join Date: Sep 2016
Location: UK
Posts: 2,917
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
plasmab is offline  
Old 31 October 2018, 17:44   #616
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,288
Quote:
Originally Posted by chb View Post
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)

Last edited by roondar; 31 October 2018 at 17:57.
roondar is offline  
Old 31 October 2018, 17:44   #617
plasmab
Banned
plasmab's Avatar
 
Join Date: Sep 2016
Location: UK
Posts: 2,917
Quote:
Originally Posted by grond View Post
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.
plasmab is offline  
Old 31 October 2018, 18:01   #618
chb
Registered User

 
Join Date: Dec 2014
Location: germany
Posts: 171
Quote:
Originally Posted by roondar View Post
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.)
chb is offline  
Old 31 October 2018, 18:18   #619
plasmab
Banned
plasmab's Avatar
 
Join Date: Sep 2016
Location: UK
Posts: 2,917
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.
plasmab is offline  
Old 31 October 2018, 21:31   #620
touko
Registered User

touko's Avatar
 
Join Date: Dec 2017
Location: france
Posts: 93
Quote:
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 .

Quote:
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 .

Last edited by touko; 31 October 2018 at 21:36.
touko is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Any software to see technical OS details? necronom support.Other 3 02 April 2016 12:05
2-star rarity details? stet HOL suggestions and feedback 0 14 December 2015 05:24
EAB's FTP details... Basquemactee1 project.EAB File Server 2 30 October 2013 22:54
req details for sdl turrican3 request.Other 0 20 April 2008 22:06
Forum Details BippyM request.Other 0 15 May 2006 00:56

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 15:20.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Page generated in 0.12758 seconds with 16 queries