C64

By Andrew Burch

While immersed in Syntax 2015 and beginning work on an intro for Hokuto Force (which went on to be released as “Technic” shortly after), I was approached by a familiar face. Unkle K sat down and we had a great chat about family, the C64, my intros and naturally, the Reset magazine. During the chat, he asked if I was interested in doing an intro for Reset64. Given Reset is an Australian magazine and I loved the work they put into it, how could I refuse? Time passes too quickly these days and it would be another 9 months before I’d start to form the basis of the intro. But once started, it came together quickly over the following weeks and I was pleased to be involved in the Reset #10 release with an intro and this write up to accompany it.

Rather than just put a bunch of things on screen, I like to focus on the design of my intros so the effects fit with the music and there is a smooth flow to the experience. Because I have so few SID contacts to help with the music, I begin most of my intros using sidplay2 and HVSC (High Voltage SID Collection) to look for existing tracks which I think I could design an intro around. Often I have an idea of how much memory I want to allocate to music, so this means I can focus on SID files of a certain size. I have a simple script that digs through the HVSC folders looking for SID files under (or between) a certain size and then copying them to a separate folder. I then create a play list from that folder in sidplay2 and explore for suitable tracks. This allows me to create a short list of music, which I will then listen to on repeat as I begin designing the flow of the intro. For this intro, I ended up settling on a track from ECO (Raik Picheta), which I had been wanting to create an intro around for quite a while. I’ve used a few of Raik’s tracks now and love what he creates.

My goal was to create the biggest (and hopefully best) Reset intro to date. I wanted the intro to be more than just a simple greets list, scroller and logo. This meant it had to have multiple parts instead of a single screen. The chosen music track suited a multi-part intro, so I was keen to flesh out something larger than the normal intro that accompanies each issue of Reset. Because this is a milestone release, the intro should celebrate the previous releases in some form and also acknowledge the Reset64 staff. A nice transition of some kind from the start screen to the intro is always a must for me and something I would incorporate into the intro. When designing the flow of the intro, I don’t necessarily know exactly how each part will appear on screen. Mainly, I focus on what each part will represent and build on that. With these few things in mind, and the music track selected, I came up with the flow to use:

• Transition from BASIC to intro
• Introduce Reset intro
• Reset team credits
• Show logo
• Intro credits
• Final part (continuous play)

With some design down for the intro, I now got cracking on writing the code. With every intro I’ve done, I always have multiple parts under development at the same time. I find it a good way to avoid getting stuck on a certain bit for too long and it also helps give an early idea on how well the implementation matches what I envisioned. Each part is developed within its own assembly file, which helps avoid working in large files. For some of the larger parts, I will even split them into smaller assembly files and code each sub effect first before bringing them together. For example, the final part which has a logo swing, cycling text, scroller and border sprites started life as four separate “effects” which were eventually brought together with their own transitions into a single assembly file, which then got merged into the final release file. I’ve found this method allows me to tweak and tune parts and their transitions easily before considering them complete and ready to move into the intro. It also makes it easier to sort out bugs before intro parts are merged together. An added bonus to this is it means I can quickly test each piece in both PAL and NTSC modes too. The final intro file will contain a small section at start up that detects NTSC mode (by peeking at the value in $02A6) and adjusts some variables & instructions to improve stability under that mode.

The assembly files won’t run themselves though and need to be compiled. My choice in compiler is win2c64 which was written by Aart Bik. There are more flexible cross assemblers around, but I found Aart’s to be very easy to use and haven’t had a reason to switch. For code writing I use Sublime Text 2 and a custom syntax colouring scheme I wrote (which I could not live without!). I make use of several common C64 cross development tools like Timanthes, CharPad, SpritePad, Sidplay2 and of course VICE.

Another tool I make use of is Beyond Compare 4, which is great not only for comparing source code changes, but also comparing images. I used this in the Reset intro where I had run the logo data through some conversion routines and wanted to make sure that the before and after output was the same. So before and after screen shots were taken from VICE and fed into Beyond Compare, which can then highlight pixels (bottom panel) where my conversion had faults.

A final piece of software I make frequent use of is Fraps. This tool allows me to capture the intro running in VICE to a video file for playback. This is extremely handy when graphical glitches occur on screen and you can then go back and watch them frame by frame to help diagnose the cause. This was used a few times on the Reset 10 intro where the transition code between parts had some conflict, which resulted in brief graphical glitch flashes and some cases where rasters were flickering. I often find the cause is usually raster interrupts fighting or a timing issue.

Along with the software mentioned, I also have a library of Lua scripts I have developed over the course of my C64 projects which are used to export and transform data into a state ready to be used in one of my assembly files. This includes things like data exporters for sprites, fonts, music, logos and scroller message formatting. There are some days where I spend more time tweaking and improving my tools than I do coding intro parts, simply because of the benefit they offer to the current and future projects. My choice in Lua is simply because, at the time I got back into C64 coding, I was working in the games industry on PS3 & X360 games and used Lua daily. So I found it quick and easy to get my early script library together. I’ve not yet had a reason to switch to something stronger.

I always like to see a transition in an intro from the start screen as I think it’s a nice presentation touch and starts the intro off nicely. For this intro I settled on fading each line of the screen to black (in a pattern), while leaving a nice bright RESET tag in the lower right corner. I use a colour table to ensure that the fade to black looks reasonable no matter what the colour ram, background and border colours are at the time the intro is run. It does however make an assumption the colour RAM is consistent across the screen. You’ll note that the border colour for each 8 pixel high character line also fades out with it, which requires raster interrupts all the way down the screen. It’s actually the same interrupt repeating all the way down, with each row containing its own indexes into the colour table. It’s a simple transition, but gets the intro off to a nice start and something I felt lacking in previous Reset intros.

With the transition done and the intro now starting, I wanted to include something that acted as an “intro to the release”. Reaching issue 10 is a nice milestone for Reset and something for Unkle K and the team to be proud of. I thought it might be good to look back at the previous releases, to see the important dates in their journey so far and then acknowledge their latest release date as part of that. There’s nothing too tricky in terms of code in this part, although originally the dates were not animated using the hardware scroll register. I added the animation to give the screen a little more life as each date fades in and out.

I wanted to dedicate a part of the intro to the team behind Reset who put it together for us to enjoy. It can be thought of as a shout out to the guys who “power” Reset64. This part went through a few design changes before the final was settled on. Originally it started a lot darker, with the scrolling text lit up using white and greys. The colour cycling was also intended to be more of a light source, circling around the text. The names were always going to glow in colour and it was hoped the darker background would put strong emphasis on the name. But the lack of colour felt dull and the “lighting” effect not as good as I imagined it would be. The light source was changed to cycling the colour RAM and brighter colours added. The scrolling “RESET64” text is achieved by rolling character data left and right, which is more efficient than using the hardware scroll and actually scrolling 12 lines of screen data. It leaves plenty of cycles free to scroll the colour ram instead. The top and bottom borders are also open, with sprites waving within. This is actually a really easy trick to perform, and requires you to switch the screen mode to 24 row mode just before the bottom border begins to render. This tricks the VIC into thinking the border is already being rendered, so it doesn’t bother starting it at raster line 250. You simply need to restore it to 25 rows somewhere in the next screen update (I usually do this as part of the frame set up in the top border).

The intro was really starting to come along at this point and I was in need of a logo. Unkle K put me in contact with Shine. This was excellent as I had been looking forward to working with him for a while. Because I wanted to swing the logo (along with bouncing it with Flexible Line Distance), I was keen for a 3 colour logo that could be converted to a character set. Keeping it at 3 colours means the colour RAM does not to be updated during the swing effect. This allows me to spend time doing other things on screen. However, this then places an annoying limit on any artist, but Shine did well to put together a logo (40×8 characters).

The logo arrived in the form of a bitmap, which I then wrote a conversion script for that converted it into unique character data and also a display matrix that could be used to render the characters to screen. This resulted in a set of 194 unique characters for the logo. Part of the conversion process was to also standardise the use of the character colour and the two multi colours. Because the logo started as a bitmap, the multi colours and character colours were not uniform across the logo. An inspection (and adjustment) of the bits for each character byte was done as part of the conversion to ensure the colours were standardised. Beyond Compare was very useful here to verify the output against the original and would highlight where bits had not been converted properly.

Although the logo would be bouncing and swinging across the screen, it wasn’t enough for me. I wanted to give the logo a little more life and decided to add some animation to it. Getting another colour on the logo might be good too, so I added sprites that flash across the letters and Shines tag. I also decided to animate the stars that appear in the top left and right of the logo.

Next I thought about how I could introduce the logo onto the screen. When it appears in the final part of the intro, the logo will swing across onto screen – so that one is easy. But I want to introduce the logo earlier, right after the Reset team credits have been shown. There is a perfect part of the music where this can happen and from the first time I heard the track, I had a mental picture of a logo vertically scrolling up. I settled on using a small “trick” of the VIC hardware, which stops rendering colour and simply renders black if you have both multi-colour and extended colour modes enabled at the same time. Putting this together with a Flexible Line Distance effect, I could make the logo begin to appear from half way down the screen. This was then finished off by rendering a line which the logo could appear from, bounce on and then disappear behind again. You’ll notice in the final intro that the word “MAGAZINE” appears in the bottom half of the screen in a wave pattern. These are sprites and are not affected by the multi-colour + extended colour “trick”.

This trick was used again for the intro credits part, but this time it also hides sprites by having their colour set to black. This way the role and credit can appear from the line in different directions. One is hidden by multi-colour + extended colour being enabled and the other is simply sprite colour changing at a certain raster line. To make the sprites appear, their y position is simply updated. The text appears by again using FLD (Flexible Line Distance) to push the character data down.

With all these parts getting to their completed state, I was able to begin creating the “final” assembly file. This is where all the parts get merged together for the final release of the intro, which means I now need to think seriously about memory layout. For this sort of intro, memory size isn’t an issue – I’m not going to run out. But I’m forever conscious about what memory I’m using and where it makes sense to compress or optimise things. The code will start at $0810 and I’ll have exomizer prefix it with an auto run block on the final build. I’ll be using memory around $0b00 to $0fff for sprite data and some table data. Music will live at $1000 and the logo character set at $2800. The main 1×1 font will live at $3000 and is made up of 64 characters. The larger 1×2 font will live at $3200, followed by animated characters used in various parts. I know I’ll need to allocate a little more space for sprites based on my estimates, so will set aside some memory here for those too. I want all graphics data sitting before $4000 so I don’t have to think about bank swapping. I built in some buffers to each of the key areas to allow for change right up to the last minute. In the end those buffers will either compress right down using Exomizer, or I’ll juggle some data tables around to fill them. The rest is free for code and data tables. With that decided I create a new assembly file with the above memory mapped out, ready to start merging parts together.

Merging everything and their transitions together can be tedious work. It can also be rewarding as you see the intro finally coming together in its final form, but it can be slow going as you realise the transitions you’ve created don’t gel well with the previous part, which then requires some juggling. Or new bugs get introduced, which can be “fun” to hunt down. I’m also more mindful at this stage of memory alignment with certain code blocks and where some bits best fit together. As I bring each piece together I test both PAL and NTSC modes. This way I can see early on where there is flicker (usually in NTSC mode) and do my best to get both running well so by the time the intro is completely together there are minimal changes required to have it run under either mode.

At this stage the intro was really flying along, but I still need to code up the final part. The final part will remain on the screen until the system is rebooted. This screen will contain a few different effects, all happening at once. It’s probably one of the trickiest parts to get complete as you not only need to get each effect running, but they have to run side by side with everything else going on screen and everything needs to transition in smoothly. I manage this with some raster interrupt juggling as each effect transitions on screen until finally it just loops forever.

When designing this part, I knew it had to have the logo and it would swing and bounce (using FLD and the hardware scroll register). This would take up the first 10 rows of screen display. When using FLD to bounce the top section of the screen, you need a second FLD effect further down to balance it out. As the top FLD increases in height, the lower FLD decreases. That way the lower section of the screen remains stable all through the bounce.

In the bottom section of the screen I wanted to put the scroller and settled on a 4×4 scroller. Instead of taking up more memory with a new 4×4 font, I wanted to dynamically create a 4×4 version of the 1×1 font already in use. Creating a scroller like this isn’t too difficult (I’ve created a tutorial on my site www.0xc64.com for those that are interested). It requires 16 characters, which make up every combination of 2×2 pixel data. Then using a bit mask and some shifting as each 2×2 bit block is processed, the scroller code creates an index into those characters to build the required 4×4 version.

That left the middle of the screen empty to do something with. I thought it might be nice to show off what features would be appearing in the release. Originally this was just a blue background with colour cycling over the text. It felt too dull and as always I wanted to put more on screen. I ended up with a parallax starfield, which was split in the middle of the screen. This had stars rolling left on one side and right on the other, keeping the flow of the colour cycling on the text. Because the new issue would contain many features, I rotate through new features every so often. With the old feature being hidden with blue colour. The update code detects this and then begins to render the next feature while the colour ram and background colours match. This way the next feature smoothly transitions on to screen.

As a final touch for this part, I opened the top and bottom borders again and added some sprites with a subtle wave to give them some life. Once all the pieces of the final part were brought together (with their transitions), it was added to the final release file.

Quite often as parts evolve, I have to juggle where updates and transitions occur, as adding more things to the screen takes up more raster time. I use a simple method of changing the border colour using an inc and dec on $d020 to see roughly how many scan lines certain update / render routines are taking up. In the screen shot below for example, the final part has several interrupts performing update and rendering for various things going on in the frame. The big gap at the top is reserved for the music, frame prep and top border sprite set up. As you see down the screen, the border changes colours at certain spots, showing the rough start and end raster lines for different routines. Often these will increase and decrease depending on what code is executed in the update. Where I have routines that execute on alternating frames, I can combine these into 1 block to try and get more effects into each screen.

At this point, the intro was ready. The scroller text and feature text are placed right at the end of the intro, which makes them easy to update. I always put these sorts of things at the end since they are variable in length and I don’t want to have to shuffle code or data around if their length exceeds what I had allowed for.

Working on the intro for Reset #10 was a great experience. It came out better than I had planned and certainly hope everyone can enjoy it. Congratulations to Reset for reaching 10 releases and let’s hope there are many more to come.
One part that you’ll never see in the intro is this one. Originally it was going to form the basis of the final continuous play part of the intro. A parallax star field, with a huge vertical logo on the right. It was intended the logo be made of multi-colour sprites, which could be moved around separate to the starfield. Text would be displayed on the right, acting as the scroller. It was ditched as I wanted to do far more on the screen and felt limited by the design. The white lines at the bottom is the raster time the star field animation is taking up.

Pre-order the latest issue of RESET C64 right now from Binary Zone!