Jump to content

danwinslow

Members
  • Content Count

    2,846
  • Joined

  • Last visited

Everything posted by danwinslow

  1. You can always write to screen memory? If I understand your point correctly.
  2. Mad Pascal is probably the closest, although if you mean 'safe' to include no pointers, then not it either. Safety usually costs some amount of either complexity, speed or memory. The 8 bit is so constrained it's usually not worth it. Java can tell you that 'no pointers' by itself does not equal safe. I come from an Ada background, a famously 'safe' language, and programmers generally hated it because of what it wouldn't let you do. It happens to still be my favorite language, but nowadays everybody uses Javascript, which I don't event consider a full language and is so bizarrely unsafe it reminds me of C, although at least C has a coherent syntax. Ah, progress.
  3. Funk - I find your complaining boring. The world is not about you. If you don't like this language, then just don't post. If it's no good, it will die on it's own. Why don't YOU bring this 'fresh wind'? You can do do at least little programs. greeting
  4. you don't need to type it all those embedded asm() calls just because you need the variable linkages. You can see C symbols just fine in your .s files, just do the correct externs and .imports. That said, sounds like pps might be on to something.
  5. Please don't quit on my opinion - I am often wrong If you are trying to save code space rather than execution time, then yeah maybe it's not needed. But if you want to use your simple_io as a basis to work in a familiar environment or convert something that is written to use those calls, then setting them up to call the CIO handlers won't really add much code, and you can probably reduce the code space used by conio.h functions somewhat by setting up your own, specifically optimized, CIO calls.
  6. You commented out your store of the printc jmp address in crt0.s, so now you have a JMP $0000 in there which is definitely going to be an issue. Looks like you were trying to jmp to the address in $E406 with a 1 added to it (?), which I guess is some kind of E: handler entry point, and the same thing for $E414. You don't have to do it like that, you could set printc up in C as a function pointer and set the address at that time, or just drop into ASM and jmp yourself, look at the options for the asm() function to see how to get symbol addresses/values into your asm statement. Your C program will start directly after crts0.s jsr to your main, so you can put any initialization you like there rather than messing with crt0.s itself. Let me just say I think (if I understand) what your seem to be trying to do is probably not a great idea...if you are trying to jump around the CIO handlers by directly calling OS routines to save time, then (a) it's likely to cause problems, and (b) not sure you'll save all that much time. If you want REALLY fast screen writes then write your own code to do direct screen memory writes, or better yet wrap the conio.h calls in your functions, those are already pretty fast. Looks like you are moving a library from a commodore version, but Atari, generally speaking, you don't want to skip handlers and directly call OS functions, they were mostly all designed to be called by handlers or by the OS itself.
  7. Yeah, don't mess with the crt0.s file unless you really know what you're doing. Not implying you don't, just saying it's dangerous.
  8. Much more likely that he's crashed Altirra the old fashioned way. But yeah, grab the latest altirra. HP, that's the standard crt0.s from CC65. Did you change it? What's in your simple_io.c file?
  9. They are? Has CC65 changed drastically lately? Not sure what I'm missing here, but I had to write my own relocation routines to load externally created .o files at runtime, even when created using CA65. You seem to be saying it will all be compiled/linked together, which of course will 'relocate' it. I was talking about a dynamic linking system, such as .dll or .so. At any rate, I'm out, because I don't understand what either of you guys are actually talking about. Love FB though.
  10. So you meant FB source code in separate files like include files?
  11. Ah that's cool. But I think he meant like separately developed object libraries. With the way you describe above, you would just have to share appropriately coded source instead of a precompiled object file.
  12. yeah, I think a way to bring object code libraries in and call named entry points would be handy....one thing, though, wouldn't relocation have to be handled? Either relocation or some sized area would have to be set aside I would think. Relocation is not all that hard, FB could specify a load format (obj prefaced with a relocation table, for instance). Actually I suppose a symbol table would be handy too, just like a real .dll or .so. So It'd be something like: [relocation table] [symbol table] [object code]
  13. Yes, I agree. I actually wound up interrogating the environment after load and using the space between my load point and the top of whatever dos as extra memory for some things, and also small relocatable bits of code. Bear in mind you can also use the RAM under the OS and extended memory too (hardware dependent though). Another popular target is a bankswitched cartridge, especially one that can be flashed such as the carts from Atarimax. https://www.8bitclassics.com/product/atarimax-maxflash-8mb-cartridge/ Don't know if that matches your use case though. Sparta does natively support relocation, although as you know it's not terribly difficult to write your own using a table of addresses to be patched and your own loader.
  14. It was 'chosen' to support all of them. I don't know if there's a particular known DOS that drove the decision. It usually wastes a lot of memory, which is why people were annoyed with it as Sanny mentioned. It just is what it is, you have to adapt to the DOS situation. Either pick a DOS, or go high enough such that most DOSes are fine. Of course, any machine language program created by any means has the same issues, and some of those don't have defaults at all - you supply them in the source code or in the toolchain just as CC65 does. Yes, that seems to be a reasonable position. The point is, though, that at any time anyone could write a new dos that violates any default you set. The $2000 was seen as a reasonable compromise between memory usage and common dos's, and it is intended to be a starting point, not really a safe default.
  15. Well, Jon spent a lot of time on it, great amounts of effort. Then there were some hardware developments that happened, and Jon's work there has enabled the great wave of advancements we've had. Hardware is the easy part, actually, and the software can be very much harder. Without it, though, the hardware is useless. Why he hasn't gone back to it by this time though, I'm not sure. I actually think Patreon/Kickstarter is a great idea, assuming that financials would help.
  16. Just stopping by to say: "Remember kids, don't feed the troll(s)" You guys bit HARD on this one. Emkay - you need to patch your troll-o-meter, it is vulnerable to 'Pokey attack"
  17. I think he is mostly just expressing generalized irritation at the rise of control complexity over the last 30 years, an opinion which I mostly share although not in relation to CC65, plus he's apparently not a fan of linux/unix. I'm guessing he was 'raised' on some narrower architectures that had a smaller complexity footprint than mine had. For instance, I had never heard of the language he's doing until now. Kaj, if you think CC65 is complicated, wait until you see things like git and docker/kubectl and java/maven, and the insanely complex world of modern web development, in which it's not only (imo) too complex but also shattered into a thousand competing fragments of teensy little intersecting FOSS utilities. (See, I can rant too!). CC65's extra complication is because of it's target, which is namely all 6502 machines. That's a broad brush, and it needs the flexibility in order to cover the targets. The price of flexibility is always complexity. CC65 is what it needs to be, and is medium-well documented. You've got to learn the tool, or pick another one up. You have nostalgia for simple, self contained things like Action!, which are Atari native. So do I. CC65 is an external, unix-style ( although not GNU-based) toolchain to produce cross-compiled stuff, so you are really not back in the 8 bit world when using it. I had some irritation and some extra time spent using it at first, but then I realized that once you cobble together the bits and pieces and flags you need, then you're set and have a lot of power at your fingertips. Asking without deriding the toolset is probably a better approach to gathering the information. Modern C systems are not any more complicated than they used to be, actually. The systems they target and run on certainly are, though.
  18. True! I agree entirely. However, his seems...well, finished, let's say.
  19. Interesting. Do they actually have laws against 'being an asshole'? I wonder how that gets defined, exactly, and also if that applies to posting rights on boards...hmm. Or even the media in general, there COULD be some assholery there too.
×
×
  • Create New...