Expansion port signals

[Charles MacDonald]

Been looking at the expansion port, tests done with the /CART pin grounded. (with corrections from Jorge Nuno)

/ROM is asserted when reading/writing $400000-$5FFFFF.

The Sega CD uses it as an output-enable strobe for the boot ROM, but it is a general chip select for any kind of access like /FDC.

/RAS2 is asserted when reading/writing $600000-$7FFFFF.

/ASEL is asserted when reading/writing $000000-$7FFFFF.

/FDC is asserted when reading/writing $A12000-$A120FF.

/FDWR is asserted when writing $A12000-$A120FF. Valid for word writes and byte writes to even and odd addresses. The pulse width is exactly one CPU clock wide (130ns), synchronous with the falling edge of /LWR or /UWR. Not sure what the point of having a narrow write pulse might be.

In addition, /RAS2 is pulsed for 130ns every 16.9us. On the cycles where it is asserted, /DTACK is also used to delay the 68000 by 2 cycles, for 6 total (780ns).

For other signals during a normal memory access without wait states:

/DTACK is asserted 115ns after /AS
/ASEL is asserted 120ns after /AS
/CAS2 is asserted 195ns after /AS

For DRAM on the expansion port you use either /ROM or /RAS2 for DRAM RAS, ASEL to select the row/column, and /CAS2 as DRAM CAS.
/RAS2 provides periodic refresh cycles but /ROM does not.


Some details on DMA timing for /ROM area CRAM transfers (updated):

Only /ASEL, /CAS0, /CAS2, /ROM convey any information about the transfer. During this time all other signals are negated. /ROM is held low throughout back to back reads, and is pulsed normally for the intermittent refresh cycles. Here's a picture of a read cycle, which is 300ns total (from the rising edge of /ASEL to /ASEL):



During a read cycle, the signal relationships are:
/CAS0 asserted 15ns after /ASEL (A to B)
/CAS2 asserted 45ns after /ASEL (A to C)
/ASEL pulse width is 175ns (A to E)
/CAS0 pulse width is 150ns (B to D)
/CAS2 pulse width is 135ns (C to F)

Supposing an EPROM was connected to the bus with CE=/ROM and OE=/CAS0, it would have an access time faster than 165ns if you assume the address is valid at the falling edge of /ASEL and valid data must be present on the data bus during the rising edge of /CAS0. This seems pretty short though, and implies the address decoder could complete in 15ns too.

It looks like the Sega CD BIOS has an access time of 150ns exactly. I wonder if DMA from the ROM is reliable or not?

During DMA refresh cycles on /RAS2, /ASEL, and /CAS2 are still present.

[Jorge Nuno]

For the address selection (which is what the ASEL is probably meant for judging by the name it bears) the RAS signal can be used most of the times to select the row/column of an external mux:
Since drams typically need a row address hold time of about 10ns (or sometimes less), we can take advantage of the propagation delay of the mux ICs, which take more than 10ns to change the addresses into columns.

Using RAS2 as a RAS refresh may make sense at first but.. the DRAM needs the addresses which you want to refresh, the rows should be incrementing, which I doubt the MD provides . The only way not to was to make a CAS-before-RAS or a hidden refresh cycle in which the row address is generated internally on the dram.


This is coming from someone who made a dram cart for the MD :V but not quite like this, it is presented to the MD as it were a pure async ROM, just taking CE_0, CAS0, addresses and data lines (obviously has onboard clocking, sync stages and a parallel port loader)

[Charles MacDonald]

For the address selection (which is what the ASEL is probably meant for judging by the name it bears) the RAS signal can be used most of the times to select the row/column of an external mux:
Since drams typically need a row address hold time of about 10ns (or sometimes less), we can take advantage of the propagation delay of the mux ICs, which take more than 10ns to change the addresses into columns.

Aha! You're absolutely right about the signal relationships, I've checked again and they look like this:

/AS goes low first
/RAS2 or /ROM follows ~30ns later
/ASEL follows ~90ns after /RAS
/CAS2 follows ~75ns after /SEL

I guess it seems obvious what /ASEL is named for, but I didn't realize it.

I've noticed the periodic refresh is only present on /RAS2 and not /ROM. The refresh rate increases during DMA too (about 9us instead of 16us).

Using RAS2 as a RAS refresh may make sense at first but.. the DRAM needs the addresses which you want to refresh, the rows should be incrementing, which I doubt the MD provides . The only way not to was to make a CAS-before-RAS or a hidden refresh cycle in which the row address is generated internally on the dram.

I see what you mean. It looks like during the refresh cycle /RAS2 is held high while /ASEL, then /CAS2 are asserted. They are held low for two CPU clocks, then /RAS2 goes low for one cycle, then all signals are negated. So you are getting the /CAS2 assertion before /RAS2.

Does that mean DRAMs that support CAS-before-RAS refresh can be more or less directly connected to the expansion port ? I'm curious what other kind of logic was needed, if any.

Thanks a lot for your insight on this!

[Jorge Nuno]

That's the order of a CBR cycle. Then yes you can connect them directly, just need a bunch of 74HC157s to mux those address lines with S connected to RAS or to ASEL, designer's choice

Too bad it's only from 0x600000+ but ehh, can't have everything...
Speaking of which, the cart slot should have identical behaviour on it's corresponding signals (CE_0, ASEL, CAS2) hum...

I think on dma the refresh pulses are synchronous with vram ones, since the governing mem acessing clock is now the pixel clock, and having refreshes elsewhere would disrupt some of the transfers

[Jorge Nuno]

Wait, you're saying that the DMA transfers are in sync with VClk? doesn't make sense to me as they seem to pulse at 150/300ns...

These are Cart slot /CAS0 (yellow) and /CE_0 (blue)



Notice the access cycle time is about 300ns, which would give a running clock of about 6.67MHz using a cycle for reading and another for writing. This makes sense if it's the pixel clock


For every 30 accesses there's a refresh pulse on the VDP, meaning no access.

Notice /CE_0 is stuck low for the entire transfer block much like /ROM is.

Sorry for the HUGE pics though

[Charles MacDonald]

Wait, you're saying that the DMA transfers are in sync with VClk? doesn't make sense to me as they seem to pulse at 150/300ns...

Ack, I had the wrong sampling mode (CPU clock instead of free running 500 MHz clock) selected on the logic analyzer. Thanks for pointing this out. I'll make a correction in a few days when I can test again.

I'm working on a project for the expansion port, hence all this signal and timing data. But it's no use if it's incorrect!

[HardWareMan]

I'm in. I can make some pictures too, if you want.

[Mask of Destiny]

I can confirm that bus operations during DMA are driven off the VDP's internal clock. It will do one read for every 4 ticks of SC (so one per access-slot) as long as there is room in the FIFO. For DMA to VRAM, you'll only see half that rate once the FIFO is full as the VDP takes two slots to retire a full word from the FIFO since VRAM is only byte wide. When the display is off, there's a VRAM refresh cycle every 32-slots (128 SC cycles) with a slightly longer period (40 slots I think) between the last refresh cycle of the line and the first of the next line. When the VDP does its refresh cycle, it misses two reads. So you get 30 slots of reads and then 2 slots without. That was measured on the cartridge port reads, but it seems to jive with Jorge Nuno's measurements. I can post a logic analyzer capture when I get home if it would be helpful.

[Charles MacDonald]

Just made some corrections!