Jump to content
Sign in to follow this  

About This Club

DASM is an assembler that's commonly used to develop for the Atari 2600, Atari 7800, and Fairchild Channel F VES.

  1. What's new in this club
  2. Thanks for the explanation. In my case, the argument is already a quoted string, not a label, so = is correct and my comment about setstr was superfluous.
  3. SETSTR makes a string literally from a symbol name. SET evaluates the value of the stuff on the right side of the SET command, and assigns that value to the symbol. Using = is the same as SET, except it's a constant symbol assignment, where you can repeatedly use SET to assign different values to the same symbol. (This is particularly useful when you want to generate look-up-table data instead of using constants, but by no means the only use for SET) This code... processor 6502 org $1000 MAC testset myset1 = {1} myset2 SET {1} mysetstr SETSTR {1} echo "myset1 is",myset1 echo "myset2 is",myset2 echo "mysetstr is",mysetstr ENDM mylabel testset mylabel ...will result in this output during the assembly... DASM 2.20.14-SNAPSHOT /usr/local/bin/dasm scratch.asm -f3 -sscratch.symbol.txt -lscratch.listing.txt -I. -I../includes -oscratch.bin myset1 is $1000 myset2 is $1000 mysetstr is mylabel Complete. (0) This is the main use case for SETSTR - so you can have a macro report which symbol it was called with.
  4. Ah. I was not aware of the 2.20.14 release. 2.20.13 does not support 'setstr'. TBH I’m not clear on the difference between 'set' and 'setstr'. The = seems to work fine in this case.
  5. Very nice. But AFAIK the latest DASM supports 'setstr'.
  6. I often want to check the top nybble, and there might be uses (bankswitching?) to check other ranges. This version can check any number of bits on either the high side or the low side. This also uses no global symbols. The trick to getting rid of them was to assign a local label from the parameter in the leaf macro. mac samebits ; {numbits, addr1, addr2, mask, side} list localoff .numbits = {1} .addr1 = {2} .addr2 = {3} .mask = {4} .side = {5} ; current dasm doesn't have setstr .addr1masked = .addr1 & .mask .addr2masked = .addr2 & .mask if .addr1masked == .addr2masked .SAMEBITS_EXISTS ; defined if non-masked bits are equal endif ifnconst .SAMEBITS_EXISTS echo "ERROR: ", .side, " ", .numbits, "bits difference (", .addr1, ",", .addr2, ")" err endif endm mac samelow ; {numbits, addr1, addr2} samebits {1}, {2}, {3}, [1<<[{1}]]-1 & $FFFF, "low" endm mac samehigh ; {numbits, addr1, addr2} samebits {1}, {2}, {3}, ~[[1<<[16-[{1}]]]-1] & $FFFF, "high" endm mac prevsamelowas ; {numbits, addr} samelow [{1}], .-1, [{2}] endm mac nextsamelowas ; {numbits, addr} samelow [{1}], ., [{2}] endm mac prevsamehighas ; {numbits, addr} samehigh [{1}], .-1, [{2}] endm mac nextsamehighas ; {numbits, addr} samehigh [{1}], ., [{2}] endm mac prevsamehigh8as ; {addr} ; deprecated: use prevsamehighas instead prevsamehighas 8, [{1}] endm mac nextsamehigh8as ; {addr} ; deprecated: use nextsamehighas instead nextsamehighas 8, [{1}] endm
  8. Sure, you're welcome. You can't use dynamic labels directly as a macro argument, but nothing stopping you from doing something like... mymacroarg SET ARG,INDEX,"VAL" ; mymacroarg is now whatever ARG#VAL is mymacro mymacroarg
  9. hi, thank you so much for your work @RevEng question: this dynamic labels can be used to pass a dynamic argument to a macro? cheers.
  10. I just remember being outraged when I formatted a newly purchased 120MB hard drive, only to find something less than 110MB free, give or take. Actually, 120MB according to the manufacturer was 120*1000*1000 bytes (Mega being 10^6). So in my terms, divide by 1024 and again... gives just over 114 "MB" I expected. In terms of 120, losing almost 6MB seemed... cheating. I was most upset with the drive manufacturers for many years, not only for that "cheating" but later on for forcing KiB on us Edit: update in calculations and trying to make the point that you lost even more space with formatting. According to https://www.tweakandtrick.com/2013/07/lost-storage-space.html a 2TB drive "loses" more than 185GB (!!)
  11. Originally the difference was not that large. A 500 MB HDD was ~4.9% smaller than a 500 MiB HDD. But an 1 TB SDD is already ~10% smaller than a 1 TiB SDD would be. And that gap will increase more and more.
  12. TY, yes. I have rewritten it but did not publish straight away, as I'm a bit wary of doing too many updates. It came about because I was having a bitch about drive manufacturers using /1000 instead of /1024 when mentioning their drive size in megabytes. The upshot was, the drives seemed much bigger when you talked in K (1000) rather than K (1024). I hated them for it, still do. But I figured it didn't belong in a dasm manual. Here's the rewrite, which will be there next update. "Historically, disk drive manufacturers were responsible for this change in meaning of the "kilobyte", as they divided capacity by 1000 instead of 1024 when listing drive size. This not only made their drives seem bigger, it created an ambiguity when discussing computer and disk memory size. The adoption of the new SI units for computer memory size removed the ambiguity."
  13. the for reads strangely to me.
  14. Nothing wrong with being precise. Especially in a document.
  15. TY. Now fixed. I also changed the memory size description to SI units, which I expect will be unpopular.
  16. There are a couple of errors regarding the 2600 in chapter 8: The console is from 1977, and the 6507 has 13 address lines so it can address 8k of memory
  17. For those who like to necro-read, I just wanted to comment that DASM has a totally new manual, available from DASM's homepage. It deals with the REPEAT/REPEND stuff, with examples. Whoever wrote it did a splendid job. Gets my A+ rating https://dasm-assembler.github.io/
  18. The manual is now a part of the "official" distribution, and can be retrieved from the DASM homepage... https://dasm-assembler.github.io/
  19. Update. I've incorporated the suggestions made above. You can easily review changes via the "Change Log" on the page after the title page. Edit: Please grab from the dasm homepage
  20. Not just readability, if you search your source for label you'll be taken to everywhere the label is used label: you'll be taken to just 1 location, where the label is defined. This can be very useful at times.
  21. A changes page will be useful, with added, modified, removed and deprecated features from the previous document version.
  22. Ok... I guess I just missed it then. Thanks for the quick response.
  23. It's not a book on how to program in assembly, so no. Having said that, I'm pretty sure it mentions labels must be first on a line. "Label definitions start at the beginning of a line and are encoded in ASCII; they must start with a letter or @ or _, and can include letters, numbers, and some symbols." in the chapter "Symbols and Labels" Also, "There must be whitespace before a directive. Thus, directives must not appear in the first column of any line." Chapter "Directives" I'm rapidly changing stuff, though I believe the above are in the version you were reviewing. Thanks for the feedback.
  24. I just read thru it real quick. Good start. Do you plan on including an "intro" section? Going over the basics of a sample assembly file.... Something where first time users can learn the most important things like: labels MUST be the first thing on a line (no whitespace allowed) and everything else REQUIRES whitespace to precede it on a line. (One of the features I hate)
  25. Thanks. There are lots of errors and typos. This is an early version and very rapidly cobbled together. It will improve as I attend to issues you and others point out. I have not discussed with DASM maintainers if it will be included. I am assuming so. I just did a version check on my local version and used that. Will fix all. Ta. That is not correct. There is ONE source file (required), and zero or more options. If you enter no options, then it just assembles the source file. I'll try and make it clearer. The source file is kind of mandatory. I have no idea what it actually does. Hopefully we can find out. I need to clarify the use of PC. There are two "address counters" - the origin and the relocatable origin. When bytes are placed in the binary, they must be assembled in increasing order. No "random access" when building a binary, basically. That's what this is trying to say. Will have a think about how to explain this in detail. Yep, ta. Yep, ta. Just for readability, I think. Personally I hate it and would remove it from the assembler. But it appears to be much-loved. Thanks for the feedback.
  • Recently Browsing   0 members

    No registered users viewing this page.

  • Create New...