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.