MP3/FLASH Test Platform

While I am waiting for the main BCII PCB to come back, I am building a test platform for the MP3/FLASH  add on module.  I had developed the code for this module using the Microchip PIC32MX Curiosity Board, a MikroBus Click MP3 module and a MikroBus Click 64Mb FLASH Module.  There is still more code development and I thought it would be better to use the known Microchip Curisoity board to develop on than the new untried BCII PCB. 

I designed a small carrier PCB that would plug into the two MikroBus slots on the Curiosity board and pickup all the signals. 

Then the completed MP3/FLASH module would plug into the carrier board.  Here is a picture of how that will look.

Now all I have to do is assemble the two boards.  The carrier will be easy.  The MP3/FLASH module will be more challenging.  Plus the MP3 portion is handled by a VS1053B and only AdaFruit had them in stock.They are in NYC, so we will see how long this takes for them to come in.

COSMAC 2020 ELF Build (part 1)

Glue Logic Design

One of the first decisions that had to made was how to handle the glue logic.  When I fist started working on this many years ago, my idea was to use an ALTERA (Intel) MAX7000s CPLD.   This was one of the first in system programmable, inputs were 5V tolerant and the outputs could be made 5V CMOS compliant with a pull up resistor.  Well fast forward to 2020 and MAX7000S is only available in the excess inventory market.  Prices are not bad ($10-$30 each for 7128 in a TQFP100), but who knows what you are really getting. 

Why ALTERA (Intel)?  Mostly because it is what I am familiar with and the free software still has schematic entry.  Not motivated to learn VHDL at this point.  That could change, but not for now.  So I then moved onto more active parts, MAX II and MAX V.  Well MAX V was more than half the cost of MAX II and more recent.  So I started looking at this family first.  The CON to these families was limited package options.  BGA packages were out for two reasons, I cant solder these down and they drastically increase the PCB layer count and complexity.  So this left just two packages, EQFP64, TQFP100 and TQFP144. 

They way I partitioned the logic would require at least 3 TQFP100 packages. The EQFP64 just never had enough pins.  With common pins and interconnects eliminated, it would all fit in one TQFP144. Another MAX V advantage was part migration with in a package.  With a TQFP144, there were 4 different parts.  Using the middle part, 5M570Z, I have used 25% of the internal resources and 103 of 114 pins.  This gives a lot of flexibility for future improvements.  Having all the logic in one part is also useful, since only one change is needed.  Finally these parts come with 8KBits of FLASH.  I am going to look at how this might be mapped into I/O for configuration or storing nonvolatile data.

Now for the very big disadvantage to this family and every family after MAX7000S.  There is no simple 5V CMOS compatible interface.  The inputs are not 5V tolerant, a resistor and a diode are needed to prevent damage.  The outputs also need a diode and a resistor to produce a 5V CMOS compatible signal.  Not very enticing.  Looking at some commercial development boards on the market showed they were overcoming this by using 74LVC voltage translators (74LVC8T245, 74LVC1T45 and 74LVC2T45).

So after some soul searching, I have decide to go this way, a MAX V part and multiple voltage translators. Once I finish the design I will publish the higher level CPLD schematics to show how I did this.

Bricks By The Bay 2020

We had hoped that this excellent convention would happen in July.  But the organizers have had to cancel.  They do have a date in Jun 2021 for next year.  They are organizing a virtual expo, how this will happen is still being worked on.  It will be interesting to see how this happens.

For more information, go to the Bricks by The Bay website.

More BC II Progress

The last few days since the last post on this have been trying.  Lots of information to plow through on how to make a bootloader work on a PIC32.  After solving the bootloader connecting as a USB HID device, it was off to loading an application.  This required modifying the linker script.  One would have thought this was straight forward, but it wasn't.  Reading the Micorchip forum found lots of people looking and what appeared to be lots of solutions.  Plus Micorchip had an old App Note (AN1388) that described the process.  So here are the parameters I used

• Bootloader occupies 56K bytes(debug console/lots of printf), allocated 0x1000 space to it.
• The PIC32MX470F512H has 512K bytes of program space, allocated 384K for the App.
• App Space starts at  0x9D01 0000
• Interrupt Vector table is at 0x9D01 0000
• Reset Address is at 0x9D01 1000
• App code starts at 0x9D01 1200

Through basic testing it all works as I expect.  There is still more testing needed and I need to update the PC program I use with my PC based applications.  Any firmware upgrades need to be part of the user application and not a separate program.

The important part of the linker script is shown below. The bootloader linker script was the default with only the length of the kesg0_program_memory changed.

OUTPUT_FORMAT("elf32-tradlittlemips")
OUTPUT_ARCH(pic32mx)
ENTRY(_reset)
/*
 * Provide for a minimum stack and heap size
 * - _min_stack_size - represents the minimum space that must be made
 *                     available for the stack.  Can be overridden from
 *                     the command line using the linker's --defsym option.
 * - _min_heap_size  - represents the minimum space that must be made
 *                     available for the heap.  Can be overridden from
 *                     the command line using the linker's --defsym option.
 */
EXTERN (_min_stack_size _min_heap_size)

/*************************************************************************
 * Processor-specific object file.  Contains SFR definitions.
 *************************************************************************/
INPUT("processor.o")


/*************************************************************************
 * Processor-specific peripheral libraries are optional
 *************************************************************************/
OPTIONAL("libmchp_peripheral.a")

/*************************************************************************
 * For interrupt vector handling
 *************************************************************************/
PROVIDE(_vector_spacing = 0x00000001);
_ebase_address =  0x9D010000;

/*************************************************************************
 * Memory Address Equates
 * _RESET_ADDR      -- Reset Vector
 * _BEV_EXCPT_ADDR  -- Boot exception Vector
 * _DBG_EXCPT_ADDR  -- In-circuit Debugging Exception Vector
 * _DBG_CODE_ADDR   -- In-circuit Debug Executive address
 * _DBG_CODE_SIZE   -- In-circuit Debug Executive size
 * _GEN_EXCPT_ADDR  -- General Exception Vector
 *************************************************************************/
_RESET_ADDR              = 0x9D011000;    /*  0xBFC00000;*/
_BEV_EXCPT_ADDR          = (0xBFC00000 + 0x380);
_DBG_EXCPT_ADDR          = (0xBFC00000 + 0x480);
_DBG_CODE_ADDR          = 0xBFC02000;
_DBG_CODE_SIZE           = 0xFF0;
_GEN_EXCPT_ADDR          = _ebase_address + 0x180;

/*************************************************************************
 * Memory Regions
 *
 * Memory regions without attributes cannot be used for orphaned sections.
 * Only sections specifically assigned to these regions can be allocated
 * into these regions.
 *************************************************************************/
MEMORY
{
  kseg0_program_mem    (rx)  : ORIGIN = 0x9D012000, LENGTH = 0x60000 /* All C Files will be located here */
  kseg0_boot_mem             : ORIGIN = 0x9D010000, LENGTH = 0x0 /* This memory region is dummy */
  exception_mem              : ORIGIN = 0x9D010000, LENGTH = 0x1000  /* Interrupt vector table */
  kseg1_boot_mem             : ORIGIN = 0x9D011000, LENGTH = 0x1000 /* C Startup code */
  debug_exec_mem             : ORIGIN = 0xBFC02000, LENGTH = 0xFF0
  config3                    : ORIGIN = 0xBFC02FF0, LENGTH = 0x4
  config2                    : ORIGIN = 0xBFC02FF4, LENGTH = 0x4
  config1                    : ORIGIN = 0xBFC02FF8, LENGTH = 0x4
  config0                    : ORIGIN = 0xBFC02FFC, LENGTH = 0x4
  kseg1_data_mem       (w!x) : ORIGIN = 0xA0000000, LENGTH = 0x20000
  sfrs                       : ORIGIN = 0xBF800000, LENGTH = 0x100000
  configsfrs                 : ORIGIN = 0xBFC02FF0, LENGTH = 0x10
}

Soft Wear Efforts

The soft wear side of the house has been quite busy the last month+.  They have made over a 100 masks for the local hospital here in Reno and for Kaiser in Santa Clara (still have connections and friends in the Bay Area).  Here is a picture from earlier of one, when it was still rather cold in Nevada.

 Here are some samples of the ones they are churning out.  All sizes, shapes, and colors.  Right now we are only doing these for the local communities and their efforts to help those in need.  So we are not taking any orders for custom masks, but check back things can change.

Production/Test Lab State

Well my production/test area is complete for now.  It is about one third of what I had before, but it will do until the final move happens in the fall.  I will be setting up a Lego build area in the next few weeks so that I can continue to work out MOC designs.

Brick Controller II Progress

Before all this insanity started, I was very close to completing the design on the Brick Controller II.  In this post on 6/14/19, I described the state of the hardware.  In earlier post I described the progress on the various software components.  One item that was missing was the USB Bootloader.  I feel that this is very important to be able to upgrade the firmware, both for the inevitable bugs that crop up and for future enhancements.

Well the Bootloader has been causing me problems for the last few days.  It kind of worked, then did not work at all.  I actually went back to one of my earlier blog posts to read how I solved the original USB HID problems I was having. That at least allowed me to make progress and the bootloader seems to come up reliably now.  Next step is to integrate the application and see if I can update the firmware.

More later.

Expanding the Space Port MOC

After watching Lego Masters, I was inspired again to expand the Bricks By the Bay 2018 MOC I built, especially since Richard and Flynn are members of BayLUG.  As a reminder this is what it looked like in 2018

and the subset I took in 2019

As you can see the design is modular with angular connectors like these

 This how the curve was created.  The new plan is to reverse these connectors and instead of a concave overall design, it will be convex.  Then start to build a cliff terrain behind this.  In a complete fantasy world it would be a complete circle around a mountain.  Here is a sample of the cliff terrain from another MOC at one of the Bricks by the Bay.

There are some issues that need to be solved first.  One, building realistic terrain.  I have seen some good examples, so research is needed in this area.  Second, how to make it curve at the same rate as the modular portions.  finally, how to make it transportable, that is modular.  If I can't move it, not going to worth anything.

More as I dive into this also.

Introducing the COSMAC 2020 ELF

As explained in an earlier post, I have started a pure vanity build of an CDP1802 system, which does not fit what we normally do, but it is something I have wanted to do for a long time.

Some background: I have been fascinated with microcomputers since 1975 when the digital logic professor came back from a CA seminar with an 8008 system.  My career started in the Navy after graduation, but I wanted to keep up my EE knowledge so in 1977 I acquired an 1802 ELF.  That was followed by a complete rebuild into a system with 64K of memory, built in EEPROM programmer, multiply divide unit, composite video interface and much more.  It took me several years, since the navy kindly asked that I spend time overseas for long periods of time.   In those days the memory was composed of 1K x 1 SRAM chips that consumed 50mA each or 30mA for the low power version.  So I decided to build these in 8K wirewrap cards.  Designed an ingenious bus interface long before the ISA bus was around.  But an 8K card had 64 2102 chips on it plus some CD4000 glue logic.  The low power version consumed almost 2 AMPS.  To get to 64K was going to take 8 cards and 16A @ 5VDC.  So I found a large transformer, high current stud diodes and large capacitors to build a 30A @5VDC power supply.  Unfortunately I never took pictures of this monstrosity.  By the time I finished wire wrapping the first 8K memory card and managed to get it working, Hitachi, Sony and few others produced the HM6116 2K x 8 SRAM chips.  These consumed only about 40mA per chip and so 4 of these at 160mA replaced the entire 2102 at 2A.  By the time I installed some these, the HM6264 8K x 8 SRAM arrived and entire 2102 board was replaced with a single chip using 40mA.  The final incarnation is shown here with the main board removed from the custom case I built.

The design philosophy this project will follow is delineated here.
1.    Use as many LSI CDP1800 series parts as possible, at a minimum
    a.    CDP1802/1806 CPU
    b.    CDP1854 UART
    c.    CDP1855 Multiply/Divide Unit
    d.    CDP1869/1870 Video interface System (VIS)
    e.    CDP1871 Keyboard Interface
    f.    CDP1877 Priority Interrupt Controller (PIC)
    g.    CDP1879 Real Time Clock (RTC)
2.    All MSI type parts will be 74HC instead of the original CD4000 type ICs
3.    All glue logic will be contained in CPLDs to reduce space and increase flexibility
4.    Will use a PCB instead of wire wrap

Follow along as this project slowly progresses.