Craft. Craft is a demo running on its own minimalistic demo platform. The demo platform is based on an ATmega88 microcontroller. Having successfully built a soundchip out of a microcontroller together with my friends in kryo, I wanted to tackle the greater challenge of generating a realtime video signal along with the sound. This is the result: Download lft_craft (Original video clip, Xvid, 89.4 MB)lft_craft_capture (Full screen video capture, H.264, 85.5 MB)Linus Akesson - Craft (Soundtrack, MP3, 3.3 MB)lft_craft_src (Schematics, firmware binaries and source code, 70.5 KB) Scene reaction Craft won the Console / Real Wild compo at Breakpoint 2008. Here's the Pouët page for Craft. How does it work? Just like your average 80's home computer, the entire design is centered around the timing of the video signal. A typical VGA-based, low-resolution CRT monitor will redraw the screen 60 times per second using an electron beam, which is sweeping across the screen one line at a time.
Music Video Schematics. Bit banger. Bit banger is my most constrained and minimalistic microcontroller-based demo yet. It won the Oldschool 4k compo at Revision 2011. Pouët link bitbanger-src (Source code, 7 kB)Linus Akesson - Bit Banger (MP3, 2.2 MB) What's all this then? Bit banger is built around an ATtiny15 microcontroller, which runs at 1.6 MHz and has 1 kB of flash ROM and a claustrophobic 32 bytes of RAM. In fact, those 32 bytes are the CPU registers. Only the most basic AVR instructions are supported; they occupy at least two bytes each, and can obviously not be compressed since they are executing from ROM, so a maximum of 512 instructions will fit inside the chip (fewer if static data is needed). The microcontroller supports interrupts, but they would have been too costly to use. At a clock rate of 1.6 MHz, the visible part of each line of the VGA signal swooshes by in exactly 36 clock cycles. I quickly arrived at the following overall design: Three registers make up a 24-bit frame buffer, organized as a 3x8 grid.
Enp-faq. RedBoot> is your bootloader for your ENP card, much like is for your host PC (still using Lilo ? Man, you must be kidding, right ?). It comes with different functions that lets you probe and test the hardware (yes, running "test all" on RedBoot while reading could be a good idea) and (of course) load and run software.Unless you encounter a situation that really requires it, there is no ROM containing RedBoot or any recovering tool so if you trash your flash, you'll have to . Take your time to read about the command, the memory map of the card and to toy with the commands. Loading something on the card This is a section where the "programmer guide" from Radisys is extremely detailed and useful.
DHCP configuration: your host (or any other machine on the lab LAN) should be running a DHCP daemon for giving the card its own IP address. TFTP configuration: this is the protocol you'll use when loading linux kernels. Running the Linux image So you have your image loaded. </i>*} HitchHacker Guide to ENP-2611.
Building a free OHCI host controller for USB « lekernel’s scrapbook. Implementing an OHCI host controller is not a straightforward task. The USB protocol is quite complex – making full hardware implementations difficult and inefficient – and its polled nature would put a heavy burden on a CPU if it were all implemented in software. The OHCI specification also makes things worse with regards to the controller’s complexity, by offloading a lot of work to the controller hardware. Block diagram of the softusb core An hybrid solution, dubbed “softusb”, was therefore chosen.
The USB controller includes a small dedicated microprocessor that runs a software version of an OHCI-compliant USB host stack. Only the parts that need very precise timing – namely data serialization and deserialization – is fully implemented in hardware. It is noteworthy that this approach enables switching between a host and a device controller by simply replacing the microprocessor’s program (and adding the appropriate pull-up/pull-down resistors on the D+/D-).
New hardware for C64: uIEC « ilesj's blog. Few days ago I got myself a uIEC/SD ordered from Jim Brain. I also bought a set of JiffyDOSes which should make a perfect match with uIEC. Even though I am a happy 1541 Ultimate user I wanted to get familiar with this device as it and other SD memory card applications using the same sd2iec firmware seems to be very popular. Also, this one can be nicely used in Commodore machines where the C64 Expansion port is not available. The device is professionally built and the main unit is not much bigger than the SD card socket. The JiffyDOS chips are neat flash memory based ROM chip replacements and they come with pre-installed on/off switch. Unlike 1541 Ultimate the uIEC, or sd2iec (the software running on uIEC) is interfaced only with disk drive commands. By default the uIEC/sd2iec is about as slow in loading as the real disk drive. JiffyDOS in the host machine would address both the usability and loading time issues as sd2iec completely supports JiffyDOS.
Related topic: Tips for using sd2iec. Stephen's Weblog » JTAG. So, many of you use JTAG? I’ve been using JTAG for many years now, which started with FPGAs, and has mostly been for CPLDs and FPGAs since- but it’s also a pretty widely used protocol for programming and debugging mid range microcontrollers all the way up to high end CPUs. I’ve always wanted to look into how JTAG worked in more depth, but never really had the time. Now, I do have some time (and some projects which depend on JTAG hacking) – so this post will go into the world of JTAG.
Many of you have probably seen the following diagram, usually in some CPU or FPGA datasheet where it talks about the JTAG port. There are really only a few core truths and fundamental operations to know about when working with JTAG: There are 4 data lines important to JTAG: TDI, TDO, TMS, TCK – All of them are expected to be pulled up with resistors (either in the chip or externally). First, the Instruction register is typically very small. As for actually doing stuff with JTAG?