s-ol @s_ol@merveilles.town
tinkering between hard- and software, research and development, audio- and visual...
Joined Dec 2018
Pinned post
...and 6/6.
Today we're announcing 0xC.pad!
Sign up for updates and fill out the feedback form here:
https://docs.google.com/forms/d/e/1FAIpQLSccvUj4WobsxLP0yTdObMYbdXgTbWaAEnlu7WoOhmo262PaQA/viewform
Or read on for longer-form information: https://www.reddit.com/r/mechmarket/comments/kgyes2/
Again all credit for this amazing clip goes to Ilja Burzev. Also thanks to everyone for the encouraging comments in the last months! RTs are much appreciated also :)
hey, can someone *please* come out with a nice set of 2x d16 labelled 0-F so I can start rolling my colors and pointers?
I can only find ones labelled 1-16 like some normal people would use :(
made a SubV / #riscv ISA reference sheet for all the common mnemonics and their values:
I almost found this out by debugging in GDB way in the beginning, but I think I broke off my testing 10s before realizing. Could've saved myself a lot of hard thinking, IRCing, code reading etc... Oh well :)
So when I was enterng characters, they were arriving in my program, but I wasn't aware that it was my responsibility to send them back out in order to show up on screen.
And when I hit enter to confirm the input, the result also didn't show up, because of the CR/LF thing.
So I assumed input wasn't working at all, when in fact input was working fine the whole time.
2) I didn't really understand the I/O convention with serial port communication: with UNIX tools, what you type is echo'ed back by the shell, and the output of the tool is intermixed (unless the tool requests otherwise). I thought this was supposed to work with my bare-metal code through qemu as well.
But actually how PC-serialports/terminals work is you just "fire and forget" your input at it, and the terminal sends back what should be on screen.
This was *deep* yak shaving territory.
In the end there was only two small issues/misunderstandings:
1) qemu sets up the terminal to send only CR, not CRLF or LF (which I expected). By piping in from `cat` I was forcing a LF; but when I typed things my code never got to the part where it continues to print the response.
Finally got underneath the mental knot/misunderstanding that prevented me from having Serial input in my SubV test program, after three days of a wild goose chase.
First I thought I was doing something wrong with the virtual Serial port hardware; then I thought there was some magic qemu stuff I might need to trigger, or perhaps an ANSI escape sequence... At some point I compiled a RISC-V Linux kernel and busybox initramfs just to see that input works there!
@akkartik what kinds of debugger support have you built for mu and SubX?
I'm looking around and the ELF/DWARF formats are looking pretty annoying tbh.
I'm thinking at this point it would be worth at least to put the labels into the ELF file as symbols, so that one can at least see *where* in the code one is...
Then it would be nice to have the source code mapped using DWARF but maybe that's just not worth the effort.
cc @akkartik
Turns out my last level of comprehension, and also syntax proposal, was still flawed - mainly because you cannot simply bit-slice signed numbers.
The solution was to split the "format" pass into two, and do the earlier half *before* "survey" runs.
This way there is no need for a slice-syntax at all anymore!
Finally got through to the end of the last SubV refactor: I added a new pipeline stage and everything makes much more sense now - including long jumps :)
I also played with UART/Serial input for the first time now, writing slightly more complex SubV programs, like this little guy:
yiiiikes... my phone just proposed an article titled "Don't believe the hype: organic produce is not healthier than conventionally-grown vegetables" (did not click).
Then I saw the source is called the "genetic literacy project" and guess what... it's Monsanto!
I see beginner programmers run into this issue / ask this kind of question a lot.
Are there any resources to point to for these kind of mental speedbumps?
The concrete solution is obviously language dependent, but I feel like there is a lot of conceptual understanding and exposition that has to go into a good answer here.
When you see an email in your "drafts" section and try to remember what that was about again
Now in the moving case, seen from the carts frame of reference:
If the cart is moving at the speed of the wind, there is zero wind speed behind the cart. The wheel/propeller link converts some of the kinetic energy of the cart and spins, so the propeller blades are pushing backwards onto the wind, essentially creating the velocity differential.
With a simple sail at no velocity relative to the ground, and a tailwind, the wind creates a force on the sail pushing forward.
The wind essentially has a forwards velocity and the sail has a zero velocity, so the difference is equal to the wind velocity and causes a forward force. Since this is in the grounds frame of reference, the ground has a zero velocity.
https://www.youtube.com/watch?v=jyQwgBAaBag
Interesting Physics Counter-Intuition thing. Can't say that I am sure I understand how it works, and I'm not going to comment on youtube and get spammed with replies for the next three weeks, but I am building an intuition that's different from that proposed in the video and comments I've seen so far, so curious if it makes or doesn't make sense to others:
tinkering between hard- and software, research and development, audio- and visual...
Joined Dec 2018
