OS4 compatible UAE expansion development status

[AMIGASYSTEM]

Originally Posted by Aegis

Alternatively, to test the screen redraw issues you can download the PNGs I was using here and just open them up with Multiview.

Ciao Aegis, on OS4 could be a problem of DataTypes, on OS3 UAE-GFX your PNG images are seen perfectly, tried to convert images JPG and OS4 UAE-GFX now he sees them perfectly.

[Toni Wilen]

Originally Posted by ccapublic

About uaenet.device : is it more efficient (or possibly more efficient later after potential optimizations) than emulating a realtek 8029 behind a pci bridge ?

I don't know. It is someone elses problem to test

Ps: did you get any support or feedback (or any progress) about how to control which code petunia interprets versus translates ?

I lost interest. The way I want it to be done apparently is not possible, at least not officially. (private api, nda, stuff, blahblah)

[Aegis]

Originally Posted by AMIGASYSTEM

Ciao Aegis, on OS4 could be a problem of DataTypes, on OS3 UAE-GFX your PNG images are seen perfectly, tried to convert images JPG and OS4 UAE-GFX now he sees them perfectly.

Unless OS4 and WarpDT's PNG datatypes (and TVPaint) are all equally bugged then it's a WinUAE issue. I've noticed Multiview shows some images without this redraw issue (WarpDT PSD datatype) but using a PicassoIV instead of uaegfx those PNGs/TVPaint work just fine.

Originally Posted by Toni Wilen

I lost interest. The way I want it to be done apparently is not possible, at least not officially. (private api, nda, stuff, blahblah)

You can say 'I told you so' if it makes you feel any better

[huepper]

Originally Posted by Aegis

Hahaha! Yes - WinUAE's awesome. How awesome? THIS awesome:

WAH!!!

Gimme this settings and UAE-Version.
Great.

[ccapublic]

I lost interest. The way I want it to be done apparently is not possible at least not officially

If I remember well forcing petunia to translate uae 68k bootrom code would significantly speed up some extensions correct ? Did you find another way to proceed or do you have to live with the limitations implied by petunia interpreting bootcode until nda, private api, stuff, blahblahblah get sorted out, ie probably never...

Another question : could bootrom or part of it be ppc code instead of 68k code to 1/ workaround petunia stuff 2/ avoid weird stuff like translating 68k code to ppc code (petunia - amiga side) then translate resulting ppc code to x86 (qemu - winuae side) ?

Those questions might be oot, irrelevant, meaningless, "you talk as if you knew anything about how all of this works but obviously you don't", "I Already told you I don't know ppc enough"... (as I just have basic culture of those topics) so feel free to ignore / delete.

[AMIGASYSTEM]

Originally Posted by Aegis

Unless OS4 and WarpDT's PNG datatypes (and TVPaint) are all equally bugged then it's a WinUAE issue. I've noticed Multiview shows some images without this redraw issue (WarpDT PSD datatype) but using a PicassoIV instead of uaegfx those PNGs/TVPaint work just fine.

I tried to delete Datatypes present in OS4, and i installed THESE Warp datatype, now your photos PNG on OS4 you can see perfectly with Multiview, although initially there was some white line then disappeared.

[Michael]

Any ideas how to get uaenet.device working ?
For me it always crashes UAE when you attempt to open it

[Aegis]

Originally Posted by AMIGASYSTEM

I tried to delete Datatypes present in OS4, and i installed THESE Warp datatype, now your photos PNG on OS4 you can see perfectly with Multiview, although initially there was some white line then disappeared.

That's exactly the redraw bug I've been describing - it shouldn't happen with uaegfx - it doesn't with Picasso IV.

Originally Posted by Michael

Any ideas how to get uaenet.device working ?
For me it always crashes UAE when you attempt to open it

I got it working by renaming the ethernet.device 'uaenet.device' then after setting up the connection I simply renamed it back again (uaenet.device is resident - you don't actually need a device).

[AMIGASYSTEM]

Originally Posted by Aegis

- it doesn't with Picasso IV.

I confirm, with a Picasso IV screen the problem does not exist.

The graphical error also solves "saving the image PNG" after opening a Windows graphical program.

Probably the look and error is due to the specific format PNG native File.

[AMIGASYSTEM]

Originally Posted by Michael

Any ideas how to get uaenet.device working ?
For me it always crashes UAE when you attempt to open it

When do crashes, your problem is to be able to sail with the Browser on the Internet?
I do not have uaenet.device enabled on WinUAE and Internet browsing works anyway.

[Toni Wilen]

Originally Posted by ccapublic

Another question : could bootrom or part of it be ppc code instead of 68k code to 1/ workaround petunia stuff 2/ avoid weird stuff like translating 68k code to ppc code (petunia - amiga side) then translate resulting ppc code to x86 (qemu - winuae side) ?

"I don't do PPC code". (Unless someone really wants to hire me to do it or something similar)

Originally Posted by Michael

Any ideas how to get uaenet.device working ?
For me it always crashes UAE when you attempt to open it

"Not enough information error" error. (EDIT: use official beta if crash generates crash dump file, other dumps are useless)

Originally Posted by Aegis

I got it working by renaming the ethernet.device 'uaenet.device' then after setting up the connection I simply renamed it back again (uaenet.device is resident - you don't actually need a device).

Just use advanced mode and type the device name in device name field.

[Romanujan]

Originally Posted by Toni Wilen

"I don't do PPC code"

Could http://www.coyoteflux.nl/ppc680x0.htm be of any use?

[edit] Download does not work, but you can find the tool on Aminet - http://aminet.net/search?query=ppc68.

[Michael]

I think I found the problem, uaenet.device seems to work only together with uaegfx, and not with PicassoIV

[Aegis]

Originally Posted by Michael

I think I found the problem, uaenet.device seems to work only together with uaegfx, and not with PicassoIV

Picasso IV works fine with uaenet.device here.

[Toni Wilen]

Originally Posted by Aegis

Picasso IV works fine with uaenet.device here.

Same here. In other words "works for me"


-> logs from both configs needed.

[Michael]

Done some more checking.... The magic is behind Add PC drives at startup option
Once enabled uaenet.device also works, without it, it does not.

But when PC drives are enabled.... what are these crazy files doing on PC drives?
1zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz Size=0

[Aegis]

Originally Posted by Michael

Done some more checking.... The magic is behind Add PC drives at startup option
Once enabled uaenet.device also works, without it, it does not.

Bzzzt. Guess again! 'Add PC drives at startup' is disabled here and uaenet.device is working fine.

Here's my config:

[Michael]

Aegis - you have a shared directory drive! It's the same thing really.

[Aegis]

Originally Posted by Michael

Aegis - you have a shared directory drive! It's the same thing really.

uaenet works without it - and with the .hdf set to Cyberstorm SCSI.

[Michael]

The white lines problem.... (UAEGFX - ARGB32 modes)
When viewing via MultiView, the problem appears only with 32bit images
like with example backgrounds from /prefs/presets/patters/OS4...

rebirth_1280x800.png - 24bit - no problems
background_1280_720.png - 32bit - white stripes

also the stripes have interesting CRT like scrolling effect when you move the image inside the window, and also the mouse pointer clears the bugs if you move it over the damaged area. (UAE bug?)