Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Addressbus trait obj #87

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Conversation

pengi
Copy link

@pengi pengi commented Aug 8, 2019

I'm trying to use the r68k emulator (Great project!) to run some old mac applications from the 90's by creating an abstraction layer for the Macintosh toolbox.

One part of doing that is to map differnt parts of the address space, given prefixes, to differnt implementaitons. For example, one would be the video buffer, one would be the sound buffer, one would be regular RAM (possibly with memory allocation), one would be for emulade global variables.

Since it would be implemented in hardware with a demux on the MSB address bits connected to the chip enable/output enable of the different peripherals, and the lower bits as addresses, it makes sesse to treat the smaller address busses as AddressBus traits too, to keep it generic.

Therefore, I implement a MuxAddressBus, like:

pub struct PrefixMap<T> {
    // ...
}

impl<T> PrefixMap<T> {
    fn locate(&self, address : u32) -> Option<&T> {
        // ...
    }
    fn locate_mut(&mut self, address : u32) -> Option<&mut T> {
        // ...
    }
}

pub struct MuxAddressBus {
    children: PrefixMap<Box<dyn AddressBus>>
}

impl AddressBus for MuxAddressBus {
   // ...
}

In that way, I can split out the address space.

The problem is the copy_from() method required in the AddressBus trait, which not really corresponds to the physical interface of address lines, data lines and control lines (read/write signals). The copy_from corresponds more to a physical memory, and would be better implenented as part of that interface (LoggedMem / PagedMem).

So I suggest moving copy_from() method to the implementation of those objects, rather than the trait AddressBus

The AddressBus models, as the name suggests, the address bus, and not RAM

The RAM is then connected to the address bus (and data bus), so that it can be
accessed.

It is however quite common to add a demux on the upper bits in the address bus,
splitting out the address bus in several busses with shorter word length, and
different chip enable/output enable signals.

One way of implementing that, is to have an object which demux the address bus
into several other address busses. But that would need to refer to the smaller
busses as trait objects (Box<dyn AddressBus>)

Since the AddressBus implements copy_from(&mut self, other: &Self), which refer
to Self as a type, it can't be used as a trait object. Also the copy_from
indicates that "other" actually stores values that can be copied, which might
not be true if the peripheral would be something like an I/O or random number
generator.

The proper way to implement a copy_from() if necessary would be to have it as
another trait, for example CopyableMemory. But since copy_from currently only
is used for testing, it makes sense to keep it simple, and add it directly to
the explicit types.

Note that a trait object creates overhead for memory access. So to be able to
have a fast cache/ram hard coded, it still makes sense to have ConfiguredCore
as a generic over the AddressBus
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant