Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by danwinslow

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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/
  8. 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.
  9. Because I am talking about a larger effort, not just about the specific code you are talking about.
  10. 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.
  11. Do we have the OS dumped out anywhere? Maybe @phaeron would add 1400XL as an Altirra emulation.....
  12. Well, we carefully preserve, archive and organize the software products and games. Why doesn't someone start a similar github - "The Atari Source Code Preservation Project" so to speak. Then people can donate source code to it for items of mainline interest as are being discussed here. Then we don't have to remember if person x has source code y and hope they are still alive.
  13. I think this is correct. And, that's a beautiful system.
  14. It would be unusual to not be able to use GCC. What OS are you on? If you are on windows, you should be able to use MinGW: http://mingw-w64.org/doku.php
  15. When the C code is written correctly, CC65 is a very powerful platform that also allows really good integration with assembly and control over memory layout. By 'correctly' I mean 'not like a usual C program'. See ilmenit's tutorials on this site. You do get some benefits from being 1 step up from bare assembler, but as mentioned it's still going to be pretty technical. It has to be.
  16. I'm not qualified to say, exactly, but I've read in threads here that Atari skimped on components and/or didn't do something right on some models. That and interference from the memory operations, etc. Maybe RF is just inherently noisier and lower quality too, not sure.
  17. the signal from the RF is crappy to start with, at least in my experience with NTSC ataris. You can get converters, I think, but they will just show you the fuzz and lines in the original signals at a much higher resolution.
  18. Wow, that's cool. Amazing. How long does it take to render?
  19. Not the wiki about bresenhams. The above is what I meant, although I don't see where Sanny mentioned it. I'll take your word for it.
  20. Nice. I recall an old thread about the fastest line drawing algorithm that also had code examples, but I can't find it before my ADHD kicks in.
  21. If TGI is performant enough, that'd sure work.
  22. The TGI support for CC65 isn't the greatest as I recall (although it may have been updated since I last saw it). I can't remember if there's OS support for plot and drawto, but I think not, and that probably wouldn't be the fastest either. I always plotted directly by writing to screen memory, and for drawto I dropped in a fast line algorithm. You can find them in asm or native C with a bit of googling or searching here. *edit* Actually, I think I recall that there are some graphic libraries that other people have done that you could find.
  • Create New...