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:-
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.
Alt-RAM logic brain fart
Alt-RAM logic brain fart
DFB1 Open source 50MHz 030 and TT-RAM accelerator for the Falcon
DSTB1 Open source 16Mhz 68k and AltRAM accelerator for the ST
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark
DSTB1 Open source 16Mhz 68k and AltRAM accelerator for the ST
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark
- frank.lukas
- Posts: 663
- Joined: Fri Jan 19, 2018 11:52 am
Re: Alt-RAM logic brain fart
... should the fastram 32bit?
Re: Alt-RAM logic brain fart
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.
/DSACK0 = 1
/DSACK1 = 0
Signals a 16 bit bus, as I understand it.
BW.
DFB1 Open source 50MHz 030 and TT-RAM accelerator for the Falcon
DSTB1 Open source 16Mhz 68k and AltRAM accelerator for the ST
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark
DSTB1 Open source 16Mhz 68k and AltRAM accelerator for the ST
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark
- frank.lukas
- Posts: 663
- Joined: Fri Jan 19, 2018 11:52 am
Re: Alt-RAM logic brain fart
I not now but over 16MB all Ram is 32bit (Atari TT, CT6x, 030 Speeder with Fastram ...) for TOS ?
Re: Alt-RAM logic brain fart
Doesn't emutos register the ram by itself ?
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
Re: Alt-RAM logic brain fart
Is that a CPU requirement I've missed? I can't see how TOS would know or be able to enforce that.frank.lukas wrote: ↑Thu Sep 24, 2020 7:08 pm I not now but over 16MB all Ram is 32bit (Atari TT, CT6x, 030 Speeder with Fastram ...) for TOS ?
If TOS asks for a longword, I thought it was down to the CPU to perform cycles until it fulfils the request.
BW
DFB1 Open source 50MHz 030 and TT-RAM accelerator for the Falcon
DSTB1 Open source 16Mhz 68k and AltRAM accelerator for the ST
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark
DSTB1 Open source 16Mhz 68k and AltRAM accelerator for the ST
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark
Re: Alt-RAM logic brain fart
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.
DFB1 Open source 50MHz 030 and TT-RAM accelerator for the Falcon
DSTB1 Open source 16Mhz 68k and AltRAM accelerator for the ST
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark
DSTB1 Open source 16Mhz 68k and AltRAM accelerator for the ST
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark
Re: Alt-RAM logic brain fart
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?
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?
Re: Alt-RAM logic brain fart
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.czietz wrote: ↑Thu Sep 24, 2020 7:44 pm 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'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.
DFB1 Open source 50MHz 030 and TT-RAM accelerator for the Falcon
DSTB1 Open source 16Mhz 68k and AltRAM accelerator for the ST
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark
DSTB1 Open source 16Mhz 68k and AltRAM accelerator for the ST
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark
Re: Alt-RAM logic brain fart
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...
So quick check of the schematic this morning and, sure enough, I'm a Pilsbury Dough Boy: Time for some more trace breaking and bodging tonight. Let's hope that's all it was.
BW.
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...
So quick check of the schematic this morning and, sure enough, I'm a Pilsbury Dough Boy: Time for some more trace breaking and bodging tonight. Let's hope that's all it was.
BW.
DFB1 Open source 50MHz 030 and TT-RAM accelerator for the Falcon
DSTB1 Open source 16Mhz 68k and AltRAM accelerator for the ST
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark
DSTB1 Open source 16Mhz 68k and AltRAM accelerator for the ST
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark