| View previous topic :: View next topic |
| Author |
Message |
bobo68
Joined: 03 Jun 2015
Posts: 212
Location: Germany
|
 Posted: Wed Apr 19, 2017 2:42 am Post subject: |
 |
|
Looking at the source code of dsp_cpu.c: there is a DSP memory map assumed (for Atari's Falcon). I'm not sure if this is valid for NeXT's 96K expansion. Have to check the mapping/wiring we found.
The large DSP expansion module from the San Francisco State University would definitely provide a different memory layout having just 3 64K chunks of non mirrored / non overlayed program, data x and data y memory. |
|
| Back to top |
|
 |
andreas_g
Joined: 30 Jan 2009
Posts: 430
Location: Austria
|
| Posted: Wed Apr 19, 2017 3:11 am Post subject: |
|
|
The memory map at the top of dsp_cpu.c was modified to reflect NeXT's layout for a 24k module. But as noted in the file it is mostly a guess. Anyway it seems to work without problems with all DSP software I tested so far (including NeXT diagnostics). Memory layout for 96k is similar: below 0x8000 overlapping 32k dsp-words. above 0x8000 separate 16k data spaces (mirrored once) overlapping with 32k program space.
As you noted the large memory module will most likely fill all space with non-mirrored and non-overlapping memory. That might in fact break some software, if it relies on overlapping. |
|
| Back to top |
|
|
bobo68
Joined: 03 Jun 2015
Posts: 212
Location: Germany
|
| Posted: Wed Apr 19, 2017 3:58 am Post subject: |
|
|
Please have a look at the address mapping SlateBlue and me found at https://docs.google.com/spreadsheets/d/1IEQZNNyqNDBm2rji7DHeYrpfK_TktUw3WzUsdI8wsJM/edit?usp=sharing, tab "Address mapping". I cannot bring your comments on the 96K module in line with what we found.
Main findings for me:
SRAMs together provide one 24-bit DSP word (3x 8 bit).
Program memory select (_DSPPS) and data memory select (_DSPDS) are not used by the module. i.e. there seems to be no distinction between program and data memory which means they would overlap.
The multiplexer is only used to generate the A14 address line of the SRAMs like this:
Inputs: DSPA14 is I0b, DSPXY is I1b
DSPA15 selects between both
Output _Zb (output is inverted) goes to A14 of SRAMs
That of course leads to a rather strange mapping of logical to physical memory you can see in tab "Address mapping" of our spreadsheet. I still have some doubts this is true but that is what we found so far. |
|
| Back to top |
|
|
bobo68
Joined: 03 Jun 2015
Posts: 212
Location: Germany
|
| Posted: Wed Apr 19, 2017 4:20 am Post subject: |
|
|
| andreas_g wrote: | | Anyway it seems to work without problems with all DSP software I tested so far (including NeXT diagnostics) |
Which software can be used for testing apart from diagnostics? |
|
| Back to top |
|
|
andreas_g
Joined: 30 Jan 2009
Posts: 430
Location: Austria
|
| Posted: Wed Apr 19, 2017 5:10 am Post subject: |
|
|
| bobo68 wrote: | Main findings for me:
SRAMs together provide one 24-bit DSP word (3x 8 bit).
Program memory select (_DSPPS) and data memory select (_DSPDS) are not used by the module. i.e. there seems to be no distinction between program and data memory which means they would overlap.
The multiplexer is only used to generate the A14 address line of the SRAMs like this:
Inputs: DSPA14 is I0b, DSPXY is I1b
DSPA15 selects between both
Output _Zb (output is inverted) goes to A14 of SRAMs
|
I'm afraid I don't understand this. But does that mean it is probably as simple as just mapping 8k DSP-words overlapping and repeating throughout the entire address space (of course except internal ROM, I/O, etc)? That would match my mapping below 0x8000. Then mapping above this value is probably wrong and this memory range was not used by the software I tested.
| bobo68 wrote: | | Which software can be used for testing apart from diagnostics? |
For example Mandelbrot and ScorePlayer demos (NeXTstep 1.x and 2.x) are heavily using DSP. But in this case it might be more useful to write a custom program (unfortunately I can't do that). One could then write for example to X data memory at 0xX800 and see if the data can be read at Y data memory 0xX800 and P memory at 0xX800 and at X data memory 0x(X+2)800 (repeat with X = 0 through X = F). |
|
| Back to top |
|
|
bobo68
Joined: 03 Jun 2015
Posts: 212
Location: Germany
|
| Posted: Wed Apr 19, 2017 5:25 am Post subject: |
|
|
I'll try to come up with a mapping description similar to the one in dsp_cpu.c.
Can you answer these questions?
How much internal memory does the DSP56001 have and how is it mapped into the address space? Is this the same address space that also covers the external expansion memory?
How does the DSP56001 know the external memory configuration? Is it configured by some bootstrap code? Or maybe it is not configured and the DSP programs have to find out / know? |
|
| Back to top |
|
|
andreas_g
Joined: 30 Jan 2009
Posts: 430
Location: Austria
|
| Posted: Wed Apr 19, 2017 6:07 am Post subject: |
|
|
Stupid question, as I am not knowing what a multiplexer does, but isn't this (quote from the spread sheet) "So either SIMM connector's DSPA14 or DSPXY signal is routed to A14 of the SRAM chips depending on DSPA15" almost exactly doing what is shown in my drawing in dsp_cpu.c:
Below 0x8000 (DSPA15 is 0): Route DSPA14 to A14.
Above 0x7FFF (DSPA15 is 1): Route DSPXY to A14 and thus split physical DSP memory into two separate pieces of same size depending on selected data memory space (X or Y).
Then in my drawing only P above 0x7FFF is wrong, because only X and Y matters and P does either go to X or Y block depending on DSPXY.
Update: If DSPDS would be wired in a way, that DSPA14 is always routed to A14, if P memory is selected, it would match my drawing 100%, wouldn't it?
| Code: | The memory map is configured as follows :
0x0000 to 0x7fff:
Program space P and data spaces X and Y are contiguous
8k dsp Word blocks. They overlap in physical memory.
0x8000 to 0xffff:
X and Y data spaces are physically separate 4k dsp Word
blocks. Program space P is a contiguous 8k dsp Word block
and phyically overlaps X and Y data space.
Y: memory is mapped at address $8000 in P memory
X: memory is mapped at address $9000 in P memory
X: Y: P:
$ffff |--------------+--------------+--------------|
| Int. I/O | Ext. I/O | |
$ffc0 |--------------+--------------+ |
| | | |
| Mirror(8) | Mirror(8) | Mirror(4) |
| | | |
$A000 | | |--------------|
| | | |
| | | |
| | | 8k |
$9000 |--------------+--------------| External |
| 4k | 4k | RAM |
| External | External | |
| RAM | RAM | |
$8000 |--------------+--------------+--------------|
| | | |
| Mirror(4) | Mirror(4) | Mirror(4) |
| | | |
$2000 |--------------+--------------+--------------|
| 8k | 8k | 8k |
| External | External | External |
| RAM | RAM | RAM |
$0200 |--------------+--------------+--------------|
| Log table or | Sin table or | |
| external mem | external mem | Internal |
$0100 |--------------+--------------+ program |
| Internal X | Internal Y | memory |
| memory | memory | |
$0000 |--------------+--------------+--------------|
|
| bobo68 wrote: | | How much internal memory does the DSP56001 have and how is it mapped into the address space? Is this the same address space that also covers the external expansion memory? |
My drawing answers this question. It has 256 DSP-words internal X memory, 256 DSP-words internal Y memory and 512 DSP-words internal P-memory. Furthermore it has internal constant ROMs, 256 DSP-words each, in X and Y memory space. I/O registers are mapped at the top of X and Y memory spaces. The internal memory and I/O memory partially cover (overlap with) external memory.
| bobo68 wrote: | | How does the DSP56001 know the external memory configuration? Is it configured by some bootstrap code? Or maybe it is not configured and the DSP programs have to find out / know? |
The DSP itself does not know how much external memory it has. Software has to find it out. NeXT does this by writing to some location and then check if/where the data can be read (e.g. write to 0x0800 and finding data at 0x2800 means 24kB memory installed). |
|
| Back to top |
|
|
bobo68
Joined: 03 Jun 2015
Posts: 212
Location: Germany
|
| Posted: Wed Apr 19, 2017 6:52 am Post subject: |
|
|
We are thinking in the same direction, but...
The multiplexer inverts its selected input, which means the physical blocks are mapped the other way round.
DSPXY is always set to 1 if program memory is accessed (at least I read this).
Address bits 0 - 13 are routed straight through to the SRAMs, i.e. the interesting stuff is happening at 16K blocks. So my picture, which tries to show which physical memory is mapped to which logical memory, looks like this:
Given:
| Code: |
SRAMs
Physical Base Address 16K block name
$4000 S2
$0000 S1
|
This would be the mapping (not showing the overlay with internal memory):
| Code: |
DSP56001
Logical Base Address X Y P
$C000 S1 S2 S1
$8000 S1 S2 S1
$4000 S1 S1 S1
$0000 S2 S2 S2
|
Does this make sense? |
|
| Back to top |
|
|
andreas_g
Joined: 30 Jan 2009
Posts: 430
Location: Austria
|
| Posted: Wed Apr 19, 2017 8:46 am Post subject: |
|
|
| bobo68 wrote: | | Does this make sense? |
My above drawing shows the map for 8k dsp-words while yours is for 32k dsp-words. I think it mostly matches (although i don't invert the input, which should not matter if it is same for reading and writing; X block being S2 seems to be correct in my code). There is only one difference: In my table P memory is treated the same no matter if addressed from below or above 0x8000. Are you sure DSPDS signal is unused? My table translated to 32k and your format looks like this (inversion difference ignored):
| Code: |
SRAMs
Physiacal Base Address 16k block name
$4000 S2
$0000 S1
DSP56001
Logical Base Address X Y P
$C000 S1 S2 S1
$8000 S1 S2 S2
$4000 S1 S1 S1
$0000 S2 S2 S2
|
And for 8k dsp-words:
| Code: |
SRAMs
Physiacal Base Address 4k block name
$1000 S2
$0000 S1
DSP56001
Logical Base Address X Y P
$F000 S1 S2 S1
$E000 S1 S2 S2
$D000 S1 S2 S1
$C000 S1 S2 S2
$B000 S1 S2 S1
$A000 S1 S2 S2
$9000 S1 S2 S1
$8000 S1 S2 S2
$7000 S1 S1 S1
$6000 S2 S2 S2
$5000 S1 S1 S1
$4000 S2 S2 S2
$3000 S1 S1 S1
$2000 S2 S2 S2
$1000 S1 S1 S1
$0000 S2 S2 S2
|
Last edited by andreas_g on Wed Apr 19, 2017 9:38 am; edited 1 time in total |
|
| Back to top |
|
|
SlateBlue
Joined: 23 Aug 2015
Posts: 75
|
| Posted: Wed Apr 19, 2017 9:06 am Post subject: |
|
|
| I guess we're not certain DSPDS isn't used, but I find no continuity from SIMM pin 42 to the multiplexer, nor to the SRAMs. All questions seem to lead back to this, so I can try checking again. |
|
| Back to top |
|
|
bobo68
Joined: 03 Jun 2015
Posts: 212
Location: Germany
|
| Posted: Wed Apr 19, 2017 11:30 am Post subject: |
|
|
| andreas_g wrote: | My above drawing shows the map for 8k dsp-words while yours is for 32k dsp-words.
...
And for 8k dsp-words:
|
I'm struggling with the way you use "32K" respectively "8K" DSP words.
My table's granularity is 16K (0x4000 = 16384), not 32K.
Your table's granularity is 4K (0x1000 = 4096), not 8K.
Can you clarify? |
|
| Back to top |
|
|
bobo68
Joined: 03 Jun 2015
Posts: 212
Location: Germany
|
| Posted: Wed Apr 19, 2017 11:33 am Post subject: |
|
|
| SlateBlue wrote: | | I guess we're not certain DSPDS isn't used, but I find no continuity from SIMM pin 42 to the multiplexer, nor to the SRAMs. All questions seem to lead back to this, so I can try checking again. |
The problem is: where should it go to? The two inputs of one "channel" of the multiplexer are used. Cascading them does not make sense. And the SRAM only have one Enable input which is also used (connected to _DSPRMEN, SIMM pin 60). |
|
| Back to top |
|
|
bobo68
Joined: 03 Jun 2015
Posts: 212
Location: Germany
|
| Posted: Wed Apr 19, 2017 11:44 am Post subject: |
|
|
| bobo68 wrote: | | Cascading them does not make sense. |
Have to take that back. One could route the output of the A14/DSPXY multiplexing through another multiplexing and let _DSPDS decide what the final result is (either the output of the first stage or something else, e.g. A14 again.) |
|
| Back to top |
|
|
andreas_g
Joined: 30 Jan 2009
Posts: 430
Location: Austria
|
| Posted: Wed Apr 19, 2017 12:23 pm Post subject: |
|
|
| bobo68 wrote: | I'm struggling with the way you use "32K" respectively "8K" DSP words.
My table's granularity is 16K (0x4000 = 16384), not 32K.
Your table's granularity is 4K (0x1000 = 4096), not 8K.
Can you clarify? |
My table in dsp_cpu.c shows the layout of the standard 24 kB (8k dsp-words) module while your table shows the layout of the 96 kB (32k dsp-words) expansion module. Because A14 is derived from different sources 8k is logically split into two 4k blocks and 32k is split into two 16k blocks.
| bobo68 wrote: | | One could route the output of the A14/DSPXY multiplexing through another multiplexing and let _DSPDS decide what the final result is (either the output of the first stage or something else, e.g. A14 again.) |
That is exactly what i am suspecting (in pseudo-code, inversion ignored):
| Code: |
if (DSPA15) {
if (DSPDS) {
A14 = DSPA14;
} else {
A14 = DSPXY;
}
} else {
A14 = DSPA14;
}
|
or with same result:
| Code: |
if (DSPDS) {
A14 = DSPA14;
} else {
if (DSPA15) {
A14 = DSPA14;
} else {
A14 = DSPXY
}
}
|
I can't confirm it, because i have no way to test (know-how missing and no NeXT hardware here). |
|
| Back to top |
|
|
bobo68
Joined: 03 Jun 2015
Posts: 212
Location: Germany
|
| Posted: Wed Apr 19, 2017 2:02 pm Post subject: |
|
|
| SlateBlue checked all outputs of the multiplexer (_Zx) and apart from _Zb (which yields the selection via DSPA15) all other outputs seemed to be open / floating / going nowhere. I guess we can give that another try. |
|
| Back to top |
|
|
|
Log in to check your private messages
Log in
Register
