English Amiga Board


Go Back   English Amiga Board > Main > Amiga scene

 
 
Thread Tools
Old 29 January 2016, 22:05   #21
pandy71
Registered User
 
Join Date: Jun 2010
Location: PL
Posts: 1,546
Quote:
Originally Posted by ptyerman View Post
More chip RAM is needed so existing software can take advantage of it, not just software that is written to ignore the chip/fast RAM divide.
You can already increase the amount of chip RAM with WinUAE, and it does wonders for software that is chip RAM hungry such as paint programs and scanner software. (Yep, some of us DO still use the Amiga for scanning documents).
I haven't noticed it break compatibility with any software yet either which is a good thing.
I agree that getting rid of the chip/fast RAM divide altogether would be a good thing, but only if existing software ran fine with it.
There is no existing software capable to go beyond 2MB (8MB it is not only CPU but also chipset issue, you need extend pointers for example and this may imply other issues).

If you can do 2MB*50 transfers per second i.e. 100MBps (from and to CHIP RAM) then practically you have unlimited CHIP RAM (and it is hard to imagine something that require continuous 2MB or more even with AGA - assuming non modified chipset).
Side to software (HW?) transfers some I/O MMU can be added to SAGA to perform quick memory remapping without even creating memory transfer need - so efficiently you can switch between multiple CHIP RAM chunks - perhaps even in a transparent way (as such create virtual multiple Amiga instances albeit from my perspective there is no need for this).
pandy71 is offline  
AdSense AdSense  
Old 29 January 2016, 22:11   #22
Samurai_Crow
Total Chaos forever!

Samurai_Crow's Avatar
 
Join Date: Aug 2007
Location: Ft. Collins, CO USA
Age: 43
Posts: 913
Send a message via Yahoo to Samurai_Crow
Ummm... I'd be surprised if they don't convert all the fast RAM to chip internally on the board once it becomes accessible to SAGA.
Samurai_Crow is online now  
Old 29 January 2016, 22:19   #23
ptyerman
Registered User

ptyerman's Avatar
 
Join Date: Jun 2012
Location: Worksop/UK
Age: 53
Posts: 1,009
Sorry mate but there is plenty of software that will use more than 2MB of chip RAM, if that's by design or a mistake is up for debate though.
Try some paint software and BetaScan or Fxscan with WinUAE 8MB chip RAM, they do make use of the extra memory.
After all, if nothing used it why would Toni implement it in the first place?
It is easy to try it for yourself and see.
ptyerman is offline  
Old 30 January 2016, 15:12   #24
pandy71
Registered User
 
Join Date: Jun 2010
Location: PL
Posts: 1,546
Quote:
Originally Posted by ptyerman View Post
Sorry mate but there is plenty of software that will use more than 2MB of chip RAM, if that's by design or a mistake is up for debate though.
Try some paint software and BetaScan or Fxscan with WinUAE 8MB chip RAM, they do make use of the extra memory.
After all, if nothing used it why would Toni implement it in the first place?
It is easy to try it for yourself and see.
Thing you reffering to can be easily made on software level - i assume there is some software that sending request to memory allocator for particular type of RAM - in this case to allocate largest possible CHIP RAM chunk - this is not HW but software i.e. OS behavior.
Chipset and beyond 2MB limit (for ECS/AGA as for OCS it is strictly 512KB CHIP RAM limit) is something else - but this capabilities are i assume solved at SAGA.
If you see modern accelerator architectural approach such as Vampire 600 then from physical perspective 128MB RAM is no longer FAST but rather CHIP+FAST - with such archtecture you easily workaround all CHIP limitations without touching chipset and if you decide to modify chipset then all RAM began to be F(ast)CHIP in natural way.
pandy71 is offline  
Old 01 February 2016, 09:58   #25
ptyerman
Registered User

ptyerman's Avatar
 
Join Date: Jun 2012
Location: Worksop/UK
Age: 53
Posts: 1,009
Your trying to make rocket science from a simple request here! Plus a few posts back (#21) according to you there was no software that used more than 2MB, until it was pointed out to you that there was, now your saying it's down to software.
The Amiga's chip RAM limitation is well known mate, it is hardware and not software that limits it.
Anyway my request/suggestion still stands. If you look at the Vampire review done by TuKo elsewhere in this forum you will see the Chip RAM is still limited to 2MB and the rest is Fast RAM, if that changes in later revisions who knows? But until it does the request stands.
There is no way of changing the original Amiga hardware beyond the 2MB Chip RAM limits, but the new FPGA hardware that is appearing does make this possible, the same as WinUAE has, it would bring a LOT of new possibilities to the Amiga, and it is something I would love to see happen!
ptyerman is offline  
Old 01 February 2016, 10:42   #26
pandy71
Registered User
 
Join Date: Jun 2010
Location: PL
Posts: 1,546
Quote:
Originally Posted by ptyerman View Post
Your trying to make rocket science from a simple request here! Plus a few posts back (#21) according to you there was no software that used more than 2MB, until it was pointed out to you that there was, now your saying it's down to software.
The Amiga's chip RAM limitation is well known mate, it is hardware and not software that limits it.
My point was that software is not capable to use more than 2MB of CHIP as this is HW limitation of the chipset (and you must see abvious difference between UAE where pinters can be easily modified and real HW where going over 8MB may be not possible easily).
Fact that OS can fulfill SW request and allocate 8MB CHIP even if this is not a CHIP as it can't be addressed by chipset above 2MB border is meaningless - my point was to show that you can't expect that chipset will be capable to access data even if OS will expose to SW larger CHIP. And most of SW is not capable with more 2MB of CHIP limitation.


As such possibility to perform very fast transfers between CHIP and non-CHIP or even address remapping is not rocket science but easiest way to workaround HW limitations without touching HW.
pandy71 is offline  
Old 01 February 2016, 13:18   #27
grond
Registered User

 
Join Date: Jun 2015
Location: Germany
Posts: 385
What breaks old and badly written programs on fast hardware is the lack of a reliable blitter wait. A lot of code was written to start a blitjob, then do something and start the next blitjob assuming the blitter was already done with the preceding blitjob. Now if the CPU is very fast, the first blitjob won't be done when the next one is set up. This is already something you can notice when using an 060 or running code in UAE with the right settings.

This problem is one of synchronising two asynchronous processing units, the CPU on the one hand and the blitter on the other. As far as I understand SAGA will solve this puzzle by having all of the custom chips inside the FPGA. Firstly, this will make vampire RAM effectively superfast chipmem (some hundreds of MB per second vs. 7MB/s in AGA). Of course, only two (or eight?) MB of the vampire fastmem will appear as chipmem as many programs avoid this slow mem and there are limitations in the hardware registers.

Having the custom chips inside the FPGA will put the CPU caches behind both the actual CPU AND the custom chips making "chipmem" cachable as the CPU caches will change when the custom chips change any of their content. However, this would still cause a headache in many cases which is why there won't be a blitter in the old sense. Please let me explain before you get all upset...

Commodore added the blitter because the 68000 sucked at bitplane manipulation. The 68020 had the (slow) bitfield operations added because of this (it is said that Motorola added them due to a special request from Hewlett-Packard who used the 68k for their laser printers). However, using an 020 for a home computer in 1985 would have required a 32bit subsystem where 16bit already was a costly step ahead (AFAIK the Atari still had some 8 bit periphery for this same reason). So instead of using an 68020 they decided to build a blitter that could deal with the bitplane manipulation easily and at low cost. As we know, this blitter was superfast and amazing in 1985 but all but hot in 1995. The blitter was long outrun by fastblit CPU patches even when Commodore was still alive. From about 1990 on the blitter was mostly a legacy thing required for compatibility. My understanding now is that the blitter will be emulated by the CPU in SAGA without any possibility of the user noticing. This means that writing to the relevant blitter registers will simply trigger a CPU routine which will carry out the blitjob in very high speed (remember, superfast CPU with superfast pseudo-chipmem) and then just continue to do its normal CPU work. The "code" for this will not be visible to the Amiga system. From a program's perspective the blitjob will be done the moment it gets started. Thus, there won't be any need to wait for the blitter and the CPU just cannot finish faster than the blitter. Of course you wouldn't use the blitter to process FullHD images which are chunky anyway. The blitter will only be able to work on the few MB of pseudo-chipmem which can't hold any of the RTG screenmode data.

As the apollo core will have all 68k instructions (and not only a subset as all traditional 68k CPUs did), has transparent caches (note how benchmark programs believe the CPU to not have any caches at all) and resolves the blitter issue in a totally transparent way, compatibility with existing (badly written) software will be much better than that of any of the previous accelerators in existence.

Eventually the RTG screen will be overlaid on the custom chip screens and both will be available through the digital video output of the vampire. Transparency of the RTG screen can be set by some mask turning the RTG into some kind of a 3rd playfield.

Of course, all this is just a roadmap and nothing you would buy included with the vampire available for sale now.
grond is offline  
Old 01 February 2016, 14:42   #28
daxb
Registered User
 
Join Date: Oct 2009
Location: Germany
Posts: 1,751
I don`t see the point with more chipram (up to 8MB). Where is the benefit if you have a super fast cpu with a lot of super fast fastram and RTG with a lot of memory? What software still needs more then 2MB chipram? I guss there is only few graphic software that could profit from 8MB (what is still not much). The rest use RTG, right?
daxb is offline  
Old 01 February 2016, 20:27   #29
pandy71
Registered User
 
Join Date: Jun 2010
Location: PL
Posts: 1,546
Quote:
Originally Posted by grond View Post
However, this would still cause a headache in many cases which is why there won't be a blitter in the old sense. Please let me explain before you get all upset...
No sense to be upset - if you have dedicated HW and access to it as CPU instruction then fine for me - this approach was started in Intel 860 and later evolved to MMX and further extension.

Quote:
Originally Posted by grond View Post
However, using an 020 for a home computer in 1985 would have required a 32bit subsystem where 16bit already was a costly step ahead (AFAIK the Atari still had some 8 bit periphery for this same reason).
Nope - easily this can be made as in Falcon - just use DSACK - at a cost of performance.

Quote:
Originally Posted by grond View Post
So instead of using an 68020 they decided to build a blitter that could deal with the bitplane manipulation easily and at low cost. As we know, this blitter was superfast and amazing in 1985 but all but hot in 1995.
I believe that Xerox Alto was inspiration for everyone...
HP use some specialized ASIC to perform fast raster operation as laserprinter works under real time constrains.

Quote:
Originally Posted by grond View Post
The blitter was long outrun by fastblit CPU patches even when Commodore was still alive. From about 1990 on the blitter was mostly a legacy thing required for compatibility. My understanding now is that the blitter will be emulated by the CPU in SAGA without any possibility of the user noticing. This means that writing to the relevant blitter registers will simply trigger a CPU routine which will carry out the blitjob in very high speed (remember, superfast CPU with superfast pseudo-chipmem) and then just continue to do its normal CPU work. The "code" for this will not be visible to the Amiga system. From a program's perspective the blitjob will be done the moment it gets started. Thus, there won't be any need to wait for the blitter and the CPU just cannot finish faster than the blitter. Of course you wouldn't use the blitter to process FullHD images which are chunky anyway. The blitter will only be able to work on the few MB of pseudo-chipmem which can't hold any of the RTG screenmode data.

As the apollo core will have all 68k instructions (and not only a subset as all traditional 68k CPUs did), has transparent caches (note how benchmark programs believe the CPU to not have any caches at all) and resolves the blitter issue in a totally transparent way, compatibility with existing (badly written) software will be much better than that of any of the previous accelerators in existence.
All this sound like Xerox Alto where blitter was microcode based (implemented on CPU made from ordinary TTL 74181).
https://en.wikipedia.org/wiki/Xerox_Alto#Architecture
pandy71 is offline  
Old 02 February 2016, 09:41   #30
TjLaZer
Registered User
TjLaZer's Avatar
 
Join Date: Sep 2004
Location: Tacoma, WA USA
Age: 46
Posts: 1,170
Quote:
Originally Posted by eXeler0 View Post
Not sure this thread is the best place to seek help for your sex and alcohol issues ��

Let's try to be grownups and wait for at least 5 pages before derailing the topic ☺
You must not know about the jumper for 8MB Chip RAM on the motherboard and Dave Haynie's historic comment. Look it up!
TjLaZer is offline  
Old 02 February 2016, 17:50   #31
eXeler0
Registered User

eXeler0's Avatar
 
Join Date: Feb 2015
Location: Sweden
Age: 43
Posts: 1,418
Quote:
Originally Posted by TjLaZer View Post
You must not know about the jumper for 8MB Chip RAM on the motherboard and Dave Haynie's historic comment. Look it up!
Haha, ok, I learned something new today.
eXeler0 is offline  
Old 02 February 2016, 23:16   #32
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
the way i like to think about the Blitter is as a single cell of a dynamically-programmable FPGA connected to a DMA channel. It is basically a really simple stream processor. The logical progression, to my mind, is to simply have lots of them (with maybe some boosted functionality), able to run in parallel or maybe even in series.

Last edited by Mrs Beanbag; 02 February 2016 at 23:26.
Mrs Beanbag is offline  
Old 03 February 2016, 00:26   #33
matthey
Banned
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
Quote:
Originally Posted by Mrs Beanbag View Post
the way i like to think about the Blitter is as a single cell of a dynamically-programmable FPGA connected to a DMA channel. It is basically a really simple stream processor. The logical progression, to my mind, is to simply have lots of them (with maybe some boosted functionality), able to run in parallel or maybe even in series.
Parallel blitters would have been good for 256 color planar graphics but it would be a waste of resources now that even FPGA hardware has enough bandwidth for moderate to high resolution in at least 16 bit chunky. The way to work on chunky is with SIMD. One proposal for problems with a high speed blitter was to trap to the CPU/SIMD which would handle the work. A more versatile and standard SIMD would allow other code to be accelerated also. Grond hinted at this being used by SAGA/Apollo which I believe to be true if and when it is possible.
matthey is offline  
Old 03 February 2016, 07:50   #34
ReadOnlyCat
Code Kitten

 
Join Date: Aug 2015
Location: Montreal/Canadia
Age: 46
Posts: 1,012
Quote:
Originally Posted by matthey View Post
Parallel blitters would have been good for 256 color planar graphics but it would be a waste of resources now that even FPGA hardware has enough bandwidth for moderate to high resolution in at least 16 bit chunky. The way to work on chunky is with SIMD. One proposal for problems with a high speed blitter was to trap to the CPU/SIMD which would handle the work. A more versatile and standard SIMD would allow other code to be accelerated also. Grond hinted at this being used by SAGA/Apollo which I believe to be true if and when it is possible.
I think Mrs Beanbag means the logical progression for the blitting architecture, not for you guys.

Parallel blitters actually allow superlinear acceleration compared to plane by plane operations because they make masking channels unnecessary: they can be computed from the combined inputs. And this is interesting for any number of planes.

A cookie-cut operation would use 25% less DMA when conducted with parallel blitters because one of four channels is made unnecessary.
Even putting just two blitters alongside one another allows sharing the mask and thus saves 1/8=12.5% DMA cycles. This is significant.

But yup, not too useful for youse.
ReadOnlyCat is offline  
Old 03 February 2016, 21:28   #35
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
Quote:
Originally Posted by ReadOnlyCat View Post
I think Mrs Beanbag means the logical progression for the blitting architecture, not for you guys.
...
But yup, not too useful for youse.
well i appreciate their aims might be different but maybe my idea is more powerful than it appears... because if you have enough Blitters joined together what you really have on your hands is a dynamically reconfigurable FPGA that has access to your graphics RAM.

And another thing i'd suggest we could have really done with is a second copper for initialising the Blitter, because it's quite a task to do it with the normal copper and at the same time get it to do fancy screen effects. Depending on how you implement that, you could create something that can do what a SIMD can do but much more flexible.
Mrs Beanbag is offline  
Old 04 February 2016, 16:20   #36
NorthWay
Registered User
 
Join Date: May 2013
Location: Grimstad / Norway
Posts: 391
I wonder what kind of technical solution they intend for SAGA. Are they going to snoop memory activity or something?
Just using the floppy to read and write data totally breaks down any kind of new chipmem located on the Vampire board. (This is different on FPGA-only solution where you don't have two of something.)
NorthWay is offline  
Old 04 February 2016, 16:31   #37
ReadOnlyCat
Code Kitten

 
Join Date: Aug 2015
Location: Montreal/Canadia
Age: 46
Posts: 1,012
Quote:
Originally Posted by Mrs Beanbag View Post
And another thing i'd suggest we could have really done with is a second copper for initialising the Blitter, because it's quite a task to do it with the normal copper and at the same time get it to do fancy screen effects. Depending on how you implement that, you could create something that can do what a SIMD can do but much more flexible.
Yup, that is also on my list of regrets.
A dedicated Blitter list would have made a world of difference and reduced CPU overhead enormously. It could even have been a simplified Copper:
- waitblitter: pauses and wakes up on Blitter finish.
- pause: waits until woken up by main Copper.
- move: well, move.
No need to wait on a given line: that can be handled by the main Copper who can then drive the Blitterlist based on the video beam.

Ahhhh, regrets.
ReadOnlyCat is offline  
Old 04 February 2016, 23:05   #38
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
Quote:
Originally Posted by ReadOnlyCat View Post
Ahhhh, regrets.
well no need for regrets here... this thread is about "Super AGA" isn't it? And that's my suggestion of how to do it.

If they want to implement something that is like a modern PC graphics card instead of AGA but better then "Super AGA" doesn't seem like the right name!
Mrs Beanbag is offline  
Old 04 February 2016, 23:15   #39
eXeler0
Registered User

eXeler0's Avatar
 
Join Date: Feb 2015
Location: Sweden
Age: 43
Posts: 1,418
Quote:
Originally Posted by ReadOnlyCat View Post
Yup, that is also on my list of regrets.
A dedicated Blitter list would have made a world of difference and reduced CPU overhead enormously. It could even have been a simplified Copper:
- waitblitter: pauses and wakes up on Blitter finish.
- pause: waits until woken up by main Copper.
- move: well, move.
No need to wait on a given line: that can be handled by the main Copper who can then drive the Blitterlist based on the video beam.

Ahhhh, regrets.
Regrets? Who are you? 😆
eXeler0 is offline  
Old 04 February 2016, 23:28   #40
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
Quote:
Originally Posted by eXeler0 View Post
Regrets? Who are you? 😆
https://commons.wikimedia.org/wiki/F...a_IMG_1132.jpg
Mrs Beanbag is offline  
AdSense AdSense  
 


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

Similar Threads
Thread Thread Starter Forum Replies Last Post
apollo-core forum HanSolo support.Other 4 16 September 2015 08:51
Premiere by Core Design Gzegzolka support.Games 3 08 January 2015 00:47
SuperAGA or AAA? zevs request.UAE Wishlist 11 04 December 2014 17:59
'SuperAGA' for WinUAE? zevs request.UAE Wishlist 13 14 October 2008 16:55

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 21:50.


Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Page generated in 0.33898 seconds with 11 queries