Building DASM on Linux

[1FF8]

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)
  

 

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

[mgiuca]

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.

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.

[1FF8]

In hindsight, I should have expected it when I was making my list up there.

 

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

 

F8

[1FF8]

There comes a time when the best thing to do, for everyone concerned, is to turn off the life support systems.

 

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

[1FF8]

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

[1FF8]

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.

 

....

 

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).

 

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

[mgiuca]

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):

 

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.

[mgiuca]

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)

[1FF8]

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!

 

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.

 

Would you mind getting Bazaar to make further commits? Alternatively, specify a different (distributed) revision control system and hosting provider.

 

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.

 

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.

 

That's reasonable.

 

P.S. I watched the

. It was remarkable to see him go into so much detail. Thanks so much for pointing me to it.

 

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

Edited February 1, 2012 by 1FF8

[1FF8]

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)

 

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

[mgiuca]

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'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.

 

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.

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.

 

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.

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. 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.

Yeah. I can't wait to read it. I was so shocked when I ordered it and it said "expected delivery: March 14" awww

[1FF8]

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).

 

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?

 

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.

 

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.

 

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.

 

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.

 

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.

 

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.

 

Yeah. I can't wait to read it. I was so shocked when I ordered it and it said "expected delivery: March 14" awww

 

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

Edited February 2, 2012 by 1FF8

[mgiuca]

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.

 

Yeah, I agree with that. Okay, 'maintenance' then.

 

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.

 

Yeah, I think that would be really helpful.

 

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....

<snip>

 

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.

 

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.

 

Well I am in Australia too, which never helps!

[1FF8]

 

Yeah, I agree with that. Okay, 'maintenance' then.

 

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?

 

...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.

 

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. :-)

 

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.

 

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.

 

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.

 

Hospice phase? Palliative care phase?

 

Well I am in Australia too, which never helps!

 

That explains it. It takes a while because it has to go by 'roo express.

 

F8

[bills442]

Thought I would add something to this older topic just to help someone maybe like me in the future. This topic helped me just now, as I was experiencing trouble with dasm on my 64 bit ubuntu. The -m32 option mentioned will indeed solve your problems; however there can be one additional hurdle and this may help someone: Ubuntu apparently doesn't include the needed 32 bit headers and libs, so you'll get some strange compile errors looking for a header file predefs.h. You may need to do something like this: sudo apt-get install g++-multilib

that will get the multi target support stuff for the compiler; after I did that, with the excellent advice earlier, my dasm compiled and ran like a champ

 

now it's back to 6502 hacking

[+stephena]

The latest version of DASM compiles and runs cleanly on 64-bit Linux systems; there's no need to add -m32 or install 32-bit binaries.

 

Granted, this is with the very latest version, which may exhibit some other issues. But I think it's better to fix issues in the latest version, rather than trying to solve issues in old software that has already been fixed in newer releases.