mellis

When you say "4K 520 STE", do you mean "4MB 520STE"?

As I recall, EDO RAM will NOT work, so avoid that. Going from memory, I believe the ST uses non-parity RAM, but it will work with non-EDO parity RAM (where it ignores the parity bit). If you buy RAM labeled as Mac RAM (for the 68000-based Macs of the day), it should also work in the ST. I have 4MB of RAM in my Mac Plus that will also work in an ST.

Hi Peteym!

If it’s a fact that you only speak that particular language, I think a person would have to be looking for an excuse to be bothered by what you wrote. There’s no need to apologize that I can see. Setting that aside, most of the fun you can have as an Atari programmer is the learning process. I would recommend that you read De Re Atari to familiarize yourself with the hardware’s design and capabilities. You can even play with the hardware registers in BASIC to see what they can do first hand. When you are comfortable with the hardware, move on to Machine Language for Beginners from Compute. It will ease you into 6502 assembly language. These books are available online as PDF files. Just do a little Googling. You’re a programmer already, so this should be fun for you. Good luck.

I think you are struggling to realize Brad is aware of the fact that, for many things, he's the only game in town. Therefore, he has the luxury of doing business any way he wants. I would advise you to be as polite and accommodating as possible if really want your parts. Otherwise, Brad's blacklist is a real thing.

I think it's kind of funny you wrote the above instead of "Thanks to everyone for their insights! I might go ahead an give my idea a try."

The 5200 controllers shipped in the console’s controller storage area (under the hood in the rear of the unit). The Super Breakout pack-in game was included as only the cart and game manual (no game box).

I was in the market for a video scaler, and today I received and tested the unit mentioned above. Unfortunately, I cannot recommend it to those with a critical eye. This scaler generates visual artifacts galore. For example, areas that should be solid blue appear instead as a dithered checkerboard. That is but one of the glitches I identified, regardless of the settings I used with it. This is not to disparage the poster, I just want to save others the bother. Amazon has accepted my refund request.

Did you boot with BASIC disabled (hold down the OPTION key during power on)?

No offense intended - I assumed you were soliciting feedback when you posted those images. In fact, you are only a few clicks away from realizing an authentic label: https://chrismcmullen.com/2014/04/15/kerning-in-microsoft-word/

That's a great first effort, but the text needs to be properly kerned before it will look as though Atari made it. Specifically: the spacing between "A R I" needs to be tightened as does the spacing between "0 8 8 X L D"

When I wrote "A PC or Mac would be a much better choice for writing and debugging C code at the source level", I was referring to writing PC or Mac software, not Atari software. When you wrote, "As for CC65 and debugging with asm. This is trying I am trying to avoid", you confirmed my hypothesis that you are writing C code to try to avoid the complexities of learning assembly. The problem is, you really need to understand assembly language to write good software for the Atari. If an understanding of assembly is really a non-starter for you, I suggest you focus your software development efforts on more capable machines such as a PC or Mac. You can reasonably expect to program those in C without an understanding of assembly. If you really love the idea of writing software for the Atari, but you are steadfast in your decision to not learn any 6502 assembly, I suggest you try any of the excellent BASIC languages. TurboBasic, Basic XE, and even Atari BASIC will deliver results to you much faster than flailing around in C.

In my experience, the best way to debug CC65 code is the same as debugging any other compiled code: via your program monitor of choice. Of course, this means that you will be disassembling memory and dumping it to the screen, but that's what targeting the 6502 looks like. If you seek a source-level debugger for CC65, you will be disappointed. These little 8-bit systems don't have the resources keep debug symbols and your C source code in memory, and as far as I know, CC65 does not offer remote debug capabilities. If you feel assembly language is too difficult to learn, and you are instead attempting to write software using CC65 in order to avoid it, you have chosen the wrong target platform. These little, resource-constrained computers bring a knowledge of assembly language as a prerequisite, as you will encounter it at some point: either while coding, while debugging, or both. I prefer "both", as what you are debugging (the disassembly from RAM) looks very similar to what you wrote in the first place (the assembly source code). A PC or Mac would be a much better choice for writing and debugging C code at the source level, and there are many free tools to do so.

Perhaps ironically, billions ended up choosing it 20 years later when its direct descendent, the iPhones iOS, took the market by storm. As a NeXT user and developer, I was tickled when Mac OS X (and later iOS) came along.

Lets not forget this beauty for only $6500 dollars back then. I ultimately owned one in the early 1990s. Fantastic machine. https://en.m.wikipedia.org/wiki/NeXT_Computer

This question has been asked an answered many times (just search through the forum). Nevertheless, I applaud you for pressing forward and getting that real hardware out of the attic, so here is a summary: Easy - high quality image: Use an RGB CRT monitor (an Atari SC1224) or one from a third party that can sync down to 15Khz. Easy/cheap - high quality monochrome (B&W only) image: Get an ST->VGA adapter cable. The only ST resolution that will work is B&W high (640x400). Hard/cheap - Low quality image: You have an STFM (not an STF), so if you search around, you can find out how to pick a composite video signal (usually a yellow RCA input on your TV) up from the monitor port on the back of your ST. However, composite upscaling on most LCD TVs is crap, and that video signal is a poor way to view ST video even on a real CRT. Hard/Expensive - High quality image: Use a dedicated video upscaler and feed it RGB signals from your ST's monitor port. You will need to understand how to build a cable to get the video signals from the ST's monitor port to the upscaler, and then how to configure that device properly.

I was simply pointing out that the linker could correctly assemble all of the object files into an executable that extends into RAM area that the program is incorrectly assuming is usable. Why would the program be addressing this RAM directly? I assume this is a possibility because the author wrote earlier that he is not inclined to learn the linker configuration process. If the linker is unaware that the program is addressing this memory, it cannot do its job of keeping code out of the way.

I think it is more likely that a problem exists with your linker configuration than with the optimizer. If you optimize for speed, grow the executable, but then do not adjust the link strategy you will end up with a situation where smaller code works but speed-optimized larger code (with unrolled loops, etc.) will fail.

Reading all of this leads me to surmise that you have elected use cc65 because you perceive 6502 assembly language as being too hard to learn. I've also read your comments suggesting the cc65 tools (specifically ld65) are too hard to learn, and you suggest that somebody should change them for you. If you want to write software, you're going to have to do some learning. I have been writing software for 35 years, and I can assure you that the learning requirement never goes away -- there's always another technique, technology, or tool you will need to study. If I were you, I would read Compute's Machine Language for Beginners and get started that way. You can easily write C code for any other computer in the word, but the 6502 married to the Atari custom chips is what makes this machine special.

Thats awesome work! I love how well integrated the PBI port is. Im going to read through your blog now.

No use complaining - just bang out a regex and get on with it.

You might have identified the issue I am having too. I suspect my UAV equipped 800XL also has the 800XLF logic board (and similar image quality issues). I shall investigate. Thanks!

I have looked at precisely this. The problem I encountered is that WINE's headers are not source-compatible with the Altirra codebase. I am confident that a compatible set of headers can be hand crafted, but it is not something that one can accomplish by sitting down and poking at it for just a few hours. The deficiency here lies with WINE - their windows headers are a generation or two out-of-date compared to the Visual Studio codebase on which Altirra is based.

It also stands for "Super Sport" on a variety of performance Chevrolets, and it is the name of one specific mode: https://www.caranddriver.com/chevrolet/ss. @SS, there's nothing wrong with your username.

I'm in for one also.