[[AMR] Altirra Middle Runner]

Seems like a handy idea to me. Thanks!

[Is there a BASIC <> Python reference guide (like a PDF)]

Well, I don't know about 'more natural'...depends on what you are used to. To me, some of the syntax in python is extremely unnatural.

But all modern languages suffer from what I call 'complexity poisoning' - they've had so many things added over the years to be 'more powerful' that now they are just unwieldy. Plus, devs seem to feel that if a language has a feature, then by god they are going to use it, needed or not.

 

Development used to be viewed as an engineering discipline...write simply, write clearly, do only what is needed. If you add complexity, have a good reason that you can explain to a user of your product.

 

[Is there a BASIC <> Python reference guide (like a PDF)]

Python is ok, but it depends on what you want to do. It's really good at manipulating large arrays of data, and it's a great 'glue' language to script infrastructure bits together. It has a really large ecosystem of libraries, and is used for a lot of scientific and AI/ML work. That said, I don't like it much from a formal language perspective, it is at heart a script language and suffers from the usual oddities. A good next language for you might be pascal or C, both are available on the Atari. If you want employment as a developer then C++, Java, or javascript would be a way forward. If you use Windows then C#/.Net is a nice environment.

[Is there a BASIC <> Python reference guide (like a PDF)]

I don't think you'll find one as such. The two languages are very different. It might be better to take it on a functionality basis and google for things like:

• How to open and read a file in python: https://www.freecodecamp.org/news/how-to-read-files-in-python/
• How to create an array in python: https://www.geeksforgeeks.org/python-arrays/

etc. There really isn't a one to one mapping as far as individual keywords go. A good place to start would maybe be https://www.python.org/about/gettingstarted/

 

 

 

[How to make a commandline processor in Action! ?]

5 hours ago, TXG/MNX said:

Hi,

 

I am playing around with Action! I would like to have a little commandprocessor are there any examples how to do this?

 

it works, I opened my own E: handler channel and wrote my own commandline util.

Depends on what you mean. If you mean like windows CMD or any of the existing command processors for atari DOS, then yes there's some examples. If you mean something else, let us know.
Usually a command processor does these things: 
1. Allows you to type the name of a program and run it, also handling any command line parameters.
2. Allows you to do things with files - delete, copy, etc.
3. Allows you store named sequences of commands, which can be run as a batch

4. Allows you to change operational environment - presence/absence of certain drivers, memory setups, etc.

 

A far as examples, I'd look to the source code of other Atari command line interpreters - Sparta, RealDos, etc.
 

[VBXE particle system]

Yes, that would be expected if this was anything other than an experimental demo. He might have left it as an exercise for the student  

[A little OT..What decides the dev number on githubs or the like.]

Yes. The other numbers probably are:

vxx.yy.zz-nnnn-

xx=major version

yy=minor version

zz=build version (sometimes...could also be some other kind of internal like a sprint number or whatever)

nnnn- this is probably something related to the build system like a sequentially rising build count or something similar. In my experience not all builds work so it wouldn't necessarily be always sequential.

 

[VBXE particle system]

It is!

[how random is RND in Basic and Turbo Basic? (seems to be different)]

I have no certain knowledge about randomization testing, but I would not have considered your results unusual for an 8bit 1980s randomizer. Is it just the once, or did you repeat this process many times? My first impulse would be to run the whole thing at least 10 more times to see if its consistent (with different start seeds).

You can find a WHOLE LOT online about randomness testing and RNGs if you poke around....almost too much, its a very heavily studied area.

[VBXE Tutorial - The XDL]

If the 'what is a blitter' question is still in play - (if not, forgive me)

 

A blitter is, as was said, a very fast memory transfer unit optimized for video memory targets and sometimes specifically for rectangular arrays of bits. It is intended to move arrays of bits in a 'block transfer' to a destination memory, and it usually has facilities for controlling how the bits get laid into the destination memory - via or, xor, or replacement.It can be used as the core of a 'sprite engine'. but it is not correct to say 'it is the sprite engine'. There still needs to be software wrapped around it that knows what a sprite is, what the color bits in a memory word mean, contains the actual sprite movement and detection logic, etc.

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