Define a device model

[larsbrinkhoff]

struct mmu is increasingly being abused for modelling hardware components. First diagnostics was added, and now interrupt handling has been included. Also, some entities that obviously model hardware components doesn't have a struct mmu. Most likely, struct mmu would be better off only handling MMU properties only.

I propose it would be a good idea to add a struct device for modelling all devices. Here are some things to consider for such a model:

• MMU interface
• Bus interface
• Interrupts
• Diagnostics
• Recording state
• Signals
• Connecting outputs and inputs to other devices
• Multiple instantiation (e.g. ROM, ACIA)
• Timer callbacks
• Periodic calls
• Reset
• Handling user/configuration/script commands

[larsbrinkhoff]

https://github.com/larsbrinkhoff/ostis/compare/master...device is a work in progress with a first step in this direction.

[stefanberndtsson]

The first description of the issue and the proposal seem to clash a bit. The first one says it doesn't have an mmu, only a device, the code however puts the device inside an mmu object. Shouldn't it be the other way around, with the mmu object inside the device?

[larsbrinkhoff]

The answer to the question is: Yes!

It's a work in progress, more commits to follow. At this point, discussion about the idea is more useful than looking at unfinished code.

[stefanberndtsson]

Good. The idea is definitely the right one. It might even be that MMU is the wrong semantic term for the I/O-mapping of devices, but that's a GLUE-related discussion :)

[larsbrinkhoff]

Since this was first written, the code is moving more and more towards using clocked state machines. The device model should reflect this.

• Devices should be able to register for clock signals. Possibly different clock cycles, and more than one clock source.
• There should be support for writing the state machines. I see a need for requesting events to happen some number of clock cycles in the future, or periodic events.
• The devices send signals to each other. If one device is to react to a signal in the same clock cycle as it's raised, the output device needs to execute before the input device, or else there will be a delay.

[stefanberndtsson]

The "request events to happen at " sort of, might be synced to a master clock, regardless of local slower clock in the device. That would probably help when triggering signals to other devices.

[larsbrinkhoff]

Different kind of signals:

• Level
• Edge
• Pulse
• Clock (periodic pulses)

Physical view:

• High/low level
• Rising/falling edge

Logical view:

• Active/passive

Implementations:

• Setting a variable
• Calling a function