SpritesMind.Net

I have read here that B31 (#TIME) line is active (low) on accesses to 0xA13000 -> 0xA130FF range. Is this true?

Could I wire this #TIME line to a battery backed 256 byte SRAM chip #CE signal, and use it to save/load games without conflicting with the ROM chips? (of course also A1~A8, D0~D7 and #LDSW would be wired to the SRAM chip).

If true, should I also wire to the SRAM the #C_OE (B16) line too? Or is this line only active on 000000~3FFFFF accesses?

doragasu wrote:Could I wire this #TIME line to a battery backed 256 byte SRAM chip #CE signal, and use it to save/load games without conflicting with the ROM chips?

Yes.

doragasu wrote:If true, should I also wire to the SRAM the #C_OE (B16) line too?

No.

Also, it's only 128 bytes if you only use /LWR and D0-D7. Only A1-A7 can be used, not A8 since /TIME is not asserted for $A131xx.

Couldn't you use that as A0, though? IIRC this is how Z80 RAM gets mapped (at the expense of requiring all accesses to be 8-bit).

Sik wrote:Couldn't you use that as A0, though?

Use what ?

Sik wrote: IIRC this is how Z80 RAM gets mapped (at the expense of requiring all accesses to be 8-bit).

AFAIK, Z80 A0 is asserted by the bus arbiter based on the /LDS and /UDS signals from 68k.
These signals are not available on the cartridge port, only /LWR and /UWR which are only asserted for writes.
For reading 256 bytes, you need 16-bit SRAM and use D0-D15.

Thanks for the replies!

Just to complete the topic, is there detailed information about the timing of this signal? Is it asserted the same time as e.g. #C_CE?

I have another question about mapping things using #TIME signal.

Do I have to assert the #DTACK signal for data reads? IFAIK this is not needed for logic mapped under the first 32 Mib address range, but I was wondering if I'll experiment a hardware lock or any other undesired effect if reading from #TIME address range without generating a valid #DTACK.

!DTACK is generated in the !TIME range. You can only generate !DTACK for the machine in 8...10MByte range (like 32X does). Rest of the range is handled by the VDP already.

Thanks!

I just wanted to make sure.

I was wondering if #TIME signal behaves exactly like a #CE or has other behaviour that justifies its weird name, so I wired a cheap 8 Channel, 24 MHz logic analyzer and soldered some wires. Then made a program that continuously reads 0xA13CA. I was surprised by the result, to the point that I'm wondering if I made a mistake on the wiring:



The first read in the #TIME range looks OK, but for the second read, #OE signal is not lowered... is this OK? Why?

I have changed the program to write to 0xA130CE, and then read from the same address to a variable, and... mystery solved!:



I was wrongly assuming that when writing to even addresses, #LDSW was active, but it is #UDSW line the one that is lowered! In the upper capture can be seen a write to #TIME range, then a write to internal RAM (I presume) and then a read to #TIME range, and this is repeated forever. Looks good to me, and it looks like #TIME signal behaves like a normal #CE signal

doragasu wrote:it looks like #TIME signal behaves like a normal #CE signal

And why it shouldn't?

It's just the weird name that made me suspect... Why is it called #TIME and not something like #CEX?

doragasu wrote:It's just the weird name that made me suspect... Why is it called #TIME and not something like #CEX?

Because it is select some timer, I guess. Maybe some add-on. In fact, it is !CS for $A130xx region.

One of the theories is that they may have planned for some early software to include a RTC that would be accessed through this port (hence "time", since it's related to time keeping). Given how early on Sega insisted on treating the console like a computer as well (at least when the modem was involved), I wouldn't be surprised.