Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
64 user(s) are online (29 user(s) are browsing Forums)

Members: 0
Guests: 64

more...

Support us!

Headlines

Forum Index


Board index » All Posts (kas1e)




Re: Pegasos2 with RadeonHD/RX via bridge
Home away from home
Home away from home


@All
Tried this adapter in end of all : https://www.ebay.com/itm/125723908233

Tried it with both bridges : pericom and pex ones, and in both cases in firmware when i go to the pci@C0000000 (agp area) all i have is pci@8 , properties on which show that this is bridge (so both bridges detects correctly via adapter), but , both didn't see a graphics card in.

One time i was lucky (probably was some bad attachment of adapter or something), and instead of just pci@8 in pci@C0000000, i did have about 20 different pci's (pci@1, pci@2, pci@3, etc), in which card were detected ! (both audio and video parts). But that was just one time, and does not matter how hard i tried to reproduce it, i always can't. While when bridge just in pure PCI without adapters all fine and detects by firmware fine.

So probably conclusion is : this missed "lock" signal is what made it not works. The one time detecting was probably some bug in this lock signal handling or something.

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top


Re: Nova Bridge - where?
Home away from home
Home away from home


@Hans
Your work is one of not many valuable things in whole Enhancer, and its indeed sucky how Mattew handle sales and in whole amistory problems users have all the time.

Is it possible to ask them to give you ability to sell things you do, with giving them their part ? Or maybe rebuy it back so you will have the rights to sell it ?

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top


Re: Nova Bridge - where?
Home away from home
Home away from home


@elfpipe
Max wrote java clone of amistore which you can use to buy things from OS where java works (i mean PC with windows at least): https://github.com/migthymax/JAmiStore

I never understood why there wasnt pc version of amistore compiled (as it hollywood in end) or simple webshop to use from any os, but that how is it

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top


Re: Pegasos2 with RadeonHD/RX via bridge
Home away from home
Home away from home


@joerg
Right, but i mean to put pci2pcie bridge in this adapter, so to use agp to double speed (as agp in peg2 its pci but not on 33, but on 66)


Edited by kas1e on 2024/7/2 11:32:24
Join us to improve dopus5!
AmigaOS4 on youtube
Go to top


Re: Qemu + VFIO GPU RadeonRX 550 + AmigaOS4 extremely slow
Home away from home
Home away from home


@Hans
I can test it on real peg2 and on qemu's peg2, but in snipped you post usSize is undeclared and usDelay = ; (no value).

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top


Re: Pegasos2 with RadeonHD/RX via bridge
Home away from home
Home away from home


@Sailor
It takes a while, but i at last received this AGP-to-PCI(e) adapter we talk about on the first page from there: https://www.ebay.com/itm/125723908233

Takes 2 just in case, but then i probably will test them once Hans deal with casual bridge , as there are changes that with this kind of adapters and tests around it my pegasos2 will burn and die, so firstly want to be able to finish testing of what Hans is working on, and then will test this adapter.

@All
Hans progressing pretty well with replacing non-working-with bridges RTAS way os4 kernel uses for pegasos2, to the direct PCI reading/writing way, and currently there few bits to fix before it can come up with something, but at least we surely have correct addresses of video memory now, things which remain is to fix some registers reading, and then there high chance it will work! Rise of Frankenstein !

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top


Re: Qemu + VFIO GPU RadeonRX 550 + AmigaOS4 extremely slow
Home away from home
Home away from home


@balaton
But radeonhd/radeonrx do not work on real pegasos for now: This is unpossible directly (due having only agp and pure pci), but over bridge it also currenly dont work: RTAS way (which peg2's os4 kernel use to read pci registers, etc) not works, so Hans tried to deal with it by direct reading of regs, test of which show that this way works, and once Hans will find time to update kernel with new code, i will be able to test it, and only then we can see if we have or not have same issue you talk about on real Pegasos.

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top


Re: What the fastest possible x64 emulation way of OS4 today ?
Home away from home
Home away from home


@all
Is someone able to use siliconmotion502 53.12 from os4depot with qemu 9.0/peg2 emulation ? All i have is black screen, while version of driver from os4-update3 works for sure.

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top


Re: Qemu + VFIO GPU RadeonRX 550 + AmigaOS4 extremely slow
Home away from home
Home away from home


@Balaton
Quote:

Does anybody know what Linux versions worked on real pegasos2?


Debian 8.11 is the one i install and use 2 months ago on my real pegasos when we test bridges in peg2/radeonhd thread you may remember. But you should not use netinstall.iso as it have bug on installation (not fully finished post install steps resulting in non booting system), so you had to use the one called debian-8.11.0-powerpc-DVD-1.iso instead, which installs and works fine on my real peg2

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top


Re: NovaBridge released!
Home away from home
Home away from home


@Maijestro
If you build latest code from their github, then you got latest version with a1222 fix in (it was one of the latest commits)

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top


Re: NovaBridge released!
Home away from home
Home away from home


@Maijestro
Yeah, rewarp is warpos support (powerpc.library) and rewarp3d is for warp3dppc.library support: some games and demos uses them back in past. For example old madwizzar's demos, old wipeout version, etc.

In other words if you have no needs in old classic warpos based stuff, they of no needs for you. Just install warp3dnova for basic 3d support, then novabridge for old minigl/warp3d support, and ogles2.library for games uses ogles2 and gl4es

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top


Re: Tracing of callhookpkt()/callhook()
Home away from home
Home away from home


@joerg
Quote:

Are you sure IUtility->CallHook() doesn't include m68k support?
That would be very strange.


Do some debugging with GDB and find out that even for IUtility->CallHook(.....) there seems to be 68k emulator check too (while, it different functions still, and not simple use of CallHookPkt() inside), see:

test case:

#include 

uint32 MyFunction (struct Hook *hVOID *oVOID *msg)
{
        
printf("test\n");
        return(
1);
}

int main()
{
        
struct Hook h;

        
h.h_Entry MyFunction;
        
h.h_SubEntry NULL;
        
h.h_Data NULL;

        
IUtility->CallHook(&h,NULL,NULL);

        exit(
0);
}


And gdb output:

(gdb) break main
Breakpoint 1 at 0x1ffb152c
file callhook_static.cline 16.
(gdbr
Starting program
: /WinDH_D/cygwin_gcc_11_3/amiga/hooks/tracer/tests/callhook_static 

Breakpoint 1
main () at callhook_static.c:16

(gdbdisas

Dump of assembler code 
for function main:
0x1ffb152c :    stwu    r1,-48(r1)
0x1ffb1530 :    mflr    r0
0x1ffb1534 
:    stw     r0,52(r1)
0x1ffb1538 :   lis     r9,8187
0x1ffb153c 
:   addi    r9,r9,5376
0x1ffb1540 
:   stw     r9,24(r1)
0x1ffb1544 :   li      r9,0
0x1ffb1548 
:   stw     r9,28(r1)
0x1ffb154c :   stw     r9,32(r1)
0x1ffb1550 :   lis     r10,15555
0x1ffb1554 
:   lwz     r3,-10520(r10)
0x1ffb1558 :   stw     r9,8(r1)
0x1ffb155c :   lwz     r9,132(r3)
0x1ffb1560 :   mtctr   r9
0x1ffb1564 
:   li      r5,0
0x1ffb1568 
:   addi    r4,r1,16
0x1ffb156c 
:   crset   4*cr1+eq
0x1ffb1570 
:   bctrl
0x1ffb1574 
:   li      r3,0
0x1ffb1578 
:   bl      0x1ffb1598 
End of assembler dump
.


Latest main+68 there is call to CallHook(), so:

(gdb) break *main+68
Breakpoint 2 at 0x1ffb1570
file callhook_static.cline 24.

(gdbc
Continuing
.

Breakpoint 20x1ffb1570 in main () at callhook_static.c:24


Inside of CallHook():

(gdbsi
0x0886b6e8 in 
?? ()

(
gdbx/24i 0x0886b6e8
0x886b6e8
:      mflr    r0
0x886b6ec
:      li      r9,8
0x886b6f0
:      stw     r26,168(r1)
0x886b6f4:      addi    r10,r1,64
0x886b6f8
:      mr      r26,r5
0x886b6fc
:      stw     r28,176(r1)
0x886b700:      mr      r28,r3
0x886b704
:      stw     r29,180(r1)
0x886b708:      addi    r29,r1,200
0x886b70c
:      stw     r30,184(r1)
0x886b710:      mr      r30,r4
0x886b714
:      stw     r0,196(r1)
0x886b718:      stw     r27,172(r1)
0x886b71c:      stw     r31,188(r1)
0x886b720:      stb     r9,56(r1)
0x886b724:      stb     r9,57(r1)
0x886b728:      lwz     r8,16(r3)
0x886b72c:      lwz     r31,8(r4)
0x886b730:      lwz     r8,36(r8)
0x886b734:      mr      r3,r31
0x886b738
:      stw     r29,60(r1)
0x886b73c:      lwz     r27,632(r8)
0x886b740:      stw     r10,64(r1)
0x886b744:      bl      0x8812058


So check what it calls inside callhook() by this latest BL:

(gdbsi 24

0x08812058 in 
?? ()

(
gdbx/8i 0x08812058
0x8812058
:      rlwinm  r4,r3,4,28,31
0x881205c
:      lis     r5,2332
0x8812060
:      ori     r5,r5,44372
0x8812064
:      lbzx    r0,r4,r5
0x8812068
:      cmpwi   r0,2
0x881206c
:      beq-    0x8812078
0x8812070
:      mr      r3,r0
0x8812074
:      blr
(gdb)


And as far as i aware, this function checks whether a pointer points to a segment containing PPC-native or 68k code. The segment is determined by the most significant 4 bits of the address, which is then used as an index into a table. The type read from this table is 0 for 68k code and 1 for PPC code. When a 2 is read, then the BAT registers decide about the type of code and go back to callhook().

Exactly the same code present in the CallHookPkt() too, so they both seems to call some internal function which do that check, something like "is_hal_native()" or something of that sort.

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top


Re: Tracing of callhookpkt()/callhook()
Home away from home
Home away from home


@joerg
Quote:

The removed amiga.lib/libamiga.a CallHook() didn't support emulated m68k code, but of course the utility.library one does.

That is clear, but now utility.library on amigaos4 have both CallHookPkt() and CallHook() : question is why they choose to add support for emulated m68k code to CallHookPkt() and not to CallHook() (which is now part of utility.library too for now).

Is adding m68k emulation support code to non-varargs functions is anyhow better choose ? Or it's all simple because CallHook() were added to os4's utility.library for easy os3 porting after CallHookPkt() were expanded with m68k emulation support code ?

OS4 devs says that in OS4, CallHookPkt() and CallHook() are 2 independent functions.

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top


Re: Tracing of callhookpkt()/callhook()
Home away from home
Home away from home


@joerg
Quote:

It's most likely not related to varargs at all, but that only utility.library CallHookPkt() includes the required check and different way to execute the Hook function depending on if it's emulated m68k code or PPC native code.


But as they have both CallHookPkt() (non varargs) and CallHook() (varargs) different implementation even today in utitlity.library, it's interesting why they choose to expand with emulator check an CallHookPkt() and not CallHook(). Probably because with the Varargs one there can be scenarios of corrupted stack, and varargs functions it not very secured ?

I mean, varargs stuff with all this “unknown amount of the arguments passed on stack” as final argument of the function can cause all sort of buffer overflows and string format issues in some conditions, and it is probably better to avoid varargs stuff as much as possible ?

I just go through google, and found right from start:

Quote:

Varargs throws out a lot of type-safety - you could pass pointers, floats, etc., instead of ints and it will compile without issue. Misuse of varargs, such as omitting arguments, can introduce odd crashes due to stack corruption, or reading invalid pointers.


or

Quote:

The vararg mandates that the parameter be passed on the stack, thus slowing the function call. On some architecture the difference can be significative. On x86 it's not very important because of its lack of register, on SPARC, for example, it can be important. Up to 5 parameters are passed on registers and if your function uses few locals, no stack adjustment is made. If your function is a leaf function (i.e. doesn't call another function), there is no window adjustment also. The cost of the call is therefor very small. With a vararg, the normal sequence of passing parameters on the stack, stack adjustement and window management is made or your function wouldn't be able to get at the parameters. This increases the cost of the call significantly.



And:

Quote:

A function using varargs cannot correctly verify its arguments

To try to avoid this, creators of varargs routines rely on conventions to manage this. For example, args sometimes get passed in as pairs - a type constant followed by the actual value ending with a sentinel:
SomeFunc(kInt, 3, kDouble, 2.0, kString, "blah", kLastArg);
Other times a descriptor is passed in first which describes the arguments:
printf("%d %f %s\n", 3, 2.0, "blah");
Other times, the first argument is a command:
DispatchMessage(kPaintWindow, &bounds, blackColor);
No matter what, it is possible to break the callee by passing in something that doesn't follow the convention. The problem is that there is nothing that can be done to enforce the convention. Without enforcement, you get a crash if you're lucky. If you're not lucky, you get a time bomb set in your heap that will go off only if the conditions are right.
In the last example, you're about as safe as you can get as long as you don't actually called DispatchMessage(), but instead use author-supplied macros like:
#define PaintWindow(bounds, color) DispatchMessage(kPaintWindow, bounds, color)
because then at least DispatchMessage is called correctly as long as the macro matches convention, and it is a single point of failure (which means a single point for a fix, which we like). I would turn around and argue that a single API, DispatchMessage, would be better off being multiple APIs.
Here's the skinny - if you're using varargs, you're probably doing something wrong out of the gate. Varargs promises a lot, but delivers very little.


So maybe that was another reasson why they choose to expand CallHookPkt() with an emulator, and not varargs based CallHook().

ps. Btw, can you remind why "A" append at the end of functions ? I mean, CallHook() -> varargs, CallHookA() - not. DoSuperMethod() - varargs, DoSuperMethodA() not. A mean A* register ?

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top


Re: Tracing of callhookpkt()/callhook()
Home away from home
Home away from home


@joerg
Quote:

The reason for CallHookA() in amiga.lib can only be AmigaOS 1.x compatibility, as written in the NOTES of the autodoc.


Very strange.. If that of course were true that AmigaOS1.x have no single hooks usage not internally not externally (just for a little time , for 6 months, of internal coding)..

From another side, maybe at this time, when assembler were too popular in amiga coding, they think that if one use amiga.lib , and it's vararg based CallHook(), then, if developers want non vararg based, then he should't have the needs to open utility.library (some additional code), and use CallHookPkt(), while, he can just use CallHookA() from amiga.lib at the same time.

But then, it didn't explain why then utility.library have only CallHookPkt() and didn't have CallHook_varargs() or similiar to amiga.lib's CallHook() or something so to fill the logic gap :)

But maybe i were falsely informed, and utility.library wasn't the only and single one using hooks internaly and there were released with them for public, before CallHookA() and CallHook() were implemented in amiga.lib


I was told that it was like this:

Alpha 5 of AmigaOS 2.0 (known as AmigaOS 1.4) in 8 June 1989 introduce iHook and CHook(). And 1.4 it is V35 (not V34). So the first (and even named different) hooking functionality were added to intuition.

How it is possible that in amiga.lib autodic, they wrote about support of "v34"... Like this is all wrong about first introduce of iHook and CHook() ?

Then, i was told that right after 6 months, after Alpha 5, in the Beta 1 of AmigaOS 2.0 in Kickstart 36.8 introduce CallHookPkt() , in 22 December 1989.

Then in amiga.lib with Kickstart v37 they introduce CallHook() and CallHookA(). But what data exactly, what exactly subversionof kickstart : dunno.

There seems some bug in the dates then, if amiga.lib told that "all should work with V34" , which is amigaos 1.3 , and not 1.4 where first hooks were introduced (seems not, then?)


PS. Also, did i understand it correctly, that they (os4 devs) tried to get rid of Varargs functions mostly from API ? Why i ask about, is that they say there https://wiki.amigaos.net/wiki/Linker_Libraries , that:

Intuition
CallHook
() and CallHookA()
These functions invoke hooksCallHook() expects a parameter packet ("message"on the stack, while CallHookA() takes a pointer to the message.
Replaced by IUtility->CallHookPkt() in V50.


Like, both were deprecated in favor of single CallHookPkt() , so to not have varargs function. Even if they have CallHook() still in utility.library (probably side effect of easy porting from os3 back in times), it all looks like that they want to get rid of Varargs one. Maybe because Varargs ones is potetialy not safe-ones, as can corrupt the stack in some conditions , etc, and that is the reassons they want non-varargs one to be used always ?


Edited by kas1e on 2024/5/19 12:51:18
Join us to improve dopus5!
AmigaOS4 on youtube
Go to top


Re: Tracing of callhookpkt()/callhook()
Home away from home
Home away from home


@joerg
I was told that the first hook (Even wasn't called callhook, but some older initial version) was the one which is used internally in the utility.library, for the string gadget. And it was in Alpha 15 of AOS2 (~1.4 somewhere in ks 35.xx). Prior to that, there wasn't any hooks usage inside the amigaos at all (in any function). I.e., no amigaos prior 1.4 have inside internally any hooking functionality of any sort, just direct usage of function and pointers, etc. By date it was in 8 june 1989. So it was first time of first hook internal (!) usage in utility.library, not even user-allowed code was. And it was Alpha of amigaos2 (So wasn't released anything prior with giving hooking functionality).

Then after 6 months, in the same "internal" code changes, in the beta1 of amigaos2.0, they made CallHookPkt(). So, fresh function, all fine, nothing released to anyone (except maybe this "beta of os2, named 1.4 for a3000). And then, in amiga.lib v37 (i do not know date exactly, and dunno what ks it was with it), then created CallHook/A in.

Taking into account that internally only utility.library use it (and when it use it, it wasn't called callhook, but just some internal name) , and that they have utility.library with callhookpkt already, i fail to see why they create CallHook/A.

I mean, it didn't looks like for support OS1.x, because not internally, not externaly hooking vere done for OS1.x. Maybe issues was all this C compilers (and maybe assembler ones?) asking for things to be on stack, so to make live of assembler programmers easy or something ? There should be another reasson, i just want to understand what one :) To fully fill the whole historical picture in OS3, before further annoying everyone about OS4 :))

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top


Re: Tracing of callhookpkt()/callhook()
Home away from home
Home away from home


@Joerg
Quote:

CallHookPkt() was added in utility.library V36 (AmigaOS 2.0), using the libamiga.a CallHook() instead was required for software which should work on AmigaOS 1.x as well.


That is strange, because as far as i know, there wasn't any callhook/callhookpkt until V36.8 (i.e. till amigaos 1.4 there wasn't any user-possible-used callhook() or callhookpkt() ). Even more, the single mention of first hooks in internal os3 code (checked by os3 developers), is dated by alpha 15 of amigaos2.0, with only internal use for utility.library. Only starting from beta1 of amigaos2.0 there were introduced callhookpkt(), and then a bit later were introduced callhook()/callhooka() in amiga.lib.

In other words, there wasn't any reasons to support 1.x code, as there wasn't any hooks at 1.4 times. It was a fresh addition from scratch. There should be some other reasons why they make 2 different functions doing the same, but called different and one placed in utility.library and another in amiga.lib (and the later on is surely worse, as take more stack space, right? )

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top


Re: updating sgit
Home away from home
Home away from home


@MartinW
Quote:

Apologies if my tone comes off as negative, but it's how I'm feeling about the platform in general at the moment and consequently it's not getting anything like as much of my attention as I would have liked.


That's ok :) You are not the first one and sadly not the last one who by some reasons at first think that obscure AmigaOS4 it is something which worth _that_ much. And that it have all the tools and languages available, and have a lot of developers and users. That of course was never and never will the case. Remaining of us trying to fix it in one or another way, but there are just not so many of us (and never will).

Any obscure OS will have lack of tools, many strange things, lots of unfinished and unreleased stuff (and even released, but then removed), and lots of pure strange and unlogical things. Some of us tried as hard as possible to explain that for every newcomer about, that they not need to hold a lot of hope for, a lot of praise for, and there are no needs to make os4 looks as it didn't look like: in real is just obscure OS for the fanatics, hackers, low-level coders and all sort of ppls who in interest in “strange” things. But it will never be "usual OS where all available".

The usage of the cross-compiler is simply better at current time because of above reasons : we have few developers, they all busy with everything else, so instead of spend their time on making native version of sgit , or awk, or whatever, they will be better use bug free, 100% times tested by 1000..xx users and developers around the world from compiler version to produce _native_ version of their tools. Not native building ? Yes, of course not native! Is it bad ? In current realm we should be happy that we even have cross-compilers , so we have a way to make work to be done with less issues, or to be done at all : for example, if not cross-compiler, there will be no Odyssye before, because even compilation of Odyssey few years ago for me on normal modern notebook take a hour. When we compile "only" gui parts on X1000 natively (8% of whole code), it take as much as it takes to build whole webkit (remain 92% of code). So you can imagine no one want to spend 2 days on building a thing, which can be build for a hour (and even faster today), only for "we can build it native" reasons :)

Of course, that not mean we not need native development tools. Of course, we require them too and better to have them too. But if we should choose, then we have what we have and what developers find better, at least for now, in the current state of things.


You shouldn't think that is issue with OS4 only : same happens with any obscure OS (And not only PPC and Amiga based ones). Even for ZX Spectrum all the games, all the art, all the coding done on PC tools and cross-compiler tools, and then adapted/polished natively. That just the reality of obscure and unpopular OSes and hardware.

In other words, don't put OS4 where is not. In reality, it is an obscure OS with the developers-hackers and users who understand it issues, some of which, sadly, will never be fixed. And some will be even worse. If you can enjoy it as it, and accept — then there will be a fun for you. If you will “hope” for more and more and be it like you wanted it to be, or like you see it at first, then it will be just rage-quit, burn out, and all that stuff.

Another practice can be applied to all this amigaos stuff: once you feel you are start to be annoyed, disappointed by anything , just take a rest for a month, or two, or a year, and then back when you will have motivation : at least that how some of us did :)

@billyfish
Btw, MightyMax taken over GDB porting, and few days ago were dealt with breakpoint/tracing stuff (he develops on qemu with peg2 emulation). So at least after few years there are progress in :)

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top


Re: Tracing
Home away from home
Home away from home


@joerg
Talked with some os3/os4 devs, to find out, that back in 1990, in the internal times of creating v36-38 , they firstly create callhookpkt() for user based callbacks. Then, after some months, were created independently callhook() and its callhookA(). While, all what they need is to create CallHookPktA() stub and that all.

So question which noone were able to answer me: why there were needs to create callhook() at all in amiga.lib, when, intuition has already callhookpkt, and all ut needs is callhookpktA(), and be done with it.

Amiga.lib ones were faster ? Less code ? But then it lioks like more code instead (put stuff on stack, back, etc). I can understand if CallHookPkt() were created after, for exactly avoiding of more code, but by history commits of the os3 it looks exactly in opposite: first one they create callhookpkt, and then after few months, internaly, they create callhook/callhooka in amiga.lib, like, it need them more. For end user it was a single push release of all 3: callhookpkt in utility, and callhook/callhooka in amiga.lib

What was the logic behind of such reversed and doubled work ?

On os4 this another story: callhookpkt were choicen, expanded to have emulator check, and callhook() added for easy porting from os3 (which developers back in past by some reasson prefer callhook from amiga.lib doing job). Probably it worth of bugreport to ditch few remain callhook() in os4 components in favor of callhookpkt(). Those 16 assembler instructions on emulator check cant bring any real overhead probably ?

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top


Re: sam460: new uboot update to handle RadeonRX coming soon!
Home away from home
Home away from home


@all
Tested also one of my RadeonHD's in : RadeonHD r7-250: (Card 0 (0): 0x1002, 0x682B, Radeon HD Verde (Mob.)) : this one works fine too. So both RX and HD cards fine (at least ones i test)

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top



TopTop
(1) 2 3 4 ... 426 »




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project