Jump to content

danwinslow

Members
  • Content Count

    2,892
  • Joined

  • Last visited

Posts posted by danwinslow


  1. 1 hour ago, Harry Potter said:

    I thank you for your input.  My SimpleIO libraries are meant to save code by calling the OS directly with minimal extra work.  It's not necessary for most purposes.  I will stop working on it.

    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.


  2. 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. 

    • Like 1

  3. 3 hours ago, dmsc said:

    Hi!

    Not necessarily, you can share CC65 libraries (.lib) or object code (.o). Currently the FastBasic cross compiler distributes all it's libraries as one ".lib" with all the compiled code. The CC65 object code and libraries are fully relocatable.

     

    Have Fun!

    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.


  4. 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]

     


  5. 27 minutes ago, Kaj de Vos said:

    I know, memory management is problematic on all 8-bits. That's why I wrote the relocator for my handlers thirty years ago. I know a convention arose early that most application programs will start at $2000, so a DOS or handler that goes beyond that does so at its own peril. But at that time there were already a few DOSes that went slightly over it, which was no problem for BASIC, the most used "application program". So I always thought the convention is a bit off, and $2100 is better. SpartaDOS 1.1 is still my favourite DOS for testing, because it boots straight to the command line, fast. Most newer DOSes try to go as far under $2000 as possible.

     

    Even better would be to write relocatable programs. That would also solve the memory differences between DOSes. But as far as I have seen, still only SpartaDOS X supports that.

    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.


  6. 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.

     

    I think a default should be safe, and people who want it unsafe should change it themselves

     

    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.


  7. 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.

    • Thanks 1

  8. 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. 

    • Thanks 1

  9. 22 hours ago, YSG2020 said:

    You are entirely incorrect. Learn the law and your rights. Clueless. It’s 2021. You can’t just go around being an asshole to people without consequences. Legal and/or otherwise. 

    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.

    • Thanks 1
    • Haha 6

  10. 1 hour ago, kenames99 said:

    with current technology you could fit 2 or more types of device on a single card. the possibilities are almost endless.

    Indeed (italics mine). Although I didn't do a good job of it, that was essentially what I was trying to convey earlier. I too would still like 8 slots though :)

    • Like 1

  11. 1 hour ago, CuloMajia said:

    No way can you do DLIs and VBIs with higher languages. If you just want to change GTIA or ANTIC registers, some will compile into LDA + LDX, just to store to an 8-bit memory location. Most of the Basic's compile and store the line number where something is coming from for debugging purposes.

    Of course you can. I did a mouse driver running off of a timer interrupt. I've done DLIs. I've done vblank routines. I even wrote a threading system that ran off of vbi. All in straight C. Coded properly, CC65 is more of an advanced macro assembler than a 'high level language'. MADS Pascal does a great job, too.

×
×
  • Create New...