Thomas Jentzsch

Removed by eBay police...

All Blog attachements are broken ATM. Al is working on it...

It depends on your setup. If your Atari is modded or your antenna cable is well shielded, then you shouldn't see any interference. I've had the most interferences with a homebrew (Marble Craze) which completely went away after my Atari was modded. I suppose interferences become more noticeable from modern carts because they are manufactured differently and also because some modern homebrews are using the Atari hardware pretty extensively.

Are you using an antenna cable? If yes, you should try replacing it with a good, better shielded cable. That way all interferences should become much smaller or completely disappear.

Harmony's hardware and software is tailored to the original Atari hardware, and the Flashback is known to be not 100% compatible. So before anyone successfully tested it, I would heavily doubt it will work.

Maybe, but it wasn't my idea to port it, so I would ask Trogdor first. And then I wouldn't like to do it all alone. I am mostly interested into the tricky parts, like efficient line drawings (almost done) and 3D calculations (next on my list), task scheduling (already implemented) etc. I am afraid all the other stuff will bore me soon. The collaboration with Andrew doing Boulder Dash was perfect. I was allowed concentrate on what I like. So for Elite I would need a partner. Anyone? BTW: I am not sure if I should OR or XOR the pixel. OR looks a bit better for close objects (no gaps at the intersections of lines), but for distant objects it would result into an unstructured, completely solid object, while XOR would at least give this object some kind of structure. What do you think?

Ok, now it double buffers and uses variation #1 and no XORing the pixels. This looks much better IMO. I also optimized the CPU utilization quite a bit, so we got ~15 FPS in NTSC now. I think this speed would be sufficient.

I must have missed that information about the music slow down. So the whole game slows down, right? At a certain point in the game or always?

I was afraid of having a virus for a moment.

The contents which are read from the hotspots are more or less random, depending on the dumper used. So most likes both ROMs are 100% identical.

Sure, but it was pretty expensive and the RAM was reused for several games. And it was very difficult write too, though I am not sure if that was done to cut costs. I see what I can do. The 2nd 1k are split into 4 256 bytes blocks, so I have to change my code to work efficiently with the different memory layout too.BTW: After measuring some Elite screen shots, I think I could reduce the height of the buffer quite a bit. The Elite cockpit view is 256x143 pixel, while my current version displays 96x85 (double height) pixel. So maybe 64 vertical pixel will work too. This would gain some vertical space for the cockpit display (without loosing even more CPU time) and some RAM space for the game play. What do you think?

But using something which was cost-prohibitive back then is like cheating too, isn't it? I mean, the programmers back then had to adapt to the existing, affordable hardware too.

Sure, but that wouldn't be 1980ies tech, would it? If I can improve the frame rate, I will use any free cycle. Yes. Clearing a whole screen costs ~5500 cycles, drawing e.g. 300 pixel costs ~11000 cycles. So we would gain maybe 25% more frames per second. But that would require double buffering to looks acceptable. I suppose Elite used the XOR variation because of the higher resolution. If you double the resolution, line drawing costs about twice as much time, but clearing requires 4 times as much.

The frame rate wouldn't benefit from double-buffering, but the result should look a bit better. E7 has exactly 2k of RAM, so the current 1020 bytes screen buffer would fit. But then there would be only 128 bytes ZP and 8 bytes extra RAM left. That seems not sufficient. One could reduce the vertical height a bit and gain RAM that way, but the status and radar display still has to be drawn somehow. I still have ~21 cycles/line left in the kernel, I wonder where those should be spent. Either for a nice cross-hair display (using BL + PF), or use the screen buffer for the cross hair too and spend the CPU time for some other stuff? I could clear parts of the frame buffer when using variation 1, but that's the only idea I have come up until now. BTW: The Thargon displayed has 331 pixel, so variation 1 would definitely be faster here (~25-30%).

Could be the TV getting old too. Did you try on a different TV?

Inspired by this blog entry, I spend spend some time with the line drawing part of Elite. Since there is no double-buffer (like Elite), I experimented with 3 ways of line drawing: 1. Clearing the whole screen and then drawing all lines. 2. Plotting pixels with XOR, erasing the old and immediately redrawing the new line one by one. 3. Plotting pixels with XOR, erasing all lines first and then redrawing all new lines. The constant clearing time in variation 1 slows down the frame rate when there is not much to draw, but would increase it when there are more than ~140 pixel to plot in a frame. The problem is, that unlike in variation 2 and 3, the screen is flickering quite a lot as a whole and not all lines are displayed for the same amount of time. Variation 2 displays all lines but the one currently redrawn. Unfortunately this leads to a lot of artefacts. The 3rd variation is a compromise between 1 (all lines displayed the same amount of time) and 3 (less artefacts), which IMO looks best and seems to be the way Elite draws its lines too (maybe someone can confirm this?). Attached are NTSC and PAL binaries (using E7 bank switching) plus the source code (if anyone is interested, nothing too special) displaying a single Thargon. The code tries to use the free CPU time (pretty imperfectly) which is much larger for PAL. Therefore the PAL version runs much faster. Still both are not running very fluently even though the status display and any 3D movements and transformations are still missing. There is a little room for improvement (like self-modfying code and better CPU time utilization), but I am not very positive this would gain enough to get close enough to an acceptable frame rate. Thargon.zip Thargon v0.02.zip

Auf die Texte hab' ich ehrlich gesagt bisher kaum geachtet.

IIRC some AA member posted this a few months ago.

http://www.youtube.com/watch?v=G_ITf7u4XRA

I had almost forgotten how good this music is. If you like this, make sure to check out your their new album! http://www.youtube.com/watch?v=PJFShE1VfEc http://www.youtube.com/watch?v=gqU_0xpILIU http://www.youtube.com/watch?v=wn9FevDdcLU& http://www.youtube.com/watch?v=TjoQiqY9MN4 http://www.youtube.com/watch?v=M8sFupDAwvo

I had some fun doing some real line draw coding on the 2600 over the weekend, 35 cycles/pixel turned out to be a very good guess. One could save maybe 3 cycles by using self-modified code. Regarding double buffering, I had a closer look at C64 Elite again. It seams that is it XORing the pixels. Which means, instead of clearing the RAM, you can draw the same line(s) again and erase them that way. No double buffer needed in this case. Clearing the RAM takes ~5000-5500 cycles, you can clear maybe 140-150 pixel with XOR in the same time. Not too much. The 2600 Elite ship displayed above consists out of about 650 pixel, so drawing and erasing it once with XOR will take ~45500 cycles, which is about 600 scan lines, which equals the free CPU time of maybe 8-10 frames. Now I wonder if there are any news about this.

http://www.videogamecritic.net/2600hl.htm#Juno_First

You got the final result wrong. It will be 3:0. After penalties!

No, I never do documentation. Unfortunately I am pretty busy over the next weeks, so most likely I won't have time to look at the code again. Maybe someone else can help?