Hi everybody,

I'm playing around with sound for my MAME port at the moment.

Can someone tell me please how to work out the current play pointer if the stream? I need to know where in my buffer to start putting my data.
Alternatively I could do it with double-buffered audio but I want to keep latency down to a minimum.

Is there good example source I can look at to see how this should be done?
Thanks!

If you can find a Catweasel Mk. IV then you're sorted. :)
Kryoflux is also good but I not sure of AmigaOS drivers, they exist, I believe, but I've never used them.
Getting hold of a Catweasel is very difficult, but worth it :)

I remember a Frieden talking at one point about how Q3 was spending most of its time in inefficiencies in the way the 2D talks to the 3D subsystem, is that why results aren't as fast as they should be on q3?
I get just over 21fps on q3 on my A1 (800MHz, Radeon 9250), but it should really be higher.
Didn't FE change the graphics subsystem? Does minigl need to be updated to work more efficiently?

It's sorted for now, but thanks!
We're using the built-in commands, not the add-on pack. It was just not receiving it, though - obviously it was checking the AREXX port name for some reason!

You, Sir, are (as they say) "Da Man".

It seems like Blitz Basic has the same problem as Python! If you don't set the node manually, even if you use CreateRexxMsg, Blitz just completely ignores it! How very useful!

It works now :)

Hi everybody,

I'm having trouble with ARexx.

I have "borrowed" the ARexx example code from here:
http://thomas-rapp.homepage.t-online.de/examples/rexx.c

I've also checked against other examples and it seems fine.

All I ever get is "Sending notification..", then "Sending message to port... *correct address here*".. and then "Waiting for Reply..."

It never returns. RX_TEST is a Blitz program which just sits waiting for an AREXX event.

I can send messages to the Blitz program via Rx or SendRexx on Aminet. Both work perfectly.
I can send messages using my program to other programs such as MiamiDx or Scout. They work perfectly.
But trying to send a messagr from my program to the Blitz program, the Blitz program never receives the message so my code hangs waiting for a reply that never arrives (because the Blitz program never received it).

Can anyone help? This has me stumped!

He's using the Generic PearPC core at the moment, he can just change to the JIT one (PearPC has different cores it can use). I suspect PearPC is a lot more supported than the Sheepshaver one.

@ddni

The X1000 IS fully functional. AmigaOS4 doesn't support one core, but the machine is perfectly working (Linux supports it) - it's just the AmigaOS support isn't ready yet. But that doesn't stop the machine working in any way shape or form.

Xena/Xorro does plenty if you tell it to. You can't say that the fact that there's no publically available uses for it yet means it's not functional, surely? It's functional if you want to use it.

The X1000 is shipped with a perfectly working ethernet card. That card is part of the system until the onboard is working.

The machine IS fully functional, it's just that OS4 can't use one of the cores, but that doesn't cause any problems at all. You can still use the machine perfectly without instability.

@Lio

The OS is very stable these days.
In the past they were working on the core OS, now it's the drivers that aren't quite complete, but the X1000 is fully functional with its Ethernet card until then.

The situation these days is nothing like how it was for the Earlybird offer (I used it too... I had to run Linux on my a1 require a while waiting for OS4 to be released!)

The X1000 is fully functional in the state in which it ships, it just doesn't support both cores yet... but it works excellently as it is.

@Breed

I just ran it on my X1000 (I fixed it on my Sam440ep) and it runs 1450% when in warp mode. At normal speed, it just runs at a steady 100% (and judging by the King Crimson OGG playing perfectly in the background, I'd say it's not chewing up all the CPU time, either).

Have you tried with default settings? Sounds like something is odd somewhere...
Anything odd about your system (not using compositing, using an odd sound card, that sort of thing)?

Hi everybody,

I've today uploaded a preliminary test version of VICE 2.4. I finally get fed up of the public version not working.
http://www.retroreview.com/iang/Vice_AmigaOS4_2.4_test.lha

The reasons why the public version didn't work are quite scary... it could never have worked. It didn't do basic things like calling GetInterface() on the library base, and so of course fell over on the first library call. There's lots of AMIGA_OS4 defines in there, but none of them do the interface opening... yet it DOES call the interface closing. Very strange. Fixed now.
Another crash was joyai_open() being called to initialise AmigaInput before the library was loaded. Also not good.

The best bit, though, and the trickiest bit, was the hang after the window had opened which is what you got if you fixed the other problems.
The Amiga code was calling p96LockBitMap() on the bitmap, and then calling the render routine, and then returning to call p96UnlockBitMap().
All seems fair enough? Yes. Until you realise that the render routine checks for a palette change, and can load the pallete off disk.

Loading off disk while the BitMap is locked? Not a good idea. It would work, but then as soon as Vice tried to call BltBitMap on the bitmap it hung solid. Presumably the loading while locked trashed the bitmap structure somehow.

This version is here is the non-stripped version of x64. Copy it into the standard VICE-2.4 distribution, but make sure you either rename "x64.exe.info" to "x64.info", or call "x64" from the CLI. If you just double click on the icon from Workbench, it'll run x64.exe which is the old, broken version.

I am aware that the monitor crashes in the locale library. Probably a NULL interface again.

Any other crashes please report them in this thread and I'll see if I can fix them.

How much network activity is there on your LAN? Does it GR when you don't have any apps open that use the network?

I find my Sam440ep crashes smbclient a lot when my LAN is under heavy load, even when the load isn't accessing the Sam itself.

Personally I'm hoping to see a lot more shareware on the store, rather than the freeware we normally get.
I know that sounds crazy, but the more people get money (even if only a bit of extra pocket money) the more apps will be written, and that's what we sorely need.

I mean it's a bug that I've fixed in the ATIRadeon.chip - it'll be released to beta-testers soon, I'm sure.

I fixed it. :) Overlay now works nicely.....
It *was* a bug in the Radeon driver.

I just tried it only my Voodoo III A4000 Os4.1.
I requested a r5g5b5 overlay window and it actually gave me a r5g6b5 window! Once I tweaked the code to support this it worked just right, though.
On my Sam440 with the M9. though it's still pink and green with the r5g6b5 code, so yes, I think it's a Radeon driver problem I'm afraid!

I'd have thought if it was an endian issue then:
a) 0xFFFF would still be white (I tried using R5G6B5 - still pink)
b) 0x0000 would still be black
c) 0x7C00 would come out blue.

The colours are right - except for the white/black pink/green thing.
But thanks for the input! The more ideas the better!

@thellierMAME doesn't use Sprites and fonts like that - it builds up the display from dynamically created textures.
First it creates all the primitives in system memory (this would be very slow in graphics memory).
Then it renders the primitives in system memory (again, very slow in graphics memory).
Then I do a p96WritePixelArray to video memory, and then CompositeTags() it over to the display (unless it's an overlay surface).

I only get the data once the primitives have been created (in system memory) though. MAME does have some support for OpenGL textures, and these are all held in video memory, but I'm not aware of it being intelligent enough to cope when video memory runs out (I presume OpenGL does this transparently) - this would be very necessary on a system like the Sam440ep with only 32MB VRAM.

It is R5G5B5 - the bytes are correct. I tested by setting all red, all green and all blue - and all was correct. It really is just that white is pink and black is green!

The R5G5B5 overlay is first, the YUV422CGX overlay is second (using my own mapping code):




Thanks for the help though! It's all useful information!

@Hans

Thanks for the advice, but I tried that and it's no different (as it should be - the autodoc says it's ignored).
I'm wondering if it's something in the Radeon hardware that needs to be set up, but we don't have a way of doing it in the P96 API? The DirectDraw documentation says you need to specify the source colourkey and the destination colourkey, but there's no way of doing that for us.

Has anyone ever actually used RGB overlays before?

If you can think of anything else though I'd be very grateful - each few percentage points of speed on my MAME is making it a bit more usable on lower end Amigas....

That's what I first thought. It's very confusing.
Same happens on my Radeon 9250.... white is pink, black is green, everything else is fine and RGB components in isolation work perfectly.
If you don't know the answer, I suspect no-one does ...!
A shame, it gives a big speed up....