Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by danwinslow

  1. Now now, don't get your feathers ruffled and start calling us 'not programmers'. I've been programming my whole life. Programmers are almost always fanatics of one sort or another. I was just saying that it's very common for people to not like a bunch of off-the-forum topic posting, especially since there *is* a forum here for the subject. You can do what you want.
  2. I'm fascinated with how much focus you guys put on the sound tracks for things. I mostly find them annoying, especially if they play constantly throughout the game. That's just me, though.
  3. Well, there IS a commodore forum here, you could start a thread over there. That said, I don't care all that much but I keep looking at this thread thinking I'll see something cool for atari with MP but, nope, it's still you and Funkheld talking about commodore stuff.
  4. The probable reason for the size is that you are using std library calls like printf, fopen, etc. Those pull in the entire stdio library even if you just use 1 call. Use conio.h or write your own IOCB calls. CC65 is capable of writing extremely powerful games, all in C, but you need to do it correctly. There's lots of information about how to write optimized CC65 code.
  5. ok. Well, if you want meaningful commentary, you'll need to take the time to provide context. I have no idea what you are talking about at all from your post. Glad you got it sorted tho
  6. Ken - good to know, that sounds good. bfollowell - I'm not missing that. I get it. But if they do lovingly build a 1090 replica...then what? We wait for boards to be developed, is then what. Since we've got a bunch of stuff already, as you've mentioned, people would have to fund and develop essentially duplicate boards to go into it. I was suggesting we make it as easy as possible to re-use some of the more modern stuff with it. Maybe that's not even possible, I don't know. I'm all for what they want to do here (and Ivop's idea too), just being realistic about it.
  7. It's to prevent variable name collisions between 'namespaces'. Lots of systems use it still, but you only run into it when mixing direct calls into C libs or using mixed assembler, etc. I think it's actually a C convention. You should see what modern c++ does to internal names.
  8. Well, OK, sounds good to me. I have nothing against the usage of as close to original as possible, but I think we should improve where possible. Full buffering for the bus, and maybe an option to adapt already produced modern boards/devices where possible, so we don't have to wait for entirely new boards to use with it.
  9. True enough, but using modern board production and components would be somewhat cheaper. Sourcing ancient parts and getting weird old boards made would be a lot more custom and more expensive per unit even if the run were in the hundreds. I think. Anyway, I kind of agree with Sugarland, I don't have any nostalgic feelings about righting the wrong that Atari never got the 1090 out the door, and so we now need to recreate it. What I want is utility. If it comes in a nice 1090 box, all the better. I want plug in boards for things that now take soldering, basically. Video cards, accelerator boards, etc. Who knows what we could do with a good PBI bus? I agree that it should have a basis in the Atari bus idea, I mean I'm not suggesting we just attach a modern motherboard or anything. Maybe we should combine this with the Atari Backplane Computer being discussed elsewhere.
  10. i don't know that I personally would want an EXACT copy. Seems like we could do it better/faster/cheaper with at least some modern tech and still preserve the essential 8 bit nature. Easier to source parts, as well.
  11. Yeah, the underscore gets slapped on automagically.
  12. this is the good part of CA65's complexity
  13. Well. Can't help with the hardware side directly, but I'd sure put some money up.
  14. The "OS" means operating system, and that is separate from DOS (Disk operating system). The OS is ROM, generally, and does not directly support writing files to disk drives like a DOS does. You need a DOS for that, there's lots of them, all with different memory usages below around $2000. There are really only a few variants of the OS roms, and you can google for Atari OS roms if you want more info. It's 10k-ish of rom. As I said, you can swap it out if you want and use the memory beneath it but some of the DOS's (Disk operating Systems) already do that depending on settings. Sounds like DOS2XL does that, from this thread : So, a DOS loads disk device handlers to support calls. An FMS is kind of the same thing as DOS, sometimes it's a separate part but mostly it's all one and the same thing. I usually take 'FMS' to mean the user interface for the DOS and the DOS itself to be the device handlers. Anyway, nobody uses the FMS term much nowadays. CC65 does not support DOS2XL in particular., as far as I know. It does not support any DOS in particular. It's up to you to arrange things so you don't stomp on memory used by the DOS. Read up on how to set your program org and so forth in CC65. If you want to do file IO in CC65, you can either use stdio.h calls, or you can write your own calls to the resident disk handler (meaning the DOS) using the IOCB's and CIO calls. If there are drivers loaded for disk (meaning you've got some kind of DOS loaded), then you should be able to call the driver with either method. I don't know a whole lot about DOS2XL, so, I can't say for sure. There really isn't much 'unused memory', is what we've been trying to tell you, other than what is being used by the OS, the DOS, and your program. If you decide to use one particular DOS, then you can tailor it to that. There are maybe a k or two you can scrounge up if you work at it in low memory in non-contiguous pieces. You can find out more in this thread, which I found using search : So, you can educate yourself and scrounge up some stuff from low memory, or you could use extended memory, or you could swap out the OS. It all depends on what you want to do, who the intended audience is, and what the use case is. Most people writing things that need a lot of memory do things like write a custom file driver or use a very low footprint DOS, punt the OS and just take the whole machine over.
  15. Yes, CC65 supports automatic access to passed in variables. Look at the ASM keyword. RTFM, in other words
  16. No offense intended, but just because you don't understand what's happening does not mean there is 'out-of-control' complexity. CC65 has exactly the boilerplate it needs to generate in order to work correctly in all situations. Plus, as Wrathchild mentioned, when you use stdio.h functions you get stdio library pulled in. That is not unreasonable.
  17. Harry, all due respect, but you might need to learn more about the atari target before you try this. You mentioned $1401, looking at it in Mapping the Atari says it's a disk directory buffer. If you have any kind of a DOS loaded, then no, it's not available. (DOS=FMS, for my purposes). Yes, typically the DOSes can read each other's files. As Thom mentioned, there is very little that is 'safe' under around $2000 unless you want to specify 'only use with this particular DOS' or 'only use with out one'. If you tried really hard, you could find probably a few pages worth of memory that you can squirrel things away in below that address, but it would be hard and not particularly useful. Believe me, it's a subject that has had much scrutiny over the years. Page 6 is famously supposed to be free, but ironically, because of that, it often isn't. There's some bytes free if you aren't using a basic cartridge, there's a small amount of zeropage stuff and I've even used the top half of the program stack. The cassette buffer is also usually free. You mention 'extended memory' - the atari has 2 sources of that. One is extra bank-switched RAM provided by the 130XE or upgraded older computers, the other is obtained via switching out the OS for 10k worth of RAM, which also doesn't work on every model, as far as I know, and has to be done carefully by stealing interrupts and swapping the system back in as needed. As far as I know, there are already malloc implementations for CC65 that allow usage of extended memory. I know I wrote one for my own use, using a 24 bit bank number+address convention. It works ok, kind of slow on a byte by byte basis but if you have set of buffer locations somewhere in non-extended and you are smart about how you do things, it's not too bad. Many people just use entire banks (16k) to swap in and out, with the banks each having a particular purpose. Read up on $D301 in mapping the atari : https://www.atariarchives.org/mapping/appendix12.php
  18. It's a complicated topic. Sometimes things are free and sometimes they aren't, depending on what OS and DOS you're using. If you're talking about the cassette buffer, yeah its mostly free usually. The big question is - are you writing like a driver that would be available across all combinations of OS and DOS (points to pile of Thom's hair on the floor), or just a program that runs just for itself?
  19. wondering that myself, I thought Rapidus was kind of a cool device.
  20. Yep, sounds like you know what you're doing. Keep us posted,
  21. why wouldn't they work in byte array elements? That seems odd.
  22. Yeah, moving it to FB would be a much better experience for you I think. CC65 and C language port would be a lot more technically intensive. To answer the stack question - the parameters for a function call, generally speaking, are stored on the C memory stack, which is not the same as the system call stack. Small calls like void foo( char a,x,y ) can be made to show up in the registers...using fastcall I think? I forget exactly, but its something like that.
  23. Probably missing the point, but...of course, since you commented out the close?
  24. Rapidly looping through all of the screen modes was never a use case I tried...there may be some subtleness going on with that aspect.
  25. For this particular subject, you can use a command line setting, but I highly recommend looking at the linker config file stuff. CC65 is very config-file dependent. You won't get far unless you learn at least the basics of the linker config stuff. The payback for this is that CC65 is extremely flexible and powerful, providing full control over all aspects of memory placement and linking operations.
  • Create New...