It’s alive!!!

The computer finally ran a fibonacci sequence code! I had to update many parts of the computer to get it to work with most of the 8080/8085 instruction set. But currently it can run a simple program!

I was dealing with an issue where the step counter just would not count, but that was just me messing up in the SC_RST logic.

Changes

• Instruction set: Wrote the python code to implement most of the 8080 instruction set, and code to generate the control EEPROM data based on the instruction set
• ALU: Had to add the hardware to enable for RRC/RAR instructions
• PC: Had to add output to data bus functionality for Jcc instructions
• MAR: Had to add functionality to increment MAR to save on time (not having to route through ALU)
• Temporary register: for XCHG instructions and JMP
• Misc: Made sure other signals were clock gated

Instruction decoder and connecting modules together

I connected most of the modules together, for now the computer works when controlled manually. I’ve also manually tested some modules by hand, and they seem to be working well together. I’ve had some bugs wiring the control EEPROMs to the control signals since I forgot the multiplexer outputs were inverted.

For the instruction decoders, to save on control EEPROMs, I’ve multiplexed some of the control signals that wont be used together. For instance the outputs to bus control signals, two should never be turned on together, so I can use multiplexing to reduce from 16 control pins to 4.

MAR, RAM updates, address decoder and ROM simulation files

I added DIP programming switches (their equivalent) to the MAR and RAM simulation files. I also changed most modules to expose their inner LEDs since you couldn’t see them when adding them as components. Also added the address decoder and ROM simulation files. The address decoder and ROM seems to work pretty well.

RAM, Output register simulation files

I built the RAM module in simulation with DIP switches to test, but I prob will actually build that into the actual computer. The Digital simulator didn’t have the MCU I planned on using, so I used the ol persistence of vision multiplexing used by Ben Eater in his videos.

MAR, PC, ALU simulation files

Made the simulation files for the memory address register, program counter and the ALU. The ALU still needs a bit of investigation into the behavior of the 74LS181 chips.

BC, HL registers simulation files

Wired up the simulation files for the BC and HL register pairs. Simulation using Digital (https://github.com/hneemann/digital)

Connecting things together

Connected parts of the modules together, still have to connect the control wires together for the instruction decoding part.

Clock & fixes

Clock

Basically the typical Ben Eater’s design of the clock module, nothing special, uses 3 555 timers in different configurations for both the manual step and the actual clock.

Flags register

Now the flags register has 4 flags, Negative, Carry, Zero and oVerflow. N flag is generated using the MSB of the sum out, since that would indicate a negative number when doing signed arithmetic. Zero is generated by ORing all the sum out and ANDing them together. The Carry flag is just taken directly from the 181 ALU. The Overflow flag comes from by NOT(XOR A7, B7) AND XOR(S7, A7)

Fixes

Now the load control words for registers are synchronous, this prevents issues with loading garbage from the bus close to clock transitions. Another fix was that the CF reader missed a VCC pin so I added that back.

BC, DE, HL register pairs, IR, output register, SC, LCD, parts of instruction decoder

BC, DE, HL registers

These registers can act together as a single 16bit register, outputting to the address bus, or also act like regular 8bit registers, outputting to the data bus. The HL register is special as it handles more indexing things. It has functionality to act as both regular 8bit registers and 16 bit register pair with increment and decrement functionality.

IR - instruction register

The IR stores opcodes from the RAM, and then passes it to the instruction decoder to get the microcode for the particular instruction/opcode. It is a simple 8 bit register using the 74LS573, without output to the bus.

Output Register

The output register consists of 4 * 7 segment displays. In Ben Eater’s original design, he uses eeproms to replace the logic for decoding. But in this case, I’ve elected to go with the ATMEGA328 microcontroller instead purely to save on board space.

SC - Step Counter

The SC handles the T-states/steps/micro instructions required to run a single instruction. Currently it uses a single 74LS161, which can handle up to 16 T-states. A reset control word is also implemented. The output of the SC goes to the control EEPROMs so that the computer knows what to do.

LCD

Using the typical 16x02 LCD, the LCD has an 74LS573 to buffer the data and the 2 control pins (enable and RS) are handled by the address decoder. 0xA00x enables the LCD using the 74LS138 decoder, and the 0xA001 sets the RS.

Instruction Decoder

I’ve decided to go with 4 W27C512 for the control EEPROMs, since it has 16bits address which is enough for 8bit opcode, 4bit step, 4 bit flag.

CF card reader, A/B register, ALU, flags register.

Finished the schematic for the CF card reader, the A/B register, the ALU and the flags register. Currently, the A/B and flags register are 8 bit.

CF card reader

The CF card reader uses the True IDE mode on CF cards, this allows for 8 bit data reading, and internal registers access using 3 address pins. CF cards uses 512bytes sectors which can be read sequentially using the IORD read strobe pin. But writing to the internal registers is also needed to set the card up for reading, hence the bidirectional bus.

A/B register

The A/B registers are 8 bit registers using the 74LS573. They have both an IN and OUT control words. The A register is directly connected to the ALU.

ALU

The ALU uses 2 74LS181 ALU cascaded together. They allow for multiple arithmetic and logic operations. The A register is directly connected to the ALU A input, while a temporary buffer is conected to the B input of the ALU to allow for loading from other registers or memory.

Flags register

Currently the flags register uses the 74LS573 to store the flags. Currently only 3 flags are wired, CF, ZF and EF. CF comes from the 181 ALU while the ZF is generated from the ALU output.

Memory address decoding, RAM, ROM, and CF card part & symbol

The 8 bit computer has a 16bit memory addressing. It is segmented into 4 blocks. From 0x0000 to 0x7FFF is the 32K of RAM. From 0x8000 to 0x8007 is the CF card/external storage segment. From 0x8008 to 0xEFFF is reserved for now. 0xF000 to 0xFFFF is for the ROM/bootloader.

Memory address decoding

To only enable ROM/RAM/CF when its their memory address sections, I used the last 4 bits of the memory address. If A12-15 are all 1, then its the ROM thats selected. Since the ROM memory is 0xFXXX. The RAM is selected whenever the A15 is 0, since the 62256 only has 15bits of address. The CF is selected when a A15-A13 is 0b100, which is decoded using a 74LS138.

RAM

The RAM uses a 62256 ram chip. The 62256 has common I/O so the 74LS245 transceiver is responsible for both RAM to bus and bus to RAM (ie STA instructions). I’ve decided to not include manual programming of the RAM unlike Ben Eater’s original design. It was simply because it would make the modules way too big.

ROM

The ROM uses a 28C64 for now. Its more for the bootloader/storing programs. Its buffered to the bus using a 73LS245.

CF card

The CF card section is for programs, it works on sectors, so the bootloader has to copy the code from the CF into the memory in order to work. Currently I found a CF card part and made a symbol for the CF card reader.

MAR, PC, SP

Made the schematic for the memory address register, program counter and the stack pointer.
All 3 modules output to a shared 16bit memory address bus.
Since the bus is 8 bit and the address bus is 16bit, the MAR, PC, and the SP are split into a High and a Low section, so it takes 2 fetch cycles to load a 16bit address into the modules (ie first fetch loads 8 bit into MAR_Low and second fetch loads 8 bit into MAR_High).

MAR

The MAR uses 2 74LS573 octal d-type registers to store 16 bits of information, it’s used for instructions needing to access data in RAM, ie LDA 0x7000. To allow for viewing the MAR data, its hooked up to LEDs and to the address bus using 2 74LS245 to act as buffer between the MAR and the address bus.

PC

The program counter uses 4 74LS161 to count up. I considered using the 74LS593, but after a quick search on Aliexpress and LCSC, found it too rare of a chip to use. So I went back to using the 74LS161. The program counter tells the computer what is the next memory address to fetch data from. This module is also hooked up to the main data bus to allow for jump instructions to work. This is also buffered via 2 74LS245.

SP

The stack pointer uses 4 74LS193 to allow for it to count up and down. First time using the 74LS193 so it was kinda confusing to figure out how to wire multiple of them up for cascading. The SP allows for subroutines to happen (JSR/CALL/RTS/RET instructions) as it allows for the computer to remember where to return to after the subroutine finishes. This is also buffered via 2 74LS245.

New plugins, night mode and page indicators

• Added new half sized clock plugins and a bad apple plugin
• Added a night mode for the app to allow for scheduled actions
• Made a new banner for the app

Fixed issues with weather provider and add AppWidgetHost functionality

• Added AppWidgetHost functionality to the app, allowing for third party app widgets to be displayed in the app.
• Removed GPS settings for privacy.
• Added a hold menu for widgets to rename the widgets.
• Added button to refresh plugins

Updated clock faces, alarms, and added provider API

• Added a clock face and updated the more colorful one to look better when the digits overlap each other.
• Added a new sensor bridge method getNextAlarm(), to get the phone’s next alarm
• Added the foundations for provider APIs and an example implementation using weather

The provider API handles more complex and repetitive tasks for the plugins. For instance, instead of having 2 plugins both having to send out API requests to get data, the app gets the weather data itself and distributes it to the plugins in a similar way to the SensorBridge JS interface.

The weather provider refreshes every hour and caches the response from open meteo and provides some basic helper methods. For instance getCurrentWeather() gives the current weather information in a JSON which is easily used by other plugins. It also manages weather icon loading and caching from OpenWeather and passes it to the plugin in base64.

Import plugin dialog!

Added a popup when the user imports a new plugin, whether from file picker or from the web that lists the requested sensor access, the domains the plugin needs access to and general metadata about the plugin (author, name, description, etc).

Also, added a way to rename plugins to be able to differentiate between multiple instances of the same plugin, especially useful when you want to have multiple configs of the same plugin!

Bug fixes & new plugins
I added a new weather plugin and a full screen digital clock plugin. I also migrated some of old plugins made before the plugin spec was written.

Also fixed a bug with stale plugin states. The old behavior was that the setup and the listeners captured a stale instance of the plugin params, which meant issues related to permissions and logging. For instance, logcat gives “PluginWebView com.geenk.standby D [Default Clock]” instead of logging it as [Weather plugin].

Also found an issue that kept crashing my phone over ADB screen mirroring, though the issue was more of an AOSP issue. (DEBUG crash_dump64 A Abort message: ’Splitting motion events requires a down time to be set for the target on connection …)

More battery stats

I have added support for more battery data to be accessed by plugins, now with support for most battery data. The SensorBridge.kt now using JSON to send information to the plugin because I was having issues with List being sent over to WebView not working correctly.

Also added a battery plugin demonstrating the new battery information.

Standby!

Sorry I forgot to break it down into smaller logs…
Standby now supports many new features.

1. Full plugin spec
   Now the plugins for the app are no longer just HTML files. There is now a structure to the plugin zip files with support for customization of the plugin itself (ie changing accent colors, turning features on/off) that is reflected in the UI.
2. Remote plugin uploading
   Instead of having to send the plugin to your phone, you can now enable a lightweight HTTP server where you can upload plugin files directly from your computer!
3. Better security
   With the full plugin spec, there is now a whitelist for the allowed domains and phone sensor APIs [note this still needs to be tested further and needs a UI when the user imports a plugin]
4. Side by side layout
   Now the app supports putting 2 half sized plugin next to each other, similar to iOS’s StandBy implementation. You can also have many different panels of plugins.
5. OLED burn-in protection
   Since the app displays a static screen for most of the time, I have added in an OLED protection feature that turns off very other pixel and alternates it to reduce burn it (user configurable, can turn off up to ~83% of the pixels, though it is very dim).Also, for phones supporting lower refresh rates, there is now an option to force the app to the lowest refresh rate when idle.
6. Better UI
   The old version had no animations and was pretty ugly in terms of UI. Now, the different buttons are animated and disappear when the app is idle. The UI now follows the phone’s colors.