From: dmb@pf.ai.mit.edu (David Baggett)
Newsgroups: comp.sys.atari.st.tech
Subject: Answer, with source code (was Re: Cyber Seq.  Info and Question)
Date: 29 Sep 92 22:04:20 GMT
Organization: MIT Artificial Intelligence Laboratory

In article <BvBtG9.958@cdsmn.mn.org> plate@cdsmn.mn.org (Doug Plate) writes:
>First the information:  The picture format document that I got from
>atari archive was inaccurate in it's description of the Cyber Sequence
>format.

Correct.  Thanks for pointing this out.  I looked at my Cyber loading
code and found the following:

        /*
         * Check magic to ensure that this is really a .SEQ file
         */
        if (sheader.magic != MAGIC1 && sheader.magic != MAGIC2) {
                diag(MYNAME, eCORRUPT);
                goto Bailout;
        }

        /*
         * Skip over frame offset information
         */
        len = sheader.cel_count * 4;
        if (Fseek(len, fd, 1) < 0) {
                diag(MYNAME, eREAD);
                goto Bailout;
        }

The fact that the offset data is useless may have been the reason I
forgot to mention it in the document.  Oops.  (For those of you who are
wondering why it's useless, consider that every frame depends on the
previous one, which depends on the previous one, etc.; so you have to
access the frames sequentially regardless of whether you have offsets.)

I'll post the corrected documented in the next message.

>Now the question: I am having a little trouble understanding how the image
>data is packed.  The runlength style encoding I understand, it's the splitting
>up of the bit planes that I'm having trouble with.  My confusion has to do
>with the terminology used to descibe the bit planes.  The document says
>the four bitplanes are split up and written vertically:
>
>	bitplane 0, word 0, scanline 0
>	bitplane 0, word 0, scanline 1
>	...
>	bitplane 0, word 0, scanline 199 (assuming 200 scanlines)
>	bitplane 0, word 1, scanline 0
>	etc.
>
>How are the bitplanes numbered?  What does it mean "word 0" , "word 1"?

ST low res screen ram is has four bitplanes.  Consider the first 16
pixels of scanline one (i.e., the 16 pixels that are in the upper
left corner of the screen).  Screen memory for these is laid out as
follows:

	bitplane 0, word 0
	bitplane 1, word 0
	bitplane 2, word 0
	bitplane 3, word 0

The next 16 pixels look like this:

	bitplane 0, word 1
	bitplane 1, word 1
	bitplane 2, word 1
	bitplane 3, word 1

etc.  There are 80 words per line total, yielding 20 words per bitplane.

What the description above is trying to say is this:  you get the data
a bitplane at a time (unlike the ST screen ram, which packs the
bitplanes together), and in vertical columns (again, unlike the ST,
which stores the screen RAM in horizontal rows).

The reason for the translation is that you get much better compression
when you separate the bitplanes and process them vertically.

>I understand that it takes bits from four words to make a pixel.  Assuming 
>these four words are numbered 0, 1, 2, 3,  isn't bitplane zero for the
>sixteen associated pixels all located in word zero?

Yes, but that's the format of ST screen RAM.  The format of the
uncompressed data is not the same.

I've included assembly source to convert the data from the format
above to the ST screen RAM format.  Use it in good health.

Dave Baggett
*-----------------------------------------------------------------------------*
;+
; Title:	Convert Vertical Separate Bitplane Data to Horizontal
;		Interleaved Bitplane Data.
; Author:	David Baggett
; Assembler:	Madmac v1.07
; History:	 3-May-1991	dmb	Created.
;		 4-May-1991	dmb	Made it work.
;		28-Aug-1991	dmb	Save A2 for Laser C.
;		 9-Sep-1991	dmb	Made it a GW function.
;		10-Sep-1991	dmb	No longer saving register D2.
;		27-Nov-1991	dmb	Save D2 for Lattic C.
;
; C Exports:
;	void vsb2hib(s, d, width, height)
;		int 	*s, *d;
;		int	width, height;
;-

		TEXT

_vsb2hib::	movem.l	D2-D3/A2-A5,-(SP)	; Save C registers

		; Equate stack offsets to C parameters
		.cargs	#28, .s.l, .d.l, .width.w, .height.w

		movea.l	.s(SP), A0		; Source address
		movea.l	.d(SP), A4		; Destination address
		move.w	.width(SP), D0		; Width
		move.w	.height(SP), D1		; Height

		moveq	#0, D2			; Clear out high word

		; Compute size of image in bytes
		; (h) * (((((w) - 1) >> 4) + 1) << 2)

		subq.w	#1, D0
		asr.w	#4, D0
		addq.w	#1, D0
		asl.w	#3, D0			; Convert to width in byes
		move.w	D0, D2			; Backup width in bytes
		mulu	D1, D0			; Size = width in bytes * height

		; Get starting source pointers

		asr.w	#2, D0			; D0 = image length / 4

						; A0 = start of bitplane 1

		movea.l	A0, A1			; A1 = start of bitplane 2
		adda.w	D0, A1
		movea.l	A1, A2			; A2 = start of bitplane 3
		adda.w	D0, A2
		movea.l	A2, A3			; A3 = start of bitplane 4
		adda.w	D0, A3

		move.w	.height(SP), D1		; Put height back in D1

		moveq	#0, D3			; Clear out high word
		move.w	D2, D3			; Get width in bytes
		asr.w	#3, D3			; get width in words / 4
		subq.w	#1, D3			; -1 for dbf

.column:
		movea.l	A4, A5			; Get top of this column
		addq.l	#8, A4			; Point to next 16 pixels
						; for next time through.

		moveq	#0, D0			; Clear D0
		move.w	D1, D0			; Height in D0 (loop var)
		subq.w	#1, D0			; -1 for dbf

.scanline:
		move.w	(A0)+, (A5)
		move.w	(A1)+, 2(A5)
		move.w	(A2)+, 4(A5)
		move.w	(A3)+, 6(A5)

		adda.w	D2, A5			; Add width in words (drop
						; down a scanline)

		dbf	D0, .scanline
		dbf	D3, .column

		movem.l	(SP)+, D2-D3/A2-A5		; Restore C registers
		rts

		END
*-----------------------------------------------------------------------------*
--
dmb@ai.mit.edu           MIT Artificial Intelligence Laboratory                  
ADVENTIONS: interactive fiction (text adventures) for the 90's!
dmb@ai.mit.edu *** Compu$erve: 76440,2671 *** GEnie: ADVENTIONS