nick3092

If you are a member of the CollectorVision club, it is most likely in the rom vault. Unfortunately, if you aren't, membership for this year closed April 1st.

Afaik this does not take advantage of SGM at all. So you won't see any difference. Infact, if I have my SGM attached when I power on the Coleco with the cart, about 50% of the time I get a red screen at the capcom logo and it freezes up. Have to play reset roulette till it boots properly.

According to the video description, it was played on a Phoenix. Which emulates the F18a hardware mod. And the F18a eliminates flicker.

Ah, I just skimmed the manual and saw "attach wire" and assumed it was the same as most other consoles where you have to have the wire sticking out. I never really pursued it on my 5200 adapter. Thanks for the explanation of what is actually taking place for the reset circuit. But still a little fiddly, especially if there is a way to do it without soldering any jumpers or wires as Steve seems to have done. Especially since he doesn't have any notes or disclaimers that his reset button only works with 2 port or modified 4 ports. I did point out to Evie on the Coleco that there must be someway to trigger the reset through software instead of the wire, as that is how Steve did it. But she didn't seem interested in pursuing it. Like I said, she seems interested in just bare bones basic functionality. Which is fine, its her cart and I actually use it without the reset wire in most cases. And I get it, it may take a much deeper dive into Coleco or 5200 hardware to figure out these reset methods that don't require wires/jumpers that shes not interested in doing. Steve basically supports like 3 platforms for his carts. Evie supports like 15 for Backbit, and seems to be working on adding more. Need to pick and choose where your priorities are at that point when you are juggling that many systems.

Backbit doesn't (automatically) support a reset button on the original 4 ports (my understanding is the ones not compatible with the 2600 adapter), but does with the 4 ports that are compatible and 2 ports. However, you have to flip a switch on the adapter to enable it. Which implies there is some sort of different pin/signal routing involved depending on the 5200 console it's connected to. I'm not sure how Steve approached that with the newer carts that now have a reset button. But for the early 4 ports with Backbit, you can clip a wire on one of the ICs that runs to the backbit, and then the reset button will work. On the flip side for Coleco, Atarimax has a reset button, no extra work needed. But Backbit requires you to open up your Coleco and clip a wire to the motherboard and connect it to the backbit to enable the reset button. So in this case, Atarimax does what Evie don't. IMO Evie seems to be more interested in a no frills approach to Backbit. And there is nothing wrong with that. I say that owning pretty much every adapter of hers that I also have a dedicated flash cart for. Having options is good, and sometimes it's nice having both options.

The club registration closed Monday. When is the vault info going to be sent out?

Mine used/took the 1756E157 version successfully. Steve is very helpful the times I've contacted him, and as I understand is very generous in his warranty. Luckily, I've never had to use the warranty. No argument there. I'd gladly buy any product he sells that I need (I already own 3). My experience is he is responsive once he replies. But it usually takes weeks and multiple emails to get his attention. And I'm not alone in that experience. Then there is the fact that unlike almost every other product out there, he doesn't publicly post the firmware nor provide any kind of changelog. So then you have to jump through hoops getting ahold of him to make sure your cart is up to date. Unless someone who already did the leg work posts them here. And even then you have no idea if it's worth it.

I mentioned that towards the end of the post: "As a frame of reference, mine is reset-less and purchased early/mid 2017 and mine used the 1756E157 version)."

Well, people should still click if they are looking for updated firmware. I posted both the most recent 5200 firmwares in that thread Steve gave me for two different cart revisions at the end of Jan 2024 or so. Again, it didn't brick my cart using the wrong one, but you never know. It certainly seems like Steve made sure there is always a recovery option.

Check the info I posted in this thread from back in Feb.

I wrote out both sides of 4am's Masquerade to a floppy with Copy II+. I had no issues running the game on my enhanced IIe. It went to side B, drew the hotel room, and I was able to go south to the lobby. So, I'm not really sure what to tell you. The image is good, as proven by both AppleWin and myself. Since it's cracked, it should just be a plain 3.3 disk image that the CFFA should be able to handle. If you have a SSC and the proper cables, you could try writing out a copy with ADTPro just to rule out the CFFA doing anything odd when making the floppy. You could run the self test in the IIe by rebooting with both apples, ctrl, reset.

Highly unlikely. My IIe where the disk images are working with my floppy emu is enhanced. The enhancement only created issues with a very small number of software where it relied on the 6502 doing something a certain way where the 65C02 did it differently. This game does not appear to be one of them.

What images are you using? If you are running copy protected software, your first stop to look for it is 4am's collection. All his images are cleanly cracked. I can't speak to using a CFFA3000 on this as I do t own one. But I can confirm that I got the 4am crack of the game working on my IIe and floppy emu. After booting, I "flipped" the disk over and it started up with graphics in the cheap hotel room. No reason you shouldn't be able to create a real floppy from 4am's images either. No need to use any special bit copy function, just a plain old copy.

You may already know, but analog does need to be TTL sync. Attenuated, like you would find coming out of a SCART cable or possibly other cables, won't work.

Latest news is in this thread from about two weeks ago. No concrete shipping date yet.

Thanks!

Since I have the original JagSD (no QR code) and I'm not aware of any way to check/download the current firmware, can someone confirm if I'm current? I honestly haven't fired up the Jag in quite a while, so I may be behind. But I also know there hasn't been a whole lot of changes in recent times either. So maybe I'm not. Not sure if these version numbers would also line up with the GD version with a QR code that someone could confirm. Firmware 1.10 Menu 1.07 Asic 1.07 Stub 1.03 Thanks!

Full disclosure, I know nothing about assembly programming. But I did find a tool that can disassemble 7800 roms (distella) and disassembled both the the original dump and mine. Then loaded the results into Notepad++ and ran a compare. And there seem to be a number of changes. I don't think bit rot could explain all of them. But again, I'd really love to hear form someone who knows programming for the 7800. For example, many of the (sub?)routines contain the same code, just at different addresses. But in some cases, the dumped version has a couple extra instructions. Like the example below. The "original" dump is on the left and my dump on the right. You can see that the addresses don't match, but the instructions are almost identical. Except on the right you can see a couple extra LDA and STA instructions. Again, I'm not a programmer by any means. But the odds of bit rot causing seemingly legitimate instructions to appear along side instructions that match the original seems unlikely to me. And in some cases my dump lacks a couple LDA/STA instructions that otherwise seemingly match: But these simple observations are about as far as I can try and decipher this.

5 weeks now with no update. I totally understand stuff happens and things like this get delayed. But I don't think asking for a quick update every two weeks or so at this point being so far past the projected date is being unreasonable. Or at least set a new estimated date and hold off on updates till then.

Looks like a bunch of diodes to try and prevent the ICs from getting fried. Ruggers Customs makes a PCB with diodes on it you solder to the to the bottom of the controller port to do the same thing. https://console5.com/store/anti-static-d9-joystick-port-esd-set-pair-of-2-static-protection-add-on-pcb.html

I was going through dumping all my 7800 carts to help No Intro verify their dumps as many only have one source. And I came across something odd with DK Jr. While all my carts matched No-Intro, DK Jr refused to. It's consistently dumping the same ROM (5 times), despite making sure all the contacts are clean between dumps. So, I'm trying to figure out if it's actually a variant or maybe just bit rot setting in. My DK Jr is coming out as CRC BE4C67B2. The one recognized by Trebor/No Intro (with the header removed) is 1C5A1082. I compared them in a hex editor, and I do see some similarities. But obviously a few differences too. Like my dump seems to have a few more extra FF's in the front of the ROM before the actual data seems to start. If I insert the header from the copy in Trebor's collection on to my dump, it does seem to work fine in an emulator. I did a very brief play through of both this dump and the one from Trebor's collection, but didn't notice any differences At the advice of @Mitch, I'm posting it here to see if anyone else can either dump their copy to see if they can reproduce this ROM, or if someone with the proper knowledge can disassemble it and take a peek to see whats going on with it. Donkey Kong Junior Dump #5.bin

He is most likely referring to it being added to the rom vault. Not saying rtype will be one of the club games. But given those games were just sold fairly recently, it will probably be at least 1-2 years before they get added to the vault.

Given we are 1 day shy of 4 weeks since the last update, any new news or ETA to share?

What's wrong with ColEm that you haven't tried that? Meets your seemingly minimum requirements of SGM and menus.