Old Sprite Format won't Render

I have got some documents that contain thousand of artworks 1.12 files & drawfiles [all 1993 or earlier], but all Draw Displays is Bad MODE on a grey box, Artworks won’t load it (“Ea02” divide by zero error) & drawplus crashes (divide by zero crash), and ImpressionX shows nothing.

Analysis of one of the files using !MultiTask show:
DrawFile ptr,Type,X1,Y1,X2,Y2,FgCol,BgCol,Text
&28,5,&0,&0,&19600,&17000,&0,&0,Sprite object
End of file

Sprite Old format ** Deprecated Mode >53 ? x ?, ??bpp no mask – sprite name: screen

Was this a RiscOS 2 file, how do I get them to render without having to modify all the files (as they are all embeded into other files) or without changing the size of of the blob.

The problem is “screen” sounds like a screenshot that was taken in a custom mode. It was common in the old days to have modules that provide a range of additional screen modes (I think Ovation had such a thing). Unfortunately nobody ever considered what might happen if this screen mode was no longer recognised by the operating system.

You have two choices. The first is to look for whatever might have created this extra mode and see if you can get it running on an emulator to determine its colour depth etc.
The second is to binary edit the sprite header in the DrawFile to try common modes (12, 20, 15, 21, etc). Somewhere along the way the data should match up so the sprite should then appear correctly. Extra modes modules tended to give new resolutions but were obviously constrained to colour depths that RISC OS knows about.
Once you have this information, a small BASIC program can be written to locate such sprites and perform the modification.

Yes. Suggest you try replacing the mode number word with 0, 8, 12 and 15 in turn (1bpp, 2bpp, 4bpp, 8bpp) – one of these will enable the sprite to display something sensible. Now you’ve identified the colour depth, if the eigen scaling is wrong then try 4, 1, 9 or 13 respectively and if still wrong try 18, 19, 20 and 21 respectively.

AIUI you have a Sprite within a Draw file which is within an Artworks file.
If so, can you extract one of the Draw files. Will it render in a current version of Draw?
Can you extract just the Sprite. Does it render in a current version of Paint?
This might narrow down the problem.

The other thought I have is that once you have discovered the colour depth of the strange mode number, all you need to do is to create a numbered screen mode using a module and Service_ModeExtension (the old ones won’t work on RISC OS 3.50 onwards) and then they’ll all render correctly. Hopefully.

When I extract the draw file draw displays the correct size grey box containing the words “bad MODE”’ artworks won’t import it, drawplus crashes, and impressions shows a blank image. When I extract the sprite paint won’t load it, artworks won’t load it, impression shows a blank box (I’ve not tries drawplus).

I suspect that the mode information is one from CC’s colour card gold, they were modes 80-120ish from memory.

The draw file has the sprite at offset &28. Hence at offset &68 is the mode number word. Try replacing this word with the mode numbers suggested above and Draw should produce something – one of the mode nos is likely to display correctly. Then write a module to add that numbered mode. Then all the other sprites will display correctly without alteration. Bingo!

The mode number in the file is 78 ( 0×4e), and it appears that mode 9 renders it correctly. This mode number does not appear in the colour card, or scanlight documentation. I’ll see if I can get them to render with a module (assuming they are all the same).

The mode number in the file is 78 ( 0×4e), and it appears that mode 9 renders it correctly. This mode number does not appear in the colour card, or scanlight documentation.

A quick dose of Google and:

-Working mainly in multisync mode 78 (Impression 16-colour large workarea mode)
Ok, here are a few things I have noticed about SrcEdit:
[http://www.chiark.greenend.org.uk/~theom/riscos/docs/apps/ROLibRequests.txt]

(It’s actually very similar to Computer Concepts Mode 78
[https://groups.google.com/d/topic/comp.sys.acorn/RVeNj_BhXCQ]

According to the PCATS manual, mode 78 is a 4bpp EX1:EY2 mode, like a higher resolution version of mode 12, so try poking the mode word to that instead. I would imagine that mode 9 would give the wrong aspect ratio to your sprites, although it would get the bpp right.

For the sake of completeness…

The State Machines G8 graphics card manual lists the following mode numbers:
1bpp 64,68,72,76 (EX1:EY1) 80,84 (EX1:EY2)
2bpp 65,69,73 (EX1:EY1) 81,85 (EX1:EY2)
4bpp 66,70 (EX1:EY1) 82,86 (EX1:EY2)
8bpp 83,87 (EX1:EY2)

The PCATs graphics card manual lists the following:
1bpp 96,108 (EX:EY1) 72,76,80,84 (EX1:EY2) 88,92,100,104,112 (EX2:EY2)
2bpp 97,109 (EX:EY1) 73,77,81,85 (EX1:EY2) 89,93,101,105,113 (EX2:EY2)
4bpp 98,110 (EX:EY1) 66,74,78,82,86 (EX1:EY2) 90,94,102,106,114,123,124,125 (EX2:EY2)
8bpp 103,126,127 (EX:EY1) 67,75,79,83,87 (EX1:EY2) 91,95,115,116,117,118 (EX2:EY2)
12bpp 119,121 [EX-:EY4] – special mode where three 4bpp pixels combine horizentally to make a 12bpp pixel
16bpp 120,122 [EX-:EY4] – special mode where four 4bpp pixels combine horizentally to make a 16bpp pixel

Between G8 and PCATS, modes 66,72,73,76 appear to be inconsistent with regards to aspect ratio, but consistent in regards of bpp.

The Computer Concepts ColourCard manual lists mode numbers 88-123:
1bpp 96,100,112,120 (square-pixel) 92,108 (rectangular pixel)
2bpp 97,101,113,118,119,121 (square-pixel) 93,109 (rectangular pixel)
4bpp 88,90,98,102,114,122 (square-pixel) 94,110,115,116,117 (rectangular-pixel)
8bpp 89,91,99,103,123 (square-pixel) 95,111 (rectangular pixel)
15bpp 106,107 (square-pixel) 104,105 (rectangular pixel)
It’s not clear which of the square pixel modes are EX1:EY1 and which are EX2:EY2.

Between Colourcard and PCATS, modes 104-106,115-123 appear to be inconsistent in terms of bpp, and modes 108-110 appear to be inconsistent in terms of aspect ratio but agree on bpp.

Mode 71 isn’t listed for any of the three graphics enhancers. All other modes >= 64 are covered.

All other modes >= 64 are covered.

I seem to recall both Impression and Ovation used to come with modules that provide extended modes…and they both used similar/same mode numbers (somewhere around 60-80)…and no, they weren’t the same.
I don’t think anything was “standardised” with relation to additional modes. It depended upon your hardware, its manufacturer, and what software was being used.

I used to use a “larger” version of MODE 12 a lot until I learned the hard way that screenshots and sprites from it were unusable on “ordinary” systems. Yup, I crashed into this problem twenty five years ago. Nice to note that nothing has changed. ;-)

I tried all of the modes that Chris suggested including 12, but mode 9 was the only one that displayed correctly.

used to come with modules that provide extended modes…

Pre-RISC OS 3.50 modules for screen mode extension will not work on RISC OS 3.50 and later. They need to be rewritten.