Jump to content

danwinslow

Members
  • Posts

    3,023
  • Joined

  • Last visited

Posts posted by danwinslow

  1. If execution speed and size efficiency is an issue for you, be aware that you have to write the C code in a very specific way to get the best performance. Using 'regular' c coding style and function calls is absolutely going to work, but will be bloated and slow compared to how it performs when written 'correctly'. If this is the case, you can search for several very good threads here on optimizing CC65 C coding.

  2. Absolutely correct, but he explicitly said he's developing for multiple platforms. That makes me think he is talking about the driver, which I don't know much about. @sanny probably does though.

     

    Atarilux - I am not sure if you can count on the joy driver being (a) sufficient, and (b) working for all platforms. Maybe you can...but if not and you are really intent on distributing for many systems, then implementing your own driver API with platform specific code underneath (such as shown above) would be a good idea.

  3. 9 hours ago, mysterymath said:

    once implemented, this should take exactly the same amount of space that the worst-case dynamic stack would. For example, trivially, all leaf functions (ignoring interrupts) could share the same static stack frame, since none could be active simultaneously.

    This might be an oversimplification, or (somewhat more likely) I don't understand what you mean, but...recursion and also threading come to mind. Recursion you could reasonably expect to see. Threading sounds unlikely but, for instance, I have written a pre-emptively threaded program on the Atari with 4 'threads' running off of an interrupt. In both cases, having exactly the same local stack area might be problematic.

  4. Not familiar with the MCU project, but I would prefer just an ethernet chip and some supporting buffers and control lines, I don't think we need a processor. Otherwise we are just hooking up an SBC like a raspberry PI or whatever to PBI. It's not really an 'Atari' networking solution at that point. Just my 2 cents.

  5. What we need is hardware. Drivers will appear. A PBI solution would be optimal, a good network chip, some buffers, maybe Wifi on the card. Fuji is awesome but SIO is kind of a bottleneck for some applications. Since Fuji has a good CIO layer it's a perfect model, rebuild the guts to use the new device and Fuji apps should still work.

  6. Nice. Something seem slightly wonky with your paypal code...it did not auto populate address from paypal's response, but otherwise as mentioned it's really cool that you did this. Y'know, maybe we should have a selling site set up for AtariAge members that we could use easily for thiings like this, both sellers and buyers. Someone would have to admin it, but that's wouldn't be too much of a burden nowadays if it were kept simple.

     

    Anyway, great work.

  7. Would it do anything? I would guess that the overall data amounts are so small, and the general overhead on the atari side dwarfs any modern device IO time overhead. Not sure it would a noticeable difference. Are you using an actual HD?

  8. If that's what I think it is, a more common notation (in my opinion)  would be 'static' type decoration on the variables or the procedure itself. Is 'keep' a known thing in pascal or did you invent it?

    It would be more familiar to most if it were written something like:

     

    procedure beep; 
    var a,b : byte; static;

    begin

     

    or-

     

    procedure beep; static;
      var a,b : byte;
    begin

     

    The first form also allows for variable specification as ''keep/static' on a per-variable basis.

     

    *edit*

    I see there is already a static in free pascal,  so maybe I don't see what keep is doing.

     

  9. I like the idea, I'm impressed by the programming, but the postage stamp size is ridiculous. I understand that it's probably necessary, but that just means it shouldn't be done.

    • Like 1
  10. On 3/13/2022 at 7:20 AM, 8bit-Dude said:

    Of course, but then the game would only work on the XE!

    I think you should go ahead and use 128k. There's plenty of options to upgrade, and nearly everyone has +RAM or, if not, there's always altirra.

    I know you are probably thinking along the lines of a re-usable sprite library for 8Bit Unity, but you could have a 128k version (fast) and a 64k version(slow). Use this game to develop the fast one, and then see if there is really a need for a 64k version.

    • Like 4
×
×
  • Create New...