Mr SQL

I think it would work -there is one low zeropage value that changes immediately when the paddle is plugged in and the value would stick on the PlusCart, paddle cap stayed charged I think. I haven't checked if this is resolved in the latest build for it. EDIT: Meant to say the value would stick on the UnoCart. I noticed I also saw this same issue Andrew observed on the other thread with the SuperCharger (bidirectional loading is actually working as long as the button press is light, it seems to be only the button latching and one other issue I can't figure out where KC proto should just load KC II after all lives are exhausted but it does not). I think the latching is definitely an issue too though:

Building a Clear GameModem Case for PlusCart: This is a clear pic of the clear case I built for my PlusCart, it matches the clear AtariMax cart for my Atari Home Computer visible just behind my Heavy Sixer. Here are two more pics showing the cart glowing with green and blue ambiance from the Popeye screensaver (I like the leave that one on) glowing through it from my big Zenith CRT Television. The PlusCart has red and blue lights on it which are really awesome and also made me want the clear case - you can see the red status light glowing dimly through it in the blue PopEye screen below: Details on how I constructed my clear case for PlusCart Tools: Hand or power drill, tiny drill bit. Component list: My clear case was constructed with off the shelf components that might be present in your home, in the Green PopEye screen you can see a clear case with Rainbow array of neoprene coated paperclips, I selected four brightly colored clips - these have a dual function for PlusCart (more on that later). The remaining components come from two clear cassette cases like these that have the high quality clear finish, but do not use the game pictured if you have it (that's a collectors item no longer available): Construction: carefully sized as you see, it resembles a longer Atari cartridge which distinguishes it from a regular cart for me and makes it feel more special, which it is having the functionality of the classic Game Modem and more effortlessly through the wireless cable modem. I particularly like the extra space at the top because it lights up with phosphorescence in front of a CRT and the LED's both shine through the area when the screen is darker. Functional construction: The wire wraps are tight but the neoprene gives enough shock absorption that PlusCart can be dropped from a height and the casing will fracture before any of the components are damaged; I've dropped my Harmony dozens of time and it's sturdy and only had to be re-flashed once, but PlusCart has additional micro-electronics so I took this extra precaution into account with the construction. I also drop carts fairly often and am pretty close to ruining my unprotected UIEC-SD cart for my C64. The end of the PlusCart edge connector extends and is exposed 1/4 inch when the cart is removed, but I am not worried about this area and it is flush and clamps tightly when inserted (used the drill to Dremel the post inserts on the clear case). Signal Booster: The wire wraps function as coils with antenna ends to form a passive diffractive grating that can boost the signal if PlusCart is very far away from the wireless modem (the PlusCart range is already excellent and matches my other computers). Pretty Cart: The Rainbow clips and clear case make my PlusCart attractive to most players and friends who have seen it and give it a Sci-Fi feel aided by the awesome ability of PlusCart to go online, but some of my friends like @Bill Loguidice with his perfect laser eyes might spot imperfections that that are pretty invisible to me

I really like playing @DEBRO's 4K Pacman and the other awesome 4K and 8K Pacmen too. For Atari fans and other programmers who like Pacman, I've been working on two new 6K versions in KC OS for the Atari Art Competition: Hope everyone enjoys them in December!

So take your pick. P.S. I will leave it as an exercise for the reader to determine how my other quote was twisted. CaptainClassic consider that the programmer who prefers no comments has also written an awesome pacman and is in my pacman folder on the Game Modem too. Regarding the ... quote I didn't agree with "update the code to be correct" since it compiled before the change and RevEng acknowledged the change was intentionally "breaking" code. From my perspective if the code builds a binary, particularly a pacman binary, it is correct. Like the pacman programmer who prefers no comments I simply prefer not to use warnings so escalating any of them to break code affects my coding model more. Some programmers find warnings more helpful and some prefer to treating some warnings or even all of them as errors. That's something new I learned on this thread which is pretty cool. Edit: Here's an example of sharing something new in Defender III and WARPDRIVE, but Alex follows me with more insults the games are running at half the frame rate, simply because of the other thread he linked where another game that looked similar ran at half the frame rate. That game and your SOL ignore game look like e-stalking to me, please knock it off and discuss technology like a normal person or play Atari games instead of forming a circle.

Alright well what did you mean then? @Albert please encourage TJ and Alex to join the conversation in a friendly way. It's OK for programmers to have different perspectives but not to throw insults when someone does not agree a perspective is the one best way. I think that the different builds of Arkanoid Airhead running black, white and Rainbow on the different Atari platforms represent interesting ideas and ways of thinking for interpreting how CBS RAM should function and no one should be angry that those different developers have different ideas and in this case, I carefully wrote code to accommodate the three different ways of thinking and still produce a working ROM. It would be more fun if both programmers participate and join the conversation or at least be tolerant enough of other ideas to let others enjoy them. Close your mind, miss the fun I'm going to post some pics of my transparent case I built for the Game Modem on the PlusCart thread, I built it to match the transparent AtariMax cart for my 800XL, and I'm only responding to friendly posts on this thread going forward, like this one: Awesome double true

I haven't twisted anyone's words, and you're neither ignoring nor contributing to the conversation in a friendly way. Why not share your view for discussion instead of throwing insults or better yet write a Pacman, I think you're a very good programmer! Can you provide an example? I think you must have misunderstood. You misunderstood this clearly, but what you say about my explanation is otherwise accurate - Here's my interpretation: What you call a "lousy toy console running an emulator" is the Atari Flashback Portable Console which is pretty cool for having an SD card to load games, and many players like this console. It doesn't support the SuperCharger format so I wrote a cross compiler to allow games written for the SuperCharger to be cross compiled for the CBS RAM Plus format (7K and 256 Bytes of RAM). If you compare the two entries at the top and bottom of my Game Modem pacman folder screenshot, you'll see Tunnel Runner and Escape from the MindMaster, both amazing 3D pacmen. These 3D pacmen were a large part of inspiration to create the cross compiler that turns SuperCharger games into CBS RAM games, because they illustrate see how close the respective capabilities of the expansion technologies were. I think it shouldn't seem an absurd explanation for abstracting the hardware for a cross-compiler but a requirement for it rather (the abstraction layer). Why not share your perspective never having written a cross compiler in lieu of throwing the personal insults while pretending to ignore me? That just looks like a hit and run...

I quoted you because you believe backward compatibility is an important responsibility of the maintainers of the build tool, which Captain Classic did not understand. I thought your subsequent opinion had academic influence from being a professor, it sounded to me like an ideal University coding model that cannot be used in the real world due to time constraints (ie an academic exercise). I cannot say that both perspective aren't valid because I know great programmers who have both and have seen them applied. I agree with Andrew it's time for a context change - you're both free to explain or comment on my coding model if you wish too, but it might be more fun to talk about Pac-Man now So for the playah's and playah-coders enjoying this thread who's down for Other Peoples Pacmen? I've got over two dozen Pacmen on the new Game Modem and I enjoy them all, Debro's is one of the best: There are some great coders on this thread so build your custom Pacman if you haven't already and share them! I like all of the variations and nuances of the Pacman genre and the individuality of the authors that shine through in the different ports, the original Pacman by @Tod frye is also one of my favorites and here I am setting one of the Game Modem high scores with the awesome 8K reimplementation of Tod's codebase modified by @Nukey Shay:

I've helped preservationists with source code, binaries, games and development tools I built in the 80's. So has Andrew and his ideas above reflect similar perspective I am inclined to agree with, though I find your perspective interesting; why do you think it's not the responsibility of the maintainers of the build tools to keep them backward compatible? Why do you believe this? There are many productive ways to program and escalating warnings to errors and breaking backward compatibility is difficult to justify, because it affects some programming models more than others. I like comments, but I think that programmers who feel the code is all that is necessary (the code is the comments) have an equally valid perspective.

Yes exactly - this is why I thought your idea to treat them all as errors could only be an extreme training exercise. Just one warning escalating into an error and breaking code can cause havoc but imagine if they all really did became errors? Instead of becoming easier no one would ever finish a project they would be so busy hunting down errors that were just warnings in the last build. Really? But I've never looked at warnings except when they are escalated to errors either intentionally or by mistake (both types often get resolved with hotfixes). Well there are many ways to program effectively and I prefer to use Tron; I run a trace when functionality breaks rather than waste time on every single warning on a large project; there's not enough time for that. That sounds like it would work great in academic examples at University along with the boiler-plate example for students, but there is simply no time to peruse warnings in large professional projects as you've pointed out, only the show stopping errors and hot-spots get attention. Debro's 4K Pacman is a very impressive project, I think "blinking dot" in 128 bytes would be the right concept and footprint for your academic exercise. If there's a large project where no warnings exist, tell me more about it's characteristics - what type of project is it?

Not everyone agrees there should be a distinction between errors and warnings or we wouldn't be having the discussion. Some programmers like Andrew feel very strongly they should be treated the same as an exercise in learning proper form (see his post just above) and RevEng explained the warning was escalated to an error similarly with the understanding it would break existing code. I think it's extreme to reclassify an error as a warning, moreso to reclassify all warnings as errors but I understand in Andrew's case he is doing extreme programming exercises to make it more challenging (try that exercise - it's hard I would be recoding forever!)

It depends - I agree warnings are supposed to be reserved for things like technically valid syntax which could be problematic. But this isn't what we see in the real world, the 30 year SQL Server codebase is a good example where well meaning warnings have been added and escalated to be show stoppers that help junior and intermediate programmers, but break complex code beyond the understanding of the author of the warnings that had nothing wrong with it. We use work arounds to resolve these issues when they make it into a release and when identified, they are often reverted via hotfixes. I'm going to buy a vowel, the other codes are ambiguously defined I think only errors should be treated as errors or else we loses the severity which is very useful for warnings; some warnings should just be ignored all of the time and some can be ignored some of the time.

No backwards compatible has nothing to do with error checking unless you escalate an error (change the category) so that the programs will no longer compile, adding additional warnings isn't a problem. I write IDE's and compilers and I think this is very important particularly when the library codebase becomes large. Unless you can personally track down all of the prior source code downloads and mirrors and correct them all too then it makes the code examples more difficult to use for having to "correct it" first so that warnings that have been escalated to show stopping errors can be resolved so they no longer stop the show. I don't think you realize that is what you are arguing; nobody is against compiler warnings, just the idea that some of them should be escalated into show stoppers that break the binary. That's what I'm questioning. "Why do that?" there's no real answer besides pedantic reasoning and there are many compiler warnings to choose from so which one do you think should be turned into a show stopper next?

I'm advocating we keep the mature compilers backward compatible so as not to break other programmers pre-existing code. @DEBRO might not have ever changed his code if the warning from the compiler had not turned into a show stopper to prevent it from working. I think the extreme position is breaking other peoples code, please explain why you disagree.

^This

X2! I didn't find out about that one until @Bill Loguidice shared some info on his Interact on the other thread, but I was impressed by that incarnation of the machine for the same reason - having the ability to write BASIC, Assembly and Forth nevermind Logo would have been awesome. If there was one computer I wish I had bitd it was the Altair: It had switches on the console that you programmed it with, so did the PDP series later but the Altair came first and it was expandable you could add a 4K ROM board with a Cassette interface and even BASIC but that's not the most attractive feature - The system came unexpanded with only 256 bytes of RAM that you program in ASM with a lookup card for the opcode mnemonics with the switches, which was pretty cool and encouraged incredibly efficient code in any language, it's not about BASIC or any other language it's about the memory footprint. The early machines with 4K and BASIC (or 3K and Forth like the oddball Ace) encouraged efficient coding because of the small memory size. I think when the C64 came along and Apple and Atari responded with larger memory footprints for BASIC, this is when we saw spaghetti code and other bad coding habits emerge that were attributed to BASIC but really had only to do with the memory footprint - more than one programmer saw and wrote about this phenomena as machines that previously had 4K were upgraded to 16K and beyond. I started with a 4K TRS-80 and a tape recorder, later in the 80's while I was writing commercial software I took a ZX-81 out of the Library for a short time on loan (you could take them out of the Library like books for a few weeks, the library had several) and found fascinating the memory scheme efficiency that allowed BASIC to run with 1K of RAM and the resulting quality and depth of the algorithms written in both BASIC and Assembly like 1K ZX-81 Chess: https://en.wikipedia.org/wiki/1K_ZX_Chess I acquired a 16K Commodore Pet around the same time but it wasn't as memorable as the ZX-81. I remember seeing ads for a machine like the Jupiter Ace in BYTE magazine that had a Joystick built into the keyboard I was interested in but the machine vanished as quickly as it appeared.

I've competed in programming contests to see who could flag the most compiler warnings so I disagree Some warnings may bother you more than others, but having any warning break the binary changes it to a fatal error - which warning should change next so programmers may be glad to have more errors flagged instead of creating binaries?? I am curious what you have lined up, but I generally don't care for correcting or making other programmers correct already functioning structures in their code.

My big Zenith also is the glowiest, so phosphorescent it feels like the Outer Limits playing at night! I've no idea what model it is but it only has a COAX input like HDN's: I've noticed the model of Atari that is used can have a big effect on the CRT glow as well - I have my Heavy Sixer hooked up to my big Zenith because it potentiates the most glow - my Vader glows a bit less and my Junior much less though it still has a nice glow on it, I imagine the 7800 must have duller video output like the Jr model. I really like the excessive chroma leakage on the Vader and the Heavy Sixer that is causing this, it brings out unexpected artifact colors in some games and textures some colors over RF! Folks doing a composite mod should be careful not to dim the glow. The Atari's nonstandard 240p signal is so bright they were initially worried about burn-in because of it - games like Defender look fantastic just cycling through the color palette in standby mode.

Cool Cat's eyes they glow like miniature green CRT's! Awesome functional setups - I particularly liked the dual VIC-20 & C64 custom wood work and shared peripherals! I also have a couple of old-school Televisions, they all have such a warm phosphor glow compared to modern displays but there is some variation in the glow across brands and wear over time, which CRT's have the best glow in your collection?

I prefer the earlier version that works. None of the old source code should be updated, rather the next release of DASM should address the compatibility issue. Sometimes there is a new release that's just not ready yet and DASM is a mature app with myriad releases - imo there's nothing wrong with going a few versions back to avoid missed bugs present in the latest broken fork release where non-fatal warnings now break the binary. This is a QA issue with DASM all the code should not have to be changed when there is a new release.

I like those options and set the variations for some games, but many classics are also played with just the default settings. The PlusCart highscore page also shows the game settings and many players are not changing them. I wonder if it would be possible to detect the unusual double-shot startup option for Space Invaders? That's one where I usually change the defaults.

Those are nice analytics but I think they might be better as a drill-down link than the default view for those players who prefer modern reporting over a top player list like the Arcades.

Very cool I remember Chromasette! I had a subscription to T&D Software which was similar and wrote several programs for them. X2 it was tremendous fun you never new how many good programs would be among the dozen or so you'd get each month without exploring them. Some were real gems

Great explanation! There's a wide range as you pointed out, OLTP is a spec I've worked with where the system must respond within a couple of seconds. In the OS world some of the real-time subsystems can also be slow by design like Lazy-Writer. imo the Atari 2600 is one of the most real-time systems as you define it in response to Joysticks, paddles and switches because it's architecture allows us to work sub-frame at the scanline level and we can write games and demos that require up to 1/60th of a second response time from the Joysticks like my Fluid City Demo and Game from SillyVenture 2019. In demo mode, the BW switch will make the game require an impossible 60th of a second response time, up from the nearly impossible 30th of a second response time in game mode which is near the edge human reaction times.

No I meant the subscription software model from the 80's where you could actually buy a subscription to some of the larger computer magazines on Tape or Disk for specific home computers as well as from vendors who specialized in subscription software. You would receive a new tape or disk every month full of programs, including quality games and utilities. Because these vendors had no printing press overhead and only the cost of mailing a cheap Disk or slightly more expensive cassette these early subscription models had the room to pay programmers better fees or royalties generally resulting in higher quality games than the magazines.

Homebrew has derogatory connotations like PD or shareware program collections. Type-ins were often pretty good quality games or other software from "power users" who were accomplished programmers. If the software wasn't so good it would get shoveled into a PD collection. Sometimes some of this would get marketed when it should not have but usually there was a hierarchy as follows: PD shareware shovelware (worst) Type-ins in less popular Computer magazines Type-ins in leading Computer magazines subscription software Third party software (best) Homebrew released today correspond similarly though packaging is often mismatched.