Omegamatrix

And finally a video of the Zookeeper Demo. Note I am playing one handed here so don't judge it please!

Okay, with a working expansion port I tried all of the CDFJ roms posted on the Champ Games website, as well as Draconian, Frantic, and Zevious. They all worked perfectly as far as I could see. No issues found.

I mechanically cycled the power switch many times before powering it on to help break any contaminants free. I tested a few Colecovision games and they all worked as they should, with no garbled graphics. Next I plugged the expansion port in and tried 2600 Ladybug. It worked on the first try, and many other times after that. However it suddenly stopped working and I got garbled graphics. I did a bunch of trouble shooting including cartridge removal, cycling the power switch (slow, fast, putting more presure on side, etc...), and moving the expansion port around (lifting it up with respect to the console, pressing down, etc...). Finally I had an idea to remove and insert the expansion port several times to break and corrosion, oxidation, or contaminants free. After doing that everything worked, everytime. My conclusion is that the connector for the module is the weak link, and that it is really deceptive as you can plug a game in and it works, and might work several times. I thought at first it was good because I had so many good clean startups.

Okay, I've tested the a bunch of CDFJ roms on a Colecovision Expansion port #1, and I don't see any issues with the CDFJ scheme. I did find an issue with the connection of the module into the Colecovision which I believe can lead to failures. More on that later. To recap last time I had used my Colecovision I had some random garbled graphics. This seems to be a common issue with the console. Today I examined the console and took it apart to clean it. I Opened the door to the expansion port and was alarmed to see a lot of corrosion. However, upon disassembling the console I could see that it was limited to just the tin plate on the shield. I gave the PCB a good scrubbing on the connector with Isopropyl. Photos below include the serial numbers of my Colecovision and the Expansion Module #1.

I am going to try as well, but it will probably be on the weekend as I first I have to dig to get to the Coleco. I had the 2600 adapter, and I'm about 50% sure I still do. I do know my Coleco had some problems with a garbled screen, but seems like a common problem and I should try and fix it. I'll load up the demo versions on a Harmony and an Encore and see if there is any difference. Many years ago I did do some tests on the expanison module and the only difference I remember was the ZP ram started up with values of zero consistently, where a real 2600 was always randomized.

I remember an idea Nukey posted years ago. I've never done it myself, but in short it was to pad a few WSYNC's after the timer exclusively for game development. The idea is to develop a stable game and remove the them after to help guarantee you don't get close to running out of cycles. The only thing I would caution there is to not have the timer run out to close to the end of the scanline, and to keep the code align with some NOP's unless you want to do a lot more testing. Myself, I generally just use LDA INTIM and branch on not equal. I like to re-use the zero value from the timer if I can. Some games I've done though had way less spare cycles and then I switched to: .waitOverscan: bit TIMINT bpl .waitOverscan That is still minimal bytes. The real advantage is of course is if you go way over cycles it recovers as soon as possible, and hopefully the TV is tolerant enough not to bounce the picture.

Yes, like Darrell says using the playfield is probably the best way. Then it is just balancing the timing of the writes to race the beam. Test3Sprites(mod).asm

I took a brief look and in couple of places I think sbx could be used: Old: txa ; 128 bytes vs 16 cycles / chunk of code clc adc #$40 tax New: txa sbx #-$40 ; X holds correct value Old: clc .pos_s sta s ; ; 8 bit unsigned cos txa adc #$40 tax New: ; no CLC needed .pos_s sta s ; ; 8 bit unsigned cos txa sbx #-$40 ; X holds correct value

Sweet find! I really enjoyed seeing these. Thanks for sharing.

If it was from Canada it is actually NTSC. I had up to three of those at one point and they were all NTSC. I have no idea why a German label ends up in Canada with an NTSC rom, but that's the weird world of pirate carts for you. I found a picture of two of my carts.

They are 100% intentional. As to why... It's a secret to everybody.

Wow, I just read that John-Michael Battaglia died back in 2016. https://buffalonews.com/obituaries/john-michael-battaglia-freelance-film-producer-writer/article_402ae9a9-2b2b-5ee2-b45e-c119ae1c7f84.html He wrote the contest clues for Earthworld and the manual for Waterworld amongst other things. I thought we emailed each other years ago but I can't find it. He had a PCBA of the Earthworld contest cart and was interested in finding a programmer to do updates to the rom. His website seems to be gone. I did find an interview here: http://www.ataricompendium.com/archives/interviews/john-michael_battaglia/interview_john-michael_battaglia.html

For sake of completeness, here are my disassemblies of Earthworld and Waterworld. All that is missing is Airworld which seems to have vaporized... SwordquestEarthworld.asm WaterWorld.asm

I have disassembled and re-assembled all three Fireworld Roms: Fireworld(all).zip The main difference in the Tournament rom is colors and objects needed for clues. Here is a summary of clues: Thank you Rick for providing the rom. This was honestly a great thing as I fear if you had not done it than it would likely have been lost forever. It gives great insight to that particular day, and is something to remember it by.

Yep, it's Earthworld cart you're thinking of. I've bought a few and dumped them but never was able to find one that is similar to the PAL version. However I'm not sure if Torr had a PAL and thought it was NTSC. He did say the colors were correct though.

Opening the windows at night didn't help as the air outside wasn't cooling down. Never seen that happen before. Lots of forest fires started after the heat wave. Smoke from them will be coming in soon I imagine. Today is a little hazy but I don't smell any smoke yet.

Cool. I haven't used that transform in any game so it shouldn't affect anything. BTW if you ever need to change the value from BCD to Binary in the game code itself than I have a blog entry on that: https://atariage.com/forums/blogs/entry/17463-bcd-to-binary/

Just saw this. It's the same problem and I don't know what I did but the roms I posted early were still off for timing. I just uploaded new roms. Please try it now as it should be fixed.

Beamrider has been modified for the PlusCart High Score Club. PlusCart users can find the PAL, PAL60, and NTSC versions in the PlusStore directory "Public ROMs\PlusROMs\High Score Club" The NTSC version can be played online in javatari.js. The ROM-file can also be played with Gopher2600. The "PlusCart High Score Club" page for Beamrider: https://highscore.firmaplus.de/?game_id=43

Tonight I was scrubbing my blogs to reformat all the mangled code block entries and thought about some code I made in @Karl G's topic about BCD to Binary Routines. Here is the last routine I made: ; BCD value $0 - $99 is in A. Returns binary number 0-99 in A BCDtoBin6: sta Temp and #$F0 lsr sta Temp2 lsr lsr adc Temp sec sbc Temp2 rts Here is @Andrew Davie's explaination of the routine:

I can't sleep. I'm consumed by this problem and I keep thinking about it... Tonight I discovered some of Batari's solutions for hex to bcd conversion here and here. They are very compact solutions, and neat. I started to wonder if a constant (un-looped) cycle approach could be found without using tables. Then the insomnia crept in. I decided to have a go at translating hex values of 0-99 (BCD range for a byte). The approach I took was to modify my divide by 10 routine so that the result was multiplied by 6, and then added it to the initial value. From there I optimized it so that some of the shifts could be cut out, and removed the correction value (adc #13) from the divide routine, because that is only required for values 130 or more (and we are just doing 0-99). Here is what I came up with: ;Hex2Bcd (good 0-99) ;24 bytes, 39 cycles ;You can also use LSR for all ROR's here... sta temp lsr adc temp ror lsr lsr adc temp ror adc temp ror lsr and #$3C sta temp2 lsr adc temp2 adc temp I wrote a real short verification program. Basically just a macro that pumps out all the results and stuffs them into zero page ram, which can easily been seen in Stella's debugger. I did a visual verification. hex2bcd.zip

Should be good now. I was logged out of the client so the roms were there but not synced to the server.

I also have thought about this since then, and while it won't work for your game I will mention that there is an illegal opcode option that is quicker, and uses less bytes: ldx roomId lda roomSpriteIdx, x ldx #$F0 sax roomSprPtrL ora #$F0 sta roomSprPtrH