Jump to content

danwinslow

Members
  • Content Count

    2,850
  • Joined

  • Last visited

Everything posted by danwinslow

  1. Doesn't help *your* goals, maybe. What's wrong with Action? It's a great language, and look, no errors, no bugs that you can find in 'longer than a few lines'. What is it exactly you think we should do? Encourage use of languages you like?
  2. Well, no one besides us (who would do it anyway) would develop in MPascal, MIllfork, or KickC based on a bunch of stuff in rosetta code, which is hardly a 'go to' resource for most developers. I think you might be missing his point.
  3. For the TSR type thing, you have to drive it off of an interrupt. VBI/VBD is always an option, you can chain yourself in there even if something else is already (provided they did it the right way). I've also driven things off of one of the pokey timers. As always, you need to attend to the stack/regs and CRITIC and so forth. Anyways, from a high level: get yourself loaded somewhere safe, steal the interrupt vector by replacing it with your routine, saving off the old one if you want to chain to it when you are done (VBI/VBD, usually pokey you wouldn't do that) and also to replace it if you quit. You finish the VBI/VBD by jumping through the old vector, if I recall, and from pokey you'd RTI. Both need attention to putting the stack and regs back together as necessary. For pokey you need to do some setup and control the rate you want. There's lots of examples in docs about VBI/VBD, pokey interrupts are slightly more exotic but there's still a lot out there. If you are ok with cross compiling on a PC, you could look at MADS or CA65. I used CA65, but if you write the C correctly you can actually use CC65 to do interrupts fairly well. The whole CC65 toolchain is fairly complicated, so you might want to look at MADS for just straight assembly. If you want to do it natively on the Atari, I'm not sure what's best but I'm sure someone will have a recommendation. For the BASIC question, I think you just PEEK(addr)+PEEK(addr+1)*256, or use DPEEK(addr) from one of the more advanced BASICs.
  4. That's a pretty clear error message. You are directing 858 more bytes into LOWCODE than it was defined to hold. You might need to put in some segment pragma control in your source code, which is one reason sanny needs to see it. It is a complicated subject, and puts a lot of people off from using CC65, but it is well worth the effort. You do just about anything with the cfg files.
  5. I wrote a few simple games in Valforth on the Atari. One of my thoughts about Forth is that it's not really a 'language to write a program in'. It's more of an 'engine to define a language to write a program in'. In essence, it's kind of like using assembler - you build all of your own language constructs. If you do it in an haphazard, informal way, you'll probably hit a wall at a certain level of complexity. That's why you need to define your words in a consistent, highly factored, loosely coupled way...just like language designers do when designing a language.
  6. From what I can tell, I think it's best to just help him along as we can, and not worry about whether he's doing something particularly productive or effective. That's just my 2 cents on the matter. What he's doing sounds duplicative to the em driver to me, but who cares. Harry - "Extra" memory- 1. Under the OS. Only on certain machines. This is just part of the 64k RAM address space. 2. Banked (or extended) RAM. This is any one of a variety of memory expansions, including the 130XE. 16K blocks mapped into $4000 by fiddling with PORTB. Axlon might be different, not sure, but same idea. 3. Unused memory. Regular RAM locations that are unused under certain circumstances. Printer buffer, cassette buffer, various FP bits and pieces, some ZP locations, etc., even under the stack if you are adventurous. Well documented over the years, but subject to a lot of variability depending on machine config.
  7. I'm not equating everyone here with my preferences...this might be a language (human, not meta) problem, but I think I understand what you mean. I clearly stated it was my own opinion. I think it's quite presumptuous of you to wave your hand and refer to criticism as 'grave misconceptions'. What were the grave misconceptions you refer to? You seem to think that any negativity or criticism results from us just not understanding things correctly, and when you have time to 'explain' then we will all see that you are right. That more than anything else is what has turned me off from this discussion. I see you started another thread, I think that's probably a good idea because there were some kind of rude posts, which if you'll recall, I spoke against. Good luck with your project.
  8. Harry - Action doesn't need 'support'. If you want to learn it to use it, then great. Read the docs and write code. No one needs a 'template creator', it's just not useful.
  9. Yknow, Kaj, taking criticism as "grave misconception" is not helpful to your argument. These guys know their stuff. If one disagrees with you, well...fine, that happens a lot. If two do, then hmmm ok but still. If nearly everyone is saying the same thing - you're probably wrong. You like REBOL, I get it. To me, it's a bizarre language that as far as I can tell never got much traction, but OK, maybe be I'm wrong. Do your thing, I appreciate the effort and skill it takes. But don't expect people to actually use it for much, this is entirely the wrong target market.
  10. Some kind of numeric over/under flow I would guess.
  11. NTSC Looks like there's a composite out and a DIN. I need to read up. Back later.
  12. Yeah, I had too. Got the manual off of it, but was wondering if anyone had done any LCD hookups. I assume a composite converter of some sort might work.
  13. Any advice on getting one of these hooked up to a modern monitor via s-video or some kind of converter?
  14. C'mon now. It's his thread and his pet project. No need to get sassy, he's been perfectly polite to all questions and criticisms.
  15. Just to be clear, my post was an attempt at a wordplay joke, not an opinion on any preceding posts.
  16. Yes, indeed. Dealing with perception is difficult, depending on your perspective.
  17. Um, neither projection is 'real'. The FA one does not respect some points of proper perspective handling. The FA one is more like moving sideways rather than actually turning. Not a huge deal to me, but it's there.
  18. Just me, but I don't think you should worry about the 64k limit. You've done this - it's amazing. Grab another 64k and go nuts for V2.0. The user base nowadays is pretty upgraded, and there's always altirra.
  19. Ok....well, you said "it needs many different, highly complex and hard to handle existing C toolchains". That was what I was talking about. If you got it covered design-wise already,, great.
  20. 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.
  21. Well, I do of course, but I don't want to have to just to write programs. My opinion.
  22. 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.
  23. Rust is a traditional language. It has some relatively novel heap-ownership mechanisms that help safety, and it's pretty fast.
  24. 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.
×
×
  • Create New...