Forum comments in chronological order
Disclaimer: I am not responsible for what people (other than myself) write in the forums. Please report any abuse, such as insults, slander, spam and illegal material, and I will take appropriate actions. Don't feed the trolls.
Jag tar inget ansvar för det som skrivs i forumet, förutom mina egna inlägg. Vänligen rapportera alla inlägg som bryter mot reglerna, så ska jag se vad jag kan göra. Som regelbrott räknas till exempel förolämpningar, förtal, spam och olagligt material. Mata inte trålarna.
- Jun 2007
- Aug 2007
- Oct 2007
- Nov 2007
- Dec 2007
- Jan 2008
- Feb 2008
- Mar 2008
- Apr 2008
- May 2008
- Jun 2008
- Jul 2008
- Aug 2008
- Sep 2008
- Oct 2008
- Nov 2008
- Dec 2008
- Jan 2009
- Feb 2009
- Mar 2009
- Apr 2009
- May 2009
- Jun 2009
- Jul 2009
- Aug 2009
- Sep 2009
- Oct 2009
- Nov 2009
- Dec 2009
- Jan 2010
- Feb 2010
- Mar 2010
- Apr 2010
- May 2010
- Jun 2010
- Jul 2010
- Aug 2010
- Sep 2010
- Oct 2010
- Nov 2010
- Dec 2010
- Jan 2011
- Feb 2011
- Mar 2011
- Apr 2011
- May 2011
- Jun 2011
- Jul 2011
- Aug 2011
- Sep 2011
- Oct 2011
- Nov 2011
- Dec 2011
- Jan 2012
- Feb 2012
- Mar 2012
- Apr 2012
- May 2012
- Jun 2012
- Jul 2012
- Aug 2012
- Sep 2012
- Oct 2012
- Nov 2012
- Dec 2012
- Jan 2013
- Feb 2013
- Mar 2013
- Apr 2013
- May 2013
- Jun 2013
- Jul 2013
- Aug 2013
- Sep 2013
- Oct 2013
- Nov 2013
- Dec 2013
- Jan 2014
- Feb 2014
- Mar 2014
- Apr 2014
- May 2014
- Jun 2014
- Jul 2014
- Aug 2014
- Sep 2014
- Oct 2014
- Nov 2014
- Dec 2014
- Jan 2015
- Feb 2015
- Mar 2015
- Apr 2015
- May 2015
- Jun 2015
- Jul 2015
- Aug 2015
- Sep 2015
- Oct 2015
- Nov 2015
- Dec 2015
- Jan 2016
- Feb 2016
- Mar 2016
- Apr 2016
- May 2016
- Jun 2016
- Jul 2016
- Aug 2016
- Sep 2016
- Oct 2016
- Nov 2016
- Dec 2016
- Jan 2017
- Feb 2017
- Mar 2017
- Apr 2017
- May 2017
- Jun 2017
- Jul 2017
- Aug 2017
- Sep 2017
- Oct 2017
- Nov 2017
- Dec 2017
- Jan 2018
- Feb 2018
- Mar 2018
- Apr 2018
- May 2018
- Jun 2018
- Jul 2018
- Aug 2018
- Sep 2018
- Oct 2018
- Nov 2018
- Dec 2018
- Jan 2019
- Feb 2019
- Mar 2019
- Apr 2019
- May 2019
- Jun 2019
- Jul 2019
- Aug 2019
- Sep 2019
- Oct 2019
- Nov 2019
- Dec 2019
- Jan 2020
- Feb 2020
- Mar 2020
- Apr 2020
- May 2020
- Jun 2020
- Jul 2020
- Aug 2020
- Sep 2020
- Oct 2020
- Nov 2020
- Dec 2020
- Jan 2021
- Feb 2021
- Mar 2021
- Apr 2021
- May 2021
- Jun 2021
- Jul 2021
- Aug 2021
- Sep 2021
- Oct 2021
- Nov 2021
- Dec 2021
- Jan 2022
- Feb 2022
- Mar 2022
- Apr 2022
- May 2022
- Jun 2022
- Jul 2022
- Aug 2022
- Sep 2022
- Oct 2022
- Nov 2022
- Dec 2022
- Jan 2023
- Feb 2023
- Mar 2023
- Apr 2023
- May 2023
- Jun 2023
- Jul 2023
- Aug 2023
- Sep 2023
- Oct 2023
- Nov 2023
- Dec 2023
- Jan 2024
- Feb 2024
- Mar 2024
- Apr 2024
- May 2024
- Jun 2024
- Jul 2024
- Aug 2024
- Sep 2024
- Oct 2024
- Nov 2024
May 2021
lft
Linus Åkesson
Tue 4-May-2021 08:49
Linus Åkesson
Tue 4-May-2021 08:49
I am curious how to go about generating the robot voice on the PO-28. (demo here: https://www.youtube.com/watch?v=KloyDjmU2dQ&t=1266s). Also do you know if this feature made it into the PO-128 that was released a few months ago?
Thank you.
Thank you.
I'm afraid that voice recording wasn't created on the PO-28, nor the PO-128. They don't have that feature.
Anonymous
Wed 5-May-2021 21:42
Wed 5-May-2021 21:42
Thank you for clearing that up. Your work is admirable regardless (PO-128 is my favorite PO so far)! You seem like an exceptional polymath, may you continue to bridge the gaps between worlds.
I'm afraid that voice recording wasn't created on the PO-28, nor the PO-128. They don't have that feature.
lft wrote:
I am curious how to go about generating the robot voice on the PO-28. (demo here: https://www.youtube.com/watch?v=KloyDjmU2dQ&t=1266s). Also do you know if this feature made it into the PO-128 that was released a few months ago?
Thank you.
Thank you.
I'm afraid that voice recording wasn't created on the PO-28, nor the PO-128. They don't have that feature.
Pushing Onwards: Return of the Chipophone
Anonymous
Wed 12-May-2021 19:49
Wed 12-May-2021 19:49
So nice to hear one of my favorite songs played by Chipophone! I was wondering, could another favorite of mine be played with it? ..the decade of dekadence by britelite: https://www.youtube.com/watch?v=nliD-_kqH7I
Anonymous
Thu 13-May-2021 02:23
Thu 13-May-2021 02:23
It would be an impressive demo even at 4k. Squeezing it down to 256 bytes is a technical tour-de-force and thank-you for the detailed explanation.
Anonymous
Fri 14-May-2021 19:22
Fri 14-May-2021 19:22
Linus, just finished The Impossible Bottle and wanted to tell you how much I loved it! All the aha moments landed perfectly and I found the world charming and delightful. Congratulations on the win!
-Ward C
-Ward C
Anonymous
Thu 20-May-2021 00:09
Thu 20-May-2021 00:09
Awesome music!
Anonymous
Thu 20-May-2021 08:41
Thu 20-May-2021 08:41
I have loved this for many years and glad to see it is still getting love from publications. Such great work Linus.
Extended re-mix - pO2112,127:rU
-dave
Extended re-mix - pO2112,127:rU
-dave
Anonymous
Thu 20-May-2021 21:30
Thu 20-May-2021 21:30
Thank you for a touching, sweet, on-point game for 2020. It had good puzzles and an excellent plot/story/metaphor. It was worth every minute I spent (there were a lot of them, I'm embarrassed to say).
Anonymous
Fri 21-May-2021 23:33
Fri 21-May-2021 23:33
I somehow felt like when I think about the fabric of the universe.
It must be as purely simple as your code.
That's poetry — and I admit I understood probably 15% of your (extraordinarily thorough) explanation.
Thanks!
It must be as purely simple as your code.
That's poetry — and I admit I understood probably 15% of your (extraordinarily thorough) explanation.
Thanks!
Anonymous
Sun 23-May-2021 07:00
Sun 23-May-2021 07:00
The year is now 2021, and this was just featured on Hackaday. And this 49 year old kid who grew up with a PET and a C64 is absolutely delighted to see it.
This is an amazing piece of art. Thanks for the detailed description too. Now I need to play around with LFSRs and note tables for a while...
This is an amazing piece of art. Thanks for the detailed description too. Now I need to play around with LFSRs and note tables for a while...
Anonymous
Sun 23-May-2021 18:38
Sun 23-May-2021 18:38
It saddens me you still haven't released the music in its original format...
Yeah, even something as dumb as MIDI would be nice ;-;A case against syntax highlighting
Anonymous
Tue 25-May-2021 06:41
Tue 25-May-2021 06:41
You've fucked many fake developers who always think syntax highlighting is the key to increase their productivity.
Anonymous
Thu 27-May-2021 04:17
Thu 27-May-2021 04:17
Wow! Everything about this great. My girlfriend turned me on to your C64 + spring reverb work on YouTube and I loved hearing you turn a computer beep into a cathedral organ. As I wander your website, your projects are deeply inspiring.
Anonymous
Thu 27-May-2021 16:20
Thu 27-May-2021 16:20
I appreciate a lot your work!!
Anonymous
Sat 29-May-2021 17:28
Sat 29-May-2021 17:28
this is great. the stuff with the computer chips is also terribly cool.
Anonymous
Sun 30-May-2021 14:19
Sun 30-May-2021 14:19
This is better than originals, but they are good too. It's like desiring to hear real SID output because of all noises and distortions presented.
Anonymous
Sun 30-May-2021 17:22
Sun 30-May-2021 17:22
The first argument is assigned to y, the second is thrown into the recursive function, and x serves as an accumulator.
The recursive function checks if the bit at 2^30 (0x40000000) is set in the input number, and then multiplies it by 2 (same as << 1), and subtracts 1 from the passed in counter (which is set to 30) by subtracting it divided by itself. This will fail once the counter is 0 (divide by zero), triggering a stack trace, which prints out the order of the calls in reverse. Depending on the bits set, the displayed line will be different. line 5 if 0x40000000 is set, line 7 otherwise. Effectively, this creates a binary readout of argument 2, which the catch statement parses by turning the stacktrace into a byte sequence and looking for the values 0x35 and 0x37. If 0x37, y multiplies by 2 (same as << 1). If 0x35, y is added to the accumulator.
Since there is no break between these cases, both will execute in the 0x35 case, so effectively, either x increments by y *and* y shifts left by 1, or y shifts left by 1 and x stays put.
This effectively multiplies the first and second argument, but only if the bits in the second argument are all contiguous (and this is the part that doesn't quite make sense).
For example, `java Main 3 15` will set y to 3 and produce a "binary printout" of 15 in the form of stacktraces (55557777777...). Accumulator starts at 0, has 3 added to it, 3 becomes 6. has 6 added to it, 6 becomes 12, etc. 3 + 6 + 12 + 24 = 45. All well and good.
But this breaks the second you introduce a number with "holes" in it, like 9, or 5, or 13. `java Main 2 9` will result in 2 + 0 + 0 + 16 (because y doesn't stop being added to itself), which should print out 18. But it doesn't. It prints out 2. In fact, when the second number *isn't* a (2^n)-1, it invariably prints 2 regardless of the first and second argument, which based on the behavior, seems like a bug somewhere in the java toolchain.
But what do I know, I'm just a C programmer looking at a Java program.
The recursive function checks if the bit at 2^30 (0x40000000) is set in the input number, and then multiplies it by 2 (same as << 1), and subtracts 1 from the passed in counter (which is set to 30) by subtracting it divided by itself. This will fail once the counter is 0 (divide by zero), triggering a stack trace, which prints out the order of the calls in reverse. Depending on the bits set, the displayed line will be different. line 5 if 0x40000000 is set, line 7 otherwise. Effectively, this creates a binary readout of argument 2, which the catch statement parses by turning the stacktrace into a byte sequence and looking for the values 0x35 and 0x37. If 0x37, y multiplies by 2 (same as << 1). If 0x35, y is added to the accumulator.
Since there is no break between these cases, both will execute in the 0x35 case, so effectively, either x increments by y *and* y shifts left by 1, or y shifts left by 1 and x stays put.
This effectively multiplies the first and second argument, but only if the bits in the second argument are all contiguous (and this is the part that doesn't quite make sense).
For example, `java Main 3 15` will set y to 3 and produce a "binary printout" of 15 in the form of stacktraces (55557777777...). Accumulator starts at 0, has 3 added to it, 3 becomes 6. has 6 added to it, 6 becomes 12, etc. 3 + 6 + 12 + 24 = 45. All well and good.
But this breaks the second you introduce a number with "holes" in it, like 9, or 5, or 13. `java Main 2 9` will result in 2 + 0 + 0 + 16 (because y doesn't stop being added to itself), which should print out 18. But it doesn't. It prints out 2. In fact, when the second number *isn't* a (2^n)-1, it invariably prints 2 regardless of the first and second argument, which based on the behavior, seems like a bug somewhere in the java toolchain.
But what do I know, I'm just a C programmer looking at a Java program.
Anonymous
Sun 30-May-2021 17:26
Sun 30-May-2021 17:26
The first argument is assigned to y, the second is thrown into the recursive function, and x serves as an accumulator.
The recursive function checks if the bit at 2^30 (0x40000000) is set in the input number, and then multiplies it by 2 (same as << 1), and subtracts 1 from the passed in counter (which is set to 30) by subtracting it divided by itself. This will fail once the counter is 0 (divide by zero), triggering a stack trace, which prints out the order of the calls in reverse. Depending on the bits set, the displayed line will be different. line 5 if 0x40000000 is set, line 7 otherwise. Effectively, this creates a binary readout of argument 2, which the catch statement parses by turning the stacktrace into a byte sequence and looking for the values 0x35 and 0x37. If 0x37, y multiplies by 2 (same as << 1). If 0x35, y is added to the accumulator.
Since there is no break between these cases, both will execute in the 0x35 case, so effectively, either x increments by y *and* y shifts left by 1, or y shifts left by 1 and x stays put.
This effectively multiplies the first and second argument, but only if the bits in the second argument are all contiguous (and this is the part that doesn't quite make sense).
For example, `java Main 3 15` will set y to 3 and produce a "binary printout" of 15 in the form of stacktraces (55557777777...). Accumulator starts at 0, has 3 added to it, 3 becomes 6. has 6 added to it, 6 becomes 12, etc. 3 + 6 + 12 + 24 = 45. All well and good.
But this breaks the second you introduce a number with "holes" in it, like 9, or 5, or 13. `java Main 2 9` will result in 2 + 0 + 0 + 16 (because y doesn't stop being added to itself), which should print out 18. But it doesn't. It prints out 2. In fact, when the second number *isn't* a (2^n)-1, it invariably prints 2 regardless of the first and second argument, which based on the behavior, seems like a bug somewhere in the java toolchain.
But what do I know, I'm just a C programmer looking at a Java program.
The recursive function checks if the bit at 2^30 (0x40000000) is set in the input number, and then multiplies it by 2 (same as << 1), and subtracts 1 from the passed in counter (which is set to 30) by subtracting it divided by itself. This will fail once the counter is 0 (divide by zero), triggering a stack trace, which prints out the order of the calls in reverse. Depending on the bits set, the displayed line will be different. line 5 if 0x40000000 is set, line 7 otherwise. Effectively, this creates a binary readout of argument 2, which the catch statement parses by turning the stacktrace into a byte sequence and looking for the values 0x35 and 0x37. If 0x37, y multiplies by 2 (same as << 1). If 0x35, y is added to the accumulator.
Since there is no break between these cases, both will execute in the 0x35 case, so effectively, either x increments by y *and* y shifts left by 1, or y shifts left by 1 and x stays put.
This effectively multiplies the first and second argument, but only if the bits in the second argument are all contiguous (and this is the part that doesn't quite make sense).
For example, `java Main 3 15` will set y to 3 and produce a "binary printout" of 15 in the form of stacktraces (55557777777...). Accumulator starts at 0, has 3 added to it, 3 becomes 6. has 6 added to it, 6 becomes 12, etc. 3 + 6 + 12 + 24 = 45. All well and good.
But this breaks the second you introduce a number with "holes" in it, like 9, or 5, or 13. `java Main 2 9` will result in 2 + 0 + 0 + 16 (because y doesn't stop being added to itself), which should print out 18. But it doesn't. It prints out 2. In fact, when the second number *isn't* a (2^n)-1, it invariably prints 2 regardless of the first and second argument, which based on the behavior, seems like a bug somewhere in the java toolchain.
But what do I know, I'm just a C programmer looking at a Java program.
Never mind. I corrupted the code somehow. I tried it again with a fresh repl.it and it works as expected, i.e. Main 2 9 prints 18. So I understand the program perfectly well :)
-Braden