A2Z Computer

A computer invented, designed and built from scratch.

Similar projects worth following
A2Z Computer is a computer made by myself from A to Z.
It is a didactic project. The goal is to work on every part of a computer : hardware and software.
The hardware is based on a small FPGA, with a custom 16bits CPU core inside and some peripherals.
The software is coded in a custom language : A2Z_Basic, with a homemade cross-compiler.
All source code is provided in this page. Everything is OPEN SOURCE.
There is an emulator available, so that you can discover this computer.
Contact e-mail : f4hdk [at]

Every part of this project is invented, designed, and coded by myself. I have not copied any line of code from another project.


FPGA Altera Cyclone 4 EP4CE6


  • Von Neumann architecture
  • 16 bits RISC (no microcode)
  • No interrupt management
  • ALU : integers 16bits
  • Data bus : 16bits
  • Address bus : 24 bits
  • Cache : 128 x 16bits
  • Performances close to 80286


  • 2MB SRAM (accessible by 8 or 16bits)
  • 2kB boot ROM (inside FPGA)
  • PS/2 interface for keyboard
  • SPI interface for 16MB Flash SPI (mass storage)
  • Serial interface emulated via bit-banging on GPIO

VGA video card (inside FPGA):

  • graphic part : 640 x 480 x 8bits.
  • Shared RAM with the core
  • double buffering (for fluid animations)
  • text overlaid: 80 col x 30 lines

What I have done:

  • Custom CPU, with it's own instruction set. The CPU is coded in Verilog.
  • Some peripheral listed above, all programmed in Verilog.
  • Custom assembler, coded in C, with it's own assembly language
  • Cross-compiler fully coded by myself, in C. This compiler takes A2Z_Basic language for input, a custom language, which is a mix of C and Basic. The compiler is the most difficult part of this project.
  • A simple filesystem, without fragmentation management
  • A simple OS : a file explorer capable of managing files and folders
  • Some programs : a text editor, an image viewer, a map viewer, and a car game
  • An emulator, that runs on PC. With this emulator, you can work on this project without hardware

All details are in the Blog, one entry for each chapter.

Table of Contents:

1) General description

1.1) Principle of the project

1.2) Personnal vision of the project

2) Hardware

2.1) The development board

2.2) FPGA-Verilog: global overview

2.3) FPGA-Verilog: the core

2.4) FPGA-Verilog: VGA video card

2.5) FPGA-Verilog: other peripherals

3) Custom software development tools:

3.1) Global organisation

3.2) A2Z Basic language

3.3) A2Z Basic compiler

3.4) Assembler

3.5) Other tool

3.6) Emulator on PC

4) A2Z software

4.1) The bootloader

4.2) File System and Operating System

4.3) Text editor

4.4) Image viewer and Map Viewer

4.5) The game : Micromachines

Description en Français

Content : sources and executables. Documentation; FPGA verilog sources; windows soft dev tools; A2Z application sources; emulator with usable flash content

Zip Archive - 9.13 MB - 01/29/2017 at 13:34


View file

  • 4.5) The game : Micromachines

    f4hdk01/07/2017 at 10:35 0 comments

    This is a car game, with a view from above, like the old “MicroMachines”.

    This application is the most fun. It uses the graphic capabilities of A2Z, especially the double buffering.


    • Right and Left arrow : direction
    • A : accelerator / Q : brake and reverse gear
    • F12 : exit

    Unfortunately, because of the slow speed of the CPU( 12.5MHz), the viewing window is only 320x240 pixels.

    The field is created with a concept of “tiles”. Graphic tiles and obstacles tiles are not the same size: graphic tiles are 128x128 pixels, and obstacle tiles are 64x64 pixels. And the whole field (circuit) is made with tile matrix, which are 2D tables : 40x40 for graphics, and 80x80 for obstacles.

    Obstacles Matrix on paper:

    Obstacles tiles coding:

    I have coded a program on my PC, in C language, that generates all the data needed to the game : graphics, and tiles matrix. The 2 tiles matrix are extracted from 2 .csv files, and the graphics are extracted from a single bmp file.

    The process of creating a circuit is quite long; therefore, I only took time to create one circuit.

    I found that collision management was difficult to code. I use the 4 corners of the vehicle. For each corner, the collision detection determines to which obstacle tile it belongs, and then check if it collides with an obstacle of the tile or not.

    I am happy with this result. It is the final result of the A2Z project, and the last thing that I have developed.

  • 4.4) Image viewer and Map viewer

    f4hdk11/18/2016 at 19:24 0 comments

    The 2 applications manipulate images.

    F12 : Exit for both applications.

    Image viewer:

    This is a very simple application. It displays image on the screen with its filename. You can browse all the images inside the folder where the first image was opened, with the left and right arrows.

    Transitions between images are made with the double buffering.

    Map Viewer:

    It is a little bit more complex. We display a 7MB “raster map file” (bitmap format). This map is stored with 256 x 256 pixels tiles.

    For each update of the display, the software determines which tiles have to be displayed for the current X-Y position. Then it draws the tiles already stored in RAM to the hidden frame buffer; then it switches the frame buffer; finally it loads the tiles that are missing from Flash to the RAM and displays them to the displayed frame buffer.

  • 4.3) Text editor

    f4hdk11/18/2016 at 19:23 0 comments

    The text editor allows vertical scrolling, lines counter, automatic line return without word split.

    I had planned to code copy/cut/paste functions, but I never get enough motivation to do it.

    The data of one text file cannot exceed 50kB (which is enough), because I manipulate it as a table inside the RAM range dedicated to variables (64kB maxi).

    The editor cannot create, delete, or rename a file. It cannot modify the FAT. All the modifications have to be made on the file explorer before or after editing the content of the text file.

    Function keys :

    • F10 : save the current file
    • F12 : exit

    This is the first software that I have coded. I needed to develop the keyboard interface (interpretation of key codes). I found this part more difficult that I thought.

  • 4.2) File system and OS

    f4hdk11/18/2016 at 19:23 0 comments

    File system:

    The file system is very simple. It is based on a FAT (file allocation table). Each file entry (file or folder) contains the following information:

    The index of a FAT entry is its position on the FAT table. I limit the file number to 1024, which is enough for 16MB, and the demonstrations.

    The filesystem enables a tree structure, of course, with the help of the “folder field” of each FAT entry.

    The FAT is the portion of the Flash that is re-written the most. Each modification of the file system leads to a FAT modification. I wanted to avoid re-writing always the same Flash blocs, therefore I implemented a mechanism that writes the FAT in 8 different places, written successively at each FAT update. A FAT index is used to find the freshest FAT out of the 8 FAT stored.

    It is a bit useless because the usage of this computer is very small, but I coded that especially for fun.

    The FAT is small (less than 64kB) and it is therefore always stored in RAM.


    • The filesystem do not manage fragmentation of files. Files are stored in a row. If there is not enough contiguous free space, a new file cannot be created.
    • Each file has a fixed size, declared once at the file creation. The file size cannot be modified later.

    Flash Memory organization:

    Human – Machine Interface : the file explorer.

    I didn’t want a “command line” HMI. I hate command line OS, since my young age, when I used MS/DOS.

    Therefore, I have coded a simple file explorer, with pseudo graphic interface, that shows the content of a folder, allows the user to select one file/folder with arrows, and propose actions to the user depending on the type of file/folder selected. This looks like the old “Norton Commander” on MS/DOS.

    All the basic commands of a file explorer are available : copy, cut, paste, rename, create a new file or folder, delete.

    You can also open a file. The action made while opening a file depends on the file type:

    • For an EXEC file, the program is loaded to RAM, and then executed
    • For TEXT or IMAG files, the explorer loads the right program for the file type, and executes it. The program will then open the selected file by itself; the OS just passes the index of the selected file as an argument. The EXEC files corresponding to programs used to open these types of files must have specific file indexes:
      • Text editor : index 2
      • Image viewer : index 3

    In the “action menu”, a specific action allows to update the content of the selected file, from the PC to the Flash. This is made in 2 manners:

    • Choice 1 for real A2Z hardware, uses the serial link, with the same protocol than the bootloader. All download must end with a “goto” instruction, that will not be executed, but that is just present to detect the end of transfer. For example, you can download a “bina” file, and then the file “goto.bine”.
    • Choice 2 On emulator : you can download a bina/bine/binc file. The transfer is initiated with an F9 command. The transfer of the file must be done before validating the selection of “choice 2” in the OS.

    OS or not OS ?

    Finally, what I call “OS” is not really an OS. It is just a file explorer. All applications are almost totally independent from the OS, and they integrate their own driver to access to the hardware. There is no hardware abstraction made by the OS.

  • 4.1) The Boot

    f4hdk11/18/2016 at 19:22 0 comments

    The bootloader is put in the boot ROM inside the FPGA. It is small enough for the 2kB of this ROM. The boot code is directly executed from this ROM.

    At the start of the boot, the user has 2 options:

    • F1 : loading a content from serial link to the RAM, and execute it. It is used when developing programs that have just been compiled on the PC. And this was also the only way to execute programs when I had not coded the OS, the filesystem, and the Flash drivers.
    • F2: loading the OS from Flash and execute it. This is the normal way to start the computer for a “user”. The OS is a 64kB executable file, put in a specific portion of the Flash.

    The serial port must be configured at 57600bds, without handshake/flow-control, and if possible 2 stop bits instead of 1. Warning : files must been sent in raw format, not ASCII format. Under Windows, I use the TeraTerm soft.

    Remark : the bootloader is not simulated inside the emulator, because I didn’t want to emulate the serial port. Some of the functions of the emulator are directly coded in C, and take the same file format (bina/bine/binc) than the bootloader itself.

    Bootloader protocol:

    The bootloader protocol allows downloading content from a file in the PC, to the A2Z RAM. I use the same protocol for the bootloader, and for updating files in the OS. The protocol is simple and mono directional. I have not wired the TX part of serial port. There is no acknowledge mechanism, no repetition, no flow control, etc…

    This protocol allows 2 actions:

    • Download a portion of data to the RAM at a specific address. I use 256bytes blocs.
    • Goto command : starts execution of the code that has been downloaded, at a specific address.

    There is a checksum mechanism for both actions, to detect data corruption.

    The bine/bina/binc files contain not only the data to download, but also the commands with this protocol. These file can be direcly transferred, in a raw format, via the serial port.

    Warning : the bine/bina/binc are therefore not raw binary files.

  • 3.6) Emulator on PC

    f4hdk11/18/2016 at 19:21 3 comments

    The emulator is very helpful tool to develop programs for A2Z, without downloading them to A2Z (which is slow). I can also develop programs with just a small laptop, when I am away from my electronic lab.

    This emulator is also the easiest way to share my project, if somebody wants to play with it, without building the real hardware. It is available for download at the start page of the project (inside the ZIP file). The emulated flash memory is already loaded with all applications and data examples.

    This is a “functional emulator”. It imitates the behaviour of the A2Z computer, but not the internal structure of the computer.

    This part was much easier to code than I first expected.

    The emulator is also coded in C, and uses the SFML library to acquire keyboard strokes, and to display the output graphic window. Therefore, the emulator should be easily ported to other platforms (Linux, Mac) with only small modifications.

    The emulator imitates the speed of A2Z : it executes 52083 instructions every 16ms, and then waits until the end of the next 16ms period. This is equivalent to the 12.5MHz speed of the real CPU. I chose a 16ms step because it corresponds to the framerate of 60Hz : graphics are updated 60 times per second, like for VGA output.


    • The Flash memory is emulated very basically, and the emulation does not correspond exactly to the real Flash. Therefore, a code that works on the emulator might not work on the real hardware.
    • I use a French keyboard (AZERTY), and therefore an US keyboard might not work properly.
    • The serial port is not emulated at all.

    User guide:

    The best way to call the emulator is via command line. You can optionally put filenames as argument. Here is the behaviour:

    • If no argument/parameter is put, the emulator loads the OS from the emulated Flash to the RAM, and executes it.
    • Parameters should correspond to name of binc/bine/bina files, that you want to load and execute. Files are interpreted in the same order that they appear. Therefore, you should put the bine (or binc) file at the end.

    During execution, you can use the following function keys:

    • F4 : pause the execution
    • F5 : resume execution
    • F7 : restart execution / reboot
    • F9 : load a new file to RAM, like the bootloader would do. This allow the user to update a file in A2Z file system, from a bin file in the PC. The update takes place in A2Z OS.

  • 3.5) Other tools

    f4hdk11/13/2016 at 18:17 0 comments

    Bin generator

    This program generates .bina or .bine files from several formats. These files are destinated to be downloaded to A2Z via the "bootloader protocol".

    If you want to generate an executable binary (bine), then the input should be a MIF file from the assembler.

    Otherwise the input file should be a raw file that you want to transfer to A2Z, and the extension of the output file will be "bina".

    Image / pictures manipulation:

    2 tools are used to create bitmap images with the right format and the right palette for A2Z.

    Palette_256 creates a windows bitmap file with 2 things:

    • A rectangle that has the size of the image that will be drawn
    • A palette of the 256 colours specific for A2Z. These colours can be easily collected and used with windows-paint for example

    BMP converter : it converts a windows-bitmap image (24 bits) into a raw bitmap image for A2Z, with the right palette. The image extracted must be located inside the rectangle drawn by palette_256.


    I have learned Notepad++ to recognise and understand my A2Z language. I have integrated 2 things in Notepad++:

    • Syntax colouring for declarations, for comments, and for text
    • Automatic detection of function declaration, with REGEX formulas.

    The configuration files for Notepad++ are available in the global ZIP. Refer to Notepad++ website to know how to integrate them to Notepad++.
    The call to the whole toolchain (compiler, assembler, and bin generator) can be automated via keyboard shortcuts inside Notepad++.

  • 3.4) Assembler

    f4hdk11/13/2016 at 18:17 0 comments

    The language is invented by myself, and corresponds to the instruction set architecture of the A2Z CPU.

    The generated code is in MIF format (Altera Memory Initialization File). I have chosen this format, because at the beginning of the project, I downloaded executables to the Boot RAM via the tool “in system memory content editor” that uses this format.

    The generated file also contains the source code in comments (both basic code and assembler code), and it is therefore easy to debug the tool chain.

    • Line commented : original source code in A2Z basic language
    • End of line comment : assembler code

  • 3.3) A2Z Compiler

    f4hdk11/13/2016 at 18:16 0 comments

    Once again, the compiler is 100% homemade.

    It is a cross compiler that runs on PC, that takes A2Z basic source at its input, and that generates ASM code at its output. Making a native compiler (that could run on A2Z itself) would have been too difficult, and my computer lacks too many things (tables more than 64kB, recursive functions, string functions, etc…).

    The compiler is, for me, the most difficult part of this project. I am more used to code low level control-command on small microcontrollers, than to code such applications that manipulate string, lists, etc…

    I needed lot of thinking and organization before beginning to code the compiler.

    But I really enjoyed coding this compiler, because it is a new matter for me.

    Sequencing of the compiler

    1) Storage of lines :

    the source code is split into a table of lines. Every line means a new instruction

    2) Configuration :

    the compiler then looks for the “configure” directive. This directive enables to configure max size, and memory position allocated to executable code and variables.

    3) Functions, first pass:

    the compiler then browses the code, and looks for functions declarations (subfunctions, ASM functions, and macros). It looks for first line of the function, and last line of the function “endfunct”. Each line of the code is tagged with its membership to a function. The first function must be “main”, and is executed at first.

    4) #define management :

    the #define are substituted with their real values.

    5) declarations of variables:

    the source code is once again browsed, and the compiler looks for variable declaration. For each variable declaration, the compiler stores its name, its function membership, its type, and the 2 sizes (for tables). If a variable is declared outside of a function, it is considered “global” (function = 0). We check that there is no double declaration (variable with the same name inside a single function), and that the RAM allocated for variables is enough.

    6) Allocation of variables :

    We then allocate the variables to the RAM, in a fixed (static) manner. The code for initial value of variables is also generated at this step.

    7) Functions second pass :

    for each function declaration (at the first line of a function), we look for inputs and outputs of the function. One function can have several inputs, and several outputs. The variables used for inputs and outputs must belong to the function.

    8) Instruction decoding:

    It is the biggest part of the compiler, and the most complex. This is the only part that generates executable code. I use the concept of “expression” : a value that can be computed with several things, that can be : variables, constant, register, cache, result of a mathematical or arithmetic expression. The expression analysis is of course recursive inside the compiler, this enable to code complex formulas in a single line. The result of this expression can be used for 3 things : assign the value to a variable/cache/register, use it as a parameter for an input of a function, or use it for an input of a condition (if/while/for).
    The compiler browses the source code from beginning to the end, looks for instructions, and generates executable code on the fly. We also count the code size and determine the address of each instruction inside the executable code. This is necessary for the branching that will be managed later.
    There are 4 types of instructions:

    • 8.1 : assembly code
    • 8.2 : assign. It is the most simple instruction, that assigns a variable, cache, or a register, with an expression.
    • 8.3 : branching (conditional or unconditional) : if/else/for/while/goto
    • 8.4 : function call are managed in 3 steps:
      • 8.4.1 : first we copy the content of the inputs of the functions from the calling function to the called function.
      • 8.4.2: then we call the function. We also manage the execution stack at this step. It is 100% software, there is no hardware stack.
      • 8.4.3 : last, we copy the outputs...
    Read more »

  • 3.2) A2Z_Basic Language

    f4hdk11/13/2016 at 18:15 0 comments

    A2Z Basic is a language invented by myself. I wanted something slightly different from existing languages, primarily for fun, but also to help the compiler. The syntax is closed to C, but much less rich.

    Be careful : if you code in A2Z Basic, there are lots of constraints that exist just to make the job easier for the compiler. For example, each instruction must be in a new line, including closing accolades.

    If you want to copy the result of a computation in a variable, you must use the instruction “assign” before the formula.

    Finally, the compiler is not smart, and it is not able to prioritize math or logic operations inside a complex expression. You must put parenthesis everywhere, in order to split each elementary computation.

    if ( ((Xm_pos//4) >= 128 ) & ((Ym_pos//4) >= 32 ) ) {

    If you don’t respect these rules, there will probably be no error message from the compiler, but the executable code generated will not work.

    You can integrate assembly code directly in the middle of A2Z Basic code. This is used to code low level functions, to access hardware directly (drivers).

    The directive #appli_config sets the maximum allowed size for code and variables, and the position of the generated file inside RAM. The RAM portion dedicated to variables can be common (separation = 1) or separated (separation = 2) from the executable code. With option 2, you can use the full range 64kB for variables.


    There are 3 types of “functions”:

    • Subf : these are classic sub-functions which calling is managed on the execution stack.
    • ASMf: so called ASM function. They are elementary, low level function that cannot call other functions. The return address is not stored in the stack, but in a specific CACHE position. The calling and return of ASMf are therefore much faster than for Subf. This is useful for repetitive functions called very often.
    • Marcos: macros are pieces of repetitive code that are just substituted inside the source code before its parsing

    Limitations of the language and the compiler

    • Static memory allocation, no dynamic memory allocation (no data stack or heap).
    • No recursive functions management : a function cannot call itself, either directly or indirectly, because of the previous limitation (static memory allocation)
    • 64kB only of memory range for variables, because of 16bits pointers. But a program can access the whole 2MB range with low level instructions
    • 2 dimension tables at maximum
    • Only 1 basic source code file at input of the compiler. No “include”, no library (static or dynamic). All functions used in a program must be copied to the source code, even repetitive functions (printf)

View all 18 project logs

Enjoy this project?



Dylan Brophy wrote 04/01/2017 at 06:46 point

Love the project. I like making things like this, but I usually dont get so far as this.  This is the kind of think I've always wanted to complete.

  Are you sure? yes | no

f4hdk wrote 04/01/2017 at 07:00 point

Thank you !
I've seen your project of CPU on FPGA, which is quite similar.
Do not hesitate to explore my project in details : everything is OPEN SOURCE.

  Are you sure? yes | no

Dylan Brophy wrote 04/01/2017 at 07:06 point

Yes, I think I can get pretty much everything working but I keep getting stuck on the problem of mass storage. So basically I have nowhere to put an OS, filesystem, etc... I will look more in depth into a2z and SPI

  Are you sure? yes | no

Dawid Pilawa wrote 01/22/2017 at 20:49 point

Hey, I just saw your comment on my blog and followed the link to your site. What you're doing is amazing, I know how much dedication these things require. Congratulations, fantastic project! (and you have video output, I don't ;))

  Are you sure? yes | no

John Croudy wrote 01/15/2017 at 19:04 point

This is a fascinating project. I don't know anything at all about FPGAs or Verilog so it's hard for me to understand. I really like the nice graphics system. It seems like you designed it with graphics in mind from the beginning. The machine code looks to me a lot like microcode instructions, as if they are even lower level than machine code normally is. I woke up in the middle of the night thinking about that :-)

  Are you sure? yes | no

f4hdk wrote 01/15/2017 at 19:53 point

Thanks John. I've also seen your recent progress on Leo-1. I understand that you have 3 boards completed out of 5, and working on the 4th. Keep going!

You are right : my computer was designed with graphics in mind. 

The machine code looks probably like microcode. It is a design that came from my imagination, not from existing CPUs. It is a RISC design, without microcode, and instruction are very low level. Therefore, the executable code is much bigger than for CISC CPUs. But the CPU core itself is very simple: especially instruction decoding is very very simple. It is also slower than CISC because the CPU takes lots of time just for reading instructions from the bus (and of course there is no execution pipeline)... But it works!

  Are you sure? yes | no

hlide wrote 01/15/2017 at 12:10 point

Reading your emulator source and comparing with ISA documentation:

if ((config_reg & 4) == 4) { addr_A_L++; }
if ((config_reg & 8) == 8) { addr_A_L++; }

CONFIG register:

3: Increment A + 2
2: Increment A + 1

 Shouldn't it be:

if ((config_reg & 4) == 4) { addr_A_L++; }
if ((config_reg & 8) == 8) { addr_A_L+=2; }

same "issue" with 'addr_B_L' too.

  Are you sure? yes | no

f4hdk wrote 01/15/2017 at 12:18 point

Thanks. At least one person is really looking at the code! ;-)

You are right, I made a mistake... but the mistake is on the ISA documentation. Both bit 2 and bit 3 of config register increment +1, so that if both are selected, it makes a +2 increment. It is exactly the same on the Verilog code.

  Are you sure? yes | no

hlide wrote 01/15/2017 at 12:29 point

so in that case:

if (config_reg & (4|8)) { addr_A_L++; }

would be better ;p

  Are you sure? yes | no

hlide wrote 01/15/2017 at 12:37 point

I'm looking at your emulator code to understand the ISA as it isn't totally clear to me (what are the available registers? what are the CACHE registers (>0x80), how many  are they? why the other registers have their 3 lsb set to 0? and so on). I'm trying to evaluate how difficult it would be to make a C compiler with that special ISA which doesn't sound standard enough to allow any easy porting of a C compiler.

  Are you sure? yes | no

f4hdk wrote 01/15/2017 at 12:38 point

@hlide : I don(t understand your proposal below, it cannot make +2 increment if both bits are selected. Each bit triggers a +1 increment separately. 

> if (config_reg & (4|8)) { addr_A_L++; }

And the current code works fine...

  Are you sure? yes | no

f4hdk wrote 01/15/2017 at 12:50 point


> what are the available registers? what are the CACHE registers (>0x80), how many  are they? why the other registers have their 3 lsb set to 0? and so on

Have you read all the blog posts of my project? Especially "Verilog Core"? All register are listed in "micro address". The cache is 128x16bits. The 3 LSb are relevant only for cache access. For other registers, these 3 LSb are not considered at all; this makes the micro-address decoder simpler. 

  Are you sure? yes | no

hlide wrote 01/15/2017 at 13:18 point

No I just have a glimpse at verilog source and found that it seemed to rely a lot upon Altera black boxes (or something like that) so I decided to look at emulator source as I thought it would be easier to catch the ISA details, not the implementation details. So ok, you are impacting some hardware implementation bits in your ISA that the pdf documentation didn't explain. Now I'm going to read the verilog core entry in your blog as it seems much more detailed as I thought, sorry for that. 

"if (config_reg & BIT) { addr_A_L++; }": ok, you choose to set both bit 2 and bit 3 to make a +2. Sorry, I underlooked the reason to have two bits doing the same things.

  Are you sure? yes | no

BigEd wrote 01/14/2017 at 11:37 point

Very nice!  And thanks for joining us at!

  Are you sure? yes | no

Just4Fun wrote 01/12/2017 at 07:45 point

Wow! really impressed...

  Are you sure? yes | no

Mark Nesselhaus wrote 01/10/2017 at 01:55 point

Very fine job.

  Are you sure? yes | no

Enrico wrote 01/09/2017 at 21:56 point

Amazing one.
Are you a student or you are doing similar stuff as a job?

  Are you sure? yes | no

f4hdk wrote 01/09/2017 at 22:07 point

Thanks for your comment.

I'm not a student, and this is not my job neither. I am autodidact, this is my first FPGA and verilog project. 

If you read all blog posts, you will understand that I made some mistakes, and that I was not able to reach the frequency that I wanted, because of my poor knowledge/understanding of FPGA's timing constraints.

But of course, I've learned a lot with this project!

  Are you sure? yes | no

jaromir.sukuba wrote 01/09/2017 at 19:03 point

Fantastic project.

  Are you sure? yes | no

Yann Guidon / YGDES wrote 01/09/2017 at 18:56 point

Congrats !

  Are you sure? yes | no

f4hdk wrote 01/09/2017 at 22:38 point

Merci Yann! Je ferais une version française de la description en parallèle sur un autre site, dans quelques semaines. 

Où en est ton YASEP? Tu as des applications qui tournent dessus?

  Are you sure? yes | no

Yann Guidon / YGDES wrote 01/10/2017 at 03:26 point

Pour l'instant, je reprends tout depuis la base, je dois réécrire YGWM, et je me lance dans l'architecture YGREC qui est encore plus minimaliste mais qui nécessite encore moins de transistors que le YASEP :-P
Ca me fait donc 3 archis : F-CPU, le YASEP et YGREC... Vivement que j'harmonise tout ça dans un YGWM tout neuf :-)

  Are you sure? yes | no

Dan Julio wrote 01/08/2017 at 16:43 point

Well done.  What an education for you.  I think it is in the spirit of people who were first creating personal computers with new microprocessors.

  Are you sure? yes | no

f4hdk wrote 01/09/2017 at 22:17 point

Thank you. 

You are right : I have read the book "I Woz" (by Steve Wozniac) at the beginning of the project. I wanted to touch this feeling : manage all the parts of one computer in details. 

But these microcomputer pioneers only had poor development tools, and today I have access to much more efficient ones (my PC, the software inside this PC, a C++ compiler, the FPGA, my logic analyzer, etc...). So the job is much easier for me!

  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