Some 32X cart port questions
Moderator: BigEvilCorporation
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
Some 32X cart port questions
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.
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.
-
- Very interested
- Posts: 292
- Joined: Sat Apr 21, 2007 1:14 am
Re: Some 32X cart port questions
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.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.
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. :\
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
Re: Some 32X cart port questions
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.Charles MacDonald wrote: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.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.
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?
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.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. :\
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 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.
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.
-
- Very interested
- Posts: 2440
- Joined: Tue Dec 05, 2006 1:37 pm
- Location: Estonia, Rapla City
- Contact:
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...
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
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
-
- Very interested
- Posts: 292
- Joined: Sat Apr 21, 2007 1:14 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+).
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.
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
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.
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.
-
- Very interested
- Posts: 292
- Joined: Sat Apr 21, 2007 1:14 am
Oops, all errors have now been fixed! Thanks for pointing that out.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.
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 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.
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.
-
- Very interested
- Posts: 292
- Joined: Sat Apr 21, 2007 1:14 am
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 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?
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. Something to try someday.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.
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
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.Charles MacDonald wrote: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 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?
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. Something to try someday.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.
You mean that CART MODE bit in the TV control register? That's actually a good thought. I see a test bin coming...
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
-
- Very interested
- Posts: 292
- Joined: Sat Apr 21, 2007 1:14 am