PacManPlus Posted April 11, 2021 Share Posted April 11, 2021 I also used Bruce's method. That was the easiest, but it only allows up to a 16K EPROM @CPUWIZ - You are a madman! Love how clean that board looks 3 Quote Link to comment Share on other sites More sharing options...
CPUWIZ Posted April 11, 2021 Share Posted April 11, 2021 17 minutes ago, PacManPlus said: I also used Bruce's method. That was the easiest, but it only allows up to a 16K EPROM @CPUWIZ - You are a madman! Love how clean that board looks Technically, you can map the full 48K, all you have to do is tap the address bus for the upper address lines on the EPROM. Yeah, that is by far the nicest oldest board I have seen. 3 Quote Link to comment Share on other sites More sharing options...
+Mitch Posted April 11, 2021 Share Posted April 11, 2021 If you have a 7800 board with the remnants of the timing circuit you can use one of the unused gates on the 74LS02 as the inverter. Mitch 2 Quote Link to comment Share on other sites More sharing options...
+-^CrossBow^- Posted April 12, 2021 Share Posted April 12, 2021 9 hours ago, CPUWIZ said: Nope, the old method (Bruce Tomlin's) was piggy backing a 7404 coackroach style on top of the 7408, above the MARIA. Unless you worked off of something else back then. That is what I used. My own method is a bit different, because I have multi BIOS modules in mine. Here is my latest module, which will finish my ZIF monster, still need to swap the 0 Ohm and plug it in. You are of course correct. I decided to take my original 7800 out of the box and closet today as I had been meaning to replace out the switches on it for sometime since the originals have been flaky for years. I did indeed solder a hex inverter in place to use with it but again I did this like 20years ago so I couldn't remember the full details. 3 Quote Link to comment Share on other sites More sharing options...
PacManPlus Posted April 15, 2021 Share Posted April 15, 2021 (edited) Here's a weird issue I wanted to throw out there... if anyone has any ideas... The BIOS works great - except for the CCII. It seems that if the console has been off for a bit, the CCII menu mostly comes up corrupted. Powering off/on the unit can make the menu come up normal about once every 15 boots. If I leave the unit on for a while, the longer it is on, the more often the menu comes up normal. Up to the point (I would say after leaving the unit on for about 20 to 30 minutes), then the menu comes up correct - every time. I've *never* seen this before, and I'm curious to know why the cart doesn't react that way with the standard NTSC bios or even the standard PAL one. Does anyone have any ideas? Thanks! Edited April 15, 2021 by PacManPlus Quote Link to comment Share on other sites More sharing options...
PacManPlus Posted April 19, 2021 Share Posted April 19, 2021 (edited) Ok, being that we cannot get past this last issue, this custom BIOS is put on hold indefinitely until a resolution is found. Edited April 19, 2021 by PacManPlus Quote Link to comment Share on other sites More sharing options...
+-^CrossBow^- Posted April 19, 2021 Share Posted April 19, 2021 3 hours ago, PacManPlus said: Ok, being that we cannot get past this last issue, this custom BIOS is put on hold indefinitely until a resolution is found. If the issue only affects CC2 users I wouldn't consider that a deal breaker for the rest of us that don't own one. The real question is if you have seen any issues with using it on normal games, homebrew releases, or with a concerto or Dragonfly cartridge? If only the CC2 is affected, I'd call that successful. 1 Quote Link to comment Share on other sites More sharing options...
PacManPlus Posted April 19, 2021 Share Posted April 19, 2021 (edited) I haven't had an issue with any normal / retail games so far, haven't found any with the homebrews that I've tried (Ive even tried 'Tainted Love' - the 512K cart!), nor with the Dragonfly. Now granted, I don't have that many stand alone games, so I can't test with everything, but I've tried some of the ones I thought might give it a hard time (like Bentley Bear). It's just this CCII thing is bugging me. The original NTSC BIOS works no matter what the temperature of the machine, as does the original PAL BIOS, so what gives? *EDIT* - I'm just afraid that if this is happening with the CCII, it could happen with something else. Edited April 19, 2021 by PacManPlus Quote Link to comment Share on other sites More sharing options...
TailChao Posted April 20, 2021 Share Posted April 20, 2021 Does the Cuttle Cart II map anything which could respond to reads when A12, A14, and A15 are low? Secret registers from $0000 - $0FFF or $2000 - $2FFF are suspect, as these would be enabled when the BIOS reads from $8000-ish. The NTSC and PAL BIOSes stay above $C000 which would prevent a conflict like this. Quote Link to comment Share on other sites More sharing options...
tep392 Posted April 20, 2021 Share Posted April 20, 2021 On 4/14/2021 at 7:37 PM, PacManPlus said: Here's a weird issue I wanted to throw out there... if anyone has any ideas... The BIOS works great - except for the CCII. It seems that if the console has been off for a bit, the CCII menu mostly comes up corrupted. Powering off/on the unit can make the menu come up normal about once every 15 boots. If I leave the unit on for a while, the longer it is on, the more often the menu comes up normal. Up to the point (I would say after leaving the unit on for about 20 to 30 minutes), then the menu comes up correct - every time. I've *never* seen this before, and I'm curious to know why the cart doesn't react that way with the standard NTSC bios or even the standard PAL one. Does anyone have any ideas? Thanks! I've been playing around with RAM in the Versiboard for the last several days. Your symptoms sound similar to what I experience with RAM errors. I'm running a RAM test in a loop and displaying any read errors that show up. I'm finding that the RAM will mostly work except for some specific areas of memory. But those errors will gradually go away as the console warms up. Does the CCII run the binaries out of RAM? I don't know what the cause of the problem is but I've found that the speed of the RAM and the temperature of the console are factors. Edit: one other thing is that dirty cart slot connectors aggravate the problem. One of my consoles has some corrosion in the cart slot. I have to periodically reinsert carts to get them to work. I've found that adjusting the position of the my test cart in the slot can help with the RAM errors. 4 Quote Link to comment Share on other sites More sharing options...
PacManPlus Posted April 20, 2021 Share Posted April 20, 2021 Hi guys! 2 hours ago, TailChao said: Does the Cuttle Cart II map anything which could respond to reads when A12, A14, and A15 are low? Secret registers from $0000 - $0FFF or $2000 - $2FFF are suspect, as these would be enabled when the BIOS reads from $8000-ish. The NTSC and PAL BIOSes stay above $C000 which would prevent a conflict like this. Thank you! I don't believe it is that, only because the PAL BIOS uses $23XX and $27XX without issue... We're (RevEng and I) are using $18XX and $27XX. 43 minutes ago, tep392 said: I've been playing around with RAM in the Versiboard for the last several days. Your symptoms sound similar to what I experience with RAM errors. I'm running a RAM test in a loop and displaying any read errors that show up. I'm finding that the RAM will mostly work except for some specific areas of memory. But those errors will gradually go away as the console warms up. Does the CCII run the binaries out of RAM? I don't know what the cause of the problem is but I've found that the speed of the RAM and the temperature of the console are factors. Edit: one other thing is that dirty cart slot connectors aggravate the problem. One of my consoles has some corrosion in the cart slot. I have to periodically reinsert carts to get them to work. I've found that adjusting the position of the my test cart in the slot can help with the RAM errors. I've actually left the cart in the slot from the beginning (cold unit giving corrupt menus) to completely warmed up (no corrupt menus at all). Ok, I'm going to have to BIOS mod my other unit to see if it happens on that one. That may lean toward the RAM issue being the culprit. Quote Link to comment Share on other sites More sharing options...
TailChao Posted April 20, 2021 Share Posted April 20, 2021 3 minutes ago, PacManPlus said: Thank you! I don't believe it is that, only because the PAL BIOS uses $23XX and $27XX without issue... We're (RevEng and I) are using $18XX and $27XX. Not sure I did a good job describing this, but I didn't mean the console's internal hardware responding to $0000 - $0FFF and $2000 - $2FFF. Rather, anything on the cartridge responding to this range. When the cartridge is "disabled" it only forces A12, A14, and A15 low - which doesn't truly disable it for the entire address space. So if the BIOS executes or reads from $8F80, the cartridge would see a read at $0F80. The sort of symptoms you're describing are typical of a bus fight, hence the paranoia. 1 Quote Link to comment Share on other sites More sharing options...
PacManPlus Posted April 20, 2021 Share Posted April 20, 2021 OH! ok... I'm trying to think of how to check for this. If I *do* change the RAM we use to stick to the $1800-$1FFF area, there shouldn't be any contention on either the cart or system ends, do I have that right? Quote Link to comment Share on other sites More sharing options...
CPUWIZ Posted April 20, 2021 Share Posted April 20, 2021 2 minutes ago, PacManPlus said: OH! ok... I'm trying to think of how to check for this. If I *do* change the RAM we use to stick to the $1800-$1FFF area, there shouldn't be any contention on either the cart or system ends, do I have that right? That would be a bug, system RAM should never be mapped by anyone. 1 Quote Link to comment Share on other sites More sharing options...
TailChao Posted April 20, 2021 Share Posted April 20, 2021 12 minutes ago, PacManPlus said: ok... I'm trying to think of how to check for this. If I *do* change the RAM we use to stick to the $1800-$1FFF area, there shouldn't be any contention on either the cart or system ends, do I have that right? Not quite, I'll try again. To preface - if you have documentation on how the Cuttle Cart actually works, that's most important. What I'm writing is a guess based upon other designs dropping registers all over the lower address space, and the stock BIOSes avoiding similar issues by coincidence. When you disable the cartridge using INPTCTRL it forces A12, A14, and A15 low on the slot. Effectively, every single read or write is masked with this... FEDC AB98 7654 3210 %00x0 xxxx xxxx xxxx ...so if the BIOS is executing from $8000 - $8FFF, the cartridge (when disabled) will actually see these accesses at $0000 - $0FFF. If there's anything hiding there (again - on the cartridge) which responds to reads, it might try to drive the bus at the same time as the BIOS ROM. A quick and dirty check would be to strip down your replacement BIOS to immediately switch into 7800 mode and dispatch the cartridge. Keep it within the 4KB from $F000 - $FFFF just like the stock NTSC BIOS ROM. If the Cuttle Cart is still acting weird in this situation, then it's probably something else. 1 Quote Link to comment Share on other sites More sharing options...
PacManPlus Posted April 20, 2021 Share Posted April 20, 2021 Ok, I think I got it - sorry for being dense. Thank you Quote Link to comment Share on other sites More sharing options...
CPUWIZ Posted April 20, 2021 Share Posted April 20, 2021 5 minutes ago, TailChao said: A quick and dirty check would be to strip down your replacement BIOS to immediately switch into 7800 mode and dispatch the cartridge. Use my SpeedBIOS. It does exactly that. 1 Quote Link to comment Share on other sites More sharing options...
PacManPlus Posted April 20, 2021 Share Posted April 20, 2021 Ha. I was going to ask how the PAL BIOS works, since it is 16K and contains Asteroids when no cart is inserted... But at that time there was no CCII Does anyone that has a PAL unit and the Asteroids BIOS run into issues with their CCII? @CPUWIZ - Good Idea... I'll give that a try. Quote Link to comment Share on other sites More sharing options...
PacManPlus Posted April 20, 2021 Share Posted April 20, 2021 Also, just so you are aware of what we are doing, the BIOS part of this ROM ranges from the addresses $E000 to $FFFF, with $E000 to $F800 containing the graphic definitions for the fuji. The game that I am adding will be from $C000 to $DFFF. Right now it's blank. Quote Link to comment Share on other sites More sharing options...
PacManPlus Posted April 26, 2021 Share Posted April 26, 2021 Good News... RevEng and I got the BIOS working with the CCII, Dragonfly, Concerto, and Harmony... and a bunch of 2600 games that I tested (including the ARM games). We need to do more testing as I have no non-multi 7800 carts (other than for the games I've done), but I'm going to continue working on my 'built-in' game now. 6 Quote Link to comment Share on other sites More sharing options...
+sramirez2008 Posted April 26, 2021 Share Posted April 26, 2021 11 minutes ago, PacManPlus said: Good News... RevEng and I got the BIOS working with the CCII, Dragonfly, Concerto, and Harmony... and a bunch of 2600 games that I tested (including the ARM games). We need to do more testing as I have no non-multi 7800 carts (other than for the games I've done), but I'm going to continue working on my 'built-in' game now. This is great news! Especially the part about continuing to work on your 'built-in' game.? 1 Quote Link to comment Share on other sites More sharing options...
TailChao Posted April 27, 2021 Share Posted April 27, 2021 Can either of you share what was causing the issue, assuming it was the cartridges doing something rude? Gotta keep all the compatibility quirks documented! 1 Quote Link to comment Share on other sites More sharing options...
RevEng Posted April 27, 2021 Share Posted April 27, 2021 Pretty sure that from the cart's perspective, A12 being forced low (via U4) made access to $1800-$1FFF look like access to $800-$FFF. The CC2 likely has an undocumented mapping or hotspot in that range. Avoiding $1800-$1FFF seems to have done the trick. 3 Quote Link to comment Share on other sites More sharing options...
TailChao Posted April 28, 2021 Share Posted April 28, 2021 14 hours ago, RevEng said: Pretty sure that from the cart's perspective, A12 being forced low (via U4) made access to $1800-$1FFF look like access to $800-$FFF. The CC2 likely has an undocumented mapping or hotspot in that range. Avoiding $1800-$1FFF seems to have done the trick. Good to confirm it, thanks - so I guess we're definitely stuck with a heavily segmented RAM / ROM space during cartridge detection. I wonder what the CC2 has stuffed in the $0800 - $0FFF range... 1 Quote Link to comment Share on other sites More sharing options...
RevEng Posted April 28, 2021 Share Posted April 28, 2021 You're welcome. I found an old doc (attached) that clears up the mystery a bit too. Quote 2K used for storing user settings: Located from $800-$FFF if NVRAM_EN & fpga_req & csiop_cs We likely gave it some impossible settings, which messed up the menu. Odd the messed-up menu didn't persist, as this is battery backed ram, but maybe it detects bad settings and re-inits for the next run. Or maybe Bob's battery isn't doing the job. CC2-techdocs.txt 3 Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.