Shepherding electrons

Memory Address Register (MAR) and Memory Memory is (obviously) an essential part of a computer, and this blog post is part of a series and concerns adding different types of memory to my 8-bit computer . The memory of my 8-bit computer is addressed with a 16-bit address register, which gives access to 64k of memory.  I have divided this memory space into ROM (EEPROM), VRAM (for the LED WS21812b module ) and SRAM, with the following memory divisions: 0x0000-0x7FFF: ROM 0x8000-0x87FF: VRAM 0x8800-0xFFFF: SRAM A zero-page in SRAM can be accessed at 0x8800-0x88FF.  In terms of the electronics, this is achieved by not writing to the high databus (D8-D15), and instead letting a set of pull up and down resistors set the high databus to 0x88 by pulling D15 and D11 high, and D14-12 and D10-8 to ground.  By not writing "0x88" explicitly to the high databus, instructions that access this memory are quicker than they otherwise would be.  The address decoding logic is fairly stra...

Every 8-bit computer needs some kind of output display, whether this is a LCD display, or a 7-segment display, it needs some way of displaying data to the outside world.  Wouldn't it be cool to have a pretty RGB LED display as a way of not only showing the output of computation, but to act as a screen for showing animations, even playing simple games?  At the very least it would be cool to have a kind of "RAM visualizer" to show the contents of RAM for debugging purposes. With that in mind, I recently came across a post on the timing for WS2812 LEDs, part 1 and part 2 , in which the blog post author Tim sets out the limits of the WS2812 LED protocol and shows they are rather flexible and not as stringent as the official datasheet suggests (i.e. see here for WS2812b datasheet or here ). Further he suggests a way of controlling LED strips with a simple timing cycle, encoding either a 0 or a 1 bit, like so: Tim then goes on to write some assembly language to control WS2812...

Many ventures into the world of the ESP8266 chip and making Internet of Things devices would do worse than to start with the NodeMCU ESP-12E board.  I started my journey with the powerful but stripped back ESP-01S board - useful for projects such my IR-Egg and cat litter tray Twitter bot where space is an a premium, and very few GPIOs are required.  However I have recently got my hands on some NodeMCU ESP-12E boards and I'm enjoying the relative abundance of broken out pins, the builtin USB with 5V --> 3.3V conversion and programming over the USB.  So far I have used the ESP-12E boards in a couple of small projects, namely as a SPIFFs HTTP file server and as the reciprocal HTTP client . The board has a whopping 4 Mb of flash memory available, and an embarrassment of pins - I feel spoilt!

In my last post we setup System Workbench and setup some flashing LED code, we compiled it and uploaded it to the Pyboard.  We had to generate a HEX file in System Workbench, generate a DFU file and then upload the DFU file to the board - phew!  It's actually fairly simple to automate the DFU conversion and upload process.  First, download the DFUSE-commandline utility, here:

I've had a MicroPython board sitting around my work bench for a while.  I think it's a brilliant way of interfacing hardware and using Python in a very straightforward way.  I've thinking about getting into into programming ARM chips for a little bit, and my MicroPython board came to mind.  After all, it's potentially a great development board if only we could hack the firmware that comes with it!