A.D.A. Amiga Demoscene Archive

        Welcome guest!




log in with SceneID


Demos Amiga Demoscene Archive Forum / Coding / Extracting Graphics from old Amiga Games


Author Message
#1 - Posted: 17 Jan 2008 14:04
Reply Quote

i would like to port an old amiga game to Flash9 (Persian Gulf Inferno). After extracting the game-files from an .adf file that i have obtained from the internet, i wonder how to recognize relevant data inside a file (e.g. graphics/audio). Anything that i can look for with a hex-editor etc..

any suggestions ?
#2 - Posted: 17 Jan 2008 23:47
Reply Quote
Not sure if I remember it correctly, but I think Persian Gulf Inferno was quite OS friendly. I think it had a trackloader operating on a DOS filesystem and I think the data files were IFF ILBM files.
#3 - Posted: 18 Jan 2008 17:15
Reply Quote
yeah, I remember - because we didn't made it to the end - d!rt!e and me watched all the end screens with DOS Control :)
#4 - Posted: 18 Jan 2008 19:05
Reply Quote
A real lame way would be to take a screenshot and cut out the graphic you want with a paint package.
#5 - Posted: 19 Jan 2008 11:12
Reply Quote
If you've extracted the files, try to load them in an image viewer that identifies files by their content rather than filename. ACDSee for Windows is one option. If that fails, Google for "graphics file formats identifiers" or similar to get lists of ways to identify the files, then open in a hex editor.

There's a good chance they're IFF ILBM, but there's also a good chance they're in a custom format, in which case it'll be impossible without a lot of experimenting and/or reverse engineering. If they are in a custom format, it's likely to be (interleaved) bitplanes with widths divisible by 16 pixels. Don't expect any kind of chunky format.

Often multiple images are stored in collection files, in which case a ripping tool like this one may help, although only if they're in a recognisable format. If not, the way the collection file is organised could give you clues too. You could look for what seem to be lists of file offsets, dimensions/depth, and so on.

And finally you may find the data is compressed. That makes it harder, especially if it's done with a custom packer, which would force you to look at the executable code for the unpacking routines. An easy way to test if the files are packed is to pack them (with say, WinZip). If you get very little compression, they were almost certainly compressed already. If you get good compression, chances are good the images are uncompressed (or at least compressed with a basic algorithm like RLE).

But regardless, there's always WinUAE, screen captures and paint packages. :)
#6 - Posted: 19 Jan 2008 12:44
Reply Quote
for a good amiga ripper : Track2file http://amiga.emucamp.com/wt/files/memory/T2F122.lz x

for a good pc ripper : Jader Naub : http://wiki.xentax.com/index.php?title=Jaeder_Naub
#7 - Posted: 20 Jan 2008 00:06
Reply Quote
wrip is ace for ripping out things from files :)
#8 - Posted: 22 Jan 2008 16:00
Reply Quote
You can also use HRTmon to interrupt the game while running. Then you can find the copperlist and quite easily save the bitplanes as an iff/ilbm.
#9 - Posted: 22 Jan 2008 17:05
Reply Quote
I used hrtmon (with a level7 interrupt button soldered to my accelerator) to capture demos for A.D.A. I used this as a last resort when the prod didn't run on winuae (for example for Captured Dreams which didn't run on earlier versions of winuae).

It was crazy. Most demos didn't survive a level 7 interrupt and crashed when returning from hrtmon to the demo so you had to restart the demo for each screen. I can't count the amount of times i have seen certain demos... In many cases, screens weren't rippable at all anyway.

Thank god i don't have to use it anymore :o)
#10 - Posted: 28 Jan 2008 11:48
Reply Quote
cool thanks people!
#11 - Posted: 2 Feb 2008 07:22 - Edited
Reply Quote
When shutting of the system democoders sometimes use the Stackpointer (a7) to get an extra register. When using all 16 registres in the MC680x0 cpu this can this prevent unessesarry memacces in inner/outerloops.
Code get small enough to fit in the cache. Useful for 020/030 optimalisation. When an interrupt is triggered The SR and PC is pushed on the stack. With a a7 not being the a valid stackpointer, this can cause unexpected results . Demos will shut of all software interrupt but cant prevent level7 (hardware) interrupt.
Patching the software might fix this issue. Sourcode is available here:


(...) in the file HRTmonV2.s
PATCH here:

;-------------- Entry point of HRTmon ------------------------------------

cnop 0,4
location2 dc.l 0 ;HRTmon location
dc.b "HRT!"
monitor: or #$700,sr ;on 68060 it is granted that the first instruction
;is executed before any pending interupts, so we
;stop them to avoid any confusing
bset #0,entered
beq.b .enter
rte ;don't enter twice
.enter move.w #$2700,sr
movem.l d0-a7,registres
move.l 2(a7),d0 ;PROBLEM??
#12 - Posted: 2 Feb 2008 08:16 - Edited
Reply Quote
Level 7 protection in a game/demo could be implemented like this:
This code is probobly not working, but just to show the point :D

lea facestack,a7.
Do some stuff.

Interrupthandler: (in the game/ demo)
move.l a0,.backup

move.l a7,a0
subq.l #8,a0
lea realstack-8,a7
move.l (a0)+,(a7)+
move.l (a0)+,(a7)+

move.l #PhyScreenPointer,-(a0)
move.l #LogscreenPointer,-(a0)
move.l .backup(pc),a0


dc.l 0

blk.l 4096,0
Realstack: dc.l LogScreenPointer
dc.l PhyScreenpointer


  Please log in to comment





A.D.A. Amiga Demoscene Archive, Version 3.0