Memory Data

Today involved integrating the Memory Data to the data-saving of the circuit. I save data for a Part as a Dictionary property (this allows for a variety of data properties to be saved in the same way to cater for different types of Parts — there is probably a better way to do this, but I presently don’t know of it).

For the Memory, I created a Resource to store the bytes as a PoolIntArray and the Width value. This unearthed many things that I hadn’t thought about before such as effects of changing the memory size. But I got the Save, Edit, and Load working fine for the memory.

ROM and RAM

The next step will be to get the Bus working where there is a RAM or ROM type of memory. I am having the Data flow in to the left for writes and out from the right for reads. Then there is no need for a R/W signal input to the memory. But the memory will be asynchronous and require I/O registers to operate like a regular memory device. But this is good to see the internals of a computer circuit.

To do

  • Use ports to direct Input Bus data to Address or Data inputs for a RAM
  • Update the Memory Size Label when the size is changed
  • Decide how to handle editing of memory in the bit mode dump display
  • Think about how to import memory data

Thoughts

I am almost done implementing the kinds of Parts that I want to implement, but if I was to refactor the code, I might work harder on the Polymorphism where there would be more granular extension of Types and improved Composition.

There is quite a lot of “If a Part is of Type X” then do something different here which should not happen in OOP code I think (we should compose a new Type). This is mostly due to a lack of forward planning I think. But it is fun to dive in to the development and discover things along the way.

Another thing is Testing. I implemented a thorough test of the Gates against Truth Tables, but I ran into many regressions and bugs that could have been avoided by having unit tests in place for other things.

I think that the reason for not automatically testing everything is simply because of a desire to get the project done ASAP.

To address the above problems (with the expectation that this project will grow big and spawn), I am thinking to release a beta test version out for free like it is now and then have a honeymoon period where I refactor the entire project towards a consumer release version. This one would adopt CD (Continuous Delivery) principles, and be very well engineered in terms of code design (OOP best practice).

More Devlog entries

Most recent first