Jump to content

awhite2600

Members
  • Content Count

    357
  • Joined

  • Last visited

Community Reputation

176 Excellent

About awhite2600

  • Rank
    Moonsweeper

Profile Information

  • Gender
    Male
  • Location
    Onatrio, Canada

Recent Profile Visitors

12,900 profile views
  1. That's funny. I thought the same thing when I read your first post in this thread. Running the game logic on the ARM would, if nothing else, make the computer "think" faster. I think that what you're doing here is very cool. It's certainly an interesting tech demo of making the 2600 do something that it was never intended to do. The display reminds me a bit of the HAM mode on the Amiga. HAM allowed lots of color but with limitations where some colors were based on the colors of the pixels to the left. This created a similar "blurry" effect that when used creatively could create some amazing images. Keep up the great work!
  2. I think that all of the Zellers games were copies. What makes this so interesting is that Zellers was a large department store chain with stores across Canada.
  3. Are there any plans to release the original or "corrected" source code? They could prove interesting from a historical / preservation perspective.
  4. Commodore 8-bit computers do perform a simple memory test on startup. The purpose is to set the memory areas for BASIC. That is why, for example, a C64 with bad RAM might boot up to something like 24,576 BASIC Bytes Free instead of the usual 38,911. This test is not an exhaustive diagnostic of every byte. I recall that the boot sequence checks every 256th byte via a simple read / write. When an address is found that fails the test that location is used to set the limit for BASIC. Using different RAM expanders on a VIC do shuffle certain memory areas around. However the first 1 kilobytes of RAM - used by the kernal and BASIC - is always in the same spot and always uses the on board RAM chips. If swapping the ROMs for known, good chips doesn't help then you likely have bad on board RAM in the first 1K space.
  5. The lack of an ending and other gameplay elements may have simply been a factor of ROM size. I believe that Empire is a 4K game. That doesn't leave much room for extras.
  6. The VIC did organize the memory map differently between unexpanded, 3K expanded and 8K or more expanded. That still didn't alter the placement of the built in RAM, especially the fist few kilobytes used by BASIC. I'd agree with swapping socketed ROMS first as that is pretty simple. Failing that, you'd need to unsolder and swap RAM chips.
  7. I too was thinking ROM or RAM. A bad BASIC or Kernal ROM could cause the normal startup sequence to fail. Even one bad bit could cause the instructions to go in the wrong direction. Equally likely is bad RAM used by the initialization routines. If the startup sequence uses a RAM location for something like a counter, and that location is bad, then the process could get stuck in a loop. Adding RAM expansion may not help as that increases program RAM. It does not alter the built in RAM used by BASIC and the Kernal. As carlsson mentioned, a game may appear normal if it doesn't use that "bad" bit of RAM.
  8. This is absolutely amazing. I can't believe how much gameplay you were able to squeeze into such a small program. Thanks for sharing.
  9. Wow. This thread has taken me back to Commodore 8-bit BASIC optimization techniques that I haven't thought about in a very long time. Commodore BASIC limits you to 80 "typeable" characters per line. (2 x 40 character lines on a 40 column machine.) One way to increase this is to use shortforms for the BASIC keywords. PRINT can be abbreviated as ?. Other commands can be entered by typing their first character followed by a shifted version of their second character, which will appear as a graphics symbol. As an example, FOR can be entered as F shifted-O. NEXT would be N shifted-E. This will expand to a line larger than 80 characters that will still execute correctly. The only downside is that you will need to reenter the entire line if you want to change it because the expanded line will be too long to edit. For variables, Commodore BASIC only cares about the first two characters. While you can use a variable such as SCORE%, BASIC only cares about the first two characters. Use SC% to save space. (If you want to mess with people reading your code you can use things like SCORE%, SCAB% and SCROLL%. BASIC will consider them all to be the same and the names can be used interchangeably.) When dimming arrays remember that they start at element 0, not 1. If memory is tight, creating one less element can help. So in carlsson's example above you can use DIM A%(19):FOR I=0 TO 19:A%(I)=0:NEXT I would also remove as many spaces from the code as possible to save bytes. Unfortunately this can make your code very difficult to read.
  10. Here's my theory... Could this have been a quick and dirty hack to assist with porting Pitfall to other systems? It sounds like the goal of the hack was to just make the game infinitely playable. The player could progress through the various screens without fear of dying. They could then compare to a work in progress port to make sure that the screens and other elements appeared in the same sequence and any onscreen elements (treasure, snakes, scorpion) also appeared.
  11. I'm finally considering archiving my floppy disk collection while it is hopefully still readable. I was inspired by this thread about external 5¼" floppy drives. My collection consists of original disks (some copy protected), backups of commercial disks (some nibbled to retain protection) and disks of personal program compilations, data, etc. I'd estimate that I have at least 500 disks in total. About 50% are C-64 5¼", 40% Amiga 3½", 9% IBM PC - both 5¼" and 3½" and 1% Mac (variable speed 3½"). I know that the following options are available. Each seems to have pros and cons. Zoom Floppy KryoFlux FC5025 SuperCard Pro Ideally I'd like a solution that can archive all of the various formats in my collection. I'd like the archive files to be compatible with PC based emulators as well as solutions like Pi1541, etc. I don't really care about the ability to write the archives back to floppy disks. If a disk is copy protected I'd like the archive to still be usable with an emulator or "disk emulator" connected to native hardware. While the Zoom Floppy is inexpensive, it is limited to Commodore 8-bit formats. The FC5025 is also inexpensive but is limited to 5¼ disks. Due to these facts I'm thinking that both solutions are out of the running. The KryoFlux is only a bit more expensive than the SuperCard Pro. The KryoFlux is considered the "gold standard" for archiving floppies. The SuperCard Pro is similar to the KryoFlux and may eventually have emulation capability. I have one or two 5¼" HD floppy drives and several 3½" drives. I also have a couple of Commodore 1541s, a 1581 and Amiga 3½" and 5¼" external drives. I'm looking for feedback from the community. What are your experiences (good and bad) with any of the above solutions? What is the software for each solution like? What is involved in archiving a disk and then making the results usable for emulation?
  12. I was in a local computer store one day in the late '80s. Some redneck looking guy walks in and says to a salesman, "I'm interested in buying one of those new HOME computers." I kept my mouth shut and walked away, controlling my laughter.
  13. Thanks for the additional info. I'm impressed that you can render these images with a stock 6507. You mention needed RAM - which makes sense for a paint program. Could a completed image be rendered from ROM, or is on-the-fly "manipulation" of the data required? I now see that you had mentioned SaveKey and other details. Sorry that I missed that.
  14. While there may be a limited audience I must admit that the idea is very cool. I too am impressed with the sample images. Can these images be generated with normal 6507 code or is an ARM processor required? A way to increase the value of a paint program beyond a novelty would be a way to either save the images (on cart or to some sort of external device) or allow the image to be exported for use as a title screen for a game.
  15. The museum was supposed to be a non-profit corporation. I don't believe that it was. While I am guessing based on information from others involved with the museum, I think that Syd did not have his affairs in order prior to his death. I have not been part of any discussion about the legal ownership of the museum assets. It sounds like either the collection is now owned by Syd's widow or that she has legal authority to control it. The museum was supposed to have a board of directors. If the appropriate legal status of the museum was not up to date then that board may be meaningless. I am told that the items are in storage. I have no further details - where they are stored, how items were packaged, what costs may be needed to pay for ongoing storage. The museum volunteers are completely in the dark at this time. We have all accepted the fact that we do not have any further involvement or control of what happens to the items. All we can wish is that the items eventually find a good home at another museum or perhaps a university. Hopefully then the items of historical value can be made available for archiving, study and even enjoyment.
×
×
  • Create New...