Tom

Just don't forget: for an assembler to get any acceptance at least in the Atari 2600 community it needs to be DASM compatible (either by being compatible itself or by being powerful enough to make it able to compile DASM sources using macros or so).

Have you seen the newer Python versions of p65 ? Even if you're not going to use them, you might want to look at them anyway. They seem to be fairly well written.

~llama: You know, awk has been somewhat obsoleted by languages such as Perl, Python, Ruby and the likes. If I was you I'd stay away from it and use Perl (or learn Ruby:)

I sure don't mind. (With the "so what" I btw. didn't mean to say Ruby is superior to Perl [although I think it is]. What I meant is that I wouldn't worry too much about using <insert-favourite-interpreted-language> instead of C.)

So what ? If I'll ever get around to writing my own assembler I'll write it in Ruby and make it somehow interpret Ruby code embedded into the source code.

That's where gas sucks at for several reasons (stupid non-standard AT&T syntax, limited real mode support, ...). I've written quite a bit of ARM (ARM and Thumb) code with gas, both as inline assembly with gcc and standalone, and it's great. Seriously, before you go and write your own 68k assembler, try out gas and other available assemblers (don't know any from the top of my head that might be worth looking at).

That's why I was asking. Binutils is no problem. Getting Binutils, GCC and a C Library to work however is a bit harder. And it gets really fun if you want your toolchain to compile C++ programs. Although I haven't used gas for writing 68k code I can only recommend it (except for writing x86 code. NASM is better for that).

Was going to suggest the same, but why do you think this needs any bravery ?

You know, you could also just write a game YOU want to see on whatever platform. That's usually the most rewarding thing...

No wonder, iirc they stated they're using Perl AND M4. I'd have gone mad long time ago if I tried that

No, to my knowledge no carts have been made. You can get the binaries and source code here: rfk7800.sourceforge.net. Anybody feel free to make and give away/sell carts yourself, just make sure you understand the license.

Not the creator of the original version, just one of many fans and porters I did the Atari 7800 version, yes.

Glad I didn't have to point it out myself this time. It's spelled all together and in lowercase, though. Like so: "robotfindskitten". Sorry, I just had to

This is a neat opportunity for me to point out that the World's best Zen Simulation has been ported to the 7800 quite some time ago

I love it. Had to find new hobbies, though, because since I'm not studying anymore but working as software developer I don't have the urge to work on software projects in my free time anymore (I used to spend a lot of time with that). Well, I picked up paragliding and am thinking about taking karate lessons.

I have two PAL juniors. Looks like I have to dig them out. What I know is what works on at least one of them is achieving an 8 pixel left shift by triggering HMOVE out of specs. I think that was an experiment with a 12/24 char kernel that moved the sprites left/right per scanline. How so ?

You get the HMOVE lines if you follow the stella manual and trigger HMOVE right at the start of a scanline. There are certain cycles (74 ?) where you can trigger HMOVE and get exact the same behaviour (same amount of movement for same HMxx value) without the HMOVE lines. See http://www.biglist.com/lists/stella/archiv...4/msg00198.html Does this work reliable on any 2600, btw ? There are also games that trigger HMOVE on every scanline, which results in a black border over the whole left of the screen. Still better than garbage moving around to the left of the screen, imo.

I told you already not to start staring at disassemblies right away. You won't get anywhere with that little bit of knowledge you have...

There were commercial games that used such bankswitching schemes. Nonsense. Last time I checked the z26 source looked as if it was fairly trivial to add new bankswitching schemes.

Actually the L in LGPL stands for "Lesser" nowadays. Was changed somewhen because "Library" confused some people to think the LGPL was applicable for libraries only or that the GPL was not suitable for libraries.

Reverse engineering is the simpler the better you know the engineering bit without the reverse thingy. That said, I recommend looking at Andrews tutorial first. Looking at game source codes or disassembling games is good for learning advanced techniques. Reading Andrew's tutorial will also help you to spot common Atari 2600 programming idioms. This will greatly help you when you're actually ready to disassemble and analyze a game.

sta.w Temp4

You mean probably this design: http://www94.pair.com/jsoper/bankswitch_f8.html

Now this thread was fun to read

They're programs to compose music, typically they have an interface like this : http://en.wikipedia.org/wiki/ScreamTracker (Scream Tracker was a fairly famous tracker that ran under DOS). The Amiga / PC trackers usually worked with sampled sounds, but for instance the C64 trackers of course use the SID. Yes. Several people have worked on such editors, including a friend of mine who made the sound for this intro : http://www.pouet.net/prod.php?which=13900. That editor has never really reached a usable state. First of all it doesn't optimize the tune (it allows you to enter duplicated patterns, which is ok, but it should optimize them away) and second it needs an emulator to play the sound, which is inconvenient. It's neither hard to write a VST plugin nor is it hard to rip out the sound emulation part out of a 2600/7800 emulator (at least Stella and emu7800 are kept fairly modular), so that could probably be done quickly, although I think an editor that is tailored to Paul's music driver would be more useful.