MOON ADVENTURE

Want to talks about games you like, would like to see developed on the Oric, it's here.
User avatar
barnsey123
Flight Lieutenant
Posts: 379
Joined: Fri Mar 18, 2011 10:04 am
Location: Birmingham

Re: MOON ADVENTURE

Post by barnsey123 »

Example of non-linear playing of different video blocks. Each block can be played at will meaning a "Whoops" vid can be played whenever either side lets something slip in conversation. Or a "*** you" if the player selects an aggressive/uncompliant response.

Here, the blocks are being played back in a random order (well, still hardcoded but you get the idea)

Next is to produce some more vids, get them to display on the smartphone and add some rudimentary interaction with text selection.
CHAPTER1-VIDEOCALL.tap
Added Whoops and semi-random playback
(14.89 KiB) Downloaded 677 times
User avatar
Chema
Game master
Posts: 3013
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: MOON ADVENTURE

Post by Chema »

This is looking very promising indeed!

Congratulations!
User avatar
barnsey123
Flight Lieutenant
Posts: 379
Joined: Fri Mar 18, 2011 10:04 am
Location: Birmingham

Re: MOON ADVENTURE

Post by barnsey123 »

OK, what I really need now is a flexible unpacker routine. In the example below, the "looking right" sequence is represented by one file (seperated by Oric software into 6 frames of 72 pixels (12 bytes) by 48 lines.)
Looking Right
Looking Right
look-right.png (54.82 KiB) Viewed 21586 times
As an unpacked image everything is peachy and the following line generates the data for the oric:

%OSDK%\bin\pictconv -f0 -d1 -o4_LookRight VIDEO\look-right.png LookRight.s

I can use the above and all is cool. However, more sequences start to chew up the memory. I'm still well within limits (26K) but I could certainly do with some compression.

Now, I can pack this file doing the following:

%OSDK%\bin\pictconv -f0 -d1 -o2 VIDEO\look-right.png chunk.hir
%OSDK%\bin\FilePack -p chunk.hir chunk.pak
%OSDK%\bin\Bin2Txt -s1 -f2 chunk.pak LookRight.s _LookRight

When this is applied to all the sequences then that 26K gets reduced to 16K (clearly a very useful saving). OK so far.

The problem comes at the unpack stage. Using the file_unpack routine I used in the Hnefatfl loading screen I found it doesn't work. It spreads the image over the whole width of the screen and of course, it unpacks the WHOLE image. I must confess that the file_unpack routine is borrowed from somewhere else and I don't fully understand how it works...that makes it very difficult to amend.

So, what I'm looking for is a more flexible, indexed file_unpack routine that can be given parameters such as the following:

Start position of image. (e.g. $a002)
Number of bytes width (e.g 12)
Number of lines (e.g. 48)
An index (0,1,5 etc)

maybe the whole file would need to be uncompressed first (but not displayed) and then the other parameters are then used to display the required frame. Ideally, it would be nice to be able to uncompress PART of the file (should require less memory and be faster?) but that depends on wether the .s file is "evenly distributed" not sure if that is the case...

Usage: file_unpack((unsigned char*)0xa000,LabelPicture);

Code: Select all

void file_unpackc(unsigned char *buf_dest,unsigned char *buf_src)
{
	unsigned int 	size;
	unsigned char	value;
	unsigned char	maskvalue;
	unsigned char	andvalue;
	unsigned int	offset;
	unsigned int	nb;
	//buf_src+=4;	// Skipp LZ77 heqder
	size=8000;	//8000;
	//buf_src+=4;	// Skipp the size
	buf_src+=8;	// Skipp LZ77 header and Size
	andvalue=0;
	while (size)
	{
		//
		// Reload encoding type mask
		//
		if (!andvalue)
		{
			andvalue=1;
			value=*buf_src++;
			maskvalue=value;
		}
		if (maskvalue & andvalue)
		{ 
			//
			// Copy 1 unsigned char
			//
			value=*buf_src++;
			*buf_dest++=value;
			size--;
		}
		else
		{
			//
			// Copy with offset
			//
			// At this point, the source pointer points to a two byte
			// value that actually contains a 4 bits counter, and a 
			// 12 bit offset to point back into the depacked stream.
			// The counter is in the 4 high order bits.
			//
			// Original
			offset = buf_src[0];			// Read 16 bits non alligned datas...
			offset|=((unsigned int)(buf_src[1]&0x0F))<<8;
			offset+=1;
			
			nb	   =(buf_src[1]>>4)+3;

			buf_src+=2;

			size-=nb;
			while (nb)
			{
				value=*(buf_dest-offset);
				*buf_dest=value;
				buf_dest++;
				nb--;
			}
		}
		andvalue<<=1;
	}
	*(unsigned char*)(0xbfde)=18;
}
I'm not worried about the speed of this (I have to add in a pause between frames anyway) and I'm not desperate for it yet but it would be very, very useful. Any thoughts?
User avatar
iss
Wing Commander
Posts: 1637
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: MOON ADVENTURE

Post by iss »

Hi barnsey123, I'm reading your posts with big interest expecting to watch movies on Oric ;).
Now seriously, bellow is kind of way to save some bytes.
I took your attached picture and split it into 6 individual frames than using GIMP I made left, right and bottom bands equal in all frames:
frames.zip
(56.7 KiB) Downloaded 626 times
Than I used a python script which automatically generate for me images with reduced size (excluding equal parts).
Here are the results:
results.zip
(33.65 KiB) Downloaded 637 times
Now you can use the first original frame as background and overlay
only the different parts (in files result-02 .. result-06.png)
with X-offset=11 and Y-offset=0 relative to background position.
New size of overlay images is 49x41 pixels.
Here is the python script:
make-overlay.zip
(1.51 KiB) Downloaded 613 times
As you can see this is the original android script (slightly modified by me)
which generates the image sequence in the same way for any android device :).
When executed script reports offsets and overlay size.

Code: Select all

# python make-overlay.py `ls look-right-*.png`
reading look-right-1.png
reading look-right-2.png
reading look-right-3.png
reading look-right-4.png
reading look-right-5.png
reading look-right-6.png
saved result-01.png
saved result-02.png
saved result-03.png
saved result-04.png
saved result-05.png
saved result-06.png
saved result.png

  X offset: 11
  Y offset: 0
     new W: 49
     new H: 41
I hope this will help.
User avatar
barnsey123
Flight Lieutenant
Posts: 379
Joined: Fri Mar 18, 2011 10:04 am
Location: Birmingham

Re: MOON ADVENTURE

Post by barnsey123 »

@iss
Thanks, you've probably solved a separate problem that I had and I'm definitely going to make use of that technique. Imagine a space suit scene, I want to use the same spacesuit, overlaid on different backgrounds, with different faces shown through the visor (all chattering away at the same time)

For this smartwatch scene I want to have a bit more video though. It's not just the face that
changes. There's all sorts of other movements. See the tap below for an example. This includes more video but now with a better way of scripting it. I can play partial "chunks" to make full use of the chunks I have (a partial "right head turn" rather than the full deal can add some variety to the "yabber" chunk)

Ignore the bit where he checks his watch - it's terrible - a real rush job and I'm tired...BTW, this is not meant to represent the final video...just playing.

Lesson 1: When making videos that are supposed be contiguous...make em on the same day, in the same light, with the camera at the same angle...try not to be on a swivel chair...

This is 32K so deffo need some form of compression...
CHAPTER1-VIDEOCALL.tap
Added vids, MaxFrame and TERRIBLE CheckWatch chunk...sorry
(31.73 KiB) Downloaded 635 times
Example of the scripting:

Code: Select all

void PlayVideo(){
  MaxFrame=MAXFRAME; // this gets reset at end of PlayChunk so can be freely changed
  PlayChunk(Yabber);PlayChunk(Yabber);
  MaxFrame=4;PlayChunk(LookRight); 
  PlayChunk(Yabber);
  PlayChunk(CheckWatch);
  PlayChunk(Yabber);PlayChunk(Yabber);
  MaxFrame=4;PlayChunk(YouFuck);
  PlayChunk(Yabber);
  PlayChunk(Tears);
  //PlayChunk(LookRight);
  PlayChunk(LeanForward);
  PlayChunk(Yabber);PlayChunk(Yabber);
  PlayChunk(Whoops);
  MaxFrame=3;PlayChunk(LookRight);
  PlayChunk(Yabber);
  PlayChunk(NodYes);
  PlayChunk(Yabber);PlayChunk(Yabber);
  PlayChunk(Disdain);
  PlayChunk(Yabber);
  PlayChunk(CheckWatch);
  PlayChunk(YouFuck);
}
User avatar
Dbug
Site Admin
Posts: 4437
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: MOON ADVENTURE

Post by Dbug »

The FilePack unpack routine in 6502 assembler is already in the osdk, you don't have to use the C version.
Now yes, it will not work with a 'width offset' simply because that would make the code extremely complex: Just use a temporary unpack buffer and copy it to screen.
User avatar
barnsey123
Flight Lieutenant
Posts: 379
Joined: Fri Mar 18, 2011 10:04 am
Location: Birmingham

Re: MOON ADVENTURE

Post by barnsey123 »

Dbug wrote:The FilePack unpack routine in 6502 assembler is already in the osdk, you don't have to use the C version.
Now yes, it will not work with a 'width offset' simply because that would make the code extremely complex: Just use a temporary unpack buffer and copy it to screen.
I have a cunning plan...a whole range of video FX awaits... :D

Step 1: get the unpack routine working properly
Step 2: routine for flipping the video vertically (should be pretty simple...famous last words!)
Step 3: flip horizontal (XOR on last 6 bits) and read video buffer backwards on each row

So, in some circumstances (say a robot is rolling towards you) we only need a video of half a robot (as long as the background is symetrical - eg a coridoor - a walking thing can be achieved by flipping the frames in a different order). Should be a blast! :D
User avatar
Dbug
Site Admin
Posts: 4437
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: MOON ADVENTURE

Post by Dbug »

If you are serious about doing pseudo-video on the Oric, I think you should consider some alternative ideas:
- You could refresh only every second line, using some color changes to simulate the screen persistence like we did in the Assembly 2002 invitation intro: http://www.youtube.com/watch?v=EfegwPu_0xA. There are only two colors, green and red, the yellow is just made by your brain when pixels are close :)
- Using FilePack is not a good idea. Normally things like video or audio should be encoded with a lossy method, not a lossless one, using the previous frame as the base to create the new frame with a combination of commands like "copy this 8x8 pixels block of data from the previous image by two pixels to the right and one down" or "fill this 4x4 block of pixels with this color".
- I would suggest to not have dithering in the source video, and apply the dithering at run time when you display the picture, that would increase tremendously the ease of compression.
User avatar
barnsey123
Flight Lieutenant
Posts: 379
Joined: Fri Mar 18, 2011 10:04 am
Location: Birmingham

Re: MOON ADVENTURE

Post by barnsey123 »

Dbug wrote:If you are serious about doing pseudo-video on the Oric, I think you should consider some alternative ideas:
- You could refresh only every second line, using some color changes to simulate the screen persistence like we did in the Assembly 2002 invitation intro: http://www.youtube.com/watch?v=EfegwPu_0xA. There are only two colors, green and red, the yellow is just made by your brain when pixels are close :)
- Using FilePack is not a good idea. Normally things like video or audio should be encoded with a lossy method, not a lossless one, using the previous frame as the base to create the new frame with a combination of commands like "copy this 8x8 pixels block of data from the previous image by two pixels to the right and one down" or "fill this 4x4 block of pixels with this color".
- I would suggest to not have dithering in the source video, and apply the dithering at run time when you display the picture, that would increase tremendously the ease of compression.
Actually I've been thinking of a different approach. I'm going to write something on windows that will take all the images in a given folder (let's say a.png, b.png and so on) and runs pictconv so we end up with a.s, b.s, c.s etc.

Then we create a baseline array (initially populated with a.s...the file a.s will remain untouched) then we perform a byte by byte comparison with the next file (b.s). If a corresponding byte is identical the value 255 gets written to b-out.s else the different byte is written to b-out unchanged. B.s becomes the new baseline and is then compared with c.s. And the process repeats until no more files.

We then have a.s, b-out.s, c-out.s etc. these files are then compressed using filepack as normal. The compression efficiency should be much better as many of the bytes will be the same. Only the changed bytes will have a value < 255.

To display it back on the oric we unpack a.s to a buffer and display as normal. Then we unpack b-out.s outputting only the bytes that are < 255.

If Filepack is not more efficient with consecutive identical bytes then it'll be a waste of time but I'm guessing we will see much smaller files (and so longer, more detailed or larger sequences). No sound of course and only monochrome...but you can't have everything.

Hoping to do something tomorrow...
User avatar
barnsey123
Flight Lieutenant
Posts: 379
Joined: Fri Mar 18, 2011 10:04 am
Location: Birmingham

Re: MOON ADVENTURE

Post by barnsey123 »

yay...got the unpacking correct. I must admit I was struggling earlier and I nearly fired a distress flare. The unpacking adds a slight overhead as each chunk of 6 frames gets unpacked. It's noticeable but not a show stopper.

It might be an issue where each frame is one file (rather than 6 frames per file here) but I'm not worried at the moment. If the file sizes are small I doubt we'd notice anything.

The C version of file_unpack is way too slow...so am using the one from the osdk. I was using the ASM one in hnefatafl but I had the C function defined also....duh! So can save some memory over there.

Anyway, by having each Chunk packed the memory required gets reduced from 32K to 24K - a VERY useful saving of 8K! And that's WITHOUT the further savings I expect to gain from using MPEG-style playback (where only the bytes containing the changed pixels are recorded).

A development on the previous idea might mean that the "out" files (e.g. b-out.s) might be a list like this (awkwardly, the first value would have to be 16bit)

byte number,value
319, $10
320, $1F
1015,$22
2026,$0F
etc

On average this should mean MUCH smaller out files WITHOUT the overhead of unpacking (only the first frame/picture needs to be unpacked). The position on screen of the byte value would be calculated relative to the start address of the video and the number of bytes WIDE and bytes HIGH.
Of course, there could be times when the out file may be BIGGER (if many bytes have changed) so I'm going to suggest a change to the OSDK. We add a new command based on filepack but called VideoPack. This would create two files (a normal filepacked one and a bytepacked one), the bytepacked one would contain a header distinguishing it from a filepacked one so a different routine would be called for unpacking purposes. This way we don't have to choose which method is most efficient as VideoPack would do it for us (only the smallest file would be saved).

Is this the start of Oric-O-Vision? :D

It all still needs to be written but possibilities are opening up. Exciting stuff.
User avatar
barnsey123
Flight Lieutenant
Posts: 379
Joined: Fri Mar 18, 2011 10:04 am
Location: Birmingham

Re: MOON ADVENTURE

Post by barnsey123 »

Try these:

The next two "videos" have been extracted from animated GIF's. They are not very fast as they are running at quite high resolution (the Star Wars shuttle craft is the biggest at a resolution of 198 x 147). The Asteroid is 120x120.

To extract images (in order) from your selected GIF and perform RESIZING at the same time (saves lots of fiddling about) do this:

1. Install ImageMagick on your PC
2. Download an animated GIF (tons of them on the interweb)
3. From command line (navigate to directory where the gif is)

convert SHUTTLE.GIF -resize 198x147 SHUTTLE%02d.PNG

In this case I ended up with 30 files (SHUTTLE00.PNG...SHUTTLE29.PNG)

In OSDK for each file:
%OSDK%\bin\pictconv -f0 -d1 -o2 SHUTTLE00.png chunk.hir
%OSDK%\bin\FilePack -p chunk.hir chunk.pak
%OSDK%\bin\Bin2Txt -s1 -f2 chunk.pak SHUTTLE00.s _SHUTTLE00

Then incorporate the .s files in your progs.

As each FRAME is a separate image it gets unpacked each time. The larger the file, the slower the unpacking.
ASTEROID.tap
NASA flyby
(36.29 KiB) Downloaded 621 times
SHUTTLE.tap
STAR WARS Shuttle Craft 198x147
(30.86 KiB) Downloaded 605 times
Now, Imagemagick has a function to detect and display differences between images and this could be a cool way of generating images that contain only the changes. Got to do some work on that as it would save some coding. This would make the packing process more efficient (just need a different display routine after unpacking maybe ignoring values of 000000). This may not be faster to draw but should reduce memory footprint.
User avatar
barnsey123
Flight Lieutenant
Posts: 379
Joined: Fri Mar 18, 2011 10:04 am
Location: Birmingham

Re: MOON ADVENTURE

Post by barnsey123 »

ASTEROID2

Some GIFS use transparent frames which screw everything up so use the -coalesce function in imagemagick

e.g.
convert ASTEROID2.gif -resize 198x135 -coalesce ASTEROID2%02d.PNG
ASTEROID2.tap
nasa asteroid flyby 2
(32.51 KiB) Downloaded 687 times
User avatar
barnsey123
Flight Lieutenant
Posts: 379
Joined: Fri Mar 18, 2011 10:04 am
Location: Birmingham

Re: MOON ADVENTURE

Post by barnsey123 »

If you get Imagemagick to do the dithering (instead of pictconv) you get many more options, sometimes better quality and sometimes smaller images (especially after packing)

Code: Select all

SET IMAGEPATH=VIDEO\ASTEROID2\
:: For Main Program
:: Full Screen Asteroid2
DEL %IMAGEPATH%\*.PNG
::convert %IMAGEPATH%\ASTEROID2.gif -coalesce -resize 198x155 -ordered-dither h4x4a %IMAGEPATH%\ASTEROID2%%02d.PNG
convert %IMAGEPATH%\ASTEROID2.gif -coalesce -resize 198x155 -ordered-dither o2x2,6 %IMAGEPATH%\ASTEROID2%%02d.PNG
::convert %IMAGEPATH%\ASTEROID2.GIF -coalesce -resize 198x155 -ordered-dither o3x3,6 %IMAGEPATH%\ASTEROID2%%02d.PNG
::convert %IMAGEPATH%\ASTEROID2.GIF -coalesce -resize 198x155 -ordered-dither checks,6 %IMAGEPATH%\ASTEROID2%%02d.PNG
%OSDK%\bin\pictconv -f0 -d0 -o2 %IMAGEPATH%\ASTEROID200.png chunk.hir
%OSDK%\bin\FilePack -p chunk.hir chunk.pak
%OSDK%\bin\Bin2Txt -s1 -f2 chunk.pak ASTEROID200.s _ASTEROID200
... repeat last 3 OSDK lines for each image...
Shown above are some examples of using different types of dithering (note -d0 in pictconv to turn off dithering)

It's difficult to determine which is best. The craters on the asteroid are brought out more using o2x2,6 but it can look a bit washed out. 02x2 (without the ,6) shows detail elsewhere but the craters dont show up so much.

There is a great deal of difference between the sizes output (of the final TAP file) and a wide variety of "textures" (see below, these are just the ones I've tested that also look pretty good: h8x8a was bigger and looked worse..)

02x2 : 27783
03x3 : 29613
h4x4a : 31448
checks,6: 29301
03x3,6: 29518 : maybe best compromise?
02x2,6: 29184
Original NASA/JPL GIF file
Original NASA/JPL GIF file
ASTEROID2.gif (492.28 KiB) Viewed 21426 times
ASTEROID2.tap
using 02x2,6...compare with previous TAP
(28.51 KiB) Downloaded 601 times
To process all PNG's in a given directory (windows DOS cmd):

Code: Select all

CD "%IMAGEPATH%"
FOR %%a IN (*.PNG) DO (
%OSDK%\bin\pictconv -f0 -d0 -o2 %%a chunk.hir 
%OSDK%\bin\FilePack -p chunk.hir chunk.pak
%OSDK%\bin\Bin2Txt -s1 -f2 chunk.pak %MAINPATH%\%%~na.s _%%~na
)
User avatar
barnsey123
Flight Lieutenant
Posts: 379
Joined: Fri Mar 18, 2011 10:04 am
Location: Birmingham

Re: MOON ADVENTURE

Post by barnsey123 »

I've developed a really good technique for extracting the differences between images and only recording that changed data (so the packing is more efficient). The previous packed images for the Asteroid GIF resulted in a 28.5K tape file.

Code: Select all

@ECHO OFF
:: Full Screen Asteroid2
:: Enable variable changes within FOR loops
SETLOCAL EnableDelayedExpansion
SET MAINPATH=%OSDK%\LUNARCOM\
SET IMAGEPATH=VIDEO\ASTEROID2\
:: For Main Program
DEL %IMAGEPATH%\*.PNG
convert %IMAGEPATH%\ASTEROID2.gif -coalesce -resize 198x155 -ordered-dither o2x2,6 %IMAGEPATH%\ASTEROID2%%02d.PNG
:: Change directory to the IMAGEPATH
CD "%IMAGEPATH%"
:: set DUMMY file name (for when the 1st PNG is processed)
SET OLDFILE="DUMMY"
:: Read all PNG files in the IMAGEPATH dir (PNG's created from above IM convert cmd) 
FOR %%a IN (*.PNG) DO (
	:: The first file needs to  be processed differently
	IF !OLDFILE! == "DUMMY" (
		%OSDK%\bin\pictconv -f0 -d0 -o2 %%a chunk.hir
		%OSDK%\bin\FilePack -p chunk.hir chunk.pak
		%OSDK%\bin\Bin2Txt -s1 -f2 chunk.pak %MAINPATH%\%%~na.s _%%~na
	) ELSE (
		:: Create MASK of changes (the current %a file compared to OLDFILE)
		compare -metric AE -fuzz 20%% !OLDFILE! "%%a" -compose Src -highlight-color White -lowlight-color Black %%~na_Mask.png
		:: Use MASK to extract only the changed pixels from original image 
		convert %%a %%~na_Mask.png -alpha Off -compose CopyOpacity -composite %%~na_X.png
		:: Add Black Backround (remove the transparency)
		convert %%~na_X.png -background Black -flatten %%~na_X.png
		:: use OSDK to produce final, compressed .s files
		%OSDK%\bin\pictconv -f0 -d0 -o2 %%~na_X.png chunk.hir 
		%OSDK%\bin\FilePack -p chunk.hir chunk.pak
		%OSDK%\bin\Bin2Txt -s1 -f2 chunk.pak %MAINPATH%\%%~na.s _%%~na
	)
:: Set OLDFILE to be the current file (next file is compared with this one)
SET OLDFILE="%%a"
)

pause
What this bat file does is this:
Take the GIF file and extract all the images as resized, dithered PNG's.
File 1 is processed normally (no changes, we want the whole image)
File 2 is compared to File 1
File 3 is compared to File 2 and so on...
In each comparison we create a MASK file (of ALL the pixels that have changed)
So we have say: FILE2-Original.PNG and FILE2-Mask.PNG
We then use the MASK file on the original which yields ONLY the interesting data FILE-X.PNG.

FILE-X.PNG is turned into Oric data using the usual Pictconv, FilePack and Bin2Txt.

This means MUCH smaller .s files and hence much smaller program. Down to 21.4K!

For playback (within the Oric) we have to be a bit careful.

File 1 has to be displayed as is (the whole file)...that works OK.
File 2 and subsequent files only need to have the data that has changed to be printed. If we print the whole file it will overwrite the original data with BLACK. And this is where the fun starts and I am stuck...

Here's the business end (the code that prints each byte on screen)

Code: Select all

_BytePrint
.(
	; load next byte
	lda (tmp0),y
        ; compare with existing screen location (if same data then skip) 
	cmp (tmp1),y	
	beq skip
	; if new data is blank then old data must be retained (skip)
	cmp #64
	beq skip
	; else data is different so print it
	sta (tmp1),y
skip
	iny
	rts
.)
Original Frame
Frame 01 (original) from GIF
Frame 01 (original) from GIF
ASTEROID201.PNG (2.5 KiB) Viewed 21406 times
The Mask of FILE 01 ( when compared to FILE 00) - note the area of space VACATED by the asteroid
The mask (contains ALL pixels that have changed...including BLANK ones)
The mask (contains ALL pixels that have changed...including BLANK ones)
ASTEROID201_Mask.png (971 Bytes) Viewed 21406 times
The final differences between 01 and 00 (ONLY the "interesting" pixels that have changed)
Final file (only interesting pixels)
Final file (only interesting pixels)
ASTEROID201_X.png (1.01 KiB) Viewed 21406 times
Oh balls I've just answered my own question...

This can't work as it is working at a PIXEL level. On the oric we have to work in 6 pixel chunks so data is getting lost which is corrupting the playback...AAAAAAAAAAAARRRGGGHHH!!!!!! :evil:

So CLOSE I can taste it....I'd thought the ASM was wrong (it might be!) but that ain't the problem...
User avatar
barnsey123
Flight Lieutenant
Posts: 379
Joined: Fri Mar 18, 2011 10:04 am
Location: Birmingham

Re: MOON ADVENTURE

Post by barnsey123 »

Just for completeness...an example of corrupted playback
ASTEROID2.tap
oh noes...
(20.94 KiB) Downloaded 642 times
:(
Post Reply