danwinslow

Oh brackets vs. parens, yeah. Brackets are apparently initializer lists. So what does a non bracketed number do? Does INT COUNT=0 do anything different? For that matter, what would INT COUNT=[0,1,2,3] do ? Its not an array declaration.

As far as I can see, it shouldn't be. It should be set to just 0. The code uses it as a variable, but count[0] sets up an array. Not sure about Action! but in some languages you would be incrementing the array pointer by doing things like count=count+1. that would be bad. Remove the brackets is my advice.

Got a trojan warning off of the first link.

Ah, that's too bad. I wonder what kind of revenue stream modern Atari Inc. is trying to protect...can't be much.

Kind of surprised the title doesn't have the word 'atari' in it.

Yep, that's why I said "you have to do it on purpose". I was comparing C code written in this manner, not the full C language.

I think that is fairly correct. You can write C in a manner that is very bare metal too, but you have to do it on purpose. I think Action! and C code such as mentioned are very similar in 'height' above bare metal...so then it gets down to which has better code generation and optimization...and I'm sure that's been explored in one of the language benchmarking threads here. Malloc functions are very interesting and fundamental routines, you would learn a lot if you worked your way through writing your own.

Yes, I'm familiar with Knuth. It's a great book.

I meant in more of a philosophical nature. Consider: any such run of numbers and the tests you mention are for, by necessity, a limited run. Proving a normal distribution over a subset of iterations is not the same as saying something is actually inherently random, it's just one way of detecting if your particular algorithm favors certain outcomes over others. The nature of your algorithm is digital - you may input some analog entropy along the way but there's no escaping the fact that your are running a deterministic routine, and you need to run it forever to prove anything. Even sampling only a natural random event such as the decay of a particle is necessarily limited in span, and a run of all 5's, say, for any given amount of time is perfectly possible. To prove randomness is proving a negative- you have to say that no causes can ever be provided for a certain outcome. This is why these algorithms are always called pseudo random generators. The actual existence of true inherent randomness is by definition impossible to prove algorithmically.

Not to mention that everything was on cards...hollerith-encoded punch cards in huge trays. JCL cards and embedded program code cards, etc. You'd get your printed output the next morning.

Not sure you can do anything about it via normal programming using the stock RNG algorithm. What you need is a source of more entropy and probably implement a custom RNG that takes full advantage of it. You can think of entropy as sources of randomness from the environment, things you can sample as a number and preferably that are themselves considered random.

My high school had a mainframe connection, a teletype. I watched someone play original adventure on it. Then I got a sinclair zx80 with 1K of RAM (!). I wrote a 'lunar lander' game on it with characters for graphics (the lander was an 'M' and the thrust was the vertical pipe symbol). Joined the Air Force at 18 and they made me a programmer and I've been doing it ever since.

The odd thing about randomness is that it impossible to prove, or even define completely. If you could, then by definition it wouldn't be random.

Python is handy, interpreted so no linking mysteries (although there can be DLL hell involved), and it's available on smaller platforms and architectures. That's part of the reason it's around so much. Nobody is writing really serious back-end applications or high performance games in it, though. It's fine for what you need. There's really nothing one way or the other that's special about it, it's just a tool, does some things better than others. The syntax is kinda funky but not overly weird. You can learn some object oriented programming with it too, although that's not it's strong point. Just start!

Yeah, the indentation thing is one of the nits I have with the language. But, I mean, python is perfectly fine for writing most non-web applications as long as you don't want super performance. playxlo.com looks like a typical javascript web site, as was mentioned. Modern dev, especially web stuff, is way more complicated than good old basic on an 8 bit. Anywhere you go you will have to get past a lot of complications, one of the biggest being the user interface. Since you like the playxlo example, try some web development with javascript, css, and HTML. All that is really doing is drawing some pictures to the web page and handling click events by playing an mp3. Get a book or take a course and have fun. If you want a desktop app, then python is fine, you'll just have to deal with picking a suitable UI library. QT, as mentioned, is a good start but there are others.

Seems like a handy idea to me. Thanks!

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.

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.

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/

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.

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

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.

It is!

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.

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.