Tips for Reverse Engineering a Cassette Program

Basic and Machine Language

Moderator: Moderators

User avatar
Noizer
Vic 20 Devotee
Posts: 297
Joined: Tue May 15, 2018 12:00 pm
Location: Europa

Re: Tips for Reverse Engineering a Cassette Program

Post by Noizer »

nbla000 wrote: Mon Mar 01, 2021 2:32 am Yes, it seems that works even if there is a "?LOAD ERROR" but maybe will be problems in a certain condition of the game or something else who knows.

Btw I've tried to create a prg file from both original/cleaned tape but each time it will produce a prg (from $1201 to $3FFF) with different CRC32, it works but I don't trust it.

By filling memory from 1201 to 3fff with an arbitrary value before to load the TAP, you see these value inside this range 1201/3ff and not always in the same place, for me a new dump is better.
I confirm. I would call it a bad dump. A look at the extracted waves shows innumerable glitches and streches in the waveforms. It's a miracle that it even loads. Maybe you could try editing it and converting it back to Tap. I remember nippur72 doing something like that in another case.
BR
Valid rule today as earlier: 1 Byte = 8 Bits
-._/classes instead of masses\_.-
User avatar
Noizer
Vic 20 Devotee
Posts: 297
Joined: Tue May 15, 2018 12:00 pm
Location: Europa

Re: Tips for Reverse Engineering a Cassette Program

Post by Noizer »

Noizer wrote: Sat Mar 06, 2021 2:30 am
nbla000 wrote: Mon Mar 01, 2021 2:32 am Yes, it seems that works even if there is a "?LOAD ERROR" but maybe will be problems in a certain condition of the game or something else who knows.

Btw I've tried to create a prg file from both original/cleaned tape but each time it will produce a prg (from $1201 to $3FFF) with different CRC32, it works but I don't trust it.

By filling memory from 1201 to 3fff with an arbitrary value before to load the TAP, you see these value inside this range 1201/3ff and not always in the same place, for me a new dump is better.
I confirm. I would call it a bad dump. A look at the extracted waves shows innumerable glitches and streches in the waveforms. It's a miracle that it even loads. Maybe you could try editing it and converting it back to Tap. I remember
nippur72 wrote:
doing something like that in another case.
BR
Valid rule today as earlier: 1 Byte = 8 Bits
-._/classes instead of masses\_.-
Vic20-Ian
Vic 20 Scientist
Posts: 1214
Joined: Sun Aug 24, 2008 1:58 pm

Re: Tips for Reverse Engineering a Cassette Program

Post by Vic20-Ian »

Fresh tap produced.
Boss.zip
(212.57 KiB) Downloaded 57 times
The first copy on the tape has a load error.

Fast forward to 70 on the tape counter and the second copy on the tape loads without errors.
Vic20-Ian

The best things in life are Vic-20

Upgrade all new gadgets and mobiles to 3583 Bytes Free today! Ready
User avatar
Mike
Herr VC
Posts: 4841
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Re: Tips for Reverse Engineering a Cassette Program

Post by Mike »

I have extracted 'header.prg' and 'main.prg' from your tape and added a loader program, 'boot.prg': (download).

Decompress the *.zip archive to a directory on a SD-Card for SD2IEC or transfer the three files with their full filenames (i.e. including the '.prg' file name extension) to a disk. Then, run the file 'boot.prg'.
kevgal
Vic 20 Newbie
Posts: 13
Joined: Mon Jun 28, 2021 5:31 am

Re: Tips for Reverse Engineering a Cassette Program

Post by kevgal »

Gday guys, here is the PRG version which requires 16k ram at blocks 1+2
Boss Chess.zip
And the Cart version (also requires 16K ram)-
Boss Chess Cart.zip
S1 to S9 set difficulty (s9 took over 2 hours to make a move!)

I think some of the issues with the tape version are due to part of the program residing in the cassette buffer.
User avatar
Mike
Herr VC
Posts: 4841
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Re: Tips for Reverse Engineering a Cassette Program

Post by Mike »

kevgal wrote:I think some of the issues with the tape version are due to part of the program residing in the cassette buffer.
In my post preceding yours I just happened to provide a version of BOSS 1.5 - transferred from Vic20-Ian's tape - that addressed this issue. ;)
User avatar
srowe
Vic 20 Scientist
Posts: 1340
Joined: Mon Jun 16, 2014 3:19 pm

Re: Tips for Reverse Engineering a Cassette Program

Post by srowe »

The code in the cassette buffer is only copy protection, it's not part of the actual program.
kevgal
Vic 20 Newbie
Posts: 13
Joined: Mon Jun 28, 2021 5:31 am

Re: Tips for Reverse Engineering a Cassette Program

Post by kevgal »

I was wondering if it was only for copy protection.
I actually used the header and the main prgs from Mike’s version to make the single PRG.
Thanks Mike.
User avatar
Mike
Herr VC
Posts: 4841
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Re: Tips for Reverse Engineering a Cassette Program

Post by Mike »

kevgal wrote:I actually used the header and the main prgs from Mike’s version to make the single PRG.
Your one-file rework came at the expense that the game now needs +16K RAM to load - the original and my 3-file version are content with +8K RAM expansion. You also got the load address wrong: BASIC programs or BASIC stubs load to $1201 with +8K RAM or more, not $1200.

Regarding the first point, it should be fairly easy to use Exomizer to produce a compressed single file version that successfully loads into +8K RAM and puts both tape buffer contents and main program into place. For my part, I considered the job done by providing a proved working rip from Vic20-Ian's tape. :mrgreen:
kevgal
Vic 20 Newbie
Posts: 13
Joined: Mon Jun 28, 2021 5:31 am

Re: Tips for Reverse Engineering a Cassette Program

Post by kevgal »

Yep should have left out the superfluous byte at 1200, my main aim was to create a cart version for my multi carts, it would be good to squeeze it into 8k.
I’ll have to checkout this exomiser app that you mentioned.
kevgal
Vic 20 Newbie
Posts: 13
Joined: Mon Jun 28, 2021 5:31 am

Re: Tips for Reverse Engineering a Cassette Program

Post by kevgal »

I've cheated a bit but here's a version that only needs 8k ram (still need 16k cart though unfortunately)
Boss Chess (8k).zip
User avatar
Mike
Herr VC
Posts: 4841
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Re: Tips for Reverse Engineering a Cassette Program

Post by Mike »

kevgal wrote:(still need 16k cart though unfortunately)
Your latest executable should actually work with just a +8K RAM expansion. Or did you mean 8K ROM (in BLK5) and 8K RAM (in BLK1)?
I've cheated a bit [...]
The idea is good (using the screen at $1100 as temporary place for the tape buffer contents and a small routine that copies those data into the tape buffer before control is handed over to the main program) - the execution isn't. If a user modifies the bottom half of the screen before RUN, your newest version again barfs. It now also *requires* to be loaded with ",8,1".

The Right Thing™ to do was preparing a memory dump from $1100..$3FFF, with aforementioned contents and let Exomizer work on that (with -n to suppress the blinking "@" in the bottom-right corner - you don't want that to modify the screen contents either).

After I already provided a guaranteed working version of the game I am somewhat annoyed about those 'improvements' you tried. People that happen to stumble across this thread are now probably unsure about what version to download now. I am not going to repair your non-working downloads. What I provided in this post works. Period.
Post Reply