Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by sanny

  1. I don't know how correctness in language and grammar is related to this, but you're definitely right with your sentence above. Sadly, "we" just don't care much about problems of the 3rd world people 😞 Most of us, that is.
  2. LSP (Language Secret Police) But I do understand your position. I'm a member of the German ReSchPo (Rechtschreibpolizei) 🙂
  3. In this case it knows. Because, yes, it's a constant. But for something like .import BLAH lda BLAH the assembler assumes 16 bit addresses. If "BLAH" is in the zero-page, you'd need to use ".importzp BLAH". regards, chris
  4. Coming from a C background, it should be quite straightforward. Make multiple object files which export some "global labels". Use these labels (like function names or data declarations in C) from other source files, and the linker will resolve all cross-references.
  5. The assembler does not know where the location of a symbol actually is. Only at link time these things are ironed out. So, if a label is not "zeropage" the assembler assumes a full 16bit address. regards, chris
  6. Yes. The linker is your friend, you'll notice only after you understand the whole picture. Forget "ORG" of other assemblers, this seems to be one of the most problematic hurdles... regards, chris
  7. Yes, the µP does the pushing of the status flags.
  8. Yes. At least, I've been contributing Atari stuff there...
  9. Use the -C atari-asm.cfg variant to gat rid of that.
  10. cc65 version 2.16 is quite old. I suggest that you download and compile the latest version from git (https://github.com/cc65/cc65 ) Just check the source code out and type "make" With the errors you posted, no binary would be created. At which bin file did you look at? Don't export a "_main" label in your code, but a "start" label. "_main" would draw in C startup code. regards, chris
  11. your posted program does not compile for me: $ cl65 -O -t atari --start-addr 0x600 test_opcodes_cc65.asm -o TEST_OPCODES_CC65_1536.BIN Unresolved external '_main' referenced in: runtime/callmain.s(27) ld65: Error: 1 unresolved external(s) found - cannot create output file $ You need to define an entry point into your program in order that the linker does not complain, e.g. --- test_opcodes_cc65.org 2020-09-03 18:21:57.676657529 +0200 +++ test_opcodes_cc65.asm 2020-09-03 18:21:39.652362817 +0200 @@ -1,3 +1,6 @@ +.export start +start: + LABEL_01: BRK ORA ($A7,X) ORA $6C Then you can compile it: $ cl65 -O -t atari --start-addr 0x600 test_opcodes_cc65.asm -o TEST_OPCODES_CC65_1536.BIN ld65: Warning: /data/home/chris/classic/atari800/cc65-git/cc65/cfg/atari.cfg(62): Segment 'STARTUP' does not exist $ ataricom TEST_OPCODES_CC65_1536.BIN ataricom 0.30-150320 (c) 2008-2014 Matthias Reichl <[email protected]> block 1: 2e00-2ef5 (bytes: 246, offset: 6) block 2: 02e2-02e3 (bytes: 2, offset: 256) INIT: 2e47 block 3: 0600-0740 (bytes: 321, offset: 262) block 4: 02e0-02e1 (bytes: 2, offset: 587) RUN: 0600 $ Or use the atari-asm.cfg linker config file: $ cl65 -O -t atari -C atari-asm.cfg --start-addr 0x600 test_opcodes_cc65.asm -o TEST_OPCODES_CC65_1536.BIN $ ataricom TEST_OPCODES_CC65_1536.BIN ataricom 0.30-150320 (c) 2008-2014 Matthias Reichl <[email protected]> block 1: 0600-0740 (bytes: 321, offset: 6) block 2: 02e0-02e1 (bytes: 2, offset: 331) RUN: 0600 $
  12. Bad news. I wish his family all the best
  13. Yeah, sorry, "-S" is for the linker, ld65. Use "--start-addr" with cl65, like cl65 -t atari --start-addr 0x3123 -o /tmp/color.com color.c regards, chris
  14. With ca65/cc65 ".org" is the wrong thing. Use "-S <address>" when linking to specify where you want your program to be located.
  15. Thanks for your divine insights, flashjazzcat... I've been working before, not with hard disk controller firmwares, but with floppy controllers. And, surely, they don't get a "buffer size" argument when reading, just "buffer address" and "number of sectors" parameters. And, yes, I was wrong. I've re-read the description in "Mapping the Atari", and the buffer size variable seems to be used only when writing and when returning the number of bytes read. So it's not an input argument. So there is in fact no "buffer size" argument when reading. This voids my comment.
  16. Proposed alternative: honor the "buffer size" parameter. Why is it there if it's ignored? One could want to read just the first 10 bytes of a sector or something....
  17. This appears to me like a recipe for desaster. Give back more bytes than the program requested, overrunning buffers?
  18. Hmm. I've changed in your latest git version the *.s.disabled flles to *.s. Compiled, and it still fits the 16K. Why did you disable them?
  19. Could be tagged as bug in APE 🙂 But I've understood...
  20. Stupid question: Why do you want to include the R: handler loading into the cart? If there is no disk drive present, the ROM will load the R: handler. At least with my 850 it seems to do so according to the SIO sound.
  21. No to you specifically, just wanted to point that out. And it appears the WDC assembler does it "correctly", but all other assemblers I know treat BRK as a 1-byte instruction.
  • Create New...