Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

572 Excellent

About danwinslow

  • Rank
    River Patroller

Recent Profile Visitors

17,744 profile views
  1. Makes total sense but never heard that before. You are encyclopedic, Phaeron.
  2. Awesome Necrobump! I've never played it either, thanks for bringing it up.
  3. #Extra memory MEMXM: file = "memx", define=yes, start=0, size=$ffff; } This is what Sanny was talking about. You are defining a flat 64K here of 'extra' memory. I don't know where you got that .cfg file, it has all kinds of extra stuff in it that don't seem related to your stated objective, but ok. As mentioned above, I'd say try starting with the CC65 native crt0.s and the standard atari.cfg file, then adding your segments into that. Seems like you got some kind of mismatch going on. Good luck!
  4. You can define them in the same way you do any segment, but I think those should be already taken care of for you if you are using the standard ( as in, not your own) crt0.s and you have used the correct .cfg file as a starting point for defining your own. You don't need to link in atari.lib or atarixl.lib at all, just use the correct -t argument, but linking them both in is definitely not correct. I wrote something very similar to what you are doing about 5 years ago, and I basically used everything stock from cc65, meaning -t atari and did not mess with the crt0.s. I defined 4 16k bank segments and a lowmem bank with page control, memory page copies, and address abstraction, just as you are probably doing. I'd say try starting with the CC65 native crt0.s and the standard atari.cfg file, then adding your segments into that. Seems like you got some kind of mismatch going on.
  5. It could be LOTS of things. Provide as much info as you can, including what's asked above and what kind of monitor/T.V. you are hooking up to.
  6. XL 'extra' memory? If you mean bank switched memory, do you mean an upgraded XL? As far as I know, only the XE's come stock with extended memory.
  7. Also, looking at code, it seems you are looking for a #13 as a keycode...thinking that is a CR possibly? It's not - atari uses ATASCII, not ASCII and besides you may be getting an internal keycode here and not an ATASCII CR ( which is 155). Then it looks like you try to zero terminate the buffer (although if you've fallen through due to the bne @lp not branching then Y will be a zero when you try to zero terminate the buffer). Not super great at reading assembler off the cuff nowadays but those are some possible problems I noticed.
  8. Just guessing, but problems with low memory usually mean it's been written over by something, usually DOS. How low are you loading, and what DOS are you using? Extended ram is usually better for overlays, but it can limit the hardware types that can be used. Under the OS is also a decent option, but a lot of programs could conflict.
  9. That routine is designed to be called from a handler, not directly from a user routine. See what I mentioned in my post above. Why is it crashing? I don't know, but you could put your emulator into debug and figure it out yourself (especially if using Altirra). Anyway, it's probably a bad idea, you should be using CIO to open the K: handler. It's not impossible to do things with direct calls, but it's generally not a good idea. You could also use one of the the getch() functions of conio.h or stdio.h. From mapping the atari, see the red underlined part: 62436-65535 F3E4-FFFF KBDORG Routines for the display and keyboard handler. The display handler beqins at 62454 ($F3F6) and the keyboard handler begins at 63197 ($F6DD), below. 63038 F63E EGETCH Like the BASIC INPUT command, EGETCH gets a line from the screen and keyboard, but only one character at a time. You must do a JSR $F63E for each character input. This is also the address of the beginning of the screen editor routines. 63140 F6A4 EOUTCH This routine puts the character currently in the accumulator onto the screen in the next print location. Similar to the BASIC PUT command.
  10. Please show us some code and provide context. If you are using C, why are you jumping to what you think are input routines instead of just using the C functionality? Never jump to 'the OS routine at $xxxx'. If you want to do low level IO functionality you must read about and learn to use the Atari CIO system. Everything is done through handlers on the Atari - jumping directly to OS locations is not done. https://www.atariarchives.org/dere/
  11. The 'beeping' is probably the file access noise that is part of OS when reading data from a file, it's probably the boot disk loading. You access a file in CC65 the same way you do in any C environment - you use fopen, fread, fwrite, or fscanf, etc., depending on what you want to do. FILE *f; f=fopen("d1:filename.dat", "r"); ... fread(buffer,len,1,f); and so forth. There are lower levels of access such as the Atari CIO mechanism and even a lower level from C, but that's how you do it in straight C. Then D1: is the 'drive' specification, D1: is teh first drive, D2: is the second, etc.
  12. Because I am talking about a larger effort, not just about the specific code you are talking about.
  13. Oh of course. Avery can hold his own- I doubt the steady pressure of my steely gaze would have any effect if he didn't want to do so on his own Twas just a suggestion.
  14. Do we have the OS dumped out anywhere? Maybe @phaeron would add 1400XL as an Altirra emulation.....
  • Create New...