Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
40 user(s) are online (20 user(s) are browsing Forums)

Members: 0
Guests: 40

more...

Headlines

Forum Index


Board index » All Posts (Hypex)




Re: SAM Flex Stuttering Issue workbench or software use / games
Just popping in
Just popping in


@joergQuote:
I don't know what that G2D rating uses. While the AmigaOS IGraphics->CompositeTag(s|List)() function is mostly used for 2D operations like scaling, rotating, alpha blending, etc., it's based on the 3D features of GPU. Of course there is CPU based fallback code as well, but very slow compared to a GPU supporting it.


That's good to know and I do recall something about 3D for 2D operations. Unless I'm thinking of something else. When I upgraded my lite RadeonHD driver to full version it was noticeable the increase in resolution and snappyness on the 5450 I was then using. But, it also has no 3d support, yet it didn't appear to be software rendering.

Quote:
Theoretically it would be better to compare the results of different gfx cards on https://www.hdrlab.org.nz/benchmark/gfxbench2d/OS/AmigaOS but since that was flooded with useless results from WinUAE and especially QEmu users (you have to ignore everything with uaegfx and SiliconMotion 502 gfx card, best results with real hardware are on page 3, best with a Sam460 on page 11 and best with a Sam440 on page 30) it's no longer usable.


Thanks for the link. I do remember this one. It's unfortunate it is flooded as it's harder to navigate than PasssMark. I got SSL or TLS errors. And no direct way to sort or search.

Go to top


Re: Trying to get a Radeon HD 7750 working in an AmigaOne XE
Just popping in
Just popping in


@geennaam

Quote:
What I meant with power injector is the cheap risers used for crypto mining. He already bought that one. It's a PCIe x1 to PCIx16 solution with a USB cable in between. The power is injected to the x16 slot by means of a 6-pins PCIe power cable, 4 pins molex cable or a SATA cable


Yes, I know what you meant there, I was just wondering if there was a neat solution to supplying power to bridge cards. The riser solution ends up being like a hack as the video card needs to then sit loosely in the case. Which is somewhat worse that lacking a long threaded screw to hold it in a PCI bracket.

Quote:
Afaik, HD7000 don't even show u-boot output without the riser/power injector described above


Unfortunately I didn't take any notes when testing hardware. I tested both R7 240 and HD 7770 in bridge card as well as in powered riser. With and without power in riser.

Quote:
Sure, his HD 5450 work with it. Just no HD 7000 series work with those PEX8111/PEX8112 bridge/adapters


Given the performance difference and lack of 3d support under HD 7000 cards not much point then.

Quote:
They are both 33/66MHz PCI to single lane PCIe 1 bridge chips. So there's only one lane connected in your x16 slot.


Well that's typical. Then the 1x board going into the 1x socket from a USB cable would suit it then. I suppose that's neat.

Go to top


Re: SAM Flex Stuttering Issue workbench or software use / games
Just popping in
Just popping in


@Gebrochen

In addition...

Quote:
9250 bench score 3
5450 bench score 136? but due to limited support in Amiga not a better card on the amiga
R7 240 by memory in the 900s, perhaps 906 in bench score
7770 had the nicest of my cards at 2000s something bench score

for exact figures, give me a moment :
https://www.videocardbenchmark.net/com ... -R7-240-vs-Radeon-HD-7770


If you see where that is you'll see it's giving the G3D rating for 3D. The 5450 has no direct 3d support in OS4 so this figure is irrelevant to OS4 really. And for supported 3d cards, the R7 240 and HD 7770 as examples, the figure is only relevant when hardware 3d drivers are installed and used. Such as Warp3D Nova and modern software using the modern drivers.

For Workbench use what important figure to look at is the G2D rating. Since that would be relevant for 2D compositing. Which is included in the full RadeonHD driver regardless.

In that case a 9250 gets 127, 5450 gets 140, R7 240 gets 273 and HD 7770 gets 461. You can see the 5450 is slightly better than the 9250 which isn't half bad. 7770 gets best score.

Of also to note is that any HD card and above needs to go through a PCI bridge. And some like the 9250 design for PCI can be better for some operations over the PCI bus. I did read of some latency with copying to VRAM. With 3d this doesn't look crippling given textures would be uploaded to VRAM for GPU operations. Though I would have thought even for 2d images would be uploaded as well so hardware would simply copy internally.

Go to top


Re: Attempting to upgrade Sam 440 with an R7 240 or HD 7770
Just popping in
Just popping in


@sailor

Thanks for your summary which is obviously a short list built from lots of time and testing.

Why I brought up a possible powered PCI-PCIe adapter is to provide a neat solution using only one bridge board between PCI and the graphic card. As it stands now, in a manner of speaking, is the need for riser for power complicates it as now it needs to be some hack with a loose graphic card sitting around in the case. Each to their own. But a random looking card at odd angles with cables all over the place going in and out of the case is not an optimum solution in my eyes.

Also, mining rig, I didn't know the mining industry used PCIe riser cards in diamond cut mines lol.

The 7770 does have at least one power input. So two will be needed here. One for riser and one for carder.

Go to top


Re: Attempting to upgrade Sam 440 with an R7 240 or HD 7770
Just popping in
Just popping in


@Gebrochen

Oh sorry. I just wanted to include all the information in one thread. Rather than have it spread over forum posts. And also list what hardware and configurations had been tested.

You had mentioned the StarTech device, even if not by exact brand, but think it was confused by some discussion about Chinese chips and Japanese chips lol.

My X1000 has a 500W supply as well. My main concern is not having enough cables for each device separately and needing to double up on power cables. Plus some basic PSUs can be lacking against better models. You will recall the first PSU in your Sam that blew out. The one now in working order is certainly better.

There's a lot 68K people who are 68K all the way and nothing else. I see that as being stuck in the past. They define the Amiga as this one and only platform with CPU and chipset. That is unrealistic. They should know, unless they lived under an Amiga rock, that Commodore had plans to replace the Amiga with a new follow up with different CPU and 3d chipset. Most, at least on Facebook, don't seem to know or have followed Amiga history for the past 30 years! They all tend to go on about the same thing, that's not a real Amiga, it doesn't have a 68K, I cant play games off floppy. OMG are they serious? The current OS4 boards are not and never been advertised as being an Amiga. Can they actually read? Last I checked those people aren't still running a DX486 DOS PC or 68040 OS7 Mac. But the way they talk is like a bunch of aging Neanderthals with their head stuck in ancient rocks!

I'm not sure what AmigaGPT needs. But an aging issue is Commodore dropped speech support in OS2. Seems silly doesn't it? Must be cost cutting as usual. Seems OS1.3 is the goto Workbench for things they removed like AmigaBASIC and speech binaries. There would be surely free speech libraries they could use. The one C= used which Apple may have used as well is old now so surely there is a better replacement.

Anyway so it looks like the hardware issues will be solved soon. If only you or I knew about needing another PCI bridge. You could have saved some money and time. By buying that instead of the R7 240. When it's likely the HD 7770 has as much chance of working. And does look more powerful in the score.

In the meantime I will continue to diagnose why my R7 250 freezes still. I'm supposing it to be a lost cause by now. The wreckage which is Update 2 continues to haunt me, as even after the hot fix, it still has the bug included which freezes my Workbench on boot and will continue to do so as we enter into winter time.

Go to top


Re: Trying to get a Radeon HD 7750 working in an AmigaOne XE
Just popping in
Just popping in


@geennaam

Thanks for the valuable info.

And yes "I am the friend" in question. So if either me or or him use the expression "my friend" we are not using a common low security phrase to describe ourselves.

It's funny that I initially had my long post here then thought I should separate it. I might as well kept it here. Or posted it to the stuttering thread.

In research I've actually found a 5450 PCI card. Perhaps good also for the XE as it may be a good way to upgrade if it works. While useful for use on a PCI system it's limited in power these days.

So possibly any card from 4 to the 6 series would be good. But, despite being popular in the X1000 era, they lack support for 3d. I purchased an XFX 4890 for my X1000 back in the day which is a monster. But really was wasted on my system if it wasn't used for 3d, which wasn't popularised on OS4 like it is now, and I didn't use it for any Linux 3d gaming either.

What's confusing is the cards work in UBoot which gives the impression it has enough power. So would this mean it only used low power in basic VGA modes? And for opening a real screenmode in 32 bit HD it needs more power to do so?

On the subject of the PEX8111/PEX8112 are there any HD cards that do work on this chipset? Mind you that means getting into the high end one you widen it from HD 7xxx to R9. It would be rather disappointing if the driver was holding it back and preventing the PEX8111/PEX8112 from working if it could. That would mean possibly working hardware rendered useless by a driver quirk.

The common example for the PI7C9X111SL chipset is the StarTech card. Unfortunately this means another expensive add on is needed. Of course this is the result of using legacy technology in PCI. It's getting closer to a Classic Amiga at this stage, with the PCI add ons, where you needed expensive PCI bridges just to add an old or cheap PCI card.

It also looks "inferior" to the PEX based one as it only has 1x lane where as the PEX one has full 16x lanes. So you pay more for less. Neither one has a power input necessary to fulfil the PCIe power standard.

BTW I did find a PCIe power injector. Looks expensive. Riser card may be better as it's common and cheap to get. Plus if it can only work with 1x PCIe bridge no point with a full slot. Otherwise a possible PCI power injector may have solved that as well. That less likely to exist.

https://quarch.com/products/gen3-pcie-power-injection-fixture/

Go to top


Re: SAM Flex Stuttering Issue workbench or software use / games
Just popping in
Just popping in


@Gebrochen

After testing it myself!

Go to top


Re: Trying to get a Radeon HD 7750 working in an AmigaOne XE
Just popping in
Just popping in


@geennaam

Oops too late. Posted it. Was too big for here.

So is the PEX8111 or 8112 only compatible with a HD 5450 or similar card?

And the PI7C9X111SL is needed for a later HD card like a HD 7770 or R7 240?

Regardless of power?

Go to top


Attempting to upgrade Sam 440 with an R7 240 or HD 7770
Just popping in
Just popping in


Hi guys.

So I have been reading articles and posts with a view to helping Gebrochen get an R7 240 or even HD 7770 working on his Sam 440.

Currently he has PCIe bridge with a PEX. Not sure what chip. He also has a PCIe riser with a PCE164P model. Which totally confused me as I could not figure out why his card was slanted at a bad looking angle.

The R7 240 fits fine in the PEX but doesn't work in OS4. It comes up fine in UBoot but breaks when OS4 tries to open a boot logo.

The same happens with the riser card in an attempt to power the card. Uboot can show but OS4 will not.

It had become a bit convoluted at one point. The R7 was plugged into the PCIe riser which was then plugged into the PCIe bridge with a USB3 cable and then finally the PCIe bridge was plugged into the PCI slot. But that's not all! Then finally power was needed to be plugged into the PCIe riser. What a nightmare!

The HD 7770 was even worse! Needing power both on the video card and riser card. Oh man!

Clearly there seems to be a power issue here but not even supplying extra power through convoluted solutions solved it. To me it looks like even the basic PEX bridge is not designed correctly as it has no power inputs. Or it's only designed for low power PCIe cards despite having a full sized 16x PCIe slot.

What's needed is a PCIe bridge with power inputs but does anyone make any? I see mention of this P17C9X chip but again do any bridge cards with that chip have power inputs? If not I see the same problem occurring. Plus connecting a 16x card through a 1x lane would be crippling for performance. So I don't think the riser solution will help here. Another, ahem, PCIe card that serves to only provide power and takes input is needed. Are there any?

The R7 has no power input so relies on PCIe bus for power. The HD does have power inputs but may not have enough power supplied. What's unclear is where power can be plugged into the riser. I looked up the PCE164P model and could not find any manual for it. I found a video but the card has input and molex on one side and input on the back. Are they all inputs? Do they all need connecting for maximum power input? It's not clear to me.

The PSU is a ROCK 500W and I wonder if that needs an upgrade as well? I saw one power output for video cards. But a clear lack of power outputs as some drives needed dual adaptors. An SSD is still intended to be installed but was failing to show up as well. There could be a power issue here. Perhaps a new PSU would solve it? Or maybe not.

One thing I notice is the following line in all failed cards and then it stops:
RadeonHD.chip (2): rhdGARTInit is not implemented yet␍␊


However, I see this line in working cards. But more lines follow. Is there a guide on what hardware is needed? Including compatible PSU? A 5450 works in PCIe bridge with OS4. An R7 240 and HD 7770 do not work in OS4 with either bridge or powered riser. All work in UBoot.

Go to top


Re: Trying to get a Radeon HD 7750 working in an AmigaOne XE
Just popping in
Just popping in


@sailor

So have been reading your articles with a view to helping Gebrochen get an R7 240 or even HD 7770 working on his Sam 440.

So far OS4 has failed to boot up. Cards do work in UBoot. A PCIe riser has been attempted as well to no avail.

Will open new thread instead as it relates to Sam 440.

Go to top


Re: The consistently curious case of the constantly crashing computer
Just popping in
Just popping in


@joergQuote:


Sorry for the bad excuse, but usually you don't open any libraries yourself but use something like -lauto, or similar solutions for individual libraries not included in libauto.a, instead. What makes it even worse is that I'm not only the main developer of the AmigaOS 4.x OWB port, but one of the two developers who did the AmigaOS 4.x port/bug fix of asyncio.library as well 🙇


Personally I open them all myself but wasn't a nightmare until I decided to write a Reaction GUI and by then it was too late.

But to be fair, aside from libauto not being recommended for pro use, that fault there would lie with libauto itself. Which should internally specify version 50 or above. Not only this, but possibly the OS4 Exec should have thrown a yellow alert if any native code used 0 for version. Which is functionally equivalent to calling OldOpenLibrary() for 35 years now or so.

Regarding asyncio.library, with the OS4 version I found on the Depot, that worked fine. I don't know how an old version found it's way onto my system. I even renamed it out of the way and Odyssey loaded fine. Does OWB actually rely it? I haven't checked what depends are included with it. But both OWB and Odyssey can run without any installing. Which is useful. But I do like that installer for upgrading.

Go to top


Re: The consistently curious case of the constantly crashing computer
Just popping in
Just popping in


@328gts

Cheers.

Go to top


Re: SAM Flex Stuttering Issue workbench or software use / games
Just popping in
Just popping in


So I've tested it myself. There is something going wrong even if the 5450 is slowed down by a PCI bus. But the 9250 is PCI card and as stated has no problems. The 5450, however, is really slow when dragging a window by the sizing gadget. It's practically unusable. It's like moving a window on my A1 Linux. :D

Gebrochen:
Try this for now. In GUI Prefs. Controls section on left. Disable resize window with contents.

Go to top


The consistently curious case of the constantly crashing computer
Just popping in
Just popping in


Hello every one.

I present the consistently curious case of the constantly crashing computer.

So it all started around two weeks ago. I wanted to load up Odyssey on my X1000 OS4 machine but my Internet dock went missing. This is something that has randomly occurred every few years. When a dock would suddenly disappear with no clue as to why and no sign when checking the settings. So I decided to just leave it. Ten tabs open does slow it down.

I then took my X1000 to a friends place for the weekend so he could compare with his Sam system. Soon after he had found some 68K software crashed on my system that worked on his. He also found my video players were old and not good at playing common videos. Guess I never noticed for a while. So he set about rectifying this and installed both 68K and OS4 software. Shogo however played well. But Spencer crashed on load for some reason so I couldn't show that. Even though it had been working fine so this surprised me.

I took my X1000 back home and set it up again. For two nights I just edited files in Cubic IDE and compiled in shell. Pretty boring I suppose given it could play videos again. So I had no issues at that point. The next night I try and open a text file, a crash log as it happens, when ironically doing so instantly crashes! It had crashed MultiViewer. I'd never seen that just crash on a text file. So saved the log and examined it. Some 68K program at the top of stack track which was nameless had crashed which was strange. How did a 68K program get called from native code?

Here's the rogue code from the crash log I needed to trace:
68k disassembly:
 
620649ae6038                 bra.b             0x620649e8
 620649b0
2041                 movea.l           d1,a0
 620649b2
22680014             movea.l           0x14(a0),a1
*620649b62029007c             move.l            0x7c(a1),d0
 620649ba
0c8000001b00         cmpi.l            #0x1b00,d0



So I set about checking files and not knowing it would become an extensive search. I first wanted to compare to backup files. So tried to run CompareDirs and then that crashed! How was the system even usable? Well it wasn't now! I then loaded DirOpus. I compared libs, classes, and devices and couldn't see any major differences apart from extra binaries added. I ran a program I wrote that lists 68K binaries and gathered a list of 68K programs on my system. Checked with DirOpus and again nothing stands out. So in the crash log I decided to copy out a section of the 68K code and do a search. I modified another program I wrote that searched for hex codes to search only in 68K binaries. So ran it over the whole Workbench to catch what 68K program contained it. I plugged in $2029007c from the crash line. Nothing showed up!

Even though I had gone beyond what should be needed to trace a crash, modifying and writing code to scan files, I still needed to go deeper. So I then set about searching the whole filesystem for this one hex code. But, it was just taking too long, and too many irrelevant files were taking up the search. After filtering them to 68K only had failed. So I decided to get out the all round disk monitor for all occasions--DiskMonTools. I really should have got it out first instead of going down a rabbit hole. So I navigated the Workbench in question to search the whole volume for $2029007c. Boom! It found it! I check and it appears to be embedded in some IFF file which is a strange place for 68K code. I look around the code and it's an IFF datatype file. I check out my datatypes and do another hex search. It's a ZX datatype file from 1996!

So I move it out the way and reboot. MultiViewer, CompareDirs and Spencer now start working! A rogue ZX datatype had crashed them. Strangely, MultiView, the core system program for viewing datatypess, didn't crash. ZX is a Spectrum image datatype. I've never had a Spectrum and no interest in viewing ZX files so no idea how a ZX datatype was installed on my system. At first I thought ZX was some kind of compression format.

This is the one:
http://aminet.net/package/util/dtype/ZX_DataType

Next I set about trying to solve the missing Internet dock issue. I examine the settings and and did a diff of XML setup files. As you can see I'm again going too far to find the issue. But OS4 lacks sophisticated tools to scan and find the problem for you. So does modern OS in a lot of respects. When I clicked on my Internet dock it just showed the grey bar. I've checked the settings and compared it with other subdocks. There's only one difference. One difference I noted was a hidden setting in GUI and XML. But I changed it and it made no difference! In the Misc tab the option "Dock is hidden" is off, while others have it on. Given I want to see it, it's funny it would be missing when hidden is set to off. So I tried setting it to hidden. But it wouldn't save it! It kept turning it off.

Then I found the problem! It was that hidden dock setting. I couldn't get it to work from the check box correctly. And saving didn't make any difference. But I accidentally double clicked the tiny bar below the dock which still showed. The icons came back! Then I checked the hidden setting and it turns it on and off. Suddenly the hidden check mark decides to work. So for hidden setting to work the dock needs to be visible or it doesn't work, while ticking on and off, looking like it does. And you need to double click this tiny grey bar to hide and unhide the dock as well as activating the hidden check mark despite it turning on and off. Seriously who does that!? What sort of stupid design is that?

With my Internet dock now visible again I set about loading up a browser. Only to be greeted by Odyssey crashing. FFS what now?!?

The clue this time was some native code calling a Webkit open file routine:
Symbol info:
Instruction pointer 0x7732434C belongs to module "OWB" (PowerPC
Symbol_ZN7WebCore7OWBFile4openEc 0x27C in section 1 offset 0x000CD328

Stack trace
:
    
OWB:_ZN7WebCore7OWBFile4openEc()+0x27c (section 1 0xCD328)
    
OWB:_ZN7WebCore7OWBFile4openEc()+0x334 (section 1 0xCD3E0)
    
OWB:_ZN7WebCore5Image20loadPlatformResourceEPKc()+0x104 (section 1 0xDF910)
    
OWB:T.2747()+0x14c (section 1 0x7873A4)
    
native kernel module newlib.library.kmod+0x00000138
    native kernel module newlib
.library.kmod+0x00002088
    native kernel module newlib
.library.kmod+0x00002d0c
    native kernel module newlib
.library.kmod+0x00002ee8
    OWB
:_start()+0x170 (section 1 0x16C)
    
native kernel module dos.library.kmod+0x000255c8
    native kernel module kernel
+0x000420ac
    native kernel module kernel
+0x000420f4

PPC disassembly
:
 
7732434438a00000   li                r5,0
 77324348
3cc00001   lis               r6,1
*7732434c8009004c   lwz               r0,76(r9)
 
773243507d234b78   mr                r3,r9
 77324354
7c0903a6   mtctr             r0


Both Odyssey and OWB crashed on the same function. Somehow Timberwolf was able to load. Then it too became unstable. So again I start another investigation. Do things appear in threes?

This time the code was fully native. So I couldn't directly trace it to any rogue 68k code. But why did they both crash inside their own routine? Something had to have infected the system like before but somehow had remained more stealth. Was it hidden in plain sight?

I decided to run Snoopy to assist which can also list library and device open calls as well as typical DOS calls. It's not always obvious what is failing as it's also common for functions to fail in normal use, such as looking for ports and environment variables. However amongst the needles in the hay stack as it were something looked strange. A library interface fail.

Here's the log:
01294 : OWB             o.k. = [execOpenLibrary("pthreads.library",0) [20463uS]
01295 : 
OWB             o.k. = [execOpenDevice("timer.device",3,0x570C55E0,0x00000000) = [7uS]
01296 : 
OWB             o.k. = [execOpenLibrary("asyncio.library",0) [16565uS]
01297 : 
OWB             FAIL = [execFindResident("asyncio.library.main") [10uS]
01298 : 
ramlib          FAIL = [execFindResident("asyncio.l.main") [3uS]
01299 : 
AmiDock         :        Delay(1) [22128uS]
01300 OWBLauncher     :        Delay(1) [22297uS]
01301 OWBLauncher     FAIL = [execFindPort("OWB") [3uS]
01302 OWBLauncher     FAIL = [execFindPort("OWB.1") [0uS]
01303 ramlib          FAIL Lock("LIBS:asyncio.l.main",SHARED) [15114uS]
01304 ramlib          FAIL Lock("CLASSES:asyncio.l.main",SHARED) [19uS]
01305 ramlib          FAIL Lock("CURRDIR:asyncio.l.main",SHARED) [12uS]
01306 ramlib          FAIL Lock("CURRDIR:Libs/asyncio.l.main",SHARED) [18uS]
01307 ramlib          FAIL Lock("CURRDIR:Classes/asyncio.l.main",SHARED) [9uS]
01308 : 
ramlib          FAIL Lock("PROGDIR:asyncio.l.main",SHARED) [8uS]
01309 : 
ramlib          FAIL Lock("PROGDIR:Libs/asyncio.l.main",SHARED) [9uS]
01310 ramlib          FAIL Lock("PROGDIR:Classes/asyncio.l.main",SHARED) [9uS]
01311 OWB             FAIL = [execFindResident("asyncio.library.main") [5uS]


The "library.main" and "l.main" suffix are a vestige from when libraries were not fully OS4 native and OS4 interfaces were split into additional library files. Why was it looking for and failing to find an OS4 interface?

So I again compared against a backup. I was familiar with "asyncio" from years ago but it wasn't in my backup. I check my local copy and then it all comes to light. It's a 68k library dated to 1997! What the?! What on earth is that doing there!?

This one here:
http://aminet.net/package/dev/c/AsyncIO

So I found this one there:
http://os4depot.net/?function=showfil ... =utility/misc/asyncio.lha

I copied that in and rebooted. Suddenly everything is working again! Unbelievable!

As i side note part of the issue is the above OpenLibrary() calls are using 0 as version. This is unacceptable on OS4, and since the 90's even, as programs are required to specify a minimum library version. A 0 will default to any version. To be coded correctly for OS4 and above it should use 50 as version which would have caught the above case.

I've never seen a system come unstuck suddenly from a few old rogue files that took ages to track down. It happened over Easter and it was like three days and three nights all over again. Freak file accident. I've looked through my recent downloads and just cannot track down where it came from. Not that I was doing much lately so one reason I didn't get tripped on it sooner. Glad it's over now.

Well, I hope you enjoyed reading the consistently curious case of the constantly crashing computer, as much as I enjoyed writing it, and didn't enjoy experiencing it!

Go to top


Re: SAM Flex Stuttering Issue workbench or software use / games
Just popping in
Just popping in


@Gebrochen

I've found sometimes window dragging can go weird and jump around. And scroll bars as well. For example CompareDirs is practically unusable with large files as I try and drag the scroll bar but it just keeps jumping up. And it doesn't support any common keypad shortcuts.

Anyway I checked my settings on the XE which has a 9200SE. Classic. Try that out in the video bench site. Lol. So in GUI Prefs Effects section I have Compositing enabled but Optimise for video memory. I have also have vertical Synchronise on.

It's connected to a full HD monitor and default to 1920x1080x32 mode. Video ram is 128MB. I have about 80MB free with a few windows open on Workbench.

Go to top


Re: SAM Flex Stuttering Issue workbench or software use / games
Just popping in
Just popping in


@sailor

Quote:
I cannot second this.




Quote:
R9 270X.


Well there's your answer!

Quote:
Here is my old article.


Definitely an invaluable resource on graphic card comparisons.

Go to top


Re: New owner of an X5040, who needs help
Just popping in
Just popping in


@skynet

It's common for AmiDVD to give those SCSI errors in sloppy windows. It used to happen for me when I had a damaged disc. I suspect it sends SCSI commands to the driver which then converts internally to ATA. Or some kind of SCSI command encapsulated in an ATA command. Since I recall some standard where SCSI wass encapsulated in ATA.

As to the device it will examine CD0: and extract the device and unit so you shouldn't need to configure it. IIRC it can be set in tooltypes. But if you have one drive it should pick it up.

I liked FryingPan, but on OS4 I found it can be faulty, and it was never finished to be fully stable AFAIK. What driver are you using for MakeCD? The SCSI3_ATAPI driver should work or it used to for IDE on my A1/XE. Also are you running the latest patched version? Here is 3.2d if you don't have it.

http://aminet.net/package/disk/cdrom/MakeCD_3.2d

Go to top


Re: E-UAE 1.0.0 with an AmigaOS 3.9 HDF runs very slow
Just popping in
Just popping in


@MamePPCA1

Have you tried EUAE included with OS4 in the Emulation drawer? The only thing is you will need to add your HDF file and I don't recall if the GUI makes this easy or if it needs to be added by hand. It's easy enough to boot WB but it's made for games or single executables under the included OS3.1 WB. Why I ask is if you don't specifically need high speed JIT for your OS3.9 setup then EUAE may be good enough.

Go to top


Re: Block comments
Just popping in
Just popping in


@kas1e

Has HKvalhe made negative comments lately? He's quote vocal on feedback and looks like he's tested a lot of updated stuff. But the comments I've read lately and that would include last year were positive or just asking for info and weren't bad in any way I could see.

Go to top


Re: PiStorm - can PPC for classic Amiga make a come back?
Just popping in
Just popping in


@geennaam

Quote:
If the definition of "ppc for classic" is to run powerup or warpos then I do not see the point. The 68k emulation will probably run the 68k versions just as fast as a ppc emulation would run the warpos versions of an app.


I would say yes to be compatible with both. So both would be supported. The only question would be is if original PPC libraries would be supported or need custom ones. To work like a PiStorm does original should be supported.

Why I would say to support this is because a PPC card, either real or a PiStorm virtual PPC, would be expected to support this when plugged into an Amiga. So the point isn't to be compatible with old WarpOS games or software. The point would be to implement the classic PPC standard so PPC software can work.

In doing so, it also means it would be compatible with OS4.1. While a PiStorm optimised OS4.1 would be nice I doubt that is going to happen. So a Classic OS4 would also run by extension by being compatible.

Go to top



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




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project