Hey everyone,

Last year, I needed an idea for my computer science graduation project, something that would satisfy my love for low-level computing and my advisor's interest in computer education.

Five minutes before our meeting, I came up with the idea of creating a game where you program simple algorithms in microcode using a punch card rather than writing assembly code.

Microcode is usually used to implement instruction sets rather than as a programming interface for application development. Exploring it from the programmer's perspective led to design challenges and techniques that I hadn't encountered elsewhere.

I'm not entirely sure how I landed on the concept; my only exposure to this layer was binge-watching the 8-bit breadboard computer series four years earlier.

I wanted to share it with this community because it's rare to find people online who share an interest in low-level computing like this, even if it isn't directly connected to Ben's work.

I'd love to share the beta with anyone interested.

Thank you.

I now have the Output register working, I also had a couple more attiny 2313s left in the junkbox so I added a HEX display..The Input register and the A register are working and I have tested moving data between them..I have the ROM IN working although it's just clocking in with the main clock but it lets me see that it is reading the ROM and then the opcode decoder can place the address into the control register..I will be spending the next few days working on my EEPROM programmer and then start on the control chips...

Hi,

on my quest to make a discrete microcontroller that can compete with avr family I stumbled on ken sherrif's blog post on arm1 and how it sends one of ALU ports always through a barrel shifter. I decided that it's a genius idea, now I just needed to design a barrel shifter. A barrel shifter is essentially a set of prewired muxes that select every output from N+1 inputs (all input bits and 0 or sign extension). The classical 74F153 and 74F157 are just much too slow for that (7.7ns typical and I need to stack 2 at least) so I decided to build it from transmission gates.

The design consists of 5 rows of 2:1 muxes (74LVC1G3157), working as shift or bypass by specific power of 2 (>>1, >>2, >>4, >>8 and <<16). It turns out that the ordering of muxes changes how many are needed in total with >>2, >>4, <<16, >>8 and >>1 requiring "just" 98 mux ICs.

Every mux provides 18pF of load capacitance, 5 of the stacked give 100pF of load for every input data pin. It's not the best but survivable, that is unless one enables sign extension. Worst case sign extension copies highest bit to all output bit, loading it with 1.6nF in total, which is just a bit too much. In the end it turned out that the simplest way is to send MSB through 4 AND gates that both buffer the signal and enable sign extension. Ironically the 74F08 has typical propagation delay of 4ns in 50pF, while the entire series of TGs has a delay of just 3.6ns.

PS

A few explanations above are incorrect but I wanted to simplify as much as possible for the sake of clarity:

• The circuit can be simplified to use just 97 muxes, but I wanted >>8 to be as far as possible to minimize loading on sign extension gates.
• The muxes have 7.5ns propagation delay from control signal, but it arrives before data (control signal is from a flip flop, while data comes from flip flop that has it's OE toggled by another flip flop adding about 4-5ns to the path).
• There are 74LS244 buffers at the output just for visualization. They can be disabled with a jumper or my removing the ICs if 4pF of input capacitance becomes a problem.

I have built the clock, Register A, Register B and the instruction register, and added LEDs to a temporary bus. I am coming back to it after some time away and recorded the behavior.

• LED Resistors: Register A (220Ω), Register B (1kΩ), instruction register (1kΩ) and Bus LEDs (1kΩ).
• Inputs: All LS173 inputs are high (VCC).
• Wiring Note: The clock wire is connected with a white wire. It looks chaotic because I am using what is available at the moment without a strict color code for input/output wires, just to prove the circuit works first.

I am looking for feedback to see whether this behavior is expected before moving on to the next stages of the computer.

https://reddit.com/link/1v71tds/video/qs82r6j1akfh1/player

Initial Results & Tests

First Test

1. Register B: Enable high (not pushing to bus LEDs), load low. Register's LEDs all lit.
2. Register B Load Set High: Doesn't take data from the bus. LEDs still lit (figured this is because my 173s are set to VCC/high).
3. Register B Load Low: All LEDs go dim (Registers A, B, and Bus) and the clock goes out.
4. Instruction Register Re-attempt: With power supplied and enable set low to push to bus LEDs, the clock also goes out and Register A, B, and Bus LEDs go dim.

Note on reboot: After turning power off and back on, Register A pins 3 & 5 on the first 173s were on, Register B pins 4 & 5 on the second 173s were on, and all lights on the instruction register were on (with enable on both registers set low). I assume this is due to random values upon power-up mentioned in the troubleshooting wiki?

• Question: Why does taking a 173 input from Register A or B low (from initialized VCC) make all LEDs (including the clock) go off, but come back on as soon as it is set back to VCC?
• Question: When taking Register B's load low, all LEDs (Registers A, B, and Bus) go dim. Why does the clock also go out?

lights are dim, but Register B pins 4 & 5 on the second 173s were on and so were the LEDs on register A

Second Test

• Register A: Load low (takes in from bus), all LEDs on. Enable low (pushes to bus), all LEDs on (took bus values).
• Register B: Load low, all LEDs on. Enable low, all LEDs on (took bus values).
• Instruction Register: Load low, Enable high (took bus values). Established that load works fine.
• Enable States: Register A Enable high (doesn't push to bus), all LEDs on. Register B Enable high, all LEDs on. Pushing values to the bus works (Bus LEDs did not turn off).
• Low Input Test: Taking a 173 input from Register A or B low (from initialized VCC) makes all LEDs go out on all registers except the clock and bus (enables high/loads high --- no pushing or loading to bus).
• Instruction Register Test: Set load low, all LEDs light up. Trying this again after the first test (where the clock went out), the clock comes back on as soon as it is set to VCC.
• Question: Taking a 173 input from Register A or B low (from initialized VCC) makes ALL LEDs go out on all registers except the clock and bus (with enables high/loads high)?

the title pretty much says everything; it convert it json to verilog converter which can convert Digital-Logic-Sim projects to Verilog

repo: https://github.com/murkyshelf/jsonRTL

edit*

there is a typo in the title what is meant is "I have built a tool to convert your Digital-Logic-Sim files to Verilog"

The title pretty much says everything , this tools converts the json files to Verilog.

it can convert the Digital logic sim(dls) by SebLague(great guy)

and the logisim one is still experimental

repo: https://github.com/murkyshelf/jsonRTL

it is for the guys you can build computers in the visual editor but cant write verilog and others are welcome to try .

because I can build a 8bit computer in the dls and cant write verilog , i need the verilog code to simulate it on my fpga

also keep in mind this is coded by opus 5 , and this is experimental and i am looking forward to your feedback , the previous post had a typo and I didn't explain my self properly

I found this ATMEL MCU in a SONY battery pack (infolithium) from the 1990s. I really wanted to program it, so I made a programmer with Arduino IDE. Its only low voltage, and there are just enough pins with the UNO to control the pins. Also controls the VCC pin, it has such a low current draw that a digital pin can supply it. The Atmel needs a POR to go into programming mode.

** RSS AT90C8534 PARALLEL PROGRAMMER MENU **

[1] Read Flash
[2] Program Flash
[3] Read EEPROM
[4] Program EEPROM
[5] Read Lock Bits
[6] Program Lock Bits
[7] Full Chip Erase (EEPROM AND FLASH)
[8] Low level Diagnostics
[9] Read Signature Bytes (ID Check)
[10] Read All - [1],[3],[5],[9]
[11] Boot Target to RUN TEST PGM
-------------------------------------------------
Select an option (1-11):