Previous Thread
Next Thread
Print Thread
Page 5 of 19 1 2 3 4 5 6 7 18 19
Edstrom #102753 11/24/15 07:01 PM
Joined: Mar 2001
Posts: 16,923
Likes: 57
R
Very Senior Member
Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 16,923
Likes: 57
The 68000 core inside the CD-i's 68070 has all 32 address bits valid. I don't know of any A32 680000s other than that.

Edstrom #102754 11/24/15 07:05 PM
Joined: Mar 2001
Posts: 16,923
Likes: 57
R
Very Senior Member
Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 16,923
Likes: 57
Regarding A24, it's important to note that the 68000 doesn't have a physical A0 line. There are A23-A1 and then two signals indicating which byte lane(s) are valid, so the address space is technically 0x800000 16-bit words rather than 0x1000000 (24^1) 8-bit bytes.

Edstrom #102755 11/24/15 07:34 PM
Joined: Mar 2006
Posts: 1,073
Likes: 5
L
Very Senior Member
Offline
Very Senior Member
L
Joined: Mar 2006
Posts: 1,073
Likes: 5
Given I can't find any pictures of the mc68032, I'm guessing it was either mythical to begin with, or it was a prospective product Motorola planned to offer but never ended up releasing it.

EDIT: AHA! It WAS a real product, but it is called mc68012 and is mc68010 derived! It is 84-pin PGA only. See http://www.cpu-world.com/CPUs/68012/

LN

Last edited by Lord Nightmare; 11/24/15 07:36 PM.

"When life gives you zombies... *CHA-CHIK!* ...you make zombie-ade!"
Joined: Jan 2011
Posts: 251
Likes: 3
Senior Member
Offline
Senior Member
Joined: Jan 2011
Posts: 251
Likes: 3
Originally Posted By Lord Nightmare
It is 84-pin PGA only.
Originally Posted By Lord Nightmare
Given I can't find any pictures of the mc68032, I'm guessing it was either mythical to begin with, or it was a prospective product Motorola planned to offer but never ended up releasing it.

EDIT: AHA! It WAS a real product, but it is called mc68012 and is mc68010 derived! It is 84-pin PGA only. See http://www.cpu-world.com/CPUs/68012/

LN


from the data sheet

The MC68012 is an expanded address
range version of the M C68010 with the additional address pins A24-A29 and A31. A30 is not included
due to packaging restrictions.

I mis-remembered the number of address bits.

Al Kossow #102757 11/24/15 08:30 PM
Joined: Jan 2011
Posts: 251
Likes: 3
Senior Member
Offline
Senior Member
Joined: Jan 2011
Posts: 251
Likes: 3
Originally Posted By Al Kossow

I mis-remembered the number of address bits.


And the only place that I ever saw them used was the Unix upgrade option for the HP 9836. I didn't know about their use in the FX/8

R. Belmont #102758 11/24/15 08:53 PM
Joined: Jun 2001
Posts: 476
Likes: 3
O
Senior Member
Online Content
Senior Member
O
Joined: Jun 2001
Posts: 476
Likes: 3
Originally Posted By R. Belmont
Regarding A24, it's important to note that the 68000 doesn't have a physical A0 line. There are A23-A1 and then two signals indicating which byte lane(s) are valid, so the address space is technically 0x800000 16-bit words rather than 0x1000000 (24^1) 8-bit bytes.


Interestingly, the address output buffer (the register that's routed to the address pins) has all 32 bits, and there are 24 address pads (die positions the pins are soldered to), a1-a23 and a31. The a31 pad has no pin soldered to it though.

OG.

Edstrom #102759 11/24/15 10:38 PM
Joined: Aug 2015
Posts: 405
Edstrom Offline OP
Senior Member
OP Offline
Senior Member
Joined: Aug 2015
Posts: 405
Well in VME the A1-A23 is called A24 adressing and there is no A0. The 68000 just happens to be the role model for the VME bus but there are plenty of other CPU architectures using it and still have to implement A24! smile There are other lanes used to pick up what byte that is transfered for example for byte transfers in A32 mode.

Another interesting detail about VME A24 mode is that it is the maximum addressable memory area that only requires the P1 connector. For either A32 and/or D32 transfers the second connector P2 is required and there is a bunch of rules how boards can be combined with only P1 or both connectors.

Maybe there is a simple workaround for A24? I am trying to set up one address space per addressing mode A16, A24, A32 and A64. In theory there are 256 different Address Modifiers (AM) which could be mapped to one address space each but I will ignore that now and assume people set up systems based on one or more of the above 4 systems. The AM:s will only be emulated to verify that both the master and slave device agrees on the transfer type.

I think I start with A16 with D8 and D16 transfers until you in the core team decides on the A24 thing.

I would also appreciate advice on how to define the four address spaces, I was thinking just to use AS_0 to AS_3 in the VME device I am creating and map accesses through the read and write handlers from the local AS_PROGRAM address space(s) of the board(s)? Will they not collide internally as the VME device itself is owned by the CPU board in SLOT 0?

The plan is to let the VME device be a slot device and access the other boards through plain slot mapping to one of the four address spaces described above. Some sub-master boards has dual ported RAM as interface to the VME bus and subsequently their own address maps.

Last edited by Edstrom; 11/24/15 10:41 PM.

Because I can
Edstrom #102760 11/25/15 02:14 AM
Joined: Mar 2001
Posts: 16,923
Likes: 57
R
Very Senior Member
Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 16,923
Likes: 57
I don't quite understand "decides on the A24 thing". It's totally possible to make address spaces with 24 address bits right now; the 68000, 65816, and several other 16-bit CPUs have one.

Edstrom #102765 11/25/15 08:06 AM
Joined: Jun 2001
Posts: 476
Likes: 3
O
Senior Member
Online Content
Senior Member
O
Joined: Jun 2001
Posts: 476
Likes: 3
Originally Posted By Edstrom
JThe direction I have is to model the VME adress spaces (A16, A24, A32 and A64) independently of the address space of the CPU board and map slot devices into those.


That sounds like a bad idea actually.

Can you describe what happens when the cpu does an access? What makes the bus decide it's for him, what actually goes on the bus, what the devices see, what they do?

OG.

Edstrom #102766 11/25/15 11:56 AM
Joined: Aug 2015
Posts: 405
Edstrom Offline OP
Senior Member
OP Offline
Senior Member
Joined: Aug 2015
Posts: 405
@RB: ok, maybe I am on th wrong path here. I was referring to the address_space::allocate function that throws up at me here
Code:
throw emu_fatalerror("Invalid width %d specified for address_space::allocate", config.data_width());
when trying to create a 24 bit address space. Maybe this is not needed, see below.

@OG: I just realized that I must have dreamt up some features that I have seen and remembered as VME features but they were really special backplanes that for example aggregated four 8 bit I/O boards to allow D32 reads of data from 4 boards in a single cycle. Reading "Observation 2.16" in the spec I know that it is not possible with the VME alone.

This makes it a bit simpler and if I also combine the A16,A24, A32 and A64 into a single address space with only a mask for each I could use the AS_DATA, or what do you suggest?

The reason I want a separate address space is that each master is accessing the bus through a window in the local address space. For example this Force board (see http://bitsavers.informatik.uni-stuttgar...anual_Feb92.pdf)

Code:
Board             A16 - end          A24 - end          A32 - end
----------------------------------------------------------------------
Force  D08-16 FCFFOOOO-FCFFFFFF  FCOOOOOO-FCFEFFFF    
CPU-40 D08-32 FBFFOOOO-FBFFFFFF  FBOOOOOO-FBFEFFFF  01000000-F9FF FFFF


Compare it to this Heurikon board (See http://bitsavers.informatik.uni-stuttgar...anual_Jun91.pdf )

Code:
Board                A16 - end          A24 - end          A32 - end
----------------------------------------------------------------------
Heurikon  D08-16 00C00000-00C0FFFF  01000000-01FFFFFF      
HK68_V3D  D08-32                                       04000000-FFFFFFFF


You can see that the windows for A16 and A24 are complete while the A32 is crippled in order to map local devices. You can also see that the A16 and A24 windows are on different locations in the memory maps. Now if we also add the slave complexity to this it is quite possible that a VME slave board installs in the lower region of the A32 range and would collide with the local devices unless separated.

The master board (any SLOT) requests the bus. The bus arbiter on the controller board in SLOT 0 will grant the bus to the requesting master if there is noone else with higher, or upstream daisy chained with the equal, priority using the bus. The master puts the addresses on the bus together with one of the 8 bit address modifiers (A16, A24, A32, A16-priveleged, A24-user-defined and so forth). Once the adresses are on the bus all boards will compare the adress modifiers and the adresses and respond if they are matching. The slave check what type of transfer is requested on the DS0, DS1 and present the data on the appropriate data lines.

I don't intend to implement the arbiter for now becuase it doesn't makes sense with the non preemptive scheduling model used in MAME currently, so all accesses will be immediatelly granted and fully executed in turn.

EDIT: of course the master board requests the bus *before* it puts the adress there...

Last edited by Edstrom; 11/25/15 01:10 PM.

Because I can
Page 5 of 19 1 2 3 4 5 6 7 18 19

Link Copied to Clipboard
Who's Online Now
2 members (Richard Bannister, 1 invisible), 23 guests, and 3 robots.
Key: Admin, Global Mod, Mod
ShoutChat
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Forum Statistics
Forums9
Topics9,103
Posts119,274
Members5,019
Most Online890
Jan 17th, 2020
Our Sponsor
These forums are sponsored by Superior Solitaire, an ad-free card game collection for macOS and iOS. Download it today!

Superior Solitaire
Forum hosted by www.retrogamesformac.com