1FF8

I just put a new flex circuit and gold buttons in a controller for the 5200 I bought new back in--well, it had to be between '82 and '84 I suppose. The buttons work great now, I'm going to do the other one this evening. Assuming they last better, it seemed worth doing. I still want a digital stick for Joust, though, one that doesn't force me to mash buttons with the wrist rotated around. F8

I'll second this.

You can't agree with me! I change my mind! Well, seriously, it just occurred to me that even 'maintenance' is dangerous, in that it invites people to send you general bug reports to fix. I doubt you want to do that, and I sure won't. I don't mind patching a few lines in a makefile, but I'm not doing anything that requires me to understand the code. How about calling it a "life support" branch? Or is that still too permanent? "Hospice" branch? Valhalla? Yeah, I think that would be really helpful. Well, I spent a little while building a makefile with rules suitable for dasm, since dasm was what I was already working on before the ca65 thing came up. After installing as per the makefile target in your makeinstall branch, you can just add your sources to one variable and have it all build easily. It's tempting to just go and play more with the code now, but I think I should do the same for ca65 first or I'll get used to an eol'd assembler myself. That is the sort of thing I thought a lab notebook thread should have. A propos of nothing, did you notice that the original author of dasm is the Dragonfly BSD guy? So free unix is on-topic here. If you squint. :-) It's hard to beat the marketing power of having Linus' name on the product. This is why I didn't try to learn a dvcs until I started noticing git pulling out ahead. I knew if I really liked one, it would lose anyway, so I decided to sit this war out and not even know what I was missing, then enthusiastically join the winning side and try to look like I've been there all along. Hospice phase? Palliative care phase? That explains it. It takes a while because it has to go by 'roo express. F8

I guess I'd call it a maintenance branch. "Development branch" suggests plans to develop the main codebase. Is anyone thinking of hacking on the dasm source? I don't think so, and by all accounts it would be both painful and pointless. cc65 is impressing me so far, it's actively maintained and well documented. I can see why Andrew wants everyone to migrate, and I think he's right--it just looks like there is a lot of old code that assumes dasm and there isn't enough community documentation for ca65 yet to help n00bs like me move to it easily. Nobody has come out and said that ca65 can assemble most of the legacy code, but when I get around to it I'm going to test the dasm-compatibility settings listed on the cc65 wiki. If it can assemble something like the annotated combat code, then maybe dasm isn't as necessary as it looked to me when I started looking at this stuff. It may be that major barrier is no more than that all the docs are written for dasm, but nobody has commented on the idea of adding lab notes to the tutorial(s) yet. That said, ca65's documentation for 2600 development is certainly better than dasm's (which doesn't have anything comparable), it's just the community docs that all specify dasm. So the route forward is there, I just haven't come across much community help for the n00bs yet. Maybe that can be fixed? Plan? Plan?!? I have no plan--I just read Andrew's tutorial up through number 8, where I needed a toolchain, and now I'm fumbling around to get a setup I'm happy with so I can continue. I just hacked in something that would work for me, but didn't want any responsibility for what it might do on someone else's machine. Yes, that's all I thought of fixing the makefile as--a transition measure. Barriers right at the beginning are the worst kind of barriers, and I wanted to make it easier to assemble your first code and follow the tutorials. For that, it would be nice if there was code that would build and install. It's still easier to do that with dasm, at least until someone goes over the tutorial code and makes it transparent to assemble with ca65. If I keep having time to do this stuff (or rather, keep robbing time from other stuff), and the community likes the idea, maybe I'll manage to help with that. Hmm. I'm the author of a completely-unknown meta-rant, mostly about free unix but also a bit about basic tools like this. This is way off-topic for AtariAge, but.... What I care about is that (1) the free unices (and everyone else who is willing) moves to a good free dcvs, and (2) there be a standard one to minimize impedance and the number of basically similar but incompatible systems I have to learn. There was some community value back in the days when *everything* was in cvs, simply because you knew how to check out any project you'd ever care about (no matter how hideous CVS is, it was *standard* hideousness. ) Only bzr, hg, and git seem to be reasonable candidates, and I wouldn't really care which of the three the community standardized on. But git seems to have won, and so that's what I use in order to further consolidation. I felt the same way about "the standard free unix"; at one point I thought BSD would be the better choice, but Linux won and it was important to have a winner. The counter argument is that it is often value to have two contenders competing--for example, I was probably wrong about how much consolidation was desirable, and instead it's probably good that neither linux nor bsd eliminated the other. Perhaps that is true in the dcvs space? Maybe, if the three rational contenders are cross-pollinating in a productive way. I'm not frankly sure of the answer, but my selfish interest is better served by making any choice (among the decent dcvs choices, of course, not something awful) than in what that choice is. It may be that we've reached the point where we need to consolidate second place between bzr and hg so that we can minimize project impedance while keeping git from slacking off. (My impression is that hg is more or less the second place finisher in the popularity contest, but I may be wrong given Canonical's backing of bzr.) We've also benefited by having a standard free C compiler, but I thinndof decent linux distros is clearly counterproductive, though ubuntu has been consolidating that space a fair bit (and that could be why bzr is still a viable contender). The only possible relevance for this on AtariAge is that version control probably isn't exploited as much here as it could be. Teaching one is bad enough, so that's why it's helpful to have a standard one providing a lingua franca for everyone who wants to freely share their development process. I suppose it's also relevant that the atari community isn't big enough to maintain their own toolchain, at least not easily, so there is no possibility of constructive competition. It makes all kinds of sense to share the toolchain with the rest of the 6502 community. What I've gathered from the web is that cc65 is pretty much the standard C compiler for 8-bit Ataris, C=, maybe Apple ][, and just about everyone else that still writes 6502 code, so it looks like he's totally correct that it would be good to standardize on it. Huh. I got mine recently from Amazon, which is probably where you ordered from. I guess I got in on the tail end of the last shipment. F8

That's better than what I intended. I was going to stick a loop in there over the subdirectories, but that's doing it the hard and stupid way. cp -r is perfect. F8

I don't mind at all, though I'd have just made it a new commit on your 32bit branch. Unless you want to have a main bugfix branch and then merge in individual fixes separately. I have bazaar, that's how I checked out your code. I wasn't planning on doing enough dasm hacking to want to make a separate repo, though--I'm gaining confidence in ca65 as the preferred alternative, since I sent in the makefile patch to the author last night and got a response this morning thanking me for the patch and saying it was already fixed in svn. So now I know cc65 is actively maintained, a *big* plus. The other thing is that git is the only decent revision control I know. That's not a reason for *you* to use it, just means I'm lazy. That's reasonable. Yeah. Most of it is in Racing the Beam, if you want it on paper. They're probably not independent sources--David Crane speaks highly of the book and points out one of the authors in the audience, so they know each other. I'd guess it's pretty likely that the authors got their information for the Pitfall! chapter directly from him. F8

Same for me--builds and seems to work, but doesn't pass all tests. Well, it *does* say to ignore them.... I suppose Andrew won't like using up medical supplies on the terminal patient , but I added an install target to the top-level makefile. Here is a patch (I wish I could just attach it to the post): --- Makefile 2012-01-31 21:37:50.816472000 -0800 +++ Makefile.install 2012-01-31 22:25:07.870720160 -0800 @@ -28,13 +28,38 @@ # TODO: need to do documentation stuff as well; don't forget to # delete automatically generated documentation in clean: below +# For install--edit to taste +PREFIX=/usr/local +BIN=$(PREFIX)/bin +LIB=$(PREFIX)/lib/dasm + # just an alias for build really... all: build echo "Build complete, use 'make test' to run tests." -# install, currently not implemented +# install, now hacked in--use at your own risk! install: build - echo "Installation not implemented, you're on your own, sorry." + @echo + @echo "The installation target is just an experimental hack; if you're" + @echo "foolish enough to want to use it, type 'make really-install'" + +really-install: build + @echo + @echo "Installing to $(PREFIX)..." + @echo + cp bin/dasm bin/ftohex $(BIN) + # FIXME: This should be a loop on the machine/ subdirs! + mkdir -p $(LIB)/atari2600 + cp machines/atari2600/* $(LIB)/atari2600 + mkdir -p $(LIB)/channel-f + cp machines/channel-f/* $(LIB)/channel-f + @echo + @echo + @echo "Machine-specific include files are in $(LIB)/<machine>/" + @echo + +uninstall: + rm -rf $(BIN)/dasm $(BIN)/ftohex $(LIB) # just run all the tests test: build I'm going to try out the dasm compatibility hacks suggested on the cc65 wiki, but I'll want to be able to verify that I have valid dasm code before I try to make it assemble with ca65. Actually installing it makes that more convenient. F8

I got around to installing cc65, and discovered that it also has a wonky makefile, though in this case it's just a shell syntax fail. The board won't let me attach a patch file, but here it is: --- gcc.mak 2012-01-23 10:00:19.489705994 -0800 +++ gcc.mak.new 2012-01-31 18:01:28.094948242 -0800 @@ -113,9 +113,9 @@ @echo 'LD65_OBJ=$(LD65_OBJ)' @echo @if [ -x $(bindir)/grc${EXT} ]; then \ - echo 'grc was renamed to grc65; but, a grc command is in your binaries directory.' \ - echo "If that command is an old copy of CC65's program," \ - echo 'then you should use a "${MAKE} erase-grc" command to remove it.' \ + echo 'grc was renamed to grc65; but, a grc command is in your binaries directory.' ; \ + echo "If that command is an old copy of CC65's program," ; \ + echo 'then you should use a "${MAKE} erase-grc" command to remove it.' ; \ fi .PHONY: install-test For those who don't, find the lines in cc65/make/gcc.mak that look like the ones above that start with '-', and make them look like the ones that start with '+' (i.e. add semicolons just before the backslashes on the end of the lines). I also went through the on-line cc65 docs enough to find that somehow I'd gotten the wrong idea--cc65 does come with a disassembler, da65. Apparently I just can't read, but that means that distella isn't such a necessity after all, even aside from the discussion about dynamic vs. static disassembly. Now to see if I can get ca65 to assemble some tutorial test code, if I can stay awake that long. F8

Hmm. For dasm, or for potential new 2600 programmers? The problem is that I'd say you (all) are still at the point where doing the first means doing the second. What about having some "Lab Notes" threads for each lesson which (I hope) could get added to the chapter index stickies? Basically a lab for each chapter, intended to be read after the chapter. The lab notes would contain machine-specific help and especially (given the current discussion) ca65 versions of your example code. I might be able to contribute some of this simply because I'm working through it at the moment. For example, the following would be appropriate for your chapter 8: Ch 8 Lab: obtaining source and building dasm and ca65 on Linux, ca65 versions of the example code (yours, and perhaps of the more interesting examples in the comments). I really hate to even suggest I do that, because I can't be regarded as a competent 6502 hacker, but the only time I'm motivated to write docs is when I need them myself. Someone would *definitely* have to provide technical review, however. Which, I guess, is no different than giving a first-year grad student a lab section to TA, whether or not they're ready for that. Poor students. The fact is, I'm stealing time for this in the evening or random times when I should be playing games with the kids, polishing the resume, or writing some completely different code, and my ability to do that could end at any time. But even if life makes me drop off the face of the Earth, maybe it would be helpful if I got something started to reduce one particular dependency on dasm (the tutorial)? On a somewhat different subject, I also built cc65 while I was waiting for a job to finish, and while it's a bit eccentric to require 'make -f' and I'd rather they use a higher-level build tool, I can say that the build was clean and at least the makefiles are far better written than those for dasm. That gives a bit of confidence in the overall code quality, at least. F8

My deep, insightful principle was the belief that nothing is too crazy for a 2600 programmer. That belief has been reinforced yet again. F8

Generally, yes having the program in ROM makes it kinda-sorta Harvard-like. But in full generality, I'm not so sure. 2600 programming seems to have involved such extreme optimization that I wouldn't bet people didn't squirrel little bits of code in RAM just so they could be re-written. That might be a good way to avoid short conditional branches in a display kernel, mightn't it? Just compute a couple of instructions (it has to branch out of RAM, at minimum) during your game logic and then execute them unconditionally in the time-critical sections. Amazingly, I was right. Here David Crane mentions doing this: "...sometimes you had to write code in ram...self-modifying code and execute code in ram because it ran one cycle quicker in ram...." I feel kinda good about guessing that, given that I'm not a 2600 programmer. I'd better shut my mouth before I screw up and ruin it. F8

Haskell is about as far from machine code as it's possible to be without just talking to the computer in English. :-) And actually, come to think of it Haskell is further than English, because English has a rich and expressive vocabulary about state. It's hard to overstate how misleading Haskell would be in guessing about machine code. Let's see--for starters, the core of Haskell starts with the absolute determination to eliminate all traces of explicit state (or at least imprison it in monads where decent folk don't have to see it), and going to any length to provide alternative abstractions. But assembly is all about state and nothing but state, with no other abstractions allowed unless you implement them by hand--with state! Haskell: the anti-assembly language. I'm totally comfortable in C, which is a lot closer, but actually still far too high level. For one thing, C subroutines still have hygenic, completely well-behaved parameters, which is maybe the single most useful abstraction you can have if you can only have one. I don't think they're dodgy, not in the context of the 2600. That's like saying that soldiers' gear is gauche because it would look gauche at a Hollywood dinner party. In the context of combat, the rules for Hollywood aren't relevant. :-) But you're totally right about the constraint. If I were writing x86 assembly to run on a Linux machine, even a slow one, I'd naturally use proper function calls with parameters pushed on the stack (or wherever the platform spec specifies). First, I have to call the C library to do anything but invisibly flip bits on unix, and second I desperately need any simplifying abstraction I can get away with. I can afford hygenic parameters in my assembly on any machine capable of running the Linux kernel. But on the 2600, it appears to me that you're seldom or never going to be able to afford pushing parameters (IIRC the 6502 is slow with stack gymnastics anyway), so you *have no subroutines*. Just stretches of code you can call with jsr, but with all parameters global and implicit (at best, the comments will document what registers you trash and what global state you mess with). Forget monads, and algebraic reasoning, and statelessness--*you have no subroutines (at least in your display code).* Think about *that*. I think that's the attraction. A high-level language defines a virtual machine for which you write code--basically, we decided we couldn't handle what the machine really is (a little state machine with only very simple operations--the VAX excepted, that's a state machine with hideously complex operations ), so we imagined a machine we could write for more easily and then simulated that easier machine. Then we wrote libraries to extend the vocabulary of primitives and make it even easier. That is to say, we couldn't handle reality and asked for a blue pill, please. (If you code in Haskell, you asked for a continuous IV feed of unreality drug. ) By contrast, the 2600 is the purest machine for which there is an audience (well, we could quibble about microcontrollers, but people rarely appreciate the code in an embedded device). There isn't any firmware, nothing but what you put then. And you can't afford to lie to yourself about the machine, so you must face up to what the machine really is. For a certain kind of programmer, it's the ultimate red pill. Well, OK, at least *I* appreciate that. And I think Ed Fries is right that, oddly enough, that kind of extreme difficulty is conducive to art. ("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. I don't claim to be good enough to do it, but I can certainly imagine it being useful. Here is another example of "Heroic age" programming, the story of Mel: http://www.cs.utah.e...lklore/mel.html Mel wouldn't have any problem with finding a way to re-use at least a couple of instructions that way. By his standards, the 2600 is for softies. Hmm...you know, it could be automated--you could write a tool to search for instances of very short routines in other code, in fact it could be done automatically in an optimizing pass. I'd write it by searching for bytes with the opcode for jsr and then then comparing backwards with what I need. If you write code with a lot of subroutines with only a few instructions (which, granted, may not describe 2600 coding specifically), you might eventually get a hit. That's pretty much how you'd do object-oriented programming in assembly--you often end up writing tiny little methods (granted, this is definitely not suitable for the 2600). I've written more than my share of C++ methods that did nothing but increment a field, and that might only be an inc, a two byte address, and an rts. It doesn't seem that unlikely to find four specific bytes (or whatever it ends up being when you dereference an object pointer, my 6502 isn't good enough to visualize it without paper) in unrelated data. While those might be unlikely things to do on a 2600, that's also the only place so memory-constrained that the payoff would be worth it. Say--has anyone proposed writing a cartridge optimizer for the 2600? That would be a rather neat hack. The result would be incomprehensible when disassembled, but that's OK. Yeah--the code that is actually executing to create his enemies at that second. I suppose so, at least once. Maybe just to impress their coworkers, at a minimum. That's what I meant, though I'm not experienced enough to know whether what I said precisely made sense. That's why I'm posting in the beginner forum. 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? Because you're putting routines in front of data that happens to be RTS, and thus interleaving code and data. O Oh, well, if we can just assume that people aren't going to do the tricks the platform is renowned for, I assume that I was just given the exhaustively documented original source and don't need a disassembler. Done. F8

Yes, a von Neumann machine can emulate any machine, so it can emulate a Harvard machine. :-) Generally, yes having the program in ROM makes it kinda-sorta Harvard-like. But in full generality, I'm not so sure. 2600 programming seems to have involved such extreme optimization that I wouldn't bet people didn't squirrel little bits of code in RAM just so they could be re-written. That might be a good way to avoid short conditional branches in a display kernel, mightn't it? Just compute a couple of instructions (it has to branch out of RAM, at minimum) during your game logic and then execute them unconditionally in the time-critical sections. Oddly enough, I just read this: "Bob Whitehead moved one of his subroutines so that it ended just before a block of sprite data....In this case, the first line of the sprite data was the hexadecimal value $60, which also happens to be the machine reference for the opcode RTS." -- Racing the Beam, p103. I don't know if there are useful instances of that or not. I would think that not using indirect addressing would be an intolerable limitation. Not sure about indirect jumps, but code pointers are super useful (a much more usable way for a program to set up the code to be executed during display, for example). I don't know if there are other examples "in the wild" besides Yar's Revenge. For a cartridge without extra ram, any code in ram would be code in zero page. Maybe if it were only accessed through one of the mirrors? This sounds intolerable on such a memory-constrained system. It's certainly educational to me. F8

This is extremely interesting. I had wondered how well a disassembler could work (never having used one) on a van Neumann machine, since IIRC distinguishing between code and data is equivalent to the halting problem (I didn't check to see if that's correct, but handwaving suggests it is)--when and if there is a difference, since those are not exclusive categories. You have answered the question--my gut feeling was right, and the best disassembler has to execute the code. I've barely scratched the surface of Stella's amazing array of abilities. Can it output the disassembly in a format suitable for re-assembly? If not, could it? It seems that rather than considering breaking the code out, stella itself is really the only thing capable of being the community's standard disassembler. And if it could do so in ca65 format, that would remove one of the legacy dependencies on dasm. I doubt that is a feasible thing for you to add to your plate, I'm just thinking through the dependencies on dasm I found as a beginner. And if there is a well-defined interface, it would at least be easier for someone else to hack on the disassembler without impacting the rest of the codebase. Really just thinking to myself here, but thanks very much for extending my understanding of the whole disassembly problem. F8

Just to keep blame where blame is due, I'm the only one who actually said dasm still looks needed, and I'm a newcomer poking around and making guesses. At best we can say nobody has yet said I'm wrong, but they haven't said I've guessed right either. Heh. I seem to recall a talk in which the Cinepaint maintainer said that is precisely how he became the Cinepaint maintainer. F8