🤑 Indie game store🙌 Free games😂 Fun games😨 Horror games
👷 Game development🎨 Assets📚 Comics
🎉 Sales🎁 Bundles

Making Art Studios

27
Posts
48
Followers
A member registered 1 year ago · View creator page →

Game

Recent community posts

> I must check it on my i7-4790k, currently I'm using it on notebook with i5, but I have access to dual Xeon workstation, it would be funny to check performance on it ;)

Unfortunately, the dual Xeons won't make a difference in performance. Currently simulation is single threaded and only 8ms of frame time is devoted to it. Until I manage to move the simulation to a separate thread and it ends up being faster than the single threaded version, 8ms should be enough for smooth interaction with the schematic.

> PS: new idea - pull-up resistors. Sometimes when you use tri-state buffers you want 0 instead of "Z" (not connected state)

Aren't pull-up resistors considered analog devices (i.e. they require a Vcc or Gnd pin to work)? If yes, they don't fit into the current simulator.

Can you describe a situation where a tri-state buffer with a 0 instead of Z output would be required? The only reason there are tri-state buffers in DLS is to be able to support buses (which are effectively wire-OR structures). Is there another usage for them? Isn't it possible to use AND/OR gates in places where you need a tri-state buffer with 0 disconnected state?

Thanks for the suggestions.

> first: could you implement more advanced save/load dialog which would allow to select directory to/from save/load?

Unfortunately, that's harder than it sounds. Implementing a proper save/load dialog using custom UI requires correct handling of Unicode paths and filenames, which in turn requires major changes to the application. This is one of those things I decided early in development and are a bit hard to change at the moment. Don't forget that even if the simulator is capable enough to handle complex circuits, my initial thought was to make some kind of game out of it. So, arbitrary save/load paths didn't fit in such scenario.

Having said that, what I have in my TODO list is the ability to add slashes as separators when saving a schematic, in order to be able to group your circuits into subfolders inside the existing schematics folder. Still needs some work to be implemented properly, but it's a lot less than what's required for what you suggest (i.e. since DLS doesn't allow non-ASCII chars in its input boxes, there's no need to handle Unicode paths).

> second: component toolbar on the left

That sounds nice. And it might be more accessible in case I add more build-in components in the future. I'll think about it.

> And third thing: maybe text component which would allow to place text note in any place in circuit.

I had that in my list, but I cannot find it anymore :) Probably removed it as not-needed. As far as I remember, what I had in mind was something like PDF comment annotations. Small symbols on the schematic grid, which you click to show/edit a comment. Is this what you have in mind? Or you want the text to be visible at all times? Maybe a "pin note" button will allow both ways to be implemented. I'll also think about it.

> LogicWorks unfortunatly refuse to cooperate with my CPU.

I haven't used LogicWorks so I'm not familiar with its capabilities. Looking at its website, it looks way more professional than DLS :)

Do you mean that it cannot simulate your schematic fast enough? Do you have any numbers which you can compare with DLS once you manage to rebuild your circuit in it? E.g. how fast is the simulation in LogicWorks (i.e. circuit nsec per wall-clock sec), like in DLS? Is there such a metric in LogicWorks?

I don't know what kind of circuits you've managed to build with DLS so far, so I'd suggest to not expect much from it performance-wise. The largest circuit I've managed to build was a cycle-accurate i8080 CPU but the simulation performance isn't great (~750usec/sec on my i3-2100).

At the moment all signals are 32 bits wide internally. But I need a way to distinguish UNDEFINED and ERROR values so actual signals inside the editor are limited to 16 bits. This is because UNDEFINED/ERROR have fixed 32-bit values.

In order to make wires carry 32-bit values, signals should be either turned into a struct (32-bit value + flag for Valid/UNDEFINED/ERROR) or increase their size to 64 bits. Both of these ideas require a lot of internal changes to the simulator, which I'm currently considering but haven't managed to make yet.

So to answer your question: Not any time soon I'm afraid. Sorry about that :)

That sounds great. Thanks! Don't know when I'll find some time to implement it and how far I'll take it, but it sounds interesting and it's something I'll consider.

Hello again,

The bug related to the new component/package dialogs has been fixed in the latest version (0.13.0) I just uploaded. Unfortunately, I didn't have enough time to search for a solution to the windowed-mode issue. Hope to fix it some time soon.

Hi,

I'd like to inform you that several of your suggestions have been implemented and are available in the latest version (0.13.0).

  • Wire thickness based on its bit width
  • SRAM component (synchronous, flow-through, standard write)
  • Colored LEDs
and a couple of other things. If you happen to find some time to test it out, I'll be glad to hear your feedback.

I just saw the windowed mode bug you described. Again, I've never tried running in window mode with the same dimensions as the native resolution, that's why I missed it (I usually run it in window mode, one resolution lower than the desktop resolution; i.e. my desktop is set to 1680x1050 and I run DLS in a 1600x900 window most of the time). Thanks again :)

Don't know if I'll be able to fix this because both window dimensions and cursor position come from GLFW. I'll search for a fix, but I cannot promise anything yet.

Regarding I/O priority/order. That's one of my thoughts. Don't know if I manage to implement it for the upcoming version (0.13) but it'll be done at some point.

FYI, the bug you were facing when creating a new component + package has been identified and will be fixed. Thank you again for your detailed steps to reproduce it. Apparently, I've never written the component name *before* opening the new package dialog, that's why I've missed it for so long.

In the meantime, try to create your new package before giving a name to the new component.

Thanks! I'll look at the crash reports you've submitted and hopefully the bug will be fixed in the next version :)

Regarding I/O pins at the top/bottom of the component. It's in my list of things to implement at some point, but it's low priority at the moment (also, I have to figure out what to do with the name of the component in this case).

Currently I/O pins appear only one the sides of the component (left pins are always inputs and right pins are always outputs). Also, their order is the order you created them in the first place. This is also in my TODO list (being able to change the order of appearance) but I haven't decided what would be the easiest and most intuitive way to implement it (e.g. separate component symbol editor/popup or select I/O index from the port's context menu?).

I forgot about it. 16-bit Floating point adder

I'm not sure if this is the final correct version because I have a couple of different schematics for this. If it doesn't seem to work correctly, please say it and I'll upload some of the others :)

Replied to BORKNET in DLS comments

> sorry, but do you type numbers which, on the right, match the letters in the output? the 7x16 does not have enough space...

No! You just write the the output values to each byte of the ROM. The first ROM byte should read 3F. The 2nd 06, the 3rd 5B, etc. Ignore the ASCII view (right part of the ROM editor). The ASCII view just shows the corresponding ASCII character for the byte value you have typed. But in this case this is irrelevant.

> although I do not know what to do with the h.

The 'h' next to every output value is used for showing that the value is in hexadecimal format. It's not part of the number.

I suggest you try creating some constant input ports or switches from the I/O dialog and connect them to the various inputs of the 7-segment display. Change their values and try to make the 7-segment display show the expected numbers (0, 1, 2...). Then take the bits of those inputs in turn and build 7-bit numbers. Those numbers in hexadecimal should match the expected output.

E.g. In order to show 0 on the 7-segment display, all segments should be turned on except from the middle one. Create 7 1-bit constant input ports and connect each one to A, B, C, etc. Try to make all the segments lit up except from the middle one, by manually changing each port's values. You'll get the following:

A=1, B=1, C=1, D=1, E=1, F=1, G=0.

So, the output of the ROM for address 0 (i.e. the number you want to show on the display), should be 011111 in binary, or 3F in hex.

Hope it's more clear now.

Replied to BORKNET in DLS comments

A ROM is a combinational component (i.e. it has no clock input). Whenever addr changes the output is updated with the data at the specified address.

If you are referring to level 2.03, you have a 4-bit input and an 7-bit output (the 7-segment display; the dp input can be hardwired to a 0 constant input port). So you need 16 7-bit numbers to cover all the input numbers. Create a 7-bit by 16 words ROM, right click on it and select Edit values. At each byte (since the "words" are 7-bit long, 1 word = 1 byte) write the value it is expected by the 7-segment display to show the correct digit for the corresponding number. E.g. if the input number is 0, the ROM address would be 0, meaning the first byte. So at the first byte you should write 3F (or 0111111b where each bit is connected to a specific segment of the display). Take a look at the truth table to figure out the correct values.

Hope it clears things up a bit. If you need more details please ask again :)

OK about the LEDs.

Regarding the push buttons (and any other I/O port in general). This isn't actually a bug. It's by design. In order to avoid something like that, please arrange the buttons in reverse order. All ports are rendered in the same order they are created.So by reversing their order, you can hide their label behind the newer port.

Putting the label on the left side of the button will not look good in case the button has a large name. Sorry about that :)

LED colors: Do you want to have both states (on/off) configurable (e.g. on = green, off = red) or just one color with different brightness will be enough (e.g. like it's implement now, on = light green, off = dark green)?

T-Junctions: Yes it's only an editing thing. To be honest, a couple of other users suggested that you should be able to start a wire from an input pin. It's already in my TODO list but I've categorized it as not important so it's a bit low on priority :) Hope it's not much of a hassle until it's "fixed".

RAM: As far as I can tell, the RAM described in the page you linked is async. One Write input which works as a clock signal (whenever a rising/falling edge is detected, data is written to the RAM). Problem with implementing just this version is that if you want to implement anything more sophisticated on top of it (e.g. synchronous pipelined SRAM with burst reads/writes), you'd have to build a component and you'll loose the ability to inspect the RAM's contents (once a RAM is inside a component you don't have access to it from the master schematic). That's why I'm thinking whether it'll be good to implement extra (configurable) features for it or not.

16-bit limit: Unfortunately, the way the simulator is implemented (how signals are stored and moved around and how special values such as Undefined and Error have been implemented) doesn't allow for a larger signal width at the moment. It bugs me too and it's on my list of thins to "fix", but since it's still early in development and it's supposed to be a game at some point, 16-bits should be enough for now.

Would love to see what you manage to build with DLS :)

Thanks for your kind words and the great suggestions :)

(S)RAM component: I've been thinking about it. The only reason I haven't implemented it yet is because you can always use a scripted component to implement something similar. The problem is that there are many types of SRAMs out there (sync/async, fall-through, pipelined, burst reads/writes, etc.) and I have to study them a bit more to figure out the proper way to implement such a component. And the only reason to actually implement it is ease of use (just drop a RAM in the circuit) and the ability to inspect its contents like ROMs. Other than that, I cannot see any other benefit over scripts. I can create a simple SRAM script for you to use if you want, until I figure everything out.

Wires and T-junctions: Unfortunately, I didn't understand your suggestion. You always start a new wire from an output pin. If you drop it on an existing wire, what I would expect to happen is to connect the output pin to the input the old wire is currently connected to. No T-junction can be created in this case (each input pin has only 1 source). What you suggest might have made sense if you could start a new wire from an input pin, but that's not the case currently. Am I missing something?

Regarding how the T-junction option of the context menu works. It creates an new wire from the old wire's output pin up to the nearest node/corner. The last line segment of the new wire is from the nearest node to the mouse cursor. I could kind of fix that by rounding the right click mouse location to the nearest grid location and add an extra node there, but it won't look good with wires crossing the grid at angles other than 45/90/135/180/etc. angles. Hope it makes sense :)

LEDs: There is a LED matrix component in the toolbar. You can create a 1x1 matrix and connect an 1-bit wire to it. Please correct me if I didn't understand your suggestion. Regarding changing the color of a LED matrix, I'll add it to my TODO list.

Wire thickness: Sounds good. Will try it and see if it'll look good too :) Will report back for feedback.

Thanks again for trying out DLS. If you have anything else to share I'll be glad to hear it :)

Replied to CAPTNCAPS in DLS comments

You are right. I've fixed it in the manual and forgot to fix the tutorial description...

To be more specific: Originally (pre v0.10) if a bus had more than 1 non-Undefined inputs, the output returned an Error value (red wire). On v0.10 I removed all Errors from the build-in components (tri-state buffers with Undefined control pin and the bus), and I thought I should make it work like it's described in the tutorial (first non-Undefined input got forwarded to the output).

But, apparently, I never did the change, so if a bus gets more than 1 non-Undefined input, its output is Undefined.

I'll fix the description for the next release. Sorry for the confusion and thanks for reporting the bug!

PS: Actually I think a bus should behave more like an OR gate, which ignores all Undefined inputs. It should just OR together all defined inputs and return that as the result. But I think this might break some existing circuits, that's why I'm still keeping the current behavior. If you have any thoughts on the subject, I'll be glad to hear them.

Replied to the_w in DLS comments

Hello again,

I just uploaded a new version (0.11.1) which includes this and a couple of other bug fixes.

Thanks again for the report.

Replied to the_w in DLS comments

You are right. There seems to be a bug with the bus component.

Managed to reproduce it so I will most probably be able to fix it. Will upload a new version as soon as possible!

Thanks :)

Replied to Dav48 in DLS comments

I'll see what I can do for the next release. Problem is that it's one more build on top of 4, that's why I avoided it till now. If I do a 32-bit Win version I'll also have to do two 32-bit Linux versions :)

Replied to seanj in DLS comments
(Edited 1 time)

Unfortunately I don't own a Mac at the moment. Somebody else is building DLS for me on OS X, so I doubt this is possible. Sorry for that. Hope you'll be able to try it out at some point in the future.

Replied to rjfwhite in DLS comments

No worries :) I'm just curious to see what other people build with DLS.

The only schematics I've seen are my own and I'm a newbie on the field (still learning as I go, adding stuff to the game I think will help me build more complex circuits easily). That's why any kind of feedback is appreciated!

Replied to rjfwhite in DLS comments

Hello again,

I'd like to inform you that in the latest version (0.9.0) I've added the ability to save and load ROM data to/from files.

In case you want to load your program into a ROM, save its byte code into a file with a ".rom" extension and place it inside the "roms" sub-folder (which is located under the current user's DLS data folder). You can then select your file via the ROM editor. Note that in case the ROM's size in bytes doesn't match the selected file size, you'll get a warning mentioning the number of bytes actually loaded.

Depending on your OS, the DLS data folder is located at:

  • Windows: %USERPROFILE%\Documents\DLS
  • Linux: The folder where you extracted the contents of the zip package.
  • OS X: ~/Documents/DLS
If the "roms" folder hasn't been created yet, you can create it manually. Otherwise, save a dummy ROM via the ROM editor, and it will be created automatically for you.
Hope it works better than pasting in the ROM editor. No need to convert your byte code to text. You can use the binary file generated by your compiler directly.

I've uploaded a new package (DLS v0.8.1 (Linux x64 - GCC 4.9.3).zip) with the executable built under Void Linux x64_86 with GCC 4.9.3. Tested it in a VirtualBox VM and it seems to work.

If you happen to test, please report back any problems you might encounter.

Replied to rjfwhite in DLS comments

Great! Do you mind sharing your schematic? :)

You are right about the ROM editor. It should support pasting, or some other form of input (e.g. load external files). In case of pasting the problem is the format of the string/data. The problem with loading external files is that a native open file dialog won't work correctly in fullscreen mode, and writing a full file browser with the current GUI is going to be a PITA :)

Until I figure it out, you can work around the issue by using a scripted component for your ROM as I did in the 6502 schematic for the Kernal ROM (https://github.com/jdryg/dls-schematics/tree/maste...). Either extract the component from the schematic or copy/paste the script into a new component. Then, Base64 encode your ROM and paste it into the script. It should work. You can even make your compiler generate the whole script and just paste the output into DLS.

Hope that helps for now. Thanks for the feedback!

Apparently Void seems to be stuck with GCC 4.9.3 (there's no official package for GCC 5.x). Rebuilding DLS with libstdc++ statically linked might help, but, unfortunately, I cannot comment on how long that'll take. I'll inform you once I find some time to work on it.

Sorry for the inconvenience. And thank you for your interest in DLS.

According this thread (https://forum.voidlinux.eu/t/why-is-void-still-using-gcc-4-9-3/420) you might be able to build GCC 5.2 from sources, in case you want to give it a try.

I forgot to mention that DLS has been built with GCC 5.2.1 (objdump -s --section .comment ./DLS) so you can try to upgrade GCC, if that's an option.

Can you please tell me which OS (incl. version) you are using in order to try and reproduce the error? I might have to link to libstdc++ statically, but before doing that, I want to see if I can find a better solution.

Also, can you post the output of the following command:

strings /usr/lib/libstdc++.so.6 | grep GLIB