Jump to content

danwinslow

Members
  • Posts

    3,034
  • Joined

  • Last visited

Everything posted by danwinslow

  1. Well, if its a temporary situation, that's understandable. Your desire to cover many toolchains will keep you busy for a long time. Consider an adapter layer, something like maybe what LLVM does, meaning a universal intermediate compilation that then gets run through a particular adapter that would then express the correct source and drive the toolchain.
  2. Kaj - I think a good project would be to do the benchmark suite as found in, for instance, the MAD Pascal thread, and show results and source codes. That would kill 2 objectives with 1 effort. If you want to get real traction for your language here that would be a step towards it. I would not expect someone else to take that on...you never know but when you get things finished to your liking I think that would be a logical next step. We are not as interested in the niceties of language constructs and flexibility as we would be in actual performance and accompanying source.
  3. Wow, looks GREAT. Thanks!
  4. Rust is a traditional language. It has some relatively novel heap-ownership mechanisms that help safety, and it's pretty fast.
  5. Philosophically, it kind of reminds me of FORTH in a way, it's a tool for creating your own language, essentially, thus the name Meta, I think. Cool if you are interested in playing around with language constructs, but I'm still not sure of applicability in our world, which is dominated by tight RAM and speed requirements. Not a shot, Kaj, just my viewpoint so far.
  6. go to google.com type "atari error codes" into the search box press return read what you find.
  7. Harry - Again, this is all probably too hard for you. Try something smaller and easier. TGB *just* explained exactly how it works. Read the code he wrote above. Look up each location in Mapping The Atari. Read as much as you can until you understand what the code is doing. Then you will know how any code in any language accesses the RAM under the ROM.
  8. Bob, I simply gave my opinion. I already know the line is blurred, if that's your point. Faster may not be all that simple, since we've only one accelerator in common usage and it has compatibility problems. Anything anybody wants to do is fine by me, I'm not judging. The point of the thread is that maybe this thing can be adapted to do something cool for the Atari 8 bit world.
  9. Well, true, and that's the point. I'm more on the conventional side of the argument. If you change too much then you might as well just use a modern machine. I would just like a compatible accelerator that would add some extra speed but not radically change the machine.
  10. So, this line of argument has been done to death. We all know where we stand. I would want to use this board as an accelerator plugin to enhance the machine, not render it unnecessary. No 100hz, no thousands of of softsprites....just a little faster of a machine but hopefully more compatible than Rapidus.
  11. Yeah, it's not going to be a 100MHZ atari. But, I think maybe with some work we could turn it into something that would allow extra processing capability during vblank or dli's, that could be very useful. Yes, it's got to live with the external bus speeds, and access to RAM will be as slow. Even just a system that doubled the 1.79 speed exactly would be an mprovement. I don't know if it makes sense to think about some kind of faster RAM local to the cpu, kind of like a cpu cache that it could use, off the bus and free to use at a faster rate while still being able to use the regular RAM. There's a lot I don't know, but we've seen some amazing things done and this just seems really promising.
  12. They said it was 6502C compatible...I thought that was what we used? Anyway, I bet you guys could do something cool with this.
  13. http://www.e-basteln.de/computing/65f02/65f02/ Seems like a neat idea.
  14. -lc C lib maybe? https://stackoverflow.com/questions/6240639/where-is-the-standard-c-library-on-mac-os-x
  15. Well, maybe you can get a 9th byte in there. Progress!
  16. Nice. That's a great bit of syntactic sugar. This is getting to be pretty amazing.
  17. The mystery is revealed in the first post. Anytime somebody posts "This is not a troll"...well, y'know. It is.
  18. You can use a few bits and pieces here and there, but it's generally not worth it as a utility library for general programming. You can use anything that isn't used by the DOS....and you can figure out where DOS stops by using some memory values. You need to READ mapping the atari and de re atari, not just peruse them. You don't need to write us a utility to use low memory, we all pretty much know what is there and can use it if we feel like it. There really is no magical piece of low memory that you can make useful to anybody in the general case, there are way too many failure cases.
  19. Harry, some friendly advice : Stop trying to do something so difficult. You do not understand the Atari well enough yet. You need to read, thoroughly, all of the available documentation and try some smaller projects first.
  20. So....which are the lines in question, and why are they disabled? When you post something, the people you are asking help from should be able to compile and run and re-create the error. Don't make them have to guess. You are asking for people's time and effort, so you should set them up to be able to re-create the error. Typically, you should: 1. Create an example that exhibits the error 2. Include information about how to compile and run 3. Post everything required to do the compile and run
  21. People are probably going to want you to post all your code, along with the .lst and .map files, as they have mentioned in the past.
×
×
  • Create New...