Alt-RAM logic brain fart

[Badwolf]

Hi guys,

I seem to be having a brain fade getting my AltRAM to work.

Here's the setup:

* Falcon with external 68030 processor running EmuTOS.
* Two 1MB 8-bit SRAM chips sitting as high-and-low bytes wired D31-D24 and D23-D16.
* /DSACK1 toggled low to terminate bus cycle, /DSACK0 held high throughout to indicate 16 bit bus.
* Logic responds to the TT-RAM position. 0x1000000-0x11FFFFF.

Boots up fine without the AltRAM registered. Writing and reading to the SRAM with my little test program seems fine at the byte and word level.

I register the memory with Maddalt(), then this happens:-

IMG_3823.jpeg

Concentrating on the text on the icons, they should read " DISK A ", " DISC C ", etc. So it looks like only every other byte is being returned (or written?), but again -- my test program seems to work.

I've tried slowing down DSACK, enforcing a longer delay between consecutive cycles (an obvious one with a long-word read returning the first cycle results again, I thought), to no avail.

This is clearly going to be a real head-smackingly obvious schoolboy logic error, but I've been staring at this two days without progress. Can anyone tell me what I'm missing?

Thanks,

BW.

[frank.lukas]

... should the fastram 32bit?

Mighty_Sonic_32_oben.jpg

[Badwolf]

The 030 has dynamic data bus sizing. If I’d wired it up appropriately it should even work with 8 bit!

/DSACK0 = 1
/DSACK1 = 0

Signals a 16 bit bus, as I understand it.

BW.

[frank.lukas]

I not now but over 16MB all Ram is 32bit (Atari TT, CT6x, 030 Speeder with Fastram ...) for TOS ?

[exxos]

Doesn't emutos register the ram by itself ?

[Badwolf]

I not now but over 16MB all Ram is 32bit (Atari TT, CT6x, 030 Speeder with Fastram ...) for TOS ?

Is that a CPU requirement I've missed? I can't see how TOS would know or be able to enforce that.

If TOS asks for a longword, I thought it was down to the CPU to perform cycles until it fulfils the request.

BW

[Badwolf]

Doesn't emutos register the ram by itself ?

No. Probably as a result of my bug.

Interestingly my tester, Stephen's hacked Magnum software and YAART TT all report my RAM is fine, but EmuTOS does not like it at all.

I need to write a more complicated tester (and check that there's not an implicit 32 bit assumption above 0x1000000 like Franck suggests), I think.

BW.

[czietz]

I think Frank is wrong here. Every address can be also accessed as a 16-bit wide port by settings /DSACKn accordingly, like you do.

However, 68030 dynamic bus sizing is quite complicated. Did you implement all the cases for the combinations of of SIZ1, SIZ0, and A0 as described by 68030UM? In particular the combinations where you also have to provide the previous/next byte in memory for byte-sized accesses?

[Badwolf]

However, 68030 dynamic bus sizing is quite complicated. Did you implement all the cases for the combinations of of SIZ1, SIZ0, and A0 as described by 68030UM? In particular the combinations where you also have to provide the previous/next byte in memory for byte-sized accesses?

I'll have to re-read it, thanks. My understanding was with a fixed 16 bit bus you always answer as 16 bit, otherwise if you're reading a single byte from the lower data bit size the data will end up on the wrong data lines.

I've used a 16 bit port to keep it the same as the Falcon's bus for now so I'm using the same logic for UDS, LDS and DSACK[0:1].

Here's an example of me writing a word and reading it back byte-wise; plus a word-misaligned write and read back. These seem OK, but perhaps there's a combination I'm missing -- or it's timing.

BW.

IMG_3828.jpeg

[Badwolf]

I have a theory!

Laying in bed last night, re-reading section 7.2.1 of the 68030 user's manual (I'm rock and roll, me), I was contemplating the difference between read and write cycles. It hit me: what if I'd wired /CE and /OE backwards on the RAM chips such that I wasn't enabling the chips selectively, but just enabling their output selectively?

That would mean reads would be fine across the board, but misaligned or byte-level writes would clobber data previously written. Probably irrelevant to a memory tester, which tends to write something and read it back, but absolutely critical for real data.

Also, the way the dynamic port sizing works during a byte-level write is to duplicate the byte four times across the 32 bit data bus... or twice if I've a 16 bit port...

IMG_3823 19.56.40.jpeg

So quick check of the schematic this morning and, sure enough, I'm a Pilsbury Dough Boy:

Screenshot 2020-09-25 at 10.18.02.png

Time for some more trace breaking and bodging tonight. Let's hope that's all it was.

BW.