Jump to content
Trebor

A Non-Interactive Title Screen is a Safe Screen

Recommended Posts

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 :)

  • Like 3

Share this post


Link to post
Share on other sites
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.

  • Like 3

Share this post


Link to post
Share on other sites

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

  • Like 2

Share this post


Link to post
Share on other sites
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. :)

 

 

unnamed.jpg

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.

 

 

20210411_173111.jpg

  • Like 3

Share this post


Link to post
Share on other sites

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 by PacManPlus

Share this post


Link to post
Share on other sites

Ok, being that we cannot get past this last issue, this custom BIOS is put on hold indefinitely until a resolution is found.

Edited by PacManPlus

Share this post


Link to post
Share on other sites
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.

 

  • Like 1

Share this post


Link to post
Share on other sites

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 by PacManPlus

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

  • Like 4

Share this post


Link to post
Share on other sites

 

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.

Share this post


Link to post
Share on other sites
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.

  • Like 1

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites
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.

  • Like 1

Share this post


Link to post
Share on other sites
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.

  • Like 1

Share this post


Link to post
Share on other sites
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.

  • Like 1

Share this post


Link to post
Share on other sites

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 :P

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.

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

 

:D

  • Like 6

Share this post


Link to post
Share on other sites
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.

 

:D

This is great news!  Especially the part about continuing to work on your 'built-in' game.😊

  • Like 1

Share this post


Link to post
Share on other sites

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!

  • Like 1

Share this post


Link to post
Share on other sites

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.

  • Like 3

Share this post


Link to post
Share on other sites
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...

  • Like 1

Share this post


Link to post
Share on other sites

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

  • Like 3

Share this post


Link to post
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...