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

[Porting Elite to the 2600]

I suggest you to start with a demo, e.g. drawing an animated 3D-cube or Elite ship. That should give you an idea about the necessary task and the required cycles.

 

After doing some pseudo code, I suppose setting one pixel will cost ~35 cycles, not 20. So my estimated 4000 cycles will now change into 7000 cycles.

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:

 

When combined with the earlier line drawing routine, this gives an average

time of 38 cycles or so (with a best time of 34 cycles); six of those cycles

are for PHA and PLA, since the line drawing routine uses A for other things.

 

Like most of the code, you can improve on this method if you think about it

a little. Most of the time is spent checking the special cases, so how can

you avoid them? Maybe if we do another article, we'll show you our

solution(s).

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.

[Porting Elite to the 2600]

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.

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.

[Porting Elite to the 2600]

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.

 

It just occurred to me, that only for clearing the 1k RAM, you will need at least 5000 cycles. That's almost the CPU time of a whole standard frame ((262-192)*76 = 5320)!

 

And if 20% of the pixels of the buffer are set and you need ~20 cycles (which is pretty optimistic IMO) to set one pixel, this will require another ~4000 cycles.

 

Then you still have to do all the 3D coordinates calculations.

 

So maybe a frame rate of 20Hz would work, but unless you want to display two empty frames in between, you have to double buffer. And then you need another 1k RAM.

 

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.

[Death of a Laptop]

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.

[Stellar Overlord v0.95]

Thanks guys. It's slowly but surely making its way towards release candidate. As suggested by the revision number, I only expect a few more versions before it's ready to go into a ROM. Making the manual has been fun, but also a lot of work. I've spent almost as much time on the manual as I did on the game.

 

One other thing that I didn't mention in the blog post is that I finally installed DASM V2.20.10. For the past 6 years I've been using the original 1995 version of DASM. I was forced to seek out the updated version when I started playing with illegal opcodes, which apparently aren't supported by the older versions. I'm liking the new version a lot, especially for faster debug without having to dig through log files.

 

Regarding Hardware Wars, I first saw that movie in 1978 at my elementary school when I was in third grade. I don't think I got the "4Q2" joke back then, and obviously neither did the teachers who showed the movie. My favorite scene is still the creature cantina.

[Playing Strip Poker II+ (Amiga)]

Hubba hubba hubba!

 

So, when do we get the Atari 2600 port? We have the necessary technology.

 

itsart.zip

 

[wav2atari.pl]

Thanks B00daW. I'd suggest getting a small, simple sample working first, and then grow from there.

 

I've discovered that it's tough to do anything longer than 2 seconds without bank switching. I squeezed out another sample last month.

 

EricBall, thanks for the info. I'll do more research on it as time allows. The Hello sample seemed reasonably clear, even though it was down-sampled from 8 bits to 4 bits.

[wav2atari.pl]

Thanks Chris. Playfield display with samples is possible, but you'd have to have a separate block of code to handle the kernel and the off-screen code to keep everything in sync. Note also that this would work for constant-rate samples, but would not be possible for variable-rate playback, unless you do something complex like wave tables.

 

I've been working on making a song with a guitar sample, but I'm finding a surprising amount of aliasing coming from the 16-bit to 8-bit downsampling. I expected aliasing from a reduction in sample rate, but I wasn't expecting it from a reduction in bit resolution. I'm going to consult some audiophile forums to see if any pre- or post-processing is possible to prevent this downsample aliasing. It adds too much distortion. (Then again, this wouldn't be a problem if your goal was a distorted guitar. )

[wav2atari.pl]

Thanks Impaler. I've added a variant that demonstrates high resolution variations in pitch. This uses a NOP jump table to create delays with 2 cycle resolution. If necessary, it's also possible to get single cycle resolution using a C9 jump table. These subtle variations in delay change the playback rate of the sample, which alters the pitch of the sample.

 

I couldn't figure out how to attach it to this comment, so I put it at the end of the blog post above.

[The ending to Asses of Fire]

Nicely done, eh!

 

You can find an mp3 of the Canadian anthem here.

[The Battle of Midway v0.21]

This is coming along great! I managed to sink a ship after a few tries. Very rewarding.

 

Not sure if this would be possible... but could you add wind or motion of the ships into the mix? Maybe by showing clouds drifting by at different speeds?

Thanks Nathan.

 

Horizontal ship motion can't be done without more RAM. I'm currently using 36 bytes of RAM to display the ship. Scrolling the ship across the bottom of the screen would require at least 60 bytes of RAM (5 x 12), and would only be possible with a dedicated kernel that wouldn't allow any other movable objects on the same scanline, because I'd have to refresh all 3 playfield registers twice on every scanline. I'm already using up most of the RAM, so I've punted on the idea of a moving ship.

 

I have considered clouds, but they wouldn't be moving clouds. An aysnc moving cloud in the area where the planes fly would use too many cycles. The current kernel is updating all 5 movable objects on every scanline, so there aren't a lot of free cycles. But I'm thinking about adding a static cloud using a mirrored playfield that would appear on harder levels.

[The Battle of Midway v0.21]

Very cool.

The way the planes disappear when they get too low and too high is a little odd, though.

Thanks Bob. The vertical plane wrapping will be gone after a few more enhancements. When I upgrade the computer AI, the Zero will have flight patterns and boundary checks that will prevent it from flying off screen. For the player, if you fly too low, you will be shot down by the capital ship. If you fly too high, your plane will stall out. You'll then have to restart the engine before your plane crashes. (Similar to the biplanes in Intellivision's Triple Action.)

[Cute or Twisted?]

This is exactly why GMOs are heavily regulated in Europe.

[The Battle of Midway v0.17]

Thanks Chris. I figured out what I was doing wrong. After trying various values, I finally got wise and opened up the Stella TIA debugger. I've never had to use the TIA panel before, but this time it proved essential for finding the bug. The sprites were strobed in the right locations and the HMOVE was executing at the correct cycle, but I noticed the HM values for P0 and P1 were both 0, even though I had just written an 8 to both registers. Well, that's the problem. I wrote an 8. What I needed to write was an $80, because the HM registers only use the upper 4 bits. Once I changed that value, everything fell into place, and I now have a title screen with no artifacts. Thanks again.

[Stellar Fortress v0.23]

Those are good suggestions, but I'm going to take a different approach. I found this copyright lawsuit story to be inspirational. The photographer in this story represented himself, although given the detail in the case, he must have had some legal background. Still, the result of the case is interesting. He was only awarded $4400 for the product that was infringed. But, he was awarded an additional $10,000 statutory damages for willful infringement, and another $5000 for the removal of the photographer's watermark.

 

So my solution is simple. I've added a watermark to my ROMs. (Good luck finding it.) If the watermark is not removed, it will be easy to prove that my work was stolen. If the watermark is removed, I can collect another $5000 in damages. So certain unnamed people (cough Randy cough) had best be careful or they'll be looking at a $25 + $10,000 + $5,000 lawsuit if my copyrights are not respected. It would only take one lawsuit like this to shut him down permanently.

 

I encourage other developers to follow in suit. (Pun intended.) I also think it's a good idea for anyone releasing a homebrew game to clarify the copyright status of the game in their blog/post and with a README.txt included in the distribution. Unless they really don't care, which is also fine.

[So this Bantha walks into a bar...]

Adds "sithcart" to project list.

[New kernel--What the Dickens?]

I missed this when it was first posted. This is a beauty of a kernel. Can you post commented source?

 

This has forced me to go back and review the illegal opcodes. There's some wacky stuff in there.

[Playing Escape from Singe's Castle (C64)]

Check out this review from IGN. It covers most of the strengths and weaknesses of the game.

 

I played the game myself a few years ago. The only problem I had with it was the boss fights. You will die hundreds of times on some of the boss scenes, and get very frustrated. However, I was able to get through the entire game. The frustration must have been worth it, because I still have fond memories of the game.

 

As mentioned in the review, the PC version is the best, because it uses the mouse. I've never played the game on a console system, but for 3D games I've always considered a mouse essential to get a truly immersive feel. Also, I think there is a patch out there somewhere for the PC version which fixes most of the bugs mentioned in the review.

 

This game is about nostalgia. They did a great job capturing the look and feel of the original game, and that alone makes it worth the purchase. The game is arguably not worth $40 US, but at only $5, it's a no brainer. I think I paid $20 for it back in 2003 or 2004.

[Playing Escape from Singe's Castle (C64)]

As a classic gamer, I of course appreciate the C64 version of Dragon's Lair. But, I have to disagree with this statement:

 

this version is widely known as the only playable game at all from the Dragon's Lair / Space Ace series of games

The best game in the series, and the most playable, is Dragon's Lair 3D: Return to the Lair. If you follow that link, you'll find lots of screen shots and videos.

 

 

Dragon's Lair 3D is an entirely new, built-from-the-ground-up, three-dimensional version of the 1980s coin-op phenomenon. While it stays true to the design and storyline of the arcade game, it offers a massive 3D experience unlike anything else Dragon's Lair fans have played before along with unexpected twists for a whole new adventure.

 

Game features include full control over Dirk the Daring for the first time - make him jump, run, roll, climb, swing, and somersault; 43 huge areas and over 250 rooms; over 30 kinds of enemies, including over a dozen new creatures designed by Don Bluth; new items, weapons, and potions along the way to choose and collect.

If you've never played it, I highly recommend it. It came out in 2002 for PC and several consoles. You can find it on Ebay for 5 bucks.

[[KM] Let there be Sprite!]

Looks nice Hornpipe. Keep up the good work.

 

Looks good! Nice looking fighters.

 

So they are flickering, right?

Thanks! I'm not much of an artist so this was the best I could do...

 

Yeah, they flicker at 30hz. I turned on "Use Phosphor" with amount 77 in Stella to capture this image.

TROGDOR smacks himself in the head with his big beefy arm.

 

I've been using Stella for over a year now, and I didn't even know that feature existed. No more hand editing screen shots for me!

[Hello Again]

Welcome back David. We were concerned about who was going to pay for the Heavy Industries superfund cleanup, but now that you're back, that won't be an issue.

[Stellar Fortress v0.20]

The player ship explosion sound reminds me a lot of the crash noise on the Odyssey2.

 

The game generally looks pretty good, though if I might offer a couple of suggestions...

 

-1- I don't know how many segments there are in the shields, but it might be nice to have the segments be grouped into clumps (larger clumps on the outside).

 

-2- If you could make one of the rings rotate opposite the others, that would be nice.

 

Star Castle was a classic, so it will be nice if it can come to the 2600.

 

The ship explosion sound is standard Atari fare. Just a low frequency white noise with a decreshendo. The explosion for the cannon will be more involved, both in sound and graphics. I'm starting to code up an effect that will make the remaining shield segments implode into the cannon before it explodes, similar to the original Star Castle.

 

There will be 6 shield rings in the final game. 3 will rotate clockwise and 3 will rotate counter-clockwise, alternating every other ring. If you look in the source, you'll see that about 300 bytes of ROM was used to hardwire the logic for the clockwise shield rotation. It doesn't use a loop. The diagonal movement of the bits is too complicated for looping. The whole thing is unwrapped, and it took several hours to code it up.

 

Version 0.16 used square rings, so it was easier to implement in a loop, but it only supported 5 rings because of the extra 28 byte RAM buffer that was necessary.

 

The game level will dictate how many rings are activated. On early levels, there will only be two or three shield rings. On the highest levels, you'll have to blast through all 6 rings. The game will get progressively harder with each level, to keep the player on his toes. Difficulty variations will include the speed of the cannon rotation, the speed of plasma cannon shots, the speed of the missiles, the speed of the shield rotation, the number of rings in the shield, and another feature that will be disclosed soon. Also, on the highest levels, colliding with the shield will be fatal, rather than just causing the ship to bounce off.

 

If you absolutely have a need for three more bits of RAM maybe you'd be interested in this:

http://www.atariage.com/forums/index.php?s...5226&st=375

 

Question to the hardware gurus:

The undefined bits in SWCHB (2,4, and 5)...are these used at all by either console? In the update, I was attempting to EOR bit 2 (in the ram copy "DifSw") to signify a board reset...which looks to work OK in emulation.

I'm not a hardware guru but these bits are not used by either console. You can use them for RAM if you would like. Before doing so though you must set the bits data direction.

 

   lda #%00110100
  sta SWBCNT

 

Thanks for the info, but I probably won't get that squeezed for RAM. If I really need the extra RAM, there are at least 10 more bytes that I can wring out of the current implementation. It will just mean a more efficient use of temp variables, and some nibble encoding. I'm also trying to remove all subroutines from the code, or at least limit the number of nested subroutines to one level, so I won't have to reserve more than 4 bytes for the stack.

[laser tv]

My threshold of pain for buying a TV is around $1000. Last year I picked up a 50 inch Vizio plasma for $1200, and I've been very happy with it. The TV industry is in such a state of flux right now that you can only expect to use your TV for 2 to 3 years before something on it is "obsoleted". I get a strong vibe of planned obsolescence coming from this industry.

 

A good example is HDMI. 5 years ago no TVs supported HDMI. But today, if you don't have an HDMI port on your TV you're TSOL, regardless of how much you paid for it.

[laser tv]

Here's a follow-up blog on the laser TV. Given the blogger's reaction, it does sound impressive. The original story also mentioned 3D capabilities, which piqued my interest. Unfortunately, from the blog story:

 

The TVs used at the demo were prototypes, but you'll be able to get your hands on the real thing in Fall of 2008. Though pricing isn't announced, I was told that you won't see the Laser TVs at your Best Buys and Circuit Citys. Rather, they'll only be available through high-end retailers.

Sounds like these TVs will be in the 5 to 10 thousand dollar range. It will be years before us common folk will have access to them, similar to the status of HDTV sets five years ago.