Thomas Jentzsch

The optimized code was tested to work, so I suppose that it is mainly a documentation flaw. Probably a return value is different from what you expect.

Alex's version works fine, its just a bit longer.

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.

What's the problem exactly?

Ah, pictures!

Are you sure that you write with LDA? Where did you get that info from?

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.

You can use PAL60 or PAL50 bios, whichever you prefer, since most PAL TVs can sync to 50Hz.

Doing Elite seems like a huge challenge. If you can get the graphics right, everything else should be "just" a lot of labor (compared to the initial problem). The hardware choice seems optimal. With the coming Melody cart, hardware for this should be no problem anymore. Some problems you have to overcome: - With just 96x84 pixel your resolution is pretty limited. Maybe you have to simplify some ships. - The aspect ratio of a pixel is not 1:2, more like 1:1.6. So probably you will have to compensate for that. - How are you going to display the crosshair? With the bitmap or with dedicated objects? - 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. - Only partially updating the screen buffer between frames will result into visible problems. Some kind of double-buffering seems necessary. What visible screen size are you aiming for? The more the better, but the less free CPU time you will have. Alternatively, you can slightly reduce the frame rate, by e.g. display 270 total lines. You should use the reduced resolution to your advantage. E.g. like you describe, reducing the ships to points. This can be done earlier than with a full resolution. For the 3D calculations you should try a table based approach. Everything else seems way too slow. Maybe the original source code can help. For hidden-line removal you fortunately only have to calculate Z-part of the surface direction. BTW: Elite became 25 this year.

I've done some Bresenham programming (heavily optimized of course ) in the past, so if you need any help, just message me. I suppose that's the only approach that will work. Continued in the other thread...

Yes, it is a standard Atari case. The Harmony cart is based on a pretty powerful ARM CPU. This allows emulating the extra hardware of Pitfall 2 and many more things for games yet to come. Works too.

Everyone's a comedian Although the Harmony cart counts. What did you use the Harmony cart to play? Maybe he just played with the menu?

Good luck with your Vostro. Dell is well known for having the best service of all. BTW: I once thought about Elite and wire-frame graphics too. I even tried to do a rotating 3D-Cube a few years ago, but lost interest half way. You need a simplified Bresenham like this, which straight forward could look like this: lda vSum0 ; 3 clc ; 2 adc vAdd0 ; 3 sta vSum0 ; 3 lda vMove0 ; 3 adc #0 ; 2 sta HMM0 ; 3 = 19 For more vertical lines, this is no problem. But the more horizontal lines are. Elite is done pretty clever, since all objects are defined completely convex. This makes hidden lines solving much easier. Nevertheless, with just 5 objects to play with, the 2600 is IMO a bit too limited (unless you do a lot of flicker), especially during mass Thargon attacks.

Great game. I will give it some more play tomorrow. A minor comment: IMO, at the credits screen, "Duck" and "Attack!" should have the same with (like at the title screen). Looks better that way. Also the vertical space between the two words is much bigger at the title screen. It should look identical on both screens.

If your analogy is right, then I wonder why the current US health system is the most expensive and still rather ineffcient (also this)compared to other developed countries which are able to offer heath care for ALL their citizens and have a cost-sharing system. People don't get severely ill deliberately, but by bad luck. A civilized society should not spit those, who are already hit by fate.

Nice S2000 collection you have there. Your car?

Depends. If you know the stack pointer, you just need 3 byte to correct the return address.

I had a 100Mhz Pentium a long time and z26 performed best.

It is more about the TV than the console. But most modern homebrews are at least switchable PAL60 or are available in both formats. And the AA store usually mentions this.

What happened to Planet Atari? Domain grabber? http://www.planet-atari.de/

What I do not understand is, why he sells NOW. The gold price is increasing and will most likely increase further. So why not wait?

This thread IS the list.

No, no, no! Make them believe those are extremely valuable and they will provide free storage space for ages. And we don't even have to finance anything now!

I am reading all speech bubbles in Nathan's comics.

The conversion quality varies. Activision only fixed the framerate and color, resulting their PAL games to be slower. Imagic usually had a PAL conversion already in their mind when writing the games, so their conversions run at identical speed. Atari is somewhere between.