Worth buying Pandora after Pyra announcement?

[ekianjo]

If there's not a decent compatibility layer at launch, I'll probably make one. It's right up my alley. I don't see any reason why we can't get close to 100% backwards compatibility.

I'm not saying it's not possible, I'm just saying that is nobody plans for it before launching the Pyra we won't have all PNDs working on the Pyra when it's available. But anyway, I would consider it to be a very minor problem.  

 

[_wb_]

If there's not a decent compatibility layer at launch, I'll probably make one. It's right up my alley. I don't see any reason why we can't get close to 100% backwards compatibility.

I'm not saying it's not possible, I'm just saying that is nobody plans for it before launching the Pyra we won't have all PNDs working on the Pyra when it's available. But anyway, I would consider it to be a very minor problem.  

I assume that notaz will make an omap5 version of his omapfb SDL and that it will be available on the Pyra at launch. I assume that omap5 is sufficiently backwards compatible with omap3 to make that easy enough. I'm not talking about the new features in omap5 like the 2D GPU, it will of course be more work to add those. I'm just talking about the features that we already have on the Pandora (hardware scaler, NEON blitters).

Even if we're stuck with a standard Debian SDL, things should still work. They would just have suboptimal speed (slow default blitters), and they would probably not be nicely scaled to full screen but look like a small 800x480 or whatever source resolution image with a huge black border around it.

 

[ekianjo]

Even if we're stuck with a standard Debian SDL, things should still work. They would just have suboptimal speed (slow default blitters), and they would probably not be nicely scaled to full screen but look like a small 800x480 or whatever source resolution image with a huge black border around it.

Is SDL2 retrocompatible with the SDL we have in SZ by the way ?  

 

[Natsu]

Quite frankly, unless you really need the Pandora right now and/or really can't wait, it would be crazy not to wait. You going have pay about the same price and

selling it at that point will sell even for less value.

 

[_wb_]

Even if we're stuck with a standard Debian SDL, things should still work. They would just have suboptimal speed (slow default blitters), and they would probably not be nicely scaled to full screen but look like a small 800x480 or whatever source resolution image with a huge black border around it.

Is SDL2 retrocompatible with the SDL we have in SZ by the way ?  

No, it is not. A major version number increment typically means backwards incompatibility was needed, and this is no exception. That does not mean that it has to be a lot of work to rewrite an SDL1.x application to SDL2, see https://wiki.libsdl.org/MigrationGuide

 

[_jr_]

It should be possible to have both SDL 1 and 2 libraries present, isn't it?

 

[_wb_]

It should be possible to have both SDL 1 and 2 libraries present, isn't it?

Of course. That is usually what happens when there's a widely used older version and a newer incompatible version of something. E.g. Python 2 and Python 3, GTK 2 and GTK 3, and so on.

 

[Kumaki]

Still, a chrooted Angstrom environment might end up being the quickest hack to supporting old PNDs with no source and no maintainers

 
Do you think the PNDs using Notaz's SDL will work out of the box ? Somehow I don't think it's likely, but I may be wrong.

If there's not a decent compatibility layer at launch, I'll probably make one. It's right up my alley. I don't see any reason why we can't get close to 100% backwards compatibility.

Now that sounds good.  I have always liked backwards-compatibility. 

I guess you could say I am very much an old-schooler, and something of a tech Luddite.  Once I get comfortable with something, I don't like change, LOL.

 

[Kumaki]

It should be possible to have both SDL 1 and 2 libraries present, isn't it?

It should be possible to have both SDL 1 and 2 libraries present, isn't it?

Of course. That is usually what happens when there's a widely used older version and a newer incompatible version of something. E.g. Python 2 and Python 3, GTK 2 and GTK 3, and so on.

Good.  Sound like backwards-compatibility will be possible, and will most likely get incorporated.

Now it is only a matter of how easy it is for the end user to USE the backward-compatibility...and a price-point.  If both of these items meet with what I am looking for, I could be a Pyra owner..

 

[WizardStan]

Even if we're stuck with a standard Debian SDL, things should still work

Different ABI. Debian is hard-float, Zaxxon is soft-float. A compatibility layer will be required to load soft-float versions of many libraries at least. That could be as simple as having the soft-float libraries in a different directory and then forcing an LD_LIBRARY_PATH to point to it, or as complex as some kind of wrapper for every single function called to take "int" arguments and manually push them to float registers.

 

[_wb_]

Even if we're stuck with a standard Debian SDL, things should still work

Different ABI. Debian is hard-float, Zaxxon is soft-float. A compatibility layer will be required to load soft-float versions of many libraries at least. That could be as simple as having the soft-float libraries in a different directory and then forcing an LD_LIBRARY_PATH to point to it, or as complex as some kind of wrapper for every single function called to take "int" arguments and manually push them to float registers.

Does this also cause problems if you're only using functions with integer arguments? Most of SDL (not the GL stuff) does not use floats at all. Blitting stuff to the screen etc. only uses integers. I would assume that as long as you don't pass floats around, it does not matter. But maybe I'm wrong here, I don't know anything about the details of the two ABIs.

Anyway, in general we would indeed need soft-float versions of all the libraries PNDs rely on. Given that SuperZaxxon is not that large to begin with, and most of it is not affected (e.g. if a PND calls Python or Perl or Bash or whatever external program it does not matter what ABI they were compiled for, only dynamic linking to libraries is affected), it should be no problem (space-wise) to include those redundant versions in the Pyra firmware.

 

[WizardStan]

Does this also cause problems if you're only using functions with integer arguments?

That's a good point. No, as long as there are no floats anywhere there should be no problem. Many (most?) PNDs should run fine, but it won't be 100%. There's probably even a few PNDs that don't intentionally use floats but have them anyway as a result of some included library.Actually I wonder, I'm going to need to test that. I have devices with both hard and soft float operating systems, I can do a simple test. Even if there's no floats the OS is still aware of the fact that the library and application were compiled with different ABIs: they should work but the OS may not let them for safety reasons. But then this is linux so even if it doesn't let them by default there's almost definitely a flag somewhere that says "trust me, I know what I'm doing".

 

[TrashyMG]

Notaz's SDL implementation is tied with the Pandora's hardware for scaling/rotating and such, the OMAP5 is similar but it behaves differently.. my guess some work there is also needed to make it work properly on the Pyra.

 

[sebt3]

I for one would be very surprized if any PND run as is on a hard-float distrib. The probability that all the libraries used dont use float is close to 0 (SDL and libX11 both does. Hey even libc does...).

A statically linked binary could work though

 

[levi]

As I understood it, the only difference I've noticed between the softfp and hardfp ABIs is that the former contains no direct floating point instruction, but makes a call for each which invokes the software floating point lib to perform an integer emulated replacement. The latter just calls the FPA hardware to do the floating point work.


The ARM docs that I've been able to find suggest that floating point numbers are encoded differently in the two schemes. If you need to pass in a floating point number or receive one back from a call, the compiler will need to populate either the floating point registers or some integer registers with the appropriate values. It can be configured either to receive numbers in one format and make calls in the same or do both in the other format, hence they're designed to work with other libs and functions built with the same compiler option - either softfp or hardfp.


The docs I've found don't suggest the ABI varies in any way if you're not using any floating point arguments, but I've not found anything that explicitly says that, just docs that don't mention any other changes.

 

[WizardStan]

There are three ABIs: hard, soft, and softfp.

In hard, the CPU is assumed to have an FPU. A floating point number is stored in a floating point register to call a floating point function. When I say function, I don't mean "10.0*2.0", I mean "foo(10.0)".

In soft, the CPU is assumed to not have an FPU. It is as you say, the floating point number is emulated, the floating point number is broken up and put into integer registers, and software math is done on it in integer space, which is very slow.

In softfp, the CPU may or may not have an FPU. A floating point number is broken up and stored in integer registers and the function that is called is then responsible for putting them back together to do standard FPU operations or call the floating point emulation if there's no FPU.

The Pandora is softfp. Before a program can call a function that uses floats it converts it to integer representation and stores it in integer registers. The function then has to reassemble it and store that into a float register.

If a PND calls a float function in a library and that library has been compiled hard float, it will look for its arguments in floating point registers. It will find junk.

The operating system is aware of what the library and application are compiled with. In order to prevent the junk that it knows will happen when you run a hard app against a soft library (or vice versa) I can see it refusing. I haven't actually tested this yet, I've got some other work I need to finish before I can get time on the boards, but hopefully this afternoon.

 

[_wb_]

Notaz's SDL implementation is tied with the Pandora's hardware for scaling/rotating and such, the OMAP5 is similar but it behaves differently.. my guess some work there is also needed to make it work properly on the Pyra.

Yes, probably. Or maybe it's fully backwards compatible on that aspect. I wouldn't know. In any case I hope that notaz finds out and updates his SDL if needed.

I for one would be very surprized if any PND run as is on a hard-float distrib. The probability that all the libraries used dont use float is close to 0 (SDL and libX11 both does. Hey even libc does...).


A statically linked binary could work though

Most libraries do have at least some floating point functions, but I'm not sure if that means that anything that dynamically links to them will break even if it does not call any function with float args. E.g. if I'm not mistaken, NanoLemmings and PIV don't use floats at all, so I'm not sure if they would necessarily break.

And of course there are PNDs that do not link to any library since they only contain stuff like shell scripts, Perl, Python, Java etc. Those should work even if the Pyra would use an x86 SoC or whatever.

Anyway, we'll need the compatibility softfp versions of libraries for many PNDs. And if a PND is still being maintained, it will for lots of software make sense to release an update anyway, in order to take advantage of the higher screen resolution, extra input buttons, etc.

 

[notaz]

The OMAPs have migrated from omapfb driver to DRM based omapdrm, so we'll have to migrate to omapdrm (DRM here is "direct rendering manager", not something else you might think). This is required to support HDMI output at least, and both drivers can't coexist. The DRM API is entirely different and much more complex that fbdev (which is used for almost everything on pandora), I'm still digging through it.. It would look like they're mostly equivalent in exposed OMAP functionality, but the rotation appears to be rather difficult to use (needed for that damn portrait LCD). This will make it hard to do efficient backward compatibility and SDL (without doing multiple buffer copying+rotation in software).

About softfp vs hardfp, all libraries and binaries are tagged with soft(fp) or hard tags in elf headers, if there is mismatch between tags, runtime linker will refuse to load the whole program.

 

[robohappy]

Quite frankly, unless you really need the Pandora right now and/or really can't wait, it would be crazy not to wait. You going have pay about the same price and

selling it at that point will sell even for less value.

If the Pyra is coming in a year or two, Id gladly wait, however if the Pyra is coming 3-4 years from now, im getting a Pandora! 

 

[Neelix]

Quite frankly, unless you really need the Pandora right now and/or really can't wait, it would be crazy not to wait. You going have pay about the same price and

selling it at that point will sell even for less value.

If the Pyra is coming in a year or two, Id gladly wait, however if the Pyra is coming 3-4 years from now, im getting a Pandora! 

There's a very good reason why ED has decided not to specify a time frame for the release of the Pyra.

Quite frankly, (IMHO) if you have any need of the functionality at all, it would be crazy to wait for the Pyra.  No one can be sure how long you'll be waiting, and Pandora won't be available for much longer.   Get a Pandora now while you can. 

- Neelix