Jump to content

TROGDOR

Members
  • Posts

    279
  • Joined

  • Last visited

About TROGDOR

  • Birthday 01/25/1971

Contact / Social Media

Profile Information

  • Custom Status
    Why Yes, I Have Played Atari Today.
  • Gender
    Male
  • Location
    Strongbadia
  • Interests
    Expounding on the theoretical limits of obsolete software

Recent Profile Visitors

15,789 profile views

TROGDOR's Achievements

Moonsweeper

Moonsweeper (5/9)

12

Reputation

  1. Hey folks, It's been about 5 years since I logged in, but I wanted to stop by and put a plug in for a game that I recently discovered that should resonate quite nicely with the AtariAge community. The game is called The Last Door. It's an incredibly pixelated Lovecraft-style graphic adventure. My wife and I played it for about an hour tonight, and so far we love it. Although the graphics are very low res, the sound effects and music are normal fidelity, and add a lot to the game. The game does an excellent job of building suspense. It's free-to-play with a donation system for people that want to contribute. I highly recommend you give it a try at www.thelastdoor.com. Some screenshots are included below. Enjoy! -TROGDOR (I put this under classic gaming because although it is technically a modern game, it's not exactly your typical XBOX / PS fare.)
  2. Hi AlmightyGuru. I'm somewhat familiar with the SID chip, having done some programming for it with the Commodore many years ago. I also did a little wikipedia research on the SID file format. I'm not aware of any atari 2600 sound file format, other than running a binary ROM in an atari emulator. It seems quite possible that atari music could be translated into midi format by replicating the unusual atari frequency tables and the various wave tables. But what you're really asking for here is a TIA (Television Interface Adapter) sound format, which is the chip responsible for producing the Atari's sound effects. Atari music is dependent on the TIA chip and the ROM implementation that generates the TIA input stream. I would guess the easiest way to accurately capture the resulting music/sounds from a binary would be to add a TIA recording feature to an existing emulator such as Stella, and then write out the sound file in either midi format, or some new atari TIA format. Of course, music can be saved today by capturing sound directly from an emulator application into a wav file. But an atari specific format, or midi, would be more concise.
  3. Yes, yes... keep the puns flowing! The fish are upsidedown. Just like the BP shareholders. Nice pic Devin. I tip my Top Hat to you.
  4. Proper use of the word affect effectively effects an affective effect on me.

  5. Proper use of the word affect effectively effects an affective effect on me.

  6. Yesterday some LDY SED I was an ASL just BCS I used my BRKs for a SEC, AND I CLD have ROLed my car! What a LSR.
  7. TROGDOR

    Scooba!

    You'll be happy with your purchase. I've been using my Scooba for over a year and it still works great. In fact I just ran it today on the kitchen. Well worth the money. Make sure you do the recommended internal component clean up every time you run it. It only takes about 5 minutes to clean the parts. Also, always run a vacuum cleaner or Roomba on the target mopping area before using the Scooba. Otherwise you'll run the risk of clogging the internals with debris, which can cause it to break. I've seen some complaints in online product reviews for the Scooba, but now that I've used mine for a while, I suspect the disgruntled users weren't maintaining their robots properly.
  8. TRIP TO THE SPACE WAR MOON CRESTA WRITE IT NOW !! YOU CAN GET A LOT OF FUN AND THRILL
  9. Here's a post that discusses random number generators, and techniques to seed them. I recommend the 16-bit implementation. It's the best trade off between RAM usage, speed, and getting a reasonably random number sequence. It's much easier to generate random numbers that are multiples of 2. To get a number from 1 to 6, you could generate a number from 0 to 7. If the result is 6 or 7, get a new number until you get one that is less than 6. Then add one to the result. The only risk with this technique is that it requires an indeterminate number of cycles, since you don't know how many 6s and 7s you'll generate before you get a usable number. It's better to adjust the game requirements so that only powers of two are needed for random numbers.
  10. To understand how negative numbers work in binary, you need to take a look at one's complement and two's complement math. You'll find information about it here, and other tutorials from Googling.
  11. I didn't notice much visual difference between the two modes for the Gecko. I'd say remove it and reclaim the cycles and archive the more accurate perspective as a code thread.
  12. It's no problem. I've moved on to another ambitious experiment. I'll be posting it soon, probably this weekend. I will likely take you up on that at some point. I've had a game in mind for quite some time that I was debating whether to implement in 2D or 3D. That's what started me on the Elite research.
  13. Excellent work Thomas. I have to admit I'm a little bummed. You've already implemented what I had hoped to achieve. Still, it's nice to see a clear demonstration that this technology is possible on the 2600. Hopefully we'll see some 3D vector games spawned from this engine.
  14. Very impressive Curt, great work! I have a few questions about the designs: - What technology node sizes were the chips designed for? (I'm guessing around 2-micron.) - How many layers are the designs? - Have you been able to compute any transistor counts? - What are the file sizes of the gds? - Is the logic full custom? I can see what appear to be two memories in the center of the GTIA layout, unless those are gate arrays. - Who owns the rights to the gds? With the full schematics and layouts, it should be possible to perfectly emulate these chips down to the most minute details.
  15. Hi Thomas, The first thing I'll need is a working M-Network implementation. I've started looking at Wickeycolumbus' E7 Template. Hopefully I can get that working this weekend. Once I have the bitmap running in actual RAM, I'll try implementing a line drawing routine. Your cycle estimate is accurate. The C= Hacking article mentioned above gave an estimate of 38 cycles average per point plotted: Fortunately, the third installment of the 3D article offers a clever optimization for line drawing that will reduce this value. But even a highly optimized solution will probably average 30 cycles per pixel. The biggest problem is going to be drawing long lines, because they contain the most pixels. The demo image above contains ~700 pixels. A single line that spans the width of the buffer is 96 pixels, and it takes a long time to draw. The half screen buffer method will get me down to ~350 pixels, but it will still be tough. On the bright side, this image is a worst case scenario. Most of the time the ships will be farther back, and therefore smaller and less effort to draw. My first demo will be something simple, like a box. You can't go wrong with a box. The fall-back plan if I can't get this half-buffer solution to work would be to use two full 1K buffers, or reduce the screen size to 64 pixel height, so it would fit in 768 bytes, with 2 3-page buffers. Then I could spend multiple frames updating the buffer without worrying about a half-drawn buffer. Or I could just try using half-drawn buffers, and see if that still looks acceptable. If you're spending 8 frames to draw a complex display, it might not be too bad if 1 of those 8 frames is only partially drawn. The reality is I can't use the entire 2K of RAM on just screen buffers. Significant memory will still be needed for other aspects of the game. For example, every ship is going to need: 6 bytes RAM to define its position (X,Y,Z) x 2 3 bytes RAM to define its rotational orientation (X,Y,Z) Either 1 or 3 bytes RAM to define its velocity (Either X,Y,Z velocity, or a 1-byte scalar that incorporates the rotational orientation to define the velocity vector) And at least 256 bytes RAM will be needed to define all the lines necessary to be drawn for the display, with 4 bytes defining a line (X0,Y0 to X1,Y1). The demo ship is 41 lines, but I will likely reduce that down to 27 lines by making the back of the ship a trapezoid. Using the Melody cart, I could probably just throw RAM at the problem. An ideal bank-switching solution for me would be: 3 slices slice 1 - A 2K block of selectable ROM, from 8 2K sections slice 2 - A 512 byte block of selectable RAM that uses 1K of addresses (for read and write), selectable from 8 512 byte sections, for a total of 4K RAM. slice 3 - A fixed 1K block of ROM for common routines and to define the bankswitching for the other slices. I took an upper-level computer graphics course back in college in the mid 90s that will help with some of this work. For the final project, we had to implement a 3D wire-frame object moving around the screen. Of course I chose to design a spaceship. But the class used these expensive high-end 60Mhz Pentium machines, so performance optimization wasn't much of a concern.
×
×
  • Create New...