Jump to content

danwinslow

Members
  • Posts

    3,032
  • Joined

  • Last visited

Everything posted by danwinslow

  1. 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.
  2. 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/
  3. 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.
  4. 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
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. Yep, doesn't hurt, could provide anybody some info, so why not. It gets old though in OP's case.
  14. 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).
  15. Why would he do that when we always wind up doing it for him? Besides, he really just wants a little attention I think.
  16. 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.
  17. 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.
  18. 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.
  19. 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.
  20. 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
  21. 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.
  22. 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.
  23. 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.
×
×
  • Create New...