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).

Comments Forum

More Devlog entries

Most recent first