COMMODORE FREE MAGAZINE

Issue number 9

June 2007


FREE to download magazine dedicated to all Commodore Computers available FREE from www.commodrefree.com


Editor

Another packed issue – although I have had to keep the page count down mainly due to the fact the text will no longer fit on a D64, I don’t want to do anything like compressing the text or creating just D81 disk images as people with only 1541 disk drives will not be able to read the magazine. Also it’s a lot to edit and I am feeling rather unwell this month, flu and a viral infection has put me on a go slow for most of the month, and I feel tired although I am on the mend now.


In this issue I managed to track down WORLDLAM about his efforts to purchase “CMD” from Maurice although it seems Maurice is still quiet. Worldlam seems to have the money and seems genuine, whatever his reasons surely it can only be a good thing cant it?If you buy a SCPU or other CMD product and receive it within 3 months at the same price Maurice sold the products then this must be a good thing, still no sign of my SCPU the order is over 3 years old, when I ordered Maurice assured me that 3 months or slightly longer was all I would need to wait, maybe he meant 3 years not months. – Maurice what is happening WORLDLAM has been aggressive on Ebay buying everything CMD related and other Commodore hardware often for inflated prices; could this just be a late avid collector? See what you think after the interview


David “loadstar” Moorman has been having problems with his house being ripped apart by a Tornado so no part III to the basic programming course; this month although David is keen to restart where he left off. I am sure we all wish him well and hope he and family remain safe, and manage to rebuild and repair their house and lives after the damage.


Magazine has changed a little I removed the reverse block title in the main text, I thought it was using to much ink if people needed to print hard copies, what do you think? Better worse, comments about the magazine have dried up but users are still downloading and reading, basically without readers comments I cant produce a reader comment page.


I still like to receive any reviews links or projects you have seen or are working on, please send in ideas or comments to the usual address


Regards

Nigel

Commodore Free

www.commodorefree.com


Some general information about Commodore Free downloads, taken from My ISP log files


Issue number 8

PDF document downloads 381

TXT document downloads 93

D64 disk image downloads 17 (33 issue 7)


Other downloads

Quick menu total downloads 52

TND tools Disk downloads 33


Thanks to everyone who takes the time to read the magazine.


---


Protovision News May 2007


MMC64 UPDATES

Oliver Achten has done a lot of work on the MMC64: Since MMC and SD cards with a capacity of more than 4GB are already available, MMC64 now supports the FAT32 filesystem. This more modern filesystem also has advantages on smaller flashcards, because most C64 files are so small that FAT16 will only waste a lot of space. The new Bios also made updates on the plugins necessary, most plugins experienced a complete re-write, the old plugins will be updated shortly and can currently only be used with FAT16.The MP3 plugin can now playback whole directories as playlists. The new AVF plugin plays an MMC64 proprietary video format that also utilizes the MP3@64 module. The Picture plugins have also been updated and they are available in version 1.3 at


http://www.siliconsonic.de/t/bin .

An example video file in AVF format is also located there. An AVF Converter for your videos is available as a beta test version.


MMC64 Bios changes from V1.04

Finally, a big update this time:

- FAT32 support! Yes, Oliver managed to squeeze FAT32 support into the MMC64 Bios. Now you don't have to worry about cluster sizes anymore with big memory cards. Currently, cards up to 4GB are supported. Cards >4GB have yet to be released and require a change of the MMC/SD command set anyway.

- New plugin system:

FAT32 support required Oliver to rework the plugin system. When a FAT16 formatted card is used, all plugins work asusual. Using FAT32 formatted cards, old plugins won't work anymore, only new, so called "multifat" plugins will work, which are designed to support BOTH FAT16 and FAT32. With the release of this Bios, most plugins written by Oliver are re-released in the new format.


- Fixed loading of plugins with long filenames

- Fixed support for very small cards.

- Fixed some problems with FAT buffering.

- Fixed a bug in the volume name display routine.

- Instead of showing a computed size value, the browser displays the card's model ID, which always includes the size.


Downloads

MMC64 Bios V1.10: http://siliconsonic.de/t/bin/MMC64_V110.zip


Recovery Disk: http://siliconsonic.de/t/bin/MMC64_Recovery_V110.zip

MMC64 MP3 Plugin V0.70 (requires MP3@64):

http://siliconsonic.de/t/bin/MP3_Plugin_V070.zip


MMC64 Picture Plugins V1.3:

http://siliconsonic.de/t/bin/MMC64_PicturePlugins13.zip


MMC64 AVF Plugin V0.3: http://siliconsonic.de/t/bin/avf_plugin_V030.zip


AVF Testvideo:

http://siliconsonic.de/t/bin/avf_testvideo.zip


AVF Converter betatest V0.02b:

http://noname.c64.org/csdb/release/?id=48707&show=notes


MMC64 VERSIONS OF HOLLOWMAN DEMOS

Hollowman released MMC64 versions of seven of his demos. These demos will now work from MMC64 (even without Retro Replay): WWIII, 26 Kg, Horsing Around, Romeo, Axis of Evil, Axis of Evil 2006 and Axis of Evil 2007.You only need to install the DFI Plugin. When starting, select "Dreamload" and confirm loading the boot file by pressing RETURN.


Downloads

WWIII: http://noname.c64.org/csdb/release/?id=36864

26 Kg: http://noname.c64.org/csdb/release/?id=3015

Horsing Around: http://noname.c64.org/csdb/release/?id=3017

Romeo: http://noname.c64.org/csdb/release/?id=41459

Axis of Evil: http://noname.c64.org/csdb/release/?id=18059

Axis of Evil 2006: http://noname.c64.org/csdb/release/?id=29292

Axis of Evil 2007: http://noname.c64.org/csdb/release/?id=48033


DFI Plugin:

http://developer.berlios.de/project/showfiles.php?group_id=7602&release_id=11984


GUI4CBM4WIN UPDATES

Payton Byrd updated GUI4CBM4WIN, the graphical user interface for the transfer program CBM4WIN, several times. The latest version is 0.6.5. For further information and the download check http://blog.paytonbyrd.com/?p=89 CYBERPUNX RETRO REPLAY ROM WITH CODENET SUPPORTJockstrap released a modified version of Cyberpunx Retro Replay cartridge ROM V3.8p. This version supports CodeNet, the network server known from The Final Replay ROM.Download: http://noname.c64.org/csdb/release/?id=48403


ARTILLERY DUEL NETWORK PREVIEW V0.06

Leif Bloomquist released Preview V0.06 of the Artillery Duel Network. Changelog: Random wind for challenge. The game’s now fun! !Really fixed race condition at end of turns.


Tweaked power settings.

20% damage for direct hit.

10% damage for near hit.

PAL/NTSC detection for music and timing.


Homepage: http://home.ica.net/~leifb/commodore/duel


Download (game): http://home.ica.net/~leifb/commodore/duel/duel006.d64


Download (source code): http://home.ica.net/~leifb/commodore/duel/artillery20070428-006.zip


SEQ PLUGIN FOR MMC64

Triad released a SEQ Plugin for the MMC64. With it you can display SEQ files, which are text files in PETSCII format.So it's really nothing fancy, just something that had to be done.


"In game" keys:

a - abort

shift - pause

shift lock - steady pause

1-0 - speed

<- - fast forward

r - reload file (only works at the end of screen)

space - exit at end of file

iopop must thank Doc Bacardi for the MMC64 libs.

Download: http://retrohackers.org/forum/viewtopic.php?t=254


SINGULAR BROWSER V0.52

Soci/Singular strikes again at Breakpoint 2007 with Singular browser v0.52. Highlights: - supports extended memory up to 16MB (like swap files on Retro Replay RAM, REU, SuperRAM of SCPU, +60K, IDE64 and 1541)


- progressing rendering, it's possible to read the page while loading

- optimized color text rendering

- automatic header redirects

- fixed some bugs in css handling


Other updates are e. g. support of scroll back with cursor keys and detection of page end.

Make Singular browser fit to your needs and download it at the new custom download system. Compiling for C128 is supported as well.Unfortunately, the Custom Download System at http://singularcrew.hu/browser is not currently not available. However, you can find the disk only version at http://noname.c64.org/csdb/release/?id=48032 .


TURBO ACTION ROM V1 FOR RETRO REPLAY

SounDemoN spiced up good old Action Replay ROM with an improved Turbo Assembler that runs entirely out of Retro Replay ROM and utilizes RR RAM for the source, thus leaving the entire $0801-$ffff area available for code! Retrohackers.org Forum topic:

http://retrohackers.org/forum/viewtopic.php?t=249

Download: http://www.dekadence64.org/tar_v1.zip

RAM-RESIDENT TURBO LOADER FOR C128 + RR

FMan released a RAM-resident Turbo Loader for C128 with Retro Replay.This is a disk turbo for 64 mode that resides in the second RAM bank of your C128. Also provides additional features. Included is a stand-alone cartridge ready version. It has been successfully tested on a real Retro Replay This is useful for any Commodore 128 user who frequently loads or develops C64 programs in the built-in monitor. More information and download at CSDb: http://noname.c64.org/csdb/release/?id=48034&show=summary


ONLINE SHOP UPDATE

Our Online Shop got updated: Now the availability of each product is visible. Happy shopping! http://www.protovision-

online.de/catalog


HARDWARE SECTION UPDATED

The design of our hardware section has been improved. Some new content has been added as well. Check it out! http://www.protovision-online.de/hardw/hardwstart.htm

http://www.protovision-online.de


---

The Search Is On For The Next Generation


Although this isn’t Commodore related I though it may interest readers hey its only 1 page


Introduction...

WHAT is The Voyager Crusade?

The concept is simple, it is to design and program an original, innovative, but above all playable game using the technology from the golden age of video gaming. Nowadays game designers have 3d graphics, FMV and surround sound to play with, and too often we see games that look fantastic, but lack that all important holy grail of gaming…playability. This is a challenge to all up-and-coming game designers…show us you can still do it!

The Voyager Crusade is the brainchild of Jonathan Thompson aka “JT”, the man behind the “Voyager” arcade cabinets and game systems . The company supplies game machines to many top retailers, including Firebox.com and Selfridges & Co. The machines are also popular with celebrities, you can find Voyager cabinets in the homes of several Hollywood stars, and David Beckham recently took delivery of his very own custom gold cabinet ! You’ll find Voyager cabinets everywhere, museums, film premieres, exhibitions and more traditional venues like hotels and pubs and night clubs including the well known Cult TV chain clubs “FAB CAFÉ”.


Who can enter?

THIS is NOT a competition to be passed over lightly; in fact if you want exposure for your talents, this is an opportunity not to be missed! The competition is open to amateur programmers from all over the world, however you must be aged 18 upwards! See rules for more information. What will you win if your game is picked?


...First Prize...

IF your program is chosen as the winner you will have your game included on the Voyager Arcade System, so your game will get exposure to a huge audience! What an advert and something to add to your portfolio! You also win a website for you to promote your games on, to other companies and also a customized one off Classic Games Machine designed to show off your games to potential clients. Thanks to Joystick Junkies you will also get a special T-Shirt...This will be one of the top of the range JT Machine Cabinet. Only a few of these top of the range cabinets exist and they are all bespoke designs! A collector’s item from day one. The winners JT Machine Cabinet will also be signed by the man behind Darth Vader’s mask, Dave Prowse and Jonathan himself for that personal touch!To make the deal just that extra bit more exiting, you will also have a launch party put on for you in the heart of Liverpool City Centre, the European Capital of Culture in 2008... TV and Film Stars will be invited as well as special celebrity guests and as prominent game manufactures and designers will be present. Who knows, they might even take your design on further…


...Second Prize...

IF your program is chosen as second place then you will have your game demonstrated at the launch party and also added to the launch party machines so you can show it off to potential clients at the party. You will also be given an opportunity to add your game to the Voyager play lists. Thanks to Joystick Junkies you will also get a special T-Shirt...


..Third Prize...

IF you come third, you will be invited to the party and also you will be given an opportunity to demonstrate your game at the event.Thanks to Joystick Junkies you will also get a special T-Shirt...


...So what is the outline of the rules…?

WELL the game must be retro in style... The game must be simple, fun for all ages and easy to play. Remember the games “Space Invaders”, “Bomb”, “Mr Do”, “Pacman”, “Starwars” and other games like “Spy Hunter”; well these are the types of games we want to see. Simple, fun and nothing special, but it must be your original concept. The games must be programmed to work on a PC Based machine running Windows XP, Graphics must be run in SVGA only, work with Electronic Coin System, 4 way and 8 Way, 3 button, Joystick configuration, 16K Sound and able to run 2 players as well as single player. See rules for full specifications and information...Launch of the entries will start officially in January 2007, but if you are already interested you can email us your FULL name, date of birth, address, your Skype ID and email address. Information will be held under the UK Data Protection Act by both Retro Arcade Machines Ltd. and PCBT Photography and will only be used to send you information packs about the competition and also follow up information about the competition only.


For more information visit

http://www.jt-voyagercrusade.com

----------

Vic-20 Multi-Cart Prototype Project

http://www.bjlyons.com/cbm/vic20/multicart/


Project is based on concept that originated during discussions at WOC show in Dec 2006.This concept became a discussion item on an Internet discussion forum devoted to Vic-20 topics

"Denial" http://sleepingelephant.com/denial The Multi-cart is intended to allow a user to run multiple Vic-20 ROM images from a single cartridge. This design builds on original concept to add features and functions


1. Concept

Allow multiple ROM images to be accessible from single cartridge Reduce physical storage requirements of having multiple carts

Greater portability to take cartridge collection with you when you are on the go

Reduce number of times a cartridge is inserted & removed from Vic-20


2. Project Features

Ability to run up to 255 - 8K ROM based Vic-20 Cartridge games or utilities

Support for 4K, 8K, 12K, & 16K ROM games

Support for all known ROM images, irrespective of location of ROM image in Vic-20 memory map

Toggle from game to menu and back to game again via reset button

RAM expanded mode with additional 32K RAM

28,159 bytes directly available to Basic (3,583 core memory + 24,575 expanded) plus 8,192 bytes addressable by Basic for storage of variables, arrays, etc.

Ability to switch to unexpanded Vic-20 Basic mode without removal of cartridge

System reset via software control or push button switch

Bank switching between RAM & ROM

Expanded RAM may remain hidden from kernel on start up and enabled via software control – no video memory address change from defaults

Software controlled write inhibit logic for R/W line on expansion RAM - no clumsy switches 150+ Games & Utilities currently loaded and fully functional (25% of EPROM capacity still available for further images)


3. Credits

Hardware Design Menu Software Testing

Brian Lyons Anders Carlsson Anders Carlsson Robin Harbron


Hardware Concept & Ideas ROM Images & Organization

Leif Bloomquist Leo – aka KilrPilr

Francois Leveille NBLA000

Mark G. – aka saundby Brent Santin


4. Current Status

Menu under development via project on Denial discussion forum

Updates may be found on Denial –

http://sleepingelephant.com/denial

or Hardware project page http://www.bjlyons.com/cbm/vic20/multicart/


Commodore free Comments

Brian Lyons sent me an email informing me about this project and said if I have free space to include it in Commodore Free magazine, so I did. I emailed Brian in the hope of an interview about the project and an update but haven’t heard anything from him so if you are reading Brian can you contact me again I would love to cover more about this project. Maybe it was just that my emails have been blocked by your spam filters

Thanks commodore Free


Anyone else If you have a project hardware or software let me know so I can tell everyone else about it

Thanks


---


Introduction to various Emulator File Formats

Compiled by: Peter Schepers

Started: Aug 24, 1996

Last updated: Nov 27, 2005


Commodore Free Peter kindly let me reprint 2 articles from his website, other are available and I suggest you study them for yourself, the attached 2 I though were worthy of a reprint


There are always questions asked regarding the various file formats which are commonly used on either the emulators or the real C64. Most often the Question involves conversion... "What do I do with LNX files?" or "How do I make these files work on the C64s emulator?" These documents attempt toexplain their internal structure, what to do with them, and some of their respective strengths and weaknesses.


These documents were compiled and written in an attempt to unify all the other smaller files dealing with Commodore file types that are floating about the net, or that exist with other programs. They are by no means exhaustive (even though they look like it), but attempts will be made to keep them up-to-date, and correct anything which is wrong. If you spot something that needs correcting please make sure to email the author so that corrections can be made for future releases... the address is contained later in this document.

Some of the information contained in these documents may not be accurate as it could have been taken from inaccurate sources, and I have no first-hand experience with said format. However, use these, pass them around, upload them, whatever. Just be sure to leave them INTACT, don’t remove bits.


I have attempted to categorize the filetypes involved using three basiccategories: IMAGES, ARCHIVES and CONTAINERS. The definitions for each of these categories can be found at the bottom of this document.


Also, plenty of good information can be gleaned from the source code contained in the archive CBMConvert, which is on the FTP.FUNET.FI FTP site.Contained in it are the sources for UnZipCode, UnLNX, Ark, some LHA info,etc. It is an invaluable set of utilities put together by both Marko Makelaand Paul Doherty.


So far, this document covers the following files:

* D64 images (1541 disks and some variants)

* X64 images (for the X64/Vice emulator)

* T64 containers (for the C64s emulator)

* T64 .FRZ (FRoZen Files, saved emulator sessions for C64s)

* PC64 containers (P/S/U/Rxx)

* PC64 .C64 (saved emulator sessions for PC64)

* D71 images (1571 disks)

* D81 images (1581 disks)

* D80 (8050) & D82 (8250) floppy images

* G64 images (GCR copy of a 1541 disk)

* D2M images (FD2000 disks)

* DNP images (CMD hard disk native partitions)

* F64 (not an image file, but a companion file to D64's)

* N64 (64NET's custom files)

* L64 (64LAN's custom files)

* C64 (PCLINK's custom files)

* CRT images (CCS64 ROM cartridges)

* 64x (PC64 ROM files)

* TAP images (for CCS64, sampled cassette tapes)

* VSF VICE snapshots (saved-emulator sessions for VICE)

* WAV Audio RIFF files for the PC

...as well as the following native C64 types, some of which are also supported on the various emulators:

* Extensive disk file layout (how files are stored on 1541/71/81 disks)

* 4-file diskpacked ZipCode archives (or .Z64, 4 or 5 files, #!xxxxx)

* 6-file SixPack ZipCode images (or .Z64, #!!xxxx)

* Filepacked ZipCode archives (or .Z64, x files, x!xxxxx)

* LNX containers (LyNX)

* ARK containers & SRK archives (ARKive & compressed ARKive)

* LHA & LZH archives (header description only)

* SFX archives (SelF-eXtracting LHA/LZH)

* SDA archives (Self-Dissolving Archive)

* ARC archives (ARChive)

* ZIP archives (PKZIP)

* CKIT archives (Compression KIT)

* CPK containers

* WRA & WR3 archives (Wraptor, version 1 to 3)

* LBR containers (LiBRary, C64 only, not the C128 CP/M .LBR files)

* GEOS VLIR files (Variable Length Index Record)

* REL files (RELative)

* CVT files (GEOS ConVerT)

* SPY containers (SPYne)

* C128 Boot Sector layout

* Binary & PRG (ProGram, with load address)

Also included is a very basic look at some C64 graphic bitmap formats (in BITMAP.TXT), and the saved session layout of the Macintosh-based C64 emulator "Power64" (in POWER64.TXT). Thanks to Peter Weighill for the aboveinfo. Joe Forster/STA has written up a description of how the various Commodore drives (1541/1571/1581) allocate sectors and directory entries when saving files (under normal mode and under GEOS). It is included as DISK.TXT


Right now there are several good utilities available to work with most of the mentioned formats. The first is 64COPY, my own conversion program. The second is Star Commander, by Joe Forster/STA. Included with his program are many smaller utilities such as Star ARK, Star LHA and Star ZIP, which will convert specific formats to D64 images.


Peter Schepers,

University of Waterloo.

http://www.unusedino.de/ec64/technical.html


---


Terms and acronyms

by Peter Schepers


Many strange terms have come along with computers in general, and I will not attempt to explain them all, but some of the ones in this document may

not be entirely clear. I will attempt to make things a little easier by explaining some of the more common ones.


<CR> - Short form for a Carriage Return ($0D) symbol.


<LF> - Short form for a Line Feed ($0A) symbol.


ARCHIVE - A file format which contains other files, and in which compression is an integral part of the design. Some examples are ZIP, SRK, SDA, ARC, LHA, WRA.


ASCII - This is an acronym for "American Standard Code for Information Interchange". The standard is a 7-bit code covering control codes, punctuation, alphanumeric (A to Z, 0 to 9) as well as math and a few other symbols. Since it is a 7-bit code, it ranges from $00 to $7F (0-127). This leaves the top 128-255 definable by the vendor. The PC world has corrupted this standard making it 8-bit.


BAM - An acronym for "Block Availability Map". Here is where the disk operating system keeps track of what sectors are allocated (or available) for each track.


BLOCK - This refers to sectors which on a logical level are grouped together. On a 1541 disk, it could be a series of sectors linked together in a file, or a partition on a 1581 disk. In the PC world it represents a "cluster” of sectors. Generally if I’m referring to a grouping of sectors thats *not* 256 bytes large, then I talk in blocks.


BYTE - A group of 8 bits, the contents of a memory location.


CHAIN - A series of sectors linked together. One sector will have a pointer to another, and that sector will point to another, until the chain has no more forward pointers. A file stored on a 1541 disk would be considered a chain of sectors, but it also has a directory entry explaining what the chain is for.


CONTAINER - A file format which simply contains other files, and no compression takes place. Some examples are T64, P00, SPY, ARK, LNX.


FILETYPE - In the Commodore world, this would be the kind of file, be it SEQ, REL, PRG, USR, GEOS etc. In the DOS world, this would possibly be the file extension, be it EXE, TXT, DOC. It tells the user what file it is, making usage easier.


GCR - An acronym for "Group Code Recording". This is the encoding method Commodore uses to physically store the information on most of the 5.25" disks (i.e. 1541). It encodes an 8 bit sequence (2 4-bit nybbles) into a 10 bit sequence (2 5-bit nybbles) so that long repeated sequences of 1's or 0's are avoided. These must be avoided so that the timing of reading/writing to the disk won't become "out of sync". As a user, you would not normally see the GCR information since the drive does all the conversion to normal HEX data before it gives it to you.


HIGH/LOW - The bytes here are stored backwards compared to the LOW/HIGH method. See LOW/HIGH for more information.


IMAGE - A file format which is a PC equivalent of a physical Commodore media. Some examples are D64 (1541), D71 (1571), D81 (1581), D2M (FD2000), X64.


LINK - This is the track/sector values, stored in the first two bytes of a sector, which point to (or "link" to) the t/s location of the next sector. A series of these links comprise a “chain” of sectors.


LOW/HIGH - This is how values are stored when they exceed one byte. A good example of this is the sector count of a D64 file. To calculate the actual value, take the second value, multiply it by 256 and add the low value. You will now get the real decimal value. i.e. (HIGH*256)+LOW=result. If you look at is as a HEX value, swap the bytes around and put them together for the 16-bit HEX value. i.e. $FE $03 would be $03FE as a 16-bit HEX value.


LSB/MSB - See LOW/HIGH.


LSU - This is my own acronym meaning "last sector useage". It is the value stored in byte position $01 (the "sector" value of the t/slink) of the last sector of a file. This value is the offset into the sector where the last byte is stored. It also represents the byte count + 1, since a value of 255 would actually mean only 254 bytes of file data exists (full sector less the 2 bytes for t/schain). Without reasonable knowledge of the disk layout, this byte can be confusing, and hard to explain.


NYBBLE - A grouping of 4 bits (half a byte), either the first or last 4bits of an 8-bit binary number, or one half of a two-digit hexadecimal number. Typically, a byte will be broken down into two parts, the top 4 bits and the bottom 4 bits. These are referred to as the upper and lower nybble respectively, and are represented by two hexadecimal digits in base 16.


PETASCII - (or PETSCII) This is Commodore's version of ASCII (the PETpart of the name comes from the first computer to use the code, the PET or Personal Electronic Transactor).Most of the codes from 0-127 are the same as ASCII, but there are differences, especially noticible when converting text from a C64 to a DOS machine. Where ASCII has uppercase characters, PETASCII has lower case ones, and vice versa. Also, the top 128 characters (128 to 255) are quite different from the PC "standard".


RLE - An acronym for "Run Length Encoding". This is a simple compression method, employed by most compression programs, and also used by some file formats (ZipCode, CPK). It encodes sequences (or "runs", hence the name "RUN length...") of the same byte (i.e. 00 00 00 00 00 00) into a smaller string using a shorter code sequence, makingthe resultant file smaller than the original. This is the simplest form of file compression.


SECTOR - It is best described as the method that the drive uses to store the smallest group of bytes physically on the disk. On the 1541 this refers to a group of 256 bytes stored together in a single sector. On a PC disk, this is typically 512 bytes.


SIGNATURE - A group of bytes, usually near or at the front of the file, which are used to identify the type of file. I.e. a PC64 file will always have the signature string "C64file" contained at the beginning of the file.


TAR - An acronym for "Tape ARchiver", a UNIX application, and method of backing up information.


Commodore Free

Reprinted with the permission of Peter Schepers

http://www.unusedino.de/ec64/technical/formats/intro.html


---


Interview with WORLDLAM

A potential purchaser of CMD


Q - Please would you introduce yourself to our reader?


I am 36 years old, married, and have 4 children. I have been a resident of Oregon most of my life. I started getting in the commodore scene back in the 80's when I was a teenager.


I remember at Christmas getting my first Commodore 64 back when I was 15 years old. I stayed up all night playing games. Joining different groups in my local area and staying up on BBS's most of the night I phreaked for a little while when you could get away with it on the Sprint Network to call long distance bbs's without my parents knowing about it. I eventually sold my C64 to get a Amiga and never got into it then I just kind went through my 20's a lost soul partying way too much. Getting married and having children brought me back to reality.


In my late 20's I was going to thrift store's finding old commodore equipment and picked up some basic's and I played for it for a while and lost interest once again. I remember the old days of having meetings at our local community college to swap software and using Fast Hack'em to copy games. Still today I have fond memories of that software. Then about 2 months ago I found Alee650 in the UK that was selling Fast Hack'em and Kracker Jax and it brought back many memories I started buying and then I couldn't stop. Then I met Jerry Kurtz which had the biggest collection of rare games and I started getting back into games again. Remembering Phantasie and Space Taxi from my teeenage years.


Q – What is the term “WORLDLAM” is it your real name or a “handle” what does it mean


It is short for my corporate name for one of my website's. Worldwide Laminate LLC.


Q - You seem to be purchasing everything with a Commodore name on it would you like to comment


I've been buying alot of rare items. I also collect Amiga, Apple, and Atari. My first choice is Commodore 64 of course.


Q - What is all the equipment going to be used for?


My goal is to end up keeping one of each item and eventually selling the rest back to the community. I really want to start playing with eproms and programming them I think it would be fun. I just haven't had the time to it yet. Maybe programming some cartridges as well.


Q - Some users are upset they get outbid on items and you always win can you comment


I sometimes overpay because of my aggressive bidding habits. However, I have always had a winning attitude and don't like to lose on anything. I can't figure out why they get upset as I took a 2 month window on ebay of stuff that has been available for years. I have quit trying to understand why people continue to flame me I just try to ignore them now. It's mainly on the message boards


I have encountered this problem.


Q - Are you just a collector or is this a part of childhood you missed out on.


Collecting items I couldn't get when I was a teenager. Like I said in my introduction.


Q - I find items on Ebay that were never released in the uk or were unavailable is this what your after.


I have noticed where theres a huge demand and whatever get's the most bid activity draws me to the auction. If other's want it really bad then I feel there is a reason for it so I sometimes bid overseas to get items that are rare. I got most of my Commodore Max items in Japan, Commodore 232 in the UK, etc. Where in the USA it's very hard to find them.


Q - Is there an item or items you desperately want and what you are prepared to pay for them maybe our reader could help out.


Part of my collection that I have the most emotional attachment to is the freezer cartridges i.e. Trilogic Expert, Action, Replay, ISEPIC. Eprom programmers i.e. Promenade C1, Merlin, Datel, etc. Fast Hack'em ALL VERSION's, Kracker Jax, Utilities Unlimited, etc. All the hacker tools that were very popular today as they were 27 years ago. You won't find me selling these item's any time soon. The games, computers, etc I feel I could always replace. Besides me and one other collector there isn't much competition on these items so I pick them up pretty cheap. The games on the other hand its very easy to spend $50k and not get much in return. Also hard to resell them and make your money back its a very strange market. One day Space Taxi sells for $520.00 and two weeks later it sells for $242.00 huge price difference.


Q - Can you tell us a little about your Commodore Collection?


Some people on message boards started posting everything I was buying and the pricing I paid which I feel is nobody's business and I was notified from a seller I was being talked about and I went to answer why I was spending so much and buying so many rare items. But the flaming wars began so now I just try to lay low and not say much if I can. Some of biggest money items to date are: Commodore 232 (5 known to exist in the world), 2001 8k Pet Clicket Keyboard (pretty rare in mint condition), 3 Max Computers, about $55k in rare games and then a bunch of misc stuff.


Q - Why Commodore what is the entire Buzz about.


Back in the 80's everyone had a Commodore 64 in their home. We all teased anyone that had a IBM or Apple. It was the machine. The love for them still hasn't died 27 years later. They are the best 8bit computer ever made. Period....


Q - You recently posted that you wanted to purchase CMD from Maurice Randel - do you have a business plan


I emailed him and didn't get a response. I saw a huge demand for CMD products on eBay and they were always going for high amounts. Yet on Maurice's website they are a lot less money. I almost ordered there but read all the complaints on the message board's that he hasn't delivered in a long time. I would need to fly out there and visit with him and see the whole story before I made a decision. There is always 2 sides to every story and I haven't heard his. I have no hard feelings for him because I never dealt with him before and he doesn’t have any of my money. After hearing his side I could create a great business plan to present to him. I have been self employed for many years and know what it takes to run a business.


Q - Have you spoken to Maurice and or do you intent to visit him personally.


I have not spoken to him yet and at this time until I get some of kind of feedback via email I will not pursue this much anymore. Maybe it would be a good time for you to interview him and see what he thinks about the thought of selling CMD and if so I would be happy to re-contact him. I emailed him but will never beg for his business so I will not continue to email him over and over again I feel he will contact me back if its a interest to him.


Q - Would you be prepared to hint at the amount you offered for CMD


Nope. There is alot of factors I would have to see the inventory, his financial books, etc. Until I know the whole picture I would never buy something blind. You would never buy a house without seeing it first, correct?


Q - What did the offer cover Intellectual Property and software or was it the whole company including spares or components Maurice has in "stock". It has not gone this far yet.


Q - Our reader may not be aware of the term IP (intellectual property) can you explain the term


The term "intellectual property" denotes the specific legal rights which authors, inventors and other IP holders may hold and exercise, and not the intellectual work itself.


Q - When you start production - What will the products retail at


I will look at cost's of materials, labor to assemble, packing, and see what the profit ratio is. I would keep the pricing the same if I could.


Q - Will you keep the CMD website www.cmdrkey.com


Yes the domain itself is worth money and everyone knows it by the name. I would never change the domain name.


Q - Will Maurice still do repairs and programming?


I would love to keep him with the team of course. You can't replace his ideas, knowledge, and new product ideas.


Q - What is you technical background in electronics and programming


I have been a PC technician for 8 years. I can fix a PC with my eyes closed. But, anything I am not a expert in I would hire outside help or keep Maurice around to assemble the products until someone was trained or just keep him doing it if he choose to do so.


Q - Will the products be mass produced or do you intend to carry on hand production


I would have to see the manufacturing process to develop a plan to expand or keep things the way they are.


Q - Do you have any feelings for users that have ordered CMD products from Maurice and still after 2 - 3 years still not received any product or refund?


Of course I do. There is a lot of damage control that would need to be addressed but there is also fraud issues where anyone can say we owe them product. There would need to be proof. Credit card receipts, mailing tracking #'s, invoices, etc to address the problems.


Q - Have you looked into the complexity of the products - some of the designs are multilayer boards


I own almost every product I have not taken the time to take them apart. I am sure they are high quality products. My role would be more of a CEO and not the one assembling them I would hire someone that would do this work but I would also hire someone to do quality control and make sure everything is working before it ships out.


Q - Will the designs change, and have you spoken to any Electronics manufacturer about mass production.


If I was buying the business I would have access to all wholesale distributors, sales agents, etc I would ideally call them and tell them I have took over and introduce myself and develop a relationship. I would also take feedback from our customers on what mods they would like to see and if there was a big demand I would see if we could develop it and market it.


Q – Will the products be available to distributors for example “protovision” and should it return “Commodore Scene Import Service”


Distributors are always a good idea as it get's your product to more customers in different country's.


Q - If you were given 1 million pounds what would you do with the money (can be none Commodore related)


A castle what man doesn’t want that.


Q - Is there a question you would have liked to have been asked?


Nope I think we covered it all.


Commodore Free

Thanks for your time and good luck with your purchase.

I open this for discussion in the magazine, would a purchaser of CMD be a good or bad thing for Commodore


---


The Shredz64 Project

By Toni Westbrook


The Shredz64 project is an attempt to build an interface to connect the Playstation Guitar Hero controller (and any other PS controller) to the Commodore 64 computer, then create a Guitar Hero like game on the C64 utilizing the guitar controller.


So far the project has been going well! As you can see, the interface, which I call the "PSX64", is 98% functional (There are some tiny bugs which don't really impact functionality on the whole). Not only are all guitar functions mapped over successfully, but it works great for playing C64 games with a normal dual shock controller. What's more, since the same DB9 port is used, the PSX64 can be used on the Amiga, Atari and Sega Master System (All tested except SMS)..


The Shredz64 game itself is still in its infancy, but progressing nicely.


Most importantly, my journal of latest updates can be found on the "News Updates" page, for those interested. I don't have a ton of free time, but I'm very dedicated to this project, so it will progress, if only just slowly.


Shredz64 News

4/6/07

Lots of very promising progress tonight (and a few nights ago). First off, I implemented code that will read both note data for fret buttons and music data from SID files off of floppy disk. I also wrote some quick utilities on my Linux box to generate note files for testing. So all the static values are out of the program and its reading off files now. More importantly though, I implemented a good portion of the SID -> Shredz64 converter tonight - this sounds much fancier than it actually is. The issue is normal SID files are big blocks of 6502 machine code that have been ripped (or created), but they contain code for manipulating the processor, memory, etc as opposed to just being music data. Not only does this waste CPU time, but its also difficult to switch back and forth between executing Shredz64 code and executing SID code. My solution for now was to hack the libsidplay library on my Linux box, and intercept any memory writes to the virtual SID chip (0xD4XX) and dump the address and the value to a binary file, along with the relative time the memory write was made. E.g. I play a SID file on my computer, and in addition to playing it it dumps all the SID chip data to a file. Shredz64 then uses that file as its music data. Actually, I didn't implement the timing tonight, but I did manually set the timing inside the game just to test it out, and it played the music pretty accurately! Very promising for first try. I do need to compress the files somehow, at least look for repeating sequences, since they get pretty big. Hopefully filesize won't end up being an impossible issue. But hearing music out of the game for the first time tonight sure was awesome!


3/26/07

I added the applause meter tonight that shows how well you're doing overall and how close you are to failing. As can be seen, its a vertical bar separated into three sections, filling from bottom to top. When doing well, the bar fill is green, when okay its yellow, and when bad its red. When empty its game over! (Though I don't have a game over yet). Your applause increases when you correctly strum a note, and decreases if you miss a note or incorrectly strum. I also fixed up some bugs recognizing correct strumming, and separated the code out into multiple files now that things are getting bigger. Next up is reading note and song data from files, and then the SID converter plugin!


3/21/07

I snuck some hours in yesterday before I went to the dentist and worked on things. Shredz64 can now take a (static) list of button data (e.g. buttons to be pressed at what time and in what order) and correctly show it on the screen. For instance, I can encode data that says "A green button should be pressed at 00:00:10, 00:00:20, and 00:00:45, a red button should be pressed at 00:00:10, 00:00:30, etc, and it will correctly show and scroll the sprites on screen. It will also detect if you strum the correct chords at the correct times and increase your score upon success. I've also added a "Shredocity" meter that mirrors the functionality of Star Power in Guitar Hero for the Playstation. I will soon be adding a crowd meter that will determine how well you're playing..


The Shredocity meter is a bit chunky looking right now, I'll be thinning out the graphics.

Overall, things are going really well. The framework of all the controls and graphics are pretty much done, there is only the big project left of incorporating SIDs in as the source of the music, and the smaller task of reading the song data from files on disk. SID music is ironically incredibly hard to work with on a C64 since its just machine code that was ripped from some other program, but I have plans incorporating SID plugins for XMMS to convert it over to a different usable format. More on that later after some code has been written.


3/4/07

Well, I got a few more things done. As I mention on the Shredz64 page, graphics are simple and confined to PETSCII and sprites right now, no high res stuff. I want to save all the processing power I can for good response and music. I'll tweak up the sprites later on, but for now this is fine. Anyway - I have the fret board showing, and button indicators at the bottom. They do respond to the guitar controller now, so if you press a button on the guitar it will light up on the screen. I have the strum bar just playing a beep out of the C64 right now to let me know its working. As can be seen, I also did a simple sprite to represent the note/button as it slides down the fret board.


3/2/07

I had a day off from work today, though I ended up sleeping pretty late and not getting everything done I wanted to. I did, however, build a PC64 cable and get cbmlink installed and running on my Debian box. Now I can successfully read/write files/disk images to my C64 from my PC, read/write memory, remotely execute programs, run disk commands, etc. The reason this is related to Shredz64 is now I can actually test it on a real C64 with the controller as opposed to only the emulator with no controller. The cable isn't too exciting looking to no pictures, but it does operate on a 4-bit parallel connection between the user port and the parallel port, as opposed to a serial connection.


2/27/07

Well, I updated the webpage a bit. Nothing too fancy, but I wanted to clean it up a bit so some sections were separated out. This page will still serve as a log of things I'm doing.


In technical news, I've got some graphical routines done and have a fretboard on the screen with scrolling buttons. Screenshots later when I have something a little more to show.


2/21/07

Lots of good work and news going on with this project, I figured it was about time to actually update this page with what's going on.The soldered prototype for the PSX -> C64 adapter is now done, as can be seen here:


The converter now does the following:


1. Determines whether a normal controller is plugged in or a guitar controller, and maps buttons accordingly


2. Turns on analog mode for guitar controller and successfully reads whammy bar. (Updates later about getting this working for all those interested)


3. Maps Strum up, Strum down, and guitar lift up to static values on one of the POT lines, which allows the C64 to receive ALL information from the guitar (except start and select button)


4. Allows button macros to be programmed onto the R1/R2/L1/L2 buttons in controller mode, up to 127 button sequences PER macro


5. If the user selects analog mode on a normal controller, it will map the left analog stick to the normal digital directions


6. And converts all buttons successfully of course.


After a hefty debugging session, the physical adapter is solid and works great with both a guitar controller and normal dual shock controller. It was amazing to try all my old games with a PS2 controller (as well as some Amiga games and Atari 2600, haven't tried the Sega Master System yet).


Also, I've started writing the actual Shredz64 (guitar hero) game for the C64. I started out with a simple debugging routine to show the status of what guitar buttons were being pressed. Here are two screenshots (literally) of the C64 reporting whats happening on both the fret board and strum bar/lift sensor:


While this program was written in BASIC, the final Shredz64 program is being written in a combination of C and 6502 assembly using the CC65 cross compiler, which I got up and running a few days ago. I'm currently developing in an emulator environment and am waiting for parts to arrive to build a cable to transfer the program to the C64 itself for testing.


Anyway, so much more to come, but things are progressing nicely! I've found out that this project is featured in Engadget which is great, I hope to be making updates more regularly now that I know people are reading. If you have any questions, feel free to email me: twestbrook AT synthdreams DOT com. Huzzah!


1/10/07 - 1/11/07

I recently ordered the arduino development board - it's a programming board for the ATMEGA8 microcontroller with a built in USB interface. It was extremely cheap (~35 for the board, 3 bucks per ATMega8 chip). The IDE allows you to program in C code and upload it straight to the flash memory on the ATMega, which is called by the bootloader on startup. The ATMega8 is awesome for 3 bucks, it runs at 16mhz, has 1K RAM, 8K flash memory, and 512 bytes of EEPROM memory. Great for a project like this. HOW DOES THIS RELATE TO THE GUITAR HERO CONTROLLER?


Well, long gone are the days when a joystick simply put voltage over a line to indicate a button being pressed. This is true on Atari/Commodore/Sega/Amiga controllers, but nothing recent. Back in the day, if you pressed LEFT, a circuit to a specific pin would be completed on the 9 pin connector. Press up, a different pin would be connected. A pin for every button, it was an easy life. But now PSX, XBOX, GC controllers have a billion buttons and only a limited number of lines, so they encode the data into a serial stream of packets, just like if you were sending data over a serial connection or network. In comes the ATMega8 microcontroller. The atmega receives the serial stream of packets, decodes them and figures out which buttons are being pressed. It then drops voltage on corresponding lines to the output to the commodore. But before I did that I had to test to make sure my decoding program was working! THIS WAS A NEAT TEST.


First I took a PSX extender cable:

I opened the male connector and got the pins out. I continuity tested each line so I could figure out which color was which pin. I then connected these pins into a solderless protoboard and mapped arbitrary pins off the arduino board into the protoboard. I also hooked a tiny loudspeaker up to the protoboard too and mapped the arduino into it. The goal to test this guy out was to have the ATMega play sounds on the speaker when I strummed with buttons held down on the guitar.


Then was the task of writing the decoder in C. I found some docs online that describe the protocol the PSX controller uses. It basically consists of sending data over a COMMAND line, listening on the DATA line, manipulating the CLOCK line to drive the data, checking the ACK line for good measure (not really necessary), and dropping the ATTENTION line when it was time to wake the controller up. The prototal was the following. Drop the attention line, Send 0x01 over the COMMAND line to the controller, the arduino should receive 0xFF back on the data line. Then the controller is sent 0x42 which is a REQUEST FOR DATA command, at the same time the controller responds back with what mode it is in (Digital or Analog, mouse or whatever). It then sends back 0x5A to indicate "Here comes the data SUCKA", and then sends 2-7 bytes depending on if the controller is in digital or analog mode. Those bytes contain a bit for each button, either set to 0 or 1 depending on if the button is pressed or not.


It took about two days to get this working, one because I needed to add a 10K pullup resistor across the COMMAND pin as the arduino was polling the controller too fast and the line noise was crapping out any packets I was sending. I found this tip online by someone who had done another PSX controller project. The other was I wasn't reading and writing data properly with the clock cycle, I was doing more on the rise of the clock and I needed to do things on the fall of the clock. It was frustrating, but eventually I got it working. I then wrote a quick program to print out to my laptop (via the USB serial link) what button was being pressed, then I pressed each button on the guitar controller and saw what the corresponding PSX button was. Here's THAT:


Green = R2

Red = O

Yellow = Triangle

Blue = X

Orange = Square

Start = Start

Select = Select

Lift guitar up = L2

Strum up = UP

Strum down = DOWN


I couldn't test the whammy bar out as I know for a fact it manipulates one of the analog sticks, and I don't know the command yet to force a controller into analog mode, so the guitar starts up in digital mode and disables the whammy bar.


Anyway, I got the decoder working, and using the button map data, I created a little program for the atmega that plays a note through the loudspeaker when the strum bar is hit depending on what key combination is held down during the strum. It basically assigns a frequency value to each key, then adds them together, and plays that. It's not aligned to real notes right now, I did it more for just a fun test to actually see the thing working. There really is no other steps between here and hooking it to the commodore 64 other than wiring up a DB9 conector.


That's it for now! Soon the interface will be done and it will be time to start on the game.


The Interface

The PSX64 interface connects playstation controllers to computers that use a DB9 port and C64 pin configuration (such as the Amiga, Atari 2600, Sega Master System, etc). Additionally, if a guitar controller is detected, it will encode strum up, strum down, lift up, and the whammy bar onto the two potentiometer lines of the joystick port. While this extra guitar functionality is usable by the Shredz64 game only (and any future projects), the normal functionality of the PSX64 interface can be used with any game, and works well!


The PSX64 features the following:


1. The aforementioned ability to hook a playstation controller up to a DB9 joystick computer. It maps up, down, left, right and X on the PSX controller to up, down, left, right, and fire on the computer, respectively.


2. If the playstation controller is put into analog mode, it will also map over the left analog control stick to the 4 up/down/left/right directions.


3. On a normal playstation controller, if the start button is pressed, the PSX64 goes into programming mode. The user can then hit L1, L2, R1, or R2, and program up to 127 buttons in for a macro mapped to that button. Hitting start again ends programming mode and saves the macro. These macros are saved in the PSX64's EEPROM and will be retained after power off.


4. If a guitar is plugged in, the PSX64 goes into guitar mode and maps the fretboard buttons into up, down, left, right, and fire. It encodes strum up, strum down, and lift up into one of the POT lines. It encodes the value of the whammy bar into the other POT line.


5. The PSX64 uses a socket mounted ATMega8 microcontroller, flashable with firmware updates with easy to build programmers. It makes use of two digital potentiometers for accurate strum and whammy encoding. It does require a 9v-15v DC power supply to operate.


Shredz64 the game

Shredz64 is (will be if successful!) a game for the Commodore 64 that makes use the playstation guitar controller hooked through the PSX64 interface. It is in the beginning stages right now, with only button testing and some graphics routines done, but is on a steady track. There is a good chance Shredz64 will make use of SID and/or MID files for its music, though with channel constraints,


SID files are more likely than MIDI files off the bat. Some obstacles to be worked through include presentation of music given the 3 voice nature of the 6581 and 8580. Calculation, whether static or dynamic, of fret button mappings to notes as well. Also, efficiency needed for quick polling of the guitar controller.


I'm keeping the graphics very simple, confined to PETSCII and sprites during the early phases, since I want to save all the processing power I can for the music and response. If I have some extra cycles left over at the end, I'll tweak and polish up the graphics. Anyway, you can see the (very) beginnings of how the main screen will look.


Why do it

Ha, this seems to be a question I get a lot. In December of 2006, I attended the TPUG World of Commodore convention in Toronto, Canada, and found hundreds of people still very much interested in the Commodore 64 and expanding its capabilities, even today. I saw some awesome demos of people building network adapters, online games, MIDI interfaces, and other cool stuff for their C64s.


I fell in love with the idea - I love the C64 and I love hacking around with software and hardware alike, so I figured this would be the perfect project! Around the same time I had also read about Jeri Ellsworth and her amazing work and success with recreating the C64, and I was just really inspired all around. If all goes well, perhaps I can present my little project at next years TPUG conference!


Really, when it comes right down to it, I work on "more serious" projects all the time, for my day job, for private contracts, all the time. They pay the bills, and I do enjoy them, but I also like to do fun, wacky stuff. We live in a world where a computer older than 6-7 is considered useless, let alone 25 years.

Well, I absolutely love my Commodore 64, it has a lot of meaning and memories for me, and I love doing fun things with it - and there's no reason why it can't do a lot of cool things, even still. You don't always need a piece of equipment that can perform 4 billion calculations per second, sometimes 1 million is more than enough. Plus, come on, hooking a playstation guitar up to a Commodore 64 is just damn cool. ;)


For more information head over to the SHEDZ64 website http://freedomirc.net/~megaboz/shredz64/


---


Interview with Toni Westbrook

Shredz64 Creator


Q - Please can you tell our reader a little about

yourself


I'm a 26 year old database developer living in a great little city on the seacoast of New Hampshire. I've been a Commodore (and classic computers in general) fanatic since my first C64. I'm a pretty big fan of life in general, and "geeking out" whenever possible.


Q - Please tell our reader about your full time job


I program database and web applications for Concord School District - (Concord is New Hampshire's state capital). I enjoy it as it allows meto work on a wide range of projects. I also run a software development company called Synthetic Dreams in my off hours which specializes indatabase development and neural network simulations. I'm pretty busy in general, but its fun stuff.


Q - How did you become involved with the Commodore 64


My family purchased a C64 when I was about 4, and it (and computing in general) pretty much became the focus of my life. It was the only computer I had until age 12, and I did everything I could with it. That little machine will always have a place in my heart, as corny as it sounds - even though parts are failing now, I'll always keep it.


Q - The Shredz64 Project what is Shredz64,


The Shredz64 project is a (successful now) attempt to connect the Playstation Guitar Hero controller to a Commodore 64, as well as write a Guitar Hero like game using the controller. The adapter I built to connect playstation controllers to Commodore machines I've named the PSX64, and the Guitar Hero like game I've named Shredz64. The adapter is great, as in addition to having extra functionality specific to the Guitar Hero controller, it also allows you to use normal dual shock controllers with any C64 (Or Amiga, Atari, or Sega Master System) game, and allows programmable macros and some other neat stuff. It's great to play old games with the new precision of a game pad.


Q - What would our reader need to try out your project


Currently I haven't released the source code or schematics for the PSX64 adapter yet - I'm waiting for the whole project to be done and all thelittle bugs to be worked out. I'm not an electrical engineer by any means, I have moderate knowledge of microcontroller programming and digital electronics, so even though everything works, I'd like to clean some things up prior to public consumption, maybe get a few opinions of some EE people more knowledgeable than myself. Right now I'm focusing on the game since the adapter is 99% done; I have a target date of being done with eveything by October/November.


Q - our reader may not have heard of the playstation

can you enligten him about the machine


The Playstation (Or more specifically, the PS2/PS3) is one of the most popular consoles on the market, along with Microsoft's X-Box line and Nintendo's GameCube / Wii systems. The PS line is great fun, as imaginative accessories like the Guitar Hero controller, or DDR pads, Or other devices are abundant on the system.


Q - The Shredz64 Project ok WHY ?


I went to a Commodore conference (TPUG's World of Commmodore) in

Toronto last December and realized for the first time that there were still a lot of people interested in using Commodore machines, even to this day. There were just a lot of imaginative things being done, network games and midi adapters and just really cool new uses and ways of pushing theC64 to its limits. Around the same time I had read about Jeri Ellsworth's amazing contributions to the field, and I just got (and still am) really excited that I wasn't the only person who still loved his/her Commodore, and decided that I wanted to actively work on something like these other bright people were. I think Guitar Hero is an awesomely fun game, so I figured there was no reason I couldn't combine the two. Then I realized how freaking cool it would be to play SID tunes with a Guitar Hero controller, and I was off and running. ;)


Q - the website says its about 98% functionlal can you explain what this means


Yeah, the 98% functional part describes the PSX64 adapter. It currently detects if you plug in a normal dual shock controller or a guitar hero controller, and operates differently accordingly. If you plug in a Dual shock, it allows you to assign button macros to the L1/L2/R1/R2 buttons using the start button, and converts L/U/D/R and X over to L/U/D/R and Fire, respectively. It also converts the left analog stick over to L/U/D/R when in analog mode. If you plug a guitar hero controller in, it maps all the buttons over, and also encodes strum up, strum down, lift up, and the whammy bar into the two analog pot lines of DB9 port, which Shredz64 reads. Really, the only thing I want to change about the adapter is protecting the MCU - right now due to a small design glitch, if you plug it into the computer without powering it from the wall, it tends to erase the programming on the MCU. It just needs a few diodes and all will be "perfect".


Q - What other developments are there to be made to the project


The game just needs to be finished. Currently, it draws the fret board, reads note data off floppy disk, glides the buttons down the fret board at the right times, reads in buttons being pressed on the guitarcontroller, increases your score and crowd meter for correctly playing notes, decreases your crowd meter for incorrectly played notes, and reads music (SID) data from disk. It currently plays the music too, but the timing is off as its not done. I need to complete the SID converter/player, and then the Shredocity meter (like star power), menus, general cleanup - add better graphics if there is any processing power left. Its coming along really nicely in general though. I've been programming it in a mix of C and 6502 assembly using the CC65 compiler on my Debian Linux box and a PC64 cable.


Q- If our reader is wanting to become involved in the project what would he need to do to help out


Just friendly words of support are great! I've had a couple people write with some helpful suggestions, or willing to do some graphics, that’s always nice too. Honestly, until it’s in the end phases, there won't be too much need of extra stuff, but until then I like to get notes just to know people are interested.


Q - Will this project be "mass produced" or is it just Designed to be a DIY effort


I haven't really decided about this yet. I will probably release everything as public domain, and then offer to build the PSX64 adapter for a fee. It’s rough with the PSX64 adapter, as if you wanted to build one, you'd need an Atmel Atmega MCU programmer, which some people have, but I imagine many people don't. So those that do could build the interface and download the hex/source for the MCU and burn it on, and those who didn't could purchase it from me. Honestly, I'm not sure yet, but I will get everything out there one way or another! :)


Q - Our reader may be thinking "i have all the parts needed but cant solder" can you provide him with an interface


Thats the other thing, some people aren't big fans of soldering – so yeah, for these people assembling the PSX64 for a fee would work out.


Q - Was this an easy project or did you encounter some unforeseen problems


Parts were easier than I thought they were going to be, and other parts were very difficult. I had a hard time finding documentation about the protocol the PSX controller’s use. There are lots of sites with general information about the pins and basic control codes for reading in directions, but when it came to sending commands to the controller, (eg forcing it into analogue mode or reading current mode, vibration, etc), I searched long and hard until I found it. Converting SID files to something usable in a very controlled application such as this one has been very difficult to say the least too.


Q - Please tell us a little about the design project - How does someone start to create such a piece of Hardware


Whenever I work on projects like these, I just take little steps. With this one, first I created a little circuit and MCU firmware to see if I could read the buttons being pressed on a PSX controller. Then I added to read the Guitar Hero controller. Then I made it play notes on a small speaker. Then it basically just grew and grew until the adapter was fully functional, then I started on the game. Its easy to get overwhelmed, but its fun when you split it into smaller projects, and easier to deal with the frustration when things don't work sometimes (often times).


Q - Are you working in any other projects Commodore or none Commodore


I'm working on a number of non-Commodore projects, but they aren't as fun - mostly database related. I have an ongoing project of building An accurate biological neural network emulator which is one of those lifelong things, I've been doing it for about 10-12 years. AI is another one of those areas that's always interested me.


Q - Do you own any other Commodore Computers apart from the Commodore 64 used in the project


Oh goodness yeah - I collect classic computers. For Commodores, I have my first C64, as well as another C64 and a newer C64C. I have a Vic-20, a C-128, and a SX-64 (great machine). In the Amiga line, I have a A1000, A500, A2000, A2500, and an A1200. I also have a Commodore 286 Special Edition. I have a range of Apples, Ataris and TRS-80s, but the

Commodores are my favourites by far.


Q - Do you actively use Commodore machines


In my work area, I have my C64C and my Amiga 1200 right next to my Debian and Win2003 Server I use for my business. I don't necessarily use them in my day to day activities, but I can't go too long without turning them on and playing some games or just messing around.


Q - Ok I always like to ask “why did you think Commodore went wrong"


I think this is a very complicated question, and I only know what I've read, but a lot of it had to do with people in power like Irving Gould and even Jack Tramiel in the early days to a certain extent. It just seems like Commodore had all these brilliant minds, amazing potential, the power to absolutely rule the entire market, and the people who controlled the money just kept making absolutely bizarre and Destructive decisions. Here was a business that had its own chip making facility, had the #1 selling computer (of all time, to this day), and could have kept going with the Amiga - a machine that was years ahead of its time. It's really sad, and what's even more sad is the revisionist history of Apple being these visionaries and all the rest of the garbage you hear. Most people today think of Commodore as a gaming machine, if they think of it at all. I would love to see a world where Commodore made it.


Q - And " what would you do i you won 1 millionpounds"


First thing I'd convert it to American currency, run my business full time, and hopefully make as big of an impact on the world as Commodore did. :)


---


The HEXFILES part 4

By Jason Kelk


'Ere mister, wanna learn machine code? Well you've come to the right place ain't ya? Yup, welcome to another installment of the Hex Files and, as is becoming fairly common ground now, I'll start off by having a look at the solution to the "challenge" (since some people have said they are too easy) set in the previous installment. If you remember, we had a simple scroll routine and I asked you to move it down a line and change where the data was coming from to $e460. Here's the modified routine:


* = $0900

ldy #$00

main ldx #$00

lda #$fe

raster cmp $d012

bne raster

move_loop lda $0429,x

sta $0428,x ; read/write moved from $0400/1

inx

cpx #$27

bne move_loop

lda $e460,y ; reads the new "text" from $e460

sta $044f ; and this used to be $0427

iny

jmp main


Right, at this point you're all saying something along the lines of "that's all very well, but what good is it?" On it's own not an awful lot, but if you start adding other things to it you get a little demo and that's just what we are going to do. Now I expect you are all wondering how I expect you to be able to understand the code for a demo, right?


Well, it's not going to be a complex demo, just something simple with sprites, a piece of music and a slightly more complex scrolling message than the one above. And you don't even have to type the code in, it's all available to download as we go if you feel lazy! So first, download this installment's sample data, extract everything to the same directory and drop demo_1.asm into a passing text editor so we can have a prod around.


First off, since this is such a large piece of source I'll cover it in chunks and any commands we haven't covered already will be explained on the way past. The first part of the source is responsible for initialization, the setting up of the computer.


scrlcount = $0340

messcount = $0341

sineposx = $0342

sineposy = $0343


sine_curve = $0e00

sine_curve_2 = $0f00


The above assigns the names scrlcount, messcount, sineposx and sineposy to various locations in memory and specify where to look for the two sine curves that are about to be loaded in. Apart from the curves, these are our counters for various pieces of the code and the memory they have been given is part of the cassette buffer so will cause no problems.


.incbin sprites.prg

.incbin sines.prg

.incbin music.prg


These three are "INClude BINary" file commands; they're not 6510 machine code instructions but assembler directives, in other words they tell C64Asm to load those binary files and include them in the final PRG it makes. In this case, they're the sprite definitions (at $0c00 to $0dff)