A place where I can ramble about my projects.

MiniDragon Homebrew CPU Early Progress

March 27th 2020, 2:05:46 pm

Progress has continued on my MiniDragon Homebrew CPU at a fairly linear pace. I'm well on my way to a very early bring up. Lots of things have been cemented and I am narrowing in on the final physical layout for lots of parts! Since my last blog post a month ago I've made a ton of progress on both the hardware and software side of things, validated a bunch of assumptions and tested a giant chunk of the existing design individually. I have yet to do a full integration test but I am getting very close to having enough of the CPU built in order to start that process!

Physical Assembly and Layout

The current plan for the physical towers of components. The bold text represent finished sections.

At the end of February several major components were out to fab and I had no design for the CPU itself outside of the simulator. In order to get an accurate part count I started putting together a high level block diagram for the whole thing. Dispite a lot of limitations and bugs, I decided to do this in KiCad. The advantage is huge: I have a block diagram where each component can be opened up and inspected, all the way down to an individual transistor. So MiniDragon is about as fully documented as is possible. I have yet to finish all of the diagrams but they are already complete enough for me to have built six components of the CPU as well as create a microcode programming generator program. If you are curious, the block diagram is up on github, along with everything else in this blog entry!

I've continued assembling circuits as they come back from fab. Progress has shifted from initial board bring-up on the first board of a design to bulk assembly of boards. I've been building components as fast as I can in order to get enough boards to build out the various high-level components of the CPU itself. Since the last blog post I've assembled nine Rev. 2 D/T flip-flops, almost a dozen simple logic gates, a few 1-to-2 decoders and 2-to-4 decoders and and a handful of the 4-bit register circuits. On the completed components I count 24 logic boards, flip-flops and demultiplexer circuts and another 24 breakout boards used to bring connections out to the edge of the 1'x1' component boards.

Assembling the D/T flip-flops to be used in the microcode counter board.

As for the components themselves, I have assembled the B and D registers (seen below on the right), the instruction register, the flags circuitry, the microcode counter (seen below on the left) and the data bus (below in the center). The pieces of each of these that interface with each other have been connected as well. Each board has been verified in isolation to ensure that it performs as specified. However, without the beginnings of an instruction decoder any test to verify that the components play well with each other will be meaningless so I've held off for now. I'm sure I'll find stuff during integration and bring-up but that's how every project goes. I'm extremely excited to be very close to this, however!

Current layout of completed components.

The block diagrams also include the wiring for control signals coming out of the instruction decoder. My current design revolves around a bunch of 32-bit ROM boards which are programmed using jumpers and collected through a pull-down open-collector bus. That means that I have plenty of room to represent the 29 control signals as reprogrammable microcodes per-instruction. It also means that I now have a physical location in ROM for each of the control signals. With that I've been able to write a utility that takes the instruction classes in the current simulator and spits out a microcode programming guide for each instruction, telling me how many microcode entries each instruction needs as well as where to put the jumpers in order to make the instructions work correctly. This also means that any modifications I make to the instruction set in the simulator can be quickly reflected in hardware. This will surely come in handy as I continue to iterate on the instruction set.

Software and Opcodes

The instruction set itself has changed little since the last blog post but the changes I have made unlock new processing power. I made some minor adjustments to the ADDPC/SUBPC instructions, renaming them to ADDPCI/SUBPCI (the I standing for immediate, to bring them in line with the other immediate-based instructions). I also added a new 4-bit sign extended immediate register to complement the 6-bit one that currently exists. This allowed me to optimize the ADDPCI/SUBPCI instructions in terms of clock cycles per execution as well as remove the need for 29 ROM boards! This doesn't seem like much, but the overall speedup to the standard library was around 7% and a few of the worst algorithms were sped up by over 20%. Also, the ROM boards themselves are massive and thus expensive, so reducing my need by such a large number of boards is huge!

Measurements taken in the simulator before and after the ADDPCI/SUBPCI change.

Renaming the ADDPC/SUBPC instructions to ADDPCI and SUBPCI opened up the ADDPC namespace for a new instruction that can adjust the PC register by a signed offset stored in the A register. I originally added this instruction to rewind string pointers for strcmp/strcat/strlen/strcpy functions in the standard library. However, after finishing the implementation I realized that it also unlocks indirect memory addressing. This means doing object-oriented operations as well as array lookups and jump tables become much, much faster. It was always theoretically possible to increment/decrement the PC in a loop, but this takes operations that could potentially be thousands of clock ticks down to a single instruction and makes it feasable to use in practice. Much like introducing SKIPIF gave me turing completeness and introducing PUSHIP/POPIP gave me subroutines, this single instruction gives me yet another degree of power to write complex algorithms!

On the software side of things, I've been hard at work fleshing out the standard library for MiniDragon. I've been coding up a host of useful basics that one might expect in a stdlib, such as atoi/itoa, strlen/strcpy/strstr/strcmp, cmp/add/negate/multiply/divide and processor initialization routines all of which are up on github. This has been an enormous amount of fun! I love nothing more than writing a standard library from scratch on a new CPU architecture that doesn't even exist physically yet! It has also been extremely valuable. The changes I've made to instructions that I detailed above came directly out of this exercise. In order to make the standard library as useful and comprehensive as possible I've been making sure that all the functions are fully tested and side-effect free from the perspective of the caller. That meant, in the case of the string functions, adding the ADDPC instruction in order to facilitate this! It has also been a huge relief to see that it is indeed possible to do real-world, useful things with this CPU and that it is not just a physical build of a toy instruction set.

Finally, in the process of writing the standard library I've made a lot of progress refining the toolset that comes with MiniDragon. I've made a boatload of improvements to the assembler, fixed several small bugs in the simulator and added additional utilities such as a function visualizer and the aforementioned microcode ROM programming generator. The processor test suite now includes validation for many classes of errors that the assembler should generate and the assembler is much more helpful in attempting to communicate why something isn't valid. This has been especially valuable in tracking down when JRI instructions reference labels outside of the 31 byte jump boundary. The simulator frontend now allows step-over-function debugging as well as run until return debugging in tandem with the existing single-step. And finally, the assembler supports much more powerful constant definitions, including the addition of the ".char" and ".str" directives for data embedding as well as support for using character literals as parameters to instructions. This has allowed me to keep the standard library fairly readable (as readable as a low-level stack-based CPU can be) while also using fewer instructions for referencing constants.

Screenshot visualization of strlen, showing stack tracing for PC and SPC registers.

What's Left?

Of course, I'm nowhere near done! I've had a few expected setbacks and for everything I finish two more things magically show up on my TODO list. The AND/OR gates that I put together to make the microcode counter board ended up not working in-circuit so I had to submit redesigns of them to fabrication before assembling the microcode counter board. Some of my seemingly simpler components were revealed to be more complicated once I block diagrammed them which meant that I had to submit more fabrication requests. And, of course, assembling the 4-bit register boards is still a very long process. I have gotten the time down from about 3 hours to an hour and twenty minutes. I have also refined my soldering technique which has resulted in far fewer parts coming up wrong during bring-up, reducing the need for time-intensive debugging sessions. However, I still have 14 more boards to assemble, so at the current rate of assembly that's about 20 hours of soldering!

Stack of register boards awaiting assembly and bring-up.

If assembling enough 4-bit register boards to complete the PC, IP and A registers wasn't enough, I also have hours upon hours of additional things to tackle before I'm on the home stretch. The microcode programming boards and the control signals termination and distributor board are all with oshpark right now. When they arrive, I'll need to bring them up and ensure they work as expected before I order a ton more ROM boards. I have another 30 bus output boards coming from fab which will be used for everything from the general purpose registers to the immediate register and the ALU. I also need to start the design of both the ALU and the external memory interface circuitry which will talk to the external RAM, bootROM and external hardware. I also need to decide on that external hardware in order to work on IO routines in the standard library. Right now I am leaning towards a simple LCD for debug messages and an 8-bit serial chip to provide standard in/standard out. It might never happen, but I'd love to pair this thing to a VT-100 like some old mainframe. And finally, I need to continue working on the standard library. I have yet to code memcpy, memset or memcmp. These will be similar to the existing string functionality. I also need to create 16-bit and 32-bit versions of the math and conversion libraries, and also handle 8-bit, 16-bit and 32-bit signed variants of the math library. And finally, once I standardize on the IO itself, I'll need to create access routines and start working on a basic shell to place in the bootROM.

As I get closer to the physical realm one thing is becoming clear: I need to finish this. If I don't, and get to 80-90% done before calling success, I am going to miss the other 80-90% of the process. I am not interested in software-only theoretical CPUs, I want a real life stack of hardware that executes software I wrote for it, built from the ground up. It is going to be a lot of hand-soldering and a lot of patience, but it is going to be VERY worth it!

Transistor CPU Part Fabrication

February 26th 2020, 4:25:26 pm

I've been working on the Transistor CPU for a few months now, which I've dubbed the MiniDragon. Since the last blog post I've changed a few minor things and nailed down a lot more of the CPU. I have a much more complete simulator, an assembler and disassembler and the beginning of a software library for an upcoming boot ROM. The CPU now has subroutine and stack instructions as well as an absolute jump, making it possible to write a reasonable library of built-in functions. Through writing a multiply subroutine I learned a lot about my chosen instruction set and have made several changes to the CPU as a result. I'm a lot more confident in the instructions since I've implemented actual software with them. That software, as well as an up-to-date description of the CPU itself, is available on GitHub.

Fleshing out the simulator allowed me to get a much better handle on the CPU itself. However, I only spent a small amount of time working on the software side of things. The majority of my time over the last few months was spent learning KiCad, digitizing schematics that I've tested on breadboards, laying boards out and sending them out for fabrication. I've been using Oshpark for fabrication since it can take pcbnew files directly and is cheap enough for small runs of boards. The boards are also my favorite color: purple! I started out with some simple logic gates that I'd breadboarded over Christmas: NOT, NAND and NOR. These aren't super interesting and they only consist of a few discrete components. However, they let me learn the ropes of KiCad before I undertook some more complicated design and routing projects like a 4-bit register.

Probably the hardest part of the last few months was being patient. As soon as I finished board layouts I wanted to throw them over the fence and get them fabricated. However, since I've never done PCB layout and fabrication before I was sure that I would make a ton of mistakes. So, I forced myself to send out small batches and observe everything that I did wrong before sending additional boards to fabrication. This paid off heavily, as I made a few mistakes that I had time to correct before it cost me unusable boards or ugly rework. It also allowed me to pace myself with board assembly, since I underestimated how much time it would take to assemble through-hole circuits.

A few specific things that I learned during this process stand out. First is to always ensure that you silkscreen the circuit title AND revision to the board. If you change component values or layout significantly, you will want to know what revision the board is in order to assemble it properly. You might be 100% sure that you will always recognize your boards, but manufacturing can take a few weeks and by the time it comes in you won't remember. I messed up my first board and forgot to silk screen it at all, so I ended up affixing labels to the circuits.

Rev 1 NOT gates with missing skilk screen.

Second is to make sure to space headers on the board apart by a multiple of the pin spacing. I chose to use 2.54mm (0.1") pitch pin headers for all of my circuits. Especially when you are dealing with 1x1 headers, it can be next to impossible to correctly insert the pin and solder it while making sure that it is plumb and square against the top of the board. However, if you have a row of multiple sets of pin headers, spacing them apart by a multiple of the pin pitch (2.54mm in my case) means that you can use a long pinsocket as a temporary holder in order to line up all the pins at once. I happened to do this on accident on my first board and was super glad that I learned this before sending out the next batch in which I had not lined up the pins at all. I use a 40-pin pinsocket as my assembly template and plug in the pin headers to it before soldering them all in one go.

Third is to use the rendered top copper and bottom copper layer photos on Oshpark. I had one board where a trace was routed far too close to a through-hole connection and another which had spurious traces. Neither of these were caught by pcbnew's constraint checker and I missed them looking at the PCB in pcbnew itself. Seeing your circuit in a new light is a super good time to check for errors. I definitely get a bit blind to errors in my layouts due to staring at them for so long while I put them together. So, a different look at the same boards has let me catch issues before sending to fabrication.

Finally, your breadboard designs might not work when laid out on an actual PCB. I arrived at values for my clock edge detection circuit when breadboarding which did not actually work when I assembled my first revision T/D flip-flop. I ended up having to do a really gross rework to verify an updated design. Luckily, I held off on sending a 4-bit register to fabrication which was based off this flip-flop. Only once I got the second revision of the flip-flop back from fabrication and verified that it worked did I send the 4-bit registers out. As a result, they worked fine! Given their size, it would have been a costly mistake had I not waited and verified. A secondary advantage to reworking the circuit was that I got to reduce the resistor part count from 4 distinct values to only 3 on clocked circuits. This makes assembly a lot easier and means that I can keep fewer parts on hand.

Nasty rework done to fix a hardware bug in the Rev. 1 T/D flip-flop.

I have a fairly decent library of logic gates and CPU components fabricated and verified on the bench at this point. I have my staples, like NOT, NAND, NOR, XOR, XNOR and a T/D flip-flop (behavior can be changed with a jumper). I am waiting for fabrication to finish on some AND and OR gates. Some of the CPU microcode logic requires them and I don't want to waste physical space and propagation delay chaining NAND/NOR circuits to NOT circuits. I have a few more useful circuits such as a 1-to-2 decoder and 2-to-4 decoder. Naturally, these can be chained to make a 3-to-8 or 4-to-16 decoder which I will be using in the instruction decoder and microcode lookup circuits. I also have a few parts that I'll use for the actual CPU designed and tested. I settled on a pull-up, open collector bus architecture due to its ease of coupling multiple driving circuits. To support that I have a few 8-bit bus backbone circuits that provide current bus value indicator LEDs and pull-up resistors as well as a ton of 8-pin headers. I have an 8-bit bus writing circuit that has an 8-pin input header and an enable control signal and an 8-bit output header designed to plug directly into a bus. Finally, I have a power on reset and clock circuit that provides automatic and manual reset as well as automatic (adjustable speed) and manual clock pulses.

Lots of completed and verified circuits!

Most of the above circuits are fairly boring in their implementation. The logic gates are similar in design to any RTL circuit you can find online. The bus circuit is just a bunch of pull-ups and a few buffered transistors driving LEDs. The bus writing circuit just converts 8 signals from 0V/5V signals to open-collector outputs. The clock circuit, however, is a bit more interesting. At its core it consists of two components: power detection and a clock generator. The clock generator is essentially an astable multivibrator buffered through some signal-shaping inverting transistors, then finally lead through a 2-bit selection switch and an output amplifier. This lets me choose either the automatic clock or manual clock pulses that are input by a switch that's debounced using a capacitor. The power detection circuit uses a zener with a reverse breakdown voltage of 4.7V, hooked up in reverse. This drives a transistor that switches on to indicate that power is good enough to use which drives an RC circuit to generate a reset pulse. The output of that is buffered, and also goes to the clock's amplifier circuit. This allows the reset logic to disable the clock while the reset line is held high or when the voltage is too low. This lets the CPU auto-reset its registers on power-up, ensuring stable boot every time power is turned on. Finally, a manual reset button is wired in as a logical OR to the reset pulse circuit. That way, if I decide to reset the CPU I can press the button and reset will be asserted while clock is disabled.

Oscilloscope showing power (purple), reset pulse (blue) and system clock (yellow).

I still have a ton of stuff to lay out and get to fabrication. I have the parts on hand to build the flags circuitry and one of the 8-bit registers (either the A register or the D register). I'm waiting on additional parts to come in to build the microcode counter circuitry. I've standardized on a 1x1 foot ABS plastic base for various logical components of the CPU but haven't permanently attached any components yet. I am also waiting on some simple bus/power/control line breakout boards that will let me run various connections to the edge of the panels for easier and more modular assembly. I need to design some jumpered 8-bit ROM boards so that I can program the microcode instructions in, and I need to start laying out the actual instructions one at a time. I also need to assemble 18 more 4-bit register boards to have enough registers for the whole CPU. Then, once all of that is brought up and verified, it will be time to start work designing, laying out and fabricating the ALU itself!

Transistor CPU Project

January 4th 2020, 4:20:15 pm

For about a decade and a half, I've wanted to design and build my own CPU from some sort of discrete components. This has become fairly standard in the hobby world and is completely obsolete with the existence of FPGAs, tons of cheap and available processors and even some microcontrollers costing as little as three cents USD. Nonetheless, I wanted to design a CPU myself mostly as an opportunity to learn and give myself a large project as a challenge.

A few weeks ago I was feeling super under the weather so I came home from work to rest up and started binge watching Ben Eater's Channel on YouTube. Side note, I love his channel. He does such an amazing job breaking things down to easy, well paced chunks that so many people can understand. The channel is like junk food to me and I love picking random things to watch. Anyway, six or seven videos into his 8-bit CPU build I started asking myself why I hadn't ever gotten around to designing and building my own CPU. So, I grabbed a set of resistors and some 2N2222 transistors I had laying around and just started playing with BJT logic gate circuits I could find on Google.

Simple circuits that I threw on paper after testing.

I didn't want to just take somebody's word for it online, so when I built the circuits I took a lot of measurements using my oscilloscope to verify the design. For each simple circuit I build I measured propagation time when the input went from low to high and from high to low as well as the amperage pulled by the circuit when running at 5V in various scenarios. Getting the worst-case propagation delay for each circuit allows me to figure out what the maximum clock speed of any CPU I build will be. I worked my way up from a simple not gate with a single transistor as well as a buffer, to nand, nor, and and or gates, and finally an SR latch. Once I had those parts built and verified, I would sketch up schematics for them with various notes on their propagation delay and current requirements. Ignore the obvious schematic errors below, I haven't done pen and paper logic design in years and completely forgot that I was drawing xor gates instead of nor gates.

Additional circuits that I tested and measured.

With an SR latch you can build all other types of latches and flip-flops. A CPU needs registers, and I want to build the core of the CPU entirely from discrete transistors and resistors, so I needed to build and test a D flip-flop. This meant adding an enable line and tying that enable to an edge detection circuit and verifying that I could "clock in" a 1 or a 0. This worked as expected, except for playing around with the resistor and capacitor values for the edge detection circuit. It still doesn't work quite right depending on the speed of the clock, and its affected by the circuit that drives it so I think I'll have to buffer it in a future redesign. Later, I added a second un-clocked enable and an asynchronous reset input, both of which will be necessary to use this as a single bit in an upcoming register. The enable will act as a chip select, allowing CPU control logic to dictate whether a particular register should store a value present on its input at the next clock pulse or retain the existing value. The asynchronous reset will allow a power on reset circuit to reset all registers to zero when the CPU is powered on for the first time.

D flip-flop with a clock and data input, a buffered output with a 10K load and an indicator LED.

If you have a D flip-flop and you have access to the inverted output, you can feed that back into the data input in order to make a T flip-flop. This type of circuit is great for chaining together to make counter circuits or clock dividers. I verified that the theory also worked on my D flip-flop circuit. I have several more circuits that I have to build and verify before I could theoretically put together a CPU of any sort. I need xor gates. I also need some way of selecting one of multiple inputs to drive a bus. Both of these could be handled by the circuits I've already built at the cost of additional propagation delay as well as higher part count. However, I want to keep the part count low so I need to build simpler circuits. Currently I have plans to lay out several busses for the CPU core and I've decided to go with an open collector design instead of tri-state output. This is because of the increased complexity involved in producing a tri-state output (multiple transistors, diodes and an inversion required) versus an open-collector (a single pull-down transistor on an active-high bus).

In order to make the CPU core more modular and thus easier to build, I've decided to go with a microcoded architecture. This will let me prototype the CPU using an EEPROM to hold the microcodes and very quickly swap things out if I don't like how it works. The final CPU will use combinatorial logic to decode instructions and a diode matrix board per opcode to store the control signals at each step in the CPU's execution. I'll use a series of D flip-flops as a counter to control which microcode to select given a decoded instruction. This design also allows me to reduce parts in several critical areas of the CPU since I can reuse expensive parts such as an adder circuit to drive both the ALU and the program counter. This comes at the cost of slower instruction throughput as only part of each instruction will be executed every clock cycle. I could have made the trade-off to have more complicated logic circuitry, but when I'm looking at hand-soldering each transistor I would prefer to keep things simple and slow.

With most of the basic theory out of the way and verified in-circuit, I got to work thinking about an instruction set. I took a lot of inspiration from the PDP-8, another transistor computer, as well as Ben Eater's simple 8-bit computer. Ben Eater's computer is more of a learning CPU since it only has 16 bytes of memory available. While it is turing complete, it is extremely limited. I want to keep my CPU simple so that its humanly possible to design, wire up, debug and code for. However, I do want to be able to write "useful" software for it. I'd like it to be capable of interfacing with external devices, possibly through serial or keyboard and VGA. I'd like to be able to code simple games or productivity software for it. And finally, I'd like it to be self hosting which means making it powerful enough to code an assembler that runs in a boot ROM. This necessitates a Von Neumann architecture. It also necessitates having access to a decent amount of memory and external hardware registers.

I settled on a hybrid 8-bit CPU design which allows for software access to 16 bits of RAM/ROM/external hardware registers. Staying true to its inspiration, I have a simple 8-bit, accumulator-based CPU and software can only interact with memory or this single register. However, several more support registers that aren't directly software-accessible will be 16-bit to enable full access to program and data memory and external hardware. I wanted to keep instruction decoding simple, so all instructions are 8-bit as well with no variable instruction width support. Most instructions deal with loading/storing or manipulating the accumulator in some manner, with a few instructions able to interact with special registers. Instead of conditional jumps, I'm going with a skip next instruction opcode which will allow any supported instruction to be made conditional. I don't currently have absolute jumps, call or return support or a stack right now but I have plenty of space reserved in the opcode space to add these in a future revision. Several of the registers are write-only or cannot be directly read or written from software which means this CPU cannot be multi-threaded. I think that's okay though, given that the CPU is probably going to run on a clock in the KHz range and would struggle with even the simplest of multi-threaded code.

Snapshot of a Google Sheets document outlining my current instruction support.

The full list of busses and their design is as follows:

The full list of registers and their capabilities are as follows:

Aside from registers and busses, a few more pieces of hardware will exist to make the CPU core:

Given that its going to be rather expensive to prototype in terms of space, time and actual components, I went ahead and wrote a microcode simulator for the CPU design. This was super useful when I was laying out the supported instructions because I was able to test out the actual capabilities of such a CPU by writing miniature programs. Using this simulator I realized that I could do away with several opcodes such as shift right, and could cleverly manipulate the IP register using the ALU to implement standard instruction advancing, relative jumps and conditional execution. During the development of the simulator I ended up also writing a simple assembler and disassembler in Python which will be super useful for writing code that runs on the real hardware before I get the on-target assembler off the ground. If you're interested in playing with it, I threw it up on my website. It also serves as the master documentation for microcodes since it fully simulates the various busses and registers.

I still have a lot of work to do on virtually all of the CPU pieces before I have anything resembling a real CPU. However, given the layout and simplicity of the busses and control signals, I should be able to piece-wise assemble and test the CPU part by part. The next big thing I need to do is test circuitry that will allow me to assert on a bus so that I can start building the bus itself and then send out some boards to be fabricated. I think I'll start with register read/write and a bus and build out the various pieces from there. The most complicated part is going to be the ALU but even that can be built function-by-function until I have a fully functioning ALU circuit. And finally, once I get this particular version of the CPU up and running I'll jump in and see if I cant get absolute jump, call and return instructions and a real stack implemented. Stay tuned for updates to this project!

Reverse Engineering a Dot Matrix Plasma Display

May 2nd 2012, 11:26:00 pm

Awhile back, I bought a lot of arcade parts from somebody on Craigslist with the intention of getting some parts and marquees for my house. I wanted to try my hand at reselling as well to see if I liked it. Most of the garage has been sorted, sold or thrown away at this point and in the back corner I found a box labeled "Betson Replacement Screen." I pulled it open and found a brand new dot matrix display. Remembering a post by a friend on his progress reverse engineering a LED display from the 80s, I decided that I had to get a picture on it.

The first thing I did when I got it upstairs was flip it over and google the model number, "APD-128G064A-1". My initial excitement was dashed when I realized that the copious links all pointed to the same 2-page PDF document that was almost entirely devoid of information (datasheet here). It did go over the theory of use at a very high level. Also, thankfully, it discussed voltage requirements. With that bit of information I decided that my best course of action would be to get power to it and see if it did anything, followed by attempting to trace the circuit and figure out what pins did what. Since the datasheet called out the method by which the screen could be updated, I just needed to get a good idea of which pin was for each of the six signals listed. Then I could experiment with a microcontroller and confirm my guesses.

There was a nice test fixture (possibly for probing converted voltages?) that mentioned Vcc, so I stupidly hooked 12V to that and ground to the gnd pin. Nothing happened, and I shut off the power supply and re-read the data sheet. I realized that it called out two different voltages, one for DC-DC conversion to run the plasma display, and one for the logic. With that bit, I re-examined the ignored 4-lead cable attachment and realized that it was probably the power connector. Vcc as labeled was traced to a pin, ground to two more, and I guessed that the last would be the 12-36V DC-DC input. I re-soldered to these instead of the test points and turned the power on. I was immediately greeted with a zapping noise and several of the dots lit up temporarily. Before I could congratulate myself, the power supply tripped. No matter, I knew I had the power lines connected right.

With a renewed excitement, I soldered wires to the used pins of what appeared to be the logic connector and began tracing the circuit out. Every chip on the circuit was a 7400 series chip with the exception of the shift registers. All of them had data sheets online. I managed to probe out several of the connections, concentrating on the circuits that fed the clock and data in pins on the shift registers. After a good hour or so of probing, I had the following crudely sketched schematic and was 99% sure as to the use of four of the six inputs. The other two were either row clock or row data, but I could figure that out by trying both combinations.

Backside of the display.

Schematic bits.

I hurried to Fry's to pick up an Arduino board and they had what they called "Arduino Compatible" OSEPP Uno boards. I got it home and after a bit of googling learned that you had to manually select a different board type. I burned the blinking light test binary on and it worked, so I was off throwing together a quick test application. Armed with a new, beefier power supply, I tried my code. The first thing I attempted was to display a test pattern to the screen. It failed outright. I figured that since the display claimed that the row needed manual resetting that I wasn't clocking the row line in properly. After a bit of time experimenting, I had a program that took the random garbage that showed up on the screen when it booted and stepped it down one line per second. I now knew which line was row clock and which was row data. After a few ore hours of throwing code together, I came up with this program. I powered on the display and below is what I was greeted with:

I had officially achieved liftoff! There was a pesky problem with wobbly pixels in some areas, and the screen refreshed so slowly that it flickered like hell. Also, there was garbage at the bottom of the screen that I couldn't account for. Now that I'd prototyped it, it was time to get rid of the Arduino libraries (they are very slow) and go to raw register accesses. Also, I wanted to create some sort of protocol by which I could update the display using the USB to serial connection provided on the Arduino. I briefly tried creating 3 color and 4 color grayscale images by displaying images 1/2 of the time, and then 2/3 and 1/3 of the time. The screen stopped lighting all the pixels when refreshed too quickly and when I slowed it down well enough to get a clean picture, it flickered, so that was out. Also, since there was only 2 KB of SRAM, I had to place half the image in EEPROM which meant that access times for the two frames were not in sync. I finally settled on a simple serial protocol by which the EEPROM could be rewritten, a 1KB buffer in SRAM could be rewritten, or text could be rendered onto the screen using the EEPROM image as a 128 character 8x8 font.

The program took me a few nights to complete, thanks to some setbacks with the Arduino programming environment. However, I got the column data clocking out via SPI instead of bit banging which drastically improved the refresh speed. I also converted to raw port accesses which helped. The images now displayed crisply and I could dump data to the screen using a test program in Visual Studio. I put my friends to work helping me format an 8x8 font bitmap and drawing black and white images to display, and the results are below:

Text rendering using font burned to EEPROM

A cat!

Milhouse is not a picture.

The current source code to the Arduino application is available here. The visual Studio application that I developed into a console application is available here. They're probably not much use to anyone who doesn't happen to have one of these screens available but I figured they would be educational to the curious. The serial protocol can currently accept a 128x64 image for display or burning into the EEPROM. It can accept text to be rendered. It can clear or invert the screen. It can force text to be drawn normal or inverted. It can also move the cursor. I plan to add several more functions to the serial API such as scrolling and scaling, blitting and other high level graphics operations one might expect from a nice display driver. I would take the easy route and just upload full processed images but unfortunately I can't push the serial past 57600 baud or the interrupt can't keep up with the image refresh.

That isn't all, however. I plan to pick up an old laptop from a friend and put Linux on it. From there, I'll need to port the console application and add a web server. I want to put up a simple PHP script that allows poeple to upload images or text to the screen from the internet. Possibly, I also want it to take twitter updates or texts on a google voice number. Basically, I want this to be an interactive toy that guests who come to my parties can interact with using their phones. Stay tuned for more development!

Wanted: Competent Video Game Sellers

November 12th 2011, 10:37:00 am

So you want to sell some video games on craigslist? Maybe you have a few games you don't play anymore. Maybe you are a reseller. Maybe you are cleaning out your parents garage and find something you think is rare. Do all of us a favor when posting and follow these simple instructions so that you don't waste everyone's fucking time with the written equivalent of a crayon drawing of your dick.

First things first. Tell us what you are actually fucking selling! You'd think this is business 101 but there's probably a reason you are selling this on craigslist instead of opening your own game store. If you want to attract anybody at all except for the lowest of low-ballers you will need to specify exactly what you have and what condition it is in! I am not even going to bother replying to you when you leave a vague, poorly worded one sentence post about your Atari and a few games. "Sweetening" the deal by mentioning that you have rarities and not mentioning what they are only makes us suspect that you have no fucking clue what you are doing. It helps to list what accessories come with a system as well as what condition it and the games are in. Also nice to know is whether manuals, cases, boxes or anything else interesting comes with your sale. By the way, brand new means just that: BRAND NEW. If something is opened but not played, it is LIKE NEW. If something is played, it is USED. Don't bullshit me with brand new when it is not factory sealed.

Please actually do some fucking research before claiming rarity on games or systems! I understand that not everyone is a collector but do realize that when you scream on about your super rare Atari 2600 with 40 games, what you probably have is nothing more than $10-$20 worth of garbage that nobody will want to take off your hands. I've noticed a direct correlation between people who think they have amazing sales and notices in the sale about ignoring low-ballers. There's a fucking reason people are low-balling the price you set, buddy! It's because its TOO FUCKING HIGH. Nobody is going to spend $20 to buy your worn copy of Tetris for game boy. It doesn't matter if the system is 20 years old; it isn't fucking rare unless people are looking for it and can't find it!

Also, pictures! Craigslist lets you post pictures for a goddamned reason. Its hard enough to trust a random anonymous stranger on the internet as it is. Provide photographic backup to your description! Don't want to post a picture? You probably have no fucking idea what you are selling anyway. Don't tell me to email you for pictures. If you were too fucking lazy to snap one goddamn grainy cellphone picture, that doesn't lend much to the belief that you will respond at all let alone with pictures that will help me make a decision on your sale! By the way, STOCK PICTURES DO NOT FUCKING COUNT. I know what an Atari Jaguar is supposed to look like. I want to know what YOUR Atari Jaguar looks like.

The condition of your games and systems ACTUALLY DOES MATTER! Believe it or not, there are some people that buy games who want their games to look good. I know for a fact that your copy of Chrono Trigger plays like new. Cartridges don't go bad! But if its covered in permanent marker and barbecue stains complete with a torn label I am not going to pay full price for it, no matter how rare you read that it is. Look at it this way: any of these old games that you are selling can be emulated near perfectly on a computer FOR FREE, so what do your games have that makes them better? I am buying something to own, to show off and to cherish. You wouldn't expect me to pay Kelley Blue Book on a car that has dents and peeling paint, even if it runs just fine! So don't fucking pull that horse shit with video games. This also goes for manuals, cases, boxes and the like. If you expect to fetch a decent price on a video game that isn't rare, have all the pieces that it comes with! If you don't, realize that it is WORTH LESS.

Also, you'd think this would be a no-brainer with something that needs to function, but test your fucking games! If you can't test them for some reason, tell us that you couldn't test them! Expect to get a lower offer unless you are willing to help us test them on the spot during the sale! Do understand that if you do not mention testing the games, it is assumed that THEY WORK. Take the car analogy again: if a car is listed and the seller makes no mention of problems it is a valid assumption to believe that everything works fine!

Now, lets touch on pricing. As with ANYTHING on the market, video games are only worth what somebody is willing to pay for them! This is another business 101 concept that I wish more people would figure out. Just because you saw it go for $300 once on eBay does NOT mean that your used copy of Final Fantasy VII is worth that much. You probably made a mistake in reading the condition of the sale! Was it a sealed copy? Was it a rare misprint? Was it signed by the developer? Chances are your copy is not worth what the most expensive games go for on eBay. Also, nothing infuriates me more than seeing somebody justify ridiculous prices by pointing out that eBay sells it for that much. If you want to sell it for eBay prices, then go sell it on eBay. I know you are a cheap-ass who doesn't want to pay fees, but I am also a cheap-ass who doesn't want to pay eBay prices! The point of exploiting a local market is that things tend to be cheaper! I am not going to go out of my way to drive to your house all the way across town to pick up something that I could have shipped to me for the same price!

With all that in mind, I look forward to purchasing from you! After all, I love video games and I love getting excited about the games you are selling if only you'd allow me to. A well written advertisement for stuff that I want will get me to jump on the sale immediately. That way you can take my money and I can take your games and we can both go home happy. After all, the whole point of doing business is so that both parties walk away happy. Otherwise, what's the fucking point?

Beta Site Raffle!

March 9th 2011, 10:52:00 pm

I'm holding a raffle to help kick-start interest in the arcade and game store search features on my beta site. Any time a site member adds a new game store or arcade to the database, they will be entered once into a drawing currently slated for the end of the month. If not enough people have entered the raffle to perform a drawing at the end of the month, the drawing will be delayed until the end of the next month. To keep this from happening, tell people you know to add stores or arcades they know about as well. After a drawing, the raffle will reset and another drawing will happen at the end of the next month. You can enter as many times as you would like by adding as many arcades and game stores you know about. The winner of the drawing at the end of each month will receive their choice in up to $50 worth of Steam gifts. Make sure you have a valid email set in your profile so I can contact you if you win!

DragonMedia Player 0.25

February 20th 2011, 12:44:00 pm

I have released another minor update to DragonMedia Player, this time with AAC/MP4/M4A support! Also included is the separation of your playlist and your file list. The interface remains the same, but files will continue to play while you browse other directories, and the next and previous track buttons will continue to work. Other minor changes included for stability and polish.

View the Wiki for More Information and a full changelist.

DragonMedia Player 0.21 Alpha

January 6th 2011, 9:20:00 pm

I have released a minor update to DragonMedia Player that addresses a few of the stability issues present in 0.20. I don't think I got everything, but it seems to be a heck of a lot more stable now. There have been more changes under the hood than are visible to somebody upgrading from 0.20 to 0.21 but these will hopefully enable me to quickly integrate streaming mp3/ogg soon! When I get that finished, I'm going to look into getting aac/m4a integrated and working and then allow aac streaming as well.

View the Wiki for More Information and a full changelist.


December 29th 2010, 10:32:00 pm

I have updated my beta site again to allow for a user-driven marketplace. I am going to get the ball rolling in the next few days with some semi-decent sales. If you have something that you want to sell and are willing to try out the new feature, have at it! For those of you who signed up or are on the fence, we need you to list your local game stores in the game store list as well! The more people that contribute, the better chance you have of finding a neat hole-in-the-wall video game store in your area.

Game Store Feature!

October 30th 2010, 2:07:00 pm

I have updated my beta site to allow members to add and rate local game stores. My hope with this feature is to amass a decent list of local game stores around the country for those of us who want to find good games at decent prices. Give it a spin as it already has a few game stores that I have added from my travels. Game Stores.

Beta Site!

October 12th 2010, 7:26:00 pm

Hey all both of you that still read this! Been working on a social site for gamers, collectors, homebrewers and anybody else interested in video games. I'm scarce on detail as the site is scarce on content, but as I get momentum I'll be updating it more frequently. Check it out at

DragonMedia Player 0.2 Alpha

August 22nd 2010, 8:34:00 pm

With time comes the resurrection of an old project of mine. I realized when I moved to my new place that I needed a decent player in my living room. So, instead of purchasing a computer or starting afresh, I grabbed my old DMP and started making fixes and modifications. What we have here is a new version that can play files off of up to 10 Samba shares, has no stuttering issues while browsing or playing off the internet, and allows for hot swappable USB and SD cards. Leave a (non-stupid) comment here or at WiiBrew to let me know how things work out.

View the Wiki for More Information and a full changelist.

Happy listening~

Repairing a Millipede PCB

July 15th 2010, 10:12:00 pm

Recently, I've been getting into arcade cabinets. I have two of my own in my living room (a Neo Geo four slot and an original Centipede upright) and am in the market for more as space and money permits. I was talking about my recently acquired Centipede cabinet at work and my coworker mentioned that his fiancée had a Millipede PCB in her living room. I got in contact with her and she said that it was broken and was willing to sell it to me for $10. Considering the simplicity of early arcade boards I jumped on the offer, sure that I could repair the board myself.

The first thing to do when I got a hold of it was to plug it into the Centipede cabinet. The PCB had come with a wiring harness that allowed it to plug directly into my Centipede cabinet which saved me the hassle of ordering one online at around $40. I gave the board a once-over to ensure that there were no burned chips or leads and sprayed it with some compressed air to ensure no dust or debris and plugged it in. The following video shows what I got on screen.

YouTube Video

The important part of the video is the beeps. The screen is just displaying random symbols as it tries to power up and test all of the components. A bit of Google searching revealed that the bad chip was located at 2M (each chip is labeled on the board). A bit more Googling provided the schematic that Atari provided with new PCBs when they were originally sold. The chip corresponded to the play field RAM and was easily located on the board. Curiously, rework had already been done on the board and several broken traces could be seen. So my first task was to verify that all traces were reworked correctly. I spent about two hours with the schematic in hand tracing every pin out from the RAM chip to every other location on the PCB and verified that all of them were good.

This left two problems: either the RAM chip itself was bad, or one of the chips it connected to was bad. Since the previous repairman had socketed the chip when he had worked on the board I decided to try replacing the RAM chip first. I ordered a few of the same chip (both Centipede and Millipede use the same chip in multiple places so I figured having some spares around would do no harm) and replaced the suspected faulty chip at 2M. After plugging the board back in, I got partial success!

However, the controls would not work. The PCB was probably not set to free play mode, so it was back to Google to retrieve the DIP settings to set the PCB up to the correct mode of operation. After twiddling with those for a good half hour, the cabinet was then on free play and the buttons started working. However as soon as the game started it was evident that the trackball was not working correctly. Moving the trackball steadily in one direction produced wild motions back and forth, and the player tended towards the upper left of the screen. I moved the wiring back to the Centipede PCB and fired it up to see if I hadn't wrecked the trackball circuit in the process but it worked just fine.

I pulled up the schematic again and looked at the trackball input and it was far more complex than simply tracing the RAM, so I fell back to assuming something was wrong with the conversion connectors. They were handmade so it was possible something got switched. After testing every single lead from the Millipede to the Centipede side, I identified two sets of crossed wires: the wires going to the sound board (these made no difference) and the horizontal and vertical position wires from trackball one (for non-cocktail cabinets). I snipped the wires on both pairs and uncrossed them before electrical taping the exposed wires away again and plugged the board back in. Success!

YouTube Video

I now have a working Millipede PCB for around $50 (original purchase, a cheap multimeter since my other one broke and the RAM chip order). After verifying the functionality by way of a few games, I mounted the PCB above the Centipede PCB and put the cabinet back together again.

The Centipede board is left in because I like the idea of having an all-original Centipede cabinet, but I don't know when I'll get bored of millipede. For now, I'm out.


February 14th 2010, 11:50:00 am

Hey!  I put out a small personal project that displays SQL dumps in a (hopefully) intuitive manner on the DS.  See this thread for details.

The program is available here.

Sample text files available here (place under /database/ on the root of your card and load the program).

EZ Flash

February 26th 2008, 8:05:00 pm

Could anyone explain why people keep messaging me on MSN thinking I am the coder for the EZ-Team? I keep getting messages with people asking me to help them with roms on their EZ-Flash. It makes no sense...


Alex says:
DragonMinded says:
Alex says:
ur the dude with ezflahs yeah?
Alex says:
DragonMinded says:
dsorganize isn't ezflash
Alex says:
oh well
Alex says:
i saw ur msn at the bottom of the readme
Alex says:
well, can tell me what dsorganise is plz?
DragonMinded says:
no you can read about it yourself
Alex says:
i wanna get pokeon pearl on ymm ezflash, but it doesnt work....
DragonMinded says:
im not here to help you pirate shit
DragonMinded says:
i have nothing to do with ezflash
DragonMinded says:
go buy the game
Alex says:
well, dnt put ur name on dsorganise then
DragonMinded says:
dsorganize is a HOMEBREW PROGRAM
DragonMinded says:
it has NOTHING to do with ezflash
Alex says:
if u dnt wanna help, dnt put it on\
Alex says:
whats a homebrew1

DSOrganize 3.2

January 27th 2008, 5:53:00 pm

I decided against my better judgement to put out 3.2 "final," seeing as all the work I put into it would go to waste if I just left it alone. I've put final in quotes as this isn't where I wanted 3.2 to be, but it's where it's going to stay. You will notice that I removed basically all references to contact me. This is not because I encourage going on scavenger hunts to pester me with shit that you can find on the wiki. This is because I don't want to fucking hear from you. So don't email me, don't pester me on any irc channels I happen to be in, don't pm me.

Direct Download
Support Site

Birthday Release!

November 29th 2007, 12:13:00 am

Anyone who knows me knows that today is my birthday, so, I decided to put out a birthday release as a gift to everyone! This version fixes a few crashes, several bugs, and adds SSL support to the browser! Also in this version is correct handling of all PNG types, including those with alpha transparency. Also, I should have a library up on my page that allows you to very quickly integrate SSL into your projects soon. Enjoy~!

Direct Download
Support Site

3.1 is Out!

November 10th 2007, 5:21:00 pm

Just letting everyone know that 3.1 is out. This, like 3.05, is mostly a maintenence release. In this version, I concentrated on fixing as many FAT related bugs as I possibly could find, and it should be much more stable for all cards concerned. I have also added support for deflate and gzip encoded web pages for the browser, resulting in pages that support these encodings loading much much faster. The plugin/executable architecture has been removed permanently as of this version, as it was extremely underused and took up space. Also gone is the resources file, and DSOrganize should boot faster now.

I am experimenting with screen orientations, and have added an option to rotate the orientation of the image viewer so that you can hold the DS sideways. If this is well recieved, I'll probably add a mode like this to to text viewer and web browser.

Direct Download
Support Site

This release has been tested working on GBAMP, MK2, MK3, GnM, and CycloDS Evo.

3.05 is Out!

October 31st 2007, 7:55:00 pm

Just bloggin' up to let everyone know that 3.05 is out! This version focuses mostly on removing defects from the web browser, but includes a few new things. Most notably in this release is support for downloading files in the browser, and a confirmed fix for the random audio playback bug. As of now, I haven't had a single freeze in the audio engine since applying the fix in late September. Also, m4a files should play back at full speed, even the higher bitrates! I hope you all enjoy this release!

Direct Download
Support Site

This release has been tested working on GBAMP, MK2, MK3, GnM, and CycloDS Evo.

Minor Bugfix Out

September 26th 2007, 11:17:00 pm

I've just posted 3.01 which is a very minor bugfix to make sure there is a stable release out there while I work on the next version. See the previous post for all links.

DSOrganize 3.0 Released!

September 25th 2007, 3:53:00 pm

I've finally gotten the time to polish up the next release for you guys! DSOrganize 3.0 is out with source! The big feature for this release is wifi configuration, complete with saving back to firmware! Other smaller features include a systemwide clipboard and some bug fixes to many screens. Head to my page for more information!

Month(?) of Bugs!

September 8th 2007, 4:44:00 pm

Well, seems like the feedback page doesn't work as well as I'd hoped. A lot of people report bugs with certain features or web sites, but they virtually ALWAYS leave out the way to reproduce the bug or which site they actually have trouble with. So, if you know a reliable and predictable way to crash DSOrganize, please let me know the steps so I can fix it.

Out of my Hands

August 21st 2007, 8:04:00 pm

So the MediaCard people are stating that they will relesae source under GPL, which is all they are legally required to do. Since I don't know of their integrity, I can only believe them at this point as I have no evidence to tell me not to. It's safe to say (at this point at least) that they are doing things legitimately and shouldn't be harassed. If you are using a banner that says not to buy the mediacart, please take it down, and don't harass them anymore. Hopefully this doesn't ruin their business in the future.

New Updates On Situation

August 21st 2007, 7:54:00 am

So I am mistaken. Apparently the GPL does not allow me to do what I am doing. As long as the MediaCart releases their source code in it's entirity, it is legal for them to use all my code and sell it. Please don't harass them until it is found out whether or not they do this.

My Work Stolen

August 19th 2007, 12:42:00 am

So a new flash cart called the media cart is coming out soon, and it appears they have ripped my work from DSOrganize and are now selling it in a commercial package. Not only was I not notified of this, but they are making money off of my hard work. Please pass it on not to buy this device. Video proof here. I have tried emailing them about it, but they don't even have a working email. If you look here, they were even lazy enough to include a screenshot of my original configuration.

DSOrganize 2.9 NeoFlash Released!

August 15th 2007, 7:54:00 pm

I've entered DSOrganize into the NeoFlash competition. Hopefully this competition will be a little better run than GBAX. Head on over to the NeoFlash Forums to grab the latest source. To have a look-see at what was added, read up on the wiki. Highlights of this revision include simple image and css support on the browser, sndh playback, wav and sid file enhancements, and a ton of bugfixes and interface tweaks! I hope you guys enjoy this release.

Also, thanks to everyone who helped me to afford my new computer. It's been so nice developing on a machine that can compile quickly!

Games & Music Compatibility

July 22nd 2007, 12:54:00 am

I have recently come into posession of a GnM to test on thanks to TheMikaus on the gbadev forums. As a result, I've figured out why it needs to be renamed to bootme.nds in order to function. Also, after fiddling and talking to chishm, I realized that booting with the Chishm loader works IF you are using version 1 of the dldi. For all of you out there where booting doesn't work or works partially, grab the new load.bin from the post below this, and patch with version 1 of the dldi (available off of my wiki or on the dldi wiki) and you should be set with booting.

Updated Loading Stub

July 19th 2007, 9:27:00 pm

Anyone who has any card by Datel, as well as Supercard One users (and anyone else who has trouble booting in DSOrganize for that matter) should try this new load.bin from chishm. Please place it in the /DSOrganize/resources/ directory on top of the old one, and make sure your default bootloader is the Chishm loader (in configuration). This should fix the issue with hanging touchscreens and such, but I'm not 100% positive. Please leave feedback.

New Update, Computer Issues, etc...

July 9th 2007, 5:00:00 pm

First order of business: There is a new update to DSOrganize. I have entered the GBAX 2007 competition with an update to DSOrganize (2.8 GBAX). If you want to grab the entry, head to the GBAX site and scroll to my entry. If you want the source or to see what's changed, head to my site. Major features include overall better support for websites as well as bookmarks on the browser, and url capturing and colors support on IRC. Several other minor fixes have been applied.

Second order of business: My pc fried a week ago. I ordered a new PC dispite not being able to afford one, and have dipped into college savings. I feel sleezy for begging for donations, but I have never asked before and really can't afford this PC. So, I'm asking anyone who enjoyed the software to donate to me at this time. The cost was $800 for the PC, the external cases to make my current drives work with it, and the additional ram to bring it up to the memory capacity my current one had. However, a week after ordering, I have been emailed to tell that my PC is on backorder (why they couldn't tell me this a week ago, I don't know). I am going to pick out a different one today and hope to have it at the same price, but it might be more expensive. Here's to hoping I can work something out, because DSDev on a 1.3GHz celeron laptop with 256MB of ram is extremely painful.

link removed

UPDATE: I have recieved $150 in donations from several kind people, but I still have a long way to go before I can afford this computer. If you have spare change, send it my way!

DS Lite Reported Wireless Fix

June 3rd 2007, 10:38:00 am

A user by the name of Daltonlaffs is reporting that he found a problem and fix with certain versions of the DS Lite firmware. Apparently, theres two versions, both which show magenta in the PictoChat trick, and one of them blocks homebrew access to wifi somehow. In order to get online, set your router to channel 10 and then reconfigure with an official game.

DSOrganize 2.7 Final Out!

May 7th 2007, 4:32:00 pm

This is a minor maintenence release. The two big things on this release are dldi auto-patching, and the fix for some mp3s and most mp3 streams skipping. Head to to grab the latest package.

2.7 and Source Released!

April 27th 2007, 1:51:00 am

Hey folks. Just popping in to let you know that DSOrganize 2.7 and the source for 2.7 have been released. I gave up waiting for you guys to find the easter egg because noone bothered to try hard enough. Version 2.7 includes a web browser with forms support. As always, get it on

To access the easter egg: Make sure you have a proper install, because resource0.bin is required. Edit your sound.dat file so that the only character is a questionmark (?), and then save it. Start DSOrganize up, go to the main screen, and press start (normally pulls up the about screen). I decided to give up waiting for you guys to find it because you were taking so long that its becoming irrelevant.

To compile the source: I don't know why the hell you would need to do this. DSOrganize already includes DLDI support and you know my stance on modifications. If you absolutely must compile it, you need all four libraries off of my site, as well as DKA r17. DO NOT INCLUDE DSORGANIZE IN YOUR FLASHCARD COMMERCIALLY WITHOUT PERMISSION. Basically, do not make me regret putting this out.

For those who had alpha 3, this is what changed on the browser:

Just a reminder...What works:

What doesn't:

IRC Channel Moving

April 20th 2007, 3:49:00 pm

If you are a regular in DSOrganize IRC, please configure your client to connect to #dsorganize now. We have moved from freenode due to its lack of features.

On Images

April 16th 2007, 10:31:00 pm

I'm making it official that for now, DSO Web Browser will stay text only. This means image support is on PERMANENT HIATUS. Please DO NOT ask me about images in the browser, if I ever consider adding this feature, I will do so when I have time.

Happy Easter!

April 8th 2007, 12:59:00 am

To celebrate Easter, I will give you guys a big hint on the easter egg:

On Gnirfleo

April 3rd 2007, 11:26:00 pm

(Crossposted to gbadev)

All this crap about gnirfleo has more than pissed me off. Not only has it stolen legitimate attention from real browsers that actually work on the DS, such as links, retawq, and my own browser (hopefully soon Okiwi too), but it is damaging the community. Flat out lying and linking to other files is the sleaziest way possible to gain attention for your own games. I am looking forward to the day where another new gnirfleo rumor post doesn't pop up on three separate forums.

Do you know how annoying it is to get users telling me to stop working on my browser because gnirfleo is better? Not only is it not out, but you don't even know if it's real or if the promises made will be realized, yet I still get people telling me I should stop wasting my time and just use gnirfleo as the browser.

You guys need to stop acting like sheep. Stop reposting the same crap about gnirfleo and stop giving that fake of a homebrewer attention. As far as I'm concerned, it shouldn't even get mentioned until an actual NDS file is released that does what's promised. I cannot believe the amount of real homebrew that is being pushed aside and ignored for another delay update that's posted on the gnirfleo blog. For crying out loud, many people still don't know that DSOrganize Alpha has been able to browse the web for two weeks, let alone about dslinux, yet we get 1000's of posts on the gnirfleo comments stating that they love him and his work.

tl;dr - STFU about gnirfleo.

Feedback Page Now Open!

March 29th 2007, 11:03:00 pm

It's been getting progressively harder to track what works and doesn't with particular releases as of late, what with people not specifying what release they are talking about when discussing flaws on random forums and such. I decided to open up a link removed on my site. It's designed to let you answer a few quick questions as well as leave comments. Some questions will depend on your version, so I can get feedback on a particular new feature or bug fix that needs testing.

Also, a shoutout to everyone leaving me positive emails or comments. Always appreciated!

Alpha 3 Out

March 27th 2007, 6:03:00 pm

I wasn't going to put another alpha out at least until I had forms done, but today I think I solved a major corruption bug with the fat library I'm using. Go ahead and try Alpha 3 and see if your card writes are more safe.


Second Alpha Out!

March 24th 2007, 12:25:00 pm

Well... Spring break is over and I don't know when I'll get another large bit of time to work on DSO for quite some time, so I'm putting out another alpha to hold you guys over. Grab it from my site and enjoy.


DSOrganize 2.7 Alpha

March 22nd 2007, 6:04:00 pm

Well, most of you have seen the video. You know what's in this release. This is a very dirty release, so use it at your own risk. The only files provided are the updated executable and a fixed resource0.bin. You must have the install files from 2.6 or 2.61 to use this, or unexpected things may happen. Grab the alpha from my site here. Enjoy the first working homebrew browser for the Nintendo DS!

What works:

What doesn't:

On another note, I need some help with maintaining gba_nds_fat. I know it's discontinued but hear me out. Upgrading to r20 breaks virtually every feature in DSOrganize. For a short list: plugins stop working, sound doesn't stream, or even respond, booting files fails on cards it used to work on. The list goes on. Also, backporting libfat has turned into too daunting a task for me to take on. I'm asking that someone who knows their way around the FAT16/32 system (perhaps the guy working on MCTool?) look at the code for fat entry creation, as well as the rename code. Files tend to disappear, and if you create too many files in a directory, the fat table tends to get corrupted with what looks like text from actual files. The library that I compile from is available here. Please don't touch disc_io.c because the drivers need to be in a certain order. If anyone takes this up then I and everyone else that uses DSO will be eternally grateful.

Maintenence Release Out!

March 19th 2007, 5:33:00 pm

As promised, I've got a maintenence release out for all the bugs that people have reported. Head over to to check out the new stuff. Also, R4 and M3 Simply users should be interested to know that there is a special compile of exec_stub.bin that boots homebrew for you! Read the release log for more information!

DSOrganize 2.6 Out!

March 16th 2007, 11:05:00 pm

Hello everyone! A new DSOrganize is out and is available at Important features in this release include support for flac, sid, nsf, and spc audio formats, fixes for the html renderer to render pages much larger in size, an updated wifi library for DSLite compatibility, and customizable colors throughout DSOrganize! That's right, all that clamoring for a customizable interface has been answered....sort of. Read up about details on the DSOrganize homepage listed above.

Just another reminder that noone has found the easter egg yet. The clue last release was that it had something to do with the sound.dat file. Another clue is that it has nothing to do with the Sound Screen itself, and visiting said screen will reset the easter egg for that boot session. Happy searching, and if you find it, let me know!

I'd like to take this space to call out MaxConsole, which missed the 2.5 release of DSOrganize completely, but hasn't failed to regurgitate their DS-X review on a monthly basis. Way to go, second release that you missed! How about releasing some actual news once in awhile instead of links to photoshopped pictures of spoofs. To the rest of the crowd, enjoy this release, and if you find bugs, let me know ASAP as I want to put out a maintenence release at the beginning of next week if anything comes up, before starting the next round of feature implementations.

~Toodles :3

DSOrganize 2.5 Is Out

February 22nd 2007, 8:57:00 pm

Good evening folks. Just updating to let you know that DSOrganize 2.5 is out! Included in this release is a vastly improved plugin architecture that has more exposed API and over 2MB dedicated RAM to each plugin or executable while running. Also included is shortcuts, with support for adding them to the home screen! Check out the latest version at Just to remind you, noone has found the easter egg yet! I'll give you a hint: it has something to do with the sound.dat file. As an added incentive, as soon as someone finds the easter egg, I'll put out the latest source!

A few of you might have noticed me lagging on the releases front lately. I'm EXTREMELY busy. With two physics classes at school and work all weekend every weekend, its hard to dedicate much free time to working on DSOrganize. I'm sorry about this, and hope to resume my frantic release schedule of almost once a week after I finish this semester in mid-May. An alternative would be for me to quit my job and dedicate weekends to more coding, but this would require a) me to beg for donations so I could afford gas for school, and b) donations. ;P I'd much rather leave it as I am now, asking for nothing except for an occasional thank you.

Enjoy the latest release, and as always, suggestions, icon sets, translations, and bug reports are always welcome. Just be patient as I find time to reply to everything. And of course, come hang out at #dsorganize on and idle (or chat, but that's against the rules of IRC).

DSOrganize 2.45 Out!

January 13th 2007, 1:46:00 am

Well, I've put out another maintenence release, fixing a few crash bugs and one playback bug, as well as adding a DSO executable format! It is very similar to a plugin but runs standalone instead of attached to a specific set of extensions. Check it out here and download the newest beta! Don't forget to grab the newest wonderswan plugin as the update has added new features to the plugin framework and thus will not work with older plugins!

Head to the newly opened Addons Page to grab stuff designed for DSOrganize. If you want to see your creation on this page and I haven't found it while trolling the forums yet, email me at and I'll slap it up there for you.

Also, please read my post on the GBADev forums about DSOrganize file formats.

PS. There is a new libFB out as well, with some bugfixes, optimizations to the text rendering engine, and and overall code cleanup. BONUS: Documentation!

Minor Update Out

January 9th 2007, 1:20:00 am

Roger pointed out to me in #dsorganize today that when switching to German, the browser stopped functioning correctly. Well, after 5 hours of tracking this new damn bug, I finally found it in a puny function that draws the home button. In the process, however, I discovered a major flaw in loading the IRC and config ini files. I have put this update out to correct the flaw and to add support for a few more card types. Head over to the FAQ to see how to get your particular card working.

For those of you who want DSOrganize as your shell, it IS possible to also patch the exec_stub.bin file to allow DSOrganize to properly boot your files. Head over to the FAQ (again) to check out the instructions.

DSOrganize 2.4 is Out

January 7th 2007, 8:02:00 pm

Head to my homepage at to grab the latest release. See the update list for changes. See me at #dsorganize for details.

A More Formal Response

October 2nd 2006, 2:18:00 am

As most of you have figured out by now, I am stepping back from NDS development indefinitely at this point. I will not be pursuing any new coding endeavors right now for the Nintendo DS as it would probably do me no good. What you saw in a previous post about flashcards is only the tip of the iceberg of issues that I have to deal with while releasing new versions. While I am somewhat sad to let my favorite hobby go, it was getting to the point where I just wasn't enjoying myself as I was months ago. As of now, consider me resigned from not only the scene, but from NDS programming. I may reconsider after I take a long breather, but the way things look now, I dont know.

First off, I would like to thank the fellow coders who were there to help me, the teams that did submit drivers for their cards, and the userbase I had that was eager to test and submit translations, as well as give me feedback on DSOrganize. Special thanks goes out to LiraNuna, for answering innumerable questions about random quirks on the NDS system. Thanks also goes out to Chishm, who has put out a fantastic library, and also has helped with questions on maintaining the old library. Also, thanks go to sgstair who endured my complaints about the wifi library and who was eager to fix bugs and put out an all around awesome library as well. Also, thanks goes to many other poeple I've hung out with online, who have volunteered time and services to further the DSOrganize project. If anything makes me consider eventually returning, it would be to work with people like these.

Second, I'd like to address the issues with the scene. People are asking why I even care one way or another about the scene, when most of my users aren't even in it. I have never developed for the scene, I have developed for myself and for those who submitted bug requests and followed my software. However, it's very difficult to figure out new features on a piece of freshly documented hardware. When coding on linux, mac, or windows, you have miles of code samples online, but on the Nintendo DS, you have what little is out there, and the knowledge of members on the scene. I haven't been very associated with them for the last few months, and it is a real burden. Instead of simply asking a question and having a scene meber who is an expert having an aswer, I've sometimes spent days, if not weeks, re-figuring out what someone else already knows. It's a waste of time. Also, I started developing on the NDS to have fun coding with others, as it is fun to meet people that share hobbies. When the scene is split, it's hard to do that.

Third, to the anonymous cowards who have taken the opportunity to bash me on this blog or other forums. I didn't ask you to read my personal blog, and I certainly didn't ask you to click in from whevever you came from. This is not 4chan, and you don't have to post every stupid thought that comes to your head. I don't think some of you even followed DSOrganize, you are just jumping on the bandwagon to insult someone because you can. Grow up. Find something better to do with your life. I have been very careful in the year or so of NDS development to be polite and calm in all my posts online, and all it takes is a single post to be called a drama queen? There's more to the problem than you know. This wasn't simply about poeple saying mean things over IRC.

To StoneCypher, who thinks that the scene is coming back together: the scene wasn't split when DarkFader mass invited to #mellowdsdev. People were not forced to go, and the fact that when given an opportunity, they left, shows that things were not all happy like you say they were. Also, according to you, I've already pulled this twice. Let me remind you that I've never posted or even publicly mentioned the split, and I certainly have never claimed to leave the scene. I did leave from September through December last year due to your actions against me, but I left quietly, simply quitting IRC and not posting updates to my program until late December. I never said during that time that I was quitting, and I never stirred up shit in #dsdev over it. Quit the damage control and face the facts. And of course I haven't talked to you in months. I ignored you on IRC when you tried to use me to ban members from #mellowdsdev.

To those who want to take the source and 'continue' where I left off: please don't. People are not going to do their reasearch, and they will associate your updates with my name. I don't want angry emails or forum posts if something you change messes up a card or screw up a Nintendo DS. If you need, feel free to look at the source and take code snippets, but please give credit where credit is due. I really don't want you taking it upon yourselves to continue the project.

To those asking me to pull the last two posts offline, I don't think I will. What's said is said and what's done is done, and pulling posts will only be viewed as a cowards way out. I stand by what I said, and even if it was made in anger, there was several months of frustration and truth behind those posts, and I would prefer they stay where they are. People are claiming I am being immature about things, but this is my personal blog, and I think a person is allowed to get things off their chest once in awhile.

Also, to the two people that donated to DSOrganize: I will be happy to send the money back if you would like, since for now I will not be purchasing new cards to test on. Email me of you would like your donation refunded and I will send it back, plus the paypal processing fees, so you don't lose any.

In closing, I know that DSOrganize has made me a bit of an internet celebrity in the NDS community. I am as shocked as anyone else, as I never expected anything I would do to get this popular. I am honored to have made it onto so many people's NDS consoles, and perhaps some day, I can continue. For now, though, things are going to have to change a little before I consider coming back, if at all. Dragon out.

How DARE You StoneCypher

September 30th 2006, 10:40:00 pm

This isn't about the shit you have caused in #dsdev and #mellowdsdev. This isn't about the lies you spread, or any of the bullshit you cause. This is directly between you and me. How DARE you use my blog comments to spread your fucking shit on how I am a liar. You have some nerve after all that you have said to me and about me. I don't care how vehemently you deny these alligations to the public. For all I care, you can spread your propaganda all over the scene channels and all over the forums. But I KNOW that you know what you did, and I KNOW you know how you treated me, and yet, you use my blog against me.

Fuck the Scene

September 30th 2006, 2:05:00 am

I'm flat out tired of this bullshit. There is nothing but rot left in the DS scene. From SC splitting the scene to card makers not releasing drivers and everything inbetween, it is just fucking ROTTEN. I quit. Good fucking riddance. I hope you are happy. If you want to complain about this, go see the people in #dsdev and #mellowdsdev on efnet.

What's up with this...

September 18th 2006, 10:30:00 pm

Anyone else notice that MaxConsole has placed the news that DSOrganize runs unmodified on their card system, yet hasn't even posted about my latest update?

DSOrganize 2.3, Source out!

September 16th 2006, 2:02:00 am

Hey everyone! I've recently put out DSOrganize 2.3, as well as the source for the project. This release is a maintenence release, and I decided to put it out now because with this semester, I am really not going to have time to release anything until after finals in December. I figured I would at least get a version out that has a few more bug fixes and such, before leaving the project to get stale for a few months. Don't worry, as I am not dropping the project, and have big plans for it when I can start working on it again!

As for the source, I was very hesitant to put it out, but since so many poeple would like to see it, I've made it available online. I really really don't want poeple to make modifications or repost their own compiles, aside from cart compatibility tests and such, as this IS my personal hobby. If you must include it in a commercial project or recompile with modifications, please talk to me first.

For the time being, feel free to hang out in #dsorganize on It's a great place to meet other members and usually get quick help and such!

Card Compatibility and Such

September 3rd 2006, 2:48:00 am

First, I will start with an announcement. From here on out, M3 products WILL NOT be officially supported. I will still put out compiles with the current (semi-working) 2.25 drivers, but I will not actively continue to fix them. I'm sorry it had to come to this, but I started DSOrganize as a fun little project, and with the constant stress on card compatibility, it is becoming a chore. I have tried numerous things, including using old beta drivers, and the newest drivers on the CVS. Even when I don't change the driver, compatibility changes per compile. So I repeat, I will NOT support ANY M3 device officially any longer. This includes the M3CF, M3SD, M3miniSD, and the G6, as well as any other new products that they spit out.

The second announcement goes out to card makers, as well as casual homebrewers. Card makers, PLEASE consider releasing official drivers in source form to the community. When you make a new card and claim it is compatible with homebrew, new users do not understand that drivers have to be written. The creators of homebrew take the heat because logically, if a card suports homebrew and a homebrew isn't working, it must be the programmer. Also, homebrewers PLEASE research what you are buying. I am more than happy to reply to a personal email on what I recommend to use with DSOrganize, and I'm sure most other homebrewers would be happy to do the same. There is also a perfectly usable FAQ and forums for you to find out other's successes with cards. If you have a product that is not supported by DSOrganize, please petition your card maker to put out official drivers. Asking me only does so much good, as I can only implement your card if there is a reliable driver. Asking chishm is only so good, as he would need to spend many hours reversing the card, and sometimes doesn't even have the card to test on.

As of right now, DSOrganize is tested working on GBAMP, NinjaDS, MK2 and MK3 (although NeoFlash products don't boot homebrew, they still work as storage when booted from a GBAMP). These are the only cards I own, thus the only cards I can guarantee the greatest success on. Reports state that EZ4 with read only support works, and SC CF, SC SD, and SCLite are all working, although I cannot guarantee it works to your satisfaction.

Also, before making bug reports, PLEASE be sure you are doing things correctly. For example, I got a ton of reports saying .ds.gba didn't boot on M3 and to please merge the homebrew databases so M3 could get .nds. I deleted all my work on the M3 database and merged it with the GBAMP database as so numerously requested, only to get a flood of reports saying that their M3 doesn't work with .nds. A recent conversation with someone has revealed the fact that .ds.gba booted by just pushing A TWICE. This will NOT be reversed, as I am not redoing all those packages, so in the future, please investigate to see if there is something you could be doing different.

I know that this sounds very rash, but I am starting to get tired of working on DSOrganize due to all the stress of keeping multiple releases and constantly trying to fix things not related to my code. I hope you all understand.

DSOrganize Gray Update

August 29th 2006, 2:45:00 pm

I have updated gray with new drivers for Max Media CF. Let me know if it works, and what does or doesn't work on it (IE booting homebrew, writing, etc). Thanks!

New DSOrganize Blue

August 28th 2006, 11:38:00 pm

I have cracked open the backups and grabbed the files in the fatlib from 2.1 in the hopes that this version can be properly patched for SCLite people, and that it would work for the rest of the poeple for whom 2.25 broke. Head on over to my page and download the blue release, and let me know!

DSOrganize 2.25 Out!

August 28th 2006, 4:13:00 am

Hey again everyone. I'm putting out this release pretty quickly as it is just meant to be a maintenence release. Big things in this release include a bunch of fixes for random bugs and a new SuperCard driver, so hopefully the SCLite will work fine. Also, I took out the driver for ninjaSD and MK2/MK3 on the Blue and Green because you guys whined so much about the 3 second boot time. Enjoy, as this might be the last release for a few weeks, what with school and such taking up my time now.

Head on over to the DSOrganize homepage to download the latest package for your card. Also, any questions, comments, just want to chat? Feel free to drop by #dsorganize and say hi.

DSOrganize 2.2 Final Recompile

August 17th 2006, 1:20:00 am

Since discovering that fixing SuperCard booting broke M3 miniSD V2+ booting, I've decided that I have to (unfortunately) start to maintain two compiles. Instead of naming them after a random card it should work with, I've decided to color them, and let people collaborate and post feedback on which version works the best. Please head on over to my homepage at and try the two posted versions. Feedback on what card you have and which one worked for you is VERY appreciated and will go towards making the FAQ more accurate.

Thanks guys!

New SuperCard Test!

August 16th 2006, 5:38:00 pm

Ok, I've gotten confirmed reports that this new test version works with SuperCard! Get it Here and write back! Also, get in #dsorganize on to chat, get support, tests, and the like.

This test is confirmed with these adapters:

Full support:

Read Only:

Not working:

It is unconfirmed with these adapters:

Supercard Test Version

August 16th 2006, 2:00:00 pm

I have compiled a newer test library with the code that used to work for SuperCard CF/SD, and would like you guys to test and report back to me on it. Get the file here and try. Also, Max Media CF users, please give this one a spin too, let me know.

Tested working on: GBAMP, NINJASD, MK2, MK3.

DSOrganize 2.2 Final Out!

August 16th 2006, 3:43:00 am

Ok, so I worked pretty hard due to some requests to get it out as fast as possible, and DSO 2.2 Final is now out! The list of fixes on this one is longer than any other set of updates, I really tried to polish this verison for you guys! Please note that even though the G6 team released a fat lib, I will not be adding support until they release the source for their adapter. It's not just that I don't want to have a second compile just for G6, but also I have added functions to my modified version of the fat lib that are needed for DSOrganize to run, so it is physically impossible.

Maybe someone can reverse the code and provide it as a standard interface to chishm's fat lib?

Anyhow, you can find the update on my site at Happy homebrewing! Please give me feedback on SuperCard/M3 compatibility, as well as Max Media CF compatibility! Thanks!

About DSO 2.2 Final

August 14th 2006, 2:42:00 am

Well, I know you guys are all hot and bothered about the next release of DSOrganize. Unfortunately, it looks like I will be holding onto the release at least until the end of this week. I want to get down to adding a few more requested features and smoothing out some more pages, as this is going to be a final release, not a preview. I'm sure you will think it worth the wait, as I have fixed a few bugs in IRC, updated the configuration screen, changed a few icons, added MANY things to the browser, and worked on FAT compatibility. Hopefully this next release works fine for those struggling with their CF cards.

SHAMELESS PLUG! As you know, it is rather hard to test for accuracy and compatibility on a card that you don't have. I am able to test on the GBAMP and the ninjaSD, as well as MK2 and MK3 as I own one of each of these, but with other cards, I have to hope that it works. Also, being vocal about the release is appreciated. I would much rather hear about it a day after so I know what I did fixed/broke something on your card, rather than stumble on someone whining on some forum 3 weeks later!

Thanks to everyone that follows my work, you make homebrewing fun!

Libraries out!

August 7th 2006, 11:06:00 pm

I've put out a new version of libFB, as well as released libPicture, the library I put together to display pictures in DSOrganize. Also, I've put up an edited version of chishm's old library for FAT. Check them all out at

Plese note that some of the links on this blog are no longer valid as the code and executables for depreciated examples have been deleted.

Why Am I Not Posting Here?

August 4th 2006, 1:13:00 pm

I kinda got bored with blogging when I didn't have little updates to the minigames that I was making, but I realized that although I have a perfect medium for releases (my site) and a perfect medium for Q&A and bug reporting (my forums), there is no good place to make announcements, etc. I've been doing it for now in my forums, but that's not a very good place to grab information, as topics shuffle around a lot. I think I will recommission this blog as a decent place to put out information as to the current status of DSOrganize, etc.

So, to get the whole thing rolling, here are a few recent occurrances. The homebrew database has taken a few new moderators to help the flow of homebrew onto it speed up a bit. Also, a new loader in the code should allow people without a supercard/gbamp to boot files within DSOrganize. I should have a release out later today/tonight, so check occasionally on my site to see if I've got it out yet.

New DrugWars!

January 15th 2006, 5:05:00 am

I have completely revamped the DrugWars release I have had out for ever and ever... Also, I have put out a new more useful libfb. Details at Enjoy everyone!

Dual BG Stuff

January 8th 2006, 3:40:00 pm

I am starting to do NDS Dev again. Sorry for the loooong hiatus, my NDS bricked with Mario Kart and I had no way to recover it until now. First things first, I have put down the clickRPG project. Sorry to disappoint anybody, but I kind-of lost interest in it. Second, I have a new demo for you guys. I had a lot of trouble getting dual exrot backgrounds to work, so when I finally got a working piece of code out, I decided to turn it into a demo for you guys out there to learn from. Don't ask me to explain every line, as I'm still somewhat shaky on the whole dealie, but the code can be copied, used as a template, or even used as wallpaper if desirable, I don't care.

Here you guys go: dualBG.rar

NOTE: Requires libfb to compile. You can easily take the text display portion out to remove the need for libfb.

DS Text Editor v.3

October 13th 2005, 2:03:00 am

I've already whipped out the next version of the text editor. I've gotten everything done on the to-do list, and fixed a few other bugs I have found, bringing this project to a releasable and usable version. The compiled version and source code to this project are both available for this release. Hop on over to my NDSDEV Site to grab the latest binary or source code.

Working Beta!

October 10th 2005, 7:18:00 pm

I'm posting a working beta of the DS Text editor. No longer is it a viewer with an annoying cursor, but a text editor! There are some bugs, such as horrid things going wrong when it can't wrap a line properly, and I'm sure there's other stuff out there. Please comment! Get it link removed.


Updates to Multiboot Extensions

October 9th 2005, 10:55:00 pm

I have updated the mod player extension to the second version. This release adds the ability to go back using B, stop and restart the mod using A/Y, and looks a bit better too. Get it link removed.

Also, I'm going to release the pre-alpha version of my text/ini file editor. So far, it has scrolling and cursor support, as well as saves back to the file, but nothing else. Please be cautioned as pressing start to save and go back WILL save your file in unix file format, not windows! Keys are arrow keys for the cursor, L+R for page up and down, select to change from insert to overwrite (does nothing now, because you can't insert or overwrite anything), and start to exit back to the main screen. Comments are appreciated. Get it link removed.

Mod Player for GBAMP Multiboot

October 6th 2005, 12:49:00 pm

I recently saw that Mighty Max had put out a multiboot loader for the GBAMP ( Since this is the method I use to load code, I was very interested. Imagine my surprise when I found there was already support for 3rd party addons. Around one hour after finding that out, I had a working .mod player that runs using the multiboot loader.

Get it link removed!

To use this thing, unzip the .nds file to mb_data/apps, the .bmp file to mb_data/icons and the .mbe file to mb_data/ext. Now, just add .mod files to any random directory on your compact flash card, and select them using the multiboot loader.

Enjoy the first release!

More Updates

September 17th 2005, 12:36:00 am

Just to let you guys know, I haven't abandoned you. I have been working on other things, and just now got to putting out the next version of the game. It's essentially the same in all respects, save for a much smaller file size (faster wifi for the same stuff!) and has been named to Separation Anxiety. I am still working on the menu graphics, so don't expect that to be finalized. Anyhow, here you go, compression and all:

More Developments...

September 6th 2005, 1:11:00 am

-=Jstart=- said...

Cool! Sounds like this game will be really fun and a great tool! If it could be done through wifi that'd be awesome too but would limit your content.

This is EXACTLY what I am aiming for. Why else would I be so obsessed with writing compressions and stuff for already small sprites? I really hope for a game thats completely wifi'able.

Update on the pallated sprites: This turned out to be a VERY good idea. I already have a utility that takes an uncompressed libfb sprite and converts it into a compressed libfb sprite (yes thats right libfb will have it built in). I have only converted a few of the menu sprites and one in-game sprite, all of which are rather small, and I already saved a good 15kb! I think I can get the game completely under 300 kb including all item and menu sprites with no deleted content right now.

Idea for the Touch RPG

September 5th 2005, 7:21:00 pm

First, I'd like to take the time to respond to the comments that I got...

davr said...

A great beginning! I love these kind of games. The graphics are perfect too

Thank you, much appreciated. :) I love these games VERY much and almost wish I wasn't making it so that when it came out, I could enjoy the storyline. ;P

JaJa said...

Heh, great game. Can you get further than that grate?
You should try and make it so it's easy to change the story and graphics so it's like an rpg maker. I would love to make an rpg, but don't know (and haven't the time to learn) how to code.

This is almost exactly like how I am going about this. There is a main engine, and then a script portion that tells the engine what sprites to show, what to display, and what sounds to play. I also have a script editor/compiler that would allow someone to VERY easily change the plot around (if they invested a little time learning the script). I want to release my sprite creator as well soon, but will do so after the update is made (that I will be mentioning soon).

-=Jstart=- said...

WOW! Awesome! Love the touch and sound stuff plus gfx are great. Would love to see this truned into a coding library like libfb! I have been trying to figure out sound forever so yah awesome game! can't wait to play the whole thing!

Again, thanks! I don't think I will be turning it into a coding library itself (although it relies HEAVILY on libfb), but the game shell is easy enough to take out data and modify that anyone with the source could have their own game out as fast as they could create the levels.

Now... I was sitting here pondering ways to save space, and I realized that most of my sprites are quite large because each pixel is two bytes, not because of their actual size on the screen. I also realized that most of my sprites have very few colors (no more than twenty on the largest ones, closer to 3-4 colors on average). Can you say pallates anyone? On sprites without many colors, I think I can confidently achieve a "compression" rate of 1:5 or almost 1:6 in some cases. This is good news, as I wanted this to be wifi'able, and if not, at least fit on any homebrew boot method (~2.7MB, 4MB max respectively), so any space saved is awesome.

Real Beta!

August 30th 2005, 12:37:00 am

This is a demo for everyone in #dsdev and #<zomgsecretlol> to have a look at and comment on. I appreciate every comment or critique. As stated before, I'm still looking for a name and a good plot, but I have the beginnings of one in my mind...

Have a look at it here at

Enjoi ~_^

ZOMG Content Already?!

August 28th 2005, 11:16:00 am

Bullshit! Nothing can come of blogging this quickly! I cheated. :< to see my latest work on the touch rpg. It still does not have a name, a plot, or some of the graphics on the first level, but most of the engine bugs have been worked out and I can concentrate on the fun. \o/

If you have a good idea for a decent plot for one of these things, or have ideas on levels or a name, etc (that kinda goes together though), you can comment and I will consider. Anyone who contributes an idea thats teh win can be in the credits. Kthx ^_^.

Start of Blog?

August 28th 2005, 11:06:00 am

I decided to start one of these blog thingies in order to post updates about my NDSDEV attempts. For old stuff and working projects, you probably want to visit my site at I want to use this page to post updates on libfb and my touch based RPG. Comments are welcome :)