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
Rewrite SeqGenElm.java #14
Conversation
"One shot" is now stored as a flag, but the boolean still exists for backcomp. This also adds a reset pin.
check out EditInfo.changeFlag(flags, bit) I wouldn't change the dump format unnecessarily. If we already are dumping a boolean for oneShot, we might as well keep it. |
Looks like a big improvement though. |
I always thought that we should just have a single "sequence" text entry field that you could fill in with an arbitrary length string of bits, rather than having 8 checkboxes. Any interest in doing that? |
So what does reset do.. I thought it would restart the sequence if we were in one-shot mode but instead it stops it? I don't know what chip this is based on, is that what they do? |
The As for sequences, I would absolutely love to add that to match the way the SRAM works. Being limited to 8 bits and having to enter them as checkboxes is rather unusual, especially if I want to provide a stream of data to my circuit. |
This just resets the circuit as if the user pressed the global reset button (for the entire circuit). It puts it in an inactive state (output low), and the generator waits until the first CLK tick before displaying the first bit. I was rather puzzled by this as well but assumed this was intentional. If it's not, we can just fix it. |
Ok it was hard to tell which code was there before because of all the whitespace changes, and I don't use this element in any of the samples so I'm unfamiliar with it. I guess a flag is fine for oneshot. |
If you don't need reset for something we should probably just leave it alone until someone complains. |
I considered using this, however the previous code resets the data pointer whenever the edit values are changed. I'm not entirely sure why it does this, and I don't know why the reset position is 0 or 8 depending on oneShot. I didn't want to break it, so I left it alone. |
I don't think the sequence generator has any equivalent real-world ICs, besides maybe a PISO shift register with pins variously fixed high or low (but even that technically can be reset, by raising the latch). It seems like a tool for producing a byte one bit at a time, or for producing a simple repeating pattern.
The sequence generator is fairly useless right now due to these restrictions. Hopefully, with this branch, we/I can make it a lot better. |
I've been thinking more about the sequence generator and I realize now is the opportune time to make substantial changes which would be considerably harder to do later. |
I've tested importing and it seems to work, but I'll need a old circuit featuring the sequence generator to be sure. |
I would just store the sequence internally as a string personally. Then we don't have to parse it and then do a bunch of work to un-parse it when dumping. We definitely do not need to pack the sequence bit by bit into an array of bytes. This is not running on a VIC-20. It has the side effect of adding a bunch of pad bits to the end of the sequence.. If you set the sequence to 111 then you get 5 zeroes at the end before the sequence starts up again. Also this is all converted to javascript so using types like byte, short, etc. instead of int accomplishes nothing. |
Whoops, using |
What's one shot doing? It's acting weird... $ 1 0.000005 30.13683688681966 50 5 50 5e-11 |
I wrote the code in such a way that changing the internal data type is relatively trivial. I can change it to store data as an int array rather than as a byte array. The reason packing/unpacking is done rather than storing as chars is because it makes the exported file considerably smaller for large sequences (which will be one of the use-cases of this sequence generator). |
Ok I see that one shot is just as broken before as it is now. |
Heh, the one-shot has a metric ton of bugs in it which need ironing out. Hopefully we'll be able to squash them in this branch. |
Ok I didn't see how you were dumping it, I glanced at it and thought you were unpacking and dumping as a string. That's fine. Making the dump file small is a worthy goal. |
There are still a few more things to do. The baud rate (of the one-shot), for instance, needs to be configurable and included in the dump. |
Importing old circuits seems fine. I don't have any old circuits to check against. |
What part of this component should the scope monitor? The input or the output? |
the output so what's going on with the baud rate, what does that do? I thought it just output one bit for each clock transition. |
I think I found the bug in the one-shot which was present in the old version. It occurs when the user resets, because the component stores a value of when the last tick occurred (
The baud rate is used when the component is set to "one shot" mode. It determines how quickly to automatically write out the bits, in bits per second. In normal mode, the value does nothing because the sequence is progressed manually.
The scope is currently reading the input-ground voltage rather than the output-ground voltage, and I'm not sure how to fix this. |
I don't like adding a baud rate.. just use a clock to specify the baud rate. Doesn't matter if the old code did it, the old code was broken. create getVoltageDiff() to return the voltage used by the scope. |
I completely agree with you. People should use a CLK instead. This would drastically simplify the component. |
Well, we should make one-shot do what I assumed it did, which is keep the sequence from restarting when it's finished. Everything else should be the same.. It shouldn't ignore the clock, have a hard-coded baud rate, etc... |
I've cut out all the old code. We can add that option separately. I think we should name the option to something clear. "One-shot" can be somewhat ambiguous. Maybe "Loop sequence" or "Play once"? |
I thought one shot was pretty clear but Play Once (capital O) is fine. renaming it might be wise to distiguish from the old broken behavior. |
If you set the sequence to 1101111100, click OK and then edit again, the sequence is now 1101111111 |
Good catch |
Various major DRY violations are now gone.
The class now inherits ChipElm's edit info. As such, the chip can now be flipped on both X and Y axes. Flip Y isn't particularly useful, but flip X should be very useful for this element.
"One shot" is now stored in the element flag instead of a boolean. This should be backwards compatible but I've only tested this in-vitro and not fully from an example circuit.
This also adds a reset pin, which had a function (
hasReset
) but was never properly implemented. Old circuits should not feature the reset pin.