Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > C64 Coding > Assembler preferences.
2016-02-09 06:03
ChristopherJam

Registered: Aug 2004
Posts: 1409		 Assembler preferences.

Two questions:
- what's everyone using these days?
- on large productions, do groups tend to enforce a single assembler for the entire project, or is the code base a bit heterogenous?

I'd like to keep this discussion purely focussed on assemblers; please leave code generators, loader toolchains etc for that other thread.


(as for me, I'm still using xa65 for most projects)
2016-02-09 06:34
Martin Piper

Registered: Nov 2007
Posts: 722		 I only use one: https://github.com/martinpiper/ACME
But then I work alone and just give away my code. ;)
2016-02-09 06:54
Mixer

Registered: Apr 2008
Posts: 452		 64tass

Larger projects tend to end up written on multiple assemblers depending on individual preferences.
2016-02-09 07:38
Oswald

Registered: Apr 2002
Posts: 5094		 64tass
hetero
2016-02-09 07:49
Flavioweb

Registered: Nov 2011
Posts: 463		 64tass
2016-02-09 08:02
Karmic

Registered: Apr 2015
Posts: 66		 64tass, all the way. :)
2016-02-09 08:27
T.M.R
Account closed

Registered: Dec 2001
Posts: 749		 i'm an ACME bunny.
2016-02-09 08:50
Bitbreaker

Registered: Oct 2002
Posts: 508		 <- Strict ACME fanboy. On projects any assembler is allowed that is able to work within a make-environment. It must accept external information liek labels and one should be able to implement a few simple macros for linking.
A project with acme, dreamass, dasm, c6510, kickass all in a mix, is no problem this way. Kickass however handles the handover of external information a bit different, so no -Dlabel=foo stuff available there, but integration is doable after finding out the differences.
2016-02-09 09:07
Frantic

Registered: Mar 2003
Posts: 1648		 ACME in general and specifically for a cartridge project I'm using DreamAss.
2016-02-09 10:40
lft

Registered: Jul 2007
Posts: 369		 xa65 here.
2016-02-09 10:46
JackAsser

Registered: Jun 2002
Posts: 2014		 ca65
2016-02-09 10:53
Shadow
Account closed

Registered: Apr 2002
Posts: 355		 KickAssembler for me.
I tend to avoid working in "big" demo projects and prefer to do all the coding myself, so I avoid the problem with different assemblers alltogether...
2016-02-09 12:51
algorithm

Registered: May 2002
Posts: 705		 acme and notepad all the way! :-)
2016-02-09 13:59
Pantaloon

Registered: Aug 2003
Posts: 124		 Kick Assembler
2016-02-09 14:07
AlexC

Registered: Jan 2008
Posts: 299		 Answering only first part of the question since I don't have experience with large projects.

Mostly TMPx + TMP - this gives me opportunity to work on my projects using the (almost the) same syntax even if I code directly on c64. This is handy when using features not emulated right now like Turbo Chameleon64 for example.

DreamAss used to be my number 1 and still is useful for cartridge development due to segments feature (I'm not saying that other assemblers don't provide similar features it's just that this was the first assembler I've tried for it and it had it). DASM due to exomizer usage of it.
2016-02-09 14:51
null
Account closed

Registered: Jun 2006
Posts: 645		 ACME for crossdev and whatever version of TASS is built into the default RR/MMC-Replay ROM on the real thing.
2016-02-09 15:17
Stone

Registered: Oct 2006
Posts: 172		 ca65 (customized)

Most of the parts in our (Offence/Fairlight/Prosonix) demos are completely stand-alone and are called as subroutines from the loader. They are delivered to whoever is doing the linking (Pantaloon in most cases) as binary files, so there is no need to enforce a single assembler.
2016-02-09 17:08
chatGPZ

Registered: Dec 2001
Posts: 11386		 not that using different assemblers is a problem.... with proper assemblers =)

acme, ca65, 64tass, xa (this order)

the framework i have been using for the last demos allows for different assemblers, packers, loaders being used on a per part basis.
2016-02-09 17:12
HCL

Registered: Feb 2003
Posts: 728		 DreamAss and Emacs, but.. Haven't we had this "discussion" already?
2016-02-09 17:21
chatGPZ

Registered: Dec 2001
Posts: 11386		 not today
2016-02-09 17:55
Slammer

Registered: Feb 2004
Posts: 416		 Quote:
A project with acme, dreamass, dasm, c6510, kickass all in a mix, is no problem this way. Kickass however handles the handover of external information a bit different, so no -Dlabel=foo stuff available there, but integration is doable after finding out the differences.


Bitbreaker: If there are features that would make integration easier, feel free to add it to the wishlist. Its in the RetroAssembler group.
2016-02-09 18:06
TheRyk

Registered: Mar 2009
Posts: 2244		 Quote: Two questions:
- what's everyone using these days?
- on large productions, do groups tend to enforce a single assembler for the entire project, or is the code base a bit heterogenous?

I'd like to keep this discussion purely focussed on assemblers; please leave code generators, loader toolchains etc for that other thread.


(as for me, I'm still using xa65 for most projects)

- ACME
- larger productions: makes things easier if everyone uses the same, but normally someone experienced enough to code for such a production is also skilled enough to press CTRL+H and adjust syntax, e.g. from KickAss to ACME, has become even easier since ACME also accepts +/++/+++/-/--/--- labels
2016-02-09 18:09
ChristopherJam

Registered: Aug 2004
Posts: 1409		 Quote: DreamAss and Emacs, but.. Haven't we had this "discussion" already?

Eh, not that recently. Was wondering what current practices are, and the "Coding on a PC for the 64?" thread is way broader in scope than the two questions above.

(and oi, no text editor wars under this topic please!)
2016-02-09 18:17
soci

Registered: Sep 2003
Posts: 480		 64tass, for a long time now.
2016-02-09 19:02
Fungus

Registered: Sep 2002
Posts: 686		 64tass
2016-02-09 19:10
DKT

Registered: Aug 2004
Posts: 99		 I'm Acme user.

So, the results are (up to now):
1st) ACME (37%)
2nd) 64tass (26%)
3rd) KickAssembler and ca65 (11%)

;-)
2016-02-09 19:15
MagerValp

Registered: Dec 2001
Posts: 1078		 ca65
2016-02-09 19:16
4mat

Registered: May 2010
Posts: 66		 Dasm
2016-02-09 20:29
Digger

Registered: Mar 2005
Posts: 437		 KickAss only :]
2016-02-09 20:30
AlexC

Registered: Jan 2008
Posts: 299		 Quoting Slammer

Bitbreaker: If there are features that would make integration easier, feel free to add it to the wishlist. Its in the RetroAssembler group.


Even my love for asm will not make me to join FB. Do we really need to discuss assembly language using Facebook? ;-p
2016-02-09 22:33
enthusi

Registered: May 2004
Posts: 677		 xa (floodgap). used to be acme before
2016-02-09 23:19
Ksubi
Account closed

Registered: Nov 2007
Posts: 87		 64tass
2016-02-09 23:30
Fix

Registered: Feb 2003
Posts: 54		 Acme since it's fast and easy to use...

For more complex stuff I'm looking into CA65 environment.
2016-02-10 07:53
Compyx

Registered: Jan 2005
Posts: 631		 Dreamass, but since that one doesn't seem to be actively maintained anymore, I'm looking into 64tass.

I agree with HCL here: we've had a similar thread recently on development environments, just ignore the text editors, Makefile's and scripts and you're left with a huge list of assemblers people tend to use ;)
2016-02-10 11:49
Perplex

Registered: Feb 2009
Posts: 255		 Assembler? I thought everyone entered the code as DATA statements? (cue Four Yorkshiremen...)
2016-02-10 12:29
MagerValp

Registered: Dec 2001
Posts: 1078		 Results so far:
  10 acme
   9 64tass
   5 ca65
   3 kickass
   3 dreamass
   3 xa
   2 dasm
   1 tmpx
2016-02-10 13:06
TWW

Registered: Jul 2009
Posts: 545		 ACME? Thought that was this Company in Loony Tunes which produces the 10T weights which keeps dropping on Wild'e Coyote's head?

For me it's Kickassembler and also the rest of the Group (although only JAS has fiddled some With it... some years ago.....).......

Damn!
2016-02-10 13:21
Perplex

Registered: Feb 2009
Posts: 255		 Since DATA didn't make it onto the list, here's another vote for ca65.
2016-02-10 13:28
Shine

Registered: Jul 2012
Posts: 369		 Long time ago i tried Acme ... only for simple sprite movement! And somehow i liked it. ;)
2016-02-10 14:03
Knut Clausen

Registered: Apr 2013
Posts: 18		 KickAssembler. We use several different assemblers in our demos.
2016-02-10 14:10
Kronos

Registered: Apr 2002
Posts: 7		 KickAssembler
2016-02-10 16:50
Axis/Oxyron
Account closed

Registered: Apr 2007
Posts: 91		 Dreamass
2016-02-10 16:53
Mr. SID

Registered: Jan 2003
Posts: 424		 Only fools would not use k2asm, and I'm not one. :)
2016-02-10 20:23
Murphy

Registered: Jul 2006
Posts: 11		 KickAssembler
2016-02-10 22:25
Cruzer

Registered: Dec 2001
Posts: 1048		 KickAss
2016-02-10 22:26
AlexC

Registered: Jan 2008
Posts: 299		 Useful addition to current discussion would be explanation why particular assembler is being used IMHO.
2016-02-10 22:31
Pantaloon

Registered: Aug 2003
Posts: 124		 AlexC, don't go there :)
2016-02-10 22:32
Peiselulli

Registered: Oct 2006
Posts: 81		 ACME - because if I miss a feature or find a bug, I can write to the developer directly to fix it in a new version very fast ;-)
And I'm too lazy to build my own.
2016-02-10 22:47
Karmic

Registered: Apr 2015
Posts: 66		 Peiselulli: What, ACME is still being developed? :)
2016-02-10 22:54
AlexC

Registered: Jan 2008
Posts: 299		 Quote: AlexC, don't go there :)

Sorry - I know I'm stepping on very thin ice but I can't resist ;)
2016-02-11 00:05
Fungus

Registered: Sep 2002
Posts: 686		 Crossbow would write SMON
2016-02-11 07:08
Slammer

Registered: Feb 2004
Posts: 416		 Mr Sid: I checked out K2Asm and saw you have bracket scopes for avoiding clash of labels. Nice, I thought KickAssembler was the only one to support this style :-) (And that I was one of the only ones to used it, since people have gotten use to referencing back and forth with multilabels)
2016-02-11 07:50
Axis/Oxyron
Account closed

Registered: Apr 2007
Posts: 91		 @AlexC: I guess 90% of the people will awnser "I someday started cross-dev with this asm and now I´m used to it". As a coder you also build a kind of a framework of libraries and code-snippets you always re-use. And no one feels like porting all this stuff to a different asm.
2016-02-11 08:49
Bitbreaker

Registered: Oct 2002
Posts: 508		 Quote: Useful addition to current discussion would be explanation why particular assembler is being used IMHO.

If it is just about typing in assembler it doesn't matter much which assembler you use, but there are things that can annoy with other assemblers. Therefore ACME is capable of:

- it handles labels without that additional colon, i hate that extra typing work
- it supports short labels like +/- (even though you can fuck yourself really hard if you overlook one of those small labels and then branch too far), as well as *+x as we know them from old tass times, right?
- macros with references
- support of local labels, be it per macro or zone
- supports all illegal menomonics, so noa ugly macro/!byte workarounds

Also as Peiselulli already stated, ACME is still actively maintained and it is fast.
Also, i don't see any problem at all to integrate a multitude of different assemblers with scripts/Makefiles as long as they are called via some commandline. No need to fall back into stoneage and receiving binary blobs. There's repositories we can use in a group and you can still hand out readymade .d64 images to those who are unable to build the whole project. At least all coders can build it (and even more), that is sufficient.
2016-02-11 10:29
Fungus

Registered: Sep 2002
Posts: 686		 64tass is also actively maintained and fast. soci has been active in this thread?
2016-02-11 17:33
CSixx

Registered: Jan 2013
Posts: 12		 Kickass, does what I need and is in java so I use the same executable everywhere (win, linux, etc..)
2016-02-11 17:52
soci

Registered: Sep 2003
Posts: 480		 Fungus: Yes, I've mentioned that I'm using it a few posts ago. Btw, sometime soon there should be another snapshot with the fixes/corrections done since 1.51.992.

I could try push it as the next best thing since sliced bread, but there's no point. Especially that I know which areas could be improved and lacking currently. But for the stuff I use it surely beats the others ;) Or else I would have given up on it long ago (almost happened around 1.4x).
2016-02-11 19:57
algorithm

Registered: May 2002
Posts: 705		 Quote: If it is just about typing in assembler it doesn't matter much which assembler you use, but there are things that can annoy with other assemblers. Therefore ACME is capable of:

- it handles labels without that additional colon, i hate that extra typing work
- it supports short labels like +/- (even though you can fuck yourself really hard if you overlook one of those small labels and then branch too far), as well as *+x as we know them from old tass times, right?
- macros with references
- support of local labels, be it per macro or zone
- supports all illegal menomonics, so noa ugly macro/!byte workarounds

Also as Peiselulli already stated, ACME is still actively maintained and it is fast.
Also, i don't see any problem at all to integrate a multitude of different assemblers with scripts/Makefiles as long as they are called via some commandline. No need to fall back into stoneage and receiving binary blobs. There's repositories we can use in a group and you can still hand out readymade .d64 images to those who are unable to build the whole project. At least all coders can build it (and even more), that is sufficient.

+the useful !pseudopc feature that is rather useful for code transferred and running in other area's (e.g zeropage)
2016-02-11 20:02
Oswald

Registered: Apr 2002
Posts: 5094		 64tass can do all of that. and I bet all the others. anyways I find myself most of the time using just very basic assembler features.

the most complex thing is usually a for loop to calculate a table of a number multiplied.
2016-02-11 20:09
enthusi

Registered: May 2004
Posts: 677		 I switched to xa since at the time, acme had no defines. it does now. xa also has .( and .) for local label space. It knows ascii, petscii and petscreen. also *= sets the pc. just that. No automated filling and shit *g*.
2016-02-11 20:10
Fungus

Registered: Sep 2002
Posts: 686		 soci: kewl, look forward to the update. Did you add a pseudopc function that can also return the length of the code somehow? Useful for disk stuff and relocating routines at runtime.
2016-02-11 20:32
soci

Registered: Sep 2003
Posts: 480		 Fungus: I'm not sure what you mean, at least what I think of is quite old. Unless I misunderstood the question.

The built-in "size()" function returns the length. The .logical/.here (pseudo pc stuff) is a "transparent" code block. You can access this block by defining a label at it's start, and it's size is probably what you're looking for.
stuff .logical $300
       nop
      .here

      .word size(stuff) ; length of .logical/.here
      ldx #size(stuff)

It's also mentioned in the "Usage tips" section of the manual in an example for copying zeropage code to it's final place.
2016-02-12 00:25
TheRyk

Registered: Mar 2009
Posts: 2244		 @enthusi: I think you should give current ACME a chance, as most (or even all) of what you complain about has been realised inbetween. Of course you might need to "learn" a few tokens.

As for
Quote:
automated filling and shit *g*

there is
!fill,<no. of bytes>,<fillbyte>

to determine yourself which range to fill with what
plus, there is
!initmem

to make clear how "empty" areas not specified via !fill are supposed to be filled (zero by default if you do not use !initmem)

I can only tell you, ask Mac Bacon, whenever sth is unclear or you want sth to be improved. My experience is, he's a true genius but also a really nice and helpful guy, who always replies quickly or - if you convince him sth is worth improving - even updates ACME in next to no time.
2016-02-12 05:49
enthusi

Registered: May 2004
Posts: 677		 yes, I believe all of that :) While back then I had a reason to change, I do not have one now, though. XA feels more 'raw' which is what I prefer in fact.
2016-02-12 06:38
Oswald

Registered: Apr 2002
Posts: 5094		 so what does initmem do ? why should the assembler know how memory looks like ? I dont get it
2016-02-12 11:22
chatGPZ

Registered: Dec 2001
Posts: 11386		 * = $1000
nop
* = $2000
nop

what should go to $1001-$1fff ? -> initmem
2016-02-12 12:28
Oswald

Registered: Apr 2002
Posts: 5094		 ah! thx
2016-02-12 18:22
Fungus

Registered: Sep 2002
Posts: 686		 @soci

Ah yes, that's exactly what I meant. I was still doing it the old tass way with using calculations :)

hrm... we need wiki's for these things. CSDB needs a wiki system :D
2016-02-12 18:36
soci

Registered: Sep 2003
Posts: 480		 Calculations are fine if you don't mind a second symbol.

There's codebase64, so I think we have a wiki already.
2016-02-12 18:49
Fungus

Registered: Sep 2002
Posts: 686		 I meant a wiki in general dedicated to use of tools and what not. :)
2016-02-12 19:09
AlexC

Registered: Jan 2008
Posts: 299		 Quote: I meant a wiki in general dedicated to use of tools and what not. :)

There is already codebase64 wiki but page about cross tools is terrible outdated - just like many other parts of this great site - for example it provides link to long gone ACME homepage. Wouldn't it be better if try to update codebase64 instead of creating another wiki?
2016-02-13 09:17
Frantic

Registered: Mar 2003
Posts: 1648		 @AlexC: Doh.. About the same time spent on complaining about the acme link not being up to date would have been sufficient to update the link instead. :) (Not meant as an attack — just a reflection.)

Anyway.. the link is now updated.
2016-02-19 08:00
AlexC

Registered: Jan 2008
Posts: 299		 I can now add Virtual Assembler to the list of natively running assemblers. The only drawback is that it seems to be based on non-macro Turbo Assembler version and missing macros or includes could be painful sometimes. Otherwise it is one of best tools you can run on your C64 and one of very few supporting SCPU.
2016-02-19 12:48
Wisdom

Registered: Dec 2001
Posts: 90		 KickAssembler since last year, before that it was 64tass.
2016-02-19 16:26
AlexC

Registered: Jan 2008
Posts: 299		 Quote: KickAssembler since last year, before that it was 64tass.

Out of curiosity could you elaborate a bit why you've switched from 64tass to KickAssembler?
2016-02-19 18:18
Glasnost
Account closed

Registered: Aug 2011
Posts: 26		 Kick assembler
2016-04-28 11:04
Wisdom

Registered: Dec 2001
Posts: 90		 Quote: Out of curiosity could you elaborate a bit why you've switched from 64tass to KickAssembler?

Due to its scripting ability.
2016-04-28 16:03
Krill

Registered: Apr 2002
Posts: 2980		 Quoting Wisdom
Due to its scripting ability.
Until at some point you realise that if you only have a hammer, everything starts to look like a nail.
2016-04-28 16:51
Dr.j

Registered: Feb 2003
Posts: 277		 Kick assembler
2016-04-28 18:35
Oswald

Registered: Apr 2002
Posts: 5094		 Quote: Quoting Wisdom
Due to its scripting ability.
Until at some point you realise that if you only have a hammer, everything starts to look like a nail.

true dat, kickass users tend to code the code, instead of just writing code. :)
2016-04-28 21:29
Frantic

Registered: Mar 2003
Posts: 1648		 But everybody knows that coding the code won't code the code, so it's cool.
2016-04-29 03:33
Conjuror

Registered: Aug 2004
Posts: 168		 Everyone knows the real gains come from configuring the code that generates the code that codes the code.
2016-04-29 09:01
Dano

Registered: Jul 2004
Posts: 234		 Doesn't it all boil down to "what gets you job done"?
In the end we all use what we are accommodated to.

Currently working with KickAssembler as it's nice to have the scripting inside the one file.

The disadvantage though is the step back in the end to write a code generator that builds the code like my scripted stuff in the end. But that's another story.. ;)
2016-04-29 09:31
chatGPZ

Registered: Dec 2001
Posts: 11386		 or that suddenly your demo takes many minutes to assemble because of all the conversion voodoo in javascript....
2016-04-29 09:55
Burglar

Registered: Dec 2004
Posts: 1101		 ah, that was to be expected, the groepaz crusade against kickass will never stop!

and really, *minutes* to compile? exaggeration is an art it seems ;)

Anyways, I currently use kickass, its probably not the best, but it's quite good and has lotsa features. It also helps that there are plenty macro's available on codebase.
2016-04-29 09:59
Conjuror

Registered: Aug 2004
Posts: 168		 Welcome to Enterprise grade demos!
2016-04-29 10:17
Wisdom

Registered: Dec 2001
Posts: 90		 Someone uses TASS for more than 20 years, and then needs to speed up trying out different ideas, and after each piece of code scripted and served its purpose, re-codes it with run-time code generation, not to mention that he has also been through several software projects in several companies, with several different environments, thus at least has an idea what is hammer and what is nail, yet one kid feels the need to state the obvious as usual.
2016-04-29 10:47
chatGPZ

Registered: Dec 2001
Posts: 11386		 Quote:
and really, *minutes* to compile? exaggeration is an art it seems ;)

its not exaggerated at all. i am referring to building a whole demo there of course, which takes less than 30 seconds to build with proper tools.

and no, its not a crusade at all. everyone is of course allowed to be masochist :=)
2016-04-29 11:18
Burglar

Registered: Dec 2004
Posts: 1101		 heh, but, I compile a complete game within 6 seconds and it heavily uses kickass and slow macros for image conversions.
Most time is spent in exomizer anyways...

(yes building is done in parallel on 8 ht-cores)
2016-04-29 11:55
chatGPZ

Registered: Dec 2001
Posts: 11386		 the problem is mostly the startup time, i guess... if you have a monolithic build then it probably not very noticeable indeed
2016-04-29 12:11
Burglar

Registered: Dec 2004
Posts: 1101		 just measured the startup time of kickass, it's about 0.100 sec on my system. 0.269 sec was used for compiling, exomizer then took 0.427 sec...

but yea, u know what they say: YMMV ;)
2016-04-29 12:26
Peacemaker

Registered: Sep 2004
Posts: 275		 dear mr.kickass.

parsing
flex pass 1
.if ( 1 == 1 ) {
.import Source "1-include/include.asm"
^

Error: Unknown import type 'Source'
at line 2, column 1 in credits.asm

Could you please fix that? ;)
Thanks
2016-04-29 13:52
Knut Clausen

Registered: Apr 2013
Posts: 18		 Quote:
Could you please fix that? ;)
Thanks


This has to do with the multi pass behaviour of KickAss, I believe.

However, Bitbreaker came up with a nifty workaround for this some months ago, when working with KickAss support for BitFire:

.import source 1 == 1 ? "code.asm" : "empty.asm"
2016-04-29 16:01
Peacemaker

Registered: Sep 2004
Posts: 275		 nifty nifty... will have a look into it. thanks
2016-04-29 18:27
soci

Registered: Sep 2003
Posts: 480		 Quote: just measured the startup time of kickass, it's about 0.100 sec on my system. 0.269 sec was used for compiling, exomizer then took 0.427 sec...

but yea, u know what they say: YMMV ;)

Yes, it varies a bit (compiling a single nop):
$ time java -jar ./KickAss.jar a.asm >/dev/null

real	0m5.426s
user	0m0.356s
sys	0m0.120s
$ time ./64tass a.asm >/dev/null

real	0m0.002s
user	0m0.000s
sys	0m0.000s

model name	: Intel(R) Pentium(R) M processor 1700MHz
cache size	: 1024 KB

356 ms is not that bad.
2016-04-29 18:47
Slammer

Registered: Feb 2004
Posts: 416		 There actually are solutions for eliminating the java startup time by reusing the jvm. One of them is called 'Nailgun', but ofcause if you are afraid that all your problems look like nails you will discard that solution ;-)

Why Groepaz have a problem when he is using makefiles, I don't know (Using makefiles he should only get the startup penalty a limited number of times) But he is know to seek out the worst possible solution and then bitch to everyone about it. I guess you could also try using ANT since it is java based so the jvm is probably also reused.
2016-04-29 19:04
chatGPZ

Registered: Dec 2001
Posts: 11386		 or i could drill a hole into my knee and fill it with ketchup!
2016-04-29 19:05
Jammer

Registered: Nov 2002
Posts: 1335		 And stick an arrow to it ;)
2016-04-29 19:10
Frantic

Registered: Mar 2003
Posts: 1648		 It is good to see that people have strong opinions about assembler preferences. :D
2016-04-29 19:13
Slammer

Registered: Feb 2004
Posts: 416		 Quote:
or i could drill a hole into my knee and fill it with ketchup!

Please remember to upload a video on youtube, im sure we are many that want to see it! :-D
2016-04-29 19:14
chatGPZ

Registered: Dec 2001
Posts: 11386		 Frantic: and that

.import source 1 == 1 ? "code.asm" : "empty.asm"

isnt the worst possible solution <3
2016-04-29 19:53
Slammer

Registered: Feb 2004
Posts: 416		 KickAss (3.x, there is a solution in 4.x) wasn't made for conditional imports as I never use them myself (and just as you can't make conditional imports in java). Different configurations was made by using different starting files, instead of conditional imports.

But I must say Groepaz, it seems like 'Crusade' is very describing for your hate of KickAssembler. It is ok, that you don't want to use it, but it seems kind of manic the way you try to seek out and destroy every positive post about Kick Assembler. Your lack of tolerance for other opinions than your own makes you an excelent code dictator, but hey, luckily we live in a free world where everyone is entitled to an opinion.

What makes me sad is when your lack of tolerance spreads to good people like Krill.
2016-04-29 21:14
chatGPZ

Registered: Dec 2001
Posts: 11386		 yeah, because people like krill (or bitbreaker) need my "crusade" to form their opinion. god forbid its the simple lack of essential features and the resulting fucked up workarounds emerging because of that. LOL
2016-04-29 21:23
Slammer

Registered: Feb 2004
Posts: 416		 Krill and Bitbreaker are perfectly entitled to an opinion. But it seem to me that Krill was attacking Wisdom for aswering a question that was asked directly to him and with the style of retoric i have seen you use many times.
2016-04-29 21:34
chatGPZ

Registered: Dec 2001
Posts: 11386		 If you think that has anything to do with my supposed lack of tolerance (which is funny by itself), then you really need your reality checked.
2016-04-30 06:59
Hein

Registered: Apr 2004
Posts: 954		 For what it's worth now that this thread is starting to get emotionally deranged: 64tass. :)
2016-04-30 07:05
tlr

Registered: Sep 2003
Posts: 1790		 dasm

Lot's of quirks but it works for me.
2016-04-30 07:15
Angel of Death

Registered: Apr 2008
Posts: 211		 If I may add to the conversation...
I seem to be the only one here that uses both and I found out that in the end it doesn't really matter which compiler/assembler you use
and that the speed at which it does it's job is dependent on how much includes, scripts, conditional compiles etc. are used.
However, not doing any programming in a 'higher language', the modern syntax and structure of kickass does look a bit alien to me
as my brain is, more or less, trained to read machine/assembly code.
There are one click solutions and enviroments for both and having the additional JAVA layer doesn't make it, necessarily, more cumbersome on modern systems.
But it does make it cross-platform.
But then again, that doesn't have anything to do with the difference between using a compiler with advanced scripting-options or an assembler that doesn't.
If you consider programming as building something it shouldn't really matter if you use a hammer and chisel
(or hammer and nails, for that matter) or a 3d printer.
Tools are tools, skills are skills...
2016-04-30 09:01
Krill

Registered: Apr 2002
Posts: 2980		 Quoting Slammer
But it seem to me that Krill was attacking Wisdom for aswering a question that was asked directly to him and with the style of retoric i have seen you use many times.
I wasn't intending to attack anyone. My point was just this: While the scripting abilities are all fine and dandy, they limit you in what you can do, until using arbitrary external tools to generate data (as it's supposed to be (TM)).

I myself use many different domain-specific scripting languages and other tools to generate data to be included with C-64 binary blobs. I guess a good example is the GNU octave (Matlab) script i used in the build process of Artefacts to pack a few tables to polynomials, which is a kind of lossy compression, and uses polynomial fitting (of course) to find the coefficients. This is a few lines in that language, as it is made for that kind of job. Conversely, it would probably be a bad idea to do this in most/all general-purpose languages.

Other examples would be graphics and audio conversion, lossless compression, etc.

Now, in the end, nothing keeps anyone from using the built-in scripting AND external data generators. But i myself have never missed the lack of the former in other assemblers (as long as they come with a mature macro engine) and keep using whatever external tool does the job.

And with regard to the hammer/nails metaphor: I have seen quite a few posts in here which were about solving some specific problem in the built-in scripting language.
2016-04-30 09:06
chatGPZ

Registered: Dec 2001
Posts: 11386		 what krill said. first and foremost, the assembler should do assembler things - and it should do it well. IMHO kickass just fails flat on a few things there (which you can surely work around, but i'd rather not). the scripting stuff is all nice and fluffy, but it doesnt solve anything for me.
2016-04-30 09:39
Slammer

Registered: Feb 2004
Posts: 416		 Krill: Good to hear your elaboration. It raises the discussion from the mud-slinging level to something constructive.

And you are actually stating an important point. Nothing prevents you from using the script together with higher level languages, just like nothing prevents you from doing something in C++ when you are doing calculations in Math-lab. You can also benefit from stuff like pseudocomands or access to the internal labels in executed macros without using the script language at all.

Now I'am sure there are other equally cool benefits in the assembler you use, why dont you state these instead of assuming people are gonna use the script language in a bad way.
2016-04-30 10:37
chatGPZ

Registered: Dec 2001
Posts: 11386		 the linker in ca65 toolchain - for bigger projects (not necessarily demo coding) being able to have proper libraries and link stuff to arbitrary locations in a memory layout defined in a linker config is unbeatable.
2016-04-30 10:57
Oswald

Registered: Apr 2002
Posts: 5094		 nothing wrong with kickass itself, its brilliant imho. as told what raises eyebrows is when people overuse it :)
2016-04-30 11:12
Slammer

Registered: Feb 2004
Posts: 416		 Linking and libraries is an interesting topic. Could you explain the benefits of the linker over for example preprocessor includes like in C/C++? I don't know the ca65 linker, are there any disadvantages? Im thinking, when are labels getting their values and is it limiting the memorymanagement in any way?

Edit: Before you take this the wrong way. I'm actually looking into these things right now and want your opinion
2016-04-30 11:29
encore

Registered: Aug 2010
Posts: 67		 for what it's worth: 64tass
2016-04-30 11:42
Adam

Registered: Jul 2009
Posts: 323		 Quoting Oswald
what raises eyebrows is when people overuse it :)


eh?
2016-04-30 11:45
Oswald

Registered: Apr 2002
Posts: 5094		 Quote: Quoting Oswald
what raises eyebrows is when people overuse it :)


eh?

read back maybe ? hint: krill's last post.
2016-04-30 11:46
Adam

Registered: Jul 2009
Posts: 323		 DASM
2016-04-30 12:56
chatGPZ

Registered: Dec 2001
Posts: 11386		 slammer: it has nothing to do with "includes" - includes are simply "copy pasted" into your source at compile time (in pretty much any language i know)(*). the libraries in the cc65 toolchain work the same as they do in "big" toolchains, like GCC/binutils. in a nutshell:

- the assembler outputs object files ("half compiled" binaries that may contain unresolved symbols and which are position independent)
- the linker reads object files and combines them into the final binary. it resolves unresolved symbols and puts the bits and pieces to their absolute memory location depending on the linker config file
- libraries are basically just a collection of object files, with the one important difference that if you link against a library, the linker will only include those object files that contains symbols that have been referenced before. (and those by themselves can reference other symbols, and pull in more object files as a consequence). this way only the object files that have actually been used will end up in the binary.

there is one backdraw with this approach, which is that the linker (the one in cc65 toolchain at least) can not change the length of instructions, which means in some situations you'll get absolute addressing when zeropage would have been enough. in those cases you'll have to explizitly state the addressing mode to get the optimal code. (or you dont care =P)

64tass contains some mechanism to do a similar thing from within the source iirc (include source files only if they are referenced. or perhaps functions/zones/noidea - i dont use this feature =))

(*)this is not completely true - modern compilers can also omit code from the same compilation unit if its unused, like from a c++ header or c source. this somewhat breaks/improves the traditional way of doing this.
2016-04-30 13:19
Krill

Registered: Apr 2002
Posts: 2980		 Quoting Slammer
Linking and libraries is an interesting topic. Could you explain the benefits of the linker over for example preprocessor includes like in C/C++? I don't know the ca65 linker, are there any disadvantages? Im thinking, when are labels getting their values and is it limiting the memorymanagement in any way?
The main benefit is that you can statically link object code and relocate it to different addresses without having to recompile it. Of course, the effect (build speed) is marginal for regular C-64 projects (demo parts), and there are basically only two or three kinds of library that people use at (sometimes) different addresses in the same project (i.e., a loader, a demo framework and maybe music/sound routines).

Object code can be linked dynamically as well, such that the code is relocated by a little object loader on the C-64 itself. There are just a few scenarios where this is useful, such as writing code for multi-process OSes (LUnix, GEOS). I have started a dynlinking feature for my loader years ago (to exchange it with later/better/other loaders with finished demos/games), but... nobody would really use it.

Object-internal labels have addresses relative to the object's base address, which get resolved to absolute addresses at link (relocate/load) time. External addresses are resolved and assigned by the linker as well.

Memory management isn't limited. In fact, being able to load the same code to different addresses gives you more possibilities, think of executable overlays in programs that would only have the currently-needed code in memory.
2016-04-30 13:23
Krill

Registered: Apr 2002
Posts: 2980		 Quoting Groepaz
includes are simply "copy pasted" into your source at compile time (in pretty much any language i know)(*).
(*)this is not completely true - modern compilers can also omit code from the same compilation unit if its unused, like from a c++ header or c source. this somewhat breaks/improves the traditional way of doing this.
Also think of C++ template classes, which usually are declared AND defined in headers, and would only emit the code for one class (of the same kind), no matter how often it is referenced by other compilation units.
2016-04-30 13:33
Krill

Registered: Apr 2002
Posts: 2980		 Quoting Slammer
Now I'am sure there are other equally cool benefits in the assembler you use, why dont you state these instead of assuming people are gonna use the script language in a bad way.
My weapon of choice is ca65 for bigger projects, for the reasons Groepaz mentioned, and 64tass for small projects (demos up to 1 K), for simplicity and speed.

That ca65 linker scheme is a powerful thing, but it is too much and too complicated for many projects. It comes in very handy, though, with drive code and bank-switched cartridge code, where its location in the executable isn't the location at run-time. It also forces you to have an abstract view of the different parts of your program, and enables you to better see what is used at what time, and how you can overlay code to have more memory at your disposal.
2016-04-30 13:37
Slammer

Registered: Feb 2004
Posts: 416		 I see. How about memory coordination between the different libraries. Does one have to manually coordinate the memorylayout of the libraries(the config file perhaps) or does the linker solve this for you. Manual fixed config+'Linker selects which ones to use' might leave unused holes in the memory when the linker picks which ones to use. A smart linker that organizes the memory for you might lead to lack of control of the memory which sometimes is important.

So i guess the interesting part is what can go in an object file. Is the code position fixed (Perhaps fixed to a given position in page?), but outside symbols not or? If you have a link to a description of the object file format and an example of a config file, please post it - I guess that would explain alot.
2016-04-30 13:50
Krill

Registered: Apr 2002
Posts: 2980		 http://www.cc65.org/doc/ld65-5.html

There is not much smartness going on, and doesn't need to. It's basically just putting objects to ascending memory locations. You can also add directives for alignment and fill values.
2016-04-30 14:05
Krill

Registered: Apr 2002
Posts: 2980		 Sorry for wall, but here's a real-world example. The code for the DISKIO* segments comes in an object file when linking (loader.o), which must define these segments (they are matched by name). You are free to add code to any segment by simply setting the segment name anywhere you like in your code, multiple times.

MEMORY
{
    LOADERZP:      start =   $4c, size =   $44, type = rw; # must not overlap STATUS ($90)
    ZPRAM:         start =   $fa, size =   $06, type = rw;
    # the C STACK memory area must be defined in the applications's link file
    # when using the importldr function to dynamically link the loader
    STACK:         start = $0100, size =   $80, type = rw, define = yes;
    RAM:           start = $1000, size = $c000, type = rw; # Plus/4 has screen and colours at $0800-$1000
    RAM2:          start = $1000, size = $f000, type = rw;
}

SEGMENTS
{
    ZEROPAGE:       load = ZPRAM, type = zp;

    CODE:           load = RAM,   type = ro;
    RODATA:         load = RAM,   type = ro, optional = yes;
    DATA:           load = RAM,   type = rw, optional = yes;
    BSS:            load = RAM,   type = rw, optional = yes;

    BITMAP:         load = RAM2,  type = bss, start = $4000, optional = yes, define = yes; # overlay with DISKIO_INSTALL
    COLRAM:         load = RAM2,  type = bss, start = $7000, optional = yes, define = yes; # $1000 on Plus/4 (SPRITES segment not used)
    SPRITES:        load = RAM2,  type = bss, start = $7400, optional = yes, define = yes; # no SPRITESHI segment: the sprites are always in this bank

    VERIFYBUFFER:   load = RAM2,  type = bss, start = $8000, optional = yes, define = yes;

    BITMAPHI:       load = RAM2,  type = bss, start = $c000, optional = yes, define = yes; # also location of IEEE-488 KERNAL extensions with SFD-1001
    COLRAMHI:       load = RAM2,  type = bss, start = $f000, optional = yes, define = yes; # not used on Plus/4

    # these three segments must be defined in the application's link file
    DISKIO_ZP:      load = LOADERZP, type  = zp,    define = yes;
    DISKIO_INSTALL: load = RAM,      start = $4000, define = yes; # fire and forget
    DISKIO:         load = RAM,      start = $6500, define = yes; # must not exceed $7000 (COLRAM) in this program
    # this segment must be defined if the loader links dynamically to the application
    DISKIO_IMPORT:  load = RAM,      start = $8000, define = yes, optional = yes; # fire and forget - however, dynlink code is in the CODE segment, too
}
2016-04-30 14:17
Slammer

Registered: Feb 2004
Posts: 416		 I see. You use normal align directives, when you want to control page boundaries. How about placement of graphics, that sometimes have to be in certain places. Do you have to work all graphics positions into the memory map?

Also, Something smart could be required of a linker. If you have libraries like: 
--- Lib1 ---
.byte 23

--- Lib2 ---
.align $100
.byte 0,1,2,3,3,4,..., $ff

--- Lib3 ---
.byte 23

--- Lib4 ---
.align $100
.byte 0,1,2,3,3,4,..., $ff

--- Lib5 ---
.byte 23

--- Lib6 ---
.align $100
.byte 0,1,2,3,3,4,..., $ff
I would prefer it first places lib2,Lib4,lib6 and then Lib1, Lib3 and Lib5 to avoid wasting alot of alignment bytes.
2016-04-30 14:26
soci

Registered: Sep 2003
Posts: 480		 The user needs to be smart to create two segments, one for aligned stuff, the other for non-aligned. And then feed them accordingly.
2016-04-30 14:26
Krill

Registered: Apr 2002
Posts: 2980		 You are free to make the segments as finely granular as you please. You can also specify graphics positions in your source files, without them showing up in the link file, but that would somehow defeat the purpose.

I don't quite see why the linker should shuffle around segments based on some "smartness" (it would sooner or later fail, as most programs trying to be smart do). You specify the order and can shuffle segments around easily with a bit of the old cut'n'paste.
2016-04-30 15:11
White Flame

Registered: Sep 2002
Posts: 136		 ca65, even for single asm file projects. I've got an easily reusable makefile & config to get simple things up fast.
2016-04-30 15:18
Krill

Registered: Apr 2002
Posts: 2980		 Quoting Slammer
instead of assuming people are gonna use the script language in a bad way
Quoting Oswald
nothing wrong with kickass itself, its brilliant imho. as told what raises eyebrows is when people overuse it :)
Reading these forums, it appears to me that many people overuse it. But that's just my personal opinion. Many people prefer KickAss for its main selling point, the built-in scripting, which is cool.

I cringe a little, though, already when people try to incbin a file, but want to skip the first few bytes, then keep a run of bytes, then skip a few more bytes, then keep the rest of the file. This is what the zoo of tools in the *NIX userland was made for. But then many people stick to Windows, and then i do see a point in wanting to do everything with one tool. I wonder how many KickAss users are Windows users, actually.

And Wisdom, assuming that you meant me: The "you" in the hammer/nail post was a generic you. I didn't intend to offend you or anyone personally, and there is no need to post your life story to defend your choice. And i'm certainly not a child any more.
2016-04-30 15:43
Slammer

Registered: Feb 2004
Posts: 416		 Edit: response to krill/socis earlier post.. I just got disturbed while writing :-)

Im just trying ot figure out it works plus the pros and cons. That includes figuring out how much is done by the linker and how much the user should do. I guess Soci gave the answer to the library question.

I see both pros and cons. When I heard linker I thought of my experience with linkers on PCs where everything is done for you without a big setup. I guess thats not posible on the c64 which is pretty memory sensitive. But I see some good things and understand why you like the feature.
2016-04-30 15:52
Krill

Registered: Apr 2002
Posts: 2980		 Quoting Slammer
When I heard linker I thought of my experience with linkers on PCs where everything is done for you without a big setup. I guess thats not posible on the c64 which is pretty memory sensitive.
Hmm, what do you mean? I've spent some time tinkering with GNU ld link files, and ld doesn't automagically do things either. You do have a bit of scripting there, but IIRC not the Turing-complete sort. The cc65 suite does many things pretty much like the original *NIX way, only with 6502-ish targets. And ld65 comes with a few built-in targets as well, so you don't have to write your own link files for simple memory layouts.
2016-04-30 16:20
Krill

Registered: Apr 2002
Posts: 2980		 Quoting ChristopherJam
on large productions, do groups tend to enforce a single assembler for the entire project, or is the code base a bit heterogenous?
As others said already, there is no need to enforce The One Assembler. And why would there be? :) Given the plethora of assembler preferences, no demo coded by many coders would get finished. And already the choice of loader usually gives you the need to work with a second assembler, albeit only once to build the loader with your preferred options.
2016-04-30 16:25
Slammer

Registered: Feb 2004
Posts: 416		 Quoting Krill
Hmm, what do you mean? I've spent some time tinkering with GNU ld link files, and ld doesn't automagically do things either. You do have a bit of scripting there, but IIRC not the Turing-complete sort. The cc65 suite does many things pretty much like the original *NIX way, only with 6502-ish targets. And ld65 comes with a few built-in targets as well, so you don't have to write your own link files for simple memory layouts.

Back in 1995-2000 when i coded C++ I never had to make any linker config files. A makefile was enough to glue it all together. Why did you need link-configuration?
2016-04-30 16:49
Krill

Registered: Apr 2002
Posts: 2980		 Quoting Slammer
Why did you need link-configuration?
E.g., for embedded systems firmware, i needed a special section for non-volatile RAM. Static variables assigned to this section ("PERSISTENT_VARIABLE(int user_flags)") would be periodically monitored and mirrored to an EEPROM by a background thread, to survive power-cycling without requiring any code other than using that PERSISTENT_VARIABLE() macro. The same firmware can be built as a regular x86-PC Linux command-line program, which needs this segment as well (but accesses a regular file rather than an EEPROM, in that background thread).

And well, in embedded systems you generally used to require your own special memory layout and link files. Not so much these days any more, with lower-end hardware already sporting an MMU and happily running Linux.
2016-05-01 08:03
Slammer

Registered: Feb 2004
Posts: 416		 Sorry for picking your brains, but I find this intersting. As I understand it the memory management of the linker seem to have 3 levels: 
   File<-Memory<-Segment
(I know the file level is not that explicit as its an argument for memory)

I completely buy that segments are good, but how much do you use the memory level. Wouldn't it be simpler and just as good to do:
   File<-segment
Also, I get the destinction between bss and other segments. But do you use the difference between ro and rw, and wasn't it better placing it (only) at the memory level?
2016-05-01 08:59
JackAsser

Registered: Jun 2002
Posts: 2014		 The Memory directive is used to emit bytes to different files. In Booze I have two memories. One from 200-1fff where init, decrucher, loader and music i located. This is emmitted to main.bin. The rest goes into code.bin. The final product is a concatenation of the two, smack on a load addy and cruch it. When it goes into the final disk linked with the rest I only feed it code.bin
2016-05-01 09:40
Krill

Registered: Apr 2002
Posts: 2980		 What Jackasser said, and multiple memories/output files can also be used for the overlays i keep mentioning. You relocate/switch banks/load files to overlapping memory regions at different times. And sometimes you do have actual different distinctive memory, e.g., in cartridges and drive code.

The access directives may be somewhat more logical when applied to memories rather than segments, but they are more practical for segments. Think of things like linker errors/warnings when it detects a write attempt to a read-only segment. Though i have never encountered that with ld65. I might have just never done this, neither purposely nor by accident. :)
2016-05-01 10:48
Peacemaker

Registered: Sep 2004
Posts: 275		 Indeed, multiple memories/output files for be very useful to make some things easier.. Himen (e.g. $e000-$ff40) output file along with the "main" bin (e.g. $2000-$abcd) output file.
2016-05-01 12:47
chatGPZ

Registered: Dec 2001
Posts: 11386		 Quote:
Also, I get the destinction between bss and other segments. But do you use the difference between ro and rw, and wasn't it better placing it (only) at the memory level?

the file level is needed for overlays, think of stuff that gets loaded from disk (eg: demoparts). if you use this consequently through the entire demo, you can just link together everything without the need of header/include files that keep all the addresses/labels for common functions (loader/music/framework).
the ro/rw stuff is needed when you have ROM - like a cartridge image. (the linker can produce warnings or even errors when you try to write to memory that is in a readonly section, thus saving you a lot of WTF)
2016-05-01 14:33
JackAsser

Registered: Jun 2002
Posts: 2014		 I also used it both in the EotB preview and in the c128 3d engine for emitting code to the upper memory block and then load it from disk
2016-05-02 06:05
Slammer

Registered: Feb 2004
Posts: 416		 Thanks guys. More questions arises, but I will take it for at testdrive to figure out the details.

Peacemaker: I dont know if you have already seen it, but you can get multiple outputfiles using the -mbfiles switch. It will save one file per memory block using the blocks name as filename.
2016-05-02 07:27
Firehawk

Registered: Aug 2011
Posts: 31		 +1 for KickAssembler (KickAssembler, xemacs and gmake), mostly because it was the first one I found when searching for a C64 assembler at my return to C64-coding (around 2010) - but I found that it suits me just fine. Don't use scripting too much, as I found its better to preprocess graphics using C++ instead.

I think this boils down to questions like "what is the best programming language?" - the anwser is not C, C++ or Python etc, but "the one you are best at".

Try claiming that opinions are subjective in this forum :-D.
2016-05-02 07:40
Krill

Registered: Apr 2002
Posts: 2980		 Quoting Firehawk
"what is the best programming language?" - the anwser is not C, C++ or Python etc, but "the one you are best at".
To be honest, this is one of the answers i DON'T want to hear in job interviews. :D
2016-05-02 07:50
Firehawk

Registered: Aug 2011
Posts: 31		 Krill: Well it's not a question that should be asked in a job interview, or? You should be asking about skills, not opinions.
2016-05-02 08:04
Krill

Registered: Apr 2002
Posts: 2980		 My point was that good programmers don't care much about which language to use, they just pick the one best suited for the job. Otherwise hammer/nail again :D
2016-05-02 08:34
Firehawk

Registered: Aug 2011
Posts: 31		 In a perfect world, yes. But in real life, you need to pick a language that the rest of the development staff masters (which is usually one or two), and although most of us here can use most programming languages, this is not the case for everyone (in particular in a large coorporation like where I work). Most newly educated programmers these days only knows Java/C#, so getting ADA/C++ skills can be difficult :-)
2016-05-02 10:44
Krill

Registered: Apr 2002
Posts: 2980		 Yes, i don't want to hear certain things, and yet i do... :)
2016-05-02 13:14
chatGPZ

Registered: Dec 2001
Posts: 11386		 and then a client sends you a an ancient source in fucking cobol.... /o\
2016-05-02 15:30
Pitcher

Registered: Aug 2006
Posts: 61		 I don't see any mention of c64prg studio, which is the first thing I found and am playing around with currently.

Should I be looking at something else instead ?, it does what I want it to and dumping any assembled code straight to an emulator for testing is quite handy.
2016-05-02 18:50
Hoogo

Registered: Jun 2002
Posts: 105		 Well, I liked the way Cobol defined its memory for variables and structures - at least the parts I can still remember after all the years. Quite close to our assemblers now.
2016-05-02 19:36
Krill

Registered: Apr 2002
Posts: 2980		 Pitcher: If it does what you want it to do, keep using it until you hit some walls. Whatever makes you most productive. There are people who prefer plain text editors and a shell over fully-integrated IDEs, and those who don't.

Personally, i've never considered using C64prgstudio. Can you decide which assembler to use with it?
2016-05-03 17:29
saimo

Registered: Aug 2009
Posts: 36		 Interesting conversation. I thought that the way I'm writing QUOD INIT EXIT II might be somehow interesting to you - or at least give you a reason to have a good laugh. The only problem is that I suffer from Constant Lack Of Time, so I really shouldn't be doing this and rather write down some more code, but anyway...


BACKGROUND INFORMATION

I have started writing code entirely in 6502 assembly only recently (there's a long story behind, but I'm trying to keep it short). I was writing QIEII's code as a mix of BASIC and BASIC BOSS £CODE statements (so, I was writing by hand the ML code as byte values). Little by little, I replaced lots of BASIC parts to save more memory (and gain speed, but that was secondary). At some point, ~95% of the code was ML: that, combined with the fact that I really would have had a use for the extra memory taken by BASIC BOSS and the whole zero page, made me decide to switch to assembly.
I had to take a decision: which assembler to use? I had already read somewhere here that there is no standard syntax; moreover, I'm working on AmigaOS 4, so I thought I didn't have much choice. Eventually, I decided to do it my own way, much in the vein of what I was already doing. And so I decided to use... no assembler at all.


THE SOLUTION ADOPTED

What I did was, instead, creating a little framework in C that allows me to write assembly-through-C, so to speak: basically I write C code whose corresponding executable program outputs a C64 executable. Note that I'm not talking of compiling C code into 6502 ML: I'm actually writing assembly code, just in a somewhat weird syntax (that I got used to very quickly). The fact that the context is that of a C source gives me a lot of power and flexibility (which I'm not even using to the fullest, I believe).
But I guess that this description fails to give a decent idea, so let me resort to some visual aids...


EXAMPLES

This picture here shows you some ordinary code/routines.



This picture shows dynamic generation of code: if the C program detects that the 6502 ML code it is generating would overwrite itself, it generates additional code to deal with that issue.



This picture shows (conditional) inclusion of sources, declaration of an embedded table, incbinning, and debug output.




CONCLUSION

There's more to this, but chances are that you're already throwing up at the syntax, so I'll stop it here ;)
2016-05-03 17:43
Frantic

Registered: Mar 2003
Posts: 1648		 @saimo: That's a funny way of doing it for sure. :D

...and speaking of Amiga. Somewhere I have a version of the ACME assembler compiled so that it is possible to run it even on A500 (with kickstart above 1.3 only I think). It is not the latest version of ACME, but it is not a very old version either.
2016-05-04 19:52
saimo

Registered: Aug 2009
Posts: 36		 Never used ACME. I started with DevPac, but soon my favourite assembler became PhxAss. The only problem I had with it is that it produced incorrect base or outer displacements (can't if either or just one of them) for memory indirect pre/post-indexed modes when in conjunction with some optimization (it was something quite specific, but unfortunately I can't remember more). That bug made me waste many hours searching for a bug in my code - eventually, looking at the disassembly, I discovered the 84574rd. The author told me that the problem wasn't curable without a complete rewrite (but it was not a big deal: if I remember correctly, it was enough to specify the size of the displacements manually and correctly to avoid the problem).
2016-05-04 21:06
Digger

Registered: Mar 2005
Posts: 437		 @saimo: I love that :) Could this be ported to JS? I make a lot of prototypes in JS (Coffescript actually) and it would be nice to convert them to gradually into Assembly and then output it as .asm file by the browser :)
2016-05-05 09:39
JackAsser

Registered: Jun 2002
Posts: 2014		 Quote: @saimo: I love that :) Could this be ported to JS? I make a lot of prototypes in JS (Coffescript actually) and it would be nice to convert them to gradually into Assembly and then output it as .asm file by the browser :)

That's exactly how I code my complex parts. Start with java code, then gradually replace each function with assembly (in java) and a crude CPU/VIC emulation to verify the correctness.
2016-05-05 09:39
Frantic

Registered: Mar 2003
Posts: 1648		 @Saimo: ACME is a 6502/6510 assembler. Not for 68k like devpac etc.
2016-05-05 14:58
saimo

Registered: Aug 2009
Posts: 36		 @Digger

Unless I misunderstand you, it sounds like you have something quite different in mind. My stuff does not compile C into assembly (so it doesn't allow to do prototyping in C), and does not output an assembly source. It's simple, but it's kind of weird to explain, so here are more details:
* all I have is a bunch of C files that constitute the framework;
* a C64 program consists of one or more C sources that include some of the framework files;
* the C sources define all the assembly code by means of C functions and macros (f.ex. ldai(0); is the equivalent of lda #0);
* I compile the sources with GCC, which generates an AmigaOS executable;
* I run the AmigaOS executable, which generates the C64 executable.


@Frantic

You've just exposed my ignorance about C64 assemblers :p
Sorry, I took a trip down the memory lane...
2016-05-05 15:06
Oswald

Registered: Apr 2002
Posts: 5094		 saimo, congrats, thats a terribly masochistic way of doing it. :)
2016-05-05 16:26
ChristopherJam

Registered: Aug 2004
Posts: 1409		 Quote: Quoting ChristopherJam
on large productions, do groups tend to enforce a single assembler for the entire project, or is the code base a bit heterogenous?
As others said already, there is no need to enforce The One Assembler. And why would there be? :) Given the plethora of assembler preferences, no demo coded by many coders would get finished. And already the choice of loader usually gives you the need to work with a second assembler, albeit only once to build the loader with your preferred options.

Good point that enforcing a standard would exclude any coders that didn't wish to switch.

I guess I was thinking it might simplify the build process, or at least make it easier to wrangle linking the handover between parts. (I'm curious as to whether any multiparters use a common kernel for juggling IRQs etc, but that's a whole 'nother topic).

Must admit, it's ca65's linker that's had me considering switching away from xa - as it is I occasionally resort to using a small Python script to parse the .lst from one prg to generate symbols to include into another .a65

Oh, and it also looks like it'd be saner for building and including code targeted for relocation (e.g. to zero page or the disk drive) if I switched to ca65. The hacks I use to get xa to do that are not my favourite thing.
2016-05-05 17:34
saimo

Registered: Aug 2009
Posts: 36		 Quote: saimo, congrats, thats a terribly masochistic way of doing it. :)

@Oswald

LOL

Indeed it bothers me a bit to have to write all those () and ;, but the power, freedom and flexibility I get from the rest outweight the nuisance by a long margin.
2016-05-05 18:05
Hypnosis

Registered: Mar 2015
Posts: 36		 @saimo: Interesting and odd solution to the problem!

I rolled my own assembler.
2016-05-05 18:07
soci

Registered: Sep 2003
Posts: 480		 Writing the instructions directly into the C source to create the desired output is way too easy ;)

Instead of doing that I wrote C program which reads in various text/binary files to describe the output. This way I gained freedom from syntactic limitations of the compiler too.
2016-05-05 18:08
Bitbreaker

Registered: Oct 2002
Posts: 508		 So much syntactic sugar and brainwank for so few releases :-D
2016-05-05 18:46
soci

Registered: Sep 2003
Posts: 480		 That's not entirely fair to him, not everyone wasted 20+ years on the scene yet.
2016-05-05 19:34
Slammer

Registered: Feb 2004
Posts: 416		 "Focus on the journey, not the destination. Joy is found not in finishing an activity but in doing it." - Greg Anderson

But, yes. Finishing something is nice too.
2016-05-05 20:03
Oswald

Registered: Apr 2002
Posts: 5094		 Quote: "Focus on the journey, not the destination. Joy is found not in finishing an activity but in doing it." - Greg Anderson

But, yes. Finishing something is nice too.

now I know why it is so hard to finish a demo :)
2016-05-05 20:07
saimo

Registered: Aug 2009
Posts: 36		 Quote: Writing the instructions directly into the C source to create the desired output is way too easy ;)

Instead of doing that I wrote C program which reads in various text/binary files to describe the output. This way I gained freedom from syntactic limitations of the compiler too.

@soci

Not sure what you mean here. It sounds like you created some sort of custom compiler... is that so?
2016-05-05 20:25
Perplex

Registered: Feb 2009
Posts: 255		 Quoting soci
That's not entirely fair to him, not everyone wasted 20+ years on the scene yet.

Time you enjoy wasting is not wasted time. ―Bertrand Russell
2016-05-05 20:35
saimo

Registered: Aug 2009
Posts: 36		 Quote: So much syntactic sugar and brainwank for so few releases :-D

@BitBreaker

Well, it isn't just syntactic sugar: there's a new dimension that opens up new possibilities. I mean, besides the compile stage, where one can enjoy the power of macros and conditional compiling offered by the C compiler, there's also the intermediate stage of binary generation executed by a self-shaping program, which makes it possible to generate dinamically tailor-made ML code.
Hmm, I can't really find the words... F.ex., it is possible to include a binary file, analyze it, and generate code depending on the results of the analysis.
I feel I'm only scratching the surface for now, but, after all, at the moment I don't need anything complicated, and I'm enjoying the possibility of doing things like this:

pc = EmbedString(pc, "ZONE 1: CLIFFS");

which writes the string at the current pc address, returning the address of the first byte after the string, and mapping automatically the ASCII characters to the characters in the charset, which are arranged in a custom order (currently: graphical tiles, 0...9, A...Z, [SPACE], various symbols). Clean, robust, and easy ;)
2016-05-05 21:03
Oswald

Registered: Apr 2002
Posts: 5094		 since I dont know any other, 64tass can do that for you (and probably most others), as you can define custom encoding in it.

[link]http://tass64.sourceforge.net/#text-encoding[/link]

byte after string is at * after the line .text.


also it has macros, conditinal assembly, all the bells and whistles.

my guess is you were just too lazy to learn a new syntax :)


edit: as I was for like 15 years using c64 native tasm assembler I dont find the need for scripting to write my code generators. I think they can be done in about the same time the native way as with scripting. Bonus is I dont have to rewrite the generator to native when done. Key is to plan the speedcode before starting to write the generator. The flexibility they offer is enough to tweak a little when needed. Esp if you copy a code segment around, you can easily add / remove instructions. I find the most problematic when a speedcode modifies another one, but thats also just a case of counting a bit how much bytes apart those places are. or if you want to be fancy add labels to the cookie cutter code, and some substractions will give you the correct answer no matter how it changes
2016-05-06 03:30
saimo

Registered: Aug 2009
Posts: 36		 @Oswald

Laziness did play a role, but it wasn't the deciding factor. I should have:
1. checked which assemblers are available for AmigaOS (4);
2. studied the features of all of them;
3. chosen the one that would suit me best.
Admittedly, this would have been tedious. But what would have really annoyed me is if, in the end, I would have liked one thing from an assembler, another thing from another assembler, and no assembler would have satisfied me entirely. Mind you, maybe there's a perfect assembler out there for me, but still finding out would have been a pain and a risk. So I did it my own way, which comes with the added bonus that I'm not restricted by the limitations of any compiler, and I can do directly in the code things that otherwise might need external tools and/or manual fiddling.

Regarding the text encoding, sure, I didn't mean to say that it wouldn't be possible/easy in other ways. Actually, that's something so basic that I expected there would be several ways of doing it easily.
The text encoding example was meant only to give an idea of how things work and of the potential (that's why I introduced it with "I feel I'm only scratching the surface for now, but, after all, at the moment I don't need anything complicated, and I'm enjoying the possibility of doing things like this"). It's more important what I said before that, i.e. that this way of generating code dynamically through an intermediate executable can be very handy and powerful.
I'll make the text encoding example a bit more interesting...

Recently, the preview of a C64 commercial game that is/was being crowdfunded was leaked, and the authors were quite pissed. So, let's imagine that one wants to provide reviewers with identifiable executables. There are a number of ways to do that, and one could be generating copies with unique text encoding. In this framework I'm working with, that is done by:
1. adding a function that scrambles the arrangement of characters in the charset in a unique way, and produces the corresponding mapping information;
2. writing a function that encodes the ASCII texts according to the mapping information;
3. compiling the C code once;
4. running the intermediate executable every time it is necessary to produce an identifiable copy.
In the end, it would all boil down to typing "make" in a shell (or some other equivalent operation) - and the result would be obtained very quickly, since there is no compiling, and the intermediate executable outputs the final executable almost instantly.

Or... let's go completely paranoid and generate a unique copy for each person who gets the game: how about having all the subroutines arranged in an order unique to each copy (the permutations are many already with a reduced set of subroutines, so the size of the audience is not a problem)? It would be sufficient to:
1. enclose each subroutine in a C function;
2. define a vector of all the functions;
3. call the functions in different order each time.
The process could be automated entirely: it would be enough to have the intermediate executable on the server that delivers the game and execute it every time a download is requested.
OK, true, no server runs on AmigaOS, but you get the idea :D

Hey, just to be clear, I'm not trying to convert anyone: just showing a different answer to the question "which assembler do you prefer?" and its potential.
2016-05-06 07:04
Krill

Registered: Apr 2002
Posts: 2980		 Quoting saimo
Indeed it bothers me a bit to have to write all those () and ;
I've been wondering why you don't use preprocessor macros to get rid of those (at least for the opcodes with implied arguments), so you'd write "txa" instead of "txa();" using a simple "#define txa txa();".
2016-05-06 07:18
Krill

Registered: Apr 2002
Posts: 2980		 Quoting saimo
Recently, the preview of a C64 commercial game that is/was being crowdfunded was leaked, and the authors were quite pissed.
Care to drop a name? I wasn't aware such things existed (but i'm not really surprised either), and i find this a bit funny. It's crowdfunded anyways, so why not give out previews on a regular basis? But that's a topic for another thread. :)
2016-05-06 07:27
Steppe

Registered: Jan 2002
Posts: 1510		 The game's called "Barnsley Badger", some kind of Monty on the Run clone. Read about it on the Hyperion 64 page on Facebook.
2016-05-06 10:40
saimo

Registered: Aug 2009
Posts: 36		 Quoting Krill
Quoting saimo
Indeed it bothers me a bit to have to write all those () and ;
I've been wondering why you don't use preprocessor macros to get rid of those (at least for the opcodes with implied arguments), so you'd write "txa" instead of "txa();" using a simple "#define txa txa();".

Your observation makes sense, but unfortunately I can only say that I could not have lived with the syntactical inconsitency :p (No kidding, that's really the reason I went that route; but, yes, that solution is tempting.)
2016-05-06 11:27
ChristopherJam

Registered: Aug 2004
Posts: 1409		 Quoting saimo
F.ex., it is possible to include a binary file, analyze it, and generate code depending on the results of the analysis.


Well yes, this is what I usually do with some Python that spits out some assembler to include in my sources. But I can see the merit in having a more integrated system :)
2016-05-13 19:32
fieserWolF

Registered: May 2003
Posts: 3		 I use ACME because I like the name.
2019-09-16 16:06
Raistlin

Registered: Mar 2007
Posts: 680		 I wonder, 3 years on, what everyone uses now?

I know most will probably say "the same as 2016.. if it ain't broke" etc ... but I wonder.

Personally, I'm using KickAss.
2019-09-16 16:10
Frantic

Registered: Mar 2003
Posts: 1648		 the same as 2016..
2019-09-16 16:13
T.M.R
Account closed

Registered: Dec 2001
Posts: 749		 Quoting Frantic
the same as 2016..


Yup, nothing has changed here either.
2019-09-16 17:58
TWW

Registered: Jul 2009
Posts: 545		 same same...
2019-09-16 19:28
oziphantom

Registered: Oct 2014
Posts: 490		 64tass is now even better than it was back then, still the best, and now that I have function identification and break out working, I can now debug at the function level in VICE PDB Debugger..
2019-09-16 19:29
soci

Registered: Sep 2003
Posts: 480		 Quote:

the same as 2016..
Yup, nothing has changed here either.
same, same...

I've got fed up with the limitations and gave in last month. I've stopped using 64tass 1.45 for compiling IDEDOS 0.90 and cleaned up the sources to use a more modern assembler. I'm using a recent version of 64tass 1.54 now. True story.

I think this thread starts to get exiting. (not)
2019-09-16 20:24
ChristopherJam

Registered: Aug 2004
Posts: 1409		 I've switched over to ca65 for all but the tiniest of projects - mostly for the linker and the multiple segment support.

Having routines in two different areas of RAM that can just reference each other's exported symbols directly is sooo much saner than my old multi-pass hacks of parsing .lst files to generate includes. Nice having an assembler that supports unintended opcodes too.
2019-09-16 20:58
Compyx

Registered: Jan 2005
Posts: 631		 Quoting soci
Quote:

the same as 2016..
Yup, nothing has changed here either.
same, same...

I've got fed up with the limitations and gave in last month. I've stopped using 64tass 1.45 for compiling IDEDOS 0.90 and cleaned up the sources to use a more modern assembler. I'm using a recent version of 64tass 1.54 now. True story.

I think this thread starts to get exiting. (not)


Oh Gods, I also use 64tass!!! When did you start using that, and what are your experiences so far? =P
2019-09-16 21:52
Mace

Registered: May 2002
Posts: 1799		 Still using Kick Assembler, though I haven't yet updated to the latest version.
2019-09-16 22:27
Golara
Account closed

Registered: Jan 2018
Posts: 212		 Used Acme for first few months, then KickAsm. I had to buy a new computer cuz I was sick of the slow KickAsm compilation (it was like 1 second, but still).
2019-09-16 23:20
TBH

Registered: Mar 2010
Posts: 21		 Until 2015 I developed natively - used a heavily modified PAL Assembler with 512KB REU. Assemble to memory banks, swap them in and test, etc. Quite fast with no disk access required except for load and save.

Now I use a PC-based system - CBM Prg Studio. It's a bit buggy and some functions are applied in non-standard ways, but it does have some nicely thought-out features, and is quite suitable for my needs.
2019-09-17 02:07
Compyx

Registered: Jan 2005
Posts: 631		 Still using 64tass.
2019-09-17 08:30
Trash

Registered: Jan 2002
Posts: 122		 64tass with my own C#-shell, if I need scripting inline and the assemblers commands isn't enough I just add:
C#
{
..code that returns a tass64 compatible string
}
2019-09-17 09:44
oziphantom

Registered: Oct 2014
Posts: 490		 maybe worth mentioning I added Array adding support to MLA on top of Tass64 and boy has it changed the way I code.. 

lda #!!ArrayAdd { [array name]:[data]}
...
.byte !!ArrayInstance{<array name>}

so this lets me add an item to an array, the add places the index into said array in its place when "assembled" then later you pull out the arrays data to use in tass. For example 
    lda #!!ArrayAdd { copyData:[$2000,$8000,$10]} ; src, dest, pages
    ...
    CopyDataFields .block 
      values = !!ArrayInstance{copyData}
      src .block
        lo .byte <(values[:,0])
        hi .byte >(values[:,0])
      .bend
      dest .block
        lo .byte <(values[:,1])
        hi .byte >(values[:,1])
      .bend
      pages .byte values[:,2]
    .bend

added it on a "yeah why not" and now I basically use it nonstop..
2019-09-17 10:35
ChristopherJam

Registered: Aug 2004
Posts: 1409		 ^ I'm still using Python code generators for that sort of thing. Starting to think it might be worthwhile bastardizing the sort of template engine that usually gets used for generating html…
2019-09-17 12:32
Papademos
Account closed

Registered: Jan 2011
Posts: 8		 I'm a bit retarded so I use my own language called LAX. It's assembler with a c-ish syntax.

// Copy glyph to screen.
y = 0, do
0xf8[0] = 0
a = 0xf0[0][y]
x = 0xf9[0], if !=, do
a >>= 1, ror 0xf8[0]
--x, while !=, endif
0xf2[0][y] = a | 0xf2[0][y]
0xf4[0][y] = 0xf8[0]
++y, y ?= 8, while !=
2019-09-18 20:49
Raistlin

Registered: Mar 2007
Posts: 680		 I just tried converting our code to 64Tass... got it working - but there’re a couple of things that KickAss does that 64Tass doesn’t seem to..? Eg.:-

.fill 64, i <— KickAss would give you a 64 byte array with 0, 1, ..., 63

I got this working in 64Tass only by using a .for loop... which isn’t anywhere near as neat. Can this be done more easily?

KickAss also lets me name blocks easily with just:-

* = $8000 “codeblock”

But in 64Tass I have to drop the name.

Maybe these features are there in different ways - I dodm’t Read the whole .doc yet...?

If 64Tass is much faster i’ll forgive it.. but i’m not sure yet.
2019-09-18 21:19
Raistlin

Registered: Mar 2007
Posts: 680		 Anyone who’s tried 64Tass vs KickAss, i’d be very interested in hearing your thoughts. I am so far finding that 64Tass is faster at compiling, and will probably stick with it for that... but i’ll see...
2019-09-19 05:29
soci

Registered: Sep 2003
Posts: 480		 Quoting Raistlin

.fill 64, i <— KickAss would give you a 64 byte array with 0, 1, ..., 63

I got this working in 64Tass only by using a .for loop... which isn’t anywhere near as neat. Can this be done more easily?

Such one liner table generation is easier with sequences than using loops. The equivalent is: 
.byte range(64)
For most of the cases just replace "i" with "range(something)" in the expression.

Quoting Raistlin
* = $8000 “codeblock”

But in 64Tass I have to drop the name.
Moving around * does not create sections, it just moves the PC and the location of data in the image. Sections and their names need to be defined explicitly. I usually define them at the start like this (with your naming):
        *= $0801
        .dsection codeblock
        .section codeblock
        .word +, 2019
        .null $9e, format("%d", start)
+       .word 0
        .send

        .dsection datablock
        .dsection bss
;------------------
        .section codeblock
start   rts

        .section datablock
bitmask .byte %10000000 >> range(8)
        .send

        .section bss
tmp     .byte ?
        .send

        .send
Results in:
Memory range:      $0801-$0815   $0015
Section:           $0801-$080d   $000d   codeblock
Memory range:      $0801-$080d   $000d
Section:           $080e-$0815   $0008   datablock
Memory range:      $080e-$0815   $0008
Section:           $0816-$0816   $0001   bss

Memory ranges show where data is stored in the image within a section. As only space was reserved in "bss" it does not have any.
2019-09-19 08:22
Krill

Registered: Apr 2002
Posts: 2980		 Real-world question:

Consider a given disk track number, anything in say [1..35], as a compile-time constant denoting the (shadow) directory track.

Depending on the track number (density zone), there is a specific maximum legal sector number.

Now, how do i put in a mapping from track number to max sector number, such that the max sector number can be used as an argument for cmp #imm, with the operand being determined at compile-time?

I've not yet found a nice solution for ca65, maybe another assembler can do that?
2019-09-19 08:26
JackAsser

Registered: Jun 2002
Posts: 2014		 Quote: Real-world question:

Consider a given disk track number, anything in say [1..35], as a compile-time constant denoting the (shadow) directory track.

Depending on the track number (density zone), there is a specific maximum legal sector number.

Now, how do i put in a mapping from track number to max sector number, such that the max sector number can be used as an argument for cmp #imm, with the operand being determined at compile-time?

I've not yet found a nice solution for ca65, maybe another assembler can do that?

KickAsm can do it with simple Hashtable: http://theweb.dk/KickAssembler/webhelp/content/ch06s04.html

I'll see if I can come up with a way in CA65, maybe @Radiant knows?
2019-09-19 08:28
Krill

Registered: Apr 2002
Posts: 2980		 There are char mappings in ca65, which i've not tried yet, but i have a hunch that this will result in at least 35 more lines of code for my specific problem. :)

Edit: Also the .CHARMAP mapping appears to be global and non-resettable, and applies to string or character literals only.
2019-09-19 08:56
ChristopherJam

Registered: Aug 2004
Posts: 1409		 
.define sectors_in_track(tk) (21-tk/18*2-tk/25-tk/31)
2019-09-19 09:09
Krill

Registered: Apr 2002
Posts: 2980		 Haha, brilliant! Glad i stated my actual problem and not just the wrong tree i've been barking up to. X-Y problem averted. =)

The academic question still remains, though. :]
2019-09-19 09:57
ChristopherJam

Registered: Aug 2004
Posts: 1409		 Cheers!

But yeah, if I really need proper data structures I just use Python to generate source for ca65 to assemble. Scripting's not its strong point.
2019-09-19 10:28
Krill

Registered: Apr 2002
Posts: 2980		 I'm generally opposed to the idea of a Turing-complete language embedded in assembly code, though (see above), so having external scripts for the complex stuff is a-okay.

But simple things like mappings i do like to have. :)
2019-09-19 11:04
ChristopherJam

Registered: Aug 2004
Posts: 1409		 Might be able to hack something out of .STRAT?
(cf https://www.cc65.org/doc/ca65-10.html#ss10.16 )
2019-09-19 12:14
Mixer

Registered: Apr 2008
Posts: 452		 Is there any compiler which can count cycles when producing a code listing? This would be a nice feature. Also so that the start/end of counting could be set from within the asm code, and macros. I've got a tool for that, but it could be a feature in a compiler.
2019-09-19 13:01
JackAsser

Registered: Jun 2002
Posts: 2014		 Quote: Might be able to hack something out of .STRAT?
(cf https://www.cc65.org/doc/ca65-10.html#ss10.16 )

Ca65 is quite easy to extend.. ;) and open source
2019-09-19 13:42
ChristopherJam

Registered: Aug 2004
Posts: 1409		 Quote: Ca65 is quite easy to extend.. ;) and open source

Get behind me, Satan!
2019-09-19 14:42
Krill

Registered: Apr 2002
Posts: 2980		 Quote: 
.define sectors_in_track(tk) (21-tk/18*2-tk/25-tk/31)

So i went with this one now: =)
.define SECTORS_ON_TRACK(T) (21 - ((.min(T, 18) / 18) * 2) - (T / 25) - (T / 31))
2019-09-20 06:23
Endurion

Registered: Mar 2007
Posts: 73		 @Mixer:
C64Studio shows the cycle count in the left lane of the editor window.
2019-09-23 15:44
Zirias

Registered: Jan 2014
Posts: 48		 Quoting ChristopherJam
I've switched over to ca65 for all but the tiniest of projects - mostly for the linker and the multiple segment support.
That's exactly the reason I always used ca65. I wouldn't want to do something a bit complex without a linker allowing me to configure the segments and memory layout and the code and corresponding data logically organized in different "compilation units".

If I need something ca65 can't do with macros, I write little C tools generating the code for it.
2019-09-24 07:56
oziphantom

Registered: Oct 2014
Posts: 490		 because 64tass has an internal linker and that lets you perform sheer voodoo :D oh and 1 pass is soo 1984
2019-09-24 09:32
TheRyk

Registered: Mar 2009
Posts: 2244		 Three and a half years of pondering which assembler to use should be enough procrastination alibi, in that time you could have coded dozens of trackmos in SMON. So finally get coding you damn lazy bastards ;)
2019-09-26 11:15
ChristopherJam

Registered: Aug 2004
Posts: 1409		 Quote: Three and a half years of pondering which assembler to use should be enough procrastination alibi, in that time you could have coded dozens of trackmos in SMON. So finally get coding you damn lazy bastards ;)

But, but, I've just realised I need a smart memory allocator to put my 32 byte tables into pages that satisfy (page+1)&0x1f==0x1f so I can safely use SHX abs,y and SHY abs,x with five bit actor indices D':
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
Flashback
CreaMD/React
pcollins/Quantum
LightSide
Shake/Role
HOL2001/Quantum
Guests online: 96
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Mojo  (9.7)
4 Coma Light 13  (9.6)
5 Edge of Disgrace  (9.6)
6 What Is The Matrix 2  (9.6)
7 The Demo Coder  (9.6)
8 Uncensored  (9.6)
9 Comaland 100%  (9.6)
10 Wonderland XIV  (9.6)
Top onefile Demos
1 Layers  (9.6)
2 No Listen  (9.6)
3 Cubic Dream  (9.6)
4 Party Elk 2  (9.6)
5 Copper Booze  (9.6)
6 Rainbow Connection  (9.5)
7 Dawnfall V1.1  (9.5)
8 Onscreen 5k  (9.5)
9 Morph  (9.5)
10 Libertongo  (9.5)
Top Groups
1 Performers  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Triad  (9.3)
5 Censor Design  (9.3)
Top Logo Graphicians
1 t0m3000  (10)
2 Sander  (9.8)
3 Mermaid  (9.5)
4 Facet  (9.4)
5 Shine  (9.4)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.422 sec.