danwinslow

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.

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.

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?

Wow, that's great stuff!

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.

So you meant FB source code in separate files like include files?

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.

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]

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.

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.

hah, ok. Never heard it called that.

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.

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"

Say what now? Do you mean 'parity'?

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.

True! I agree entirely. However, his seems...well, finished, let's say.

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.

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

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.

He's looking off in the distance, trying to absorb the fact that he just made SO much money using his new Atari on the Stock Market! The dog just wants a smoke, he's staring at the ashtray.

I would think we've cumulated as much as is possible on POKEY by now.

Is Steve Carden still active? Haven't seen him in quite a while.

Now now, don't get your feathers ruffled and start calling us 'not programmers'. I've been programming my whole life. Programmers are almost always fanatics of one sort or another. I was just saying that it's very common for people to not like a bunch of off-the-forum topic posting, especially since there *is* a forum here for the subject. You can do what you want.

I'm fascinated with how much focus you guys put on the sound tracks for things. I mostly find them annoying, especially if they play constantly throughout the game. That's just me, though.

Well, there IS a commodore forum here, you could start a thread over there. That said, I don't care all that much but I keep looking at this thread thinking I'll see something cool for atari with MP but, nope, it's still you and Funkheld talking about commodore stuff.