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.

Prototype routing done!

Schematic mostly doneee