Jump to content

danwinslow

Members
  • Posts

    3,032
  • Joined

  • Last visited

Recent Profile Visitors

18,811 profile views

danwinslow's Achievements

River Patroller

River Patroller (8/9)

786

Reputation

  1. My two cents - leave the vbxe and other fancy hardware out of it for now. Finish the original core base, leaving things set up so that folks can reasonably easily add features - i.e., APIs are present for the core system and for a device driver layer.
  2. Indeed. As is the weird behavior of displaying case in file names but it not actually mattering to the file system.
  3. Looks like whatever is building the args of the CA65 call is not (re?) enclosing it in quotes. Just a guess. Can you tell it to show all commands as they are being run?
  4. If he is just using the RAM bank switching capability, he doesn't need to turn interrupts off. That only is needed, as you point out, if he also switches the OS out.
  5. So, I'm wondering how to create a custom stream. I would like new (unread) content from Atari 8-Bit Computers and the Atari ST/TT/Falcon Computers together in one stream. It's not clear to me how to do that...it's probably really simple but for whatever reason I can not see how to do it. I see the 'My Activity Streams->Create Stream' option, but that just takes some viewing attributes and does not seem to let me set which forums I want involved. What am I missing?
  6. Well, you have to write things such that all of your 'processes' get called in the game loop and they all just do a piece of what you want, then save where they are at and return back out to the game loop for the next thing to do. It generally means more time and memory keeping track of where everything was so it can do the next step. So for your back ground drawing that you mentioned, it would do only a part of the pixels each time it is called. You have to be sure that you don't lock up too long in any one operation. You can't really use BASIC with VBI, unless you want to write that part in assembler. Writing in a lower level language like Action! or C or Mad Pascal you could do more of what you're talking about.
  7. My point was not about loading software, it's the ability to play action games with others, requires a lot of fast packets. Serial anywhere in the chain makes that too slow.
  8. A Fujinet which was not trapped behind SIO would be awesome (meaning it would transfer via the 1090 bus) but some of the interface/driver software would have to be rewritten I would think.
  9. Harry does not read help. He just asks here, and someone unfailingly helps him.
  10. The way to say it is: In the CC65 Atari library, the Atari "IOCB" construct has been completely abstracted under the C standard 'File Descriptor' concept. It is still possible to use either or both in a program, but mixing the two in the same program can lead to problems. In my opinion, the memory cost of pulling in a bunch of stdio stuff supporting the file descriptors is too high, and I just wrote a thin utility layer over IOCB's and used that. Where the CC65 stdio library really comes into it's own is for quick utilities and also when cross compiling non-Atari c programs.
  11. Look, it's not thinking. It's just pattern recognition and response production on a mass scale. It has been trained on millions of input patterns and responses of, well, us. In a very real sense we are just hearing our own words/code repeated to us.
  12. I've used a system similar to what's been mentioned above. With CC65, I used the linker config to setup named code banks (bank1, bank2, etc.,) all at $4000, and used segment names to organize code and data into each one, each in it's own file. Then I had a small loader function that would load the banks one by one, flipping banks as necessary. I also had a table of metadata about the bank locations of various functions and data, and a function caller that would change bank as necessary, and call the function. It's much better to organize groups of related functionality so that most of the calls are within the same bank. Even duplicating sets of functions, for instance, utility functions across the banks can help a lot with the switching overhead.
  13. I don't understand much about what's going on here, other than it is something about cassettes, but I just wanted to say that the above quote is now my favorite way to express excitement.
  14. Yeah, casting is a way to tell the compiler 'shut up, I'm doing this on purpose'. memcpy is, under the hood, just using the same kind of memory move that you would roll up yourself in machine language. I thought there were separate memory areas for each PMG, so it wouldn't be that they are overwriting each other in actual ram...more likely that you need to look into the way that the color priority works if they do overlap on the screen. Check out documentation around GPRIOR...I'm no expert but I expect it's somethign to do with that. Never mind, I missed the 'missiles' part in your question. TGB is probably right...you could still use memcpy, but you need to figure out things about what exactly you are moving and when. I think its not about whether you are using specfically memcpy or not, its more about how you are using any memory move capability. YOu didn't give a real full explanation as to what you meant by 'cancelling each other out' so its hard to say.
×
×
  • Create New...