ARM9/bass 106

fork of byuu's bass assembler

KatDevsGames/z3randomizer 42

Zelda 3 Randomizer Template ASM

qwertymodo/MSU1-Zelda 10

ASM hack to implement MSU-1 functionality in Zelda 3, enabling playback of CD-quality soundtracks.

qwertymodo/msupcmplusplus 8

A native libSox implementation of the msupcm tool

qwertymodo/foo_input_msu 7

MSU-1 PCM audio input decoder for foobar2000

qwertymodo/ChronoTrigger-MSU1 6

ROM Hack that adds support for playing CD quality music in Chrono Trigger using MSU-1. I also hope to play the FMV from the PS1 version.

qwertymodo/ct-anime-intro 3

Chrono Trigger with anime intro (MSU1 hack based on smkdan's work)

qwertymodo/Mercurial-Magic 3

MSU-1 pack manager and exporter

qwertymodo/msupcm 3

Simple script for generating MSU-1 PCM audio files from source tracks

issue commentguysoft/OctoPi

"No wireless interfaces found" on RPi 3B v1.2

No, I would still consider this an open issue. Even if the root problem is caused upstream, if there is a working version of the upstream image, that image should be used here. I'm still working on trying out different versions to figure out where the break occurred.


comment created time in 21 days

issue commentguysoft/OctoPi

"No wireless interfaces found" on RPi 3B v1.2

I've just confirmed that the issue also exists in the upstream image 2020-12-02-raspios-buster-armhf-lite. Going to try the latest upstream image and see if that fixes it, and if not, I'll try rolling back and see if I can figure out where it breaks.


comment created time in 21 days

issue commentguysoft/OctoPi

"No wireless interfaces found" on RPi 3B v1.2

I just went looking for the older version of RaspiOS that OctoPi 0.18.0 is built on so I could test on that (looks like it was 2020-12-02-raspios-buster-armhf-lite). I'll report back once I'm able to get that installed. This pi has been running off of WiFi just fine on an old Raspbian build for a couple of years now until I pulled it down to install OctoPi this morning. Power supply and power cable are both tested as good, with this Pi on its previous OS, as well as another Pi 3 just to be sure.


comment created time in 22 days

issue openedguysoft/OctoPi

"No wireless interfaces found" on RPi 3B v1.2


Also read the FAQ:

This is a bug and feature tracker, please only use it to report bugs or request features within OctoPi. If its not a bug please use the community forum:

Do not seek support here ("I need help with ...", "I have a question ..."), that belongs on the community forum at, NOT here.

Mark requests with a "[Request]" prefix in the title please. For bug reports fully fill out the bug reporting template (if you don't know where to find some information - it's all described in the Contribution Guidelines linked up there in the big yellow box).

When reporting a bug do not delete any lines from the template. Its here to help you report relevant information, and the help text will not be displayed.

Thank you! -->

What were you doing?

<!-- Please be as specific as possible here. The maintainers will need to reproduce your issue in order to fix it and that is not possible if they don't know what you did to get it to happen in the first place.

Ideally provide exact steps to follow in order to reproduce your problem: -->

  1. Fresh install of OctoPi 0.18.0 from the official installation image on a Raspberry Pi 3 Model B (v1.2)
  2. Configure octopi-wpa-supplicant.txt with network config copied from a previous working installation (running 0.17.0)
  3. Boot the Pi
  4. No network connectivity
  5. Run raspi-config > 5 Localisation Options > L4 WLAN Country
  6. Result is "No wireless interface found"
  7. Run ifconfig
  8. Interfaces eth0 and lo are the only ones listed, no listing for wlan0 (or any wlanX interfaces)

<!-- If you encountered a problem with specific files of any sorts, make sure to also include a link to a file with which to reproduce the problem. -->

What did you expect to happen?

I expected WiFi to work properly, or at the very least for the wlan0 device to be detected so I could troubleshoot further.

What happened instead?

WiFi does not connect, and the OS doesn't seem to believe that any wireless interface exists at all, despite the one built into the board. This seems to be a problem with the underlying OS image used, and nothing to do with OctoPrint.

Did the same happen when running OctoPrint in safe mode?


<!-- Test if you can reproduce your problem in safe mode. You can find information on how to enable safe mode in the Contribution Guidelines.

If you can't reproduce in safe mode, this is a bug with one of your installed third party plugins. Don't open a ticket here!

If you can't test this in safe mode, state why. -->

Version of OctoPi

<!-- Can be found in the lower left corner of the web interface. ALWAYS INCLUDE. --> 0.18.0

Printer model & used firmware incl. version

<!-- If applicable, always include if unsure. --> N/A

Screenshot(s)/video(s) showing the problem:

<!-- If applicable. Always include if unsure or reporting UI issues. --> N/A

[X] I have read the FAQ.

created time in 22 days

issue commentUltimaker/Cura

Allow Bridge Skin Density > 100%

Thanks for that link. It's still a feature I'd like to see upstreamed.


comment created time in a month

issue commentARM9/bass

arch local constants

This is kind of possible already via the use of namespaces.


comment created time in a month

issue openedUltimaker/Cura

Allow Bridge Skin Density > 100%

Is your feature request related to a problem?

When printing a bridge, the lack of a previous layer to press the lines flat means that they are "taller" than usual, and therefore "narrower" leading to gaps between lines on the first (and sometimes second or more) layer of the bridge. In order to counteract that, it would make sense to print the lines of a bridge closer together than normal. There is a setting which affects the line spacing of bridge areas, called "Bridge Skin Density", but it is limited to only accept values <= 100%, and anything > 100% results in a slicing error.

Describe the solution you'd like

It seems like this is just a hard-coded limitation that refuses to accept any value over 100% for this setting. I think this restriction should be removed to allow bridges to be printed with lines closer together.

Describe alternatives you've considered

There is another setting "Bridge Skin Flow" that can be set to > 100% to fill in these large gaps, but high flow in bridge lines causes other issues, like additional sagging, and slower cooling, so in a lot of cases, it would be better to print with reduced flow rate and increased density.

Affected users and/or printers

Affects all printers/users when printing models that include bridge geometry.

Additional information & file uploads

No response

created time in a month

issue commentNationalSecurityAgency/ghidra

Unhandled NullPointerException in GhidraHelpService.install

Ok, so I've finally had a chance to try generating a new Eclipse project the way you suggested, and the error did not occur. I will try to diff out the project directories and see if I can figure anything out from that.


comment created time in 3 months

push eventqwertymodo/msupcmplusplus


commit sha 719b8732de265a6ed9050d79c763f87fbfd1a80f

Add missing linker libraries on Linux build

view details


commit sha 5976628905c484369fa086c3ad12f79fecd8bd22

Fix broken unicode handling on linux I am not proud of this code. I don't care.

view details


commit sha 5de1a7550874bafed6881ab9bbb7e27a1cdf7496

Update version number

view details

push time in 3 months