Share your projects

[PCXT]

After moving to Linux I missed GUI for editing FAT disk images.
I can mount it. But if it's precious original floppy image any complex GUI file manager would destroy its free space needed for e.g. some historical analysis with metadata and preview programs with temporary files.
There is a command-line mtools program for nice, controlled access to DOS image.
So few months ago I started to do a quick interface for it in Qt to be shared on some GPL:

Current state is that it is usable, yet I think not enough for everyday use. Drag and drop doesn't work as it should (so extracting is made through a "Select folder" window) and code is far from being well-organized.

 

[jeeks]

some eclairs (last ones were soggy, these were awesome), fermenting-in-process kimchi, and sourdough bread tomorrow i'll tackle the burger-shaped macarons if i have time :3

 

[FBnil]

I thought Spanish readers could get along well enough without

yeah... but not without a ñ (Although there are very few words with uppercase Ñ).. can't keep everybody happy I guess...
[doublepost=1489240568,1489240329][/doublepost]

kimchi

yuck! (the eclairs look delicious though)

 

[jeeks]

yuck!

people told me it's smelly and all, but the first time i opened a can of kimchi, i literally stuck my nose in there because it smelled delicious i don't put it in my office lunches though (same with tuna salad cheese sandwiches and aioli dip) :3

 

[ClockworkCoder]

some eclairs (last ones were soggy, these were awesome), fermenting-in-process kimchi

Korean bibimbap is one of my favourites (at least the one my wife makes). Mouth-wateringly good.

 

[FBnil]

aioli

Ah... if you make your own mayonaise, then I have this suggestion: One-KAH-EENAH (huancaina) sauce

My version, which is different to the Peruvian one:
I omit all exotic ingredients though, I buy this fresh white cheese from the market (pretty salty and crumbly, so no extra salt required, and not much work to mix it)
make a mayo with egg yolks, mash some walnuts, mash some garlic, mix all together (if you have a food processor you do not need to pre-mash things).
(basically: aioli with white cheese and mashed wallnuts for texture)

The sauce goes well on oven potatoes that have been cooked unpeeled (but washed) in aluminum foil and with some thick salt crystals. It also complements a good steak. Which means you only need an easy salad: sliced tomatoes with red-onion rings, and lettuce-olives, for example.
[doublepost=1489325254,1489325145][/doublepost]

Mouth-wateringly good.

Does it look like this Bibimbap? Because that is totally delicious... looks spicy though...

 

[jeeks]

update on the kimchi batch (yes, i still have some left): i got to watch a small bubble bath-esque event when i opened one of the jars this morning! also, holy wow, that stuff burned my mouth in a good way fermentation magic plus chili is just lovely :3

bonus: the gases that were released alarmed my landlord who was visiting, and he checked the gas line and the sewage pipe under the kitchen sink for leaks

 

[ingoreis]

Maybe i can use this for Qemu IMG Files too?

 

[PCXT]

Maybe i can use this for Qemu IMG Files too?

Feel free to try, here is the code. Looks awfully, is missing lots of checks, but seems to work. There is a support to choose partitions from multi-partition FAT image files (however then saving may be disabled not to overload temporary directory - image can be open as read-only or in direct mode, when all changes are instant), I needed it when I had to mess with BOCHS images. If they're the same, it'll work. Just have a TestDisk around as it uses it extensively for getting partition table and of course mtools.

 

[JDTAY]

I just remembered my fantasy console project from this thread today. I think I might pick it back up. I'll probably simplify it a bit though. Get rid of or reduce the 225KB color background, get rid of the 256KB map data, leaving the amount of map data up to the user, and reduce the 512KB reserved for Lua bytecode. I think I want my file size for carts to be 128KB instead of a full MB. Might as well please myself; I bet I'll be the only one using this thing.

At first, I was thinking that the world doesn't need another fantasy console, but I'm bored and making a fantasy console would be easier for me than making an actual game, because at least I already know what I'm supposed to do; I just have to learn how to do it. With games, I can't seem to flesh out my ideas at all or come up with any really interesting original ones.

I kinda miss the Monster Rancher clone engine I deleted. Furthest I ever got along with a project. It had graphics, working menus, and its own scripting system, plus it taught me how to use polymorphism. It just was too unoriginal for my taste though.

 

[T.T.]

I nearly forgot about this thread.

This is what I've been working on for the past 2 weeks. I got my hands on a gameboy and decided to have it display onto my oscilloscope. I call it the AnalogBoy


I got this idea (and information) from the NintendOscope.
The interesting thing about the gameboy and other early handhelds is that their video signals are very similar to the signals needed for a CRT. In the case of the gameboy, it has 2 digital pins that determine the shade of grey (or green in my case) and horizontal and vertical sync pulses.

I figured it would be somewhat simple to use analog circuitry instead of a microcontroller (as is done in the NintendOscope) to generate the raster scan and brightness information the drive the oscilloscope. The circuit consists of two 555 timers acting as ramp generators. Each of these are triggered by their respective sync pulses to make a ramp. These ramp signals are fed into an oscilloscope running in X-Y mode to give a screen raster. As for the two digital pins, I just used a 2-bit R2R ladder to get the analog voltage needed.

So far it's turning out well. Right now I still have no clue why some of the sprites are broken up. I'm using the same two digital pins as the ones used on the NintendOscope and the weird sprites don't show up on the gameboy's original screen. Although did notice while poking around with the oscilloscope that there are two pins that seem to have similar signals as the two digital pins that I'm using. Perhaps they may fix the issue.

 

[rygD]

Fucking awesome! If you can't overcome that issue I know of someone that may have some info and be able to give some guidance, if he still messes with such things. I can't remember his name right now.

Which model GB are you using? Any plans to make it portable?

 

[T.T.]

If you can get me in contact with him, that would be awesome. I have no clue what the problem is.

I'm just using a DMG-01. It had some lines through the LCD so my brother took the shell and I took the guts. I actually have a 5 inch monochrome CRT from an old portable tv that I want to hook up to this. I'm going to make a little arcade cabinet scaled to the size of the CRT to make a mini gameboy arcade.

 

[rygD]

The DMG display connection was poorly designed, so it is particularly vulnerable to vertical lines. They are relatively easy to fix (temporarily). I can't remember signal flow through the device. Depending on what parts you aren't using, someone (me, for example) may be interested in them, especially if the screen can be salvaged. Regardless of all that, it seems to me that the DMG is the easier one to use for things like this.

I would love to see pics/videos of your little arcade thingy, including some in progress stuff. Is that portable tv one of those black and white ones? I think I have seen something like this, so if I come across it again I will post a link.

Give me a bit to look around for that guy I mentioned. I think his name was

Edit: I think I was getting a couple people confused in my head. While looking I found that both of those people might be able to help, although so far I don't see anything with them messing with the display...I could have sworn I saw a diagram of what each line does, but I can't find it right now. So I will keep looking. I am digging through forum posts, blogs, etc. to save you time. I also came across a mention of someone I was talking about recently in another thread (prolly the "What are you playing" one; I was talking about a GB cartridge reader/flasher), and that makes me think they might have been the one I was thinking of above that made something to get video out...or it could have been for a different model, or I could be thinking of one of a bunch of other projects.

Lemme know if you want me to just post names and links so you can look or contact them for yourself instead of me digging through all of this extremely interesting stuff to find what is relevant to what you want to do. So much nerdy greatness for those that love GBs!

 

[T.T.]

The DMG is definitely easier than what a pocket would be, plus they're pretty easy to come by. Once everything is done, I'll only be using the main CPU board of the DMG, the LCD will probably just be set aside and forgotten.

I haven't even started the cabinet for the arcade thing, I wasn't going to start that until I got everything working perfectly on the oscilloscope.

The tv was a black and white one. I guess I could do a color one, but they require higher voltages and slightly more complex circuitry.

So I made a post on the GBDev forums about my issue, and here's the answer I got

The Gameboy has inconsistent LCD timings. When it's drawing sprites, it takes a longer time because it has to fetch additional tile data for the sprites. This would not be acceptable on a console connected to a TV, since the TV's CRT beam will keep sweeping regardless. But the LCD signal in this case is asynchronous and is relying on a clock for timings. In other words, you can't really use a simple timed ramp, but you need to have some way of progressing the ramp one step when receiving a clock pulse.

That looks to be my problem. My circuit assumes that every pixel will take the same amount of time to be drawn, which for everything but sprites, is fine. So now I need to redesign my entire circuit.

The new circuit may not actually be all that hard. As said above, I need a circuit that would move the ramp over one pixel for every clock pulse. What I might be able to do is feed the clock into an 8-bit binary counter and then have that go through an 8-bit DAC which would give me the analog ramp signal needed. If this works the way I think it will, then the ramp will be perfectly in sync with the pixel data. I'll be sure to post again when I try this.

Thanks, and go ahead and post any information that may be useful, I need all I can get

 

[pmprog]

I spent some time at the weekend upgrading my Pimiga to a RaspPi 3 and 3D printing some holders
Just need to reconfigure all the software now

 

[rygD]

The DMG is definitely easier than what a pocket would be, plus they're pretty easy to come by. Once everything is done, I'll only be using the main CPU board of the DMG, the LCD will probably just be set aside and forgotten.

I haven't even started the cabinet for the arcade thing, I wasn't going to start that until I got everything working perfectly on the oscilloscope.

The tv was a black and white one. I guess I could do a color one, but they require higher voltages and slightly more complex circuitry.

So I made a post on the GBDev forums about my issue, and here's the answer I got


That looks to be my problem. My circuit assumes that every pixel will take the same amount of time to be drawn, which for everything but sprites, is fine. So now I need to redesign my entire circuit.

The new circuit may not actually be all that hard. As said above, I need a circuit that would move the ramp over one pixel for every clock pulse. What I might be able to do is feed the clock into an 8-bit binary counter and then have that go through an 8-bit DAC which would give me the analog ramp signal needed. If this works the way I think it will, then the ramp will be perfectly in sync with the pixel data. I'll be sure to post again when I try this.

Thanks, and go ahead and post any information that may be useful, I need all I can get

So the diagrams I found were poorer quality than the one at the link you gave, and no additional useful info for what you are doing was provided. It was basically all info relevant to double inversion of the stock screen to give higher contrast when backlighting. The interesting things I found, that may be useless for you, are that everything is labeled on the GB pocket board, and that everything is fairly identical with regard to the display signals on the pocket and brick (I think I knew that since I have seen people transplant a pocket screen into DMGs). I am not sure about the GB Light.

Anyway, here is a blog post of one of the guys I think might be able to help:
http://blog.gg8.se/wordpress/2009/11/23/how-to-patch-your-dmg-to-use-a-biverted-palette/

BennVenn is another person that might be able to help, however I haven't finished looking through all his stuff, so I will post a link later.

There might be others. Despite the main topic, chipmusic.org has lots of knowledgeable people, and that scene has pushed a lot of innovation (plus some new products for customizing), so it might be worth trying to get help there too if you don't otherwise find what you need to know.

I need to head out right now, but I will be back tonight.

 

[T.T.]

I'm actually using a hex inverter in my circuit for a similar reason for biverting. It makes a great buffer so that the signals switch more cleanly. Plus I needed to invert the sync pulses. I have a GB pocket that I backlit and biverted, in fact a GB pocket may even behave better in this circuit, but I didn't have an extra GB pocket laying around.

I came across BennVenn's site while I was searching for something unrelated. He has some good info.

Thanks for the help so far.

Also, I've ordered the necessary parts for the new circuit from digikey, so hopefully I get those before the weekend. I have a good feeling about the new design, it uses the same concept as a digital ramp ADC, so that made me feel better about it.

 

[erico]

I have been working on a Burger Time based game with more gravity action and 3 simultaneous single-computer players.
Sound is yet missing but everything else is pretty much done.

On the video, a couple friends are playing on the keyboard and joypad...I´m playing the green guy by my phone using a wifi joypad app.
Expect the green player to be constantly falling off platforms amongst other dumb stuff.

 

[ptitSeb]

Nice @erico ! Gameplay looks solid, and style is coherent and well done.