Share your projects


I designed a mod for the gameboy pocket! I'm pretty pleased with how it turned out honestly.
It's a USB C and replacement regulator for the pocket. The thing I think is the neatest part of it is that it just solders in place using the existing solder pads on the gameboy.

I've got a more detailed write up on it here
View attachment 36785

That is pretty cool! Actually, could this be changed easily to work with the GameBoy Color?
McWill's LCD Mod includes a charging mod as well - however, it does not replace the full power circuit of the GBC, which is pretty flakey.
My own unit doesn't start anymore when I add the Charging mod and the new LCD.... it works if I only use the new LCD or only the charging mod with the old LCD, but both doesn't work.
And some customers had the same issue... so that circuit would need to be replaced.

I'd love to mass produce and offer such a USB Lithium-Battery mod which replaces the original power circuit, if possible. So if you'd be up for it, we could work together here .)
 
That is pretty cool! Actually, could this be changed easily to work with the GameBoy Color?
McWill's LCD Mod includes a charging mod as well - however, it does not replace the full power circuit of the GBC, which is pretty flakey.
My own unit doesn't start anymore when I add the Charging mod and the new LCD.... it works if I only use the new LCD or only the charging mod with the old LCD, but both doesn't work.
And some customers had the same issue... so that circuit would need to be replaced.

I'd love to mass produce and offer such a USB Lithium-Battery mod which replaces the original power circuit, if possible. So if you'd be up for it, we could work together here .)
A GameBoy Color version is actually in the plans! I've ordered the first batch of 50 for the gameboy pocket, so while I wait for those to arrive, I'll probably start development of the Pocket Power Color. Originally, I was considering not bothering with replacing the power circuit, since the Colors I have have been pretty rock solid, but, if that's actually an issue, modifying the Pocket version wouldn't be too terrible. The GBC just needs 3V, 5V, 13.6V, and -15V instead of the Pocket's 3V, 5V, and -18V rails.

I'm definitely interested in working with you! I have no good way of getting these to europe, and I'd love for people to have it there as well. When I get the design finalized, or close to finalized, we ought to discuss an arrangement of some sort.
 
I have written me a C64 sprite multiplexer
Whoa, I've checked a few of my fav karate games, but those look like original, selfmade sprites. Nice.
Australia looks a bit off to me.
Scanline-multiplexer?

 
  • Like
Reactions: rSl
Whoa, I've checked a few of my fav karate games, but those look like original, selfmade sprites. Nice.
Yep, all home grown (except an 8bit sorting routine). I may look to replace the PETSCII character set if I finish the actual gameplay...

Australia looks a bit off to me.
If only Australia does, then that ain't half bad ;-) My world map was drawn in probably a whole 20 seconds

Scanline-multiplexer?
Not entirely sure what a scanline multiplexer is. My raster splits move with the player sprites, as opposed to having fixed splits and the sprites drawn to fit

Thanks, I might have read those before, and I also headed to Codebase64 a couple of times, and arguably, I should just use a multiplexer written by somebody who knows what they're doing. TBH, I should have really worked the multiplexer in from the start, because the title screen and the player select both have static multiplexers and then the game features it's own dynamic (scanline?) multiplexer. It's sure is wasteful...

I considered stopping and asking for help a few times on various bits, or even dropping and rewriting a large chunk to use a single multiplexer throughout, I thought I'd just try and get the job done before worrying about how optimised it is. If I've got the memory for 4 multiplexers, then reworking everything into a single one is rather a waste of time... and to me time is currently more precious than the amount of RAM I'm using. That may change when it reaches 60kb in size, but I'll deal with that if it ever gets there.

I am also considering making SJKT64 open source too... It probably won't really be useful to anyone, because I imagine most coders who are still working on the C64 are far more proficient than my half-baked cobblings, but hey...

 
A GameBoy Color version is actually in the plans! I've ordered the first batch of 50 for the gameboy pocket, so while I wait for those to arrive, I'll probably start development of the Pocket Power Color. Originally, I was considering not bothering with replacing the power circuit, since the Colors I have have been pretty rock solid, but, if that's actually an issue, modifying the Pocket version wouldn't be too terrible. The GBC just needs 3V, 5V, 13.6V, and -15V instead of the Pocket's 3V, 5V, and -18V rails.

I'm definitely interested in working with you! I have no good way of getting these to europe, and I'd love for people to have it there as well. When I get the design finalized, or close to finalized, we ought to discuss an arrangement of some sort.
That's perfect, please do contact me when it's done :)
I can either simply resell it or handle the production as well (paying license fees) :)
 
Nice, I'll take a look at it later. I'll just mention that in your link in your last post you've replaced a hyphen with a full stop and hence it doesn't work. Anyone interested can find the right link in the previous post however.
 
Nice, in this line:

Code:
 with open(down_loc_file) as down_loc:
>    down_loc_out = down_loc.read() + "%(title)s.%(ext)s"

You could use os.path.join, if you first import os.path. Then it doesn't matter if you include the final slash or not, the code will automatically make a well formed pathname. Something like
Code:
import os.path
...
with open(down_loc_file) as down_loc:
    down_loc_out = os.path.join(down_loc.read(),"%(title)s.%(ext)s")
It might make more sense to use readline there rather than read, which as far as I'll know will read the entire file into the variable, and I'm not entirely sure what'll happen if you try to make a file with /n (or /r/n) characters in their names, but I'd expect it to be invalid. You might also be better off stripping the user input name in case they put a newline after the final line (if you continue the scrape the entire file in) although that might cause problems if their folder name legitimately ends with a space or tab.

I've written a similar program, although mine is designed to read links from a file, so that it can be run in the middle of the night when contention is lower. It's also written in bash, and also copes with multiple different programs I can use to download videos. I use a python program to kick off ffmpeg after using ffprobe to figure out if the video is too tall or too wide for my playback machine, or uses too fast an fps rate, or uses a codec that's not supported if I'm transferring stuff to be watched on my TV.
 
Many thanks for the file loading help. Would it be ok if I credited you in the readme file or would you prefer to remain anonymous?

Current code looks like this:

Python:
down_loc_file = os.path.join(os.path.dirname(__file__), 'download_location.txt')
with open(down_loc_file) as down_loc:
    down_loc_out = os.path.join(down_loc.readline().rstrip(),"%(title)s.%(ext)s")

I'm currently having a play with .rstrip() so that only newline characters are removed.
 
  • Like
Reactions: rSl
I think if you're using readline, you don't need to strip it. Readline should stop just before the newline, so it shouldn't be included. But in general, rstrip can be given a sequence of characters, so if you only want it to remove newlines should they somehow get in there you could do "".rstrip("\n").

I don't mind if you credit me or not. I consider this name to be pseudonymous enough.
 
I think if you're using readline, you don't need to strip it. Readline should stop just before the newline, so it shouldn't be included.

It isn't included if there's only one line in the file, but if there's more than one line then a \n gets appended to the end of the string.


I'm having a go at guarding against errors that occur due to people pressing enter once they've entered the download path into the file, then saving the file. I doubt most people will but there's always one.

so if you only want it to remove newlines should they somehow get in there you could do "".rstrip("\n").

I tried that method first and it seemed to work fine, the bit that I wasn't sure about at the time was, is it just \n that has to be removed or would it be wise to remove \r\n too. Though of course having thought about it, you just need to strip out \n due to it being the newline character that is returned by .readline().
 
Last edited:
It isn't included if there's only one line in the file, but if there's more than one line then a \n gets appended to the end of the string.

I'm having a go at guarding against errors that occur due to people pressing enter once they've entered the download path into the file, then saving the file. I doubt most people will but there's always one.

I tried that method first and it seemed to work fine, the bit that I wasn't sure about at the time was, is it just \n that has to be removed or would it be wise to remove \r\n too. Though of course having thought about it, you just need to strip out \n due to it being the newline character that is returned by .readline().
The argument provided to rstrip, despite looking like a string is really better considered a sequence of characters, or a set. I just tried "string\r\n\r\n".rstrip("\n\r") and it came back with 'string' indicating it doesn't really care about the order of characters, it just eats them until there are no more.

Edit: But yeah, seems I'd forgotten that readline actually ends after the newline, so you do need to strip it more often than not.
 
I took to using Rosegarden (a midi recording studio that includes wav recording). But there are not midi definition files for my keyboard (Yamaha EZ220) so I'm making my own.
There was a python script from someone, but that generates old definitions for an older version of RoseGarden and it's not on the web anymore. So I rolled my own Perl script.
I got all the voices, now need to export the drums from the pdf. Scratching my head though, but I'll figure it out.
Once done I'll try to push it off to RoseGarden.

= Creating a RoseGarden file for the Yamaha EZ220
First we download
Then we convert the pdf to html text, so it's a bit more workeable:
pdftohtml ez220_en_om_a0.pdf

Then we follow the procedure described in:

Here we know that MSB and LSB are:

A true program change that also selects a bank is composed of (3) MIDI messages:
CC 000 nnn (Bank Select MSB – Most Significant Byte)
CC 032 nnn (Bank Select LSB – Least Significant Byte)
Prog Change nnn (MIDI Program Change message 0~127)
 
I've uploaded the completed version of my image resizing tool that I first posted about here to my website.

Now instead of you just being able to shrink an image to a fixed resolution (while still preserving the aspect ratio), you can shrink either a single image or a folder of images to a resolution of your choice (while still preserving the aspect ratio).
 
Have updated my Lonely Tower story/game/thing to display passage titles, and it now also features a (completely unnecessary) HP bar.
The game is too linear for my taste.
 
Back
Top