mgiuca

Yeah, I agree with that. Okay, 'maintenance' then. Yeah, I think that would be really helpful. I agree with that stuff about consolidation. It would be useful if everyone was using the same DVCS, I suppose. But in my view, Bazaar has significant usability advantages over Git. I don't like the idea of switching to what is, in my view, an almost entirely inferior system just because it's more popular. But I may eventually have to. As for compilers, I can't disagree about CC65, given that DASM is basically dead. The maintenance of DASM should (unless someone comes out and really wants to support it) be considered a transition phase. Well I am in Australia too, which never helps!

I'm not sure what's best -- I haven't worked on a project where the trunk doesn't seem to be accepting patches any more. If the 32bit branch is to be the main "in development" branch, then it shouldn't be called 32bit. Perhaps I'll rename it to 'devel'. The makeinstall changes probably shouldn't be merged until they are tested properly (I think they work okay). Were you planning to have the 'really-install' thing forever, or just during testing? I think it's okay to move that to 'install', since on most systems it will require a 'sudo' anyway. Yep. I'll probably check out cc65 at some point too, but it would be nice to leave DASM at least in a state that builds and runs successfully, even as a transition measure. Heh. Well I don't mind using Git (seeing as how everybody else uses it these days), but I find Bazaar much more natural and I'm the author of a semi-famous anti-Git rant. Yeah. I can't wait to read it. I was so shocked when I ordered it and it said "expected delivery: March 14" awww

Also, I fixed the FIXME comment in the Makefile. Is this what you intended? Rather than manually copying each machine type, I just do: + mkdir -p $(INCLUDE) + cp -r machines/* $(INCLUDE)

Great work. I hope you don't mind -- I have applied your patch to a new branch in Launchpad. If we are going to hack on DASM, we may as well use revision control rather than forum posts! Would you mind getting Bazaar to make further commits? Alternatively, specify a different (distributed) revision control system and hosting provider. In the mean-time, I applied your patch listing '1FF8' as the author since I don't know your real name. If you want me to change authorship, let me know. The branch is here: https://code.launchpad.net/~mgiuca/dasm/makeinstall It incorporates my earlier 32-bit branch. I have also made a change to your installer: I think that the .h files should be installed in /usr/local/include/dasm, not /usr/local/lib/dasm. On Unix platforms, /usr/local/lib is reserved for actual software libraries. So I have changed the install target to put them there. P.S. I watched the . It was remarkable to see him go into so much detail. Thanks so much for pointing me to it.

Whoa, that's a fantastic find. Thanks for the link. I'm going to watch the whole thing. Of all the 2600 games, Pitfall is my favourite, and I've studied a bit about how it works. It will be awesome to hear it from the horse's mouth. And yeah, that was a good guess. In hindsight, I should have expected it when I was making my list up there.

Thanks for both your responses. From reading them, and also doing a bit of investigation into a couple of Atari games, it seems my demands were probably unreasonable. I'm used to doing static analysis on nice clean high-level languages (like Haskell), where you can make a lot of assumptions (like "code is code"). In assembly language, you can theoretically write "nice clean" code that follows my assumptions, but I'm beginning to see that the machine is so constrained that everyone resorts to dodgy tricks which wreck a static analysis. It sure was a different time! Oh, right. You can't. But I don't really see that as a problem. I assume every program point would be marked as "garbage" by default, unless the analyser sees that the PC goes there, or sees that it could be accessed by a data operation. So whatever comes after an unconditional jump would just be garbage unless some other code jumped to it, and then it would be code. For example, a while loop usually ends with an unconditional jump, but then the top of the loop would jump to the line that comes after it, so eventually it would all be considered code. Ah, is that RAM on the cartridge or something? What 2600 games store RAM on the cartridge? ("Never branch to the middle of an instruction") By this one, I meant that, say an instruction was 2 bytes long. If you were to branch to the 2nd byte, you would see a totally different instruction, and as you kept stepping through, you would continue to execute a (completely nonsense) program until one of the instructions happened to land on one of the original instructions' boundaries. I can't imagine that doing this would ever be useful, but it is certainly something that could happen. Wow, awesome! So it's like seeing Matrix code? Neo could be playing Yars' Revenge and actually be reading the code as it goes by. So I assume Stella marks that as CODE then. Yeah, I guess so. And I suppose that means people have done it. Hah, crazy. Yeah I've definitely got to read Racing the Beam. I just ordered it on Amazon. They said it would be here in six weeks --- maaaan. I assume by "mirrors" you mean the fact that the top 3 bits of an address are ignored, so each physical memory location actually has 8 distinct addresses? Hmm, I was thinking that using mirrors could help static analysis a lot. But on further thinking, it probably wouldn't, because the static analysis would need to know about mirrors and consider all of those addresses to refer to the same location. This sounds intolerable on such a memory-constrained system. Hmm, I'm not sure. Is there any space saving reason why you'd need to move code after data? Why not just have all the code up front, then have data? Assuming you aren't going to be doing other fancy tricks like we discussed above.

That's a good way to phrase the problem. My understanding is that you are right -- distinguishing between code and data in the general case on a von Neumann machine is equivalent to the halting problem and hence impossible to do perfectly. However, a program that exercises a strict subset of the von Neumann capabilities should be possible to statically analyse perfectly without any dynamic analysis. To be specific about this strict subset, a 6502 program would have to: Never modify its own source code (not an issue on Atari 2600), Never branch to or allow the program counter to land on a memory location that is considered to be data, Never branch to the middle of an instruction, Never use an indirect jump or indirect addressing mode, Never directly (with an absolute addressing mode) read memory from a location that is considered to be code, Have no code in the zero page (because any zero page addressing instruction could access any data in the zero page), Have no code that is less than 256 bytes after the start of an array (where an array is a location accessed by an (absolute,x) or (absolute,y) instruction). I may have missed some, but it seems if those rules are followed, a static analysis (not necessarily the Stella one, I haven't studied it) could infer with 100% accuracy the code/data status of each byte in the program. The above rules guarantee that every memory access occurs at either a known address, or within 256 bytes of one (in the case of the (absolute,x) or (absolute,y) addressing modes). As long as there is no code within this range of uncertainty, a hypothetical static analysis could observe every reachable instruction and infer all of the data that it could possibly read or write, and the two regions would be entirely separate. I'm not sure how many games conform to the above rules, but they do not seem overly unrealistic. The only one that might be difficult to satisfy is the last one, but that can be satisfied by never having code after data. I'm also not sure why it's hard to cope with conditional branches -- couldn't the analysis simply mark both the subsequent and the target instruction as code, and continue analysing both? Anyway, interesting discussion.

Not trying to blame anyone. I think DASM, at least right now, is the easiest way to start 2600 programming. At least for the reasons you stated: tutorials mention it, and distella outputs it. So I'm happy to do a small amount of work to maintain it. He he.

Okay, I take your point. But, having read through the rest of the conversation, it looks like CA65 is more advanced, but DASM is still needed by the community. So in the true open source way, and just trying to have a "fix it quickly" solution, I have made a public fix to the Makefile to add the -m32 switch. I've opened up a project on Launchpad (https://code.launchpad.net/dasm), which is a code hosting service that includes the ability to automatically import code from other repositories. Note that this is NOT an attempt to take over maintenance of DASM, but merely the creation of a public place where people can contribute public patches to DASM without requiring the permission of the project owner. The branch located at: https://code.launchp...iuca/dasm/trunk will be kept up-to-date automatically by Launchpad (by pulling from SourceForge), so it will always be identical to the Subversion (but converted to the more modern Bazaar revision control system). I have also created a branch here: https://code.launchp...iuca/dasm/32bit which contains the one-line Makefile fix proposed by Tjoppen. Anybody who wants to can create their own branches of DASM and push them into Launchpad, just as I did. Thus, the easiest way to build DASM on a 64-bit platform is to download my branch. You will need the Bazaar revision control system. Then, just type: bzr branch lp:~mgiuca/dasm/32bit dasm and that will download my patched version of DASM. As far as I can tell, the 32-bit version of DASM is working fine on 64-bit Linux (though it isn't passing the test cases; perhaps they are old). If there is enough interest, we could build a release on Launchpad to avoid requiring that people use Bazaar to download the code. I realise DASM has had a long history of forks, and I didn't want to contribute to the mess, but if the trunk on SourceForge is no longer being maintained, then this may be a way forward. If the maintainer of the trunk on SourceForge responds and is willing to accept patches, then these branches can go away.

Fantastic coincidence -- I was just going to build DASM on Linux 64 myself just now, and found this at the top of the forum. Indeed, the compiled binary was rubbish, and adding -m32 fixes it. The last real commit in SVN was 2008, and the last mailing list post was 2009, so I assume this project is no longer maintained. It looks like Andrew Davie (who wrote the 2600 Programming For Newbies guide here) was maintaining it, but his site (http://www.atari2600.org/DASM/) is down at the moment as well.