Projects

bleu-romtools

The Bleu-Romtools are a set of tools that I've created over the years that have helped me create and edit ROMs for Arcade game hardware. Some of these tools will work with other systems as well. Genroms will take the output from your assembler/compiler as an Intel Hex File (IHX), and pad it ... [More] out into a defined ROM space. It will also pre-load the ROM space with ROM image files, so that you can make quick, reproducible patches for ROMs TuracoCL is a portable command line reimplementation of the TuracoClassic tool. It has no graphical interface (yet), and is meant to be run in an automated fashion from the command line or a makefile, which was not possible with older versions of this codebase. It loads and saves PCX and ROM file formats. Current development efforts will add an optional curses-based user interface, to allow for ROM editing from shell windows. TuracoClassic is a DOS-based sprite image editor for arcade graphics ROMs. It is quite old, and only works on DOS. It is highly based on AGE, but mostly re-implemented from scratch with future expansion and flexibility in mind. TuracoClassic requires MS-DOS libraries and has no command-line interface to control it. AGE is an even older DOS-based sprite image editor, like Turaco. It has a primitive graphical interface, and a Pac-Man map editor. It has its shortcomings, but works. [Less]

elementos

This project is meant to create an operating system to experiment with modern technology available on the x86 platform including various devices at the author's disposal. It is also an experiment with various techniques for accomplishing OS fundamentals such as memory management, scheduling, resource management, etc.

gogoboard

The GoGo-Board is a open-source low-cost robotics platform designed with easy construction for hobbyist in mind. It can be programmed with the Logo programming language, which let's you spend more time on what you want to do rather than on the hardware details. This repository focuses on the ... [More] hardware design and the firmware development. NewsApr 5, 2007 - The gogoboard code goes online. Finally we have released the entire source for the gogoboard (starting at version 3.5.) We hope this is a beginning of a productive collaboration that leads to a platform that allows more people to become engaged with robotic projects and learning activities. Policy for using this code & commercial interestsWe support those who wish to build and sell gogoboards as long as they understand and agree to our license and policy. Please contact the community via the gogoboard mailing list for more information. How to download the codeYou can anonymously download the gogoboard hardware design files and the firmware source code from the SVN repository. Click on the source tab for more info. For end users who only want the final design files and the pre-compiled firmware, please visit the GoGo Board website. If you are new to SVN. We recommend TortoiseSVN for Windows users. Here are some useful links: Overview of SVN from Wikipedia Simple guide on how to use TortoiseSVN GUI to checkout the latest source code. Practical guide to TortoiseSVN How to submit changesYou must be a member to submit changes. Please send membership requests to Roger. You are more than welcome to join the community. You also need a google account as well. Visit Google for more info. [Less]

hbcode

few libraries for embedded system use on Renesas mcu , Texas Ti MSP430

mega8-hob

this is a misc repo of projects from uni...

mikrowerk

This is the codebase of the mikrowerk microcontroller projects. So far, we have the following projects: USBTemp - a digital thermometer that can be accessed via USB. Meet-O-Matic - a timer that prevents meetings to take too long.

moasicsondemand

more later

pushpin

Pushpin Game Boy Color MIDI SynthesizerNoah Vawter and Brian Whitman are proud to finally present Pushpin, a MIDI synthesizer kit for your Nintendo Game Boy Color. Pushpin converts your Game Boy into a MIDI ready device that you can control from any keyboard, sequencer, or software. It comes as a ... [More] ROM file you program to any flash cartridge along with simple instructions to build a cable that hooks into the GBC's Link Port -- one end of the cable is a link connector, and the other is a MIDI in. Pushpin is controllable from every dimension, including 90 MIDI CCs. It's four channels of multi-timbral retro-video-game perfection. 2 square waves, a noise channel and a programmable wave channel. Each can be tweaked real-time from MIDI Controller messages. It's a great handheld battery-powered performance tool. Use it with any hardware or software sequencer you choose. Pushpin listens to and interprets MIDI note messages, continuous controllers for every single possible sound parameter of the Game Boy, pitch bend messages, and program changes. Pushpin requires a Game Boy Color for technical reasons. Please read the documentation for more details Pushpin.gbc file for use on a flash programmer for Game Boy Color devices Short hardware instructions Source code Discussion group [Less]

radixnine

An esoteric C# graphics engine My goals for the project are to make an engine that: is both real-time and off-line; is implementation and hardware agnostic (yet while using all available hardware acceleration); cross-platform (through Mono) and LGPL. Uncomprimising software design and high ... [More] extensibility are central themes. RadixNine is not tied to the fixed-function graphics pipeline; it can light (using arbitrary lighting engines) and render (using plugable rendering back-ends) objects of arbitrary nature (not just triangle meshes). It is so hardware independant that without a client program knowing anything about a rendered object, the client can "migrate" the object from one RadixNine "render host" to another-- eg: migrating a fractal approximation from a DirectX mesh to an OpenGL render list-- seamlessly between render frames and with full hardware acceleration! It can even switch between traditional rasterization and ray tracing mid-frame and so (eg:) switch from a course aproximation of that fractal to "the real thing" by changing one method call-- inside a scene with traditionally rasterized objects. [Less]

libedi

EDI is a collection of message transmission formats used primarily in electronic business-to-business (B2B) transactions where the implementation pre-dates the use of an XML-based format. EDI specifications exist for a whole range of transactions, most covering those needed to implement ERP in ... [More] association with suppliers. libedi aims to be as generic and flexible as possible, because each of the main EDI variants in widespread usage (EDIFACT, TRADACOMS, ANSI ASC X12, ODETTE) have different syntax rules. libedi does not concern itself with the transmission or reception of EDI interchanges themselves, simply with parsing them into an easily-digestible form, or generating them programatically. At present, libedi only performs a “low level” parse of an interchange: the result is a structure containing one or more segments, each containing one or more data elements (of which the first is treated as the segment's tag), in the order that they appear in the message. No attempt at present is made to produce a higher-level representation of the interchange based upon knowledge of the EDI variant in use. For example, libedi doesn't know that an UN/EDIFACT message is wrapped with UNB…UNZ segments, or that a functional group is wrapped with UNG…UNE segments. As far as libedi is concerned, there's simply a UNB segment, followed by a UNG segment, (followed by a UNH segment and so on), and then a UNT segment, a UNE segment, and finally a UNZ segment. This is likely to change in the future, however. libedi contains no support itself for reading and writing XML-based representations of EDI interchanges, but can be used to facilitate the development of software which does. Given the level at which libedi operates, it's unlikely that the addition of this as a feature would be useful currently: any representation produced by libedi would simply be the same segment and tag structure encapsulated within XML nodes, when what would generally be required would be an XML representation of the information contained within the interchange, structured in a way most suited to the type of information being represented (that is, for example. a purchase order would have a different XML document structure to a flight availability enquiry). It's conceivably possible to extend libedi such that it has support for (and knowledge of) specific EDI interchange types, but this can only be accomplished if the relevant format and structure information can be expressed in a generic and extensible manner (for example, something not dissimilar to XML Schema Definitions). [Less]