Welcome, Guest. Please login or register.
Amiga Kit Amiga Store Iridium Banner AMIStore App Store A1200/A600 4xIDE Interface

AuthorTopic: newb questions, hit the hardware or not?  (Read 14005 times)

0 Members and 1 Guest are viewing this topic.

Offline OlafS3

Re: newb questions, hit the hardware or not?
« Reply #30 on: July 15, 2014, 12:30:07 PM »
Quote from: nicholas;768996
There are many. Not sure about publicly released
ones but I know of several that are in various states of finish.

yes there are quiet a lot... but many long forgotten (if they were ever used)

example is this:
http://aminet.net/package/dev/misc/gms_dev

the author allows it to be patched. AGA works (and propably ECS). RTG could be supported too if someone makes the changes. The problem is it seems not be used very much. Years of work in it but everyone reinvents the wheels. We should use it, perhaps make a documentation about the state, recommendations when to use and so on, get permissions and sources where possible and start to improve these libraries, make includes/modules for different languages. That would help development a lot more than many other ideas.
 

Offline itix

Re: newb questions, hit the hardware or not?
« Reply #31 on: July 15, 2014, 12:34:46 PM »
Quote from: OlafS3;768994
would it not be better to have standard libraries for that with versions for the different target platforms? When I worked on building up Aros Vision I did a lot of search (in both web and aminet) and found a lot of libraries that are dedicated to offer fast graphics hiding what platform you use (partly supporting ECS,AGA and RTG). SamuraiCrow knows one of those (and the owner has permitted to make changes on it). If adapted it would make life a lot easier. The 68k codebase is huge and we should make use of it as far as possible. We should have a set of portable libraries covering all important areas like graphics, sound and so on so that developer do not have to care about implementations/optimizations for a certain core (and it would be possible to port it to AROS/MorphOS/AmigaOS too).


At overall they are not better than OS routines. Maybe some functions are optimized better for some hardware but you still can't get max performance out from older Amigas. Sprites are hard to abstract since they have many HW restrictions on Amiga and Copper is completely missing from RTG.
My Amigas: A500, Mac Mini and PowerBook
 

Offline SamuraiCrow

Re: newb questions, hit the hardware or not?
« Reply #32 on: July 15, 2014, 12:37:27 PM »
Quote from: nicholas;768991
It's not like we can't detect the machine we are running on and use a different codepath for each architecture. Best of both worlds. :)


We could if we coded for a static VM and let the final optimization take place at install time.

Quote from: Thorham;768993
Do we currently have such tools? How fast would that be for 68020/30 compared to hand optimized code?


Mostly all that exists at this point is compiler middle-ware like LLVM or fixed-function compilers like GCC and VBCC.  But I know LLVM has a PBQP register allocator that is smart enough to stuff multiple small values in a large register when it makes sense to do so, for example:
Code: [Select]
move.w (a0,var1), d0  ;load var1
swap d0  ;stuff it in top half of d0
move.w (a0, var2), d0;  load var2 in the bottom half of d0

and so on.  Compilers can be smart if they are programmed to be.

Once implemented, a virtual machine based on this could make a difference for anybody with generally unsupported hardware!  This technology is already in use by the PNaCl VM in the Google Chrome browser but for little-endian machines only.  This is why low-level coding is dying out, not only because high-level code is cheaper to make, but the optimization can be automated!

I've been pushing for this stuff since 1998 and if Amiga, Inc. hadn't been so pig-headed stubborn, we'd have had this on the Amigas by now!  AmigaDE could have made Amiga much more compatible without the need to alter the hardware. Since LLVM is Apple-supported open-source freeware and the backend used by the PNaCl VM is also (except-Google supported), it is almost in reach again!
 

Offline SamuraiCrow

Re: newb questions, hit the hardware or not?
« Reply #33 on: July 15, 2014, 12:48:31 PM »
Quote from: itix;769001
At overall they are not better than OS routines. Maybe some functions are optimized better for some hardware but you still can't get max performance out from older Amigas. Sprites are hard to abstract since they have many HW restrictions on Amiga and Copper is completely missing from RTG.


I've been studying how to do this since 1995.  Sprites may be hard to abstract but they are easy to emulate.

One of my planned libraries will be to make it possible to "tile" sprites side-by-side and top-to-bottom.  All it needs is for a rectangle of a layer to be allocated for each 16-color sprite pair (using a non-standard interleave so that it appears to the OS to be a narrow 16-color screen).  Layers.library will queue a separate blitter operations to each rectangle with clipping applied so that the seams between the sprites will not be detectable.  Of course the main graphics will have to be specially coded for Amiga but getting it to work on other systems will be dead-simple by comparison.

I've got similar plans for the effects created with the Copper as well.
 

Offline Thorham

Re: newb questions, hit the hardware or not?
« Reply #34 on: July 15, 2014, 02:25:36 PM »
To SamuraiCrow:

That's all very nice, but I like programming in 680x0 assembly language, it's one of my computer related hobbies, and I'm not the only one.
 

Offline SamuraiCrow

Re: newb questions, hit the hardware or not?
« Reply #35 on: July 15, 2014, 02:38:54 PM »
@Thorham

That's cool.  Just don't throw away your Assembly source.  The comments help others to figure out how to cross-assemble it into bytecode.  :-)
 

guest11527

  • Guest
Re: newb questions, hit the hardware or not?
« Reply #36 on: July 15, 2014, 05:39:57 PM »
Quote from: SamuraiCrow;769006
One of my planned libraries will be to make it possible to "tile" sprites side-by-side and top-to-bottom.  All it needs is for a rectangle of a layer to be allocated for each 16-color sprite pair (using a non-standard interleave so that it appears to the OS to be a narrow 16-color screen).  Layers.library will queue a separate blitter operations to each rectangle with clipping applied so that the seams between the sprites will not be detectable.  Of course the main graphics will have to be specially coded for Amiga but getting it to work on other systems will be dead-simple by comparison.

Why do you make this needlessly complicated? First, layers is *not* the right library or abstraction for sprite emulation or blitting. It only maintains cliprects and damage regions, nothing else. But, if you want movable objects, there is already perfect support for this. Graphics.library BOBs exist since ever, provide an unlimited number of moving and animated objects. The correct abstraction is there, is in the Os and is completely supported. IIRC, the workbench uses them for moving drawers and icons around.

The copper is too specialized and, given the number of colors a graphics card supports, not even required there. The copper was a chip from the 80s required to work around the limited bandwidth chips had back then. Similar effects do not require a copper nowadays, and allow a simple straight-foreward approach that was not available back then.
 

Offline LiveForIt

Re: newb questions, hit the hardware or not?
« Reply #37 on: July 15, 2014, 05:47:14 PM »
@Thorham

Hit the hardware is issue of speed vs comparability / flexibility, for the user it means it will limit there hardware choice..

It depends on what you want to do, for most part you should avoid banging the hardware, but if you are interested in making a OCS game for Amiga500, it makes the most sense to take advantage of every CPU cycle you can get, and try to avoid the overhead of the software API.

Writing a game for a modern graphic card, and using CIAA/CIAB timers, will exclude many people from using your software (AmigaONE-*/Sam4*0), there for its not a good idea.

Poking around in $DFF00A and $DFF00C, to get Joystick and mouse, will limit your software to only to work with 9 pin joysticks, and mouse, and will not allow your software to support USB mouse and Joysticks.

Many people have USB upgrades to there classic Amiga (Algor/Subway), and NG users don't have 9 pin bus mouse at all.

Other things people do that is annoying is that they assume they know BytesPerRow, this forces the game or program to only run in one screen resolution, and fixed mode ID's that can't be changed.

For examples if you write game/program to use Paula sound chips, then it might be faster on a MC68020, where don't have lot of CPU power, but you will not allow your game/program to use a modern sound cards like Prelude 1200 or any other sound card.

Sticking to graphic.library will make your game or program run on any hardware but, it will most likely run slower then if you wrote directly to memory, instead of using graphic draw functions, and so on.
« Last Edit: July 15, 2014, 05:54:23 PM by LiveForIt »
 

guest11527

  • Guest
Re: newb questions, hit the hardware or not?
« Reply #38 on: July 15, 2014, 06:22:19 PM »
Quote from: LiveForIt;769029
Sticking to graphic.library will make your game or program run on any hardware but, it will most likely run slower then if you wrote directly to memory, instead of using graphic draw functions, and so on.

I pretty much doubt this. If there is no cliprect (i.e. the rastport has no layer) graphics.library goes directly to the hardware on native amigas. There is no overhead in such a case. Again, before making such claims, please measure.

If there is a graphics card, it goes to the hardware of the graphics card if it supports 2D acceleration, same story. Only difference: It works on all hardware.
 

Offline LiveForIt

Re: newb questions, hit the hardware or not?
« Reply #39 on: July 15, 2014, 07:06:09 PM »
Quote from: Thomas Richter;769032
graphics.library goes directly to the hardware on native amigas.

I guess it depends on what you want to do, but writing directly too hardware might be slower.

Chipmem is slow, and fastmem is fast, so pre rendering into fast makes sense, if your doing a lot of read and writs from/to memory, and then using the most efficient way to transfare to chip memory.

The same is also true for modern graphic cards, writing directly to graphic card memory over the PCIe interface is slow, because it does not allow you to use DMA to copy the data.

The OS pen system is not most optimized for any picture format.

Quote
Again, before making such claims, please measure.

I should maybe not be so absolute in my statement.

Quote
it goes to the hardware of the graphics card if it supports 2D acceleration, same story. Only difference: It works on all hardware.

I take your word for it.
 

Offline Thorham

Re: newb questions, hit the hardware or not?
« Reply #40 on: July 15, 2014, 09:58:13 PM »
Quote from: LiveForIt;769029
It depends on what you want to do
Write software that's fast on 20s and 30s with AGA, and when possible OCS/ECS, while keeping it system friendly, but without sacrificing speed (no need for syskill practices, custom screens and what not, of course).

Quote from: LiveForIt;769029
Writing a game for a modern graphic card, and using CIAA/CIAB timers, will exclude many people from using your software (AmigaONE-*/Sam4*0), there for its not a good idea.
I'm only interested in writing Amiga software anyway.

Quote from: LiveForIt;769029
Poking around in $DFF00A and $DFF00C
On 20s and 30s there's no need for that. Especially the mouse and keyboard are very easy to handle properly with the OS.

Quote from: LiveForIt;769029
Other things people do that is annoying is that they assume they know BytesPerRow
For a game that opens a fixed sized screen this isn't a problem. On Amigas this is generally not a problem, and if some user can't use this, then I wonder how their Amiga is set up.

Quote from: LiveForIt;769029
this forces the game or program to only run in one screen resolution, and fixed mode ID's that can't be changed.
You can at least use different monitor IDs so that double scan is supported. For non-games software it's a definite no-no.

Quote from: LiveForIt;769029
For examples if you write game/program to use Paula sound chips, then it might be faster on a MC68020, where don't have lot of CPU power, but you will not allow your game/program to use a modern sound cards like Prelude 1200 or any other sound card.
Not a problem when you run the software on an actual Amiga, unless someone doesn't have Paula output connected, and that's their own problem.

Quote from: LiveForIt;769029
Sticking to graphic.library will make your game or program run on any hardware but, it will most likely run slower then if you wrote directly to memory, instead of using graphic draw functions, and so on.
Only using the OS in general is unacceptable for me, because it only helps NG users. Why should we take NG users in account when writing Amiga software? If people want to run Amiga software, then let them use Amiga computers or emulation.
 

Offline biggun

Re: newb questions, hit the hardware or not?
« Reply #41 on: July 15, 2014, 10:07:06 PM »
Quote from: LiveForIt;769029
@Thorham

Hit the hardware is issue of speed vs comparability / flexibility, for the user it means it will limit there hardware choice..

It depends on what you want to do, for most part you should avoid banging the hardware, but if you are interested in making a OCS game for Amiga500, it makes the most sense to take advantage of every CPU cycle you can get, and try to avoid the overhead of the software API.

Writing a game for a modern graphic card, and using CIAA/CIAB timers, will exclude many people from using your software (AmigaONE-*/Sam4*0), there for its not a good idea.

Poking around in $DFF00A and $DFF00C, to get Joystick and mouse, will limit your software to only to work with 9 pin joysticks, and mouse, and will not allow your software to support USB mouse and Joysticks.



What you say it correct.

But it does not need to be like this.
A CIA need minimal FPGA
By adding the smallest and cheapest FPGA to a new system - every system could be made CIA compatible for a price of close to nothing.

The same is true with USB and accessing them via DFFxxx registers.
A USB to DFFxxx bridge logic costs around $2.

Technically there is really no reason to not havce both.
A NEO sytem could with no problem at all implement USB and DFF chipset and CIAs for nearly not money.

Offline matthey

Re: newb questions, hit the hardware or not?
« Reply #42 on: July 16, 2014, 12:16:29 AM »
Quote from: Thomas Richter;769032
I pretty much doubt this. If there is no cliprect (i.e. the rastport has no layer) graphics.library goes directly to the hardware on native amigas. There is no overhead in such a case. Again, before making such claims, please measure.

If there is a graphics card, it goes to the hardware of the graphics card if it supports 2D acceleration, same story. Only difference: It works on all hardware.


I agree with your point on using the AmigaOS (where possible given constraints) but I disagree with the "no overhead" claim to using the AmigaOS, even if it "goes directly to the the hardware". Function calls through the jump table have overhead and compiled AmigaOS code is not optimal. For example, your new layers.library is riddled with instructions like:

   lea (0,a6),a4  ; optimize to move.l a6,a4
   move.l #0,-(sp) ; optimize to clr.l -(sp)
   lea (a3),a6 ; optimize to move.l a3,a6

That's just talking about peephole optimizations. It's compiled for the 68000 which isn't a huge loss with this particular code but it's a few percent more. Actually, the biggest gain could be using the auto word extension of address registers which SAS/C doesn't take advantage of (MVS or MOVE.W+EXT.L fusion/folding would be a huge gain with this code). There is no instruction scheduling for superscalar processors like the 68060. Cache accesses sometimes look like they aren't even avoided like this:

   move.w (a5),d0
   move.w (a5)+,d1  

We are not talking about a cycle or 2. All these lack of optimizations add up and then programmers roll their own code to gain 10%+ speed over the AmigaOS. I want programmers to use the AmigaOS functions (but not required). We need to improve compilers and try to make code close to optimal for this to happen. Call me a cycle counter and ignore me if you like.

Quote from: Thorham;769052
Write software that's fast on 20s and 30s with AGA, and when possible OCS/ECS, while keeping it system friendly, but without sacrificing speed (no need for syskill practices, custom screens and what not, of course).


With a little bit of learning, it's possible to write code that is fairly optimal on the 68020-68060. Instruction scheduling for a 68060 generally doesn't affect 68020/68030 performance but can double 68060 performance with some code. Learning about modern CPU pipelining, superscalar execution, caches, hazards/bubbles, etc. (not just 68020/68030 timings and specifics) will improve your code for the 68020/68030 also. We may get a superscalar 68k fpga CPU someday where your code will magically be much faster too ;).

Quote from: biggun;769054
What you say it correct.

But it does not need to be like this.
A CIA need minimal FPGA
By adding the smallest and cheapest FPGA to a new system - every system could be made CIA compatible for a price of close to nothing.

The same is true with USB and accessing them via DFFxxx registers.
A USB to DFFxxx bridge logic costs around $2.

Technically there is really no reason to not havce both.
A NEO sytem could with no problem at all implement USB and DFF chipset and CIAs for nearly not money.


The SAM 440 and 460 have a small Lattice fpga. The mentality of some of the so called next generation Amiga guys is to get away from hardware dependency. They also may be trying to keep their AmigaOS closed for proprietary and security reasons.
 

Offline psxphill

Re: newb questions, hit the hardware or not?
« Reply #43 on: July 16, 2014, 12:28:37 AM »
Quote from: matthey;769066
The mentality of some of the so called next generation Amiga guys is to get away from hardware dependency.

If you can't hit the hardware to read the mouse buttons then it's not an Amiga. However that only supports two ports, if you want more than two then you need to use the OS.
 

Offline LiveForIt

Re: newb questions, hit the hardware or not?
« Reply #44 on: July 16, 2014, 06:04:47 AM »
Quote from: Thorham;769052
On 20s and 30s there's no need for that, Especially the mouse and keyboard are very easy to handle properly with the OS.


its even easier to check the BITS, that's way some developers do it.
No need to reply intuition messages and so on, its maybe more common in games and demos.

Quote
and if some user can't use this, then I wonder how their Amiga is set up.


Some people like to use ModePro or some tool like that :-)
lol

Quote
Only using the OS in general is unacceptable for me, because it only helps NG users.


Not really, many Amiga1200/4000 users have Opalvision/Cybervison64/Cybervison3D/BlizzardVision, Grex/Mediator bus board upgrades some Roaden graphic card, sure they get around it by simply selecting a different video source on the monitor or some thing like that, or have two monitors connected, Its maybe more of convenience for this people, but might be problem for some with out scan double if they exist.

:-)