Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by sanny

  1. 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.
  2. 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....
  3. This appears to me like a recipe for desaster. Give back more bytes than the program requested, overrunning buffers?
  4. 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?
  5. Could be tagged as bug in APE 🙂 But I've understood...
  6. 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.
  7. 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.
  8. Even if the opcode sets "addr + 2" as return address from the interrupt, any system I know treats it as a 1-byte opcode. The IRQ handler returns to the address of the BRK + 1. And, for a two-byte opcode, the correct syntax in the assembly source would be brk #num instead of just brk Wouldn't it? regards, chris
  9. Just to add to the options to create tokenized BASIC programs from ASCII input... 🙂 You could also use the atari800 emulator in "basic" mode. In this mode it doesn't open an UI and just uses stdin and stdout. AFAIK no precompiled binaries are available for the "basic" version, so you will need to compile it yourself. Configure the build process like this: ./configure --with-sound=no --with-video=no --disable-riodevice Then create a small text file (script.txt) with the inputs to the emulator, ENTER "H1:INPUT.ASC" SAVE "H2:OUTPUT.BAS" and run the emulator with something like atari800 -basic <path_to>/dos25.atr < script.txt What host dirs are referred to by "H1:" and "H2:" is configured in the atari800 config file. regards, chris
  10. With your change you don't reserve any memory anymore. But you are using GRAPHICS 8. I'm not sure this is correct. If you need to reserve memory, you can change your atari.cfg file either to put the value there, or make the symbol weak and do it like before on the linker command line. I've noticed that the atari-cart.cfg in cc65 also doesn't declare it as "weak". I wrote the original version and I don't remember why I did change it to non-weak. Maybe that's also wrong in cc65. I've managed to build a version with ST mouse support (which had the biggest overflow in my test) with a modified cc65 runtime library. I did this change: diff --git a/libsrc/atari/tgi/atr8.s b/libsrc/atari/tgi/atr8.s index 7d2a6386..f4ff8a09 100644 --- a/libsrc/atari/tgi/atr8.s +++ b/libsrc/atari/tgi/atr8.s @@ -80,4 +80,5 @@ loop: lda (ptr1),y rts .endproc +USE_CIO_LINE = 1 .include "atari_tgi_common.inc" This changes atari_tgi_common.inc to use the ROM to draw lines instead of using its own implementation. Caveats: it's not documented (I found nothing) it has not been tested much, I think, since no one knows about this knob. Therefore using it will require some testing sessions. regards, chris
  11. I'm using latest cc65. And, in fact, the error is correct. It's not declared "weak" in src/atari/atari.cfg.
  12. Is it correct that the last commit to this branch was on May-14-2019? I'm getting a build error there: [blasi:~/atari800/platoterm64]$ make cl65 -t atari --start-addr 0x2420 -Wl -D__RESERVED_MEMORY__=0x2000 --mapfile plato.map -o plato.atari -C src/atari/atari.cfg obj/atari/screen_base.o obj/atari/protocol.o obj/atari/terminal.o obj/atari/keyboard_base.o obj/atari/plato.o obj/atari/io_base.o obj/atari/touch_base.o obj/atari/mulfuncs.o obj/atari/terminal_char_load.o obj/atari/touch.o obj/atari/screen.o obj/atari/io.o obj/atari/font.o obj/atari/keyboard.o obj/atari/cartinit.o obj/atari/click.o obj/atari/cartstart.o obj/atari/screen_beep.o obj/atari/fast_text.o ld65: Error: Duplicate external identifier: '__RESERVED_MEMORY__' Makefile:311: recipe for target 'plato.atari' failed make: *** [plato.atari] Error 1 [blasi:~/atari800/platoterm64]$ Strange. I think I was able to compile it successfully months ago. regards, chris
  13. Ok. In CBM world at least (I just have some C64 knowledge, not much of the other machines). On C64, the load address of a BASIC program is always $0801. In this regard it wouldn't make much sense to store the load address also in the PRG file. But, one can also load files at arbitrary locations (as specified in their PRG header). 'LOAD"file",8' will (on the C64) always load the file to $0801. But 'LOAD"file",8,1' will load the file to the address specified in the PRG header. On the C64 the area $C000..$CFFF is free, beyond the BASIC ROM and not used by BASIC. So you typically loaded utilities (like machine language monitors or such) to this address and started them with SYS49152. My fingers still remember to type this address... 😊
  14. My CBM-fu is rusty, but I think it worked like this: A PRG file contains the load address in its first two bytes. DOS knows the length of the file from the file system. So 'LOAD"PROG",8' loads the complete contents of the file to the load adress. The first part of the file contains a small BASIC program which just calls SYS. The rest of the file is the machine language program. The parameter to SYS is the entry point into the machine language program loaded beyond the BASIC stub.
  15. If you have a DragonCart, you can use telnet65 ( regards, chris
  16. "MA65"? IDK it. But sure, everyone has his opinion and his way to tackle problems. cc65 linker scripts are difficult at the beginning, and then a "breeze". That's my opinion, others might disagree. I just wanted to give the OP another option. And, of course, I'm biased, since I wrote the support for the "atarixl" target in cc65.
  17. Nobody (at least not I) suggested that.
  18. I didn't mean you should write your program in C. If you could live with ca65 (the assembler included in cc65) instead of mads, you could write a main() Program in C which does nothing more than calling your assembler routine. You would have the memory under the ROM directly accessible. Some caveats exist, bunt in general that's the case.
  19. You could use cc65's "atarixl" target 😊
  20. Where is the "go to first unread" button? When I enter a (long) thread and want to forward to the new posts? regards, chris
  21. What I was told (a very long long long time ago, when I was writing BASIC programs for other systems), is that with interpreted BASIC, put the subroutines at the top of the program and jump (GOTO) over them in the very first lines. An interpreter typically searches from the beginning of the program for the line of GOSUBs (and GOTOs), and if they are at the beginning this search is faster. Don't know if this is the same in ATARI BASIC. Just wanted to mention it. regards, chris
  • Create New...