Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

123 Excellent

About sanny

  • Rank

Profile Information

  • Gender
  • Location

Recent Profile Visitors

5,492 profile views
  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.
  • Create New...