Jump to content
IGNORED

sd cartridge for 7800?


metzger130

Recommended Posts

33 minutes ago, batari said:

The problem is that I used RIOT RAM heavily, thinking it was OK because the 7800 BIOS itself uses it, but testing has shown it to be unreliable, and there is no way to make it reliable.

That's a fascinating discovery to me. Is there a particular technical reason why that is? I am no 7800 coder that's for sure, but I seem to recall from thumbing through the official Atari developer docs on Curt's website that the system clock changes whenever TIA or RIOT is accessed, basically throttling down to the speed of a 2600 at 1.19 MHz, then jumping back up to the usual 1.79 MHz otherwise. When I was playing around with my oscilloscope after I put a UAV into my daily-driver 7800, I could clearly see these clock speed changes. 

Link to comment
Share on other sites

21 minutes ago, DrVenkman said:

That's a fascinating discovery to me. Is there a particular technical reason why that is? I am no 7800 coder that's for sure, but I seem to recall from thumbing through the official Atari developer docs on Curt's website that the system clock changes whenever TIA or RIOT is accessed, basically throttling down to the speed of a 2600 at 1.19 MHz, then jumping back up to the usual 1.79 MHz otherwise. When I was playing around with my oscilloscope after I put a UAV into my daily-driver 7800, I could clearly see these clock speed changes. 

I don't know but have guesses. RevEng has been very helpful with this, and he determined that no matter *what* you do with RIOT RAM, there is no way to make it work 100%. DMA on or off, it doesn't matter.

 

He has a logic analyzer and we could also see the clock speed changes, and we measured a bunch of things and found them all within spec, so it is still a mystery why RIOT RAM access is unreliable, but we can confirm with no doubt that it is. At the same time, for scientific completeness, we found *no* issues with 7800 RAM.

 

If I had to guess, I would say that the problem could be related to the two clock domains. The 7800 clock is 14.318 Mhz so 1.79 divides by 8, and 1.19 divides by 12. The two clocks only line up every six 7800 cycles, or four 2600 cycles, so depending on when the transition happens, there need to be six different transition cases, and one of these could have a problem that hasn't been identified yet.

  • Like 7
Link to comment
Share on other sites

11 hours ago, batari said:

I don't know but have guesses. RevEng has been very helpful with this, and he determined that no matter *what* you do with RIOT RAM, there is no way to make it work 100%. DMA on or off, it doesn't matter.

I'm not entirely surprised by this, as components from this era aren't always tolerant of having their clock changed. If you're going for completeness, it might be worth investigating if different manufacturer's implementations exhibit different behaviors. But yeah, in this case the manual's warning is correct - RIOT's RAM isn't stable.

 

Once you do enable DMA - Maria's fetches aren't PHI2 aligned which is definitely out of RIOT's spec. Having Maria read graphic data from RIOT's SRAM gets your some pretty chaotic textures.

  • Like 4
Link to comment
Share on other sites

On 8/18/2020 at 8:43 AM, TailChao said:

I'm not entirely surprised by this, as components from this era aren't always tolerant of having their clock changed. If you're going for completeness, it might be worth investigating if different manufacturer's implementations exhibit different behaviors. But yeah, in this case the manual's warning is correct - RIOT's RAM isn't stable.

I'd love to see if the 2MHz flavour of the 6532 is affected similarly, though I suspect it will be...

 

There seems to be a couple failure modes at play, with one factor being DMA on/off, and another being how you're accessing the memory. With DMA off, absolute, absolute indexed, and indirect y-indexed, are actually fine on my unit. The bios sets up RIOT RAM for 2600 mode this way, so it's probably fine on most other units, or else there would be periodic problems when switching into 2600 mode for 2600 games. When DMA is on, failures in these modes always seem to involve DMA switching on mid or post instruction. (DMA interruption was my original hypothesis for the RIOT RAM failures)

 

Execution from RIOT RAM in 7800 mode blows things up completely, and Maria's internal state goes off-track - I was able to capture one of these melt downs in the logic analyser, and Maria both halted for DMA and enabled RW at the same time.

 

I didn't bother sending Maria to the RIOT RAM for graphics, since the clock is way out of spec, but your result sounds fun.

 

In semi-related news, the RIOT timers are actually pretty usable, provided you check the value immediately after setting and repeat if necessary. (with the obvious caveat that each TIA and RIOT access during the timer period will stall the timer by 0.5 cycles.) Reads to check the timer (absolute) never fail on my unit, even with my heavy+variable DMA test program.

  • Like 5
Link to comment
Share on other sites

2 hours ago, RevEng said:

I'd love to see if the 2MHz flavour of the 6532 is affected similarly, though I suspect it will be...

Only one way to find out!

 

 

2 hours ago, RevEng said:

When DMA is on, failures in these modes always seem to involve DMA switching on mid or post instruction. (DMA interruption was my original hypothesis for the RIOT RAM failures)...

This is where you really have to be careful in designing a mapper or bus arbiter or whatever. I'm curious as to what's going on with Maria's chipselect signals here as she's the one enabling RIOT and any stuttering while she's capturing the bus could gunk up a pending write. The timing requirements for accessing the R and IOT portions of RIOT might differ, too.

 

On the note of designing cartridges, we observed a lot of variance in PHI2 integrity from unit to unit - especially on the PAL boards. Some were extremely sensitive to how the signal was routed, which is why Rikki & Vikki's PCB has a nice thick trace which runs directly to the mapper and that's it.

 

 

2 hours ago, RevEng said:

I didn't bother sending Maria to the RIOT RAM for graphics, since the clock is way out of spec, but your result sounds fun.

It's not always fun, but was left in our hidden Maria Diagnostic feature for easy access...

 

m_diagnostic.thumb.gif.2c52cf7d2c14b0c584b035c4555e6767.gif

 

...here the RIOT's RAM is pretty dead, with a bit of gunk on the start of every 64px segment from Maria parsing DLs elsewhere - but the IO and Timer are still readable this far out of spec.

 

 

2 hours ago, RevEng said:

In semi-related news, the RIOT timers are actually pretty usable, provided you check the value immediately after setting and repeat if necessary. (with the obvious caveat that each TIA and RIOT access during the timer period will stall the timer by 0.5 cycles.) Reads to check the timer (absolute) never fail on my unit, even with my heavy+variable DMA test program.

Yeah, I've observed similar - and if there were any timer stability issues they would have manifested in Beef Drop since it uses them. In any case I'd recommend sticking with only the IO of RIOT's feature set for 7800 software... unless the point of said software is reverse engineering ;)

  • Like 5
Link to comment
Share on other sites

13 minutes ago, TailChao said:

here the RIOT's RAM is pretty dead, with a bit of gunk on the start of every 64px segment from Maria parsing DLs elsewhere - but the IO and Timer are still readable this far out of spec.

 

 

Yeah, I've observed similar - and if there were any timer stability issues they would have manifested in Beef Drop since it uses them. In any case I'd recommend sticking with only the IO of RIOT's feature set for 7800 software... unless the point of said software is reverse engineering ;)

Wow, the IO and timer being readable at Maria speeds is fascinating!

 

On Beef Drop... it's not always foolproof to go by one or two previous homebrew releases. 7800 aficionados will have problems that go unreported, because they assume it's just a problem with their specific 7800.

  • Like 2
Link to comment
Share on other sites

4 hours ago, TailChao said:

I'm not entirely surprised by this, as components from this era aren't always tolerant of having their clock changed. If you're going for completeness, it might be worth investigating if different manufacturer's implementations exhibit different behaviors. But yeah, in this case the manual's warning is correct - RIOT's RAM isn't stable.

 

Once you do enable DMA - Maria's fetches aren't PHI2 aligned which is definitely out of RIOT's spec. Having Maria read graphic data from RIOT's SRAM gets your some pretty chaotic textures.

The programming docs said "don't use" RIOT RAM because it may not be available in future versions of the MARIA chip, which we know now isn't true, and the 7800 BIOS itself uses RIOT RAM for executing code (for booting a 2600 game). So with this I figured it was safe, so I used it for booting all games (and for many other things.) If it said RIOT RAM is unstable, I missed that part. That said, I probably do still need to use RIOT RAM for booting 2600 games in a similar manner as the BIOS does, but I will keep its use to an absolute minimum.

  • Like 2
Link to comment
Share on other sites

30 minutes ago, RevEng said:

Wow, the IO and timer being readable at Maria speeds is fascinating!

The registers are yielding data, but if you look closely the reads appear to be shifted one fetch late - so it's still taking awhile for the RIOT to catch up to Maria's strobes. Although I wouldn't have expected this to work at all from the datasheet. It's quite possible PHI2 aligns closely enough to Maria's fetches for the RIOT to latch some of the addresses, or the actual silicon isn't doing exactly what the manual says.

 

 

Quote

On Beef Drop... it's not always foolproof to go by one or two previous homebrew releases. 7800 aficionados will have problems that go unreported, because they assume it's just a problem with their specific 7800.

Agreed, but if any strange behavior gets (or was) reported - that's data.

 

 

7 minutes ago, batari said:

The programming docs said "don't use" RIOT RAM because it may not be available in future versions of the MARIA chip, which we know now isn't true, and the 7800 BIOS itself uses RIOT RAM for executing code (for booting a 2600 game). So with this I figured it was safe, so I used it for booting all games (and for many other things.) If it said RIOT RAM is unstable, I missed that part. That said, I probably do still need to use RIOT RAM for booting 2600 games in a similar manner as the BIOS does, but I will keep its use to an absolute minimum.

The manual also states it was moved off the zeropage "...because of speed discrepancy with the 6532..." which, along with the all caps DON'T USE text, felt very much like "here be dragons". I am curious though, have all these tests been with Maria enabled / MEN (INPTCTRL,1) set? RIOT shouldn't give any fuss with Maria's features disabled, since that is 2600 compatibility mode and should use safe timings.

  • Like 1
Link to comment
Share on other sites

So I finally got around to testing my 3 systems.  2 stock, on with s-video/composite mod.  2 of the 3 seemed to pass the tests fine.  One of the stock ones had some issues, here are some screenshots.  Let me know if there is anything else I can do.  The Ikari warrior picture is to show it plays games fine off of a cart.

a78-2.thumb.jpg.a83d8ba6df0e67fa5b0459638c1538d0.jpga78-3.thumb.jpg.6c9498e9d78635b982995388a2bc77fa.jpga78-4.thumb.jpg.b4977d07e049e3659e068f0108eaaba5.jpga78-5.thumb.jpg.e5abc203a3aa8d3523ee1d1b07536f1b.jpga78-1.thumb.jpg.46c766301d8279b1e4541221917bc396.jpg

  • Like 3
Link to comment
Share on other sites

Thanks for testing

On 8/23/2020 at 11:58 AM, evg2000 said:

So I finally got around to testing my 3 systems.  2 stock, on with s-video/composite mod.  2 of the 3 seemed to pass the tests fine.  One of the stock ones had some issues, here are some screenshots.  Let me know if there is anything else I can do.  The Ikari warrior picture is to show it plays games fine off of a cart.

a78-2.thumb.jpg.a83d8ba6df0e67fa5b0459638c1538d0.jpga78-3.thumb.jpg.6c9498e9d78635b982995388a2bc77fa.jpga78-4.thumb.jpg.b4977d07e049e3659e068f0108eaaba5.jpga78-5.thumb.jpg.e5abc203a3aa8d3523ee1d1b07536f1b.jpga78-1.thumb.jpg.46c766301d8279b1e4541221917bc396.jpg

Thanks for testing! Glad yours also shows the error, as this will help toward a fix.

  • Like 1
Link to comment
Share on other sites

I just noticed...but why are the checksums for the BIOS blank? I suspect due to the diagnostics not knowing the BIOS type, but why can't it? I also hadn't realized you had added RAM to it to double as a RAM cart? Interesting...

 

Link to comment
Share on other sites

I got Mitch's problem console today.

 

Only problem is, it works 100% perfectly. All green in the integrity test, under all of the test BIOSes I posted.

 

The problem may not entirely be the consoles at all, but maybe there is something that is also different about some of the Concertos that got out there.

 

I will keep testing and see if anything else becomes obvious, or if I am able to repeat the issue somehow.

Link to comment
Share on other sites

I'll post the latest test BIOS anyway, which eliminates RIOT RAM wherever possible. It isn't complete and only changes the menu, not the splash screen. It may cause loading of 2600 games to fail, as RIOT RAM use needs to be put back in just for booting 2600 games and this hasn't been done yet. This is only intended for those getting integrity errors on the diagnostic utility, and the only intended purpose for this BIOS is to see if these errors go away.

 

 

 

 

concerto_test5.cbi

  • Like 3
Link to comment
Share on other sites

This has probably been answered, but is there anything I can do to make the Concerto more stable related to initializing?  It boots up about 20% of the time.  I can get it to boot up, but I have to power off and on several times.

 

I tried this latest BIOS.  Works OK for me if I can get the cart to boot.  Is there any particular game you want me to test, etc.?

Link to comment
Share on other sites

Just now, KylJoy said:

This has probably been answered, but is there anything I can do to make the Concerto more stable related to initializing?  It boots up about 20% of the time.  I can get it to boot up, but I have to power off and on several times.

 

I tried this latest BIOS.  Works OK for me if I can get the cart to boot.  Is there any particular game you want me to test, etc.?

That is similar to what I experienced with the latest firmware. Getting it to boot to the menu was the hardest part.

 

Mitch

Link to comment
Share on other sites

 

Just now, Mitch said:

That is similar to what I experienced with the latest firmware. Getting it to boot to the menu was the hardest part.

 

Mitch

 

My Concerto always acts this way no matter which BIOS I'm using.

Link to comment
Share on other sites

1 hour ago, -^CrossBow^- said:

I also hadn't realized you had added RAM to it to double as a RAM cart? Interesting...

 

Is this addressed towards me?  I haven't added anything, this is a stock console.  Or is this addressed to batari?

 

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...