Quote:
Makes sense.
But is there a list of cards which haven proven to work with the emulator?
I have heard that Radeon9200 and 9250 may be ok. Any other?

Update: Luckily I was wrong. The board is ok. But my Pico-PSU is defect. I don't seem to have much luck with my PSUs these days... :P

I found an old 200W ATX PSU, which works.

m3x is right, U-Boot 1.3.1 behaves nicely and defaults to serial.

Although it doesn't like my GeForce 6200LE, and hangs after VESA is detected as being ok:


Doesn't u-boot support all graphics cards in VESA-mode? Is there a list of working cards somewhere?

Without graphics card I can use u-boot:


Now I need to find a PSU which can replace the 400W model in my new micro-ATX tower...

Then the board is defect. There is no output.
For another test I used a GeForce 6200LE and connected an USB keyboard. But again no reaction.

Pressing the power button only switches the blue LED off. But the pico-PSU doesn't seem to switch on. The connected drives get no power either.

But how would you type those setenv commands without a graphics card? ;)

It should be easy for UBoot to find out whether a graphics card is connected or not. So it can automatically default to serial when missing.
The Pegasos OpenFirmware, for example, will switch to serial when you disconnect the keyboard.

Quote:
Hmm. I would have expected that U-Boot uses the serial port for output when there is no graphics card.
Can anybody confirm it doesn't work?

Ok. I will wait for the Radeon 9250 before doing further experiments.

This weekend I installed my new 440ep-flex board into a Micro-ATX case with 400W PSU. It has a SATA hard disk and DVD drive attached and the board is equipped with 1GB RAM. The graphics card is still missing. I need to find a suitable one next week.

I would have expected that the blue LED besides J21 should be lit as soon as I give AC power to the PSU. But nothing happens.

It was suspected by other users that the board is not drawing sufficient power to activate a modern PSU, so I tried a Pico-PSU instead, and the blue LED went on.

But there is still something which troubles me. When I use the board's power switch the blue LED goes dark, but there is no other reaction: the DVD drive still has no power and there is no output at the serial port (I connected a terminal at 115200bps 8N1).

Is that to be expected?

Thanks for the replies.
Yes, I should have ordered the RAM together with the board from Acube, but I didn't realize that it was so special. :(

I wonder why they used these modules. Is it a requirement of the 440 CPU? Seems stupid, to increase the price dramatically with special DDR-100 printer RAM.

Hi,
I just got one of the 440ep-flex boards from Acube. But I am a bit confused about the type of RAM modules they use.

I told my local hardware dealer that I need DDR1 RAM for at least 266MHz with 100 pins, but he could only present my DDR1 RAM with a single whole and 168 pins.

He wanted to order it, but we didn't find out which type of RAM I need. Is it so rare?

@ZeroG
Thanks.
Seems I was blind. Downloaded the same archive some hours ago, but didn't find the #?.so in it... :P

If you have built libjpeg.so you should upload it somewhere.
I could not find it anywhere. It has disappeared from os4depot. And Wesnoth is also linked against libjpeg.so ... :|

@nubechecorre
Do you have an USB-joystick too? Then you have won.

@kas1e
I have a Pegasos2 myself, so I know everything works there. :)

Hi all!

I need a beta tester for Giana's Return, which might be released this month.

Basically you only have to start it and report back if it works. But you need to fullfill the following requirements:

- You own a Sam440 for testing.
- You can connect an USB joystick and test with it.
- OS4.1 with latest update is installed.
- Recent libSDL.so from code.google.com in SOBJS:
- libSDL_mixer.so from Fredrik Wikstr?m (OS4Depot) in SOBJS:

I need to be sure that the code works on the 440 CPU, and I also would like to know if USB joysticks are supported by SDL with the latest update.

As I don't want to receive dozends of emails, the first person who will reply in this forum will be contacted by me. So others can easily see that they are too late. :)

Quote:

I cannot update my system but that's good to know. The same source works fine with PowerSDL, so I just compile and hope the best. :)

@kas1e
Actually we seem to have two problems.

1. HWSURFACE is very slow.
2. When creating too many hardware surfaces the system will lock up.

Another problem I just realized, is not related to hardware surfaces: the SDL Joystick doesn't work. Does it support USB joysticks? AFAICS those three are all problems to fix for brining the OS4-version on the same level as the MorphOS version.

@afxgroup
I will try to create an example source for you and contact you privately.
I don't have your email address, so I hope the one linked under Contacts at www.amigasoft.net is correct?

@afxgroup
The last thing I want to do is to create an account at Google. ;)

But you can count on my help regarding this bug. You can contact me for more information and for testing every time.

Since I got the full source text a few days ago, I'm currently porting "Giana's Return" to OS4. The MorphOS version is already running perfectly, but I won't release anything before both versions are working. ;)

Unfortunately there seems to be a problem with hardware surfaces with the recent libSDL.so from Google Code. After running the game for a short time I'm always getting system hangs (cannot move the mouse or switch display). The bug occurs in different situations, but now I finally found an SDL call which didn't return: SDL_ConvertSurface().

Hundreds of small graphics are converted into the native screen's graphics format with this call. So it must have run serveral times before, but suddenly it freezes.

I realized that the function was requesting a SDL_HWSURFACE, like many other calls in the game. Surprisingly, when I changed this call to SDL_SWSURFACE the program continues, and seems to work!

Why is that? Could it be that at some point no more video RAM for hardware surfaces is available? But then the system should just return a software-surface and continue? A bug?

But the performance was disappointing: 10 fps. Then, just for a test, I replaced all SDL_HWSURFACE with SDL_SWSURFACE and it accelerated to 50 fps!

Is it a bug in SDL_ConvertSurface() or with hardware surfaces in general? Can somebody check or confirm that?

@ZeroG
Quote:
That's a pity. After reading Hans-J?rg's mail I had some hope that it will work with recent versions. :|
Thanks for your test. So I need some workaround for it.

Quote:
No. I know that the crash happens in an uninitialized PLT slot from libalpha to beta().

@ZeroG

If you would like to test, which I much appreciate, you can download a tiny shared object test from: http://sun.hasenbraten.de/~frank/TEST/sotest.lha

The main program test will call alpha() from libalpha.so, which will call beta() from libbeta.so. test only requests libalpha and relies on elf.library to recursively resolve the reference to libbeta.

I terminated my OS4 developer account last year, so I would have to buy a legal 4.1 version to be registered (but I never cared how this process worked)? I guess I will better wait for the X1000 before doing so...

@kas1e
Although I have got some other problems, but this works for me.

At least the gcc from the current SDK which I tested will only link shared objects with -use-dynld (and annoyingly also requires to resolve even all inter-dll references during linking).