Close
0%
0%

Isetta TTL computer

Retro computer built from TTL, with 6502 and Z80 instruction set. Includes video, sound and filesystem. No microprocessor or FPGA.

Similar projects worth following
For this project I decided to adhere to a well known instruction set. It can execute 6502 instructions and can on-the-fly switch to Z80 instructions and back.
The video has 320 x 200 pixel graphics with several colors, and a 80-column colored text mode. There is no microprocessor or microcontroller. It also has on-board file system and sound. The prototype is working and can also run ZX Spectrum games.

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 CPU 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 (80nS cycle time)
 - 512 kByte RAM ( 8 bit wide )
 - 24 bits wide microcode in 3 flash chips 
 - programmable (upgradable) microcode
 - On-board SSD file system 32 Mbyte
 - video VGA 320 x 200 pixels, 64 colors for each pixel
 - video VGA 640 x 480 pixels, 64 colors for each character FG/BG
 - 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

ISETTA SYSTEM DIAGRAM

PERFORMANCE FOR Z80 MODE

Many Z80 instructions take much less cycles on Isetta than on the real Z80. These are mostly quite simple instructions, but they are used a lot. Examples are:

When the above instructions are (equally) used, the amount of cycles decreases a factor 2.2 !  That means the effective speed would be 2.2 x 12.5 = 27.5 MHz !  Instructions involving (IX+d) or (IY+d) also take about half the amount of cycles compared to Z80. The improvement is mainly caused by the fact that Isetta can access memory in a single cycle, where the Z80 needs three cycles for most memory accesses.

But not all instructions show such an improvement. Most instructions that involve shifts, stack or 8-bit arithmetic and logic take about the same amount of cycles as the Zilog.

And there are a few that are dramatically slower than on the Z80: EX AF,AF' and EX DE,HL take almost 3 times as many cycles (but EXX takes 4 cycles, same as on Z80). Exact specifications of the number of clock cycles for each instruction can be...

Read more »

apple1.woz

Executable for Isetta. It switches from Z80 to 6502 instructions and runs the original Apple 1 BASIC.

woz - 9.66 kB - 07/11/2024 at 20:54

Download

microcode bin 240711A.txt

plain - 896.01 kB - 07/11/2024 at 20:13

Download

tge bin 240622A.txt

The Great Escape, Isetta executable for this ZX Spectrum game.

plain - 135.01 kB - 06/22/2024 at 07:11

Download

mm.z80

Manic Miner, original source code for this ZX Spectrum game.

z80 - 345.95 kB - 06/09/2024 at 09:47

Download

zx_video.z80

Assembly program for initializing the ZX Spectrum screen mode on Isetta.

z80 - 5.49 kB - 06/07/2024 at 19:40

Download

View all 21 files

  • Two Spectrum games working

    roelh06/27/2024 at 20:39 0 comments

    After a little while, I got the Manic Miner fully working, including sound:

    But in the video signal, there are two annoying stripes at the right side of the screen (also going through the score). This is related to a end-of-line flag that is tested there in the microcode that builds the screen. The exact reason is not known yet. [ edit: the reason was found, and the bug removed.]

    SOUND

    The sound took a little fiddling to get it to work properly. The ZX Spectrum has a very simple sound system, similar to that of the Apple II. It is a single bit of an output port (port 0xFE), that is amplified with a single transistor, and connected to a small speaker. The program has loops that toggle that bit with a certain timing.

    The Z80 of the Spectrum runs at 3.5 MHz. Isetta runs at 12.5 MHz. But Isetta spends around 73% of her time rendering the Spectrum screen, so her effective speed is about 3.375 MHz. A Spectrum program, generating a constant tone, would come out as a series of high-frequency 'chirps' during blanking time.

    The write to the 0xFE output port is handled by microcode. It now stores the value instead of writing it to the speaker. At every line interrupt, this value is put in a buffer (only during blanking time when the Z80 code runs, that is about 140 lines per frame ). But in every line interrupt (525 times per frame), a value is read from the buffer and written to the sound output. The same value is used four times, and then the buffer pointer is incremented. So the sound is stretched by a factor 4.

    It had another problem. The sound bit is normally zero, then it toggles during the tone, and then is zero again. This means that it has a low-frequency component. In the ZX with its tiny speaker this was probably no problem, but in my case I have a set of amplified PC-speakers (with 3.5 mm jack connector) that have a 'good' bass response. So the little 'music' tones were accompanied by loud plop sounds.

    The sound system of Isetta has 8-bit samples. I defined a level that was halfway the 0 and 1 of the speaker signal. So normally the signal was at 50%. When port 0xFE was written, the signal would be 0% or 100 %. But the point is, it is difficult to know when the tone stops, so you don't know when to go back to 50% . I did this as follows. At each interrupt, when the 0xEF port was not written, I bring the speaker signal a few steps closer to 50%. So when the tone stops, the signal will go to 50% quite soon. This gave a reasonable sound quality.

    KEYBOARD

    I already had Z80 code to convert the PS/2 keyboard to ASCII, and to convert ASCII to the codes for the ZX Spectrum keyboard matrix. But for playing a game, I also had to use the PS/2 'key released' messages, to tell the game program exactly when a key was released. 

    THE GREAT ESCAPE

    I tried another program. The Great Escape. This program also has a very good, commented disassembly

    In this program, a prisoner of war has to escape from a prisoners camp. It is totally different from the previous game.

    The display is a semi-3D rendering. It is almost a modern game, where a camera follows the hero on the terrain and in the several buildings.

    It did not take much time before I saw the first guards walking on the screen. But it was only a few second, then the program crashed. What could it be ? I looked through the source and I found it used an instruction that I had not implemented, because my thought had been, who is ever going to use that ??  RRD  Rotate Right Digit

    But the game uses it to shift the whole screen four pixels to the left or the right....

    So the RRD and RLD are now also in the microcode.

    Program worked. But I have no clue how to escape...

  • Trying to get a ZX Spectrum game running

    roelh06/14/2024 at 14:44 0 comments

    TEXT MODE

    In the last log I mentioned that there was video output.

    A 80-column text mode was created. Each character is in a 8 x 8 pixel matrix. To make it better readable, a few empty scanlines are between the textlines. The VGA pixels are generated by the microcode.

    At the moment this is mainly used as a text mode, although it is actually a graphic mode with 8 bytes of 8 pixels each. For each row of a 'character', there is also a color byte. The idea is that every character can have a different color (but since this is a graphic mode, each row of a character could have it's own color). The background color for a character can also change, but that's not fully implemented yet.

    The picture shows how the system starts in the current version. It shows a few big colored fields to show some of the colors. At the right side you see some random colors, where you can see that each character can have a different color for each row.

    You also see how the file directory shows up. A line that starts with "D" means that this is a directory.

    After I got this video mode working, I worked on the PS/2 keyboard input. The keyboard did only give a singe message after startup, always the same, and did not respond to key presses. After searching my keyboard on the internet, I found that some keyboards need a RESET message before they start working. In my case, I had to solder two transistors on the pcb to be able to transmit the reset message to the keyboard. But then it worked ! A Z80 program translates the scancodes to ASCII. 

    Isetta can now run with its own keyboard, video output and file system, without the need for the RPi !

    ZX Spectrum video system

    After I got that working, I spend some time making a video mode that behaves as ZX Spectrum graphics .

    To test this, I downloaded the source of the game Manic Miner. I could only get this to work if I also found the explanation of Manic Miner source code. Here is the first result:

    Obviously, not everything was working correctly yet. There were vertical lines at every character boundary, and apparently the attribute bytes of the lower part of the screen were not correct.

    It could be traced (within reasonable time) to a failing LDIR (load-increment-repeat) instruction. This is used in the game to copy big blocks of bytes to the screen, with a single instruction. The LDIR, that is implemented in microcode, was designed to check for an interrupt periodically, and in the case of interrupt set the program counter two steps back, and after the interrupt resume the copy operation. But it didn't work correctly with interrupts.

    The LDIR was a highly optimized piece of microcode. At ten cycles per transferred byte, it loaded the byte, stored it at the destination, incremented the HL source address (with carry between low and high byte), do the same for the DE destination address, decrement the BC byte counter, test if BC is zero. And also check the interrupt signal at every transferred byte.

    I took the fast way out. I grabbed a RST instruction (0x20) and did put a copy routine there. In the source of the Manic Miner, I replaced every LDIR with a RST 0x20. Followed by a NOP to leave addresses unchanged. Getting the bug out of the LDIR instruction was put on the TODO list. Now I got this:

    Already much better !

    I could also see on the piano keys that the start-up tune was playing (but of course I have no sound yet). Also, a scrolling message was visible. After that, the program crashed. More debugging to do !

  • Who is afraid of Red, Green and Blue ?

    roelh05/15/2024 at 20:17 0 comments

    A true milestone today !  Just half an hour ago...

    The picture shows my test setup, with a laptop, scope, Raspberry-Pi screen, and....

    FIRST VIDEO OUTPUT !

    It shows just a simple testpattern that I quickly made up. Colored bars and pixel patterns, and when I wrote it I had no idea how it would look. I did not bother to start the pixels at the correct distance from the sync pulse, so apparently I started much too soon since a the right-side, one-third of the screen is empty. (but I also just generated 60 characters instead of 80, to have simpler code).

    The picture gets its stability from the timer interrupt on Isetta. The picture stays fully stable if I give Isetta commands via the Raspberry Pi screen. On the Isetta, there is no need for forcing your code in certain blocks with exact equal amount of cycles as in some other designs. (but of course, the interrupt code that generates the picture must have exact timing).

    You can see on the picture that the video connector connects with wires to the pcb. That's because I used the wrong footprint for the 15 pin video connector. I had no idea that there were different types. The difference seems to be that one has a row distance of 2 mm and the other one a distance of 2.5 (or 2.54) mm.

    Soon there will be characters on the screen !

  • File system and command shell

    roelh05/14/2024 at 20:38 0 comments

    FILE SYSTEM

    Isetta has a 32MByte serial flash, and it is there because I want her to have a file system.

    While making this file system, I also make a simple command shell, at first just for testing the file system functions but it will grow to get every command that is needed.

    The serial flash is a W25Q256JV device. It has 8,192 erasable sectors of 4kByte each.

    It would be cool to have a little wear-leveling. That almost rules out a FAT system, where an allocation table is written to the same sector, each time as one of the files changes (unless you write it on a different position each time).

    What did I come up with ? The system has the following properties:
     - files (that consist of one or more sectors)
     - hierarchical directory structure
     - deleted or overwritten files stay available (but are normally not visible in the directory), until erased (after adjustable time).
     - supports hidden files

    FILE STRUCTURE

    The first sector of a file (or directory) has this structure:
    At 0x0000:
     - (byte) flags
     - (word) sector of the directory that it belongs to
     - (byte) lsb of the properties address
     - (byte) hash of the name
     - (byte sequence) name (zero-terminated), max ca 100 chars.
    At properties:
     - (word) number of the following sector
     - (word) reserved for more flags (unused yet)
     - (4 bytes) date (YYYYMMDD, so today is 20 24 05 14)
     - (4 bytes) time (HHMMSS00) (so it is zero-terminated).
     - (4 bytes) file size (little-endian)

    At 0x0100:
     - maximal 0x0F00 bytes of data 

    The first sector has a lot of space to define more properties. For the sectors that follow, only the flags and the number of the next following sector need to be present. For ease of programming, the data in these following sectors also start at 0x0100.

    The flags at address 0 are these ( they are active low ):
     - bit0  if 0, sector is ready to be written
     - bit1  if 0, sector is in use
     - bit2  if 0, sector belongs to a file (but is not first sector)
     - bit3  if 0, this is a directory
     - bit4  if 0, this file was deleted (but still available)
     - bit5  unused
     - bit6  unused
     - bit7  if 0, this file is hidden

    FLASH LAYOUT

    Where are the files placed in the flash and how do we find them back ?
    There are two rules:
      - The first sector of a file will be placed at a position that is based on  the directory that it belongs to, and on a hash function of it's name. If that position is occupied, it will start looking for an empty position in one of the following sectors.
      - The following sectors of a file can be placed anywhere, since they are all linked.

    There is only one fixed position, and that is the ROOT directory at sector 1.

    DIRECTORIES

    The flash is divided in 8 compartments. The files of a certain directory will all be stored in the same compartment. A simple hash function, applied to the sector number of the directory, tells with compartment it belongs to.

    FILES

    In every compartment there are 1024 sectors. A hash function, calculated from the first and last character of the file name, determines the preferred position of the first sector in the compartment. If the preferred position is already occupied, the first free sector that follows this preferred position will be used. 

    So, when the file name is known, it can be found very fast, because only the flags, directory, and name of a file have to be checked in each sector. In most cases it is not needed to check the full filename, because checking the hash is sufficient. In such cases only 5 bytes of the sector need to be read.

    When the file name is not known (when asking a directory) only a single compartment has to be searched for valid files. Only the flags and the directory sector have to be checked. This is also very fast, when you type a "ls" command you don't notice any delay.

    The bytes for date and time have the highest bit...

    Read more »

  • Moving Z80 binaries to Isetta and run them

    roelh05/07/2024 at 19:48 0 comments

    Next step is the loader program. It will be a Z80 program, running on Isetta, that uses the console char I/O, so now it is controlled from the RPi console but in the future it can be controlled from PS/2 and VGA.
    This loader program will be in the microcode ROMs, and some microcode will download the loader into the RAM soon after reset, and then start the Z80 loader.

    What must the loader do ?
     - download program files from RPi into the Isetta memory, through the 'keyboard interface'
     - start a program
     - inspect memory and change bytes in memory
     - read a file from serial flash (to automatically start software in the future)

    Need an assembler !

    I found a nice online Z80 assembler:  https://asm80.com
    Written by Martin Maly, Prague: https://hackaday.io/adent

    It can also assemble for the 6502, that can also be useful in my project.

    The assembler generates Intel format binary (.HEX), like this:  (spaces added)
    : 10 E000 00 31FEFFC325E04FD3317928FAC9DB3128 2F
    : 10 E010 00 FCC97EB7C8CD06E02318F7CD0DE077FE 2A
    .....
    : 10 E0E0 00 20202020202020202F72756E20617420 97
    : 10 E0F0 00 68686868000D4973657474612070726F 98
    : 0E E100 00 6772616D206C6F61646572002A00     A9
    : 00 0000 01 FF

    So the structure is: <:><nr-of-bytes><address><record-type><byte-sequence><checksum>
    See: https://en.wikipedia.org/wiki/Intel_HEX

    The Javascript microcode generator has now the ability to read this intel hex format, in order to include the loader/monitor in the microcode.
    Another change to the Javascript simulator was giving it char I/O according to new KB, TX standard.

    Now came File transfer from RPi to Isetta, to load the Isetta memory with a Intel Hex file. In the Isetta loader you have to type a "Load File from Host" command, "F" followed by filename. Isetta then sends %Dfilename%  (D is the command: download). So '%' is used to introduce the file name and start the download. For just sending a plain '%' to be displayed, it must be doubled to "%%".

    The data has to travel over the link to Isetta, and that is not very fast. So I did a simple change, replacing every two hex digits by a single byte. In this new format, it uses '=' instead of ':' at the beginning of a line.

    RPi will now send the file.  Since the values 00 and FF can not be transported over the link, they are escaped with '['. And because values 00 and FF can occur quite often in machine language, all bytes are first XOR'ed with 0x40, so:
    Sending from RPi:
      - xor with 0x40
      - if 00 replace by <[><A>, if FF replace by <[><B>, if [ replace by <[><[>
      (send it)
    Receiving at Isetta:
      - if [, get another byte, if A then -> 00, if B then -> FF, if [ then -> [ 
      - xor with 0x40
    This transformation does not apply to the '=' at the start of the line. and to the 0x0D at the end.

    The record type, 0 for a normal record and 1 for the end, has many unused values, so that can later on indicate if the bytes must be loaded into another memory bank. TBD. 
    And the recordtype could be used to store target cpu 6502/z80/... (but it is more practical to define that every program is a Z80 program. A program for 6502 should simply start with an instruction that switches to 6502). Recordtype 0x99 indicates 'file not found'.

    During transfer, Isetta transmits readable progress messages on the console: at every 128 transferred bytes it displays the current address. It can also terminate the transfer with a special %X sequence (in case of error).

    So, now it is possible to assemble Z80 programs online, send the binary to Isetta, and execute it there !

  • The real hardware runs Apple 1 Basic !

    roelh04/19/2024 at 19:07 0 comments

    A major milestone was reached today ! The original Apple 1 BASIC, programmed by WOZ, is running on the real Isetta hardware ! It runs on the intended 12.5 MHz (80nS cycle time).

    For character I/O, there is a synchronous serial link with a Raspberry Pi. The screen and the keyboard of the Raspberry Pi are used to communicate with Isetta.

    Here you see a screenshot of the RPi screen.  After the ">>" (generated by the RPi) the RPi reads a full input line, echoing it on the screen. Then, after a CR (return), the line of characters is sent to Isetta Apple Basic, and Basic again echoes the characters to the screen. Then the output of the Basic interpreter follows, and the Basic prompt ">". Note that there is an "*** END ERR" because there is no END statement at the end of the program.

    PROGRAMMER

    Quite some work had to be done after the prototype was soldered. I had to make a Python program on the Raspberry Pi to program the microcode into the three microcode flash chips. On the programmer board  (described in the previous log) a small change was needed. This Python software can also execute arbitrary microcode on Isetta, and run a test program that tests hardware functions.

    The programmer can grab the clock of Isetta, by putting the first 74AC163 clock divider into LOAD mode, and providing a new clock (SW generated by RPi) to the first two preset inputs of the 163. The transistor that transferred this clock was, unsurprisingly, not fast while switching OFF, and I suspected that was the reason that I sometimes got a bad working instruction during singlestepping. This transistor also did the 3.3V to 5V translation. I replaced it by a simple diode with a 1N5 cap in parallel. It's a poor man's level converter. At the high RPi 3V3 level, 0.7 V is added by the diode so the ac163 sees around 4V on its input. That worked, errors now occurred rarely, and could be handled by a retry mechanism in the programmer.

    How does the application program (the 4K Basic interpreter) get into the main RAM ? I could modify the programmer such that it writes to RAM instead of microcode flash. But I already had a mechanism in place that would also work with a fully stand-alone power-on and reset. A certain part of the microcode copies the BASIC interpreter program from the microcode flash to the main RAM, soon after reset.

    COMMUNICATION

    Next thing was communication (characters in, characters out) between RPi and Isetta. It should also work when Isetta  generates VGA output, so we are handling a single bit directly after the horizontal interrupt. (That is generated by a simple hardware timer).
    The bit handling should always take exactly the same amount of cycles, independent of the data send or received, otherwise there will be jitter in the generated VGA output.

    When the VGA output and keyboard are working, we still need this interface to the RPi to transfer files to or from Isetta. We could also use the RPi screen as debugging output while an application runs on the VGA screen.

    Since it should also be possible that a PS/2 keyboard is connected to Isetta, the choice was made to use the same receiver hardware and software for the keyboard as well as for data coming from the Raspberry Pi. Since it uses open collector outputs, both clock and data signals can simply be tied together. This combination was not foreseen when the PCB's were designed, so a few wires had to be added.

    Communication RX receive driver

    The keyboard has two lines, KB_CLK and KB_DATA. Both lines are driven by a open collector output on a standard PS/2 keyboard (pullup resistors in Isetta). If no information is sent, both lines are high. The keyboard receive driver will be able to receive scancodes that are sent by the keyboard. It has the following states:

    • Wait for startbit. If the clock line has a falling edge, and the KB_DATA line is low, the startbit is valid and we proceed to the next state. If the data line is high...
    Read more »

  • 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 once, 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.

View all 23 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