Here we are, back again with the first issue release of a new year, and while I can't promise one per month, that’s the goal I work toward (time limits permitting). I hope everyone reading this issue is well, and of course in good health and completely rested after the holiday season.
There is quite a lot to fit into this issue, with a Bomberman game and an interview with the game's creators. Now I know most of you will tut and groan at yet another Bomberman game, however this one has been released by RGCD (in various formats), and when I saw the demo, I knew that I had to go out and buy the cartridge version. It’s not just a mindless bomber copy; this game really is what bomber style games should be, and with multiplayer options, slick animations; and mind-blowing music, this could be a really tough release to beat for the year. (Although technically it was released last year) Heck, let’s not cut hairs. So it's either the best release of 2013 or it could be the best release of 2014, depending on how you prefer to look at things (Maybe it’s both. Heck, I have lost the plot now so let's move on. [or could I say GOTO the next section])!
Okay. It’s a weak link to what could be a regular series in Commodore Free written By Bert Novilla (satpro), we have issue $00 of our Assembly language programming tutorials, (Yep. We are so cool we even start the issue talking like we know what we’re doing) Of course we need to walk before we can run, so this first lesson, or 'primer' as they call it, is all about introductions and getting the right tools together. It's lighthearted and I am sure absolutely anyone will be able to follow it, even if you have never programmed before.
We have more Vic-20 news, as people have been contacting me with exciting new projects, and are really open to interviews and welcoming comments about their work, which is great. So we have 3 Vic reviews this issue. Now that’s a first for Commodore Free!
I am, however, conscious that the Commodore PET is now getting left out of the magazine, so If I am missing something, such as releases or news from this machine, please drop me a line so I can share the information with the readers.
That’s it for now as I have so much spell checking to do.
Yes, I do actually pretend to do spell checking sometimes.
Anyway, take care and best wishes.
Wow! I nearly forgot, if you love to read the magazine in splendid HTML5 format, maybe on one of those really expensive devices that starts with a lower-case 'i' or another Generic tablet, then I have a treat for you courtesy of Alessandro Di Nepi, who is busy converting issues of the magazine into a format which can then be viewed as one of those swanky HTML5 documents. Head over to http://issuu.com/commodorefree and make sure you sign up as a follower. A big thanks to all who signed up and have helped out Commodore Free.
Sender: Kurt Johns
To: commodorefree@commodorefree.com
Hey! Thank you very much for the mention in your magazine! As you probably know by now, the domain the games were on is no longer in service. I have a new domain (that I should have for at least a few years!!) and the games will be available here: www.rufnoiz.com/aj&kj.html . If you could mention this in a new issue I would really appreciate it. Although I am an old Vic enthusiast I am fairly new to the online Vic community, so I have only read the last 4 or 5 issues of you magazine. I really enjoy it and hope you can continue for a very long time. Thanks again.
Kurt Johns
COMMODORE FREE
Whoops looks like a domain change for these game on the Vic, Still the great thing is they got mentioned twice in two different issues, I think secretly you changed the domain after you saw them mentioned in Commodore Free and then thought 'Hey. If I email in and change the domain they will have to mention them again, so I get twice as much publicity.' Hey. Your plan worked!
Seriously, If you have a Vic take a look at the website for some great games to buy or download.
COMMODORE FREE
In Googling on the internet recently, I found Jim Butterfield introducing the Commodore 64 on YouTube, not unusual as hundreds of these Jim Butterfield and retro news items have been posted on YouTube. This one lasts over 2 hours and is interspersed with adverts if you look here http://www.youtube.com/watch?v=xmnlkLc1Foc you will see the video. I was quite intrigued about a piece of software he was using, you will see it at around 1Hour:55 in the video, after a few Google searches found nothing, I am wondering if anyone could either; shed some light on the software, send me a copy, or point me to a download; or website with further information the software. The item in question was released by HES and is called “COCO”, it seems to display the Commodore 64 registers graphically, where you can type in short programs and the results are displayed pictorially on screen. If anyone knows of something similar I would also be interested.
Once again, your favourite part of the Commodore Free; the 10th edition of the E-Cover Tape. This time we are happy to bring you yet more great, high-quality goodies. These include: a couple of Puzzle games, a little bit of Winter Olympics, a graphics designer, and an Etch-A-Sketch thingy. Also, we have a SEUCK game with a big difference. All of these will be burning the spools out from your tape deck. So press SHIFT / RUN STOP, press play on tape, and experience the wonders of those flashing stripes while enjoying this issue's E-Cover Tape. I'm pretty sure you will.
We haven't been able to feature any 6510+ assembler types in the listings this issue due to time constraints. We cannot promise you when the next instalment will come out. Sorry about that.
© 2013 The New Dimension
Programming | Richard Bayliss |
---|---|
Graphics | Richard Bayliss, Achim Volkers and Johan Janssen |
Music | Richard Bayliss |
Invert is a new game from The New Dimension, which also features a fully built level editor. Compatible with both disk and tape devices, the game was originally entered for the RGCD 16KB Cartridge Competition 2013, but never featured the editor, due to less memory being available on the cartridge.
You are a Blob that has been kidnapped by a flying monster and thrown into a cell in Puzzle Land. In an attempt to escape from the cell, you must complete all 32 puzzles inside. All black, inverted tiles in the play area must be INVERTED back to their normal state within the time limit. This may sound simple enough, but you are not alone. Monsters (Chatters) are out to stop you from completing the puzzle. They run around the perimeter of the outer rim of the cell. At times they will feel like throwing bombs. So you must not only restore all inverted tiles, but do so while defending yourself from the Chatters.
The tiles in the game vary on some levels. Read the up scroll for more information about these.
As mentioned before, this version of the game comes with a simple-to-use level editor. The scroll text already gives you the instructions on how to place a tile. The joystick can be used to move the flashing cursor around the grid. Pressing Fire will place a chosen brick into place. Pressing keys A-L will place a selected tile where the cursor lies. Please read the upscroll to find out which tile indicates the object in the game. Using + / - will go forward / backward a level screen. You have 32 screens to design in total.
(C)2006 Manic Mailman Productions
Programming | TFG |
---|---|
Graphics | TFG |
Music | Richard Bayliss |
Since the Winter Olympics are coming and to get you in the mood for this type of event. We are happy to bring to you “Super Ski”, a Downhill Ski simulator by TFG. This is a funny sports game, which I'm sure you'll enjoy. It even uses digi-sampling as well.
The game is for 1 to 8 players. You have a set a time to complete each downhill course. You must pass through the flags on each slope. Avoid skipping right past them. Otherwise you will receive a time penalty. Also, avoid crashing into various obstacles, such as logs, trees, rocks, etc. If you crash into any of these a total of 3 times, then you'll lose the game. Try to reach the finish in record time.
Full instructions are in the game itself.
© 2006 by Unreal
Programming | PCH / Unreal |
---|---|
Logo | TCH / Brutal |
Music | Alan Petrik |
This is a fantastic puzzle game inspired by the PC flash game, 'Gem-i-cide'. This, however, is a C64 game, built with a similar style, with some very nice graphics. The game has its own game play and hints as well.
The object of the game is to rotate balls of different colours to match three or more. If three or more match horizontally or vertically, they are be eliminated from the board. New sets of balls then appear on the screen. If you get stuck, just wait a while and a helpful hint will appear, allowing you to shunt more balls into place.
The level is complete when the progress bar has filled itself to the very top. After completing a level, a little animation interlude will take place, giving you bonus points.
The game is lost if it is impossible to get a match. There are plenty of levels which you must complete to be able to complete the game. Be warned – Marble Logic is very highly addictive with its gameplay. One go, and you'll want to play it all over again. :)
Please be aware that to load / save high scores. You are required to have device 8 set as your default disk drive.
(C)2013 Anthony Burns
Programming | Sensible Software, Jon Wells and Richard Bayliss |
---|---|
Graphics | Anthony Burns |
Music | Richard Bayliss |
This is a game which made second place in the 2013 SEUCK compo, and this version is the final, enhanced version of the game. Featuring new front end, in game enhancements, etc. The idea of the game is pretty simple. Citizens of Midgard are building a city full of good forces, but the evil forces just want to break it down again.
You must control a galleon, which must defend cities of Midgard. You are able to shoot cannon balls at the evil demons and invaders, but must watch out for the invasion of each City. A lost city will cost a life. If you lose all lives in the City and the Galleon survives, you will not win the game completely. Instead, you will fall at the last hurdle. Upon completing the game, You will gain a pass code which will need to be entered in part 2 to see the true ending. Good luck!
(C)1992 Binary Zone PD / Small Change Software
Programming | Hades/Small Change |
---|---|
Graphics | Hades/Small Change |
Music | N/A |
Storage | Disk only |
This is a handy utility in which allows you to build your own maps for your very own programmed games. It also consists of an example map to help you get started.
The basic concept of building your own maps consists of designing your very own character set. You design the character set by placing the characters into blocks to build the tiles. Then you place the 4x4 tiles to build a map. Actually getting the game maps in action will require additional programming. Anyway, here are the general editing controls:
Joystick Port 2 to control cursor. Fire to place pixels.
Joystick in port 2 to control cursor. Fire to place chosen characters.
Use joystick port 2 to place the blocks on to a map. Fire will place block in to map.
(C)1992 Style
Programming | The Wiz / Style |
---|---|
Graphics | Decomp, Elwix, PK, The Wiz, Alter Ego / Style |
Music | Deathlok/Style |
To end this issue's E-Cover tape, we have a memorable piece of classic C64 history. If you remember the classic toys back in the 1980's/1990's called “Etch-A-Sketch” then here's a fab demo from Style called “Etch-A-Style”. The demo will start with an automatic drawing. You can however have a play with the Etch-A-Sketch demo, simply by pressing the RUN/STOP key, and use the keys, L-Shift, A, Crsr Up and Crsr Left to draw your own sketches. Since this is a classic demo, not a utility – you are unable to save your pictures you draw. Anyway have fun with it.
Sadly no contributors releases hit this issue's cover tape. We mainly relied on the Public Domain sector. However we have tried our best to bring you a good E-Cover tape. Hopefully it is a good one for all of you.
We shall continue to bring you the E-Covertape, but if you want to contribute anything for the next E-Cover Tape (Issue 78 of Commodore Free), please send those programs over to either to richardbayliss.c64(a)gmail.com or to Nigel at nigelp2(a)yahoo.co.uk. (Note (a) is @ in email addresses). We will be happy to feature other formats as well as just the Commodore 64. So if you have anything that is for other Commodore computers i.e. VIC 20, C16 +4, etc. Which has not been commercially released or is your own work. Then please do mail those in to us. Maybe next issue, you'll be starring on the next E-Cover Tape :)
Raymond wrote:
...the Q-Link session from 1989 I recorded on VHS tape to http://blip.tv/file/4138357 But not if you go there they took that video down. I don't get why. So I uploaded it to you tube here:
http://www.youtube.com/watch?v=SHo3qjpDsm4
Robert Bernardo wrote:
Blip.tv took down all the Commodore, Amiga, and Star Trek videos that I gave to BIOS to be posted there, because those videos no longer meet their new "Terms of Service". By that, they mean no videos of meetings, presentations, etc.. They only want entertainment programs, preferably on-going series of entertainment programs.
Do not worry. Except for two videos that Blip.tv lost somewhere, all the other videos were archived and will eventually go back up at Biosjerbil's channel on Youtube.com With over a hundred to be posted, that may take some time. In the meantime, my Amiwest Show 2013 videos have been posted there lately (for Amiga computer fans).
Can’t find a case for your 1541 ultimate, http://www.1541ultimate.net/content/index.php? You could just download the files to print out your own, assuming you have access to a 3D printer, with the cost of 3D printing now within the grasps of the average user, I can seem more and more of this (print your own) for Commodore users, especially for these types of short-run cases .
Richard Janicek has a website with the VICE emulator available to play online. this emulator uses JavaScript and should work on most modern browsers. Future updates will add joystick and gamepad support, as well as being able to support other Commodore computers.
http://retroplay.co/c64/#{"vice":{"-soundsync":0,"-soundrate":22050,"-soundfragsize":2}}
C64 Studio is a machine language development environment that works with in conjunction with the VICE emulator. You can write machine language; and test the code in the VICE emulator. Recent changes: Added: Tile map editor, Ignoring warnings and modifiable constants. Improvements for PDS and DASM support, overlapping segments, breakpoints, and the find / replace function.
http://www.georg-rottensteiner.de/en/index.html
News from Goog
You may have heard elsewhere already, but I released a new online game and new version of Comet Chat.
This game is similar to Tron's Light Cycles...the game isn't super fancy in terms of graphics and sound, but offers a nice 2-player head-to-head game that you can play online, using CommodoreServer's gaming service.
https://www.commodoreserver.com/BlogEntryView.asp?EID=D4F2A40C607B4A06BF52F402FB409D16
This version of chat allows you to load different fonts from the Internet. At 38K speeds, it is incredibly quick. As the online disk grows with more fonts, your choices will be greater for displaying text. It also allows you to launch games directly from the chat app. This is nice, because as you're chatting, you'll not only see the games that people launch, but also be able to join them quickly.
https://www.commodoreserver.com/BlogEntryView.asp?EID=D92C94933211459F91BC83A7322414A7
Enjoy, Goog
Published on September 20, 2012
This Germany language clip; shows Frank and Jan Janssen two C64 experts with 25 classic C64 computers.
Janssen is currently working on his website http://www.c-64.org/de/index.html which will document the history , and different models of this legendary 8- bit computer.
Frank 's First Chief of Return magazine http://www.return-magazin.de the magazine for 8- bit computers
COMMODORE FREE: It all looks incredibly professionally-recorded and incredibly interesting, however, because I can’t speak German, I haven’t much of a clue as to what is going on here!
http://www.youtube.com/watch?v=5pymxsNdtKo
Released by: The Wizard
Download :
Phvic is working on a flash memory expansion for the Commodore VIC-20.
The following features are planned:
The device is still in development. You can follow the progress on Denial Forum.
http://gator3293.hostgator.com/~sleeping/ipw-web/bulletin/bb/viewtopic.php?f=11&t=6758
Just to prove nothing can ever be called impossible; and I have reported this before about Doom on the Vic. Kweepa has released a port of the shareware version of Doom for the Vic 20. The software needs a 35k Ram expansion and a disk drive to run. Although the screen size is small; and movement is jerky from slow screen refresh rates, you have to tip your hat to the guy, as this is an amazing achievement on the Vic. His Doom ports seem to be getting better and better.
Features 8 shareware levels, 4 enemies, 5 weapons, 11 music tracks, 20 sound effects, cheat codes, a map screen, corpses, secrets, pickups, exploding barrels, intermission and victory screens, and more! The Loading screen that looks incredible on the Vic is by Mike. Also of note is the doom music faithfully created by the Vic very good indeed!
The download is available from here
www.kweepa.com/step/vic20/doom.d64
You can follow its development on the denial forum here
http://gator3293.hostgator.com/~sleeping/ipw-web/bulletin/bb/viewtopic.php?f=10&t=4889
Programmer Beamrider (Adrian F) has released a version of Pooyan for the Vic 20 the Requirements are : VIC-20 + 16K + Joystick
The denial forum and discussion about the software is here also with a link to download the software
http://gator3293.hostgator.com/~sleeping/ipw-web/bulletin/bb/viewtopic.php?f=10&t=6780
Direct link to the software download
https://docs.google.com/file/d/0BypVxYomFCZfTHRCTVpNTnhyTVE/edit?pli=1
Denial message thread
http://gator3293.hostgator.com/~sleeping/ipw-web/bulletin/bb/viewtopic.php?f=2&t=6749
TUNNEL game in Basic for VIC=20 available as a free download with cartridge expansion 8K RAM.
Link to web site: http://gamecast.altervista.org/
Direct Link to the game : http://downloadgamecast.altervista.org/root/index.php
You have to be a registered user to be able to download the game, however in you look at the Denial thread you will see that someone has attached the file for easy download.
In the game you run around collecting bags, you have to work your way round the maze and out of the exit that is a swag-shaped bag with a T on it, later levels need the key collecting
Author | Misfit |
---|---|
Release Date | August 26th 2013 |
Requirements | Unexpanded VIC-20 + Disk Drive + Joystick |
Tested | VICE 2.2 and real VIC-20 (PAL) |
The game was created in 48 hours!
Download: D64 from here
http://www.riimukivi.net/data/fastboy/vic20_fastboy_ld27.zip
Description: Ludum Dare 48h game competition entry
http://www.ludumdare.com/compo/ludum-dare-27/?action=preview&uid=10677
Discuss: here
http://gator3293.hostgator.com/~sleeping/ipw-web/bulletin/bb/viewtopic.php?f=10&t=6755
Author | Misfit |
---|---|
Released | 30.11.2013 |
Requirements | Unexpanded VIC-20 + Joystick. |
Tested | VICE 2.4 and real VIC (PAL) |
Description: a simple Boulder Dash clone for vic.
Download : the game now as a D64 or T64 image
Discuss: here
The NST's Monitor Extension; is an extension of the internal Plus / 4 software. Features: More features to TEDMON. Use of "illegal codes." Scrolling the screen in two directions. Editing disk drive memory. Editing disk block. Clear memory and much more. On the web page of the NST's Monitor Extension you can read more about this system
Steve Gray is working on project to build various Editor ROMs for the Commodore PET/CBM computer The Editor ROM is responsible for all video initialization, screen output, keyboard input, screen editor, and IRQ handling. Putting all these features into one ROM, Commodore was able to customize the machines for various markets, not all models had all options! Later CBM machines had additional editing features and even a simple power-on menu for "Executives"
http://www.6502.org/users/sjgray/projects/editrom/index.html
News from CNET
Google's Portable Native Client technology gives a new Web-based lease on life for an old operating system and the games it could run. The Amiga 500 lives again -- in Google's browser. Google developer Christian Stefansen on Thursday resurrected a version of the venerable computer system from the 1980s in the form of a Web app that runs in Chrome. 40-year-olds who want to relive their childhoods or younger people who want to see just how hard their elders had it can visit the Amiga 500 emulator for Chrome online, boot the machine, and play some games.
Read more here
http://news.cnet.com/8301-1023_3-57615373-93/google-emulates-1980s-era-amiga-computer-in-chrome/
Elbox Computers is has announced a new product for Amiga computers: TurboFlyer 530.
TurboFlyer 530 is a new 68030-based accelerator with integrated FastATA CF/SATA controller for Amiga 500/500+ and A2000 computers. TurboFlyer 530 is an internal expansion and plugs into the 68000 processor socket.
TurboFlyer 530 will be on sale in February 2014 at the suggested retail price of 240 EUR (VAT excl.).
https://www.facebook.com/System3Games
System 3 Facebook,
Dear Amiga fans of Putty Squad
Further to our previous statement about Putty Squad for the Amiga, we’re pleased to bring you an update on where we are with the project.
We have provided the source code and mastering files to members of the Amiga community who are hard at work on them.
The objective is to produce an ADF file which will be available to download from our website this side of Christmas to allow the game to be played on the Amiga 1200 or on Amiga emulators. We intend to allow the game to be written to a floppy disk so that people who still have a traditional old Amiga with floppy disk will also be able to enjoy the game.
We are doing everything that we can to make this happen but, as you can appreciate, it is not entirely in our control how quickly this is achieved; However, please be assured that our objective is to give the game back to the Amiga community, for free, as soon as possible.
Sincerely
John Twiddy
System 3
You can download it here
http://www.winuae.net/files/WinUAE2700.zip
Homepage is here http://www.winuae.net/
How Sensible Software turned the horror of war into a 90s classic.
Jon Hare talks about the making of the game
http://www.eurogamer.net/articles/2013-12-04-never-been-so-much-fun-the-making-of-cannon-fodder
Programming, and Design | Michal Okowicki (Samar Productions) |
---|---|
Music, Player & Sound effects | Owen Crowley (Samar Productions/Onslaught) |
The cover art work was designed by Steve 'STE 86' Day, and the game comes complete with a 32-page printed manual, two code sheets, a vinyl Samar Productions sticker, and a double-sided poster that features an extensive monster info sheet on the reverse.
The game supports the Commodore 128 in 64 mode, but uses the c128`s extended hardware registers for acceleration. The game runs on NTSC hardware, but does however play fractionally faster; so is labelled as NTSC compatible, After loading, the machine type is displayed in the lower left corner of the main menu.
Stupid comment that sounded funny when I first though of it!
Bomberland not only can you get your fingers burnt, but you could get them blow off as well!
You could say; the game has taken Over 10 years in development on and off its more that the game has evolved, the game has existed in various guises. So from its first conection to the final release, that game was Created between the years of 2005-2013. Its roots however go back to 1995, when sceners Raspi, Gutted, Lobo and Skull (Michal) worked on a prototype named Boombastic Benny, however; this version of the game was never completed.
If we now roll forward to 2007; and a rebuilt version of the game called Bomberman C64 emerges. expanded and developed in an on and off way; until it became Bomberland. Conrad (Owen) was asked to write the music for the final game; and began work on this in early 2008, basing his sonics of the game on the 1991 Dynablaster game for the Amiga and PC ;with tracks by Eike Steffen (Romeo Knight). The music was finally completed in 2010, However! There were issues embedding the music files in the game, so Conrad wrote a customised music routine; and converted the original music data into a format readable by the routine. This saved a lot of graphical resources in the final 64k cartridge and also enabled his music work to be replayed in full with the limted cartridge resources available.
Now finally RGCD have released the game on cartridge, The game can be used with either the Protovision or Hitman adapters for up to 5 players action. The single player version supports a massive 36 screens of bombing action. With an end of level bosses and a number of different enemies. Dont forget to add the a mind blowing sid soundtrack as well as passwords; to work your way through more challenging levels, and the easy ones to if you find the game to challenging.
To load the Bomberland on cartridge, is a simple matter of; turning off your C64/128, then insert the cartridge and then; turning the computer back on. The game will load automatically, but does take a few seconds to decrunch.
For those of you unaware of the game; the basic idea is this;
You guide your lets say “hero”, (he doesn’t seem to have a name) through bomberland. In this wondrous land; you will have to fight against enemies that loyally protect your main objective; the Lord Bomber. You have a special skill; you have the powers to plant bombs to kill the enemies, these bombs will explode in 4 directions and; the bombs can also destroy some walls or bricks, hidden behind some of these walls; or bricks; are bonuses. Once all the bad guys are killed on the level; you will need to find the exit that will be hidden in one of the bricks, don’t however blow up the exit portal as bad things will happen, oh and don’t try to explode bonus`s as you will loose the bonus; and gain more attackers.
Not all the bonus`s are helpful; the skull bonus for example could hold a nasty surprise. In the last level; Lord Bomber will await you in his chamber. A password is provided in the game after 3 stages, the password not only holds the level you finished on, but also the powers and bonus`s you had as well as your score.
Each world is divided into six stages; with different themes: Brick Factory, The Swamps, The Rockies, Snowy Foothills, Laboratory and the dreaded Castle of Lord B. Each stage finishes with a boss to defeat.. The game is controlled by the joystick (in either port), but can also be played from the keyboard on your C64.
As Bomberland supports up to 5 players, in addition to the joysticks connected to ports 1 and 2, another two joysticks can be plugged via hardware connected to the User Port on your C64. The joystick algorithm is based on the use of a CGA (Protovision) adaptor, or can be switched to a HIT adaptor (by Excess and Hitmen). By default, the CGA adaptor driver will be used.
The game has many different types of monster, each with its own unique behaviour. Some are slow and quiet, others are aggressive and fast, some can even fly over walls. Remember though; you are up against the clock to finish the level; so don’t hang around, once the timer reaches zero; Time guards are released they home in on you from all sides of the screen. However on the final levels when the timer runs out; the TIME GUARDS will not appear you will instead die instantly.
It’s another tried and tested game play strategy; and many versions of the game exist, some are better than other protovisions bombmania comes to mind as being one of the better versions for the c64
After loading you can select options from the main screen, note in the bottom left I am using a PAL c64 and the program has picked this up.
After clicking start you are given
If you die on a level; you start the whole level again, all the monsters are back; and the timer is reset. Of course such strategies are best avoided!
Gameplay | 9.5/10 tried and tested bit in this case expertly coded
|
Overall
9.5/10
not quite perfection but incredibly close
|
---|---|---|
Sounds | 9/10 amazing SID tunes
|
|
Graphics | 9/10 great animations and carried colourful levels
|
Although it’s not a new concept, the extra features; and the fact this could be a 5 player game; add to what is already a very playable game anyway, the expert programming and mind blowing SID sounds; make this game unmissabe, factor in Superb animations, and attention to detail; to make this title shine out like a fine diamond in a area of black coal. I would say this is a must for every commodore 64 user. Try the demo then go out and buy the full version. Because this is a first “real” release from Samar productions, the future for this group looks incredibly rosy.
Review by Nigel Parker
A preview version of Bomberland in .d64 disk format can be downloaded from http://csdb.dk/release/?id=113464
You can also buy the game on cartridge or as a download from RGCD http://rgcd.bigcartel.com/artist/samar-productions
The cartridge version is available in two packaging types, a standard card carton and a more expensive 'deluxe version' that comes in a plastic case (a Universal Game Case with a specially cut foam insert to hold the cartridge as shown below). The standard version is priced at £25, whereas the deluxe version costs £30. Shipping is £4 for UK/Europe and £5 for the rest of the world. Bomberland is also available to buy as a downloadable .CRT image to use via emulation or on real hardware devices such as the Ultimate 1541-II. Purchases of both physical versions include this download for free.
Although the Bomberland game is reviewed later in this issue of commodore Free , (and you may be better reading that first; before the interview!) I thought that I would catch up with the game's creators, Skull and Conrad; to chat about how the program was developed. Also I was curious; if they had any other plans to release more titles, and what machines they thought they would develop for.
AC = Answers by Conrad (Owen)
AS = Answers by Skull
Q: Guys, can you introduce yourselves to our readers?
AC: Hi there. My real name is Owen Crowley, I'm 27 and live in Teesside, England. I work full-time as a Software Engineer for an Industrial Automation company. I also play drums as a musical hobby, showing that music is also part of my life as well as the scene, (although I'm not in a band yet :)). My parents had a C64 in the mid/late 80s; and I grew up with that machine, (as well as an Amiga). The Commodore 64 was one of the first machines I learned how to program BASIC on, followed of course by machine code. I also learned how to make SID music; with composer tools from the late 80s. In 2003, when I was 17, I had access to the internet; and there I discovered the "new era" of the demo-scene. Eventually I joined the C64 scene, (this was in January of 2007). Between 1998 and the present day; I have composed over 200 SID tunes, many of them for experimental purposes; but, a lot of serious ones too! In my time of the scene I have used two handles, "CRD" and "Conrad". "CRD" was short for "Crowley Designs", a brand name I primarily used for writing my own little computer games on the PC (in Blitz Basic, Dark Basic, C++ etc), I used CRD as a gaming handle also. "Conrad" was a name I thought up to replace my old handle, using the same letters... at the time no one else in the C64 scene was using it, so I thought why not? :). However, I put an end to this handle in January 2014, and now I just use my real first name as a handle, despite the fact there already is an "Owen" in the C64 scene (though he hasn't been active for many years).
AS: Hi, my name is Michael Okowicki, I was born in 1976; and I live in Poland. I work for a company producing construction materials, as a planner. My main hobbies are, of course, c64 and I have a wife and two kids. My adventure with a variety of microcomputers started in the late 80s, but the machine I owned was a second-hand Commodore 64 - with a defective CIA chip! Even this did not stop my love for the machine. I had a classic start; i.e. playing games and then learned BASIC. Later myself and a few guys created a five-member group called "Legion". However, apart from a few cracks, we didn’t really release anything. During this time we did however learn about the C64 scene; (although this was mainly in Poland), and assembly language programming. This group lasted until mid-1996 when we abandoned the C64, this was because we all started to study at university. I returned back to the scene in 2005, and entered the Samar group a year later. I am also an editor of the Polish magazine about Commodore computers called "C&A Fan".
Ah yes C&A Fan sorry didn’t realise you were the editor of this magazine for our readers; You can download issues from here http://dl.dropboxusercontent.com/u/33833039/index.html and read the issues on line via issue.com from here http://issuu.com/ramosc64/docs the magazine is in Polish.
Q: Now Lets jump straight in with a question on Bomberland... Although you could say it’s taken 10 years to develop, or I think a better word is evolve, with 2 bomber style clones being released, how long did this version actually take to code from concept to the final release?
AC: I think this is a question that Skull should answer primarily. :)
AS: Yes, I like the word "evolve", and the story of this project began much earlier, in fact way back in the 90's. As I mentioned before, in the nineties, when I was a member of Legion, there we had the idea of creating a clone game of Dynyblaster, which we liked playing in multiplayer mode on the Amiga and on the PC. We were able to create the preview; which was never officially released, but somehow it has leaked onto the web. This game was called "Boombastic Benny" and focused mainly on game-play in multiplayer mode, where single player was very modest.
Unfortunately; we started this project a little too late for the C64 scene. The idea was that we would release the game commercially, however; it was 1996, and that was really the end of an era of 8-bit machines even in Poland. Besides, we started to study; and were living far away from our family homes – so the C64 world was for a better phrase “deposited into oblivion”.
I came back to my hometown in 2004 and lived there with another group coder called Raspi. After a while, he began to torment me about finishing the game :). I was unemployed for a while, so I slowly started to refresh my knowledge on the C64.
Unfortunately, chaotic game archive sources in turboass; forced me to take the decision and to start creating the game all over again from scratch! Raspi had to leave the city; and I was left alone with the project. Since then, I entered the Commodore scene; and I began to try a cross-program and started using new tools. After about a year, the game gained a new shape. The graphics were moulded on the Dyna Blaster graphics, but I had a problem with the music for the game. I was ashamed to admit this; but I entered Samar mainly to look for someone who could write the music for the game :) - but not straight away, because I had to quickly start to code for a music collection for them (Catollica).
Luckily, it was also at the time that the young Owen (CRD) joined Samar; and therefore the mission of creating music for the game was given to him. He did it so fast; that the title Bomberman C64 was released for the competition organized at the beginning of 2007, the competition was called "Game Over (view) Freestyle Jam", where it gained second place, and meet with a warm welcome from players, which encouraged me to finish project.
I received an offer from the publisher; however I felt that the project still didn’t look quite right, especially as I had cut out the multiplayer mode. Years passed; and the project was developed sporadically. Its true I took long breaks on the projeect, often pushing it into the background; with respect to other matters (e.g the "Dream Travel" demo or "Jagged Sword" game preview). The project was still in the back of my mind. In 2010 Owen sent me a new great soundtrack for the game that was definitely closer to Bomberman, and this pushed me back into action. At the end of 2012, we had already coded something like the final design view – and a preview was released. There was still a lot of interest from publishers, However we both decided to give it a commercial release on cartridge – mainly because it is a very durable medium.
It's hard to determine how long the game actually took to code! but it certainly wasn’t 10 years. :) Before the release of the Bomberland Preview, we again refreshed the whole code. A lot of refinements meant the game now wouldn't fit on the ROM cartridge. I think there aren’t many games that use the rom card the way we did, such as depacking data all the time. Most of them work by transferring the packed game at the beginning and unpack it into the computer RAM and that’s all. In our case, transferring data and depacking was done 'on the fly' happening many times within the game, turning the ROM cartridge into extended memory. Through this project I learned a great deal about programming, and has really improved my skills. Work on the game also provided me with many challenges and I learned to overcome them, giving me a great deal of pleasure and satisfaction.
Q: Why did you think we needed another bomber clone, and what are your thoughts on Protovision's "Bombmania"?
AC: Bombmania by Protovision has proven to be a very successful party game, especially with their very own joystick adaptor that they developed specifically for these kind of games. However; in my humble opinion, it isn't a true conversion of the original arcade Bomberman by Hudson Soft. In terms of graphics, music and playability. Despite the differences in storyline and extra features, we wanted to release a conversion that played, displayed and sounded like the arcade version, as well as other clones; like Dynablaster (Amiga/PC).
AS: As Conrad said really, Bombmania as well as existing clones on the C64; are far from what we offer in this version and what Dynablaster/Bomberman on other platforms offer. The main difference is the way you control the player. In Bombmania, the movement is more like Boulder Dash. That is discreet, so after determining the direction by joystick, for a while we passively watched as the hero moves unconditionally to the next field. Yes, some love Boluder Dash and probably a control model also fits them. For me, BolderDash works, but in bomberman games this gives you a lot of limitations.
So I tried to create a player control that was closer to DynaBlaster, with movements in any time-dependent motion of your hand. For convenience, there is also the added possibility of sliding on the corners of obstacles - thereby giving you the ability to move even more quickly. I needed to add that and this is one of the elements in Bomberland, which I'm really proud of. A graphic character is just a matter of taste. :)
Q: You use the top border for the scoring and level information. Did you think about opening out the borders completely for the game; thus giving you more game area?
AC: In terms of vertical borders, it is technically impossible to display high resolution graphics within 40 columns "outside" the main screen. First of all, this would require sprites... without any professional coding tricks, you can only display 8 sprites in one row. Each unexpanded sprite uses up 24x21 pixels, which gives us the total of 192 horizontal pixels for 8 sprites. This is not enough to cover high-resolution/multicolour graphics for the whole border. Expanded; all 8 sprites (i.e. doubling the horizontal scale) can cover all 320 pixels, but this means that 2-colour graphics per 2 pixels can only be achieved for the most high-resolution display. In the late 80s however, a well-respected coder named Crossbow achieved a text screen with 3 rows of 40 hi-res characters in both the top and bottom borders. He did this using, what I like to call, the "$3FFF trick"; he cleverly drew characters in the sprite data. But this would not be suitable for a game such as Bomberland. In my opinion; vertically opening the borders are perfect for informal graphics; such as scoreboards or scrollers, which has worked well in many games and demos from the past 25 years. Skull, of course; has found nice ways of making the scoreboards beautiful in terms of multicoloured hi-res graphics and sprite overlaying in the right positions. :)
AS: I am not going to talking about the technical details of the C64 like Conrad has, but I would like to add that this actually is not possible while trying to maintain the quality of a game. Also as Conrad said; there is the problem of the number of sprites on a single horizontal line, this can only be only 8. Despite many tricks, no method of obtaining a larger number of sprites is possible to use sensibly. But the main problem is, opening the side borders would take time away from the processor. Doing this for the entire length of the screen (like the FLI, NUFLI etc.) would completely impact on game performance - 2/3 of the CPU time would be "wasted" (in ntsc even more). In our game the side borders are open at the screen introduction/history part, and displays of a new password. The effect of the border scroll is shown in the main menu.
Q: On some of the levels the playfield actually scrolls around with the player (in single player mode for example). What prompted this and why didn’t you just stay with a static playfield?
AC: Official Bomberland/Dynablaster clones published by Hudson featured scrolling levels, so we wanted to achieve this for our version of the game as well. The magic of VSP (Variable Screen Positioning), discovered by JCB/MeanTeam in 1987, helped us achieve this. :)
AS: Conrad is right, but I would also like to add that on the C64, there just aren't enough games that use smooth scrolling on a full "normal" screen 40x25 (320x200 px), mainly because it takes a lot of CPU time and usually some part of the screen. A few lines at the top or bottom are allocated to information about scores, lives etc. Lets take SEUCK games as an example... they use the entire volume of the screen, but are often slow (mainly through the use of multiplexer sprites) as there is a lot more action on the screen. In Bomberland, the horizontial scroll was quite simple to obtain (it’s a VSP effect - unfortunately, not every c64 handles this correctly), the vertical scrolling really affects the machines performance. There is just a small part of the code responsible for doing the smooth scrolling and without shakes or judders, even under NTSC.
Q: How important was the multiplayer option and, although you stopped at 5 players, could theoretically more be added? (assuming the crush for the keyboard could be worked out)
AC: We want a game where more than one person can enjoy at the same time, We wanted to achieve a game that challenges a group of players rather than one player. As for more than 5 players, that really is dependent on the timeline of when active hardware engineers in the scene release new and exciting things which, coincidentally, happened around the same time we released Bomberland. In July of 2013, two Czech sceners (Ray/Unreal & PCH/Unreal) developed a multi-joy adapter running via a HCS08 CPU, which enables you to connect 8 joysticks at once. So who knows? Maybe Skull could adapt this new feature in an expanded version of Bomberland or a completely new project.
AS: Five players do a lot of mayhem, but the fact is that getting 8 players in the code does not constitute any major modifications. A small problem with the display would be the fifth player, which requires additional IRQ requests that are also calculated every time. The game mobs are dual-layer and five players would need ten sprites. While in the case of monster mobs, it can anticipate the movement and control - the code will not allow more than 3 in a row (plus a player gives it 8 sprites in line), in the case of multiplayer it could happen. However this problem disappears if we decide to use single layer sprites (but would reduce pixel resolution ), then we have 8 sprites for each of the 8 players. A set of keys to operate the 5th player is also not accidental. The matrix keyboard uses the same registers as joysticks - this leads to a conflict when reading. Currently selected keys are only sensible if they don’t conflict with the joysticks. Therefore, the next players will not be able to use the keyboard.
Q: You mentioned about how you met, so how did you both end up working together on this project?
AC: Well I first met Skull face to face at Silesia 4 demoparty in Poland, in September of 2010. It was also the first time we actually spoke to each other too, despite the fact that we had both been in Samar Productions approximately 4 years beforehand, at the time when we both released Bomerlands's predecessor, Bomberman C64 (that was through the help of Ramos/Samar, who provided my music to Skull directly). In the beginning, communication was rusty... I don't speak Polish (although I am learning a bit ;)), and Skull was still getting to grips of speaking English flawlessly. Nevertheless, we have got on well over the years; and I believe we're a great development team, despite the fact that we're from two different countries. :) Although I knew that Skull was the coder of it all, I actually first heard of the Bomberland project from a German scener named "doZe", who is also a member of Samar. It was he that asked me to write music for the game, this was about six years before the official release. I haven't heard from doZe for a long time though, so that made me assume that the project was put on hold. But when I met Skull at Silesia 4, he showed me the current work he had done on the project on his C64 setup at the party. I was so blown away with the work he did, that it convinced me enough to ditch my old work; and make some new, top-quality music for the final game.
AS: Yes mainly what Conrad said, and yes the biggest obstacle for us was the language barrier
Q: Do you have plans for any further releases, and do you think you would port the game onto other Commodore hardware?
AC: We're actually thinking of producing an extended disk-version of Bomberland game sometime this year; but we are not sure exactly set on an official release date yet. As for other Commodore hardware... Bomberland is also playable on a C64GS and (as you know already) and on the C128 but, in regard of other Commodore computers such as the Plus4, C16 or Vic20, we haven't planned to develop such ports.
AS: For me personally I just wanted to code a good bomberman clone game on sixtyfour, and I think I have achived this with Conrads help! is already finished that was my intention and we are both happy with the end result”. I do think about completely different games, and in my dreams, I have still a lot of them :) I do not think I'll find time to port Bomberland to other of a platforms though.
Q: the game is listed as Samar Productions, we have already spoke about the group but can you tell our readers; who makes up this team of coders, you said the group was primarily a Demo coding group; and this is your first real game release
AC: Samar Productions is a Poland-based demo group, it was founded in September 1993 by Ramos. It is, indeed, a group who primarily release demos, as well as music-collections. Although the majority of the members are Polish, there are/were many foreigners in the group too. I believe I am the first English/UK scener to join this group, and this was in January 2007. Some of the greatest demos they have released include:
Extacy (1996), Opium (1997), Digital World (1998), Air Power (1999), I Love the Cube (2011-12), Dream Travel (2011-12), and most recently a co-op demo with Arise (a well-respected Polish demo group) called "Fogyish" (2013).
Samar have released some other games in its timeline! however ;these were very small games released to the public domain. Bomberland, however, is officially the first published game developed by Samar.
From what I've read in forums and other places, there's been rumours for many years that; some people in the Polish scene consider Samar as a lamer group, mainly because of the leader (Ramos). Whether those rumours are true or just a joke, I'm personally not bothered about it... I like being in this group; and there's a lot of friendly members/ex-members that I've met. :)
AS: Haha! You tell them Conrad! Samar is a large group with a lot of Polish sceners; however parting was not always friendly, and yes some people accused us of being 'lamers'. There are really a lot of talented people in the group. Yes, Bomberland is the first game released commercially on c64 from the Polish group (and it comes after more than thirty years since the creation of C64 ;-)).
Q: It has to be said that the quality of the title is very high. Did you intend to make a playable game? Or were you setting out to make the best title possible to WOW the scene, and show people what the group was capable of?
AC: Both really. :) as Skull said; This title has gone through many revisions and phases, I think Skull and myself wanted to make a great impact in the C64 scene; and the gaming community. I believe we achieved that with this title! :)
AS: Exactly!
Q: I read and you have already mentioned that the music routine caused problems, and that Conrad rewrote a special player for his music. What were the issues with the music?
AC: This was basically an issue of memory space on a 64K memory chip. When I finished and compiled all the tunes in late 2010, the resulting memory size was well over $2000 (8192) bytes. But during the development, I was informed by Skull that the maximum memory space for static music data is $2000 bytes. This was a problem for me personally because, in order to reduce the compiled music to less than $2000 bytes, I would have to reduce the quality of musical patterns that I originally composed; (so for example, miss out some drums here, remove an appreggio there, get rid of this instrument here, and so on). I did carefully optimise the entire music data as much as I could for the official music player that it was compiled for, but it still didn't get down to $2000 bytes. So I got on my thinking cap and tried a different approach... I decided to extract all of the pattern/track data, convert it, and transfer it into a brand new music routine that I had coded by myself. The trick was to copy a selected set of pattern/track data to the correct location addresses, so that the music routine "believes" it is playing a brand new song from the beginning. The advantage of this is that currently unused musical pattern/track data can be crunched and stored away on the cartridge memory, and the musical pattern/track data to be currently played can be stored well within the maximum memory range advised by Skull. Of course, it was a long-winded and difficult process, but it was challenging; and helped me understand better on how music routines work. :) If you want to read more technical write up about this, have a read on the Bomberland article in Vandalism News #60 by Onslaught. Available from here http://www.atlantis-prophecy.org/onslaught/mags/vandalismnews10.zip
AS: Conrad completely surprised me, because he created the whole service system sound - including support for SFX!
Q: You mention the game supports enhancements on the Commodore 128. Can you describe what these are?
AC: Skull will need to answer this one, since I never owned a C128. :)
AS: Well, I have c128D and in truth it is only using the registry to speed up the processor in some moments such as unpacking... but also in the game on the bottom border - it gives you an even better fluidity of movement mainly in the fierce game play of multiplayer mode or to increase performance for ntsc systems. The game recognizes the platform on which it is running and automatically adjusts itself. One of the curiosities is to use the second button, when a joystick is attached to Commodore GS. That in the game serves as a pause (GS system does not have a keyboard).
Q: What projects are you currently working on and can we expect another game release this yea?
AC: As far as myself and Skull are concerned, no other projects have been confirmed yet; (We're taking a break ;)). I personally however; have been working on another (small) game with another Samar member, that will be published officially in Poland.
AS: At the moment I'm taking a break due to the birth of a second child, so my time for C64 has decreased recently. The plan is to help with making a new Samar demo at some point in time. I'm also creating a file manager for the SD2IEC called "sdbrowse".
Q: Why was the game released on Cartridge from RGCD and what promoted you down this route rather than another distributor?
AC: I'm only answering this with what I have heard, read and experienced, but Protovision was actually the main guys who wanted to publish this game. But for some reasons that I don't know of, they were inactive for quite a while; and I think it convinced Skull that we should just release the game on our own. Around the same time, RGCD were publishing a lot of really good C64 games on cartridge, including a couple of games I worked on such as "Not Even Human" (2008) and "Assembloids" (2012). James Monkman (who I've known since 2011), the founder and organiser of RGCD, came across our "Preview" version of Bomberland, this was released publicly in 2012; and that's pretty much where it all started. James, Skull and myself all agreed to work on a 64K cartridge version of Bomberland which quite honestly, woke both of us back up to get this game finished, thoroughly tested, and published at a great and affordable price.
AS: Yes exactly, The first interested in the project was from Protovision. I was glad at first, but soon I began to fear that the game would transform to "BombMania 2". As I mentioned earlier, Bomberland is of a different nature to BombMania, besides issuing two titles of actually the same genre would seem a little odd for Protovision. However, for a long time we had not been in contact with each other. Then interest in the game was shown by James of RGCD. After some years and a release of Bomberland Preview, he asked us again about the game, as opposed to Protovision which by this time were silent. I liked the idea of publishing games for cardridge, Conrad too liked the format- so we agreed to terms and conditions, then Jacob of Protoviosion contacted me again, but it was just before the release of the game in October - which was now ready to sell. But the idea was born, the concept of release of the game (extended) on a floppy disk, with the cooperation of both RGCD and Protovision.
Q: How was the game created what tool did you use? For example, was it created in a cross compile way or entirely on the Commodore 64?
AC: Shamelessly, the music was composed in a cross-development tool named GoatTracker, a SID tracker that I've been using for a lot of years now. But, due to that memory issue I answered previously, a new music routine was developed, using a cross-assembler named KickAssembler. Although the final music routine code was written this way, I also wrote some testing code directly on a real C64, using the machine code monitor on Action Replay V6, remember my attempts to show you raster interrupt programming with the Action replay cartridge! You see, I like to make sure that actual parts of a music routine work 100% on a real C64 before I attempt to write and document it on a text editor, so I would say I have developed code both on a real C64 and PC/laptop. The final music compilation was also tested on a real C64.
AS: My development environment used in this project was Relaunch64 editor with 64tass compiler and the Vice emulator. Next I had a whole bag of interesting tools... Exomizer, Timanthes, MUSC converter, makedisk, CharPad, SpritePad etc. (I don't remember them all)... but I started with TurboAss running on the emulator and tools from C64. I am not sorry that I didn’t use a real C64 for all the work, because I couldn't; mainly due to the complexity of such a project and constantly keep refining the small details.
Q: Apart then from the Music routine, what else caused you the most problems in creating the game?
AC: It was mainly all trial-and-error from that point. James helped us to test the game for bugs, which we found along the way. There were also problems to solve when tested the game on NTSC machines, so that kept us busy. Another interesting fact is that me and Skull promoted Bomberland at Silesia 7 demoparty, 3 months before the game was officially released. We did this through a "Bomberland tournament". The idea was, not only to have a fun competition at a party, but to also check for gameplay bugs tested by real human beings. We found many bugs this way, which we took note of and fixed afterwards. I personally want to thank the sceners at Silesia 7 party who took part in this... you lot were a great help.
AS: I don’t want to think it all over, but it was a hassle! - errors popping up exponentially - and the removal of some resulted in the formation of new ones! I think I complicated the code about a million times. The project "Bomberland" has more than 50 files of sourcecode in them; tens of thousands of lines. At the end, mainly the problem with not enough memory on the cartridge :)
Q: is there a question you would have liked me to ask but I haven’t
AC: Not that I can think of... I think you've asked us enough. :)
AS: I have to admit that you are asking quite clever questions, you are good at this job :) Thx for the review.
Author | Misfit |
---|---|
Requirements | Unexpanded VIC-20 + Disk Drive + Joystick |
Tested on | VICE 2.2 and real VIC-20 (PAL) |
The game was created in 48 hours for the Ludum Dare 27 competition
You can Download the game as a D64 from here
http://www.riimukivi.net/data/fastboy/vic20_fastboy_ld27.zip
The Download for the Source code is available from here
http://www.riimukivi.net/data/fastboy/vic20_fastboy_ld27_src.zip
FastBoy won 36th place in 48h compo (1437 entries)
http://www.ludumdare.com/compo/ludum-dare-27/?action=preview&uid=10677
This is a regular accelerated game development Event. Participants develop games from scratch in a weekend, based on a theme suggested by community, The LudumDare 27 theme was the 10 seconds.
That's why "fastboy" has a "10 seconds" timer on each screen.
Now when a game is released and it’s labelled; “for the unexpanded vic 20” it usually means one of two things, either it’s a load of rubbish, or…. You have a programmer who`s original idea was so good; and his programming skills are so competent; he managed to fit an incredible concept into such a small amount of memory; and still come out with an amazing game
Well for the record it’s the latter of the two, it`s an amazing game!
Fastboy is of those quite annoyingly simple games in concept, but actually when it comes to play the game; it`s so difficult to actually play, not that its hard, its simple and that’s the beauty it`s so simple it`s difficult to play. You know like Tetris, it’s a simple game and easy to play but sometimes so difficult to master.
Fastboy is a retro game for unexpanded Commodore VIC-20, and was written in a 48 hour period from scratch for the Ludum Dare competition. As the competition has ended and the results are in; with this game came in 36th place, I am judging the game purely on a Vic release rather than a competition entry.
The instructions for the Game are sparse, In fact within the game they are Zero, with the games roots in the competition, I suppose more time was focused on the game rather than rules, as a game release that’s one of the games downfalls, I felt; the game lacked instructions, on screen or from a text file with instructions. (Although as said it’s a competition entry rather than a game release)
The games splash screen is effective, with scrolling bricks underneath the static text, although not a new idea; is still incredibly effective and with the shading works very well to grab the gamers attention.
The game is incredibly simple anyway, it needs a joystick, you control fast boy who appears as a white blob on screen, You “the fastboy” have 10 seconds of time and need to collect at least one diamond before you can move onto the next level. If you fail to collect a diamond within the 10 seconds then it`s GAME OVER
Of course that would be easy if it wasn’t for other things in the way that are also moving around the screen, the higher the level the more things that are in your path, hit one, and again you are show to the score screen ready to start the game again.
Not what you could call a new idea, however apart from the said lack of instructions, it’s nicely implemented and runs incredibly quickly on the Vic. Yes I know it’s a competition entry but its being judged here as a Game release.
If you use VICE, xvic.exe is a VIC-20 emulator. Configure joystick and open my D64 disc image.
LOAD"*",8,1 command loads a program if emulator does not run it automatically.
RUN command starts the game (if emulator does not start it automatically)
First you see start screen. Push joystick fire button (or space)
wait.. it loads...
Push joystick fire button to start the game.
Thanks!!
Graphics | 5/10 nice splash screen and in game borders/shading otherwise graphics are basic
|
Overall
6/10
|
---|---|---|
Sounds | 5/10 nice tune and spot sound effects
|
|
Gameplay | 6/10 arrrrrrrrrrrgh just one more go
|
Basically just a competition entry but with some good ideas, as it stands it’s a credible game for the vic and I am sure one you will load to have just one last attempt at a better score.
Author | Misfit |
---|---|
Requirements | Unexpanded VIC-20 + Joystick. |
Tested | VICE 2.4 and real VIC (PAL) |
Bolder Dan is labelled as a simple Boulder Dash clone and will run on the unexpanded VIC-20, now remembering what I said about the unexpanded machine, 3.5k of memory isn’t a lot; and it takes some skill to create a game, it`s possible but some fall short in both quality and gameplay.
Once loaded the splash-screen appears with sparce instructions, but I can`t think anyone would not know what to do in this game. Basically you need to collect all the diamonds but beware of the rocks as walking under one will cause it to topple and fall, this could crush you or block you way to collecting all the diamonds on the screen, you need to think quickly and plan your route through the screen
Selecting a dungeon the game begins
As you progress through the levels various “enemies” try to get in your way, by following you or generally annoying you. The game has 4 levels or dungeons with 29 levels.
The game looks great, the animations are a little rough and jerky; but it all adds to the games charms, the tracks left by the players moves are a nice touch and the “sparkle” of the diamonds is another imaginative idea, taken from the game that this is a clone of. The title screen has some manic music that adds to the tension of the game, but I wish it would returned to this screen after all your lives had expired, you just see the score and have the option to play again, I guess this is down to memory limitations. It’s all in here as you would expect from this type of game, you can push boulders to kill or trap creatures; and the game controls work well, also the gravity seems to be acceptable, all in all a really good release for the Vic
Graphics | 8/10 colourful
|
Overall
8.5/10
quite brilliant
|
---|---|---|
Sounds | 7.5/10 great tune on the splash screen, with in game bleeps and pops
|
|
Gameplay | 8/10 great, everything you would expect is here all packed into such a small space
|
Showing that games really can be packed into small amounts of memory, it has everything you would expect from a game in this category, with great sounds colourful graphics. A brilliant release from the author. Its another Vic Must have title!
Q. Please introduce yourself to our readers
Hi, my name is Mika "Misfit" Keränen, I am 37 years old; and am a punk rock coder from Northern Finland (City of Kajaani).
I'm a software specialist (boring software developing stuff for Windows/Linux/mobile/embedded devices etc.) and making games is my long time hobby. I hate game design; but low level and Hard Ware independent coding are my favourites.
When I was a kid I received a VIC-20 and started to learn basic programming. The VIC however was my second computer, Salora Fellow was my first one. A Few years later my parents bought a C64 for me and rest is as they say is history.
Q. How did you start programming on the Vic
I don't remember my first VIC program; however it was some kind of text adventure. I was about 8 or 9 years old when I wrote it. My parents sold that VIC and time passed..
A Few years ago I met my school friend Aleksi Eeben in the Boozembly event; and he told me that making programs for VIC-20 is awesome. After that meeting; I thought that maybe I would have to go back to my roots too; and I bought a VIC again. I downloaded the VICE emulator and a copy of the CC65-compiler, and started to make simple "hello world" tests. ..a few days later I started to develop a simple Boulder Dash clone.I noticed that coding for 8-bit machines is very inspiring, and it was like a time machine transporting me back to my childhood and 80's.
Q. Tell our readers about the the Ludum Dare 27 competition
Ludum Dare is a regular accelerated game development event. People develop games from scratch in a weekend, based on a theme suggested by community. Developers make games in 48 hours and play/judge each others games for several weeks. The Ludum Dare community is a very supportive group of game developers; and everybody wants to just have fun.
Q. So FASTBOY won 36th place in 48h programming competition section; up against a vast (1437 entries) what computer systems were covered; and you must be very pleased with that result
Most of people use high level tools and create web or Windows games ;(only few games for retro devices). I made 3 games for Windows, Android, Wii and Web, but then I recognized that retro platforms received lots of publicity. So I choose to make a small experiment with my VIC-20; and check if it would get any publicity. And yes.. my evil plan worked fine, :-) People respect old machines. There were people who are too young to understand what VIC-20 is; They know about the Commodore 64 but didn’t know what the VIC was.
Q. How does the competition work, for example what tools can you take in the competition with you, and how do the judges know you haven’t got a “stashed” disk in your coat pocket to just “pull out” at the last minute!
You can use 3rd party tools/game engines; or your own base code, but you have to publish the base code; and tools list before competition. When competition starts, the theme of the competition is then published. Of course you can "pull out" your old polished game, but it would be pathetic. Ludum Dare does not have any prizes; and people realize very quickly if you cheat.
Q. The source code has been released as well as the game; it looks like the game was written in C programming language, what was the reason for this why not machine code.
Well I am a C dude. I always use C (or C++). I even make web applications with C. When I started developing games for VIC; my goal was to check that it was possible to use C for 8-bit games. Sometimes I feel that I have to code same game twice, first I would make a C code; and during optimizing I research compiler results; and then try to understand best way; to make smallest compiled file. But that's fun!
Q. Apart from memory limitations on the machine, what other single factor was the biggest problem while writing the game
I did not have any problems mainly because I had 48hour to fill just a few kilos of memory (how hard could that be?). I was making "Bolder Dan" when I wrote "FASTBOY"; and I have learned enough to help me avoid the biggest problems. "FASTBOY" is so simple; that developing it did not cause me any nasty surprises, only straightforward coding, a few graphic objects and coffee.
Q. Did you go into the competition with the game idea, and test code written “in your head”, or did you just go in blind in the hope something good would come out at the end
I had only one plan: that was to write a simple game for VIC-20 and make it as quickly as possible. I didn’t have any high hopes about making best and most unique game ever.
Q. how do you practise for such a competition
I develop my own framework which support Windows, Android, Web and Nintendo Wii. I am interested in OpenGL and low level coding. I wrote my own music tracker; which gave me new information about audio programming. I feel that retro 8-bit coding is something that is missing when you make applications for modern devices.
Q. the next game I reviewed in commodore Free “this issue” was “boulder Dan”; now we can see that time limits weren’t an issue on this game; as the quality is very high, how long did the game take to write, and was this also written in C
Yes, it is also written in C. (funny.. thins about the name is, the game is called "bolder dan" but English people always spelling it "boulder dan". Well.. maybe I was trying to be too clever when I discovered the name. I'm sorry about that.).
"Bolder Dan" took almost 6 months. It took only few weeks to make gameplay, but memory limitations were total pain. I made a simple level which provided a skeleton of the game and realised that the memory was already full.
First I optimized everything, then I gave up; and rested for a few months (and I built a new roof for our home). After summer I started optimizing again. I squished a few bytes and added a new feature. Then I squished few bytes again and added more stuff. This continued over several months.
It was so slow but so rewarding to realize that I can make it. Finally I posted the game to Denial forum and decided that the project has reached its target.
Q. In my review I criticised both games for not returning to a “main menu”, I presume this is purely down to memory limitations, was all the available memory used up on bolder dan
Yes.. that "feature" is very annoying, but you are right the reason was that the memory limitations of the machine were hit. My games have several parts; because I wanted to provide decent music and a neat start screen and use all available memory for gameplay.
If you check the Bolder Dan screen you can recognize that first row is black. This is because the first row of screen has program code. I used too much memory, no room for new data. No room for going back to "main menu". Maybe C-language is the main problem; but it was my decision to use it.
Q. what plans do you have next
Well.. my first goal was a make decent game for unexpanded VIC. I think I have made it and now! So maybe I can use some extra memory next time.
My next project is bigger; and its working title is "Bertie The Ball". I made a "smooth" software sprite routines and the main gameplay is now ready. I just tested it on a real VIC and it worked really nice.
I have to add new screens and puzzles before I can release it though. I won't tell you too much but I have to say that one of my favourite C64 game is "Cauldron 2".
Q. Ohhh sounds cool, what tools did you use to develop both bolder dan and fast boy games
cc65 compiler and CBM prg Studio for graphics. Now I use Commodore Sprite Maker v.1.4b (nice little app btw.) and my csm to h-file converter which exports sprite data to my data format.
I planned to make music tracker for windows which could make music for VIC. But that is a another story.
Q. That would be a neat project, bolder dans music in very unusual, can you enlighten our readers more on its creation and what you based the piece of music on
Well It took few hours to make that song. I am a fan of 8-bit music and a year ago I made my own chip-tune music tracker which I used when I made games for Ludum Dare competition. I used that knowledge when I created music for VIC games; but I did not use any music tools for that. I just coded a small routine which handled my simple music format and I put bunch of notes to code table.
Here is "bolder dan" theme music (very complex):
const byte a1[]= {C3,E3,G3,C3,D3,G3,C3,D3,E3,_E}; const byte a2[]= {C1,_S,_S,G1,_S,_S,C1,_S,_S,G1,_S,G1,C1,_S,_S,G1,_S,_S,C1,_S,_S,G1,G1,G1,_E}; const byte a3[]= {_S,_S,_S,_S,_S,_S,C2,D2,E2,E2,D2,C2,_S,_S,_S,_S,_S,_S,E2,D2,C2,D2,E2, C2,_S,_S,_S,_S,_S,_S,_S,_S,_S,_S,_S,_S,_S,_S,_S,_S,_S,_S,_S,_S,_S,_S,_S,_S,_S,_S,_S, _S,_S,_S,C3,D3,E3,E3,D3,C3,_S,_S,_S,_S,_S,_S,E3,D3,C3,D3,C3,G3,F3,E3,D3,C3,_S,_S,_S, _S,_S,_S,_S,_S,_S,_S,_S,_S,_S,_S,_S,_S,_S,_S,F2,E2,D2,D2,D2,C2,C2,C2,D2,D2,D2,E2,E2, E2,D2,D2,D2,C2,C2,C2,E2,E2,E2,G2,G2,G2,_S,_S,_S,_S,_S,_S,_S,_S,_S,_S,_S,_S,_S,_S,_S, _S,_S,_S,_S,_S,_S,_S,_S,_S,_E};
Q. Do you think the Vic still has secrets that can be uncovered for programmers
A: I think that every hardware has own secrets and always somebody will make something new.
My opinion is that if you finish a project and start a new one, the new one is always going to be better; and you can always push your own limits and the machine further.
Q. is your intention to always release games for the unexpanded machine, and do you feel adding extra memory is cheating in some way or less challenging
Well yes, As I said, my first goal was to make a game for unexpanded VIC. I made it, and my next goal is make something more complex. Unexpanded VIC is a nice challenge, but extra memory gives you different challenge to beat.
Q. do you have any question you think I didn’t ask or would you like to add anything more
Are you a proud member of KISS Army Finland : Yes! I Am.
Thanks for the interview and your time
Programmer | beamrider (Adrian F) |
---|---|
Requirements | VIC-20 + 16K + Joystick |
VIC version download
https://docs.google.com/file/d/0BypVxYomFCZfTHRCTVpNTnhyTVE/edit?pli=1
Discussion on denial
http://gator3293.hostgator.com/~sleeping/ipw-web/bulletin/bb/viewtopic.php?f=10&t=6780
Or if that doesn’t work the main link for the Denail forum is here
An original arcade game manufactured by Stern Electronics, under license from Konami; and was released in 1982. The game was so popular, it was ported to many home computers of the time, including The Commodore 64 and recently the playstation and Xbox. However no Vic 20 version was ever released until now.
In the game You are "Mama", a pig whose babies have been kidnapped by a group of horrible wolves. “mama” pig has to defend her home; and rescues her "Pooyan" (these are the piglets that the wolves have kidnapped). “mama” has an elevator car; this car can move up and down (by pushing the joystick up and down) “mama” has access to a bow and arrow (as do all pigs) she uses this to Fire at the wolves by pressing the fire button (no surprises there then). Also At the top of your rope; is a piece of meat that appears, at what seems to be random intervals. But by Collecting this meat; it gives “mama” a special shot that will descend in an arc; and knock out any wolves it hits. The wolves seem to have also developed some sort of shield for their balloons and can deflect arrows (some times) by putting a shield up in front of the balloon.
It’s a game of two halves in 3 parts.
the wolves are floating down to the bottom of the screen after jumping out of the Trees; they do this floating by means of balloons, As “Mama” you need to shoot the wolves down by popping the balloons, with your bow and arrow (not shooting the Wolves) although the wolves also have the ability to throw rocks that can knock “mama” out of her elevator; and of course she will then hit the ground and Die. If you don’t kill the wolves; then they will start to steal more pigs; resulting in you loosing bonus points, after this; the wolves will slowly start to climb up the ladders, blocking “mamas” movements and eventually they will eat her.
(occurring after an "intermission" sequence), the wolves are floating to the top of screen, and if enough get there, then they push a boulder on top of Mama and kill her, though in the second stage the boss must be shot down.
The game also features a bonus stage, Oh that’s three stages then (well technically)
Of course most people will like the game because it contains the word Poo in the name of the game, and you can laugh and joke about it in a school yard way, should you like to.
On loading the game, just like the arcade version; the balloons appear float midway up the screen and then pop and for the letters pooyan. To see this screen again you have to die; so you will get used to it! After the main title screen; we are treated to an animation of the pigs being chased by the wolves, this then clears and we start the first stage.
The vic conversion works well; and is very fluid in its controls, All the elements are here; and have been well implemented within the restraints of the hardware. I found the game quite hard to play, but my attempts sat in a smoky arcade; while I should have been sitting in maths lessons at school; were just as pathetic. The game seems very much like the original; the Vic version actually looks remarkably like the commodore 64 version. Sounds are good for the Vic; with a nice tune playing during the game, and spot in game sounds, the graphics are large and colourful.
One thing that did strike me; and I don’t know if the original was the same, but when you throw the meat it doesn’t seem to shoot out very far, but then I am not an expert on shooting meat from a suspended cradle you understand, but the wolves do seem to have to be quite close to you for the meat to hit them!
Gameplay | 7/10 ok it’s a remake, but its a good conversion
|
Overall
7.5/10
very nice conversion for the VIC
|
---|---|---|
Graphics | 7/10 very accurate to the original
|
|
Sounds | 8/10 nice version of the music plays in the game
|
Not much to add really; a very competent conversion for the Vic 20, quite slick and well executed, great animations and graphics and in game music.
Q. Can you please introduce yourself to our readers
Sure. My name is Adrian Fox. Originally from the North of England; and now living in Swindon in the South-West. I am married with a step-daughter; I also have two sons all in their mid/late teens. Work wise I’m a freelance software engineer; currently I am on contract in London. When not on the Vic; I enjoy messing around with gadgets, hiking and motorcycling.
Q. Can you give our readers a brief history of how you became involved with the Vic; and how you started coding on the Machine
I received a Vic as my first computer at the age of 13, after the machine was recommended to me by my Maths teacher; as a cut-down version of the Commodore Pet; that I had been using at school. Initially, I had no tape deck; and so had to retype in the programs from the user guide at every power-on. When I finally obtained a datasette, I wrote a couple of games in basic myself, but they were nothing special. I always wanted to write machine code, but when I tried it seemed too difficult, especially using the vic itself as a development platform. I eventually moved onto the C64 and Amiga but never did any coding.
Q. What prompted you to code a port of Pooyan for the vic and how long did the conversion take
I started getting back into the vic about 10 years ago, acquiring hardware from E-Bay; and following the scene on and off. I was impressed by some of the recent excellent releases for the vic; [Frogger-07, Quick-Man 2008 etc] and my attention turned to some of the games I’d enjoyed on the C64 in my youth that were missing ports onto the vic. Pooyan being one of my favourites came to mind. I began to wonder if I could finally master 6502 coding. I had several attempts but the effort seemed too much until a couple of tools became available, [VIC-SSS and CBM-Prg Studio] and these were the catalyst that got me started. The game took about six months from start to finish.
Q. Are you still developing the title or is this now a “finished release”
No, I’ve finished it really, unless anyone finds any critical issues that need addressing.
Q. Do you have plans to release the title commercially through a Scene distributor
No, there won’t be a commercial release as it isn’t an original game; and so legally a grey area. Also, it’s nice to just give something back to the community; after using all the excellent free resources like Vice, etc.
Q. How close to the original version do you think this port is
I tried to make it as close as I could within the constraints of the vic. E.g. I put in nearly all the animations from the Arcade, eyes blinking up and down, etc that I could. There are some omissions due to graphics and memory constraints….
Q. So what’s missing from the Vic version that the “full” version had, and what did you use for reference
The arcade has some more cut scenes, different coloured super-wolves, free floating balloons and fruit. All these features would push the game to 24K at least, - something I resisted doing. I wanted to make it playable on real hardware, a vic + 16K is (was) a fairly common configuration. I used the original arcade game running under MAME and also the C64/NES versions for reference.
Q. What was the main problem converting the game to the Vic
I think lack of user defined character space for the graphics was the main obstacle to overcome. It was difficult to fit everything in. For example, I couldn’t include the full alphabet and only copied across the letters I needed from the Vic character ROM.
Q. What process did you follow with the conversion, did you for example create a test code; or did you start with the graphics then try to fit the code around them?
I mocked up the main screen; then developed some PC based utilities in C# to convert the graphics to compressed (Run Length Encoded) data; and then wrote my first ever 6502 routine to display this on the screen. It was really nice to see it appear on the Vic screen for the first time. Next step was to define some graphics for the wolves sprites; and float these over the top (learning more 6502 along the way). It all followed on from that, with game elements being introduced one by one. The final step was to develop the music player.
Q. Do you plan any other conversions to the Vic
No, not at the moment at least. Pooyan took pretty much every minute of my spare time for about 6 months, so was quite a drain for me; on top of my full time job. I find it difficult to put things down once I start, so the game kind of took over. Sometimes; I would have to get up in the middle of the night if I had thought of a solution; and type in the code for it otherwise I just couldn’t sleep
So now I’m quite enjoying the rest from it, but eventually I might try my hand at something else - there are a couple of possibilities I have in mind.
Q. What are the conversions Best features in your opinion?
I have always liked chip-tune music; and I think that the in-game music isn’t too bad considering the limitations of the Vic. It took me a while to get the music and sound effects to play independently. I also like the cut scene and title screen.
Q. I know you mentioned some of the tools you used but could you expand on that a little, and do you intend to release the source code to the general public
Yes, as I already mentioned; the game is built on top of the Robert Hurst’s Software Sprite Stack from Denial. I created the graphics and sprites using CBM Prg Studio. I used the CA65 as the assembler; and Notepad++ with a couple of plug-ins as the development environment.
Sorry - I’ve no plans to release the source code at the moment.
Q. So you programmed this as a “one man team” didn’t you have input from anyone else
It was just me really, well apart from help on the Denial forum; and also my wife helped, she made the spreadsheet to generate the curve data for the projectiles in the game.
Q. How do you go about testing the game to iron out the bugs that may appear
Nothing special - just repeatedly playing the game mostly. There was a particularly nasty bug that I found by setting the game up to invincible mode with auto-fire; and running several instances of the game under the Vice emulator in warp mode (10 x normal speed) over night. Some of them had crashed by morning due to overwriting a wrong zero-page memory address.
Well, here we go. This is the first installment of a series focused on learning to write assembly language programs for the 65x family of processors found in Commodore computers. I would like to publicly thank Nigel at Commodore Free for allowing me to share some of my programming knowledge and experience with you here. My belief is that as the current computer “Renaissance” plays out it is important to have modern information regarding assembly language available to all of us. This series of articles is my effort. Thank you, Nigel.
Our mutual goal in this series, yours and mine, is to explore the world of 65x assembly language. Together we will discuss various aspects of what many consider the “black art” of computer programming. I will show, and you shall soon see, that assembly language is indeed nothing more than a method of communicating through a computer using a set of human-readable codes called mnemonics. These mnemonics are translated into a series of instructions the computer understands using a tool called an assembler. Unlike BASIC or C, which are considered “high level” languages, and where one command is translated into a series of machine language computer instructions that may easily reach hundreds of bytes in length, assembly language is translated in a one to one fashion, and is known as a “low level” language. One assembly language mnemonic equals one computer instruction. Therefore, assembly language programs execute very quickly, often hundreds or even thousands of times faster than the equivalent program written in BASIC, and substantially faster than equivalent C language code. In addition, assembly language programs use less memory than their BASIC and C counterparts.
In this series we will examine the 6502/65816 instruction set in detail, and you will learn efficient ways to use these instructions in the programs you write. The choice to learn assembly language puts you, the programmer, in the driver's seat. Contrary to popular belief, any program can be written in assembly language, and also contrary to popular belief, program development time does not have to be an issue provided you are equipped with the proper setup and have the right tools, skills, and habits for the job. This article is devoted to helping you with this endeavor.
More importantly, throughout this series you will learn to communicate through the computer at a level that is either not possible or is very difficult with BASIC or C alone. We will explore the 8-bit 6502 as well as the advanced 16-bit 65816 processor found in the SuperCPU. Along the way we will discuss good programming habits and techniques advanced programmers use in programs they create. Our discussion will be limited to assembly language programming in the generic sense, so I will not attempt to bog you down with lists of specific computer addresses nor will I demonstrate hard-core sound and graphics as they are complete subjects of their own. We will, however, discuss our topics within the context of the Commodore 64.
So, what is planned for this series? Each time out we will explore a topic relevant to learning assembly language programming, beginning today with the tools you need to create assembly language programs. Future topics include an on-going inside look and comparison of the 6502/65c816 central processing units, the instructions these processors understand, data movement, addressing modes, both simple and complex, application flow control, arithmetic, and logic and bit manipulation. We will also devote time to the stack and interrupts – advanced subjects that even many seasoned programmers do not fully understand. But you will.
Along the way I'll throw some good programming tips and habits at you, things I have picked up in my own never-ending path to knowledge. We have plenty of time to learn programming in assembly language, and I promise, there is plenty to learn. Our goal is to explore and learn, so let's start right now...
In order to create assembly language applications you will need an assembler. An assembler is the tool you use to translate text-based source code into executable code. You, as the programmer, feed the assembler with symbolic pseudo-language text files and the assembler outputs binary files the computer understands. Thankfully, the assemblers we can choose from are free and easy to obtain, and below is a table showing you where to find them. In the course of my own personal exploration I have used countless assemblers, so I have seen some good ones and, shall we say, some not so good ones. Some (arrggh!) I typed in from magazine or book listings.
But before we do that we have a decision to make. Do we want to create our applications directly on the Commodore 64 or do we wish to do our development on the PC? Many purists would argue the former. Well, I have an opinion about that, so it's probably a good time for Tip #1:
I have what I feel are good reasons to believe this, but Tip #1 is not a golden rule. The applications you create on your physical or emulated c64 are no different than those drawn up on the PC, so feel free to code on either the real thing or in VICE, or both, but there are other factors you may want to consider.
First, and most important, is development time. Twenty five years ago most programmers created programs right on their c64s. Most amateur programmers, that is. The pros were busy developing on machines that were faster and had more memory. They stored their source files on disk drives that were much faster and larger than the c64 could offer.
As projects grow in size the assembly process becomes a time-consuming burden. And let's face it: this is not the 80s. Computer users today expect sophistication. They expect things to be easy. This means you will have to work harder to impress them. What I am saying is that in today's world you will probably not get away with rainbow colors, INPUT statements, and CBM character graphics. A modern user interface is going to require better planning, some creativity, the mouse, and ultimately much larger and more complex source files, so if you are developing on a stock 64, even one equipped with JiffyDOS or an IDE64, you will soon find yourself waiting increasingly longer for your project to compile into its final, executable form – and that's just a waste of good development time.
A second major reason to create your applications on the PC is that developing programs on the test machine risks contaminating both environments. What if you need to use most or all of RAM for your program? That's going to be tough if you are developing and testing on the same machine, especially since assemblers need some of that memory for themselves. One assembler I consider to be excellent for native c64 development, Turbo Macro Pro, or TMP (listed below), has a version that stores your source text in the REU. Although the size of the source is ultimately limited and the c64 can only compile the source code at 1 MHZ, for small to medium-sized projects TMP would be my choice for native development. Noteworthy is the similarity between TMP and two PC assemblers, TMPx v1.0 and 64Tass. Moving from one to either of the others should require few, if any, changes to your source text.
For larger applications the PC is the smart choice for development. For example, I am working on a project now that is comprised of well over 100 source files. By the time the project is finished it will use nearly all of the stock c64 RAM and the source files will easily exceed 1 MB. It is further complicated by the fact that it is a SuperCPU-based project, and makes extensive use of extended RAM. My 3 GHZ PC assembles all of it in about a second – and does not disturb the Commodore 64 environment at all, with testing in VICE an automatic task. I shudder to think how long it might take to assemble on a real c64, even with a SuperCPU, and I wonder (doubtfully) if any native c64 assembler could pull it off.
In BASIC there is usually just one source file. There is a limit as to how large it can be and your program executes as soon as you type “RUN.” If you make a typing mistake or some programming error the computer lets you know about it right away. Variables are stored safely away and unless you do some crazy poke, the computer will not freeze up or “crash.” The program will just stop, tell you there is an error, and that's it. You are in essence running managed code. Assembly language is different – there is no safety net. Syntax errors are caught by the assembler but otherwise you are free to do what you want, where you want to do it. This leads to frequent crashes, especially while you are learning. As you progress through your assembly language journey the inevitable program crashes are a fact you will definitely get used to, and frankly, regardless your level of experience, crashes never really go away. The good thing, believe it or not, is that crashes are almost always a good learning experience because, if for no other reason, they bluntly point out a mistake you made somewhere.
Assembler | Platform | Supported CPU | Where to Get it |
---|---|---|---|
CBM prg Studio | PC-GUI | 6502/65816 (soon) | Arthur Jordison http://www.ajordison.co.uk/ |
C64 Studio | PC-GUI | 6502 | Georg Rottensteiner http://www.georg-rottensteiner.de/en/index.html |
64Tass | PC-command line | 6502/65c816 | Soci/Singular https://sourceforge.net/projects/tass64/files/latest/download?source=directory |
TMPx v1.0 | PC-command line | 6502 | Style http://style64.org/release/tmpx-v1.0-style |
KickAssembler | PC-command line | 6502 | Kick Assembler V3.30 http://theweb.dk/KickAssembler/Main.php |
cc65 | PC-command line | 6502/65816 | Ullrich von Bassewitz / Oliver Schmidt http://oliverschmidt.github.io/cc65/ |
Turbo Macro Pro (TMP) | Native c64 | 6502 | The Wiz/Style, Elwix/Style http://style64.org/file/Turbo_Macro_Pro_Sep06_c64-STYLE.zip |
Buddy/Power Assembler | Native c64 | 6502 | cbm8bit.com http://cbm8bit.com/8bit/commodore/search |
Sirius | Native SuperCPU | 6502/65816 | Stephen L. Judd (The Fridge) http://www.ffd2.com/fridge/sirius/ |
The list of assemblers above is by no means complete; rather, these are assemblers I am familiar with and have used with some success. These assemblers, many of which are being developed by active members in our community, come with different levels of complexity, functionality, and stability with regard to program bugs, which is to be expected, yet all are very capable and will help you get the job done. Just as with a home, car, or TV, we all have have our own preference. There is no right or wrong assembler in the list, and you may try several before finding “the one” that suits you. I primarily use 64Tass and CBM prg Studio for my programming, just in case you were wondering, although there are others in the list which have specific features I find valuable. For example, cc65 has a brilliant 6502 symbolic disassembler, which is incredibly fast and useful for “tearing” programs apart and seeing how they work. Sirius is good for native SuperCPU work, and Buddy is great for smaller stuff to be easily added later to the larger project.
Developed by Arthur Jordison, a talented guy who has become a good friend of mine, CBM prg Studio is what you might call a “complete package.” Within this IDE (integrated development environment) you can create BASIC and assembly language programs, design sprites, character sets, and complete screens. CBM prg Studio, or CPS, also includes a debugger (a great feature) and has facilities for batch program creation, which can be useful for creating multi-load programs, such as a menu program which loads different modules based on the menu choice. All of this is housed in a very nice layout.
Arthur works diligently to fix bugs as they are reported, and he always seems to be busy working on CPS. He has recently begun work (I would like to think as a result of my urging) to include instructions for the 65816 and SuperCPU, which when completed, will make this assembler package a true powerhouse. I frequently use Arthur's studio to create sprites because I can quickly export the data directly into assembly language source code, which is a world easier than trying to type everything in. Highly recommended.
Written by Georg Rottensteiner, C64 Studio is a Windows Forms-based IDE for C64 development on a Windows system. It was made specifically for writing games and targets the hobby developer. C64 Studio provides code editors for assembler and Basic V2. In conjunction with Vice debugging through the assembler, C64Studio features breakpoints, watches, memory and register views, and has tools for character set and sprite creation and editing. The assembler in C64Studio is based on ACME syntax. One of the newer products in the list, C64Studio is quickly finding a following. I like it.
Of all of the assemblers in the list, 64Tass is my personal favorite, and I have yet to find a flaw with the current version. Written by Soci of Singular, one of the VICE developers, 64Tass can assemble programs of any size or complexity for any of the 65x processors in the blink of an eye. 64Tass is probably not for the beginner as it makes use of advanced concepts, but for the experienced programmer it is really a beauty which uses standard syntax compatible with Turbo Macro Pro (a feature I like a lot) and outputs any type of file you would need for the c64. An important but undocumented aspect is that Soci readily and generously answers questions when you have them. 64Tass is a command line assembler, but can be easily integrated into any good programmer's text editor which supports a command line, such as Notepad++.
TMPx v1.0 is billed as the first and only cross assembler that is 100% compatible with the full syntax of the C64-based Turbo Macro Pro, and it was, in my opinion, the best 6502 cross-assembler I used after migrating to the pc for full-time development. I may never have moved on to anything else, but SuperCPU work requires an assembler capable of outputting 65816 code. Otherwise this assembler is excellent, and for those who used the original TMP on the c64, their old code can be made pc-ready by using a companion program, TMPview v1.3, which is a tool that converts binary source code files saved from Turbo Assembler, Turbo Assembler Macro, and many variants including Turbo Macro Pro into an ASCII version of the code which can be fully assembled by TMPx. Powerful, stable, and easy to use, TMPx is one of the really good ones.
My C/C++ programming skills are shaky at best, but if you do have the background, one assembler I would highly recommend is the popular Kick Assembler. Now in version 3.30, Kick Assembler uses syntax and concepts that are very similar to those used in C/C++ programming. Many of my programmer friends use and really like Kick Assembler, which has one of the best and most thorough manuals you can find for any pc program. I used Kick Assembler for a while and liked its speed and features, but as mentioned before, I did not have a C/C++ background, so something as basic as curly braces was very foreign to me, and you know the saying about old dogs...
The final PC assembler in our list, and by no means the least (probably just the opposite), is a programming suite named cc65. For serious programming projects, this one if tough to beat. Originally written by Ullrich von Bassewitz and now maintained by Oliver Schmidt, cc65 has it all – source archiver, 6502/65816 assembler, linker, assembler-source-to-HTML converter, C compiler, 6502 disassembler, object-file converter, GEOS resource compiler, object-file analyzer, and a sprite/bitmap utility.
This programming suite is probably not for the beginner as it is very advanced (and equally capable). Anything is possible, including C-style projects. I frequently use several of the cc65 modules in my work and find all of them to be solid, blazingly fast, and error-free.
The learning curve could be considered steep, but once you are comfortable with assembly language, check this one out.
It is important to note that while a GUI is nice to use, with CBM prg Studio standing as a prime example, any of the command line assemblers may be used with an advanced text editor such as Notepad++ to achieve very good results. Tabbed text editors allow the programmer to view multiple files at once, and editors in the Notepad++ category generally include a pseudo-command line interface to assemble and test your programs.
I purposely did not elaborate any of the native c64 assemblers as there is ample information about each to be found on the Internet. Native assemblers have been in circulation since the 80s and by now are usually very stable creatures that are no longer in active development. Our list above names just three but there are many, many native 6502 assemblers to try and use if you choose to go in that direction.
Before finishing our discussion today we should mention an important tool all assembly language programmers should possess called a machine language monitor. The ML monitor is of great use when something doesn't work as planned. It is very helpful to look into memory while the program is running and see if a data value (or any register) is what you expect it to be. An ML monitor can do this for you.
If you choose to develop on the PC and use VICE for testing then you can use the built-in monitor/debugger. It works fine and operates “above” the emulation, so you can literally peer into a program as it executes. Native c64 developers may want to get themselves a hardware freezer cartridge such as Action Replay, the Final Cartridge, or Super Sanapshot. An example of a great software monitor is JiffyMon from CMD. Micromon is good, too. At any rate, have an ML monitor at hand. Great places to find an image of a hardware cartridge or machine language monitor are cbm8bit.com or pokefinder.org.
Throughout this article I have referenced the VICE emulator, so for those who are unfamiliar, VICE is a very good multi-platform emulator of the Commodore line of computers. In particular, the c64 version is rock-solid. SuperCPU emulation is relatively new, but works very well in its current version (2.4.5). I use it every day and love it just like the real thing. Most actual CBM hardware clocks in at nearly 30 years old, and many of the people who worked on or repaired them in the 80s have either passed, retired, or simply moved on, so VICE fills that void very well. VICE can be found here: VICE Emulator .
Well, that will do it for today. We didn't get to any coding, but this was an introductory chapter to be sure. Our next topic in this series will focus on 65x architecture. We will examine similarities and differences between the 6502 and 65816 processors and the parts that make them both “tick.” So, between now and next time, take 'er easy.
Please send errors, omissions, or suggestions to bert@winc64.com or on Lemon64, username satpro.