|
Post by Leif Bloomquist on May 18, 2006 16:05:59 GMT -5
Six and I both use DASM ( www.atari2600.org/DASM/ ) . fuzz is using Turbo Macro Pro, and I'd certainly like to encourage development on the real hardware as much as possible. So. What's the best way to integrate everything? Ideally we'd do the main compile under DASM, so that everything is where it should be in memory and so on. fuzz could export his code to a SEQ and then somehow turn it into ASCII. Or we could assign a block of memory to him and just do an incbin of his compiled code. We'd need to handle labels manually though. I haven't done a collaborative coding project on the C64 before - has some unique challenges. Any recommendations?
|
|
|
Post by Robin Harbron on May 21, 2006 18:10:43 GMT -5
I've been involved in two collaborative projects now. For the C64-related one, we used cc65 and each (more-or-less) had our own couple source files we were responsible for. We'd email each other our updates, and it went surprisingly smoothly. Then for the latest project (mostly coded in VC++, for the GBA) we set up Tortoise SVN - tortoisesvn.tigris.org/ - and now I'll never go back. It was exceedingly handy in every way - you can leave comments in a log for each commit you do, you can see all the files that got changed with each version with an easy to use visual diff, you never have to worry about breaking anything when you're experimenting since you can revert so easily... blah blah, in short, super cool. There's a bit of a learning curve to know how to use the system properly, but once you've got it, it's totally brilliant. I think I'll use it even for solo projects from now on. I'm not too sure about how to integrate TMP in with the rest of the project - some nice perl tools already exist to do most of the work for extracting files from .d64s and so forth. If that could all be automated, could be neat. On the flip side, Fuzz is a smart boy, maybe it'd be good to just decide on one environment and insist that everyone uses it for the sake of the project? One person (probably Schema) would be sort of the "architect" and could put the project together - set up template source files, get make working, all that sort of stuff, and once it's set to go, then it's easier for other people to help out even if they're new to the environment. Getting set up properly is typically the most painful thing in a project. Well, that, and actually getting it finished
|
|
|
Post by Leif Bloomquist on May 26, 2006 14:43:12 GMT -5
We use a tool called Source Integrity at work, sounds similar to Tortoise.
For this, I think we'll be OK if we keep the # of function calls in Fuzz's code to a minimum, and define the interfaces well. Also he'll have to define any internal buffers/variables inside his memory "block" and never venture outside it.
Then he can just give me binary code to try out. Sort of like a crude ActiveX object.
I have a nice long ride to C4 next week (With Joe P. driving), and I'll have my laptop and car power adaptor. I'm hoping to code up the bulk of the game logic during the drive. (I have very little free time these days!).
|
|
|
Post by Six on May 29, 2006 11:15:07 GMT -5
Style uses Tortoise, mostly for the reasons that Robin outlined. It really takes the work and thinking out of this type of development.
|
|
|
Post by Six on May 29, 2006 11:16:28 GMT -5
fuzz is using Turbo Macro Pro, and I'd certainly like to encourage development on the real hardware as much as possible. I really need to do a Turbo Pro version of the network lib. I don't see it happening before C4, but if anyone wants to volunteer to transcribe it...
|
|
|
Post by Leif Bloomquist on May 29, 2006 11:57:47 GMT -5
I believe Turbo Macro Pro doesn't work properly with the IDE64, otherwise I'd use it a lot more.
|
|
|
Post by Six on May 29, 2006 18:59:01 GMT -5
Time to bug Elwix for an IDE64 version. Maybe I can get him to knock one out at C4...
|
|
|
Post by fuzz64 on May 30, 2006 6:57:29 GMT -5
What part of TMP doesn't work with IDE64? Also... I have downloaded DASM and am playing with it a bit to see if we get along!
|
|
|
Post by Leif Bloomquist on May 30, 2006 7:59:14 GMT -5
I used TASM on the 64 for a while, and found DASM very easy to pick up as a result.
As for TMP and the IDE64, I haven't actually tried it myself (oops), but Elwix said it probably wouldn't work right. I'll try to find time at C4 to test it, especially if Elwix is there.
|
|
Moloch
Junior Member
Posts: 55
|
Post by Moloch on May 30, 2006 11:14:08 GMT -5
|
|
|
Post by Leif Bloomquist on May 30, 2006 12:48:34 GMT -5
Yeah, I have the Turbo Assembler v5 IDE64 version. It works very well, but you can't use various chunks of memory because TASM itself uses them ($9000- and $C000, I believe.). TMP is really appealing because you can use an REU to hold stuff and effectively use the whole C64's memory.
|
|
|
Post by Six on May 30, 2006 17:59:52 GMT -5
Elwix agreed today to shoot for a version of Turbo Macro Pro for the IDE64. AFAIK, it'll use temp files on the drive instead of swap ram.
|
|
Moloch
Junior Member
Posts: 55
|
Post by Moloch on May 30, 2006 20:08:42 GMT -5
It works very well, but you can't use various chunks of memory because TASM itself uses them ($9000- and $C000, I believe. Yep, but somehow in the "olden days" we always got past that. I'm currently trying out Relaunch64 + ACME, it's my first foray into crossdev.
|
|
|
Post by Six on May 30, 2006 20:37:57 GMT -5
Actually, that limitation is why I always coded in the Super Snapshot monitor.
|
|
|
Post by Leif Bloomquist on Jun 23, 2006 17:49:22 GMT -5
OK, I'm going to go out on a limb and suggest that a mixed environment is OK. Those developing on a real 64 can send me a .PRG of their binary and I'll "incbin" it with the DASM code. Just be ready to move it around in memory if necessary ;-)
|
|