Cam Astro Marine Corps fit on 1 Disk?

[BarryB]

Using the QTX version it only has data to track 61.1 on Disk 1 and data to track 64.1 on Disk 2, but is that data heavily packed enough to prevent it fitting on a standard Amiga disk?

[Galahad/FLT]

I don't think so, game is already packed and a good judge is the size of the ZIP archives for the disk images, if both of those archives combined was around 900K, it would be worth investigating, but otherwise no.

[BarryB]

Well both disks compressed into 1 zip archive is 1.2mb so that answers that question!

Thanks Galahad

[Don_Adan]

Originally Posted by BarryB

Well both disks compressed into 1 zip archive is 1.2mb so that answers that question!

Thanks Galahad

Not exactly, ZIP dont compress too good already packed files, double packing is never efficiency. You must depack all files from both disks first and later pack all files using ZIP or arj7.

[Galahad/FLT]

Originally Posted by Don_Adan

Not exactly, ZIP dont compress too good already packed files, double packing is never efficiency. You must depack all files from both disks first and later pack all files using ZIP or arj7.

Its a good enough indicator, by all means prove me wrong

[Don_Adan]

Originally Posted by Galahad/FLT

Its a good enough indicator, by all means prove me wrong

Sorry, present I cant, because i'm inactive.
And no access to Amiga.
For almost impossible missions is ross
Anyway except packer efficiency, often some files/data are doubled for 2 disks games.
I dont think that creating 1 disk version for LZMA (Fire) packer can be problem for this game, perhaps for arj7 too. But LZMA has very slow decompression, then game can be not playable. But maybe mix LZMA and Arj7 can be solution, exactly some data packed within LZMA packer and some data packed with Arj7 packer.

[BarryB]

Well the disks are NDOS so someone with the relevant experience is needed to extract and unpack the files! The only file ripper I have is Track2File and that found nothing.

[ross]

Originally Posted by Don_Adan

For almost impossible missions is ross

I took a quick look and it seems to me that the loading and unpacking system is very simple.
The packer doesn't seem very efficient, so there's plenty of room to get better use of the space (and loading speed..).

I'm not saying it's possible to fit everything on one disk or that I will .

Anyway except packer efficiency, often some files/data are doubled for 2 disks games.

You fully hit the target.
There is a 'flag' for the loader signaling to load "from whatever disk is inserted".
And indeed this feature is used for the intro and start menu (including the tracker module).

[dlfrsilver]

Originally Posted by ross

I took a quick look and it seems to me that the loading and unpacking system is very simple.
The packer doesn't seem very efficient, so there's plenty of room to get better use of the space (and loading speed..).

I'm not saying it's possible to fit everything on one disk or that I will .


You fully hit the target.
There is a 'flag' for the loader signaling to load "from whatever disk is inserted".
And indeed this feature is used for the intro and start menu (including the tracker module).

Hi Ross, it is a modified Bytekiller packer if i remember well ?

[Don_Adan]

Originally Posted by dlfrsilver

Hi Ross, it is a modified Bytekiller packer if i remember well ?

You can scan first disk for "BTB6" tekst (BK decrunch routine, if i remember right). If this is ByteKiller, then this is very average packer. Most of no header packed files are packed with ByteKiller.

[ross]

No, it is not BK. And it seems even less efficient.

I put the source here, maybe someone recognizes it:

	movem.l	d1-d3/a2/a3,-(sp)
	move.l	(a0)+,d0
	andi.l	#$7FFFFF,d0
	lea	(a1,d0.l),a3
	lea	(a0),a2
	lea	($12,a0),a0
	move.l	(a0)+,d1
	moveq	#$20,d3
lbC00001A	cmpa.l	a3,a1
	blo.b	lbC000024
	movem.l	(sp)+,d1-d3/a2/a3
	rts

lbC000024	dbra	d3,lbC00002C
	move.l	(a0)+,d1
	moveq	#$1F,d3
lbC00002C	add.l	d1,d1
	bhs.b	lbC00008C
	dbra	d3,lbC000038
	move.l	(a0)+,d1
	moveq	#$1F,d3
lbC000038	add.l	d1,d1
	bhs.b	lbC000040
	move.b	(a2),(a1)+
	bra.b	lbC00001A

lbC000040	cmp.w	#4,d3
	blo.b	lbC000054
	subq.w	#4,d3
	rol.l	#4,d1
	moveq	#15,d2
	and.w	d1,d2
	move.b	(1,a2,d2.w),(a1)+
	bra.b	lbC00001A

lbC000054	moveq	#0,d2
	dbra	d3,lbC00005E
	move.l	(a0)+,d1
	moveq	#$1F,d3
lbC00005E	add.l	d1,d1
	addx.w	d2,d2
	dbra	d3,lbC00006A
	move.l	(a0)+,d1
	moveq	#$1F,d3
lbC00006A	add.l	d1,d1
	addx.w	d2,d2
	dbra	d3,lbC000076
	move.l	(a0)+,d1
	moveq	#$1F,d3
lbC000076	add.l	d1,d1
	addx.w	d2,d2
	dbra	d3,lbC000082
	move.l	(a0)+,d1
	moveq	#$1F,d3
lbC000082	add.l	d1,d1
	addx.w	d2,d2
	move.b	(1,a2,d2.w),(a1)+
	bra.b	lbC00001A

lbC00008C	cmp.w	#8,d3
	blo.b	lbC00009A
	subq.w	#8,d3
	rol.l	#8,d1
	move.b	d1,(a1)+
	bra.b	lbC00001A

lbC00009A	dbra	d3,lbC0000A2
	move.l	(a0)+,d1
	moveq	#$1F,d3
lbC0000A2	add.l	d1,d1
	addx.w	d2,d2
	dbra	d3,lbC0000AE
	move.l	(a0)+,d1
	moveq	#$1F,d3
lbC0000AE	add.l	d1,d1
	addx.w	d2,d2
	dbra	d3,lbC0000BA
	move.l	(a0)+,d1
	moveq	#$1F,d3
lbC0000BA	add.l	d1,d1
	addx.w	d2,d2
	dbra	d3,lbC0000C6
	move.l	(a0)+,d1
	moveq	#$1F,d3
lbC0000C6	add.l	d1,d1
	addx.w	d2,d2
	dbra	d3,lbC0000D2
	move.l	(a0)+,d1
	moveq	#$1F,d3
lbC0000D2	add.l	d1,d1
	addx.w	d2,d2
	dbra	d3,lbC0000DE
	move.l	(a0)+,d1
	moveq	#$1F,d3
lbC0000DE	add.l	d1,d1
	addx.w	d2,d2
	dbra	d3,lbC0000EA
	move.l	(a0)+,d1
	moveq	#$1F,d3
lbC0000EA	add.l	d1,d1
	addx.w	d2,d2
	dbra	d3,lbC0000F6
	move.l	(a0)+,d1
	moveq	#$1F,d3
lbC0000F6	add.l	d1,d1
	addx.w	d2,d2
	move.b	d2,(a1)+
	bra.w	lbC00001A

[BarryB]

Thanks for looking at this ross, may be a chance it's possible after all.

[paraj]

Originally Posted by ross

No, it is not BK. And it seems even less efficient.
I put the source here, maybe someone recognizes it:

Don't recognize it, but seems very basic. If I'm not mistaken it has a small dictionary of 17 bytes.
Input bit=0 -> copy 8 bits directly to output, otherwise read one more bit, 1=>copy first byte from dictionary, otherwise read 4 bits and copy byte from dictionary [1+bits].

[Don_Adan]

Originally Posted by ross

No, it is not BK. And it seems even less efficient.

I put the source here, maybe someone recognizes it:

	movem.l	d1-d3/a2/a3,-(sp)
	move.l	(a0)+,d0
	andi.l	#$7FFFFF,d0
	lea	(a1,d0.l),a3
	lea	(a0),a2
	lea	($12,a0),a0
	move.l	(a0)+,d1
	moveq	#$20,d3
lbC00001A	cmpa.l	a3,a1
	blo.b	lbC000024
	movem.l	(sp)+,d1-d3/a2/a3
	rts

lbC000024	dbra	d3,lbC00002C
	move.l	(a0)+,d1
	moveq	#$1F,d3
lbC00002C	add.l	d1,d1
	bhs.b	lbC00008C
	dbra	d3,lbC000038
	move.l	(a0)+,d1
	moveq	#$1F,d3
lbC000038	add.l	d1,d1
	bhs.b	lbC000040
	move.b	(a2),(a1)+
	bra.b	lbC00001A

lbC000040	cmp.w	#4,d3
	blo.b	lbC000054
	subq.w	#4,d3
	rol.l	#4,d1
	moveq	#15,d2
	and.w	d1,d2
	move.b	(1,a2,d2.w),(a1)+
	bra.b	lbC00001A

lbC000054	moveq	#0,d2
	dbra	d3,lbC00005E
	move.l	(a0)+,d1
	moveq	#$1F,d3
lbC00005E	add.l	d1,d1
	addx.w	d2,d2
	dbra	d3,lbC00006A
	move.l	(a0)+,d1
	moveq	#$1F,d3
lbC00006A	add.l	d1,d1
	addx.w	d2,d2
	dbra	d3,lbC000076
	move.l	(a0)+,d1
	moveq	#$1F,d3
lbC000076	add.l	d1,d1
	addx.w	d2,d2
	dbra	d3,lbC000082
	move.l	(a0)+,d1
	moveq	#$1F,d3
lbC000082	add.l	d1,d1
	addx.w	d2,d2
	move.b	(1,a2,d2.w),(a1)+
	bra.b	lbC00001A

lbC00008C	cmp.w	#8,d3
	blo.b	lbC00009A
	subq.w	#8,d3
	rol.l	#8,d1
	move.b	d1,(a1)+
	bra.b	lbC00001A

lbC00009A	dbra	d3,lbC0000A2
	move.l	(a0)+,d1
	moveq	#$1F,d3
lbC0000A2	add.l	d1,d1
	addx.w	d2,d2
	dbra	d3,lbC0000AE
	move.l	(a0)+,d1
	moveq	#$1F,d3
lbC0000AE	add.l	d1,d1
	addx.w	d2,d2
	dbra	d3,lbC0000BA
	move.l	(a0)+,d1
	moveq	#$1F,d3
lbC0000BA	add.l	d1,d1
	addx.w	d2,d2
	dbra	d3,lbC0000C6
	move.l	(a0)+,d1
	moveq	#$1F,d3
lbC0000C6	add.l	d1,d1
	addx.w	d2,d2
	dbra	d3,lbC0000D2
	move.l	(a0)+,d1
	moveq	#$1F,d3
lbC0000D2	add.l	d1,d1
	addx.w	d2,d2
	dbra	d3,lbC0000DE
	move.l	(a0)+,d1
	moveq	#$1F,d3
lbC0000DE	add.l	d1,d1
	addx.w	d2,d2
	dbra	d3,lbC0000EA
	move.l	(a0)+,d1
	moveq	#$1F,d3
lbC0000EA	add.l	d1,d1
	addx.w	d2,d2
	dbra	d3,lbC0000F6
	move.l	(a0)+,d1
	moveq	#$1F,d3
lbC0000F6	add.l	d1,d1
	addx.w	d2,d2
	move.b	d2,(a1)+
	bra.w	lbC00001A

If I want to find name of unknown for me packer, i try to find any hex ID from depacker inside xfdmaster.library and external xfd decrunchers. I used FileMaster for this job.

[ross]

Originally Posted by paraj

Don't recognize it, but seems very basic. If I'm not mistaken it has a small dictionary of 17 bytes.
Input bit=0 -> copy 8 bits directly to output, otherwise read one more bit, 1=>copy first byte from dictionary, otherwise read 4 bits and copy byte from dictionary [1+bits].

Yep, very simple static dictionary compression.
This stage is followed by an RLE depacker also simple (it use as token the less present byte in data).

The net effect is to compress relatively poorly and annoy real LZ(H) packers, hence the little effect of the further ZIP compression.
For some types of data it could also make sense (maybe..), the problem is that the decompressor is also slow and therefore not even that advantage.

Originally Posted by Don_Adan

If I want to find name of unknown for me packer, i try to find any hex ID from depacker inside xfdmaster.library and external xfd decrunchers. I used FileMaster for this job.

I haven't seen any explicita tag, excluding the first byte of the stream which is filtered for some reason...
But I assume you mean an 'un-wanted' id formed by the code.
It's not worth the time

[Don_Adan]

Originally Posted by ross

Yep, very simple static dictionary compression.
This stage is followed by an RLE depacker also simple (it use as token the less present byte in data).

The net effect is to compress relatively poorly and annoy real LZ(H) packers, hence the little effect of the further ZIP compression.
For some types of data it could also make sense (maybe..), the problem is that the decompressor is also slow and therefore not even that advantage.



I haven't seen any explicita tag, excluding the first byte of the stream which is filtered for some reason...
But I assume you mean an 'un-wanted' id formed by the code.
It's not worth the time

Yes, ID from code's decruncher. BTB for ByteKiller, BSB (if I remember right) by DefJam Cruncher, other ID ny RNC (without header or with fake header) or Atomic etc. When i was young i know most depackers ID.

[ross]

Originally Posted by Don_Adan

When i was young i know most depackers ID.

A saying from my country: "Da giovane saltavo i fossi per il lungo" -> "When I was young I jumped ditches from the long end".
(if not clear 'the long end' it is the direction where the water flows, not across..).

So we can't help it, our brain isn't what it used to be, too much time to do (simple) things, and moreover I always have the impression of not doing it well.

Now I'm sad, I'll soon be 53

[ross]

Originally Posted by BarryB

Thanks for looking at this ross, may be a chance it's possible after all.

I collected some data from the FAT of the game, to get a rough idea if at least one attempt could be made.

The total data on both disks amounts to 1425920 bytes.
Not all data is compressed (about 18k is not) and, being a sectors loader, not all sectors are full.
The total files are 55 of which 5 are shared between the two disks.
It's not a negligible value because if we have an average of 256 extras bytes per file, that's about 14K usable.
The data shared between the disks is approximately 282000 bytes, which must therefore be subtracted from the total (compressed) amount.

I did a test with a fairly large and generic file and with a good compressor you can gain at least 20% per file (unfortunately this is not a valid estimate for each file because those that contain audio usually compress much less, but there could be some which you compress more..).

This leads to: (1425920-282000)/1.20-9K-14K=~908K..
There's still 30k left to make up for somewhere (plus I've considered quite favorable conditions).

Sure, values a bit to be taken with a grain of salt, but they give an idea that it would be a really tough challenge, where to implement various tricks to be able to do it .

No, I don't do it, and in any case definitely not now

[dlfrsilver]

Originally Posted by ross

I collected some data from the FAT of the game, to get a rough idea if at least one attempt could be made.

The total data on both disks amounts to 1425920 bytes.
Not all data is compressed (about 18k is not) and, being a sectors loader, not all sectors are full.
The total files are 55 of which 5 are shared between the two disks.
It's not a negligible value because if we have an average of 256 extras bytes per file, that's about 14K usable.
The data shared between the disks is approximately 282000 bytes, which must therefore be subtracted from the total (compressed) amount.

I did a test with a fairly large and generic file and with a good compressor you can gain at least 20% per file (unfortunately this is not a valid estimate for each file because those that contain audio usually compress much less, but there could be some which you compress more..).

This leads to: (1425920-282000)/1.20-9K-14K=~908K..
There's still 30k left to make up for somewhere (plus I've considered quite favorable conditions).

Sure, values a bit to be taken with a grain of salt, but they give an idea that it would be a really tough challenge, where to implement various tricks to be able to do it .

No, I don't do it, and in any case definitely not now

Do you have the files extracted from the disks ? If yes, can you zone them please ? Thanks

[Don_Adan]

Originally Posted by ross

I collected some data from the FAT of the game, to get a rough idea if at least one attempt could be made.

The total data on both disks amounts to 1425920 bytes.
Not all data is compressed (about 18k is not) and, being a sectors loader, not all sectors are full.
The total files are 55 of which 5 are shared between the two disks.
It's not a negligible value because if we have an average of 256 extras bytes per file, that's about 14K usable.
The data shared between the disks is approximately 282000 bytes, which must therefore be subtracted from the total (compressed) amount.

I did a test with a fairly large and generic file and with a good compressor you can gain at least 20% per file (unfortunately this is not a valid estimate for each file because those that contain audio usually compress much less, but there could be some which you compress more..).

This leads to: (1425920-282000)/1.20-9K-14K=~908K..
There's still 30k left to make up for somewhere (plus I've considered quite favorable conditions).

Sure, values a bit to be taken with a grain of salt, but they give an idea that it would be a really tough challenge, where to implement various tricks to be able to do it .

No, I don't do it, and in any case definitely not now

Perhaps You are used ZX0 packer. Someone can try with arj7.
BTW. How big is main file for this game? If is big enough then packing with Pack Fire (LZMA) can be enough, i think. Similar method like for BC Kid.