magazine logo
Welcome to the official Attitude website - Europe's #1 C64 scene disk magazine
The Power Of Perl
by DJ Gruby/Oxyron

MAKING LIFE EASIER (FOR C64 PROGRAMMERS)

There are many ways to enhance your programming skills and to edit your source code more efficiently. There is a tidy number of demo coders who help themselves with doing some C programming first, and then using the results of their arithmetic as the base for their C64 effects. Turning to C might seem natural, as this is a low-level programming language (not that "low" as assembly, but still compared to the other high-level programming languages, it might be considered a low-level one), giving a programmer the full control over the methods he is adopting to achieve his goals. This belief might be misleading. Can it really be the fastest way to help yourself with developing C64 applications by writing helper tools using C? This article has been written to convince you (or to help you discover) that scripting languages, Perl in particular, might be a better alternative.

Limiting serious programming to assembly language is specific to all kind of 8-bit machines. You will never have enough memory nor CPU power to perform complex tasks. I am sure we all enjoy watching amazing demo effects with breathtaking rotating vectors, and beautiful zoom rotators. The best demo coders of these days put our 1 MHz clocked processor to its ultimate limits. Doing complex precalculations helps them to achieve this effect. This will never be a pure and genuine realtime routine if we want it to look perfectly. Even simple vectors require about dozen of multiplications. I believe I do not have to make a case for the need of having repetitious calculations already done and stored in a memory before our program starts.

In the past years I used to begin all my coding work with creating a subroutine named something like "generate tables", whose main purpose was to execute a set of miscellaneous calculations that would instead be performed too many times to make my products working fast enough not to annoy potential viewers. Computation results have been stored within tables in a memory, though a drawback to this approach was that the start was always delayed in order to have each calculation performed every time a program was run. Sometimes this is the only choice, especially when memory consumption is the case (like in 1k/4k compo entries). But most often you have a free space already reserved somewhere in memory to store your look-up tables. You can keep this data already there, being ready-to-use. You can generate this data in an extremely easy and convenient way. You have got Perl now!

Perl is a scripting language, whose main purpose is making text processing easier by providing a set of powerful tools built into the core of a language. "You say text processing?", you might ask. All right, that is agreed we hardly ever deal with purely textual data on the C64. We are actually always dealing with binary content, even when this is just the text of an article for a diskmag like "Attitude", which is stored in its own internally recognized format (but still this is much less binary data). I am going to show you that Perl deals with binaries as well as it does with text. I am not going to get into all technical details of Perl, neither I am going to teach you all of the Perl programming. This is something you have to investigate on your own. But don't worry! Perl is extremely easy to learn. If you have ever dealt with C plus you have the basic understanding of regular expressions, you are almost there - it feels like you already know most of what you need to learn about it. Grab a quick tutorial about Perl and believe me, you are going to become a master in a couple of next hours. Is it going to fit your needs? This is the question you have to answer yourself. Consider how much time you are going to save by writing a simple script that will do what you just need after executing it in a split second. Why not making your life easier and enjoy your C64 work even more?

So how would you actually make your life easier with Perl?

First of all writing Perl scripts is exceptionally fast. Accessing the data stored in files via an operator that will read the whole contents into a scalar variable at one step. Writing your code as a procedural programs or using purely object-oriented approach, that is your choice. Creating complex data structures reflecting complex data relationships and dependencies. These are just a few slogans, which do really work.

To give you a real life examples, I would like to share with you the ideas I have used while working on this issue of "Attitude" diskmag. They all helped me to put the whole mag together in an extremely short amount of time. They helped me to focus on the most important things: articles and communication. Those scripts are still on my PC's HDD ready for use and quick deployment for the 11th issue of "Attitude" when all type of contents like articles, soundtracks and graphics are finally collected.

At first I have written a script to extract the bitmap and the screen/colors data from multicolor and hires graphic files. This data has been then relocated and compressed using another script. Then I combined all those scripts into one and created a file with all source data required for diskmag engine to work that could be used when compiling the code with "Dreamass" assembler. Upon completion of graphic related tasks I created a script for converting SID tunes into PRG files, compressed them all using HCL's "ByteBoozer", and copied all to an empty D64 disk image. The same procedure works fine for all the articles, too. A working text converter has been coded to translate data from PC text files into internal "Attitude" proportional text displayer format (that means anyone writing an article for "Attitude" may and should deliver his chapter in a common PC text file!). Automation tasks had been finalized by writing an integration script compiling the main source code with the mag engine, putting all the stuff together, and copying all the files to a D64 file. All of these can now be done with just one single step!

Another script I have also written was a simple utility to display the detailed contents of a D64 disk image, including the following information for each entry: file type, its size, track, sector, and loading address. Since the IRQ loader I am using in "Attitude" is loading files based on their track/sector location, I was able to easily get the information about each file stored on a mag-disk. I could have done it as well by running "VICE" using the legendary "Dir Master", and to exchange the disk image, browse through the directory contents and to rewrite track/sector numbers by hand. If that is a one-time event, that would be fine. But developing a disk magazine is a constant process. There are some last minute articles delivered, or a new soundtrack arriving one day before a release date. You still do not want to disappoint people who put that huge effort to support you. While having a script like that, it is a matter of one second to rerun it and get the updated information incorporated automatically.

You might argue that plenty of tools like that have been already developed. Sure, but having it operating on a command line enables scope for integrating "work" of many scripts running otherwise separately. Imagine a single script that executes in a sequential order your other scripts to convert the SID tunes into PRG files, to extract bitmap data from pictures sent to you by a graphic artist, to compile assembly code using some cross-assembler tool, to convert PC texts to your internal editor format, to crunch all the articles, then puts everything together and copies over to a D64 disk image. In addition it makes you able to do that on both Linux and Windows, no matter which production environment you do prefer, because Perl is everywhere. I would just say: "Wow!" The effort you put into writing those few scripts compared to the time you save while performing all those tasks manually is simply invaluable.

TECHNICALLY SHORT NOTE

The only one technical topic I would like to cover before this article finds its ending is handling binary data in Perl, as this is something that is not necessarily obvious for most developers nowadays. Currently in the world of software development writing code to handle binary data is pretty uncommon, unless you are truly dealing with a low-level issues very close to the hardware related stuff. Here is the list of tips that will help you to understand the basics of binary data handling in Perl and to avoid problems you would otherwise have to face:

1. When reading the data from or writing the data to a file handle, make sure to indicate you are working with a binary data:

binmode FILEHANDLE, ":bytes";

This line of code tells the interpreter that you are working with a binary file and avoids special care of any new-line related characters.

2. When a binary data is read from a file handler, it is considered to be a binary. Unlike used from C you cannot force Perl to treat a byte with binary content as a number. Okay, you can, but you will get a very unpleasant warning. Perl is not a typed language, that means there are no types and each variable behavior is determined based on the context in which it is being used. Get the numeric representation of a requested byte first, after that you will be able to display it using a common function like "printf":

my $byteValue = ord $rawByte;

3. When having a hexadecimal number retrieved from a text string, you should explicitly convert it to a number, because numeric context will not be forced here correctly (Perl has no way of knowing that it is dealing with a hexadecimal numeric value unless you tell him):

my $hexValue = hex $hexNumber;

4. If you want to store binary data in a target file, you need to write just the same binary data to a file handler. If you try writing a numeric byte value, Perl will output a number. That means that instead of $bd single byte value you would get three ASCII numbers '1', '8', and '9' sent to a file handle, because Perl considers number to be a string in this context. To get a single byte representation of a particular value you need to get the actual character represented by that number, which then can be written as a single byte to a target file:

my $rawByte = chr $byteValue;

These four simple tips should be a good starting point for you to begin efficiently working with a binary data within your Perl scripts.

I hope that within this article I have given you a chance to find out a better way to organize your efforts while supporting the scene with new productions. It does not have to be that time consuming as we are always afraid of or used to be from the past. PC is not the evil. It may be and it surely is a great tool to help developing C64 programs, and there is nothing wrong with that, as one would have thought. Find your opportunities and use them!

Regards,
DJ Gruby/Oxyron.

   Add/view comments on this article (comments: 0)

SCENE GROUPS
 
OPINION POLL
Do you believe we are
able to cope with
releasing "Attitude"
on a regular basis?

yes no

 YES: 277 (70.84%)
NO:114 (29.16%) 

NEWS COMMENTS

ART COMMENTS

STATISTICS
all visits:

visits today:


website started:
23/09/2004
 
Official Webpage
of Attitude
Copyright 2004-2017
 
DJ Gruby/TRIAD