Add support for an EEPROM #229
Conversation
|
Excellent! have to test it out. |
| saveInfo.constructorParamaters.push(data); | ||
| return saveInfo; | ||
| } | ||
|
|
There was a problem hiding this comment.
I love that EEPROM is able to inherit from RAM so well.
|
Did a quick test, looks good. |
|
I'm a little bit disappointed with this.. The reason I wanted this component was because the idea of having a computer with a file system and that gave the end user the ability to create their own programs made me very excited. However, in the current state of this component (with only 10 bits for the address) such a computer would be almost impossible, especially when considering my planned ROM size of 64KB (16 bit address.) I could still have a larger RAM which on startup would load values from a ROM, maybe using DMA pins, but this still does not allow for saving the RAM values onto the ROM, meaning I would be unable to save any programs made in the computers software, the only programs that could be saved are those which were programmed by hand onto the ROM. |
|
Hi @blane1257 , let me address the different issues you pointed out:
You shouldn't feel limited by the address space of an element. You can always increase the address space by multiplexing them. This is how circuits in the real world create address spaces from smaller parts. As an example, here is a 256-bytes ROM built from the built-in 16-bytes ROM: https://circuitverse.org/users/1935/projects/4872. You can do the same with the RAM and EEPROM and you can then multiplex that circuit to build even bigger ones. Before we made the RAM built-in I was building large RAMs like this: https://circuitverse.org/users/1935/projects/4774, but then eventually we ended up hitting a limit on the size of the simulation queue.
64KB of ROM (or EEPROM) in this simulator sounds fairly ambitious. :-) Back in the days, Z80 computers managed to get away with 16KB of ROM and that was handling graphics and BASIC interpreters. We can certainly bump the address space limit to reduce the need to create multiplexing circuitry, but keep in mind the simulation is slow (on purpose, I suppose). The min clock time is 50ms for each tick in the simulator, meaning you need 100ms for a full up/down cycle, which means you can read (or write) about 10 addresses/second on a single address line. Reading 64KB addresses would take 6554 seconds, just shy of 2 hours. All that being said, choosing a smaller address space for the EEPROM was arbitrary, so we can always change it. The intention was to give a sense that you don't design "real" circuits around a lot of EEPROM, because they cost more per byte in the real world.
My suggestion would be to avoid copying - you can split the address space of the computer so that certain addresses target the EEPROM and other addresses target the RAM or even a ROM. This way you don't need to spend time copying values from the EEPROM to the RAM. Since the EEPROM is programmable you can always write directly to it, without having to write to the RAM and then copying to the EEPROM. If you look at the larger RAMs in my example, https://circuitverse.org/users/1935/projects/4774, you'll notice they take an address line, split its bits and use some bits to select the smaller components and passing the remaining bits as address to those smaller components. That is how you divide the address space between ROMs, EEPROMs, RAMs, graphic cards, etc.
The ROM is indeed read-only, but the EEPROM you can write to it like you do with the RAM. Once you save the project, the values in the EEPROM will persist. Values in RAM will NOT persist. |
|
The reason I would rather not multiplex is because it's much less practical, to achieve the same 64K space I would need 64 individual EEPROM components. Though I suppose you are right about such large address spaces, until now I haven't really put much thought into the time it takes to read/write, as "It's only one clock cycle, which is as fast as it could possibly get, so it couldn't possibly be an issue." But now I see, such a large ROM would be very impractical given the speed, so I should probably go down to 32K or 16K. This still would require 16 EEPROMs (or 8 for 16K) but that is significantly less.. The idea of one big address space with separate sections for ROM, RAM, and EEPROM sounds like a massive pain to make programs around, unless i misunderstand what you are saying. |
Fixes #212 , #117
New Element: EEPROM
The EEPROM is a non-volatile memory element.
Its content is persisted within the CircuitVerse project and its pins and usage are identical to the RAM element.
EEPROMs are more "expensive" than RAMs, so the maximum address space of the EEPROM is smaller than the RAM, limited to 10-bits (1024 addresses). For CircuitVerse, this helps keep the serialized project small.
Erasing the EEPROM will make all its values zero. There is no way to recover the original data once you erase it, just like it happens on a real EEPROM. That being said, you can always reload the project and the saved data will be there. If you erase the EEPROM and save the project, then, you know...you asked for it. :-)
EEPROM data survives cut-and-paste operations, so you can do interesting things, like duplicating EEPROMs, creating an EEPROM in one circuit and then cut-and-pasting the element in another circuit, or you can have a library of ready-to-use EEPROMs with interesting data.
Programming EEPROMs manually
Users might want to manually program the contents of an EEPROMs instead of building a circuit to do so.
An easy technique for this is to edit the JSON representation of the element directly:
Screenshots