mellis

Oh well - I would have ordered both a 1400XL and a 1450XLD badge just to have in the event I was able to acquire either machine sometime in the future.

Being a Spectre GCR user, I had already amassed a significant amount of Macintosh software and knowledge, so I purchased a Macintosh LC II. As a 68000 programmer, I was very excited to have both the 68030 and the more sophisticated Mac OS (which was called System 7 at the time).

Your flyback transformer is getting ready to go. That was a pretty common issue on the Samsung and Goldstar (pictured) versions of the SC1224. Do not attempt to repair that unless you know how to discharge the mega voltage in the CRT without killing yourself.

It sounds to me like you are trying to install kernel extensions without disabling System Integrity Protection. Have a look at this link.

You might find that the SDL version of Atari800 will fit the bill, command-line-wise.

This is C, so you are responsible for memory management. Your Windows 11 box is crashing because Windows has memory protection, and you are likely writing to unallocated RAM. In doing so, it is doing you a favor; you now know you have a buffer problem. If you are going to program in C, you will need to diagnose and fix this yourself. It is the only way for you to understand your mistake and avoid it in the future.

I do love some "Yes". That would've been the Union album during that timeframe.

To wear the "good programmer" crown, one must understand the linker and the role it plays in producing an executable binary. There are many different ways to configure the linker in order to ensure that only the library/runtime code you really need is included in the resulting binary.

The M1 Macs are capable of running X86 binaries using their built-in Rosetta 2 emulator. It all works swimmingly for everything I've thrown at it (and I am a professional developer). While I have not specifically tested the software you mention, I have not encountered anything which I ran on my Intel MacBook Pro that I can't run on my M1-based Mac with one exception: VMware Fusion. However, there is a solution for that also: Parallels. The latest Parallels will allow you to run ARM Windows, and that has its own X86 emulator for when you need to run X86 Windows binaries. In short, I would not worry about upgrading. It will be fine.

In light of the posts that preceded this one, I am not sure if you are joking. If you are, it's pretty funny. In case you aren't joking, here are the steps (since this question seems to be quite popular): 1. Obtain a memory map showing where the 8-bit's custom chips appear. 2. Obtain a memory map showing where the 5200's custom chips appear (same chips, different memory locations). 3. Determine if the 8-bit program uses the OS, and if it does, rewrite those portions so that the program does not use the OS at all. 4. Determine where the 8-bit program access the controller inputs, and change those routines to scan the 5200's controllers. 5. Replace all of the 8-bit custom chip memory locations with 5200 memory locations. 6. Ensure that the program is only using RAM from 0 - $3FFF. 7. Ensure that the program instructions appear in the $4000-$BFFF range. 8. Get familiar with the assembler, linker, and debugger, and prepare to spend quality time with them. And there you go! Only 8 steps, all of which require non-trivial programming and analysis skills.

Are you using AtariWriter or AtariWriter Plus 80? There is an important difference.

It sounds like you are looking for a general-purpose library (or routine) to handle the sprite multiplexing, but you are going to find that the only general-purpose implementations will lead to the flickering you have now. A flicker-free multiplexor will need to be designed around your specific game, with clever in-game constraints allowing you to reuse the same players/missiles on different scan lines.

Sure seems like you are observing an interrupt firing, and as a result, you are being carried into the OS.

I was paying attention when it happened (the 7800's release in the late 80s), and Pole Position II absolutely blew me away. Especially the track with the detailed and animated circus in the background. Loved that game.

In short, "yes" and "yes". The Atari's graphics capabilities are impressive, but employing them to their greatest effect is at odds with using a general-purpose library.

Try using the environment variable: LIBRARY_SEARCH_PATHS=/usr/lib or possibly: DYLD_LIBRARY_PATH=/usr/lib after first confirming that /usr/lib/libc.dylib exists.

Looks to me like the linker is looking for "libc", as indicated by the switch "-lc". It is customary for *nix linkers to automatically drop the "lib" prefix when looking for libraries, so the "-l" switch is followed by "c", and prepending the "lib" prefix back gives you "libc". Modern macOS versions do not ship with the command line compiler tools, but you can download and install them if you want. Check out this URL: https://osxdaily.com/2014/02/12/install-command-line-tools-mac-os-x/

Over the decades that I have been involved with Atari 8-bits, I've watched some folks look to higher level languages (like C or Pascal) for something faster than BASIC but easier to learn than 6502 assembly language. What ends up happening is that, outside of simple console I/O programs (which could be written on any computer) those languages do little to make programming our 8-bit Ataris any easier. With such limited resources, programming a 64K computer requires a thorough understanding of its memory map and what that means in terms of the computer's underlying hardware. If you find these details too cumbersome, BASIC is truly the best, most approachable way to program these machines. When you get more comfortable with that, you can branch out into programming small, assembly language subroutines that can be used to speed up your BASIC program. What I am reading in your threads is that you do not understand how the computer's memory map works, and therefore you struggle to properly configure the C linker. Unless you really understand the layout of your program in memory, you will continually struggle to make C do what you want on these machines. I assume you are attempting to program the 8-bit Atari because you want to take advantage of its graphics and sounds capabilities, but doing so will be very difficult in this language I believe you have chosen specifically because you think it will be easier (spoiler: it is not easier). If Atari 8-bit sounds an graphics are what you seek, I recommend getting started in BASIC and then moving to assembly language.

Indeed, that would be fantastic -- why don't you get to work on it? The source code is available here: https://github.com/lybrown/dis

In C, the prototype for main() is: int main(int argc, char** argv); Where argc is the number of command line arguments, and argv is a pointer to an array of char*, where each pointer points to a command line argument.

+1 I agree that bypassing the CIO handlers is bad idea: it will likely break on machines running upgrades that include alternate OSes.

Yes - and I prefer my Ataris.

If you are really through with it, I will take that 1200XL off of your hands. Please don’t trash it.

I had an ST do that. It was stored vertically in a box but outside of its original packaging in a hot attic. I was able to correct the warping using modeling clay and an oven. I used clay to make a mold that supported the back side of the case, and then used more of the heavy clay and a carefully applied clamp to apply pressure to to top side to counteract the bowing. I then placed it in an oven set as low as it would go (around 200ish Fahrenheit). You need the plastic to heat up enough to soften a bit, but not enough that it melts or deforms. You will also need to put this on a hard surface to take it in and out of the oven. Less is more. I’ve never done an XEGS, so this might or might not work for you. Be careful if you try it. I had nothing to lose, so I went for it.

You might be thinking of Atari’s ST line, which was typically available with between 512KB and 4MB of RAM. There were some exotic sizes (like the 260ST or the high memory TT and Falcon configurations), but for most, 4MB was the upper bound.