danwinslow

Interesting. Are you looking at a shadow reg? They may have just been generally following the 'do all the OS reg/shadow updates during the VBI' philosophy. Copy the OS to ram and patch it to set the reg when you expected it to, see what happens.

Since we're mixing subjects, then: 1. I have a deep personal hatred of Eclipse from the dim past, it's probably time to revisit with modern versions. I used to get the dreaded green bar for doing ANYTHING and it always seemed to take forever. Plus, there was no Brief key emulation, and no Vi key emulation. 2. I like how lightweight VS Code is, but I can see that the 'Lets add stuff!' weevils are busy at work weighing it down as fast as they possibly can. And, there is a good Brief emulation, so. 3. I actually like Slickedit over anything, but its a licensed product, and not cheap either. There you have my much needed opinions. You're welcome.

If you go to Extensions and search for 'Atari' you do get some stuff, but I'm not sure if any of it has a build system. Otherwise, you may have to wade through the process of configuring a build system in VS code. That's what someone did for MADS in Eclipse.

Beds of roses are hard to find, and usually have thorns somewhere If you are going to do anything serious in any language on the Atari, knowledge of of how the Atari hardware works and how it is programmed is always going to be essential. The linker is complex, but that complexity allows the freedom to do things relatively easily that would be difficult otherwise. The assembler developers would use the built in CA65 assembler rather than trying to write large amounts of in-line assembler. There are libraries that support mouse, joystick, and some graphics stuff. Example code is also easy to find. I would agree that CC65 would not be my first choice for a small project, unless I had already learned it, but power brings complexity. Also agree that the 'C' part of it is in kind of a middle ground when writing for efficiency. You can get very efficient code generation, but you have to write in what amounts to kind of a very advanced macro assembler anyway so then you can feel like you should just use assembler anyway. I always preferred the setup from crt0.s and then drop into CA65 for things that really needed efficiency. But, I have written some really time-critical stuff in straight C (DLI, mouse driver, VBI, etc.) so it is capable of doing so. Mad Pascal is a great choice, too, from what I can see, but you do lose some of the linker control you have in CC65.

Hmm, are we supposed to all listed in the above spreadsheet posted by Big_M? And anyway, my order for 1 130xe and 1 800 would be to the US and NTSC video, forgot to specify that.

1 for 800 1 for 130xe Thanks.

Yep, doesn't hurt, could provide anybody some info, so why not. It gets old though in OP's case.

A .h file is a 'specification' file for the C language, also known as a 'header' file. You put definitions of things in there so that other modules can see/call them. So, for instance, a foobar.h file might have: void foo(int bar); in it. Then, if another C language file includes that .h file, it can see and call the foo() function. Note that there must be a matching foobar.c file with a matching function 'body': void foo(int bar) { //some code.... } The 'body' is signified by the open and close braces and the code between them. This is called separation of specification (.h) and implementation (.c).

Why would he do that when we always wind up doing it for him? Besides, he really just wants a little attention I think.

CC65 is as well. I personally think it's the best for Atari dev. You can get very near assembler speeds out of it, but you have to write the source code in a non-standard way. In-line assembler is supported well and the tool chain supports linking assembler modules written in the CA65 assembler that comes with it. Kick C is probably good too, I haven't used it though so I can't say.

It's interesting to see the first steps towards separating specification and body in this language. This was a major inflection point for programming languages in general. The syntax also reminds me of Ada a bit with the BEGIN/END and the CASE syntax.

This is very true. Most of the stdio stuff isn't really necessary, since there are lower level things available (conio, for one) or you could just do a specialized CIO call of your own. Keeping passed variables down to things that fit in a,x,y help too. Use globals a lot, etc. There are good threads here for optimizing cc65 for either time or space. Taken to the extreme, you do wind up using cc65 as sort of a very advanced macro assembler, and so then you begin to think, well, why not just use assembly? I think something that would aggressively prune the libraries at link time would be helpful, analyze the code paths and drop anything out that didn't get called.

Not sure what the point of procedures is in this situation. I doubt you're getting (or would want) stack recursion and 'local' variables, and from the description it sounds like it's just adding extra code and possibly execution time.

The default display list is usually set up by the OS graphics commands. You can find the location pointer in $0230. When setting up your own, you can put it pretty much anywhere that is protected from overwrites. As far as I know there is no 'usual location'. In practice it is often in high memory next to display memory. Same answer for video RAM, really, pointed to by $88. There are some restrictions about jumping certain boundaries in higher resolutions, which you take care of in the display list itself. https://www.atariarchives.org/mapping/memorymap.php

Well, just as general advice, in my experience the usual cause of mysterious crashes when accessing extended ram is to not have the bank you think you do actually switched in. Basic XE would have taken care of that for you, but I don't see any bank switching in the USR itself. You could be clearing code space rather than the extended bank. Crashing behavior could vary based on whether the supporting language/environment has anything it needs at $4000.

That's what I wound up doing. restore last 'under' if any, save what's under new location, place cursor. It ran in a pokey interrupt.

I'll second that. If you plan on writing a larger, graphics/action game you will need to learn Atari-style minimalism. Coding for speed and memory efficiency in CC65 really requires using as little of the standard C lib as possible. It's more like using a very good macro assembler than a standard C program. Search for many good how-to's by @ilmenit in particular.

A display list is a series of display line codes. It's like a very small program that Antic runs. You have a certain number of scan lines available, and you can for the most part use any combination of graphics modes you want as long as you don't go too far over or under the number of tv scan lines. As mentioned, you can set an interrupt bit and put a pointer to a small bit of 6502 program code that will get executed while the electron beam is tracking back to the left to draw the next scan line. This is known as a Display List Interrupt, or DLI. You can change a few things like colors, but you don't have much time. A lot of the screens that you see in small basic demos that draw all the colors possible in the atari on the screen at once are using the same graphics mode over and over. There are many other things you can do in the display list - coarse and fine scroll, change video data address, etc.

tbh, a big reason I use VS Code is that it supports a keymapping from an editor that I imprinted on long ago, has an Ada extension, and is free.

I made a similar game called 'Sprack-man'. The hero could emit a small but powerful cloud of greenish pixels.

I just use it to edit files, then use the integrated cmdline terminal to run my scripts. Not sure what else you're trying to set up with it. There are some extensions you can load, such as 'Atari Dev studio' and a few others. Use the extensions search feature and look for 'Atari'. And, we are talking about VSCode, right, not Visual Studio?

VS Code works, too.

This language is fine, if you are interested in that kind of thing. It's a language essentially about languages (thus the 'meta') and as far as I can tell is focused on extreme flexibility of syntax and what some people think are 'natural' language constructs. I kind of think it's interesting, but I would rather be eaten by weasels than have to write an Atari game in it. It is manifestly not 'clear'. You saying 'well, you have to go learn it before you can see how clear it is' is a self-negating statement. Kai, I don't know why you chose/included legacy 8-bit computing platforms for this experiment...I can't think of a more inappropriate platform to do something like this. No one here cares at all about running on large numbers of 'platforms', niceties of syntax, ease of expression, abstract clarity, or creating sub-idioms with flexibility. They care about program size, hardware control, and speed. Non-clarity is actually a plus, because it means something really tricky is going on. Most of us are assembly coders for heaven's sake. We spend hours staring into the the navel of a 6502 chanting opcodes just to save a few bytes. Let's all just stop arguing about it. Kai is doing his thing, if you don't like it just don't respond. Kai - good luck.

To be fair, that's a pretty simplistic test...needs to cover more ground to really be able to say "In general, this is x% faster than that". I agree with you though - if you want Basic, then its hard to do much better than Basic XE in my opinion.

Error 130 means 'no such device'. Do you have a disk drive of some sort? Many of us use an adapter to use our PCs as the disk drive, or use the Altirra emulator and it will take care of that for you. It would help us help you if you could explain what action you are taking that generates the error 130. It's not weird to need to open a file to save anything - what else would you expect? Every system I have ever worked on needs the same kind of thing. The Atari is a little different because it has what was for the time a sophisticated OS, that uses IO handlers that can be mapped onto different devices. It also has custom screen handling hardware and does have sprites called Player/Missile graphics. They just take a bit more of extra control than you might expect, but many languages have support for them. It also uses a 'display list', which is a small program for the screen generator hardware. Lots of flexibility, but adds some complexity. Read https://www.atariarchives.org/dere/ and other books at that same location.