danwinslow

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.

I remember that back in the day when I worked on a Burroughs 3500, there were some files that when line printed made ascii art porn

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.

If I remember my C you probably need to put an incomplete type first so that it knows the name of the struct, something like typedef struct node node; struct node { char *name; node *parent; };

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.

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.

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.

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.

Beautiful.

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?

Hey, this is custom curated small-batch electronics. Don't worry about the charge. People who do this kind of thing for the community should actually make some money, a little at least. You're doing us a favor. As a matter of fact, I'm planning on paying even more for an assembled board, if you're willing.

I have already said I am interested...let me be specific - in a complete, populated board. No prices have been mentioned, but I'll be happy to compensate your time and effort.

Interested!

Ah, so I did not understand what it was for. Thanks.

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.

Why start with Rev C.? I don't get the advantage. If you are going to wind up on a much more capable basic, why not start there?

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.

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.

Not suggesting to do a clone of DM, but suggesting the traditional RPG dungeon crawler as a topic. Maybe something like Telengard but in 3d.

(IMO) Raycasting engine should raycast. Using extra memory for fast textures - OK. Trying to pre-cache every possible view - lame.

Sure, but if you're thinking about doing something like calling back into basic from assembler, that's probably a sign that you should just be using assembler. I wasn't knocking basic at all.

The thing to do here is to pitch basic and write the whole thing in assembler . It's actually not that much harder, it's just more tedious.

Hmm, that IPFS is really interesting.

As far as I know, you don't put quotes around the procedure name when you define or call it. I don't remember my Basic XE very well, but that's what stands out to me.