PhotoDesk 3.12
Pages: 1 2
Chris Hall (132) 3559 posts |
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. |
rob andrews (112) 200 posts |
Have you tried it with photo fix from rcomp |
Chris Hall (132) 3559 posts |
Yes. Didn’t fix it on Titanium. Works fine on ARMX6. |
rob andrews (112) 200 posts |
Yes it fixed on omap 5432evm to but I had to reinstall then run the fix before it would run. |
rob andrews (112) 200 posts |
Maybe a problem with new adfs?? Or has that fixed now??? |
Chris Hall (132) 3559 posts |
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. |
Chris Evans (457) 1614 posts |
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. |
Rick Murray (539) 13851 posts |
Do you have an address relative to the start of the module? Can you dump the code around that address? |
Chris Hall (132) 3559 posts |
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. |
Rick Murray (539) 13851 posts |
Can you *MemoryI around the address? With code, ought to be possible to match up to the module itself. |
Chris Hall (132) 3559 posts |
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: |
Martin Avison (27) 1494 posts |
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? |
Raik (463) 2061 posts |
I have not a Titanium but I use PD 3.13… Maybe it fix any problems… not sure. |
Chris Hall (132) 3559 posts |
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. |
Raik (463) 2061 posts |
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. |
Martin Avison (27) 1494 posts |
@Chris: does your version run on any other processor which has alignment exceptions enabled? |
Chris Evans (457) 1614 posts |
3.13z is an alpha version with known (so far untraced) bugs, when the bugs are fixed it will be released. |
Chris Johnson (125) 825 posts |
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. |
Rick Murray (539) 13851 posts |
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? |
Chris Johnson (125) 825 posts |
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. |
Rick Murray (539) 13851 posts |
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. |
Steve Pampling (1551) 8172 posts |
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. Alternately everyone can re-invent the wheel. |
Rick Murray (539) 13851 posts |
It is a peculiar way of calculating a workspace size, for sure.
Now it work out how much it actually wants:
Now, the interesting question comes from looking at the registers in the dump:
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… 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. 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… |
Rick Murray (539) 13851 posts |
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? |
Chris Hall (132) 3559 posts |
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). |
Pages: 1 2