TROGDOR

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.)

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.

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.

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.

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.

TRIP TO THE SPACE WAR MOON CRESTA WRITE IT NOW !! YOU CAN GET A LOT OF FUN AND THRILL

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.

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.

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.

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.

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.

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.

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.

Are you sure that you write with LDA? Where did you get that info from? The LDA could be used to trigger the correct write address, but you're right, the STA is necessary to correctly populate the data bus. LDA might actually work if you loaded zero into the accumulator and did a STA to populate the data bus, and then followed it by running all the LDAs to write zeros to the buffer. This would leave the databus in the Z state, likely retaining the previous zero. But that's sketchy. Whether it would work would depend on the hardware implementation, and how the emulators chose to handle it, so I'll avoid using this.

Thanks for the feedback guys. Thomas, here's what I came up with for the issues you mentioned: - With just 96x84 pixel your resolution is pretty limited. Maybe you have to simplify some ships. I don't think the resolution will affect the ship design. The one thing I am considering is making the ships appear larger in the Atari version so they show detail sooner. I'd have to see what they look like in a rendered. To be sure, at farther distances when they're only 8 pixels wide they will look more like filled polygons. - The aspect ratio of a pixel is not 1:2, more like 1:1.6. So probably you will have to compensate for that. Hmmm. I'm not seeing that. I looked at an individual double-height pixel for a while and they look pretty square to me. - How are you going to display the crosshair? With the bitmap or with dedicated objects? Bitmapped would be easier. It can be drawn very quickly into the video buffer, and then I won't have to mess with it during the kernel. - The 3D radar screen also looks like a real challenge. I suppose the 84 lines are only meant for the space screen, right? Maybe you have to reduce that to ~75 lines to have enough space for the radar, which IMO is essential. For the radar, I would deviate from the original design. I'm thinking 2 side-by-side radar boxes at 16 x 32 pixels (half-height pixels) The left radar would show a front-on view, so you'd see the X and Y axises. This would be primarily used for targeting. The right display radar would show a top-down view, so you'd see the X and Z axises. The dots on the radar would be color coded to help you correlate them between the two displays. This should be sufficient to show their position in 3-space. - Only partially updating the screen buffer between frames will result into visible problems. Some kind of double-buffering seems necessary. The buffer clearing is bad, but not quite that bad. Remember that the memory "writes" are done with LDA, not STA, so it's only 4 cycles per pixel using absolute,X mode. By writing 16 pixels per loop, the overhead of the loop can be reduced. So the entire buffer could be cleared in about 4300 cycles. Another trick I can use is based on the fact that the screen is displayed at 30Hz. I'm considering changing the display so that all the pixels on the left are displayed in one frame, and all the pixels on the right are displayed in the next frame. I'll have to see if the flicker is bearable. If I use that setup, I buy some time. I can use 512 bytes to buffer only the left side of the screen, then switch to that buffer instantly. For the right side of the screen, I will have 2 frames to update it directly in video memory, since it's only displayed ever other frame. 2000 cycles would be used for clearing the right side of the buffer, so there's ~8000 cycles left for line drawing. The overall refresh rate would vary, similar to a modern 3D game. For simple displays, it would refresh every 2 frames. For complex displays, it may only refresh every 16 frames. This applies to the buffer only. The display will always be shown every 30Hz, to prevent excess flicker. It will just be showing an "old" buffer. I need to get to work now. I'll comment more later.

Thanks for the suggestions on the Laptop. I'm going to talk with Dell support tomorrow and see what they recommend. I'm confident I could safely pull the drive myself and back it up. I just don't want to set off any "open case" flags in the system that would void my (hopefully extended) warranty. Thomas, I've been looking at the Bresenham algorithm. It's covered in a 3D rendering tutorial that I've been researching. I'll discuss it my next blog post. As for the number of objects that can be displayed at one time, it will be more than five, depending on the level of detail. It's going to use a bitmapped screen.

After spending a couple days researching Elite, I'm convinced this game could be ported to the Atari 2600 and still retain most of its original look and feel. Here's what the original Elite looked like on the Commodore 64: And here's a prototype screenshot on the Atari 2600 (this is from an emulator, not a mockup): The Bitmap The first challenge of the port is implementing a high-resolution bitmap. This can be achieved by using the 30Hz text display from Stellar Track. The 12 characters from this display provides a resolution of 12 x 8 = 96 pixels per scanline. The next question is how tall should the display be. This is defined by how large of a video buffer can be provided and maintained by the hardware. I chose a 1K buffer as a reasonable target. 1024 / 12 bytes per line = 85 scanlines. This would fit nicely in the 96 scanline resolution of a 2-scanlines-per-pixel Atari display. Using square pixels also simplifies the rendering math. To simplify the kernel code, it would be preferable to keep each column of buffer bytes in its own page. 84 x 3 = 252, so using 84 scanlines you can fit 3 1-byte columns in a single page. Multiply that by 4, and you've got 12 characters spanning 84 scanlines, so the final resolution is 96 x 84 pixels. The size of the bitmap can be seen inside the yellow border in the prototype image. The Hardware The 2600 only has 128 bytes of RAM, so it's going to need some help. The only current options for hardware that would provide a 1K RAM buffer are the Supercharger and an M-Network cartridge. The Supercharger only allows for a 6K game without multi-loading, and I don't think 6K would be sufficient to do an Elite port justice. Writes to Supercharger memory are also slower, if my conclusions from studying the Supercharger are correct. The M-Network architecture, on the other hand, is just about optimal for this scenario. The 16K of ROM provides plenty of room to make a detailed game. The 1K continuous block of RAM is perfect for the high-resolution buffer, and allows quick read and write access to the entire buffer. The extra 1K of split RAM would be useful as scratch memory for the 3D calculations, and also as extra memory to store details about your ship configuration and cargo. Another hardware consideration is the CPU. The main processor for the Commodore 64 is a MOS 6510 running at 1.02 MHz. The Atari CPU is a MOS 6507 running at 1.19 MHz. It's surprising that the Atari CPU, released in 1977, is clocked 19% faster than the Commodore CPU, which was released 5 years later in 1982. Other than the I/O port and the extra address pins, I'm not aware of any 6510 feature that would make it more powerful than a 6507. So the Atari starts out with a 19% advantage over the Commodore. The big disadvantage for the Atari is having to process the kernel. This effectively excludes 192 of the 262 scanlines from any kind of render processing, resulting in a (192/262) = 73 percent loss of processing power. So only 27% of the processor can be dedicated to rendering. When the faster Atari clock is factored in, you get 27 * 1.19 = 32 percent speed relative to the Commodore processing. So it can only handle about one third the processing load. Video Buffer Sizes The upside of the small Atari video buffer is that there are fewer pixels to render. The Commodore buffer used 256 pixels by about 140 pixels, for a total of 4480 bytes. The Atari is using less than 1024 bytes, so it has less than a quarter of the pixels to render. This matches well with the one-third processing power. Rendering The main functions needed to display the images are: 3D Rotation Projection from a 3D object to a 2D plane Hidden surface removal Line drawing Circle drawing I found some online resources that could really help with these functions. The most authoritative source is one of the original authors, Ian Bell, who posted the entire source code for Elite! This source was written for a BBC Micro, which also uses a MOS 6502. The only problem is there are very few comments in the code, and it's written in some kind of BASIC wrapper around the assembly code. While googling for 6502 3D algorithms, I happened upon a great 3D tutorial written specifically for the 6502. If you scroll down to the "art of 3d" section, you'll find three links to C= Hacking issues. It's a 3 part study titled "A Different Perspective: Three-Dimensional Graphics on the C64." It includes a very detailed discussion of projections, rotations, line drawing, circle drawing, and hidden surfaces. It also provides full assembly implementations of these algorithms, and optimizing suggestions. I highly recommend it. Code Organization Using the M-Network bankswitching scheme, here's how I think the implementation would work. ROM bank 7 (slice 1) On system boot, the code would immediately bankswitch to bank 0. Bank 7 would be entirely reserved for only routines that need to access the 1K RAM buffer. This is necessary since none of the other banks can access this RAM directly, and it would be far too slow to use bank switching to set the video buffer or read it for kernel processing. So, the only code that would go here is the bit-mapped section of the kernel (which is actually very small, less than 200 bytes,) and the line drawing and circle drawing routines, which would need direct buffer writing access. Hopefully they could be squeezed into 1.5K. ROM banks 0-6 (slice 0) All the other routines, including projection, rotation, and surface removal, would go here. The only data that would have to be passed to slice 1 is an array of line and circle definitions that need to be drawn to the screen. This array could be stored in one of the 256 byte RAM sections, which are also available to slice 1. Other ROM banks would include system boot, sound effects, text display, trade interfaces, and all the 3D data for the various ships. It would also include the non-bitmapped bottom portion of the ship kernel, which would include radar and ship status meters. Concessions I think the Atari could keep up on the Video RAM drawing routines. I'm not so sure it could keep up on the 3D rendering. I don't know what the ratio of necessary compute power is between these two functions. However, there are several concessions that could be made to reduce the 3D rendering load on the Atari. The most obvious is to reduce the number of lines and polygons on the ships. For the ship displayed above, the rear of the ship consists of an 8-sided polygon, plus 4 4-sided polygons for the thrust ports. The 8-sided polygon could be reduced to a 6-sided or even 4-sided polygon (a trapezoid) and still retain the look of the original ship. The two smaller thrust ports could also be removed. Small alterations like this could save significant processing time. Another optimization is to greatly reduce the polygon count when the ship is farther away. I'm not sure if the original Elite games did this, other than turning them into dots when they are very far away. For the Atari version, any ship that is sufficiently far away can be reduced to just 4 points, essentially a pyramid, of varying shapes and sizes to match their corresponding ship. Other Platforms There are two other systems that came to mind while I was doing this study. The first is the Channel F. Oddly enough, its hardware setup is great for 3D rendering. It already has dedicated RAM for a screen buffer, and its resolution of 102 X 58 is comparable to the Atari buffer, minus the flicker. Plus, its CPU operates at 1.79 MHz, so it has the most processing power and the smallest video buffer to render. I know that video RAM access is slow in the Channel F, but this still sounds like a possibility. The other system of interest is the Vectrex. This system is begging to have an Elite port. Graphics rendering would be a breeze on this system. The Vectrex is powered by a Motorola 68A09 at 1.5 MHz, which is far more powerful than the Commodore CPU. Elite ported to this system could look better than any of the original 8-bit versions. A Google search produced no evidence of any effort to port Elite to the Vectrex. The Prototype elite_study.zip The prototype binary I'm posting here is quite simple. It doesn't contain any 3D rendering. The ship is just a static image loaded from ROM. What it does demonstrate is the size and appearance of the bitmap, and the simplicity of the kernel. The only difference between this bitmap kernel and an actual M-Network bitmap kernel is that it would point to a different location in memory, corresponding to the M-Network RAM, rather than ROM. The VideoRAM[0-11] addresses in the source would become RAM pointers. I haven't implemented this in an M-Network bankswitching scheme yet. That will require more research, since the M-Network switching method is fairly complicated.

My main laptop died last month. It was a Dell Vostro 1400, and I was very happy with it up until the video card fried. Its best feature was the Nvidia Geforce 8400GS video card, which had its own dedicated video memory. Regrettably, that feature was its undoing. The system died a couple months after the 1 year warranty expired. I did some research on the problem, and found that graphic card failures due to overheating were a common problem for this particular laptop model, common enough that Dell has supposedly extended the warranty for an extra year if it fails for this reason. Hopefully I can get it fixed under warranty. Unfortunately I had all my Atari development code on that system. The good news is that the harddrive is still intact, and the system still boots. I just can't see the display at all. The main laptop display is blank, and the external display port is also blank. I'll have to work with Dell to figure out how I can get the data off that harddrive without voiding my warranty. I have an external SATA disk reader. If I can pull the diskdrive out of the system, I can backup all its contents. There is no way I'm shipping off a system for repair work without backing it up entirely. I've heard too many horror stories. I'm now back on an old laptop that I haven't used in two years. It was so old, it had Stella 2.1 installed. Since I can't access any of my existing Atari work, that has left me with a clean slate to spend a few hours yesterday doing a 2600 port feasibility study. I'll post the results soon, probably tomorrow. Here's a snapshot of what I have so far:

I'm an avid fan of robotic technologies. Over the past several years I've been following the progress of advances in robotics, including mechanical dexterity, sensor implementation, and software AI. I'd like to share these advances with the AA community and discuss their implications. I think the robotic industry is on the verge of a profoundly significant break through, where robots will start to become ubiquitous in our lives. (As I am typing this post, there are two robots cleaning my kitchen, and they're doing a great job. But I'll get more into that later.) I'm going to break this discussion up into several parts, so it's not one long post. In this first installment, I'll present the state of the art in robotics, which is best demonstrated by an assortment of videos. http://www.youtube.com/watch?v=Q3C5sc8b3xM&NR=1 Asimo Asimo is the gold standard in the world of robotics. Honda has been working on this model for over 20 years, with the first demonstration in 1986. This robot hosts many features, including advanced environmental recognition, excellent balance and motor skills, and the ability for both feet to leave the ground while running, which allows for significantly faster movement. The above video focuses mostly on Asimo's motor skills. I'm taking my family to Disneyland next week. One of the highlights for me will be the chance to see an Asimo robot in person at the Tomorrowland exhibit. http://www.youtube.com/watch?v=Yh7xssnhoXM&NR=1 Toyota's Partner Robot Toyota is also investing in robotic R&D. They have some nice musical demonstrations, but I get the impression they are behind Honda in this field. http://www.youtube.com/watch?v=qyPAIpXm-nU Toyota's Partner Robot II This is another Toyota demo, this time playing a violin. http://www.youtube.com/watch?v=CETUmThm8Rg Twendy-One This robot was designed at Waseda University in Tokyo. The video demonstrates precise manual dexterity. Japan in general has been investing far more money into humanoid robotics than the United States. Their primary motivation for this investment is the long-term goal of providing care and companionship for Japan's growing elderly population. http://www.youtube.com/watch?v=MY8-sJS0W1I Repliee Q1 A related field that the Japanese have been working on is building life-like humanoid robots. Repliee Q1 is capable of fairly life-like eye and mouth movement, and upper body gestures. Her facial construction has a realistic appearance, even when the camera is zoomed in. http://www.youtube.com/watch?v=M3tcSlWLS_g Actroid DER2 Kokoro's Actroid DER2 Female Robot is the most realistic android I've seen so far. http://www.youtube.com/watch?v=aQS2zxmrrrA Nexi MDS Continuing on the theme of human interaction robots, here is a video of Nexi MDS, developed by MIT's Media Lab. This robot's specialties are facial expression and manual dexterity. But I'll let her speak for herself. http://www.youtube.com/watch?v=SSkG5xf_ytQ R Daneel This robot, designed by the University of Tokyo ISI Lab, is human-sized and has the impressive ability to stand up on its own, using a familiar martial arts technique. http://www.youtube.com/watch?v=rSKRgasUEko Nao Designed by the French company Aldebaran Robotics, Nao is an impressive little robot with many capabilities. This is the first robot I've seen that can bend over and pick up an object off the ground. It can also lift itself up when it falls over. http://www.youtube.com/watch?v=WZmWjfRJtyU More Nao This is another Nao demonstration which shows its excellent sense of balance. Note that this video shows Nao using a different technique to get up from lying on its back. In the previous video, it was lying on its front. The blog software won't let me post any more videos, so this is a good stopping point. I'll post more on this topic in the future. Feedback and comments are welcome.

That's why the work I'm doing is based on Atari's Surround, and it won't be called Tron. Very doubtful. First Star Software, the owners of Boulder Dash, is a small company, and the fact that they allowed a port of their game is the exception to the rule. Disney is a massive company with 150,000 employees. They have a reputation for being very aggressive about copyright enforcement. For details, see this public service announcement: http://www.youtube.com/watch?v=CJn_jC4FNDo

Tron? Never heard of it. But I have been working on a totally unrelated game called Positron: Write Cycles, which is in no way similar to the licensed Disney franchise. My game is loosely based on the early Atari game Surround. Or Snafu, for Intellivision fans out there. The game is posted in my blog if you want to check it out.

Most of my asm files use an 8K footprint now, and I keep running into a problem in the Stella debugger of setting a break address, and having it hit on the wrong bank. Is there an easy way to specify the bank when assigning a break?

I haven't even played it yet, and this game already kicked my ass.