Video for Beam Racer available

A video of my first Commodore 64 intro is available!

Of course I did not mean to make a technically extreme one on my first attempt. I just wanted to put together something that looks nice and is timed nicely: check at what point the scrolltext starts and at what point the drums start – then check on NTSC too ;)

Posted in Retrocomputing, Technical | Tagged , , | Leave a comment

All Rack-It loader variants supported in TAPClean now

Today, after rewriting the code for this format in order to extract loader parameters on a per tape basis (similarly to what happens for Cyberload), I also added support for the only known variant used in a few titles.

In total, there are 13 Commodore 64 tape dumps that can now be automatically tested and archived for preservation :)

Thanks go to Mason for making the tape dumps available and Peepo for setting up the FTP “exchange” server!

Posted in Retrocomputing, Technical | Tagged , , , , , , , , , | Leave a comment

Rack-It variants

Once again Mason has submitted a bundle of tape dumps, this time for his Rack-It/Hewson games. Interestingly enough these prove that loading parameters of the Rack-It loader (endianness, pilot byte, sync byte) were fully configurable at mastering time.

This is the second time in a few days that we have to correct our knowledge of a tape loader based on the inspection of tape dumps previously unavailable: It was 6 days ago that we made a similar discovery about Visiload!

I have identified the invariant bits that should make it possible to decrypt the code where loading parameters are stored and support all Rack-It/Hewson games at once in TAPClean :)

Posted in Retrocomputing, Technical | Tagged , , , , , , , | Leave a comment

Visiload variants

Mason has submitted tape dumps of a number of older tapes using variants of Visiload unsupported in TAPClean. These suggest the initial loading parameters were fully configurable at mastering time and in earlier tapes they were indeed configured in combinations that we had not seen so far.

All variants I was sent by Mason are now supported in TAPClean :)

Posted in Retrocomputing, Technical | Tagged , , , , , , , | Leave a comment

My first ever crack intro

My first ever crack intro, Beam Racer, has been published on CSDB: http://csdb.dk/release/?id=131448

Beam Racer

If you have a look, make sure you read the credits as these are all well deserved :)

Posted in Retrocomputing, Technical | Tagged , , , | Leave a comment

Burner – Early Mastertronic version

Have you ever tried to load one of those Mastertronic tape games that use an early version of Burner just to find yourself facing the following sort of puzzling screen output?

Early Mastertronic Burner load breaks unexpectedly by Luigi Di Fraia

Early Mastertronic Burner load breaks unexpectedly

Loading from the cassette interrupts due to a “BREAK” condition detected but you have neither willingly or unwillingly pressed the RUN/STOP key. So what is going on here?

Well, first thing is that if you hit RUN/STOP and RESTORE together, you can then issue a RUN command and keep loading the game. Example:

All is well - just hit RUN/STOP + RESTORE and issue RUN by Luigi Di Fraia

All is well – just hit RUN/STOP + RESTORE and issue RUN

Burner loading resumes from here by Luigi Di Fraia

Burner loading resumes from here

Back on the question: what is going on here? Some people might not even have this issue at all when loading the tape on their C64. In fact, I believe these early Burner tapes used to work on earlier C64s (1984 or thereabout). I won’t go deep into the details of this, but basically on later models of the C64, including emulators, the ISTOP vector (at $0328/$0329) seems to be erroneously set to $F6E0 rather than $F6EF or $F6EA: these are the values one would expect to find in order to disable the detection of RUN/STOP and RUN/STOP+RESTORE respectively. Disabling RUN/STOP+RESTORE prevents users from stopping and listing the BASIC program currently being executed (the one with the “hit a key to continue” message in the above screenshot): it is a sort of source code protection as the BASIC program is auto-executed and unstoppable.

$F6E0 is right in the middle of the CBM Kernal function that reads the real time clock. Such code happens to leave the flag register in a state that triggers a false positive detection of the STOP key press. That’s why the READY prompt is returned with a BREAK condition. The Kernal code that tests the STOP key is at $F6ED (which is what ISTOP points to normally).

The interesting thing about this is that the vector manipulation is made via an illegal/undocumented opcode (used along with other invalid opcodes by the coders in order to achieve code obfuscation):

*=$02A7
        NOOP $AE      
        LSR  $02BF    
        NOOP $CC,X     

        LDX  #$FF       
        ANE  #$51       
        SAX  $FB        
        NOOP $4C       
        ANE  #$E1       
        NOOP $CC,X     
        SAX  $0328      ; Set LSB of ISTOP (this results in $E0 in later C64s and emulators - meant to be $EA or $EF in older ones)

I believe the results of the execution of the obfuscated code above depend on the C64 in use.

Later versions of Burner do not use illegal/undocumented opcodes, but clearly set ISTOP as per below, possibly due to the fact its authors were reported about issues with later models of the C64:

 LDA #$EA 
 STA $0328

That is it from me :)

Posted in Retrocomputing, Technical | Tagged , , , , , | 1 Comment

TAPClean: Enigma Variations scanner improved

The load/end address gathering of all files in a non-multiload game is now available for the “Enigma” scanner in TAPClean.

With this new piece of functionality all data blocks in a non-multiload game (most games using this loader are single-load) can be verified for integrity. What this means in practice:

  • the broken last pulse of the last data byte can now be detected and repaired (manually as it requires content inspection and information reconstruction);
  • pulses that belong to the trailer are not being mixed with the data itself any longer (there are a few cases in which there is a trailer sequence even if most Enigma files haven’t got it): this is expected to produce an overall CRC-32 that does not match what we have documented previously. Hopefully this is only the case for a few tapes;
  • every raw dump of game using the Enigma loader should be checked with TAPClean 0.32-pre2 (in CVS) and cleaned: in case of non 100% recognition I am more than happy to assess the situation;

I am happy to manually test those titles that are not supported in TAPClean due to the fact they use multiload to load subsequent stages (e.g. “Rally Cross” and “Implosion”), if you care sending through your raw dumps.

Dig your dumps and do your bit now :)

Posted in Retrocomputing, Technical | Tagged , , , , , , , , | Leave a comment