PhotoDesk 3.12

PhotoDesk 3.12 will not run on the Titanium, giving an error ‘Abort on data transer at …’ when performing the command ‘RMLoad $.Utilities.!PhotoDesk.Modules.PhotoDesk’ when executing its !Run2 obey file. Same error even if I use Aemulor.

Have you tried it with photo fix from rcomp

Yes. Didn’t fix it on Titanium. Works fine on ARMX6.

Yes it fixed on omap 5432evm to but I had to reinstall then run the fix before it would run.

Maybe a problem with new adfs?? Or has that fixed now???

It refuses to install from a version 3.12 ‘upgrade’ CD saying ‘transfer too complex’. Tried a ‘clean’ version 3.10 ex Iyonix, then update to 3.12, then apply fix – same abort error. Hence was able to upgrade an earlier version (3.10) but still gives abort error.

Maybe a problem with new adfs??

Not on titanium.

Not on titanium.

Piccolo Systems report the problem shown up by the new ADFS is common to both the Titanium and the OMAP5432. Though it appears to happen less frequently on the Titanium.

giving an error ‘Abort on data transer at …’ when performing the command ‘RMLoad […]

Do you have an address relative to the start of the module? Can you dump the code around that address?

Unfortunately it does not get as far as loading, so I cannot see how far into the module the abort address is. I presume its initialisation code fails and the module is left in RMA memory, inactive.

Can you *MemoryI around the address? With code, ought to be possible to match up to the module itself.

Can you *MemoryI around the address?

The error is ‘Abort on data transfer at address’ where address corresponds to the highlighted instruction at 000000F4 below:

Seems to be storing a guard? word at the end of the memory block it has just claimed?

What does *showregs give after the abort?
That should show what it was storing, and where – ie STR r0,[r2,r1]

I have not a Titanium but I use PD 3.13…

Maybe it fix any problems… not sure.

*showregs
Register dump (stored at &2000FF50) is:
R0  = 11111111 R1  = 00F0B4F6 R2  = 2052BC94 R3  = 00F0B4FA
R4  = 0007FD87 R5  = 00BFC3F0 R6  = 0027F37B R7  = 00010000
R8  = 00000000 R9  = 30003C6C R10 = FA641C3E R11 = 00000000
R12 = 30003C84 R13 = FA207D98 R14 = 205181EC R15 = 20518208
Mode SVC32 flags set: nzCvqjggggeaift        PSR = 20000013


SWI  "XOS_ReadMemMapInfo"
; sets R0 to 4k and R1 to &7DF7F showing
; most of 2Gbytes is available
MUL   R0,R1,R0
;  R0 = total memory available (&7DF7F << 12)
; sets R4 to &7DF7F + 8
; sets R5 to 24 * &7FD7F + 8 = &BFC3F0
; makes sure R5 is at least &8000
; sets R6 to &7DF7F + 4 * &7DF7F = &27F37B
; sets R7 to &10000
; sets R3 to R4 + R5 + R6 + R7 + 4 = &F0B4FA
; call XOS_Module to reserve workspace sizer = R3
; copies &11111111 into memory from R12 onwards
; using R12+i where i=R3 - 4,i-=4,i>=0
Hence abort as R3 is not aligned 

It appears to reserve a workspace size of &F0B4FA and then fill it with &11111111 but does unaligned, hence the abort.

Where is 3.13z available from please? I thought the latest available version was 3.12.

Also note the odd colours in the sprite saved on Titanium at 32k – appears on titanium as yellow bar but sprite is 32k RGB and Virtual Risc PC cannot handle it. ArtWorks and PhotoDesk and DplgScan on ARMX6 cannot handle it either but fortunately I did manage to find a way to convert it to a jpeg (but can’t remember how at the moment). It shows colours were wrong though.

3.13 is from a4com. Maybe is a prerelease. Sorry, I’m not at home. So I can not take a look in my mail archive.
I think you should have Detlefs email adress (early MX6 list).

@Chris: does your version run on any other processor which has alignment exceptions enabled?
If not, it is an alignment problem not a Titanium specific problem.
Looks as if one or more of r3-r7 need rounding up to a 4 boundary.

3.13z is an alpha version with known (so far untraced) bugs, when the bugs are fixed it will be released.

Also note the odd colours in the sprite saved on Titanium at 32k – appears on titanium as yellow bar but sprite is 32k RGB and Virtual Risc PC cannot handle it. ArtWorks and PhotoDesk and DplgScan on ARMX6 cannot handle it either but fortunately I did manage to find a way to convert it to a jpeg (but can’t remember how at the moment). It shows colours were wrong though.

The ‘funny’ colours are due to the Titanium using BGR format sprites, rather than the traditional RGB. You have to read the spriteword and modeflags to work out which new sprite format is being used. I know David Pilling has been working on Ovation Pro to make it understand these new sprites. I hope to update Snapper and ConvImgs to deal with the new style sprites (Snapper will save the sprite in the new format, but of course lots of software cannot display them). In ConvImgs, and DPScan, it is ‘simply’ a case of modifying the way the 24-bit RGB value is constructed in eg jpg or png production.

I know David Pilling has been working on Ovation Pro to make it understand these new sprites.

Shouldn’t this be the job of the OS? Shouldn’t you just chuck the data at OS_SpriteOp and have it do the necessary?
Each app reinventing the same wheel is…….

Shouldn’t this be the job of the OS? Shouldn’t you just chuck the data at OS_SpriteOp and have it do the necessary?

Well, yes. However, it is not just a case of plotting the sprite as is on the vdu. A number of the apps mentioned allow processing of the individual colour channels, so they have to know the sprite format The OS does not have a sprite to jpg or sprite to png SWI, so the app needs to know. In addition, older versions of the OS know nothing about these sprites. Unless the later OS versions have a direct call to convert sprite formats, then again you are on your own if you need backwards compatibility. Perhaps some of these issues will be addressed in the OS of the future.

A number of the apps mentioned allow processing of the individual colour channels, so they have to know the sprite format

Fair point, yes.

Thinking of a recent post regarding “how much space does this sprite require?”, maybe the OS ought to be more….forthcoming….with this sort of information.
I took a look at the docs for the various descriptors that may be used to describe a sprite. Um.

The OS does not have a sprite to jpg or sprite to png SWI, so the app needs to know

That’s the point that Rick was trying to make – the OS does not currently have that facility/feature, but it should.

Now if someone has the ability to create that feature and add it to the OS code set then the feature is in the OS and available to all applications.
If the default is to convert to a known format then ALL existing applications suddenly have the ability to work with the foreign format.

Alternately everyone can re-invent the wheel.

SWI  "XOS_ReadMemMapInfo"
; sets R0 to 4k and R1 to &7DF7F showing
; most of 2Gbytes is available
MUL   R0,R1,R0
;  R0 = total memory available (&7DF7F << 12)
; sets R4 to &7DF7F + 8
; sets R5 to 24 * &7FD7F + 8 = &BFC3F0
; makes sure R5 is at least &8000
; sets R6 to &7DF7F + 4 * &7DF7F = &27F37B
; sets R7 to &10000
; sets R3 to R4 + R5 + R6 + R7 + 4 = &F0B4FA
; call XOS_Module to reserve workspace sizer = R3
; copies &11111111 into memory from R12 onwards
; using R12+i where i=R3 - 4,i-=4,i>=0
Hence abort as R3 is not aligned</pre>

It is a peculiar way of calculating a workspace size, for sure.

• R0 is memory size (from ReadMemMapInfo and a MUL)
• Shifted right 12 into R4 to give the memory size divided by 4096 (which incidentally is an 8th of the RAM size, divided by 32K units)
• R5 is set to the size of the memory map (number of pages in R1) times 3
• …plus a word
• …twice.
• R6 seems to be the same 8th/32K calculation, again. This value has the page count (shifted left twice) added in.
• R7 is set to &10000

Now it work out how much it actually wants:

• R3 is set to R4 (first mem calc) + 8 + R5 (second mem calc) + R6 (third mem calc) + R7 (the fixed &10000).
• This is then claimed.
• And the entire buffer is filled with &11111111
• …which, as we know, fails due to the non-word-alignedness.

Now, the interesting question comes from looking at the registers in the dump:

R4  = 0007FD87 R5  = 00BFC3F0 R6  = 0027F37B

Thankfully the results of the calculations are scattered in the upper registers so we can see what is going on even after the memory claim and buffer fill attempts. R4 and R6 have resulted in bogus values. Why?

Using your calculations, this suggests that ReadMemMapInfo is returning a page size of 4096 (bytes) and a page count of 515967 pages.

And this is where we fail. 1<<12 is 4096. So if we are adding the page count to the page size and shifting it to divide by 4096…
…aren’t we basically going from page count, to total memory size, then back to page count again?

I suspect there are two principle points of failure here. The first is that some of the calculations would seem to imply the assumption of the page size being 32K; something that hasn’t been true for a long time. This isn’t a big thing, as we work on page count more than page size, so it scales up.
The bigger thing is that this methodology will quite clearly and demonstrably fail when the page count is not a number divisible by four.
With the values you have provided, the implication is that the available memory is 2,113,400,832 bytes. This is not 2GiB (which is 2,147,483,648 bytes). There is a discrepancy of 34,082,816 bytes, or ~32½MiB. I’m guessing this is reserved for GPU workspace or somesuch?
I don’t know what the additional about-half-a-megabyte there is for, but it is this which is damaging the calculations. Or maybe it is just luck that the GPU claims on, for instance, the Pi family are regular non-weird amounts, so the page size has always been divisible by four. Until now.

I can’t provide clues on how to fix it as I don’t know what the calculations are actually for though I’d say the simplest “cheap fix” is to mask out the lower two bits of the page count (R1 following ReadMemMapInfo) to force it to the next lowest multiple of four. A simple one-instruction fix, and possibly a lot easier than trying to work out what the heck is going on here…

By the way, I make &F0B4FA to be about 15MiB. Wouldn’t this be better in a Dynamic Area instead of stuffed into the RMA?

On the Titanium, the available memory is 2050MB.

R4 and R6 have resulted in bogus values. Why?

Not sure they are bogus. &7FD7F * 4k is available memory = 2GB – 4k – 2.5MB which looks about right (some space reserved for ROM).