Recently I thought about Rob Hubbard and his recreation of SID tunes using an orchestra, I also thought back to the “BACK IN TIME LIVE” events I have attended where people and bands like “Press Play On Tape” http://www.pressplayontape.com/ (and of course others) perform SID music tracks on real instruments (guitars, keyboards, drums and added vocals in the case of Press Play On Tape) while both attempts were truly superb, heck we have even had a group at one of the events SINGING SID music accapella (Visa Röster) http://www.livet.se/visa/. I thought wouldn’t it be fun to do this the opposite way around! Maybe take an orchestral score (star wars for example) and rework it to a SID format, (hmmm done before I here you say) Hold on though wait until you hear me out fully.
First you take 16 Commodore 64`s chained together via MIDI with a master machine as the sequencer; then rework the score and play it back using the SID chips of the 16 machines. Now that to my knowledge hasn’t been done before. I did have some success with 3 machines, however the amount of space required for 16 machines prohibits my further experiments (also I don’t have 16 Commodore machines and interfaces at my disposal) but it would make an interesting concept, not sure how well it would work live though, maybe 16 or 32 people could play 16 or 32 commodore’s live using the keyboard from the Commodore “sights and sounds” range now that would be impressive (in my opinion anyway).
I keep thinking of this rather silly idea:
a SID singing Contest where you take 3 people to perform a SID karaoke or SIDaroke, I am sure you can visualise this in your mind right now. Of course this would need to be performed live to avoid cheating and external help from electronic processing etc. I do know some people who can do very convincing saw-tooth waveforms with there mouths. I suppose it’s something I do all the time really (although usually when I am alone)! I will Buzz out a pulse width modulated tone along with the lead sound of the real SID tune usually on my car cassette player (yes I can’t afford a CD player in the car) We could have heats like the X factor, working up to a semi-final and then the grand final with presentations. I wonder if Simon Cowell would be interested in purchasing the idea from me, Of course this would need to be at a reasonable cost? I suppose 100 million pound would convince me to alleviate the copyright from my possession, and a 10% fee on royalties from spinoffs etc.
The thing that re-sparked my interest on these SID related ideas was another 8-bit inspired album this time from the band LukHash you can read about this more in the News section of Commodore Free, where you will find a link to their website that has features a option to download the songs as music files for free. The combination of SID sounds with Rock music, works very well (hmmm in my opinion).
Also in this issue we have an interview with "Gunther Schmidl" who maintains the INFOCOM Documentation Website, the interview did take place some time ago and has taken some time to complete, but that’s the problem with real life getting in the way of projects. This interview was on the Commodore Free back burner for a number of years, and now finally its been checked and included for your enjoyment.
If all that wasn’t enough I have included some information about MINIGRAFIK: FOR THE VIC 20, you can read about the project and the paint package that uses the extensions MINIPAINT, at the end of this issue,
Oh nearly forgot to mention this, Myself Alan Chris and Shaun all met up to mull over some Commodore related ideas and test out the latest Commodore monitor Connection setup. Alan has bee working for some time to get an off the shelf board working, to display Commodore video on a flat panel monitor, to some extent he is successful. However there are some limitations at the moment, but we think these can be ironed out. Although others have attempted this, once working the plan is to purchase in some boards for CCC U.k. and sell them to order, when you see a Commodore 128 displaying 80 columns on a TFT Screen its quite an amazing sight.
Ok thanks for Reading
64COPY is an all-purpose DOS and C64 emulator file manager, modelled after “Norton Commander”, and runs under the Windows XP/2000 DOS VDM, or in real DOS session. 64COPY will run in a Windows Vista 32-bit VDM, but Vista 64-bit has no VDM support at all. It specializes in converting and manipulating emulator files between various formats. 64COPY does not do any communication to the 1541/71/81 floppy drives to read disks. If that is what you need, download Star Commander for that task.
64Copy v4.43 has been released, and is available from the downloads page. The CHANGES.TXT file for this release is very large. I still have not finished the CheckDisk for GEOS disks and VLIR files but this is still planned for a future release.⇧ Back To Contents
PS/2 Keyboard on a PET/CBM
If your CBM/PET keyboard is not working too well. Here is the answer:
A PS/2 interface that lets you connect a regular Personal Computer keyboard (with PS/2 connector) to your PET/CBM. The interface is installed inside the PET/CBM and does not take up any ports, other than an internal expansion power connector. As an added bonus, pressing Ctrl + Alt + Del on the keyboard will reset your pet.
Amiga Virus Encyclopaedia - The Amiga Virus Encyclopaedia has been updated. This web site dedicated to analysis and descriptions of viruses for the Commodore Amiga computer. The database has now information of more than 500 viruses⇧ Back To Contents
VICE v2.2 - VICE is a emulator for the 8-bit Commodore computers. The software can be used on a variety of platforms: Unix, Linux, MS-DOS, Win32, OS/2, Acorn RISC OS, BeOS, QNX 6.x, Amiga, GP2X, Mac OS X, AROS64, QNX 4.x, HPUX, Atari Mint, Solaris Express and SkyOS.
C128 VDC, VIC-20 and PAL emulation.
ReSID's resampler optimized.
SFX Sound Sampler and SFX Sound Expander emulation.
Mega-Cart and Final Expansion cartridge,
paddle and lightpen/lightgun emulation,
userport joystick adapters
A new Dutch Commodore 64 website has been created by Marc Teunissen. This site’s especially for the (Dutch) Commodore Community with a emphasis on the Commodore 64 but doesn't exclude non-Dutch users (who speak Dutch)⇧ Back To Contents
Developer Josef Soucek has announced that IDE64 V4.1 is once again available for ordering.
Go to http://news.ide64.org to read up on the latest news for this well-supported device.
The IDE64 cartridge is a device for connecting an IDE hard disk drive and CD-ROM drive to a C64, and/or it can be used with a Compact Flash card. It is plugged into the Expansion Port and connected to the hard drive by means of a 40-wire cable. IDE hard drive transfer rate is more than 100 times the rate of the floppy drive 1541. The IDE cartridge contains a 128kB ROM (EPROM or flash EPROM with IDE DOS, Machine Code Monitor, File Manager and Setup), a 28kB RAM (used for internal buffers), a real-time clock chip (powered by a battery), two LEDs (to indicate the presence of the cartridge and HDD activity), a Short-BUS for new peripherals, Amiga Clock Port, mini-USB Device Port (PCLink), and an ispLSI chip. Its price is 99 Euros including shipping.⇧ Back To Contents
The Star Commander and the Star Utilities have both been updated to version 0.83. More information and download links can be found at the website.
The Star Commander is the ultimate DOS shell that can handle the image file formats of the C64 Software Emulator (© by Miha Peternel, 1994-1997), CCS64 (© by Per Håkan Sundell, 1996-2009), Personal C64 (© by Wolfgang Lorenz, 1994-1997) and VICE (© by the VICE Team, 1993-2009), it copies files and disks between the PC and a Commodore 1541/1570/1571/1581 drive, optionally in turbo mode, and also converts several popular Commodore archive formats. It is a comfortable, user-friendly and fast giftware software with online help and is very similar to The Norton Commander (© by Symantec Inc., 1986-1995) and The Volkov Commander (© by Vsevolod V. Volkov, 1991-2000).⇧ Back To Contents
While rummaging around various Beta, VHS, Digital 8, and DV tapes, I came across a VHS tape that was given to me. Its label was printed, "Chicago Commodore Expo, October 24, 1998 - Jim Butterfield Tells a Commodore Story". I viewed the tape, and though the video quality is only fair, the audio is good, and of course, Jim tells a good story of the early days of Commodore.
Thanks to BIOS for the upload,
Fresno Commodore User Group
"DEAD PIXELS" is an experimental; fourth long play album from LukHash. A fusion album with an interesting 8bit sounds blended into Rock music. Songs were recorded using real chiptune DMG Gameboys and Commodore 64. online: WWW.LUKHASH.COM Album is distributed free of charge.
In 2009 LukHash began experimenting with original chiptune machines; including the COMMODORE 64 and a couple of modded DMG Nintendo GAMEBOYs to create a blend of original 8bit sound from the 80's and Rock music⇧ Back To Contents
Our Online Shop is available again for a while after being offline for a few weeks in October/November 2009.
1. Distribution is now being done by our new member Stefan Schauf (Doc of Desire). Hence our new postal address is:
Schoetmarsche Str. 25
Our banking details and our PayPal address changed. The means of payment will be shown during the order process and will also be transmitted to you after successfully completing an order.
Oliver Förster (Poison) who took care of Protovision's distribution for over six years, stays member of Protovision and still takes care of organization as well as our website.
2. For orders under 20 Euros we have to charge a low order fee of 3 Euros. Within Europe, shipping is free for orders over 20 Euros. For orders outside of Europe, shipping costs will be charged according to the weight.
3. Because of tax changes, German VAT will be listed from now on. Customers from outside of the EU don't have to pay VAT.
MMC REPLAY is completely sold out. It is still unsure whether there will be another batch of MMCRs. The manufacturer is currently concentrating on the new CHAMELEON cartridge. However, a remaining stock of the RETRO REPLAY freezer cartridge is available again (limited stock!).
The COMPETITION PRO JOYSTICK can be obtained again as well, either as single joystick(s), or in form of the limited COMPETITION PRO 4 PLAYER BUNDLE: 4 Competition Pro joysticks and one 4 Player Interface at a reduced price. The Ethernet card RR-NET is on stock again, too. Did you know? RR-Net and MP3@64 also fit on the new IDE64, available from http://www.ide64.org Last but not least, CARTRIDGE CASES are also available in yellow now!
Almost all titles are available again. The only exception here is NEWCOMER. ULTIMATE NEWCOMER (English and Hungarian version) is still under development, completion is very close! See the updated Newcomer section for more information:
Issue 52 of the Australian based disk magazine VANDALISM NEWS has been released on 31st October 2009 at Syntax Party 2009.
"The Market" chapters contain information about game projects Protovision is involved in:
Leech at: http://noname.c64.org/csdb/release/?id=84122
NETBOOT65 - TFTP, TELNET, GOPHER AND HTTPD FOR THE C64 There is a new release (v1.0.25) of the increasingly inaccurately named NETBOOT65 by Jonnosan, which now includes:
ShadowM implemented IP65 (a TCP/IP stack for RR-Net) into GEOS and wrote a small chat client for it. Look here: http://lyonlabs.org/commodore/geoLink/geoLink.html
The STAR COMMANDER and the STAR UTILITIES have both been updated to version 0.83. More information and download links can be found at the
The latest version of the popular VICE emulator contains support for some 4 Player Interfaces, including the one by CGA (Classical Games) which is being distributed by Protovision. Downloads are available from the VICE homepage:
http://vice-emu.sourceforge.net/ (mind the new URL!).
Commander Laserstrahl is the name of the protagonist of Metal Dust. Some time has passed since his mission within the SuperCPU game. His new mission is to study the earthlings and to explore Planet Earth as a possible "New World". He does this in the form of a radio play in German language, produced by Welle: Erdball. The new double CD of COMMANDER LASERSTRAHL has been released at the end of December 2009. MacGyver/Protovision speaks a little guest role in one episode. Learn more at http://www.welle-erdball.de/commander-laserstrahl/
The Protovision homepage experienced some updates. Find out what is new
in these sections:
Hardware section: http://www.protovision-online.com/hardw/hardwstart.htm
Links section: http://www.protovision-online.com/links.htm
There is also a new pricelist (01/10) available. You can find it here:
http://www.protovision-online.com/⇧ Back To Contents
Dear Sid Fans
We're proud to announce two new lower-cost HardSID products designed for C64 music lovers who want to play back SID tunes, play games on emulators and create C64 tracker music without buying a more expensive SID synthesizer.
The new devices:
Please visit our new products page:
Please send a Tweet about us:
The HardSID Team
Follow us on twitter:
Enjoy over 36000 wonderful C64 tunes in high-quality played back on a real SID chip!
Do you need both old and new SID versions for playback? You need the HardSID UPlay then!
The HardSID 4U is the most powerful SID synthesizer since the legendary C64!
Many PC parts (sometimes the USB controller itself) are generating electromagnetic interference (EMI) which travels through the USB cable into your USB Audio device (HardSID 4U in this case). Even if you use a cable with built-in EMI suppression some of the noise will work its way through to your audio device. So, if any part in your PC isn't properly electromagnetically shielded, the EMI noise will be audible when low level audio is played. EMI noise can not be perfectly removed by any suppression method except by expensive physical separation of circuits connected to the PC from the audio circuits.
Suppressed EMI noise is still perfectly acceptable for hobby usage, but if you're planning to record your work/art in studio quality, you should consider going for the HardSID 4U Studio Edition, since it physically separates your audio circuits from the ones connected to your PC. We're using expensive technologies to replace direct electrical contacts between the PC driven circuits and the audio circuits.
Just wanted to let all of you know that I FINALLY created a WORKING PLA Replacement for my C64. I have only tested it in one of the Breadbox C64's so far.
I use Ray Carlsons Diagram,
latest updates and corrections 11-20-07
The supply of replacement ICs for Commodore computers has been shrinking since Commodore stopped making chips more than a decade ago. Most of what you find now are used "pulls" from existing equipment, some good, some bad. The most common failure in the C64 has been IC U17, a pre-programmed 28 pin generic 82S100 programmable logic array or PLA. That IC normally runs very hot and should have been heat sinked. It was in later versions of the 64. Since the supply of obsolete unprogrammed 82S100 ICs has likewise dried up, a way to replace the Commodore PLA with some other kind of device has been discussed many times on the newsgroup comp.sys.cbm and elsewhere. A 64K EPROM programmed with the code from a working PLA and rewired via a circuit board or other adaptor to cross-connect a few pins has had some success in duplicating the logic of the original PLA. There are several different versions of this modification on the internet. Note that the code for the EPROM must match the pinout of the adaptor that goes with it! The modification I found takes only a few pin swaps to make it work. The other one takes more. Guess which one I chose to use? ;-)
With a "burner" on my PC, I began experimenting with various types of EPROMs when my stock of PLA chips was depleted. The original PLA averaged a rather speedy 50nS. The best information I had early on was that a very fast IC was needed to simulate it. Most reprogrammable UV EPROMs are much slower at 150 to 300nS and I already had some of those. A one-time-programmable (OTP) Atmel AT27C512R45 seemed fast enough with its 45nS response time and they were cheap at the time, so a batch of the OTP chips was purchased and some adaptors made out of "sandwiched" IC sockets. One adaptor was needed to extract the PLA code and get it into my computer, and another adaptor to make the programmed EPROM work in the C64. I'm putting up both adaptor schematics and the code on my site if anyone wants to make their own substitute PLA. The resulting replacement ICs do work in many C64 boards but not in others, even ones with the same board number. Now to the reasons...
One of my C64 boards (250407) will work with just about any PLA substitute EPROM from the slowest 250nS to the fastest OTP. Other boards are -very- fussy about the replacement PLA. Results with those boards varied from blank screen to less than the normal bytes free at startup to random character colour errors or program crashes... common indicators of a failing OEM PLA or bad RAM. The sub-PLA could be made to work in some boards by replacing the VIC, the MPU and/or the CIAs. For example, a CPU with a later code date worked in a board with a sub-PLA whereas the earlier CPU chip wouldn't even boot up (blank screen). My oldest 64 board, a 1982 326298, gave me the most trouble. Most of the chips in it are early versions. Swapping some of them out with newer ones made that board work fine.
The original RAM ICs Commodore used were either 150nS or 200nS. RAM chips of a certain speed may work with the original PLA but not with the sub-PLA. In one experiment, a sub-PLA worked with all 200nS RAM, then one 150nS RAM chip was substituted, and the bytes free at startup was reduced although the original PLA worked fine with that arrangement. I conclude that C64 ICs work within a narrow "window" of acceptable pulse timing, neither too fast nor too slow. The use of a substitute PLA in some boards obviously creates timing errors, some fatal (blank screen) and others producing subtle screen "glitches" and program crashes.
If an EPROM works in a particular board, that's fine. But, what do you do if no sub-PLA seems to work? One workaround I found was to add a small capacitor (one end tied to ground) to the replacement IC output pin 18, the \CAS line to the RAM, which adds a bit of delay to those pulses. I experimented with values between 50pF and 220pF and got good results. The bottom line here is that whatever board you have may or may not work 100% with a sub-PLA. It may need to be "tweaked", and most users will not want to do that. So, a drop-in replacement for the original PLA that will work with all boards without any problems is still unavailable.
When I repair a C64 that needs a replacement PLA, I can make the sub work in most cases with chip swaps, selecting an optimum speed of the substitute EPROM and/or by using the time delay capacitor. Testing the final product involves 1. observing the bytes free on the opening screen to see if it's normal, 2. looking for "glitches", random colour shifts or odd characters anywhere on the screen while a program is running, 3. testing with several different cartridges such as CBM Jupiter Lander (which refused to load in one board when everything else seemed to work) and a passing grade using the C64 diagnostic cart some kind soul gave me years ago.
Making the substitute PLA is pretty straightforward. With a few pins rewired via an adaptor (schematic is readpla.jpg) I made with two "sandwiched" IC sockets, I used my ERPOM burner to copy the code from a working PLA chip. The burner reads it as if it were a 27C512 EPROM and the resulting file pla.bin has a checksum of hex DAA0. That code was burned into a standard 27C512 EPROM. I then used another cross-wired adaptor (schematic is eprompla.jpg) to install the EPROM in my C64. The files mentioned above are on my schematics website at http://staff.washington.edu/rrcc/uwweb/eprompla/
One last thing... replacing a PLA with an EPROM in an adaptor socket that plugs into a board-mounted IC socket may cause intermittent operation if the board socket has loose contacts. One way around that is to use an adaptor socket with round pins that are thicker than the standard replacement types. Of course the mod PLA socket can be soldered into the C64 board directly. It's likely to be the last time it will be replaced anyway... as long as it works correctly the first time it's installed. It doesn't need to be heat sinked like the original PLA should have been... the new chip runs cool.
Much appreciated for the info Ray.
Since I'm using a Promenade C1, I had to break the file into two 32k sections as there is NO WAY to program an entire 64k file with a Promenade C1. Each file will need "00 20" inserted into the Beginning of the file, they will be 32770 bytes in size.
In order to program a 27c512 EPROM. BEST to use -45ns for the PLA. you will have to run a ground wire from the CASE of the Promenade C1 to PIN #1 on the IC. This will allow you to program the FIRST HALF (32k) of the EPROM. Remove the wire to program the SECOND HALF of the EPROM.
I am using Promshell to do this. You can find the disk on my FTP site : ftp://www.n2dvm.com//Commodore/Programs/Eprom/promshell.zip
Here are the files I used for the PLA. They already have the "00 20" added to them to make it easier on you.
Have fun.⇧ Back To Contents
Q. Please introduce yourself to our readers
My name's Gunther, I live and work in Austria - unsurprisingly, in programming. I'm a big fan of adventure games, both text and graphical, and I've written a few text games myself. These days, free time doesn't really permit authorship, so I'm playing and occasionally reviewing adventures instead, though I'd like to dabble in some authoring again. I'm also interested in the history of Interactive Fiction, and have managed, with the invaluable help of people like Stephen Granade and Graham Nelson, to unearth several obscure games and bring them to a greater public.
Q. Are you an Infocom fan in general or do you have a bias to a particular machine, I know we are Commodore users but we wont be mad if you preferred another system
I'm an Infocom fan in general. I actually grew up on PCs - our first computer was an insanely expensive IBM laptop with two 3.5" floppy drives and no hard drive - and the first two games I played were Space Invaders and Space Quest 2. Friends of mine had a C64, an Atari and an Amiga, so all the "big" home computers were available to everyone. Naturally, I still have an affinity for the PC, but I know my way around the other machines as well.
Q. Do you own any Commodore systems?
Only in emulation, I'm afraid. Like I said, I know a bit about both AmigaOS and C64 BASIC, so I can get stuff running, but I rarely do it these days.
Q. Did you ever finish any of the Infocom games yourself, and if you did; did you need to use hints?
I finished most of them, with the notable exception of Journey, but few without hints. I managed to finish SUSPENDED, and got a horribly bad result, but it was the first I actually finished by myself.
Q. What's your favourite Infocom puzzle?
Hard to say. One of the most well-executed puzzles is the Babelfish puzzle in The Hitch-Hiker's Guide to the Galaxy, but I can't actually call it a favourite. I think the time travel puzzle in Sorcerer was pretty good, if extremely hard. LGOP's T-Remover is also fun.
Q. Do you think text-only games are better at stimulating the imagination?
I think both text and graphic adventures have their merits. Text can, of course, do things that non-text can never convey (the famous "voice of honey and ashes"), and are more precise ("what is that four-pixel object on the screen supposed to be" was a common question in parser-driven graphical adventures until pure point-and-click games took their place -- where after pixel hunting became the new guess-the-word). Graphics are easier to convey exactly what the author wants to show, but you couldn't pull off things like surprise the player with a character's gender/race/... as easily.
It's easier to have mimesis-breaking puzzles in graphic adventures, I would think -- to implement a Fifteen puzzle or Towers of Hanoi in text would be more work than it's worth (though the 15 puzzle has actually been done). Text adventures had hunger and sleep daemons, turn limits, and mazes. Graphic adventures have arrange-these-items-in-the-correct-order puzzles, timed sequences, and mazes. The medium dictates what you can do to annoy the player :-)
Q. Were the games all text based or did some graphics scenes exist?
Most of the Infocom games were all-text, but they did produce a few games with graphics: Beyond Zork had a graphical mode where it would display a map of your surroundings, and a special rune font. Zork Zero, Arthur, Shogun and Journey had illustrations and graphical puzzles (Towers of Hanoi, Nim, etc)
Later a few mostly graphical games (including two adventures, "Return to Zork" and "Leather Goddesses of Phobos 2") were released under the Infocom label, but that was after their acquisition by Activision.
Q. Do you think Graphics from adventure games detracted from the gameplay?
Graphics pretty much started out as illustrations of the scenes, as in Sierra's "Mystery House", the first graphic adventure. What they did do was dumb down the parser, so you'd have to guess from the line drawings what object, exactly, you were seeing on the screen, and then issue two-word commands and hope the parser would understand you. Thus, yes, the games interrupted play, pulling the players out of the
game world, by throwing "I don't know what you mean" messages at them. This problem was mitigated by going point-and-click, however.
Douglas Adams later made Starship Titanic, a full graphic adventure which was advertised as having an intelligent parser to let you communicate with the denizens of the ship. Let's say it wasn't very intelligent after all and leave it at that.
Q. Do you still own any boxed Infocom games, with their "feelies" can you explain about the "feelies"?
Feelies were (and are, sometimes!) a way of getting people to buy, instead of pirate, the games.
One, you'd get a nifty box with, for example, a glow-in-the-dark stone, a rubber centipede, some "gemstones", booklets, or "hieroglyph rubbings", etc.
Two, in later games, material from the game box would actually be needed to pass copy protection in the game. A game might ask you to type in a word from the manual, or set a code wheel to some specific position and type in a number from it, or answer a question to be learned from the feelies, etc.
I've managed to come into possession of several games with their feelies -- it's just nifty to have something tangible along with the game itself. Shows the extra effort the company spent to immerse the player in the world. Plus, hey, piracy protection. Which worked about as well back then as it does now.
Q. I presume these games are highly collectable, what are the top 10 most valued games?
Top ten is hard to say, but by far the most collectable items are the original Starcross "Saucer" packaging and the original Suspended "Mask" packaging. They often go for several hundreds of dollars on eBay. Everything else is way more commonplace, except the oddball games like "Fooblitzky" or "Quarterstaff" (a Mac-only RPG), and the
product that caused the downfall of Infocom: their database system "Cornerstone".
Q. Ok there must be at least one duffer what is the worst Infocom game you played and why was it so bad?
My two least favourite Infocom games are "Beyond Zork" and "Journey". The former is an adventure-RPG hybrid which does neither part very well; the latter is a glorified choose-your-own-adventure-style game which has endless possibilities of getting you stuck at the very last puzzle because you run out of something you need much earlier. Like I said, I never completed it myself despite multiple attempts.
Q. Recently, memos and e-mails about a possible Hitch-hiker's sequel were made public. Do you think it could have been a success, and do you think the company information should have been revealed?
With the built-in audience for Hitch-Hiker's, I'm pretty sure the game would have been at least a moderate success. I don't know if there were plans to add graphics to it, but probably yes - I think that the kind of graphics available then would have worked against the HHGG world. There's a reason why the books and radio series were vastly more successful than the TV series and the later movie.
As for the infamous "Infocom Drive", it is sad that the information was revealed the way it happened. I'm sure nobody wants to see their dirty laundry aired in public, and I'm also sure that because this happened, it will be much harder to get actually interesting stuff out in the public - you don't antagonize the people you depend on for goodwill.
Q. Are there many documents/manuals that you are still looking for? And Can you give or readers a plug about the website?
We have a full set of the available Infocom documentation. Unfortunately, Infodoc has not been updated in a long time due to time constraints by Roger J. Long, who did the majority of the work, and myself, and thus it has been surpassed in some ways by other websites, most notably http://infocom.elsewhere.org/gallery /
We do still, however, offer fully OCR'd (and a few 100% screen-reader-friendly) versions of the manuals, with all the important information, as well as a number of neat things not readily available elsewhere, such as a full set of the company newsletter sent out to customers, information on the Japanese version of Zork 1, and a few other surprises.
Q. How was all the information collected to the site?
The manuals were readily available in PDF format from the Masterpieces of Infocom collection. Other material was scanned or photographed and OCR'd (or just typed in). We cleared the rights with Activision, who gave permission readily. We didn't hear back from the rights holders of HHGG and Shogun, which is why those manuals are not available.
Q. If our reader can help out or wants to help what do you need or want?
If anyone wants to take up the transcription of the manuals into screen-reader friendly format, they are welcome to do so; I don't think, however, that much is going to happen with the site in the future. It mostly stands as it is, and is hopefully useful to people.
Q. How many Infocom games were released in total?
http://infodoc.plover.net/goodies/files/gamelist.html has a full (but now out of date, due to the discovery of the Drive) list of all the released games by Infocom. Infocom released a total of 36 text adventures.
Q. Was there a fan base with newsletters for the games?
There was the official company newsletter, The New Zork Times (later renamed to The Status Line after the New York Times complained). There were also unofficial fan clubs, and these days there are, of course, multiple fan websites.
As an example of the dedication of Infocom gamers, consider this hand-drawn map of Dungeon, the predecessor to Zork 1-3: http://almy.us/image/dungeon.jpg
Q. Were there phone lines providing hints and tips?
Involuntarily - people called the Infocom office for help and hints. The Zork User's Group (ZUG) was created to handle these calls on a pay-per-hint basis. This eventually led to the creation of Invisiclues, the hint booklets in invisible ink, to take some load off the poor employees.
Q. Do you know the shortest time it took to complete on of the games ?
Q. Is there anything else you would like to add?
Thanks for the questions, and thanks for your patience.
I left my house and drove down to Preston Train station, shortly after my arrival I met Shaun Bebbington and Chris both Commodore Computer club U.k. Members www.commodorecomputerclub.co.uk we exchanged greetings then all boarded my car and set off to Alan’s house. Intense fog, roadwork’s and sheer amount of traffic meant the going would be slow, but eventually we arrived, parked up and were greeted by Allan.
The first order of the day was a strong cup of tea, and then after a brief tidy up! Allan invited us into his Den of computers. Now I have been to Allan’s on 2 other occasions, but this time marked a new and cleaner Computer room (actually a converted garage); Allan said he was installing more storage and shelving so to excuse the mess (although it was scarily tidy, every paper filed neatly away; and every disk labelled and stacked in place; even nuts bolts and screws found there own storage boxes and a shelf to house them in).
Moving further into the garage I was greeted by an almost complete looking Dalek scarily pained in grey like it had come out of a mould and was getting prepared for world domination or some such similar event; maybe like scaring small children. In the picture you can see how truly evil the machine is, without power and a full armourment its still intent on attacking a florescent jacket. If you want to follow the Dalek project you will find it here http://commodorescene.servebbs.org/dalek.html
Allan said he was still working on his Commodore setup but did have his Commodore 128D with SCPU, RAMLINK and Cmd hard disk setup all connected to a Flat panel TV, So this begs the question “Allan did you get the A-22 Board Working? Allan’s reply was “sort of have a look”
Although the picture wasn’t truly accurate, (colour problems) it was good enough to use and stable, as can be seen in the screen shot (sorry it’s off my phone I didn’t take my camera; although it does show a very clear image.
You can also see a picture of the A-22 board Allan has spent time adapting to get the full colour display of the 128 and a stable picture, so the colours are not all bleached out. I see in some forums the users seem to think the board can be purchased and used as is, the problem is this isn’t a perfect picture, especially if you want to use Geos and Wheels.
Now booted in 80 column mode glory was a 128d with a TFT screen, Allan then booted the wheels operating system (and updated version of Geos) and the screen sprang into action again, very clear and usable although there were some problems like the mouse pointer colour, although still usable it tended to blend in with the background on some areas of the wheels desktop (so the board isn’t just plug and play as some forum members suggested). Allan booted up Post print and as you can see it worked perfectly with all areas of the screen visible and clear and in full colour.
The quite remarkable thing about this was that the demo “Risen from Oblivion” ran without a hitch, although the colours were not 100% accurate but without this machine side by side to one running the demo on a commodore monitor it would be hard to spot, and the demo did still look impressive.
If you can’t get the demo to run try watching the demo on the YouTube link, Although the Demo will run under Winvice the timing is incorrect (I think the Winvice emulation of the 128 is limited to 1mhz) and so some of the effects don’t work properly, especially the end picture again this must be the emulators limitation, the problem is the final picture is well worth seeing and a main part of the demo (in my opinion). Still a very impressive demo, even viewing it after all this time from its initial release. The link is for version 2 of the demo.
The demo itself needs some bizarre hardware to actually run in the real world so we were quite surprised it; firstly ran and secondly that it didn’t look to bad on the screen (again apologies for the poor screen shots from my Camera phone)
Next we decided to re-visit the networking of a Commodore 64, Shaun suggested we test out GEOLINK, http://www.lyonlabs.org/commodore/geoLink/geoLink.html for information; this software was written by ShadowM using the IP65 network stack and runs under GOES, with the server version running in Java on a remote machine, although still in an early form, the software has been tested with RR-Net, MMC Replay, FB-Net, 1541 Ultimate, and 64NIC+ network cards. We very easily obtained via a DHCP router an IP address and were able to test logon to the remote server, and even ping domain names, the Application comes on a customised GEOS disk (downloadable from the website) boots on a c64 with a 1541, we tried running the software on Allan’s 128 setup but it didn’t seem to work so we downgraded to a Commodore 64 and 1 disk drive and a network card; although still in an early release the demo is quite impressive stuff. I hope this application evolves into a real set of networking tools for Geos /Wheels users, something sadly lacking from such a setup.
From Allan’s router we could see the Commodore 64 machine on his home network and even ping the commodore 64 from a pc, the software with the aid of the DHCP client is so easy to use and takes any confusion from the user who is new to networking and or IP addressing, filling in IP address, Subnet mask, gateway and DNS server settings.
Of course no meeting would be complete without some for of game play and this was in the form of Richard Bayliss`s “sub Hunter” Possible Richards finest work to date. After a quick dance around to the music, we took turns, sadly no one completed the game on this session though.
All to soon my day pass ran out; and With regret I had to leave Allan and head back to the motorway, although it was rush hour when I left, and the road had a large number of roadwork’s, I made it quickly back home, drank a cup of fruit juice and went to bed.
At this mini meeting various CC U.K. problems were tried to be resolved like banking issues and I asked for a list of stock to sell via Commodore Free magazine. (Allan is compiling a list of items the CC U.K. shop has. Hopefully this will be included in this issue maybe.) One thing that was causing confusion was the membership, its quite confusing with the various options 6 months 1 year and life so we decided that we should just have one option that of life membership for £30. Also we suggested a “crap game competition” More on this when details arrive.⇧ Back To Contents
This is a short expose introducing MINIPAINT, and its accompanying BASIC extension, MINIGRAFIK:
I'd like to introduce two programs designed for doing high resolution graphics on the VIC-20: MINIGRAFIK, and MINIPAINT.
MINIPAINT is an editor for a 160x192 pixels graphics mode, and MINIGRAFIK is an accompanying extension for CBM BASIC. Unlike to the Commodore 64, where the VIC-II chip provides a dedicated graphics mode, on the VIC-20 there is only a text mode available. However, the character definitions can be placed into RAM, and by "painting" the text screen with unique characters, it is possible to set up a bitmap.
Only the internal memory is accessible to the VIC-I, and the layout of the bitmap has been carefully chosen to only allocate the upper 4K. A RAM extension is required, at least 8K for MINIGRAFIK, and 16K for MINIPAINT. The zeropage is untouched, and so both programs are compatible to KERNAL, and CBM BASIC.
The main screen of MINIPAINT shows three windows. All edit operations are done in the first - largest - window, which shows a zoomed view into the picture. This window is overlaid by a dialog box, when you invoke the help screens, or want to access storage media. A second window, and third window show the same view in original size, and additional status information. Pressing the SPACE key toggles between editor, and a full-screen preview.
MINIPAINT, and the stored picture files are compatible to both PAL, and NTSC. The pictures can easily be used by your own programs in BASIC and machine language. For BASIC programmers, the MINIGRAFIK extension provides powerful commands for loading, saving, and manipulating pictures in this file format.
There are some projects where these two programs already have contributed to: VIC=toria Gold Edition, a strategy game set in the times of Ancient Rome, some of the graphics in Realms of Quests III were designed in MINIPAINT, and quite recently 'Island of Secrets' has been re-released with additional graphics.
I hope to have piqued your interest, and maybe yours is the next program or game to use bitmapped graphics on the VIC-20 with MINIGRAFIK, and MINIPAINT.
Here's MINIPAINT, a pixel-oriented editor for MINIGRAFIK bitmaps:
The main screen is divided into three windows:
Within the editor:
Within the load/save dialog box, DEL deletes the last char, RETURN starts the load or save, and f7 cycles through the devices 1, and 8..11:
Further plans mostly concern the completion of the batch processing suite. MINIPAINT as such is feature complete. Version 1.2 fixes some small issues in the directory display.
The batch processing suite makes use of MINIGRAFIK to convert PGM files into MG format, export MG files to Koala bitmaps, and convert to and from charset binaries (1K or 2K) at 4096, 5120, 6144, and 7168 - thus transforming MINIPAINT into a comfortable charset editor
Here's King Tut, pixeled with MINIPAINT
I used a suitable cropped, and re-sized photo, and a variant of PGM import to obtain a first workstage in white, light orange, orange, and blue. The lower part of the snake (in cyan), and the black shades were added in MINIPAINT.
Outside MINIGRAFIK, or MINIPAINT the file must be loaded ,8 (not ,8,1!), and then RUN. You'll need at least an 8K RAM expander to view the image this way.⇧ Back To Contents
New version 4.02 of MINIGRAFIK!
<...> denotes parameter expressions
[...] denotes optional parts of a parameter list
@ON initialises the 160x192 pixel graphics. The screen is recentered correctly regardless of MINIGRAFIK running on a NTSC or PAL VIC.
@CLR clears the hires screen. Furthermore the Colour RAM is initialised to the foreground colour.
@RETURN returns to text mode. If an error occurs during program execution, this command is executed on your behalf before outputting the error message.
@<colour>,<x>,<y> [TO <x2>,<y2>]
Draw line in <colour> from (<x>,<y>) to (<x2>,<y2>). If the TO part is omitted, a single point at (<x>,<y>) is plotted.
<colour> denotes a logical colour. <x> and <x2> may range from 0 to 159, <y> and <y2> from 0 to 191. The origin (x=0, y=0) lies in the top-left corner. All arguments can be written as numbers, variables, or arbitrary numeric expressions.
In High-Resolution mode (M=0) the allowed logical colours are:
0: clear pixel to background colour G
1: set pixel in foreground colour F
In Multi-Colour mode (M=1) two extra logical colours become available:
2: set pixel in border colour B
3: set pixel in auxiliary colour A
In Multi-Colour mode the resolution is halved, so that when <x> is even, <x> and <x>+1 address the same pixel.
The foreground colour (F=0..7) and Multi-Colour enable (M=0..1) are set individually for each 8x16 pixel cell. The background colour (G=0..15), border colour (B=0..7), and auxiliary colour (A=0..15) apply to the whole screen.
To assign a physical colour to the logical colours, issue the following POKEs:
POKE 36879,16*G+8+B (set background, and border colour) POKE 36878,16*A (set auxiliary colour) POKE 646,8*M+F (set foreground colour, and enable/disable MC mode) Physical Colour Table: 0 Black 8 Orange 1 White 9 Light Orange 2 Red 10 Light Red 3 Cyan 11 Light Cyan 4 Purple 12 Light Purple 5 Green 13 Light Green 6 Blue 14 Light Blue 7 Yellow 15 Light Yellow
@SAVE [<filename> [,<device>]]
Save screen to device. A device-number greater than or equal 8 addresses the disc drive. In that case a filename must be given.
If the device-number is omitted, or equal 1, the screen is saved to tape. @SAVE without any parameters saves an unnamed screen to tape. A tape save notifies the user with a border flashing black/red to press RECORD & PLAY on the tape drive. When the save has completed, your program continues execution.
The file contains a stand-alone display routine, to view the image via LOAD and RUN without MINIGRAFIK in memory. If MINIGRAFIK is loaded, use @LOAD instead, inside a program.
Memory Map: MINIGRAFIK MINIGRAFIK active not active $1000-$10EF char map, not saved $10F0 free $10F1-$10FD $1201-$120D 2008 SYS 8584 $10FE $120E VIC register 36878 value $10FF $120F VIC register 36879 value $1100-$1FFF $1210-$210F bitmap $2000-$2077 $2110-$2187 colour RAM, compressed $2078-$20EF $2188-$21FF stand-alone display routine
@LOAD [<filename> [,<device>]]
Load screen from device. A device-number greater than or equal 8 addresses the disc drive. In that case a filename must be given.
If the device-number is omitted, or equal 1, the screen is loaded from tape. @LOAD without any parameters loads the next screen from tape. A tape load notifies the user with a border flashing black/green to press PLAY on the tape drive.
When the load has completed, the image is displayed on screen, and your program continues execution after the @LOAD command. There is no wait for a key press.
DO NOT load anything else than a @SAVEd screen with @LOAD!
This function returns the logical colour at (<x>,<y>). <x> may range from 0 to 159, <y> from 0 to 191. Both arguments can be written as numbers, variables, or arbitrary numeric expressions.
For a High-Resolution 8x16 pixel cell, the function returns 0 for background, and 1 for foreground colour. If the cell is Multi-Colour and <x> is even, then <x> and <x>+1 share the same logical colour, and you must be prepared for the function to return values from 0 to 3.⇧ Back To Contents
Q. Please introduce yourself to our readers
A. Hi, I'm Michael Kircher, 37 years old, and working as electrical engineer in Nuclear Fusion research. I'm posting as 'Mike' in the VIC-20 Denial forum. When I don't use my spare time for programming, I enjoy swimming, cycling, photographing, construction of models, and playing a good game of chess.
Q. What is your first Memory of computers and Commodore?
A. I became interested in computers at quite an early age, when I could try out my uncle's ZX81 in the summer of 1982.
The most fascinating thing for me at that time was, that a TV set actually could display something different than the normal TV programme - something one could think out oneself. I had been tinkering around with electronic kits already for some time then, having built an AM transistor radio at the age of nine. I really didn't focus on Commodore until I got my first computer.
Q. What was the first Commodore Machine you owned, and did you progress through the C64 and onto the Amiga?
A. My first computer was a German Commodore VC20, as a Christmas present in '83. Even though it was considered as family computer at first, it was soon monopolised by me. Intrigued by those strange DATA statements full of numbers in BASIC type-in programs, I even wrote my first ML programs on the VIC until its PSU gave up mid '86. I already had a C=116 then, and later on, I had a C=128, which then was my main computing platform until early '91. I changed to Acorn, and bought an Archimedes A3000, which was followed by an A5000. So at least I could avoid the PC world for quite a long time.
During that episode, I taught myself ARM machine language, and C. This led me to vastly different methods of program design. Interestingly enough for me, I found many of these methods could be transferred back to the machine language of the 6502; if one was willing to throw some false suppositions over board. All in all, it was quite an interesting time then: together with a friend, I published some demos, and a disk magazine called 'Hardliner', under the handle/group name 'Architects'.
Even though, today there is nothing much more than the PC monopoly. One good thing about it, is that nowadays emulators, and cross-developing allow programs to be written for our first machines, that we simply couldn't do in former times without those tools at hand.
Over the time, one main interest for me always had been computer graphics. So, when emulators had matured enough, I thought what I could have achieved with the VIC, had its PSU not given up early?
Q. Can you tell our readers about the VIC-20 graphics extension MINIGRAFIK?
A. MINIGRAFIK is a compact tool for the VIC-20, that provides a high resolution graphics screen of 160x192 pixels with at least a +8K RAM extension being present. It features commands for changing between text, and graphic modes, pixel plots, line drawing, and it can save, and load the graphics screen. There is support to mix hires, and multi-colour graphics on the same screen, the latter which allows up to four colours being placed nearby on the screen, at the cost of resolution.
Q. So when and where did the idea for MINIGRAFIK come from?
A. A friend of mine gave me a tape with the original version of MINIGRAFIK in 1985. It had been published by a German computer magazine as type-in program. The original version had been written for an unexpanded, or +3K expanded VIC-20, and featured a 128x128 pixel screen. Line drawing, and graphics load/save commands were not included, but even so I wrote some programs for it, like function plotters, pie charts, and a simple joystick-driven graphics editor. The tape, and the extension later got lost in time.
I had subscribed to the Denial forum late 2004, and in 2006 there appeared a discussion thread about hires graphics in general, which gave me the incentive to reconstruct MINIGRAFIK, this time with a resolution of 160x192. Only the internal memory of the VIC-20 is accessible by the VIC chip, and I chose this resolution as it is the maximum one, which can be displayed without clobbering the lower 1K used by CBM BASIC, and KERNAL.
Besides the increased resolution, the added line draw, and load/save commands, I also included enhanced support for multi-colour graphics.
Q. Is the extension still evolving, for example are there still new features to implement?
A. As it stands, the current version of MINIGRAFIK already gives a good starting point for graphics oriented programs. Many graphics primitives can be coded with pixel plots, and line drawing alone. For example, I didn't include a BOX command, as that can simply be expressed as sub-routine with 4 line commands.
Some sensible candidates might be a colour selection command, circle/ellipse draw, flood fill, and text output. Even though, the usefulness of a dedicated colour selection command can be disputed, because it would only replace up to 3 POKEs for eye candy, but no other advantage. The other features will most probably be implemented as SYS-callable library routines in machine language, leaving the kernel of MINIGRAFIK untouched. Currently, a program using MINIGRAFIK can count on using nearly its whole code, so there is no baggage of unused parts of MINIGRAFIK around when it is loaded.
Q. Apart from the obvious VIC-20 limitations like memory and screen resolution, what main problems did you face implementing MINIGRAFIK?
A. The main concern was, that MINIGRAFIK does not operate on its own, but acts as support library for user programs. That required a seamless integration into the BASIC interpreter. I also wanted the extension to work on both PAL, and NTSC TV systems. For this, the two versions of the VIC chip must be programmed in a different ways, an auto-detect routine takes care of that.
Q. Can you explain to our readers how to use the MINIGRAFIK extension from their own programs, for example can you use BASIC commands to use the features of MINIGRAFIK?
A. MINIGRAFIK installs itself as extension to CBM BASIC. The new commands, and functions are all prefaced by an '@' character. @ON, @CLR, @RETURN select graphics mode, clear the graphics screen, and return to text mode. @LOAD, and @SAVE access tape or disc to load, or save the graphics screen. '@' on its own specifies a pixel plot, or line drawing command, with a syntax similar to the DRAW command in BASIC 3.5 or 7.0. Finally, the @() function takes a co-ordinate pair as two parameters, and returns the pixel colour within a numeric expression.
I could have added additional tokenizing, and de-tokenizing routines to give the commands their own names. Still, the combination of a flagging character, and standard BASIC 2.0 tokens with fitting descriptions of the intended use seemed satisfactory to me.
The screen bitmap has a simple address function, so programs written in machine language have fast access.
Q. I presume the whole of MINIGRAFIK is implemented as machine code? How big is the code when loaded into memory?
A. Indeed MINIGRAFIK is 100% machine code, only 1K in size. Even though, the memory from addresses 4096 to 8191 is permanently allocated for graphics display while the extension is active. With the minimum required +8K RAM extension that means there is still 7K available for BASIC programs.
Q. Has MINIGRAFIK been used in any recent VIC-20 games?
A. It found use in 'VIC=toria Gold Edition', a strategic board game set in Ancient Rome, which Alessandro Ubiali, and I co-developed in late 2008. Some graphics for 'Realms of Quest III' by Ghislain de Blois were prepared off-line with MINIGRAFIK-enhanced conversion programs. A few weeks ago, the text adventure 'Island of Secrets' had been re-released with a new LOOK command to show screens of more than 30 locations in the game. And, while it might not strictly qualify as game in the usual sense, I've also written a LIFE simulator which uses MINIGRAFIK.
Q. When or where did the program MINIPAINT evolve from?
A. Really, MINIPAINT started out from the editor part of the LIFE simulator I just mentioned. To get the features of a full-fledged graphics editor, and for speed reasons, I had to translate many parts to machine language, but there is still a main part written in BASIC which interfaces that ML library to MINIGRAFIK.
I did the first drafts of MINIPAINT in 2008, the project then lay dormant for nearly one year until I picked it up again last year.
Q. What was the main idea of MINIPAINT?
A. MINIPAINT, at its heart, is a pixel-oriented graphics editor. Before I had written MINIPAINT, the two main methods of creating graphics were either using MINIGRAFIK itself to do "programmed" graphics, or import images from PCs or other sources, converting them into the format specified by the @LOAD, and @SAVE commands. One of these programs, PGM IMPORT, does a fairly good job of translating a 80x192 pixel 256 grey-scale level PGM file into a MINIGRAFIK multi-colour screen dithered to 13 intensity levels.
Still, the VIC chip is capable of displaying really stunning pictures when a good graphician has complete control over the finest aspects of the displayed picture. This is, what MINIPAINT is designed for. Of course it can also be used to fix up conversions.
Q. I see you have an example piece of art work "Tutankhamun", can you take our readers through the process to draw this on the VIC with MINIPAINT?
A. I used a cropped photo of the mask of King Tut, and a variant of PGM IMPORT to produce a first workstage in the colours blue, orange, light orange, and white. Since I had selected white as foreground colour, I could add shades in black as another foreground colour within MINIPAINT. Another small part, the snake at the top, was repainted in cyan colour as well.
It was mainly a matter of luck I had no problems with attribute clashes of the foreground colour with this picture, and so it turned out quite well.
Q. How long did the picture take to complete?
A. The preparation on the PC, and the conversion maybe took 15 minutes. Adding the black shades incurred the longest part of completing the picture, roughly 2 1/2 hours.
Q. Can MINIPAINT drawings be used in user programs or called as standalone PRG files for demos, etc.?
A. Since MINIPAINT, and MINIGRAFIK share the same picture format - the save/load function in MINIPAINT is implemented with MINIGRAFIK commands - the pictures can simply be loaded, and displayed by your own programs with the @LOAD command. The picture files themselves are actually executable PRG files. That means, even if one does not currently have MINIGRAFIK, or MINIPAINT available, that picture can be displayed by LOADing it ',8' (*not* ',8,1'!), and then typing RUN.
Q. Are both applications well documented with user guides and examples?
A. MINIGRAFIK is still being discussed in the thread in Denial about hires graphics. I had posted quite some example programs there over time, many of which are now also hosted on my SkyDrive account.
MINIPAINT features a small, but handy on-line help system, which is invoked by pressing the '?' key.
For both programs I am currently preparing a comprehensive manual, which includes a tutorial for MINIPAINT, example programs, and utilities using MINIGRAFIK, and additional documentation for those who want to access the hires screen from machine language.
Q. Have you had much feedback from users of the applications?
A. There has been quite some feedback, mostly by Denial fellows. While I did the design, and coding of MINIGRAFIK all by myself, for MINIPAINT I got some very important feedback during development from Shane Fell, and Vanja Utne.
MINIPAINT wouldn't be the program it is now without their suggestions.
Q. Have you had any thoughts about other applications that will utilise the MINIGRAFIK add-on for the VIC?
A. The hires screen can be used to "host" output from a 40 column emulator. Even though there are some of these programs around, like FAT-40, they all suffer from a sluggish output. This is mainly because they replicate the whole BASIC editor functionality within themselves - there's not much room to optimize things, when the API focuses on single character output.
Text output on a bitmapped screen is heavily sped up when a routine that can print complete lines at a time. Such a routine already has been used for the dialogue boxes in MINIPAINT. These ideas might end up in a 40 column text editor. Together with an assembler, it might even be possible to produce a new kind of programming environment for the VIC-20.
Q. What 3 things would you change about the VIC-20 if you were able to go back in time and help redesign the machine?
- The 3K RAM between 1024 to 4095 should have been populated as well. That would have allowed to locate the screen at 1024, not only increasing the amount of accessible RAM for the VIC chip, but there would also never have been any problems because of a relocating text screen with bigger RAM extensions.
- Nice would have been an error-free shift register in the VIA chip. That would have given us fast floppies right from the start, without the necessity for the CBM developers to re-implement the IEC protocol bit-banging style in software.
- Separate luma, and chroma, instead of composite video output.
These features would have kept the essence of the VIC-20. And for any other enhancements regarding graphics, sound, and memory, there's still the C=64 around. ;)⇧ Back To Contents
As a comprehensive manual for MINIPAINT is in the works, a complete coverage of the editing functions is given there. For the following tutorial it suffices to know, that cursor controls work as usual, pixels are set with the keys 1 to 4, their colour assignment is changed with CTRL-1 .. CTRL-4, SPACE toggles between editor, and a full screen preview, and while editing it is always possible to invoke the on-line help system with '?' (SHIFT + /).
MINIPAINT requires at least a +16K RAM extension.
When you draw a picture in MINIPAINT, at first you need to think about, which colours appear most often in the scene. For an example, consider a single apple tree against the sky, with the sun, some clouds, and a few birds.
The three most common colours are Light Blue for the sky, Green for grass, and leaves, and Brown for the branches and trunk of the tree - where the darker version of Orange is the best approximation for. One of these three colours must be chosen from the lower 8 available colours, because it is assigned the border colour. In this case, there is only one choice, Green.
In case you do not want a visible border appearing around the scene, you might:
Press 'M' to show the full palette display in the status window. Then change background (1) to Light Blue, border (3) to Green, and auxiliary colour (4) to Orange. The foreground colour (2) is used to draw everything else, for the moment you should set it to Black. Press CLR (with SHIFT) to clear the screen.
Orange is toned down to Brown for the branches, and trunk of the tree. For this, mix Orange, and Black in the top-left corner of the screen in a chequered pattern, up to X=6 and Y=15 - the whole top-left attribute cell. Cut the cell with the DEL key, and then sketch the bottom ground, and tree with the INST key:
Refine the details by clearing pixels to background colour, and adding pixels in Black or Orange fitting to the pattern. Sketch the outline of the treetop in Green:
The grass at the bottom is painted in two steps: first put a two-pixel thick line in green between ground, and sky. Then add blades of grass with vertical lines. To draw the apples, change the foreground colour (2) to Red. Place the apples within the treetop. While doing this, some parts of the branches might change colour from Black to Red. This is the colour clashing mentioned in chapter 2. Leave the affected parts alone for the moment.
When you have placed all apples, take a look, where the branches have changed from Black to Red. There, replace the Red colour with Green. Since that colour is taken from the border colour (3) this does not incur yet another colour clash - and later will 'hide', that a colour clash had happened in those places. Then, within the outline of the treetop, apply another chequered pattern of Green over the background, so the Green pixels are aligned with those used to conceal the colour clashes. This step completes the tree.
To draw the sun, change the foreground colour (2) to Yellow, and press 'H' to switch to high resolution mode. Place the sun in the top-left quarter of the picture. Draw the outline first, then fill the interior. Then, add some clouds. Change the foreground colour to White, and place the clouds in good distance to both sun, and tree to avoid colour clashes. Add some structure along the top- left facing part of the clouds by clearing pixels to background colour. For the finishing touch, change the foreground colour back to Black again, and add some birds - the picture below to the right-hand side shows the result: