Close
0%
0%

Isetta TTL computer

Retro computer built from TTL, with 6502 and Z80 instruction set. Includes video system.

Similar projects worth following
For this project I decided to adhere to a wellknown instruction set. I started with the 6502 but with very little extra hardware added it also executes Z80 instructions.
The video has 320 x 200 pixel graphics with several colors, and a 80-column colored text mode. There is no microprocessor or microcontroller.

The idea for this design was born at the end of januari (2023). 

While many homebuilt CPU's have their own, unique instruction set, I decided that for this project the CPU would use an existing instruction set. Also, I wanted to build the computer from parts of the TTL family. That are integrated circuits, that can perform elementary logic functions. They were first used in the 60's of the previous age. I use a modern version of these circuits, that use less power.

So which instruction set to use ? The CPU inside your laptop or cellphone is much, much too complex to build. But it is possible to use an older CPU from the time when microprocessors just became available. There were two processors that can be regarded as the Beetle and the Deux Cheveaux of the beginning of the homecomputer age.

Those processors are the MOS Technology 6502 and the Zilog Z80

The 6502 is famous because it was the heart of the Apple 1, the Apple ] [, the Commodore 64, the Nintendo NES and many others. The Z80 is well known because it was used in the TRS-80 and the ZX Spectrum.

So now, I had to decide whether to use the instruction set of the 6502 or that of the Z80. But then I thought... why not build a CPU that can do both ?

I did spend a few months searching for a good design that would give good performance while not using too many parts. I think the basic design is stable now (end of march 2023). I can now start with the details of the design.

BUILD A COMPUTER

A CPU is a nice thing, but on it's own it does nothing. It needs memory, power, and input and output devices. So I planned to build a full computer. Here are the specifications:

Specifications:
 - runs 6502 programs
 - runs Z80 / 8080 programs
 - processor speed 12.5 MHz
 - 512 kByte RAM ( 8 bit wide )
 - 24 bits wide microcode in 3 flash chips 
 - programmable (upgradable) microcode
 - On-board SSD 32 Mbyte
 - video VGA 320 x 200 pixels, 64 colors
 - video VGA 640 x 480 pixels, 64 colors
 - PS/2 keyboard connection
 - Connection for ESP-01S WiFi card
 - Connection for SPI device (micro SD card)
 - real-time clock synchronized by WiFi
 - sound generator
 - blinkenlights (4)
 - general purpose I/O
 - pcb 119 x 150 mm  (4.7 x 5.9 inch), 4 layers.
 - powered by 5 volt USB input

 Components:
 - RAM memory chip
 - Three Flash memory chips
 - SPI Flash memory chip for mass storage
 - 46 TTL logic chips (38 CPU, 8 Video and I/O)

 Principles for the design:

 - No microprocessor, microcontroller, SOC, FPGA, CPLD, GAL, PAL or 74181
 - All components have good availability at the big distributors
 - Low number of components
 - No fine-pitch devices that are difficult to solder

TECHNICAL DESCRIPTION

Here comes the system diagram of the CPU. Most arrows and buses represent 8 wires, that means that the information flows through the processor in units of 8 bits (a Byte).

I might as well start with explaining some of the parts.

  • PCH/PCL (program counter high byte and low byte)
  • A (Accumulator)
  • T (Temporary register)
  • DPH/DPL (Data pointer high byte and low byte)
  • IR (Instruction register)
  • CGH Constant generator, generates only 0 (mainly for zpage addressing)
  • CGL Constant generator for small integer values
  • MBANK Bank selection system

You will miss the 6502 registers S (stack pointer) and the index registers X and Y. And you will miss the long list of registers that are inside a Z80 CPU. Those registers are in memory. A special memory section (outside the normal 64K range) is used for the registers.

The control section will use microcode to run the whole show. The microcode has 16 pages, 1 page is needed for the 6502 and 5 will be needed for the Z80, and the software can switch between 6502 and Z80.

PERFORMANCE

The clock frequency of the processor will be at least 6.25 MHz (1/4 of the VGA...

Read more »

Isetta 20231204.pdf

Not fully up-to-date

Adobe Portable Document Format - 3.16 MB - 12/04/2023 at 19:42

Preview
Download

generated microcode 230725.txt

Current microcode for 6502 and Z80

plain - 256.34 kB - 07/25/2023 at 20:36

Download

Isetta 20230610.pdf

First version of schematic.

Adobe Portable Document Format - 2.17 MB - 06/11/2023 at 13:31

Preview
Download

microcode 230421_new.txt

First version of 6502 microcode generator.

plain - 39.04 kB - 04/21/2023 at 20:55

Download

  • PCB and parts arrived !

    roelh03/11/2024 at 14:16 0 comments

    I received the PCB's ! These PCB's were sponsored by the kind people of PCBWAY. As always, they are of a very good quality.

    And I also received a big bag of parts:

    Warm up the soldering iron !

  • PCB finished, Logisim simulation, and programmer

    roelh02/22/2024 at 20:25 0 comments

    LOGISIM simulator

    The design was only tested on the logical level, in the Javascript simulator. Before making a PCB I wanted some form of confirmation more on the hardware level, so I entered the design in the good old Logisim.

    Nowadays there is a further developed version, called Logisim Evolution. I tried it by loading one of my old designs in it. It became a big mess with long hex-sequences appended to my net names, and many shapes not displaying correctly. And indeed, Evolution is no longer compatible with the old file format. That's a pity, because I had quite a lot TTL devices converted to Logisim circuits.

    So I stayed with the old version, 2.7.1, so I could use my library of TTL components. And I found a few mistakes in my design. Also found a way to save a chip on the generation of the horizontal sync pulse.

    But it is slow. At it's top speed (Logisim says it is 4100 cycles/sec), when you type a short line of Apple Basic, you have to wait one minute before the prompt reappears !

    PCB Finished

    I finished PCB design. Here is the nice 3D preview of KiCad:

    It is 119 x 150 mm  (4.7 x 5.9 inch), 4 layers.

    Microcode Programmer

    I also needed a programming interface. Previous projects used the Raspberry Pi for that. The Pi has enough GPIO pins to accommodate the 8 or 16 bit wide Flash memories of those projects. The interface was not much more than a small universal board, with resistors for 5-to-3.3 volt conversion. 

    But in the Isetta the microcode flash memory is 24 bits wide. That is almost all I/O that the Pi has, not leaving enough for control signals. So now I use 8 bits I/O from the Pi. The data going to Isetta is first transferred to three HCT574-type registers (the HCT will also translate 3.3V to 5V), and then it can be transferred as one 24 bit value to Isetta. For data going to the Pi, there are three LVC244 chips to convert 5V to 3.3V. Only one of the LC244 is enabled to transfer its value to the Pi. There are two more LVC244, one for the databus and one for control signals from Isetta to the Pi.

    The new RPi programmer is only required to program the microcode. The program for the 6502 or Z80 can reside in RAM, and can be programmed in BASIC or any other convenient language.

    The Raspberry Pi has the following control outputs to Isetta:

    • Disable the data output of the 3 Flash chips
    • Give a programming pulse to the 3 Flash chips
    • Take control of the Isetta CPU clock signal
    • When it has control, send a clock to the Isetta CPU (to single-step it).

    The RPi also has a few serial lines to/from Isetta, intended for character read/write so you can use the RPi as a terminal as long as Isetta has its video and keyboard interface not yet working.

    Here is how it looks. Isetta connects to the left side, and the RPi to the right side. It also has LED's for the 24 microcode signals (with explanation on the pcb), and LED's for the databus and the instruction register. The LED's will also work if the RPi is not connected. It is a 2-layer board.

  • PCB design progress

    roelh02/14/2024 at 14:22 0 comments

    Here is the current state of the design, it's almost finished. The Flash chips had to change from DIL to PLCC, because the required 55nS speed is not available in DIL.

  • Re-started PCB design, in SMD

    roelh01/28/2024 at 09:20 0 comments

    Since I last worked on the PCB design, there have been many changes.

    And after looking at the availability of the chips, I found that several of them were not in stock (in DIL version). And since the design has become faster, it is not as easy any more to switch between the TTL logic families, because for many chips, the speed is critical.

    This made me decide to switch to SMD devices. Only the microcode flash chips will stay in DIL, so they can be easily taken out to program them (although there will be a system to program them while they stay on the board).

    Here is a preview of the new design:

    Dimensions are 12 x 15 cm ( 4.7 x 5.9 inch). It will be a 4-layer board. It is designed to fit in a Hammond RM2055S enclosure.

  • Less parts and higher speed

    roelh12/04/2023 at 20:36 0 comments

    It's been a while since I wrote a log. In this log I will tell you what happened to the design in the past months.

    BYPASS

    The design has a few buffers that implement the "bypass". This can place the address registers on the databus, so we can inc/dec them, or store them to T and then to memory. This is also the path to store the program counter (pch/pcl) for a CALL instruction. And it is used to add the offset to the PC in case of a branch.

    As always, I was looking for components to remove, to get a low-component-count design. And indeed, we can do without the buffer for the low address bus ! We can simply put a 1-to-1 table in a zero page of memory, and an access to this table will give us the register value on the databus. The high address bus must be 0 to access this table, that it is already an existing function.

    We have 8 memory banks, so there is a maximum of 8 zero pages, enough space in zero page. One of the zero pages already has a table for right-shift.

    For the high byte, this is less useful, since the table would be scattered through memory, occupying one byte in every page. That is not a good idea. 

    But...  the only register that we need from the high bus is PCH. And the PCL bus is not loaded from the result bus, but from the DPH register (in this picture, that is. It was later changed to come from the T register).

    If we modify it, and load the PCL register from the PCH register, we can access the PCH contents by loading it into PCL first ! In fact, when we write a new value to PCH we will at the same time (with the same signal) write the old PCH contents to PCL.

    For doing a jump, first write the LSB to PCH, and then write the MSB to PCH (that will move the LSB from PCH to PCL). And for a CALL, first save the PCL address through the 1-to-1 table, via the ALU, to T. T is then stored to the stack. After the LSB of the subroutine address has been written to PCH, the old PCH is in PCL and can now also be saved to stack. 

    The control signal for the bypass is obviously no longer needed. Used it later to double the amount of RAM-based registers.

    The 1-to-1 table in RAM is built by microcode, directly after reset, in the same loop that fills the right-shift table.

    Changes for this were done in the simulator and the microcode generator.

    SPEED

    In october I did some timing calculations, using the typical values for 74AC logic. (These typical values are only in Fairchild datasheets, not in the Texas Instruments datasheets).

    I was a bit surprised to see, that with some measures, the clock speed could be doubled to 12.5 MHz !

    We would need a 10nS RAM. Circuits in the address bus needed a few changes to make it faster. One of the address signals (for the CGL register) came from a 74HC238 1-to-8 decoder that had a quite big delay. It was used to extend the number of memory-based registers. This way of extending the number of registers was dropped (replaced by a directly available microcode control bit). This HC238 also delivered a signal to select SUB and a signal to select  DEC in the ALU. This could be changed to a single signal for both SUB and DEC. Other functions in the HC238 could also be solved in a different way. The HC238 could be removed.

    The circuits for the flags had to change, in the design the CY-out of the adder sometimes had to pass four devices before a flag result could be clocked-in in its register. The flag system was changed such that the adder-cy-out is used at only a few places. The condition-selector can choose it, and in a group-1 instruction it can be put into the C flag. The adder-cy-out now only has to pass 2 devices. The last of these is a 74HC4053 analog switch, that is slow in switching to the other channel, but relatively fast to pass a signal. Since the switch channel can be setup at the start of the cycle, it is expected to be fast enough.

    The adder-cy-out signal is called TC (temporary carry) in the microcode. For group 1 instructions,...

    Read more »

  • Colors

    roelh08/24/2023 at 18:34 1 comment

    This computer will have 64 colors (2bits red, 2 bits green, 2 bits blue).

    I was curious what the colors would look like, so I made a kind of three-dimensional plot with dimensions red, green and blue. It became a cube, built from 64 small bricks. If we look at the cube with the black brick pointing to us, we see this:

    So, starting from the black brick going to the right, we see increase in the red component. To the left, we see increase in blue component, and from black going down we see increase in green component. At the circumference we see the bright rainbow colors, and the remaining colors are darker versions of the colors.

    At the opposite side of the cube (unvisible in the above picture), we have a point where the amount of all primary colors is maximal. That is the color white. If we look at the other side of the cube we see this:

    At the circumference we see the same bright rainbow colors again. The remaining bricks are the lighter versions of the rainbow colors.

    But we did not see everything ! At the inside of the cube, there are 8 bricks that we didn't see yet. These are light-grey, dark-grey, and a grayish version of the primary colors:

    So here we see the eight hidden bricks, shown from both sides.

    The following table shows these colors, numbered from 0 to 63, and also with their hexadecimal web color. The first column has the grayish colors, and black, white and the two greys are at the bottom:

    So this table will be a help if I ever come so far to program colored stuff for my contraption.

  • Video system

    roelh08/22/2023 at 18:51 0 comments

    The Isetta video system will now be described.

    GENERAL

    The generated signal is a VGA signal with a maximum resolution of 640 x 480 pixels.

    The timing is: 
      25.175 master clock
      approx. 40nS per pixel (for 640 pixels/line)
      approx. 32uS scanline
    A whole scanline has a width of 800 pixels (only 640 pixels used)
    A whole frame has a height of 525 scanlines (480 scanlines used).
    Exact values can be found here.

    The isetta can work with maximum or reduced horizontal resolutions:

    • 40nS per pixel (for 640 pixels per line)
    • 80nS per pixel (for 320 pixels per line)
    • 160nS per pixel (for 160 pixels per line)

    In the vertical direction, scanlines can be repeated (to keep the pixels almost square, also when a lower horizontal resolution is used), giving:

    •  480 lines, or 
    • 240 lines (480 divided by 2), or
    • 120 lines (480 divided by 4)

    There are 64 colors (but the color can not be freely chosen for every pixel).

    HARDWARE PRINCIPLE

    The Isetta processor runs with a cycle of 160nS (6.25 MHz). The video output is directly generated by the processor, so during every instruction, one or more pixels must be generated:

    • 1 pixel/instruction (for 160 pixels per line)
    • 2 pixels/instruction (for 320 pixels per line)
    • 4 pixels/instruction (for 680 pixels per line)

    Isetta contains a hardware timer that triggers an interrupt at the beginning of every scanline. At the beginning of the visual part of the screen, this interrupt transfers control to the microcode that has the video instructions to give screen output. It can also initiate the generation of the frame sync pulse (the line sync pulse is generated by the hardware timer). If the interrupt is outside the visible area, the interrupt code will only increment the line counter, and return to the interrupted program almost immediately.

    A video instruction will get a single byte from the RAM, and gets color information, pixel information, and sometimes control information (flags) from that byte.

    The microinstruction fetches this byte from the indicated RAM location.
    The RAM is normally addressed with the (PC++) mode (Of course this requires that the PC that was used in the Z80 or 6502 program was saved when the interrupt is entered).

    The color information is 6 bits. The instruction can store the color in register T (foreground color) or in register A (background color).

    Information about a pixel is only 1 bit. If that bit is 1, the color of the pixel comes from register A. If the bit is 0, the color comes from register T.

    We now come to the basic byte formats that are used for the video system.

    • Color definition:

    Byte format: -cccccc-

    The 6 color bits 'cccccc' can be transferred to the T (Foreground, FG) or A (Background, BG) register.

    • 320 pixels/line :

    Byte format: a------b

    Two pixel bits 'ab' select the two pixels to be used in 320 pixels/line mode. These pixels are placed in the 4-bit 'pixel register' as 'bbaa'. The pixel register is loaded at every instruction, so the information is only available in the next cycle.

    • 160 pixels/line :

    This format is the same as the 320 pixels/line format, but in this case the bits a and b simply have the same value.

    • 640 pixels/line :

    Byte format for 4 pixels: --pppp-- 
    Four pixel bits 'pppp' select four pixels to be used in the 640 pixels/line mode. These pixels are transferred to the DPH register, and the output of this register is connected to a multiplexer that selects the correct pixel to be displayed. The 'pppp' bits are in bit5, bit4, bit3 and bit2 of the byte. The pixel register is connected to other inputs of the same multiplexer.

    Byte format for 2 pixels:  ab-----1

    This 2-pixel byte must be loaded with a SHL (shift left) instruction, while shifting a '1' into bit0. That will put the bits in the 4-bit pixel register as '11ab'. The '11' section defines background color (in register A).

    • Select pixel register or DPH register:

    One of the bits in the microinstruction ( ctl_reg1...

    Read more »

  • Started KiCad layout

    roelh08/06/2023 at 10:49 2 comments

    This is the first project where I use KiCad (version 7.0.2).

    Schematic entry was quite smooth, but with the pcb layout I experienced some problems. It was difficult to arrange the components on a 0.1" grid. And since I do everything on a 0.1" or 0.05" grid, it is annoying that KiCad displays things like cursor position only in millimeters. [ Edit. You can set this to inches, see comments ].

    Routing is not very difficult, but I miss certain functions. But it is possible that I do not yet know all commands for routing.

    But don't get me wrong, I think the KiCad developers did a great job !

    Here is the current state (you can click on the picture to get more detail) :

    The lower part of the pcb is routed. For the rats nest I use several colors:

    • red, VCC
    • blue, GND
    • light blue, databus
    • green, address bus, micro-address bus, internal ALU signals
    • magenta, microcode bus
    • yellow, operand bus
    • orange, result bus
    • white, several control signals

    This is far from finished, especially I/O components must still be added.

  • Update

    roelh07/21/2023 at 21:15 2 comments

    In the past months i've been working on the hardware design and the microcode.

    The number of required IC's got too high in my opinion, so some hardware was removed, every removal costing some effort to implement the removed instruction in microcode. I removed the following items:

    • The 74ac151 that calculated the V flag. Now, the two bit-7 adder inputs and the bit-7 adder output, needed to calculate the V flag, are connected to an input port (that has some unused inputs), and the value is saved after every addition/subtraction (or 6502 BIT instruction). When the V flag is tested, it is first calculated (by using the 3 bits to compose an opcode, and executing that opcode).
    • The zero-calculation. This was composed of three 3-input NOR gates (74F27) and a 3-input AND gate (74ac11). The other gates in the 74ac11 could not be used somewhere else, so this saves 2 IC's. After a ALU operation, the result byte is now saved to a (memory-based) register called reg_z. When the Z flag is tested (for a BEQ or BNE instruction), an 0xFF value is added to this register (same as decrementing), and when a carry occurs, the value was non-zero. There also was a physical flag Z and a upd_z microcode bit that indicated that this flag had to be updated. Both are not needed any more, and the upd_z frees a microcode bit that will be used to double the amount of available (memory-resident) registers. But it costs one extra cycle at every instruction that updates the Z flag, and one extra cycle when the Z flag is tested.
    • The shift-right multiplexers (2 x 74hc157) were removed. Shift-right is now done with a table in RAM (outside normal 64K section). After reset, some microcode constructs this table.
    • There was a special 8-bit buffer to put a byte of microcode on the databus. It was intended for special microinstructions that could place this byte in RAM (at an auto-incrementing pc++ position). This would be convenient for moving boot-code to RAM directly after reset. But this can also be done without this buffer, costing one extra microinstruction per transferred byte, and some microcode to organize this.
    • It was intended that the video section would have it's own RAM, such that video can be generated while the cpu is doing it's own thing. This will now be an option (additional pcb, called 'performance option' ), and the on-board video is bit-banged by the cpu ( 'economy version' ). It saves around 8 or 9 IC's.

    Of course I've been thinking about the video generation. The on-board economy version will have a 6-bit color value in both the A and T register. A multiplexer will select which color is connected to the output. There can be a few video modes, and the video mode can be different for each line. The basic video modes are:

    • 160 pixels/line. In every 160nS cycle, the A register will be filled with a new 6-bit color, providing 160 pixels per line, of 64 colors each. (it is just a special case of the 320 pixel/line mode).
    • 320 pixels/line. In every 160nS cycle, the A register will get a new 6-bit color. The remaining two bits determine the color of the two 80nS pixels that will be displayed in this cycle. Each pixel is either the foreground color from the A register, or the background color from the T register.
    • 80 column text mode. In an 'odd' 160nS cycle, 7 bits will be read, 4 bits will be 40nS pixels in the odd cycle, and 3 bits are 40nS pixels in the next ('even') 160nS cycle. The 4th pixel in this next cycle will be background color (blank pixel between characters). Again, each pixel is either the foreground color from the A register, or the background color from the T register. Since only 7 bits of the byte are used, there is one spare bit that indicates that a new foreground and background color will be loaded in the next two 160nS cycles (while displaying a space character).

    During the verical blanking time, the cpu will be executing instructions. At the end of every line, it will get an interrupt, that counts the lines,...

    Read more »

  • Another interesting BASIC to test the 8080 instructions

    roelh05/23/2023 at 18:52 1 comment

    Since the Isetta supports instructions of the Z80 processor, it also supports the famous 8080 processor, because the Z80 has the 8080 instruction set as a basis. The 8080 is interesting because it is the grandfather of almost all INTEL CPU's for personal computers of the past 40 years.

    One of the very first personal computers was the Altair 8800 from the company MITS. It was built around the 8080 processor. Bill Gates, Paul Allen and Monte Davidoff created a BASIC interpreter for this computer, the Altair BASIC. It was called a 4KByte BASIC. But the actual program was smaller than 4K, because 4K was all memory that the Altair had ! There were only 790 bytes free for user programs ! Altair BASIC was the very first product of Microsoft !

    So I used this Altair BASIC to test the 8080 instructions on the Javascript emulator of the Isetta processor. I found an Annotated disassembly and a binary version. And I really needed the disassembly, to understand a little of the program.

    Subtract and compare

    After the first tests, I found that for the 8080/Z80, the carry flag behaviour for the subtract and compare instructions is inverted w.r.t. the behaviour in the 6502. I created a new microinstruction that complements the carry flag for the 8080/Z80. In several situations, it can be executed at the same time as another microinstruction.

    Parity flag

    Altair Basic has a FCompare at 0A4C that compares two floating point numbers. It returns
    one of the following values:

    • 0x00 for zero
    • 0x01 for greater than zero
    • 0xFF for less than zero

    That's very logical. Now you can simply test the sign flag or zero flag to jump according to the result.

    But in two instances, at 0B63 and 0C03, it is followed by a JP PO (jump on parity odd) instruction, that will jump if the result is greater than zero (as 0x01 is the only one of these three values that has an odd number of '1' bits in the byte)

    On the 8080, (almost ?) all arithmetic and logic instructions that act on the accumulator will 
    set the P flag according to the parity.

    But on the Z80, the parity flag behaviour is different. Logic instructions will set the flag according to the parity, but the arithmetic instructions will set the flag when there is an overflow. And indeed, it has been reported on the Internet that the Altair Basic will not work on a replica Altair that has a Z80 processor instead of the 8080 in the original Altair.

    So, although it is widely believed that the Z80 can run all programs intended for the 8080, this is not true because the behaviour of the P/V flag is different.

    And on the Isetta it is also a problem because parity is not implemented at all.

    The parity flag is tested with JP PO on only two occasions, at 0B66 and 0C04. Both instances are preceded by a call to FCompare at 0A4C. I replaced the calls to FCompare by a new subroutine, that does the following:

    • Call the FCompare function at 0AC4
    • Return if result is non-zero
    • Save Accumulator
    • Load Accumulator with 0xFF, and OR A to set the sign flag
    • Restore Accumulator and return

    Both JP PO instructions are now replaced by JP P (jump if positive). The parity flag is not needed any more (at least not for this BASIC).

    A nasty bug

    Strange thing were going on. The display of numbers displayed the first digit as a letter. And with another test program (TRS-80 Basic), identifiers were not recognized. After a few days, I found out that the carry flag was not cleared after an XOR A,A instruction. The microcode seemed ok, it said the carry was written (and at the same time a load operation was done). But for the carry-complement (for subtract and compare) I changed the behaviour such that writing the carry while doing a load resulted in a complement-carry ! Sometimes it is difficult to program your own contraptions.

    Other changes to the BASIC

    The code at the following positions was changed for character output and keyboard input:

    • The code...
    Read more »

View all 17 project logs

Enjoy this project?

Share

Discussions

Con Cunningham wrote 04/21/2023 at 21:11 point

Just  been reading your square inch TTL CPU - great work. Did you publish your microcode, or is that proprietary ? Curious how you managed such a rich ISA with so few control signals!

  Are you sure? yes | no

roelh wrote 04/22/2023 at 18:08 point

Hi Con, the microcode can be seen when you scroll down on the simulator page: 

http://www.enscope.nl/simas_nac/

Did you read the logs ? If you also look at the schematic,  ( https://hackaday.io/project/161251-1-square-inch-ttl-cpu/log/154913-schematic-of-the-cpu ) you should be able to understand how it works.

  Are you sure? yes | no

Con Cunningham wrote 04/21/2023 at 20:51 point

I honestly don't know - perhaps when I get to wire-wrap some of it, and it starts to operate I might do so. Yes indeed, I use the 74181 as a 16 bit address incrementer, and of course, for all of the other 6502 arithmetic and logical ops.  Keep up the good work.

  Are you sure? yes | no

Con Cunningham wrote 04/20/2023 at 21:03 point

An ambitious project. I know this because I have been working on something similar (When work allows) for some months. I am on my 3rd iteration. This time I have based my design roughly on Tanenbaum's "Structured Computer Organisation" , see https://csc-knu.github.io/sys-prog/books/Andrew%20S.%20Tanenbaum%20-%20Structured%20Computer%20Organization.pdf

I am using 74LS TTL, and have opted to make life easy by using 4 x 74181 as a 16 but ALU. I hope to implement all of the 6502 ISA, with the exception of Decimal Mode.

Have you begun to use a simulator, such as Logisim or Digital yet?

I wish you the very best of luck with your project, keep the updates coming!

Con

  Are you sure? yes | no

roelh wrote 04/21/2023 at 20:03 point

Thanks Con !  I'm curious about your project. Will you publish it on Hackaday ? I suppose you will use the 4 x 74181 as address incrementer ? Yes I will soon start simulating.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates