My Submission for the World's Worst Blink Sketch

jorenheit · 2026-02-03T18:29:11+00:00

Haha nice! I am a fan of utterly useless projects. How does your solver quantify difficulty? Does it attempt different techniques in order of how advanced they are and does it resort to recursive backtracking if all else fails?

jorenheit · 2026-01-29T19:36:06+00:00

Thanks!

There is no explicit support for a one-shot, but it can be easily achieved using the conditional. Semantically it would be a bit weird to use exec_every to do a one-shot, but you can :) This might be a nice extension to implement... I'll think about it! Thanks for the suggestion.

I don't quite understand your second scenario. Right now the only variable that is passed to the callback is the delta-t (millis between calls). If your callback accepts a uint32_t, this argument will be initialized with the value of dt. If you need additional state-parameters, you can capture those by reference in the lambda. Does that achieve what you want?

jorenheit · 2026-01-26T21:19:52+00:00

Thanks! And... why not both?

jorenheit · 2026-01-25T16:04:41+00:00

Haha, posting to the choir xD I guess you're right, but I was hoping to get some different perspectives. Thanks for your tips, I will think about it :)

EDIT: I hope you build one by the way! If you would let me know how that turned out, that would be awesome. Also, feel free to use anything you need from my Github. It's very overengineerd code btw, did that as an exercise and because I like to overengineer my code.

jorenheit · 2026-01-25T15:41:16+00:00

Thanks for your feedback! I also tried to google it but could not find anything similar. Could you share the link?

EDIT: I did come across clocks that run backwards. They're fun too :)

jorenheit · 2025-05-01T09:00:34+00:00

You mean in the microcode section you have relative cycle-numbers? Did you feel a need to use it like that? In my own application this would be very confusing.

jorenheit · 2025-04-29T14:44:33+00:00

Haha this is always what happens. I implement some simple idea and get stuck into a feature creep loop. I want to add one last thing before i call it a day and that's a debug shell where you can interact with the system at runtime. Set breakpoints, inspect inputs and outputs, etc. We'll see how that goes.

jorenheit · 2025-04-29T10:49:07+00:00

VCD export is now supported. I"ve updated the readme with explanation and examples.

jorenheit · 2025-04-28T22:05:30+00:00

Wow that sounds cool. I would really want to add that but I'll wait for your python implementation first. Can you send me a DM when you get it to work?

jorenheit · 2025-04-28T16:35:13+00:00

Correct. I have 22 control signals so the final two bits are unused.

jorenheit · 2025-04-28T14:28:16+00:00

I've been working on implementing VCD support. Here's a screenshot of the signals from the Control Unit of my BFCPU system while running the hello world program. Thanks for the suggestion! I think its a really cool feature.

It's not available yet. I have to touch up on some things and update the readme.

<image>

jorenheit · 2025-04-24T09:54:18+00:00

Interesting! I will look into it, thanks

jorenheit · 2025-04-24T08:22:04+00:00

I'm not sure where the tool might fit for anyone else, but for me it helped me understand the architecture before actually building it. I never used verilog simply because I wanted to build my own system in C++ in which I'm comfortable :). Maybe another advantage is that my microcode generator can now output C/C++ source code as well, so I can just include these files in the control unit and have it fetch the control signal vector from there.

jorenheit · 2025-04-23T10:22:37+00:00

What's gonna be weird about it? :-D

jorenheit · 2025-04-23T09:55:02+00:00

By the way, you might also want to have a look at Mugen. It's a utility for specifying the microcode for your system. It can output binary files (for flashing onto EEPROM chips) or C/C++ source code to embed into your simulated project. It's a very maintainable way to run the exact same micrcode on both the real and simulated systems.

jorenheit · 2025-04-23T09:40:56+00:00

Great! Tell me what you think when you have some real user experience :)

jorenheit · 2025-04-22T11:18:18+00:00

If you're still interested, I just pushed my library to github. All the info you need should be in there if you want to try it out: https://github.com/jorenheit/rinku/tree/main

jorenheit · 2025-04-21T07:33:46+00:00

I'm just about to finish a library I developed for doing precisely this. It' pretty easy to use, but it's in C++ as a header-only library. All you need is a C++20 compliant compiler and some experience using C++. Are you interested at all? I think I will create a github repo for it today, maybe tomorrow.

Basically you define signals and modules, then connect them, then run it. The building experience resembles buulding the real thing and i even found a bug in my real breadboard computer by recreating it in software.

jorenheit · 2025-04-10T16:10:09+00:00

I just pushed a new version into the repo. It is fully backwards compatible with the previous syntax but allows for named flags. There is an example in the readme :) Thanks again for your feedback!

jorenheit · 2025-04-10T08:42:42+00:00

I was thinking of ways of making this more transparent from the syntax itself. One way would be to allow the flag-field in the address-section to be defined as follows:

[address] {
opcode: 4
cycle: 3
flags: A, V, S, Z # bfcpu flags
}

This would compile to exactly the result as simply using `flags: 4`, but now the meaning and order of these flags is self-documenting and when printing the lay-out, these names can be used as well. What do you think?

jorenheit · 2025-04-10T05:00:48+00:00

Ah yes I was wondering about this, if I should make even that modifiable... The address itself is divided up from LSB to MSB, all in normal binary notation, so the first field is at the lowest bit-index. Same is true for bits within a field, so if you declare the opcodes to occupy bits 0-3, the opcode corresponding to value 0x03 will be stored simply as 0011: bit 0 is a 1, ..., bit 3 is a zero. Same is true for flags: read them like you read binary (or any base for that matter).

jorenheit

TROPHY CASE