BEFORE USING, YOU MUST READ AND AGREE TO THE DOCUMENT C:\AZTEC64\LICENCE.TXT IN ITS ENTIRETY OR REMOVE ALL OF THIS FROM YOUR COMPUTER NOW. DO NOT CHANGE ANY OF THIS UNLESS YOU HAVE A COMPLETE UNDERSTANDING OR IT MAY NOT WORK! ReadMe.txt for the C:\Aztec64\PRODUCT Directory This directory contains one subdirectory called "TIME". The TIME program for the Commodore 64 contains a completely rewritten English Language version of an application that I originally developed and published for the Apple IIe in 1991. The formal title of this program is "What Time Is It?". The goal of the application is to teach Elementary School Children how to tell time. Regardless, my own goal in producing this program was to provide a full-blown application that demonstrates what a seasoned expert programmer can do in the Aztec C Environment for the Commodore 64 (C64). Now if all you are in this for is run programs and not to make them the TIME directory like all my other program directories contains the finished programs including a diskimage called time.d64. These programs are preloaded on the diskimage and run nicely in the vice emulator. If you are using these in WinVICE remember that while graphics load quickly in Warp Mode, the sound routines are time-based and you should take your emulator out-of Warp Mode for proper sound playback and time-based events. Introduction If you are reading this but have not reviewed all of the samples and all the projects in this programming environment please do not be offended if most of this goes completely over your head, or worse yet sounds like a nattering old man (which it should if it's flying high enough, since that was my intent). Take comfort in the fact that I am giving you all the source code and graphics images that I used to produce the TIME application. All this is completely transparent. There are no trade secrets here and no TIME deadlines so take your TIME and enjoy the confusion because it's part of the game. It feels so good when you finally understand, for a moment... 'nuff said. So let's get started and talk about the architecture and I am assuming that you have read the other make files and gained an understanding that memory management and mapping is "Job One". Balancing the TIME Overlays I really enjoyed this part. Some of you can imagine how I hurried through getting all my samples and library routines written and tested so I could actually do something more-or-less meaningful. I wondered myself at times whether I would be able to fit all the stuff I needed to into memory. My work on this particular application on the Apple IIe using Aztec C was in the PRODOS 128K environment which allowed me to store data in auxilliary memory. Even in that environment which is about the same size in conventional memory as this one, I needed to break down the Apple IIe version of TIME into more overlays than I did here and to keep the graphics data in upper memory... an option I don't have here. So when I did all this and it just barely fit I knew I could show the rest of you how far this can go without breaking, Like I said above; memory management and mapping is "Job One" and showing someone what can be done makes the job fun. You should have already figured-out from my other programs that I have been playing around with program memory holes, and sticking data into bits of memory that I couldn't run my programs in. This is the way we do it. You should also have figured-out by now that the linker outputs the code and data sizes, and that my make files can be redirected to disk file so you can review errors and do something about them, or to examine actual data and code size and adjust the memory usage until there is barely any wasted space. When I do overlays I am always trading-off what to put into the main (root) module and what to link into the overlays. If the main module gets too bloated and the overlay wipes-out the upper ram the program will finish but never get back to the BASIC prompt. My goal is always to get the user back to the OS whether I program for Windows, Linux, MS-DOS, Apple IIe ProDOS, or the C64. One must therefore consider all the overlays at once and realize where one must put what and when to discard and when not to. In making TIME fit into SPACE I created some pretty neat tools to help save memory, and kept the code that I could in the main module, and the code that I couldn't in the overlays. I run-length encoded my graphics and re-used buffers as well. The C64 disk drive is notoriously slow, so it is bad enough that I needed to read these overlays from disk but it would have been much worse if I needed to read additional graphics from disk, or worse yet, to read more overlays (like I needed to on the Apple IIe). My comments are pretty good in the TIME modules, but sorry kids, they are intended for experts. So become one yourself if you aren't already and read the code and the MAKEFILE and run the thing and have some fun with it. 'Nuff Said on the balancing of overlays... some additional eulogies on the topic are in the TIME source code. Using The Graphics and Sound Routines If you have looked at my graphics routines you know by now that I could have gone much further, but that was never my goal. I just wanted to have a little fun with this old compiler and show-off a little bit and leave the field wide-open for competition. I also could have optimized a little further, or a lot further. But I already know where all this breaks and by now I think I got some of my money's worth back on my original purchase price in enjoyment. Part of my goal was to showcase the B64NAT.LIB in all of this. I think that the C64 routines that I am leaving you with are better than what I did on the Apple. The sound is better of course and the gameplay is without doubt the same since the processor is the same. The memory saving technique of run length encoding can be taken further, but I kept it simple. Still, by comparison the C64 stuff is easily as robust as the Apple IIe equivalent of using bitmap graphics from upper memory. I am satisfied and can now leave this alone. So by all means change the code, and have some fun yourself. My selection of multicolour mode was deliberate. The graphics are simple since I originally drew then for the Apple II to avoid aliasing which effectively puts them somewhere close the same coarse resolution as on the C64. There are strange considerations when comparing low resolution graphics on the IBM-PC and Apple IIe and C64 which I have discussed in length in my Wikipedia articles etc. But the common denominator that I mostly went with was 4 Colors, and 2 of them being Black and White, with the other two mainly Red and Blue, and I will leave the rest for you to figure-out on your own. Read the code, run the program and have fun! Over and Out. Bill Buckels February 25, 2008 End of Document