Mr SQL

I had a similar error in my iterate readonly registers program, so my consistent results are due to programming error, that very same error actually! I've attached a corrected iteration program that goes through the first 99 addresses and shows the values, they are mostly zero but when the cap is charged by the paddle or the sega pad register 24 (AUDF1) goes high and a few others may change as well I haven't finished comparing. Charging the cap changes the environment the program sees from by plugging in a paddle or a sega-pad as we see, and you are able to somehow discharge the cap with the harmony menu (maybe when you read the paddle to see if it is being used??) and the supercharger GUI also discharges the cap similarly. In the instance with KC breaking, we can get the cap to discharge with another program and then KC runs again - my program with the error was discharging it as well, but for best compatibility the capacitor discharge init in the menu like you are doing grants closer emulation to the SuperCharger because it is doing it too. The closer we can get to making the environment a 100% match, the closer we get to running all of the SuperCharger classics and homebrews - Harmony is doing that and Uno is very close, so any differences where Harmony and Stella are matching the SuperCharger environment and Uno is not are important to tune to match. FIXED_iterate_writeonly_regs.bin

We ran across what looks like a stable hardware initialization for register 24 ($18) that appears to be part of the SuperCharger BIOS and your Harmony BIOS, but not present in the PlusCart. Looping through the write only regs prior to 24, performs a hardware init (discharges a cap likely) and register 24 comes up correctly initialized to 24 when read. If the hardware init isn't done it can stay floated so the readAUDF1.bin test will continue to yellow screen when run on the pluscart after a paddle is inserted into the left joystick port with the power on (charges a cap) and it stays high even if the Atari is unplugged and the cart is unplugged. It will stay high until a SuperCharger or a Harmony is inserted and their startup BIOS reinitializes it like the second test program is doing to trigger a hardware init - imo there is a part of your Harmony menu routine startup routine that touches the low registers, I just have to insert the Harmony same as the SuperCharger to trigger the init - they both loop through the low regs and set them to zero as part of the init routine, either that or they are touching at least one of the low regs somewhere that discharges the cap like we see happening in the test examples above?

Well when I run the test program on my Jr and my Vader using the Harmony, Uno or the SuperCharger, or on the emu I'm getting consistent results except for the paddle/bad breaking $18. I'm very curious why reading any increments of 10 from the write registers will freeze the Atari - but if the programmer makes that mistake they know right away. I'm also curious what others systems look like because so far it looks like a consistent design; I agree temperature can change $18 too but it takes hours with the Harmony cart and many hours with the SuperCharger - two unanswered questions we have so far related to this interesting design are related to the edge case $18: Why does the UnoCart need to be unplugged to stop from floating $18 (AUDV1) after a paddle/Pad is inserted into the left port to trigger it during the attached AUDF1 read demo and the Harmony only needs to have the Atari powered off and back on to return register $18 to read $18 again? And what else is my KCMM ROM doing that it needs either the Harmony inserted in the interim or the demo program to be run to restore it? Seems perhaps another value is being floated? I have to leave KC running for hours to trigger a temperature change to the register $18 read on the Harmony and it's even more stable with the SuperCharger. Folks are playing a game not running a mission critical app so it looks good enough from what I've seen so far. You say you don't need the test program, I'm skeptical anyone with just a joystick plugged into the left port is not going to see the iteration test program in my last post counting up evenly from 2 until it freezes at 60 (skipping the other 10's). Anyone get a different result?? Please try the test and share info on your Atari model, this is pretty interesting. READAUDF1.bin

I don't think this is a coincidence, this has been observed before with another write only register by @vdub_bobby : Here is another test ROM to illustrate with GRP0 but it is more stable because a paddle or sega-pad does not change the read value ReadGRP0.bin Are there any write only registers that don't follow this rule when reading them? It is a fairly common bug so there could be multiple titles to support by emulating the clever design. EDIT: Added a test ROM that iterates through all the low write-only registers - multiples of 10 crash the Atari and the emu, all other numbers seem to follow the design, at least on my Atari's. I let it crash on 60 ITERATE_WRITEONLY_REGS.bin ITERATE_WRITEONLY_REGS.wav

More interesting information on this bug - it looks like the UnoCart can be triggered to different read state on a write-only register as shown in the test program here that shows the read value and yellow screens when this condition occurs. To reproduce this condition insert a sega-pad or paddles into the left joystick port while the program is running, then power off and put a regular joystick back in; power back on and reload the program - the different state is maintained as illustrated when it yellow screens again. To resolve the condition it is necessary to remove the UnoCart and reinsert it, and run the test program again (no yellow screen). What is still very elusive however is that these same steps cannot be used to fix KC once the sega-pad breaks the game - the yellow monster will still continue breaking even after the UnoCart is removed and the game is reinserted, however there is a workaround: the test program can be used to restore the UnoCart, then KC runs again The KC II SuperCharger version does not exhibit this issue as it does not try to read from a write only register. This is an important bug to fix imo because for many write only registers, the same read value is returned as would be for a literal so that " lda 24 " is effectively no different than " lda #24". This is a very common mistake so the safety-catch built into the original hardware needs to be mirrored for full compatibility. @DirtyHairy I have been working on Survival Islands multiload compatibility with @Al_Nafuur and have a question about the RIOT RAM, is it preserved on subsequent loads for the SuperCharger? If not this may be may be why the codes entered are not passed to the next stage of the multiload. Or maybe this odd bug has something to do with it.

Is it possible you referenced location 24 instead of #24? Location 24 is the TIA register AUDF1 which is a write register, but if you read it it actually returns 24 which is pretty handy - at least it does most of the time. turns out if you insert a Sega-Pad or a paddle this location briefly changes; I utilized that feature for KCMM because it prevented use of a Sega-Pad and required a joystick, but it caused some unexpected behavior. Here's a test program that will show the value of AUDF1 on the screen - some weird things happen that should be reproducible: READAUDF1.bin The program polls the write only register and shows the value, and yellow screens when the value exceeds 99 When I run it on a Harmony it's always 24, but if I plug in the paddle or the pad it yellow screens. With the Uno cart the behavior get's very strange, I think a hardware issue maybe with a cap in the console because the Harmony cart can be used to fix whatever is happening with the Uno when it sticks: The Uno returns a 24 at first if using the joystick, but after the sega-pad is plugged in it doesn't matter if I power off and unplug the UnoCart and then put it back in, it continues to yellow screen unless I plug in the Harmony cart to clear it. I suspect if James leaves the test program running overnight it may yellow screen, temperature change can cause the read to fluctuate.

EDIT: Added the enhanced SuperCharger version for SillyVenture2020 with carefully tuned PAL colors and an improved power-up tune with help from @Al_Nafuur! And inspiration from @aramis!

James it may not be the TIA that is causing random playfield pixels to be set - I had a 2014 build of KC Munchkin where this was happening but it would only happen after the game was on over night. I found it was temperature dependent as an Atari in a cold room could trigger it in just a couple of hours. Turns out some of the low Zero Page memory locations can change with temperature (not the 128 bytes of RAM) and if you are using as an offset, the offset value changes causing the stray playfield pixels to be set. What's stranger is that the phenomena only happened with my Harmony running KC as per the description from the vid - This strange behaviour showed up only after a 20 hour burn in on my Harmony running KC; 48 hour plus burn ins on SuperCharger run clean. @batari any thoughts if these are related or what is causing them?

Yes I am creating a PAL version for the SillyVenture 2020 compo! PAL colors behave more differently than I had thought, I learned that some of the dimmer PAL colors can vanish completely on some systems depending on the type of composite mod while working on a PAL release last year. I will PM you the PAL build before I release it if you could help me tune it for PAL, I would like to get it as close as possible on all PAL displays.

FPGA's have been advertised as surpassing emulation like the core for the new mini Nintendo console. But I think there is still some form of emulation (not simulation) going on as in the case of MISTer's Atari 2600 core, which is very impressive but not outputting a genuine NTSC or PAL video signal to race the beam but rather an HDMI signal that may not match closely enough for all projects: https://retromaster.wordpress.com/a2601/ I utilize the classic VCS hardware in a research project that requires very high accuracy and an NTSC CRT, I could probably use an FPGA Atari provided a classic video signal was generated for CRT. There are also really fun games like this one that use phosphor and NTSC artifact colors to create visual effects that require a CRT Television and are currently lost under HDMI. The future of FPGA: It would be a daunting task, but if an FPGA could be created to simulate a CRT then we could see all of these cool effects under HDMI because as @Keatah had observed it is possible to shoot a video off of a CRT Television and then see the effects happening on LCD, so now all we need is a real time FPGA simulated CRT with that simulated beam to race

I just released the sequel to KC Munchkin which supports the UnoCart and the Atari Flashback Portable I tested the sequel on the Retron77 console with the community build of Stella and patched a new Stella bug before releasing where the decimal flag gets set on startup. That generally doesn't happen on the real hardware, and it seems as ARM game support is increased existing compatibility goes down. This isn't so surprising as it's easy to introduce new bugs with new development; emulators that are finished (Z26) or focus on supporting only classic Atari 2600 games are starting to show greater compatibility, the Flashback Portable is a good example in not needing the special fix the Retron77 required. Stella could evolve into an ARM game only platform that simply cannot support classic Atari games if the trend continues; quality control and testing is important when frequently releasing new builds. The ROM is here:

EDIT: Added the enhanced SuperCharger version for SillyVenture2020 with carefully tuned PAL colors and an improved power-up tune with help from Al_Nafur! KC_MUNCHKIN_II_PAL.bin KC_MUNCHKIN_II_NTSC.bin KC_MUNCHKIN_II.bin (Flashback Portable Version) KC Munchkin II, approved by Ed Averett KC's Dad the creator of KC Munchkin on the Magnavox Odyssey2! This CBS RAM Cartridge version is compatible with the Atari Flashback Portable and the Uno Cart! SuperCharger version comming soon... The Story: KC Plays on a very expansive scrolling board and covers a much larger territory than in the prequel with interactive phat background music! You can take control of KC from the AI at any time you choose, or play cooperatively allowing the CPU to make some of your moves for you! Demo: Try just watching the game for a minute in Demo mode without touching the joystick to see how it is played. Play: A Joystick is recommended for precision control, but a Sega pad can be used in this sequel. I've attached the manual for KC Monochrome Dreams which has similar gameplay and will tell you how to find the score! Here is the online version to try in the Javatari emulator which plays excellent. Note: If you are using Stella or the Retron77 console community build to play, make sure to turn off phosphor emulation and merging frames as this game uses motion blur reduction controlling all 60 frames individually to achieve the fast animation effects without judder. For best play experience, use a classic console and a CRT Television (NTSC)! KC_Monochrome_Dreams_Manual.pdf

Cool project! I liked your innovative research on your site delving into 1920's retro tech; the circuit bending example with the two oscillators. Amazing use of that pioneering technology in it's emergent state to create and apply those optimizations over SAM to get the footprint under 4k. Very interesting read!

I think you only need the Copyright office if you are protecting IP that has not been distributed yet or you do not have a clear record of distribution - A contract or direct sales to even one person will suffice to support your copyright notice on the IP. Open source fans should be aware however that they may not have the same rights to their own IP; I give IP away freely to specifically avoid open source licensing for commercial development so that I can use that IP without restriction in licensed IP products (problematic using open source kit to do the same thing because it attaches the GPL).

Agree - the VCS was released in the era of the Altair when folks understood that switches on the console were for programming the computer system and that was a big part of magic. You could either just play the games, or you could throw the switches in combination to program in commands to access additional games, sometimes dozens per cartridge! All you had to do was learn to program the new video computer system via the switches like you saw your friends learning to do.

Thanks this is interesting to see, I've never looked at the actual BIOS from the SuperCharger just used it like a black box but I can see what part is missing from the UnoCart implementation. @Dirty HarryI hope this helps: cld ldx #$ff txs .1 sta $00,x dex bne .1

The game modem could also be included. And the Canal, a Brazilian variant of the SuperCharger with more RAM.

Very cool! Fantastic if you are able to get it running on the Harmony too. I had to choose between an upgrade to the Encore or the Uno recently to play BitChess and found the Uno is not as compatible with SuperCharger games, can you share your SC BIOS emulation code to help with compatibility? This solution sounds ideal but I don't want to get up to press select - what about monitoring only the button being pressed and held for 7 seconds to restart? This might be a problem for games where you hold the button down though....

@Dirty HarryI think you've created your own SuperCharger implementation, every other one performs an init like the SuperCharger. This reminds me of when you merged the frames in Stella breaking STARBLITZ on that platform; why not shoot for more compatibility instead of trying to break games that push the envelope? You've previously thrown a lot of insults while sharing your perspective, so it looks rather deliberate - and that's too bad it's a fun game. Why not try to write a fun game instead of having fun breaking them? It would give you a better understanding of the Atari and so would not just copying code but writing an original implementation from the ground up. The non-functional code you are adding is original code, yet it is only breaking my games selectively which looks like a very old game: Today some of the other racers have powerful engines hidden in the frames and don't need help from anyone throwing sticks. There are more than 128 bytes on the Atari, please fix the bug so folks can enjoy the game on the UnoCart too.

Interesting thread! There were home computers with chips like this too, advertised as 32K but really having 64. The supposedly half-bad chips worked great; the Brazilian version was called the Prologica.

The SuperCharger BIOS handles initialization on startup so I think it's better if the stub can emulate this aspect rather than requiring the programmer to repeat it, so that the full 6K can be used for the game. btw I was working with some old demo code recently, and I believe you were correct about CBS RAM being randomized on startup. I have an interesting CBS RAM binary for Arkanoid Airhead that is white on the flashback portable, black on the Uno and Harmony carts, and Rainbow on the Retron 77 console because of three different ideas on emulating it for best compatibility. In this instance, the game is still playable and more interesting if you have all three different consoles to play it on!

UPDATE: I tested KC on Gopher2600 with @JetSetIlly and it worked perfectly! Gopher2600 uses the real SuperCharger BIOS ROM rather than emulating the BIOS while the Harmony/Encore emulates just the part of the BIOS necessary to run the game. The UnoCart goes further to emulate more of the SC BIOS including the curtain opening, however the SC BIOS initializes the paddle RAM which the UnoCart either does not do or initializes differently triggering the bug: Plugging in a Sega-Pad will cause the game to break apart like this using a real SuperCharger or the Harmony/Melody cart by design, because the Sega-Pad initializes the paddle RAM to a different state than the SC when it is plugged in.

Nice! The 32 character venetian blinds text display adds a lot of character to the font, awesome for reading text! This opens up the possibility of having text manuals right next to the game. Is the main menu still using the large VIC-20 sized font like the UnoCart? I find it easier for the game selection. I hope that the manual reader gets backported to the UnoCart and possibly added to Harmony/Encore like the alpha-sort.

I think there's probably nothing wrong with your friends light sixer, but that your friends Television is likely right on the spec requiring a stable scanline count. Even some classic Televisions have additional circuitry to tolerate a degree of variance in the scanline count, yours may have this. I initially used a Sony CRT with my setup that had these characteristics and did not roll easily, models like the JVC or Sears SR1 Composite Monitor are better for development on the real hardware, because they are right on the spec and will roll with a variance of just 1 scanline; that is the kind I use now.

Yes here is a clip from the Uno compared to the Harmony: KCMM_breaking_on_UNO.MOV KC_working_on Harmony.MOV