Amiga.org
Amiga computer related discussion => Amiga Hardware Issues and discussion => Topic started by: mikej on November 23, 2015, 04:01:42 PM
-
Jim Drew and I have been working on an RTG implementation for the Replay (FPGAArcade) board.
I've implemented the display engine and dedicated blitter which is working fine, and the system is in a usable beta.
http://www.fpgaarcade.com/2015/11/21/amiga-rtg-graphics-card-working-and-in-beta/
The card driver is based on publicly available information, but we noticed the blitter is not used as much as expected.
To move forward, we would very much appreciate any details on the driver SDK or APIs for Picasso96.
This is not meant to be an open/closed/IP debate, I realize the waters are somewhat murky here, but to find a way forward which minimizes the amount of work and makes best use of the code currently available.
If Picasso96 is the best thing available now, it seems daft for us to re-invent the wheel when there are other fun things to be done.
/MikeJ
-
Oh, I forgot to add I have developer hardware available at cost if anybody is interested in working on this (or any other) area. May have minor cosmetic issues etc - mail me if interested.
/MikeJ
-
Just noticed when clicking on those images to see the bigger versions that the left image goes to:
http://www.fpgaarcade.com/wp4/wp-content/uploads/2015/11/rtg2.jpg
Instead of:
http://www.fpgaarcade.com/wp4/wp-content/uploads/2015/11/rtg1.jpg
As you probably intended.
All looking good and I hope that there is a good solution to all of this.
Andy
-
Strange. Seems to be fixed after a refresh. Thanks.
-
Oh, I forgot to add I have developer hardware available at cost if anybody is interested in working on this (or any other) area. May have minor cosmetic issues etc - mail me if interested.
/MikeJ
Have you already contacted Toni about it? If someone has deep insight knowledge then he
-
Have you already contacted Toni about it? If someone has deep insight knowledge then he
Not specifically, although Jim may have. I examined UAE of course when working on the first cut of the driver.
-
I asked Toni some basic questions when we were trying to figure out the problem with monitor files not even appearing in the ScreenMode setup.
The UAEGFX monitor file source really doesn't help with the Picasso96 stuff. It just gives you a basic monitor file skeleton (which is nice). I am looking for info on the system patches that are available for replacement. The PicassoIV monitor driver has a bunch in there - more than any other Picasso96 supported board. I have disassembled the monitor file some, and I should be able to use the disassembly along with a few bits of source code from FUSION to figure out some of the system patches. I have a PicassoIV board in my A3000, so I can look at system vectors as well and see what doesn't point to the normal Intuition/Graphics routines.
-
I asked Toni some basic questions when we were trying to figure out the problem with monitor files not even appearing in the ScreenMode setup.
The UAEGFX monitor file source really doesn't help with the Picasso96 stuff. It just gives you a basic monitor file skeleton (which is nice). I am looking for info on the system patches that are available for replacement. The PicassoIV monitor driver has a bunch in there - more than any other Picasso96 supported board. I have disassembled the monitor file some, and I should be able to use the disassembly along with a few bits of source code from FUSION to figure out some of the system patches. I have a PicassoIV board in my A3000, so I can look at system vectors as well and see what doesn't point to the normal Intuition/Graphics routines.
@Jim
You could patch setFuncrion() early in the SS (removing set patch if not needed for the test) and print which function is been patched and the name of the task doing it then you'll know.
Kamelito
-
Have you considered using AROS/m68k instead? It is quite capable. I have a plan to build a minimalistic OS3.1 like AROS distribution, targeting MIST and Minimig for now as those are systems I have.
-
I am looking for info on the system patches that are available for replacement.
This is completely irrelevant for driver development. P96 patches over half of gfx to get its services announced, but the monitor driver is unrelated to that. It is the rtg.library which does that. The monitor and card files are regular libraries that offer their services to the rtg.library and provide elementary services for programming the video chip on the card, and provide basic facilities for 2D hardware acceleration.
-
This is completely irrelevant for driver development. P96 patches over half of gfx to get its services announced, but the monitor driver is unrelated to that. It is the rtg.library which does that. The monitor and card files are regular libraries that offer their services to the rtg.library and provide elementary services for programming the video chip on the card, and provide basic facilities for 2D hardware acceleration.
Thanks Thomas, that makes sense.
ORI.L #(1<<15),(PSSO_BoardInfo_Flags,A2) ; BIF_BLITTER
LEA (BlitRectNoMaskComplete,PC),A1
MOVE.L A1,(PSSO_BoardInfo_BlitRectNoMaskComplete,A2)
LEA (BlitRect,PC),A1
MOVE.L A1,(PSSO_BoardInfo_BlitRect,A2)
LEA (WaitBlitter,PC),A1
MOVE.L A1,(PSSO_BoardInfo_WaitBlitter,A2)
-
Thanks Thomas, that makes sense.
We need to look more into the card driver and make sure we are setting all the board info flags. For example, during setup ( InitCard: )
ORI.L #(1<<15),(PSSO_BoardInfo_Flags,A2) ; BIF_BLITTER
LEA (BlitRectNoMaskComplete,PC),A1
MOVE.L A1,(PSSO_BoardInfo_BlitRectNoMaskComplete,A2)
LEA (BlitRect,PC),A1
MOVE.L A1,(PSSO_BoardInfo_BlitRect,A2)
LEA (WaitBlitter,PC),A1
MOVE.L A1,(PSSO_BoardInfo_WaitBlitter,A2)
We only ever see blit calls with mode 12 (dst = src). This is all we have implemented, but would be good to know if we can do more.
Likewise, for supported modes
ORI.W #$3FF2,(PSSO_BoardInfo_RGBFormats,A2)
Seems to be correct, but I want to add additional formats so I need to figure out the bits I need. I'll have a read around, maybe the details on the BoardInfo struct are documented and I missed it.
-
Have you considered using AROS/m68k instead? It is quite capable. I have a plan to build a minimalistic OS3.1 like AROS distribution, targeting MIST and Minimig for now as those are systems I have.
i think they are dismissing it since mikej said in the initial post:
"it seems daft for us to re-invent the wheel when there are other fun things to be done."
so i wouldnt try to pursue this further.
what concerns minimal aros that runs on an unexpanded amiga or the like, im also messing a bit with that. though currently im stuck because of few issues. for instance my desktop of choice, scalos is causing an illegal instruction fault. if you like we could make a separate thread on this subject.
-
"Have you considered using AROS/m68k instead? "
Happy for people to run whatever they wish! I can help with drivers etc as required.
-
"Have you considered using AROS/m68k instead? "
Happy for people to run whatever they wish! I can help with drivers etc as required.
it is not a problem with aros68k, it will accept a driver in a p96 format if you succeed to build one;)
my aros proposal was only meant as general solution to a repeated problems different parties are facing. but i have created a separate thread in case anyone has something to say in the matter:
http://www.amiga.org/forums/showthread.php?t=70091
please let us stay on topic. im eager to see you succeed, mike.
-
Sure, appreciated. The P96 driver for Replay is already working and the binary for now is on my forum. Please feel free to give it a go under AROS if you fancy, and let me know if you need any hardware to play with.
-
@kolla
tbh, i dont know how to boot your arcade with rtg support. i guess you have an 1mb kickstart? if you were softkicking from amiga kickstart you would have to:
AROSBootstrap ROM boot/amiga/aros.hunk.gz somecard.card somecard.chip
at the beginning of the s-s, but maybe it can be just compiled in, better ask toni;)
-
@kolla
tbh, i dont know how to boot your arcade with rtg support. i guess you have an 1mb kickstart? if you were softkicking from amiga kickstart you would have to:
AROSBootstrap ROM boot/amiga/aros.hunk.gz somecard.card somecard.chip
at the beginning of the s-s, but maybe it can be just compiled in, better ask toni;)
Slightly off topic, but you can upload any ROM images you fancy anywhere.
In the .ini file :
# F80000, 0x40000 256K ROM FC0000 also mirrored to F80000
# F80000, 0x80000 512 ROM
# E00000, 0x80000 then F80000, 0x80000 1M ROM
#ROM = kick.rom,0x40000,0x00F80000
#ROM = kick_13.rom,0x40000,0x00F80000
#ROM = kick_13.rom,0x40000,0x00FC0000
ROM = kick_31.rom,0x80000,0x00F80000
-
@mikej
the problem is that aros rom is full being 1mb, i suppose. and especially since drivers come separately and under different licenses from the hardware vendors they have to be loaded from disk, no matter if we are talking about graphic or a lan card. i think it is also a reasonable way. aros and its kickstart should provide only a basic and common set of drivers, the amiga hardware ones and maybe a vesa one for rtg cards. third party drivers should be loaded from disk imho.
-
Thanks Thomas, that makes sense.
We need to look more into the card driver and make sure we are setting all the board info flags.
P96 is very much built around the capabilities of comtemporary (at its time) VGA chips and hence only accelerates blitter calls that are native (or typical) for such chips. Fully configurable min-term blitting was beyond any VGA chip, even more so as these typically work with chunky memory organizations and not planar organizations, like the Amiga.
As such, it only uses the on-board blitter to fill a rectangle, invert one, or copy one rectangle to another. The only additional function that could be speed up is BltTemplate(), i.e. a blitter function that takes a binary mask and draws the foreground in one color, and either draws the background in the second color or leaves it transparent. This is what the graphics.library Text() is built upon, and BltTemplate() of course.
The low-level interface looks somewhat different, but it can provide hardware acceleration for them.
The second additional hardware feature P96 supports is a cursor (aka "sprite" in Amiga terms). It is an optional feature.
The Picasso-IV is special in the sense that it supports also video overlays, though even the internal documentation of P96 does not say how these work or how the interface is defined.
-
"As such, it only uses the on-board blitter to fill a rectangle, invert one, or copy one rectangle to another."
Ok, we've got the copy covered. I haven't seen fill or invert called, but there may be flags to enable this which we haven't found yet.
I've implemented hardware sprite for the cursor and that works fine.
Thanks,
Mike
-
We only ever see blit calls with mode 12 (dst = src). This is all we have implemented, but would be good to know if we can do more.
Likewise, for supported modes
ORI.W #$3FF2,(PSSO_BoardInfo_RGBFormats,A2)
Seems to be correct, but I want to add additional formats so I need to figure out the bits I need. I'll have a read around, maybe the details on the BoardInfo struct are documented and I missed it.
$3ff2 = %0011111111110010
Are the following modes with a '1' in front the ones currently supported?
0 RGBFB_NONE ; no valid RGB format (should not happen)
1 RGBFB_CLUT ; palette mode, set colors with LoadRGB32, etc.
0 RGBFB_R8G8B8 ; TrueColor RGB (8 bit each)
0 RGBFB_B8G8R8 ; TrueColor BGR (8 bit each)
1 RGBFB_R5G6B5PC ; HiColor16 (5 bit R, 6 bit G, 5 bit B), format: gggbbbbbrrrrrggg
1 RGBFB_R5G5B5PC ; HiColor15 (5 bit each), format: gggbbbbb0rrrrrgg
1 RGBFB_A8R8G8B8 ; 4 Byte TrueColor ARGB (A unused alpha channel)
1 RGBFB_A8B8G8R8 ; 4 Byte TrueColor ABGR (A unused alpha channel)
1 RGBFB_R8G8B8A8 ; 4 Byte TrueColor RGBA (A unused alpha channel)
1 RGBFB_B8G8R8A8 ; 4 Byte TrueColor BGRA (A unused alpha channel)
1 RGBFB_R5G6B5 ; HiColor16 (5 bit R, 6 bit G, 5 bit B), format: rrrrrggggggbbbbb
1 RGBFB_R5G5B5 ; HiColor15 (5 bit each), format: 0rrrrrgggggbbbbb
1 RGBFB_B5G6R5PC ; HiColor16 (5 bit R, 6 bit G, 5 bit B), format: gggrrrrrbbbbbggg
1 RGBFB_B5G5R5PC ; HiColor15 (5 bit each), format: gggrrrrr0bbbbbbgg
0 RGBFB_Y4U2V2 ; 2 Byte TrueColor YUV (CCIR recommendation CCIR601).
0 RGBFB_Y4U1V1 ; 1 Byte TrueColor ACCUPAK.
If so then this is RGBFB_CLUT|RGBFB_R5G6B5PC|RGBFB_R5G5B5PC|RGBFB_A8R8G8B8|RGBFB_A8B8G8R8|RGBFB_R8G8B8A8|RGBFB_B8G8R8A8|RGBFB_R5G6B5|RGBFB_R5G5B5|RGBFB_B5G6R5PC|B5G5R5PC.
Include Picasso96.i from the P96 SDK to get the values for RGBFormat. For example, to add 24 bit modes this would be changed to RGBFB_CLUT|RGBFB_R8G8B8|RGBFB_B8G8R8|RGBFB_R5G6B5PC|RGBFB_R5G5B5PC|RGBFB_A8R8G8B8|RGBFB_A8B8G8R8|RGBFB_R8G8B8A8|RGBFB_B8G8R8A8|RGBFB_R5G6B5|RGBFB_R5G5B5|RGBFB_B5G6R5PC|B5G5R5PC or $3ffe. Be careful though as RGBFormat is a ULONG and this is only using the least significant 16 bits. The upper 16 bits of RGBFormat are currently unused by the external P96 API but should be zero.
-
Ok, we've got the copy covered. I haven't seen fill or invert called, but there may be flags to enable this which we haven't found yet.
It's simply called if the minterm of BltBitMap() is set such that the destination is inverted (i.e. D=not C IIRC) and the mask value is 0xff. The same goes for fill, it's a matter of a fitting minterm.
-
$3ff2 = %0011111111110010
Are the following modes with a '1' in front the ones currently supported?
Yes. Thanks, 0x3FFE should enable the 24 bit modes when I add them. Thanks for the pointer to the header file, that's really useful.
-
Thanks Thomas, I'll take a look.
-
@kolla
tbh, i dont know how to boot your arcade with rtg support. i guess you have an 1mb kickstart? if you were softkicking from amiga kickstart you would have to:
AROSBootstrap ROM boot/amiga/aros.hunk.gz somecard.card somecard.chip
at the beginning of the s-s, but maybe it can be just compiled in, better ask toni;)
Not sure if you intended to address me? I have only booted AROS successfully on Minimig, bootstrapped from AmigaOS, loading the 1MB AROS kickstart to RAM. I intend to trim down the kickstart, throw out everything strictly not needed, so it fits within 512kB and can be loaded directly by the Minimig without going via AmigaOS. When 1.5 MB of non-chip RAM is all you have, you don't want 1MB to vanish for no good reason ;) I know Chaos who is doing Minimig implementation for MIST is doing some work so the 1MB AROS kickstart will load on MIST.
-
Not sure if you intended to address me? I have only booted AROS successfully on Minimig, bootstrapped from AmigaOS, loading the 1MB AROS kickstart to RAM. I intend to trim down the kickstart, throw out everything strictly not needed, so it fits within 512kB and can be loaded directly by the Minimig without going via AmigaOS. When 1.5 MB of non-chip RAM is all you have, you don't want 1MB to vanish for no good reason ;) I know Chaos who is doing Minimig implementation for MIST is doing some work so the 1MB AROS kickstart will load on MIST.
AROS should run on Replay as-is (64M of RAM). I'm happy to give it a go if you mail me the files. 1M ROM is already supported.
/Mike
-
AROS should run on Replay as-is (64M of RAM). I'm happy to give it a go if you mail me the files. 1M ROM is already supported.
/Mike
in case you want to run a current nightly build they are here:
http://aros.sourceforge.net/nightly1.php
the rom images are either on the floppy or on the boot iso, boot/amiga directory, but i dont know if its a in a proper format you need. you dont need the floppy otherwise, if you can boot from hd. decompress the iso to a bootable partition and off you go.
there is currently aome problem with screenmode prefs, but otherwise it should work.
-
in case you want to run a current nightly build they are here:
http://aros.sourceforge.net/nightly1.php
the rom images are either on the floppy or on the boot iso, boot/amiga directory, but i dont know if its a in a proper format you need. you dont need the floppy otherwise, if you can boot from hd. decompress the iso to a bootable partition and off you go.
there is currently aome problem with screenmode prefs, but otherwise it should work.
Content of AROS-20151124-amiga-m68k-boot.lha is:
aros-amiga-m68k-rom.bin 512 kB
aros-amiga-m68k-ext.bin 512 kB
aros-amiga-m68k-ram.elf 1450768 B
bootdisk-amiga-m68k.adf 901120 B
It is obvious for me what adf, rom.bin and ext.bin are, but what is the ram.elf file?
-
I am guessing that .elf = is the PPC version, since that is what the PPC code hunks are called.
Where do the AROS rom.bin and ext.bin get mapped into the Amiga's address space?
NOTE!! Apparently AROS already works fine with the Replay board... from the AROS website:
AROS at AmiWest 2012
Author:Jason McMullan Date:2012-11-02 At AmiWest 2012, Samuel Crow and Jason McMullan demonstrated AROS v1 running on the Sam460ex from ACube (http://acube-systems.biz), the FPGA Arcade Replay from FPGA Arcade (http://www.fpgaarcade.com), and the Raspberry PI from the Raspberry PI Foundation (http://www.raspberrypi.org).
-
I am guessing that .elf = is the PPC version, since that is what the PPC code hunks are called.?
no, it was used for ppc, but elf is simply binary code format as opposed to amiga hunk format. gcc generates currently binaries in this format. aros68k can load both (in my experience elf loading is faster) but to be run under amiga binaries need to be converted to hunk. aros provides a tool elf2hunk and converts also the aros binaries contained in the iso to hunk. practically when softkicking aros only needs arosbootstrap to be in hunk.
i dont know about the floppy, but the iso/boot/amiga contains either aros.elf (not converted, as i compile it) or aros.hunk.gz images.
Where is the AROS rom.bin and ext.bin get mapped into the Amiga's address space?
i guess kickstart needs to be mapped to an address where it is expected to boot from, but i dont know. best ask toni on eab.
-
NOTE!! Apparently AROS already works fine with the Replay board... from the AROS website:
AROS at AmiWest 2012
Author:Jason McMullan Date:2012-11-02 At AmiWest 2012, Samuel Crow and Jason McMullan demonstrated AROS v1 running on the Sam460ex from ACube (http://acube-systems.biz), the FPGA Arcade Replay from FPGA Arcade (http://www.fpgaarcade.com), and the Raspberry PI from the Raspberry PI Foundation (http://www.raspberrypi.org).
sure it should, as fpgaarcade provides amiga compatible hardware. jason even presented it on amiwest, but then there was only 68000 implementation without aga i guess, so it might not have been that impressive. jason have been amiga68k developer together with toni.
-
Looks like the ext-bin.rom is PC relative and can be placed either in the 0xE0 area, or the 0xF0 area, with the main rom in the normal 0xF8 area. I will setup a HD partition and .ini for Replay and try it. I don't expect any issues.
I have only worked with .elf hunks on PPC machines (Amiga with PPC and PowerMacs). I didn't realize it was a new hunk type in general.
-
I don't expect any issues.
if there is any, aros nightly has enabled debug output on serial, baudrate 115200
-
I changed the mode ID from 0x3FF2 to 0x3FFE and saw no difference in features or performance. I guess I need to really need to thoroughly disassemble the PicassoIV monitor file to figure out the system hooks.
-
I have only worked with .elf hunks on PPC machines (Amiga with PPC and PowerMacs). I didn't realize it was a new hunk type in general.
https://en.wikipedia.org/wiki/Executable_and_Linkable_Format
-
if there is any, aros nightly has enabled debug output on serial, baudrate 115200
Hm, isn't that a wee bit too high baudrate for an Amiga?
-
Hm, isn't that a wee bit too high baudrate for an Amiga?
too high? why? i have been using serial logging with this setting on aros from the beginning with no problem, i guess i tested even with an 68020.
-
Yes, I suppose for logging it works well enough. For data transfers, be it zmodem or IP over PPP, 115200 is not at all reliable, even 57600 is stretching it. 38400 works most of the time.
-
Gunnar BigGun said to me he have the Picasso96 SDK...
I asked to give it to me, but no answer some years ago...
Ask him, maybe you will be lucky...
-
Gunnar BigGun said to me he have the Picasso96 SDK...
I asked to give it to me, but no answer some years ago...
Ask him, maybe you will be lucky...
They're looking for the DDK, the SDK is freely available. Maybe just a typo...
Kamelito
-
Yes, I suppose for logging it works well enough. For data transfers, be it zmodem or IP over PPP, 115200 is not at all reliable, even 57600 is stretching it. 38400 works most of the time.
It depends on what else is going on. There were replacement serial.device where 115200 would work ok, especially on an a1200.
If you're using 16 colour highres screens on ECS or run a "blitter nasty" patch then you'll have more issues.
I don't think aros 68k is currently aimed at the unexpanded a500.
-
Running on RTG 115200 works fine.
-
It's all working fine now - some errors in the soft core T68K bitfield instructions were causing problems.
I've a little work to do now to enable the high frequency clocks and then we'll have 1024, 1280 and maybe 1920 modes over DVI/HDMI/Analogue also.
I've had some conversations with Thomas, but my attempts to reach the original authors have not been successful so far regarding potential licensing.
My P96 driver is based completely on publicly available information, and like UAE the driver (as well as the core shortly) will be open sourced.
The hardware is generic, and the core has a build option for the RTG subsystem at the moment, but as the core implements a generic video display system and blitter it does not have any dependency on P96 - it could be used with alternative software for example.
I was a little surprised to hear that that licensing discussions were on-going for the Apollo/Vampire project,when I was told just a week or two ago that no contact had been made - and I was discouraged from any attempts to release a product.
In my view, it would be a very sad day for what remains of this community if an attempt was made to exclusively license the P96 system.
Anyhow, play nice and have fun.
/Mike
-
I was a little surprised to hear that that licensing discussions were on-going for the Apollo/Vampire project,when I was told just a week or two ago that no contact had been made - and I was discouraged from any attempts to release a product.
In my view, it would be a very sad day for what remains of this community if an attempt was made to exclusively license the P96 system.
You are not the only one...
It's like that on Amiga...
"No mercy" is the rule...
:(
-
Given the much higher volumes of the generic platforms, it wouldn't make sense financially either.
-
I was a little surprised to hear that that licensing discussions were on-going for the Apollo/Vampire project,when I was told just a week or two ago that no contact had been made - and I was discouraged from any attempts to release a product.
In my view, it would be a very sad day for what remains of this community if an attempt was made to exclusively license the P96 system.
*Sigh* I really don't understand this community. No matter what you do, somebody will get it wrong.
There is no attempt to make an "exclusive" deal with Apollo. There is an attempt to create a situation where you can again license P96, no matter whether you are "Apollo" or "not".
The point is not that the P96 rights go to Apollo. Neither will they go to me. The only reason why I took Apollo into the boat was because it was the first team that asked, and a team I had contacts with by pure coincidence, and it was already tough enough to build up an atmosphere of thrust with all parties involved at this point. It wouldn't have made it easier to include another party at this point, but even then, I indicated already (two weeks ago) that there is more than one FPGA team that would be interested in this.
So no, nobody is "off the boat" at this point, and there is no conspiracy to be exclusive or keep somebody off from using P96. We're really early in the negotiations, and I haven't forgotten anyone. It is just too complicated already. As soon as there is something to release to the public, it will be released, really.
The idea is really to keep the P96 license model untouched, in the same way Alex and Tobias originally considered it. The user gets P96 for free, but if you're developing a hardware that depends on a P96 driver, you have to license it - yes (gosh!) for money, for a sum that still has to be discussed. The money does not go into my pocket, or into the pockets of Apollo. But somebody has to keep care of the software, and somebody has to pay the party.
-
Thanks Thomas! It would be nice for this to be possible again!
-
IMO, the better approach would be for all interested teams to band together & negotiate the liberation of P96.
That would be better for everyone, since further development of P96 would finally be possible.
-
IMO, the better approach would be for all interested teams to band together & negotiate the liberation of P96.
That would be better for everyone, since further development of P96 would finally be possible.
Some people in the community are just control freaks and prefer to keep 15 years old code in their closets.
The model that was originally used by Tobias possibly could have some sense back in 1995 when Amiga market was much, much bigger and there were actual companies doing new development for classic Amiga. That licensing model is completely unfit for the current market and limits access to P96 only for the biggest players. I considered developing a new RTG card for classics but I am unwilling to participate in this absurdity.
Currently, we are all just hobbyists working on Amiga stuff whenever our time permits.
@Thomas
How about a bounty to open P96 code? If the money is really an issue, this could solve it.
-
IMO, the better approach would be for all interested teams to band together & negotiate the liberation of P96.
That would be better for everyone, since further development of P96 would finally be possible.
Why do you think that further development is *not* possible if the library is not open source? Actually, I would be glad to have more manpower in the team if I would maintain P96, so where's the problem joining the team?
-
Some people in the community are just control freaks and prefer to keep 15 years old code in their closets.
The model that was originally used by Tobias possibly could have some sense back in 1995 when Amiga market was much, much bigger and there were actual companies doing new development for classic Amiga. That licensing model is completely unfit for the current market and limits access to P96 only for the biggest players. I considered developing a new RTG card for classics but I am unwilling to participate in this absurdity.
Currently, we are all just hobbyists working on Amiga stuff whenever our time permits.
@Thomas
How about a bounty to open P96 code? If the money is really an issue, this could solve it.
sigh.. slowly im tired of reminding everybody who wants to liberate p96 or create a driver for it that there is aros cybergraphics, that would very likely be less hassle to port over to genuine amiga system than getting actual p96 sources released. hell, it even has a wrapper that accepts p96 drivers..
i really dont understand why to make things more complicated and even less likely to happen, even though there are already open solutions out there.
-
Some people in the community are just control freaks and prefer to keep 15 years old code in their closets.
No, that's not the problem. The problem is that in the end somebody must be willing to buy the code, and somebody must be willing to sell the code.
It seems that we are converging to a situation where we have a seller and a buyer, and apparently a buyer who is interested in further development of the code. I would say that this is quite a positive development, even more so as the current seller (Tobias and Alex) have not made any attempt to create a productive environment in the last ten years that would stimulate or even allow its progression. And we have a buyer who expressed a an interest to create exactly that. So it's an improvement, after all. That licensing model is completely unfit for the current market and limits access to P96 only for the biggest players. I considered developing a new RTG card for classics but I am unwilling to participate in this absurdity.
Then don't buy it. Once again, not everything has to be free in this universe, even more so as some party is apparently putting money into it. Its *own* money. It's not morally wrong to buy something for money, you know?
Then again - Do you call me a big player? I don't have any money and I didn't put any money into the pot. I only helped a bit establishing contacts, that's all. Do you call "Apollo" a big player? This is also only a group of hobbyists. Yet, there is a seemingly successful negotiation between the parties which came up with a reasonable price (or so I hope). So if "Apollo" is large enough to handle that, why do you believe that you are "too small" for it either? Currently, we are all just hobbyists working on Amiga stuff whenever our time permits.
Do you believe this is any different for any other player here? I'm a hobbyist, and the people from Apollo are, too. The whole thing just "works" because we came (or will come, hopefully) to the conclusion that the best way of handling the situation is by the exchange of some small green paper sheets. (-:
@Thomas
How about a bounty to open P96 code? If the money is really an issue, this could solve it.
You need two parties for such a deal: A seller, and a buyer. Apparently, you're willing to buy the code? The question is whether the current owner is willing to sell it for such a purpose. I don't know whether the acquisition of P96 is already set in stone, but I somehow doubt that there is any seller in the market that would opt into such a deal. That was my impression, at least.
Even more so, what does it buy you having the code Open Sourced? I would hope that there will be a development environment that encourages people to join the team, so you would get access to the code anyhow. Probably even in exchange of some small green paper slips back into your pocket.
I believe if we get such a deal done, much has been gained, namely again an ongoing development of P96. I don't quite see why that is a problem. It's quite an achievement.
I don't know what the future will bring and whether the current owner has the interest in setting up a development community, but I'm very much for inviting as many trustworthy people into the party as I would love to. But it's not my role to decide that. I can only express my opinion openly, and currently, I have the impression that it has been heard.
Apparently, the negotiations so far worked so well because none of the parties were hard-core Open Source fanatics - we tried to find a pragmatic solution and a compromise that would work fine for everyone in the game. Whether Open Source works or not is a matter of the environment, the players, the users, the personal trust between the parties, the situation around the code, its history, its developers... Given the negotiations, it seems that this was not given for P96. In the end, it looks like it will turn out just fine - it was the matter of pulling the right strings at the right time, and it seems to work. Or that is my impression. We will see. It's not on me to make announcements, I only play a minor role in all of this.
-
sigh.. slowly im tired of reminding everybody who wants to liberate p96 or create a driver for it that there is aros cybergraphics, that would very likely be less hassle to port over to genuine amiga system than getting actual p96 sources released. hell, it even has a wrapper that accepts p96 drivers..
Where can this be found?
-
Where can this be fou cannd?
https://trac.aros.org/trac/about
you can download the nightly sources here:
http://aros.sourceforge.net/de/download2.php
id look for files in question in here:
https://trac.aros.org/trac/browser#AROS/trunk/AROS/rom/graphics
perhaps also around here:
https://trac.aros.org/trac/browser/AROS/trunk/AROS/workbench/libs/cgxvideo
to get detailed information its best to join aros dev-ml or ask toni wilen, who delivered amiga hidd. initially its probably best to compile files within aros build system, which is pretty easy and even i can help with it. but there are instructions, how to do it outside i can point to.
-
im not familiar with aros cgx but i think it can be thought about as reimplementation of graphics library with full color graphics in mind, because it was done for systems equipped with such graphics to start with. amiga chipset graphics frontend has been implemented on top of this (i dont remember the name and am not sure where to look for it in the source right now, i suppose the name was somehow like fake cgx or so). of course this is currently not optimal for planar graphics as most if not all is handled internally in 24bit, but rtg graphics is working fine and fast even on amiga hardware, except some exotic pixel formats, like those 15 and 24 bit of picasso4
some accompanying info i ve just found:
https://en.wikibooks.org/wiki/Aros/Platforms/68k_support/Developer/HIDD
-
Thomas,
Thanks for the response.
"There is no attempt to make an "exclusive" deal with Apollo. There is an attempt to create a situation where you can again license P96, no matter whether you are "Apollo" or "not"."
Sounds great, I'm very relieved to hear. I'm all for a pragmatic way forward, and certainly believe in working out a solution which works for everybody regarding licensing and onwards development.
/Mike
-
Just out of curiosity, is P96 the only available option to us ? And when SAGA is ready - will we even need P96?
Im guessing the only reason its being considered is to enable backwards compatibility with RTG.
Anyone care to comment?
Nick
-
Just out of curiosity, is P96 the only available option to us ? And when SAGA is ready - will we even need P96?
Im guessing the only reason its being considered is to enable backwards compatibility with RTG.
Anyone care to comment?
Nick
If you want to use chunky modes in WB then yes you need P96 or CGFX or AROS.
If you are satisfied with 256 color normal AGA resolutions then no you dont need P96 after SAGA is implemented.
-
Just out of curiosity, is P96 the only available option to us ?
Obviously not, it's just the easiest option as it already exists.
And when SAGA is ready - will we even need P96?
You will still need something, however P96 may not be the easiest option at that point as it was designed for add on cards and not for mixed OCS/ECS/AGA/SAGA graphics.
-
Obviously not, it's just the easiest option as it already exists.
if you just need documentation to write drivers for it, perhaps.
but if is is supposed to go again into the full maintenance modus as thor suggests, it may become more difficult. for starters it would likely have to be made compilable with todays compilers, say gcc 4.x-5.x and so on..
-
Where can this be found?
Cybergraphx v3 and its driver development kit are both freely available, as is the CGXAGA driver for ECS/AGA screenmodes with source.
http://aminet.net/package/driver/video/CyberGraphX3
http://aminet.net/package/dev/misc/CGraphX-DevKit
http://aminet.net/package/driver/video/CGX-AGA
-
Then don't buy it. Once again, not everything has to be free in this universe, even more so as some party is apparently putting money into it. Its *own* money. It's not morally wrong to buy something for money, you know?
Well, free as in beer is certainly a possibility. I asked nicely for a copy of the DDK about 11 years go (yikes!) and received one with the only stipulation being obfuscation of the driver interfaces behind a closed source shim. (But honestly, everything in m68k Amigaland has been decompiled, reverse engineered, and analyzed to death at this point. I'm surprised we even need a DDK.)
-
if you just need documentation to write drivers for it, perhaps.
AFAICT the drivers exist, they are just trying to figure out the licensing issues.
but if is is supposed to go again into the full maintenance modus as thor suggests, it may become more difficult. for starters it would likely have to be made compilable with todays compilers, say gcc 4.x-5.x and so on..
Making aros graphics.library useful on 68k hardware is also going to be difficult, nobody has bothered so far anyway. I wasn't aware that anyone was using modern gcc for 68k either and SAS/C runs in vamos.
-
Cybergraphx v3 and its driver development kit are both freely available, as is the CGXAGA driver for ECS/AGA screenmodes with source.
http://aminet.net/package/driver/video/CyberGraphX3
http://aminet.net/package/dev/misc/CGraphX-DevKit
http://aminet.net/package/driver/video/CGX-AGA
Thanks Nicholas.
The p96 driver is fully working, no need for the DDK.
Could Cybergraphx do a similar job on this new hardware, sans licensing issues?
/MikeJ
-
Thanks Nicholas.
The p96 driver is fully working, no need for the DDK.
Could Cybergraphx do a similar job on this new hardware, sans licensing issues?
/MikeJ
As far as I'm aware developers don't have to pay any licence fee to develop a CGX driver.
The end user is theoretically supposed to pay for CGX if they like using it but the free trial is fully functional with no time limit and CGX3 has been long abandoned for CGX5 which is MorphOS exclusive.
Might be worth contacting Frank Mariak from the MorphOS Team for further clarification.
-
Might be worth contacting Frank Mariak from the MorphOS Team for further clarification.
Will do, thanks.
-
Cybergraphx v3 and its driver development kit are both freely available, as is the CGXAGA driver for ECS/AGA screenmodes with source.
http://aminet.net/package/driver/video/CyberGraphX3
http://aminet.net/package/dev/misc/CGraphX-DevKit
http://aminet.net/package/driver/video/CGX-AGA
What I need is information (or an example) for creating a CLDriver. That info is not contained in these archives. This is the same situation as the Picasso96 card driver. We have a skeleton driver that works, but it is missing a LOT of the hooks for accelerating functions. If there is source code to an actual card driver (CLDriver in the case of CyberGraphics), that would be great!
-
The idea is really to keep the P96 license model untouched, in the same way Alex and Tobias originally considered it. The user gets P96 for free, but if you're developing a hardware that depends on a P96 driver, you have to license it - yes (gosh!) for money, for a sum that still has to be discussed. The money does not go into my pocket, or into the pockets of Apollo. But somebody has to keep care of the software, and somebody has to pay the party.
How is this at all relevant for MIST, FPGA Arcade and other hardware that has no dependance on P96? Remember, it is only when using Amiga softcores that it even becomes relevant to *maybe* use RTG.
Or to put it more correctly - the license model of P96 is stupid.
-
You will still need something, however P96 may not be the easiest option at that point as it was designed for add on cards and not for mixed OCS/ECS/AGA/SAGA graphics.
In my view, CyberGraphX is and was way better. P96 only became "standard" when it was chosen to be included with OS3.5 or 3.9 (I cannot remember). CyberGraphX was firmly planted in what became "the blue camp", whereas P96 became part of the hack&patch mess we currently know as "the red camp".
-
As far as I'm aware developers don't have to pay any licence fee to develop a CGX driver.
The only viable business model.
The end user is theoretically supposed to pay for CGX if they like using it but the free trial is fully functional with no time limit and CGX3 has been long abandoned for CGX5 which is MorphOS exclusive.
Also, CyberGraphX was something _anyone_ could buy, not just "manufacturers". I have personally bought CyberGraphX 4 at least twice, as a user. P96 is only something I have only really used with UAE and Mediator, though I have also tried it on various other hardware (CV64, PicassoIV... stuff I have mostly gotten rid of).
-
Or to put it more correctly - the license model of P96 is stupid.
Ok, what is the license model or business model you would put forward? Let the tax payer pay for the work on the driver?
You can either let the users pay for something (and given the "business mentality" I get here, I would expect it would be sold once, then copied forever) or you can get the hardware vendors to pay for it, which means that you let at least someone pay that generates some income from the work.
In the end, who will pay the developers for P96? The state? Social welfare?
Sorry, but I've other plans with my life. If you want P96 to be maintained, *somebody* has to pay for it *somehow*. I consider it fair enough if someone in the market chain does that, and not the general public.
-
Also, CyberGraphX was something _anyone_ could buy, not just "manufacturers".
Could you please stop the bull%&$#?@!%&$#?@!%&$#?@!%&$#?@!? Ok, here's a little one-Oh-one of the market:
The customer pays X+Y euro/dollar to the manufacturer. The manufacturer pays Y euro for the license.
Question: Where does X+Y come from and who bought the license?
Ok, I get it: No matter what I do, I do it wrong. If I give users the opportunity to get *some* drivers for some boards for free I'm bad because I don't give them the opportunity to pay for my software. If I let users pay for the software in first place, I'm damned because I'm using an evil closed source model and rip off the users for worthless software.
Is that approximately how your thinking goes?
Now, if everything is for free, and the user gets the software for free, and the manufacturer gives the hardware for free, and the developer gives the driver for free, do I get my lunch for free as well?
Or do I send the bill to Norway and will you pay for it?
Kolla, with all necessary respect: Don't you get how stupid this is?
-
I'm keeping my head down here, but :
Or do I send the bill to Norway and will you pay for it?
Maybe we in the Nordic countries can have a whip-round and buy it. Actually, not going to the pub here once would probably pay for it.
On a serious note however, I would question the "If you want P96 to be maintained" statement. Actually, for me it works great as is - admittedly using the legacy OS it was designed for.
/Mike
-
@Thomas
Even if its for free, people will complain its not updated/maintained ;)
So you are right, you cant win!
-
On a serious note however, I would question the "If you want P96 to be maintained" statement. Actually, for me it works great as is - admittedly using the legacy OS it was designed for.
The idea is really to update "a little bit more than P96 alone". But the components have to work with each other, and that's sometimes a bit delicate.
To give you an idea what I'm talking about: When I worked on layers V45, which was approximately in ~2000 or so, I re-did the whole layer-re-arrangement code to be faster and more RTG-friendly. This works so far, but what I did not notice immediately (but only little later) is that the P96 overlay functions for the Pablo board (video overlay) depend on some internal undocumented layer pointers.
Bad, bad, evil P96! Ok, so I was working with Tobias and Alex anyhow, getting some core-level bugs of P96 fixed, and so I had the chance and fixed this P96 issue as well. Unfortunately, T&A lost interest in the whole P96 affair soon after (guess why!) and so the fixed and modified and V45-layers compliant version of P96 never really made it to the end user.
It's probably not the last issue in P96 that would, in the next (near) future require some minor update here and there. Probably to support some features of new hardware, or probably to support some new features of some Os level components.
Now, of course, folks like Kolla could come and say: "Thomas, just work more in your spare time, update layers, then update P96, then update graphics, and here are a couple of bugs in exec as well...". However, as much as I like playing for the system, I don't have all the time to do that, and at some point, one must come to the conclusion that all the enthusiasm of a hand full of people is not enough to get the job done, and it requires some external motivation. AROS is still not there after all the years - not saying that they are doing a bad job - it's just too small a group and too little motivation. Not their fault, not at all!
Probably it needs a motivation that will someone buy some lunch. Not necessarily *my* lunch, but someone's.
It's really more than P96 all over, and I'm really asking to respect that. I don't want to let AmigaOs classic rot more than it is, with everyone patching it together - plus making it incredibly hard to set it up correctly and get it running correctly.
That requires fixing, and it requires that someone has to pay for the lunch of somebody else at some point. It doesn't work "all for free" because we're all so nice people and funded by Norwegian Oil or the German state.
-
That requires fixing, and it requires that someone has to pay for the lunch of somebody else at some point.
Or open source it and then the developers who want somebody else to pay for their lunches can go off and do work that pays and the community can then sort out amongst themselves who can fix the mess.
I know - this is the Amiga community we're talking about - if there is a whiff of even a cent laying around then someone is going to try and extract it.
-
@Thomas Richter
If you are going to mantain it, I hope we (users) get some improvements.
My humble suggestions:
1-The most painfull and user unfriendly program on Amigas is probably Picasso96Mode. Could you please actually redo it, so that it makes sense?
CGX for example, has a very easier counterpart (CGXMode). If you search the web a bit, you will find lots of complaints about this on P96.
2-Add documentation on how to manage multiple gfx cards on P96
3-Implement multi-monitor/multi-display support (extended mode - clone mode)
4-Build a Picasso96 AGA driver which would be very useful (much like a CGXAGA driver counterpart). Even better if you could develop an OCS/ECS one, with of course, a limited feature set.
-
Or open source it and then the developers who want somebody else to pay for their lunches can go off and do work that pays and the community can then sort out amongst themselves who can fix the mess.
I know - this is the Amiga community we're talking about - if there is a whiff of even a cent laying around then someone is going to try and extract it.
It does not look like that the owner is willing to opensource it
@Thomas
I can only express my personal view (not speaking for anyone else)... if amiga history teaches one thing then that the basic components should be free and open and not controlled or property of individuals who can kill it from one day to another. That is also better if you want to attract devs because you can guarantee longterm life in opposite to something controlled by few. I personal would never be willing to invest in closed components. Just my 2 cents and personal view.
-
It does not look like that the owner is willing to opensource it
@Thomas
I can only express my personal view (not speaking for anyone else)... if amiga history teaches one thing then that the basic components should be free and open and not controlled or property of individuals who can kill it from one day to another. That is also better if you want to attract devs because you can guarantee longterm life in opposite to something controlled by few. I personal would never be willing to invest in closed components. Just my 2 cents and personal view.
So you only support AROS?
-
Or open source it and then the developers who want somebody else to pay for their lunches can go off and do work that pays and the community can then sort out amongst themselves who can fix the mess.
At least the costs for the acquisition of P96 need to be covered in some way. P96 does not come for free. Also, Kickstart sources did not come for free either. I know - this is the Amiga community we're talking about - if there is a whiff of even a cent laying around then someone is going to try and extract it.
If it would be just so easy. It's all part of a legacy problem. Kickstart/AmigaOs was a commercial product, P96 was a commercial product. Acquisition of these components was not for free, so it's quite natural that whoever bought it would like to get the money back in the end.
If you look at the Linux community: Lots of developments are sponsored by the larger players: Intel, the Linux distributions (gosh, also paid by users!) like SuSE or RedHat... all of them put money into the pot. Amiga is not quite in such a luxury position.
-
@Thomas Richter
If you are going to mantain it, I hope we (users) get some improvements.
It's probably a bit early for a wish list. The first point is to get the deal done. There are many points on my personal wish list as well, but who does it, if it is done and whether I'm even involved in this is just another question.
-
If you look at the Linux community: Lots of developments are sponsored by the larger players: Intel, the Linux distributions (gosh, also paid by users!) like SuSE or RedHat... all of them put money into the pot. Amiga is not quite in such a luxury position.
Amiga developers, on the other hand, seems to do do everything within their power to *not* make money on their stuff. :p
-
1-The most painfull and user unfriendly program on Amigas is probably Picasso96Mode. Could you please actually redo it, so that it makes sense?
Nah, there's plenty worse programs than Picasso96Mode. Heck, even I was able to figure it out. Sort of. Ha! ;)
Maybe this will help? https://www.youtube.com/watch?v=n8lLfEuVI2Y
PS - I ramble a lot. ;)
-
So you only support AROS?
I support open standards and open sources to guarantee availability even in longterm. Neither Hyperion nor MorphOS team is interested in that and 3.X is hold hostage by several companies. Then there is not much left. BTW components like the CybergraphX from Aros could be improved and backported to 3.X then you would have both, the beloved old components and open standards.
-
Amiga developers, on the other hand, seems to do do everything within their power to *not* make money on their stuff. :p
sounds as if you knew better how to make money here. which i doubt that there is any generally sensible method for. including so called amistores or the like, but that can be confirmed or argued against by actually involved with such alternatives.
-
Picasso96Mode
this program is probably almost completely unnecessary as of today. when using flatscreens with their normed frequencies, almost no tolerances, and fixed native resolutions, user defined display modes will likely rather lead to problems then solve any. hard coded standard resolutions is much more sensible approach in this respect.
-
Perhaps PicassoModeTNG is easier - btw it's the tool to flash Picasso IV FliFi http://www.sophisticated-development.de/software/P-IV/pmtng-2.9.lha
-
looks like wise people do the right things. judging by who is involved, it looks like aros based rtg driver for kick 3.x amiga600/vampire instead of p96 one done within few days since the developer received the hardware.
its not like i want to credit anything on foreseeing this as best option, simplz want to indicate how things can be done with least effort for most advantage of community avoiding the whole barrage of licensing issues.