danwinslow

It's mostly SIO serial time. It's only noticeable in action games, where you really need like direct UDP to memory transfers.

Very nice looking. It would be interesting to develop a 'board game server' via fujinet that could connect instances of people playing this or other board games. Server itself would just connect the various instances together and who is playing with who and pass the game packets along as necessary. Likely would be suited for a small linux instance on some device. Peer to Peer(s) game play with one instance selected as 'primary'. The games would have to be written to support it, of course (or maybe extensively modified if they are already multi-player). This would be a great game to start with.

I did something similar a while back. I set up a lowcode segment at 0x2000-0x3999, a bank segment at 0x4000-0x7999, and set up the regular loading segment and compilation at 0x8000. I used the segment facility #pragma's to direct where things got created in in code. Seemed to work ok, but that was an older version of CC65. My equivalent of your array was loaded above 0x8000.

Ah gotcha. Might work then.

The angle brackets mark templating, where a declaration takes a typename as an argument. The L marker on a literal means that it is a 'wide ascii' literal (2 bytes per char). The code is probably fine for most c++ compilers but will never probably not ever compile on anything that has a target of the Atari.

When I was a very young teen, my Grandfather took me to meet his group of radiohead friends, who all had decrepit old crystal radios and sat around messing with them, modding them, and arguing. They smoked (inside!) and talked to each other in Morse Code. I rolled my eyes and thought "Oh man, look at these old fogeys. I will never be like that!" Now that I am a grandfather myself, the irony is strong.

Things fall apart; the center cannot hold; Mere anarchy is loosed upon the world, The blood-dimmed tide is loosed, and everywhere The ceremony of innocence is drowned; The best lack all conviction, while the worst Are full of passionate intensity. From "The Second Coming" by W. B. Yeats

I'd just like to say how glad I am to see some Ada usage. Beautiful language, sadly underused.

Sometimes I wonder what he would say to an inventory buy offer.

He generally refuses to do his own research. As long as someone gets sucked into 'helping' him (which it seems someone always is), he is content. I think he more or less just wants attention.

I can't believe he's not.

WOW that is an awesome rant.

Just guessing, but the circularity of both of them needing the other might be a problem. Have you tried putting them in the same file?

Well, to be fair, CC65 has never represented itself as 'the best thing to use on Atari for anything'. It is what it is - a good ANSI compatible C compiler that you can use on a host of 65xx systems. You have to expect some amount of generalization. It's a good toolset, you need to know how to use it on the Atari and when you do, it can be very good. I've used it for many things and never once had to suffer through the horrors of clrscr(). Ironically the OP's goal is to write for commodore and Atari.

Neat. I highly doubt it's actually new, as in previously unknown and never done before, but it's still good thinking. Another thing to look at is how the results vary with scale - do the curves go up linearly as you increase the list size.

Nobody is using your stuff. That is your actual problem. You are providing something that no-one needs. All of your utilities help with things that aren't actually problems. Everything you handle is either already done in numerous ways, or trivial. In particular, no-one needs "cubbyhole" optimization software. AdvSkel is actually not a bad idea, but its executed and documented so badly that no one wants to use it. Stop obsessing about sizes, and take the time to build AdvSkel out into a real toolkit for people writing text adventures. Document it well. Then, even in this late day of 8bit, somebody somewhere might use it.

Well, do as you like, of course, but if it's usability you want to optimize, then improve your documentation, feature set, and code stability. Having an extremely compact utility that no one uses is literally useless. You also might consider that you are providing features that are either already fixed by other things, are not actually a problem, or are trivial.

I'm just reporting. I Had nothing to do with CC65's source code. I'm sure they had their reasons.

Here is the source code for the current version of clrscr: https://github.com/cc65/cc65/blob/master/libsrc/atari/clrscr.s and it calls setcursor at the end: https://github.com/cc65/cc65/blob/master/libsrc/atari/setcursor.s

yeah, I assumed as much, since he hasn't commented. I'm glad you've known about this, please pardon us for discussing it in your thread. Neither one of us was advocating for a change in MadPascal, I was just voicing an opinion.

It shouldn't make them constants, constants go in a 'constant' block. Whether local var initialization should do anything and whether it should occur every time the function is entered is less clear, can't really get a direct answer after googling a bit. This thread is probably relevant - https://en.delphipraxis.net/topic/923-initialize-local-variables-at-declaration/ But anyway, as an outsider opinion I think it definitely should behave the way I was thinking - either make it happen each function call or don't allow it. There are various different implementations out there though, so maybe MadPascal allows compilation of such sources with the proviso that you might have to go back in and add your own direct initialization.

Ah. Ok, thanks. The guy asking about it seemed to have some expectation of it working that way, so I kind of thought it was supposed to. Maybe it's kind of a language hole, and only works in variants that MadPascal is not implementing.

Scope, yes, but whats the point of allowing the declarative initialization if it's only going to be done once? The fact that the last value is retained makes it act more like global scope, even if the name scope is there. Not a pascal expert but seems kind of wrong.

TGB, yes, you "fixed" it, but thats not the point. The locals in the xyz() function should be re-initialized to 0 each time the function is entered. According to his output, they are not, and retain the 10 from the previous call. I think this is a bug. Unless pascal explicitly doesn't do that, in which case I wonder why they have local vars at all.

Makes sense. Altirra debugger is extremely powerful, but that does come at a cost of complication.