[Timers 3,4 and 5]

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.

[Visual Studio Code]

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.

[Visual Studio Code]

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.

[Deep Blue C worth it?]

3 hours ago, baktra said:

I don't believe so. I would go cross-platform. Native C development environments for 8-bits are usually clumsy, because the computers were not powerful enough. At Atari, they were developing cross-platform in the 80s too, using assemblers executed on stronger computers. A 40-column screen doesn't help either.

 

When it comes to development using CC65, it is not a bed of roses, too.
I would always consider the following:

1. There is no rich library of functions for sound and graphics for Atari. Therefore, knowledge of how the Atari hardware works and how it is programmed is still essential.
   C65 is not at fault here, it is the way it is. One has to know assembler and how to interact with C.
2. One must know how the LD65 linker works. This is especially important when including data (like fonts, bitmaps, display lists) in the project.
3. Unsurprisingly, the generated code is not as good as handwritten assembler.

This makes the CC65 somehow sandwiched: 

• The assembler developers would complain about inefficient code and boilerplate syntax, fighting with the compiler. A better choice can be to stick with ASM.
• The higher-level language programmers who would find the library insufficient and do not want to deal with the intricacies of the linker. A better choice can be the Mad Pascal with richer library.

 

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.

[Sophia 2 preorder thread]

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.

[Sophia 2 preorder thread]

1 for 800

1 for 130xe

 

Thanks.

[AdvSkelVic65 problem w/ scrolling on Atari8 cartridge]

3 minutes ago, TGB1718 said:

I know, I'm suckered in, but decided to do this just for fun.

 

@Harry Potter attached is some MADS source, have a look, it's only a demo, but the code that does the business is small

and could easily be improved on. Easy to include into a cc65 program as assembler routines.

 

Bear in mind though MADS is nice in that if you put ASCII strings in double quotes it produces the string in Atari Screen format

not ASCII.  

scratch.xex 274 B · 0 downloads scratch.asm 2.32 kB · 0 downloads

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

[AdvSkelVic65 problem w/ scrolling on Atari8 cartridge]

18 hours ago, Ecernosoft said:

Just a noob question: What is a .h file? Just asking. Not like I'm going to use CC65 though. And if I ever did I'd just use 8bitworkshop's built in CC65.

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).

[AdvSkelVic65 problem w/ scrolling on Atari8 cartridge]

23 hours ago, Wrathchild said:

We repeatedly point you at tomes such as De Re Atari and Mapping the Atari, and there will be many articles in the likes or Page 6, Antic, Analog magazines...

Please take the time and effort to do homework before asking people to do it for you.

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

[Deep Blue C worth it?]

17 hours ago, Mark2008 said:

They want a full featured C, that produces performant code, that allows them to treat C as an assembler replacement, because it just that performant.

Such a thing doesn't exist, in my view.  However, before I move on the discussion, let me say that KickC is a modern cross compiler that supports Atari 8-bit and is worth checking out.

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.

[PL65 Review, World's hardest game, progress thread]

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.

[Deep Blue C worth it?]

1 hour ago, TGB1718 said:

It's always the libraries, just a simple empty main() compiles to just over 500 bytes,

just add printf("Hello World"); and it's 2.8K

add one more line scanf("%u",&i); and now it's nearly 5.9K

I know they are probably 2 of the worst, using <conio.h> functions produces slightly smaller code.

but the more library functions you use obviously the worse it gets. 

 

Once a library function is used, repeated use doesn't increase the overhead other than the call

and variables used in the call.

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.

[Procedure calls with parameters MADS]

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.

[New Dev Questions]

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

[Disappointed with BASIC XE]

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.

[moving screen editor cursor with joystick]

20 hours ago, OxC0FFEE said:

I'm getting the picture. It might just be easier to poke a fake "cursor" into the right place in the text window. Avoids the needing to tickle the screen editor and the last row/column issue.

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.

[requesting C code feedback/review for first tiny game in CC65]

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.

[how many graphics modes can you have in a display list?]

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.

[C Lion and CC65]

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.

[Making an atari 800 game: how to start exactly?]

On 7/28/2022 at 4:15 PM, rdefabri said:

I did make some "games" and/or "demos" back in the day.  One was a primitive soundboard called the "Fart Chart", where you could select different types of passed gas, and it would have an animation (with sound effects) of a guy passing gas.  It was stupid, but fun.  I did some preliminary work on a Smurf type game, I had a P/M character (like a smiley face) that would bounce on screen with some background, but nothing more.

 

We're talking over 30 years ago, I've long forgotten how to do much of it.  I think my ideas outstrip my abilities, so I need to think more simplistic.  I have an idea in mind, I think it's something I could (possibly) do.  I need to plan and learn, then I'll give it a go.

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

[C Lion and CC65]

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?

[C Lion and CC65]

VS Code works, too.

[Meta language]

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.

[Making an atari 800 game: how to start exactly?]

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.

[Making an atari 800 game: how to start exactly?]

22 hours ago, Frozone212 said:

the Atari is...weird to say the least. You need to open a file to save anything, no commands for sprites? I get that there are extensions and Altirra basic but what i'm looking for is this:

 

 

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.