Some 32X cart port questions

Ask anything your want about the 32X Mushroom programming.

Moderator: BigEvilCorporation

Chilly Willy
Very interested
Posts: 2581
Joined: Fri Aug 17, 2007 9:33 pm

Some 32X cart port questions

Post by Chilly Willy » Thu Oct 04, 2012 5:01 pm

Tiido has been working on an SRAM cart for the 32X and ran into something strange... it seems like the SH2s don't generate a write signal to the cart space. I wrote a couple of test programs, and I cannot write to CD backup ram from the SH2, or save ram from the SH2. In both cases, the SH2 reads just fine, but doesn't even trash what is already in the ram. Tiido's test sram cart shows the same behavior.

Has anyone done any tests of the cart port when accessed from the SH2 side? If someone can check signals, I can provide any needed test code.

Charles MacDonald
Very interested
Posts: 283
Joined: Sat Apr 21, 2007 1:14 am

Re: Some 32X cart port questions

Post by Charles MacDonald » Fri Oct 05, 2012 4:49 pm

Chilly Willy wrote:Tiido has been working on an SRAM cart for the 32X and ran into something strange... it seems like the SH2s don't generate a write signal to the cart space. I wrote a couple of test programs, and I cannot write to CD backup ram from the SH2, or save ram from the SH2. In both cases, the SH2 reads just fine, but doesn't even trash what is already in the ram. Tiido's test sram cart shows the same behavior.

Has anyone done any tests of the cart port when accessed from the SH2 side? If someone can check signals, I can provide any needed test code.
This may be related: I found when the 32X adapter is enabled, 68000 writes to the TIME# area do not pulse /LWR. Likewise, the Sega CD RAM cart uses /LWR for the battery backed RAMs.

So perhaps SH-2 writes to the cartridge area don't allow /LWR to be enabled either? That might explain why the RAM couldn't be trashed, since the write strobe was never being asserted to begin with. What do you think?

I found CAS0#/CE0# worked normally with the adapter enabled (so reads are OK), and I have a hunch /UWR might be passed through. When you reset ADEN then all signals work normally.

I can analyze any of the cartridge signals, but my devcart has that fault with 32X ROM reads by the SH-2 being unreliable. I guess you'd have to increase the wait states or shuttle data from the 68000 to SH2 via the communication regs for me to be able to run any SH-2 code. :\

Chilly Willy
Very interested
Posts: 2581
Joined: Fri Aug 17, 2007 9:33 pm

Re: Some 32X cart port questions

Post by Chilly Willy » Fri Oct 05, 2012 5:57 pm

Charles MacDonald wrote:
Chilly Willy wrote:Tiido has been working on an SRAM cart for the 32X and ran into something strange... it seems like the SH2s don't generate a write signal to the cart space. I wrote a couple of test programs, and I cannot write to CD backup ram from the SH2, or save ram from the SH2. In both cases, the SH2 reads just fine, but doesn't even trash what is already in the ram. Tiido's test sram cart shows the same behavior.

Has anyone done any tests of the cart port when accessed from the SH2 side? If someone can check signals, I can provide any needed test code.
This may be related: I found when the 32X adapter is enabled, 68000 writes to the TIME# area do not pulse /LWR. Likewise, the Sega CD RAM cart uses /LWR for the battery backed RAMs.

So perhaps SH-2 writes to the cartridge area don't allow /LWR to be enabled either? That might explain why the RAM couldn't be trashed, since the write strobe was never being asserted to begin with. What do you think?
I think that it must assert /LWR while RV is set because you can write the sram just fine from the 68000 while the 32X is active, but you have to set RV. I also think maybe I should try writing a word and see if that does anything instead of writing a byte.
I found CAS0#/CE0# worked normally with the adapter enabled (so reads are OK), and I have a hunch /UWR might be passed through. When you reset ADEN then all signals work normally.

I can analyze any of the cartridge signals, but my devcart has that fault with 32X ROM reads by the SH-2 being unreliable. I guess you'd have to increase the wait states or shuttle data from the 68000 to SH2 via the communication regs for me to be able to run any SH-2 code. :\
Hmm - could you use a Myth flash cart? I've got three, so one generally only gets used when I'm testing backwards compatibility on menu updates.

Chilly Willy
Very interested
Posts: 2581
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Fri Oct 05, 2012 7:06 pm

I did some more testing - while the SH2 can read the sram as bytes, trying to read as words fails... you don't get any data at all. Writing as words seems to do nothing as well.

If I leave the psram write-enabled (the psram in the Myth is used as the "rom" when running MD/32X games), I can write to the psram on the MD side while the 32X is active, but (carefully) testing the writes shows the SH2 cannot write the psram.

So it currently looks like the SH2 doesn't generate write strobes to the cart space at all.

I had previously thought the SH2 could write the psram, but I'm guessing now I wasn't careful enough about the cache - write tests could pass if you aren't careful because the data could go into/come from the cache, making you think the write succeeded. I used an uncached volatile pointer this time, and flushed the cache for the line before reading the data back, and I get what the 68000 wrote, not what the SH2 tried to write.

User avatar
TmEE co.(TM)
Very interested
Posts: 2302
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Post by TmEE co.(TM) » Fri Oct 05, 2012 10:35 pm

I made any cart access not reads into writes so the SRAM should pick up the data bus even though !LWR or !UWR aren't active. Writes still don't work and since data did not get trashed I get the feeling the enable strobe is not pulsed on writes either.
I wish I had a logic analyser...
Mida sa loed ? Nagunii aru ei saa ;)
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen

Charles MacDonald
Very interested
Posts: 283
Joined: Sat Apr 21, 2007 1:14 am

Post by Charles MacDonald » Wed Oct 10, 2012 2:42 am

Here's what we found with regards to the write strobes and other signals on the 32X cartridge connector:

68000 access to cartridge area:

When RV=1: (This is the setting where SH-2 can't access cartridge space)

- LWR#, UWR#, TIME# function normally.

When RV=0: (This is the setting where the 68K and SH-2 share access)

- LWR# is always inactive. E.g. on a byte write to an odd address or a word write, LWR# remains high.

- UWR# and TIME# function normally.

Other comments:

When RV=0 you can't write to most cartridge save RAM or the Sega CD Backup RAM cartridge as they use LWR# to control RAM writes. The data can still be read.

When RV=0 any cartridge hardware cannot make a distinction between byte writes to even addresses and word writes as both assert UWR# exclusively.

SH-2 access to cartridge area:

In another set of tests we found that the SH-2s cannot write to the cartridge space (as before, RV=0). Specifically LWR#, UWR#, and TIME# are never asserted.

This makes the cartridge area effectively read-only for the SH-2s. In the case of various save RAMs; they are also read-only.

It also explains why only the 68000 can access the cartridge banking register (at $A130F1+).
Last edited by Charles MacDonald on Wed Oct 10, 2012 2:42 pm, edited 1 time in total.

Chilly Willy
Very interested
Posts: 2581
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Wed Oct 10, 2012 5:18 am

For the Other comments and SH2 access sections, you mean RV=0, not RV=1. When RV=1, the 68000 can do anything normally as mentioned in the first section, while the SH2 halts. So it's RV=0 where the limitations come in.

Also worth a mention is that without the CD attached, the 32X seems to be able to read up to 8MBytes of rom from the SH2 side. The addresses wrap at 8MB, so an access of 10MB actually accesses 2MB. With the CD attached, the CD area acts the same as with the MD: accessible at 0MB when there is no cart (with BRAM carts showing at 4MB), and accessible at 4MB when a cart is inserted.

Charles MacDonald
Very interested
Posts: 283
Joined: Sat Apr 21, 2007 1:14 am

Post by Charles MacDonald » Wed Oct 10, 2012 2:43 pm

Chilly Willy wrote:For the Other comments and SH2 access sections, you mean RV=0, not RV=1. When RV=1, the 68000 can do anything normally as mentioned in the first section, while the SH2 halts. So it's RV=0 where the limitations come in.
Oops, all errors have now been fixed! Thanks for pointing that out.

Chilly Willy
Very interested
Posts: 2581
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Wed Oct 10, 2012 7:08 pm

No problem. Looks good now.

SEGA seems to make strange choices on the hardware at times. We saw that with odd things about the Z80 hardware, like a serial bank register instead of parallel.

I don't understand why they screwed with the rom space, especially on the 68000 side... why is it normally mapped to 88xxxx-9xxxxx? Why not leave it at the original location? All it seems to do is add more useless hardware to handle bank selecting at the new location, and extra hardware to remap back to the original location AND halt the SH2s for VDP DMA operations. If they were concerned about the VDP halting the 68000 for DMA, they could have left the rom alone and just made the RV control whether the SH2 were halted for rom accesses or not. The rest of the hardware moving the rom around is a complete waste!

I can understand them not handling SH2 writes to the rom space... it's extra hardware, and they were worried about changing sram on both the 68k and sh2 sides at the same time. But that's a PROGRAMMER concern - they should have dropped the silly "let's move the rom around for no reason" hardware and used the gates for allowing sh2 writes. At that point it's up to the programmer to not do silly things like write on both sides at the same time.

Charles MacDonald
Very interested
Posts: 283
Joined: Sat Apr 21, 2007 1:14 am

Post by Charles MacDonald » Wed Oct 10, 2012 9:38 pm

I don't understand why they screwed with the rom space, especially on the 68000 side... why is it normally mapped to 88xxxx-9xxxxx? Why not leave it at the original location?
The only thing I can think of is that DTACK isn't auto-acknowledged in the $800000-$9FFFFF range, so they needed to use that region so that the 68000 could be momentarily delayed while giving the SH2 priority access to ROM. For addresses below $800000 the 68000 can't be stopped and would have priority instead of the SH2.
I can understand them not handling SH2 writes to the rom space... it's extra hardware, and they were worried about changing sram on both the 68k and sh2 sides at the same time.
It's probably a dead end but I was wondering if any other bits in the 32X control register that enable DRAM refresh on the cartridge port may do something else like enable writes. :D Something to try someday.

Chilly Willy
Very interested
Posts: 2581
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Wed Oct 10, 2012 10:26 pm

Charles MacDonald wrote:
I don't understand why they screwed with the rom space, especially on the 68000 side... why is it normally mapped to 88xxxx-9xxxxx? Why not leave it at the original location?
The only thing I can think of is that DTACK isn't auto-acknowledged in the $800000-$9FFFFF range, so they needed to use that region so that the 68000 could be momentarily delayed while giving the SH2 priority access to ROM. For addresses below $800000 the 68000 can't be stopped and would have priority instead of the SH2.
AH! That makes sense... otherwise the 68000 would have priority, slowing the SH2s even more. Unless you were smart enough to put the 68000 main loop in work ram like I do. :wink: :lol:
I can understand them not handling SH2 writes to the rom space... it's extra hardware, and they were worried about changing sram on both the 68k and sh2 sides at the same time.
It's probably a dead end but I was wondering if any other bits in the 32X control register that enable DRAM refresh on the cartridge port may do something else like enable writes. :D Something to try someday.


You mean that CART MODE bit in the TV control register? That's actually a good thought. I see a test bin coming...
:D

notaz
Very interested
Posts: 176
Joined: Mon Feb 04, 2008 11:58 pm
Location: Lithuania

Post by notaz » Fri Oct 12, 2012 3:38 pm

IIRC there is also bunch of registers in the SH2s themselves that affect how SH2s access the memory and the timings. Messing with those might affect all this too.

Chilly Willy
Very interested
Posts: 2581
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Mon Oct 15, 2012 6:38 pm

notaz wrote:IIRC there is also bunch of registers in the SH2s themselves that affect how SH2s access the memory and the timings. Messing with those might affect all this too.
That was the first thing I checked... there's no reason the SH2 cannot write the space given the bus controller settings.

Chilly Willy
Very interested
Posts: 2581
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Fri Oct 19, 2012 5:26 am

I tried setting the CART MODE bit in the test if the SH2 can write save ram... it makes no difference. The SRAM is unchanged.

Charles MacDonald
Very interested
Posts: 283
Joined: Sat Apr 21, 2007 1:14 am

Post by Charles MacDonald » Fri Oct 19, 2012 7:02 am

Chilly Willy wrote:I tried setting the CART MODE bit in the test if the SH2 can write save ram... it makes no difference. The SRAM is unchanged.
I don't suppose turning on all the unused bits in that register will do anything? Probably make the system freeze up, though. :)

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest