alrj.org

A DOS minesweeper in 256 bytes

2025-02-17T10:00:00+01:00

Twenty-five years!

It has been twenty-five years since I last released a prod at a demoparty, according to Demozoo (not that I have release many...). But this year, finally, I submitted a small minesweeper game at the Lovebyte 2025 demoparty. Sadly, there was no nanogame competition this year and games were only showcased, but judging from the reactions in the chat people seemed to like it, which is absolutely wonderful!

What is it?

It is a game of minesweeper, for DOS. It runs in Dosbox and in Dosbox-X, it also runs on my 486 under MS-DOS 6.22 and FreeDOS 1.3, and it even runs in a DOS window under Win98 on my K6-III.

It presents as a .COM executable file, and the entire game is 256 bytes.

What does it features?

It runs in VGA graphics mode 13h so that the mouse pointer can be an actual arrow. Also, this gives the opportunity to use a nicer color palette.

The digits indicating the amount of nearby mines are colored based on their value, and right-click can be used to flag a cell.

Full eight-way flood reveal is implemented to automatically reveal entire zones where adjacent cells have zero nearby mine.

Try it by yourself right here:

Limitations

Of course there are limitations. What did you expect, this is a 256 bytes game!

The map generation is not delayed, so you might end up dying on your very first click.
There is no tri-state flagging, where you could put a question mark on a cell.
No middle-click either that would allow to reveal all neighbours of a cell that has all its nearby mines already flagged.
Map size is fixed. You can change the amount of mines, but this is done by editing the value in source code and recompiling.
The only way to exit the game is to win or lose it. And to know if you won or if you lost, when you get back to the DOS prompt, you need to check the last cell you clicked. If it shows a mine, then you lost ;-)
The video mode is not restored on exit, but on the other hand this leaves the finished game on screen so you can tell if you won or not.
The presence of the mouse driver is not checked. I must admit I haven't tested that and I don't know how you'd exit the game without a working mouse. Apologies if that gets you stuck when trying to play on a real computer.
When you lose a game, there's no visual clue of wrongly placed flags and unflagged mines.
There is no display of elapsed time or the number of mines left.

Despite these, I find the game totally playable, but I might be biased.

Download and externl links

You can download the game here. Source code is included, of course, and you can do whatever you want with it.

Entry is now created on Pouët.net and the page on Demozoo is up, though still a bit empty.

BB-88 runs Minix

2024-07-22T10:52:00+02:00

This is a log entry about BB-88. See the project page to know more about it.

Running Minix on BB-88 was certainly not part of my goals when I started this project, but at some point, seeing how I could get MS-DOS running, I thought I should at least give it a try.

Now, although Minix can run in the very limited amount of memory a 8088 can address, that's not exactly the ideal setup, and there are limitation. Thankfully, most shortcomings are covered in the FAQ:

Minix Installation

Without a floppy disk interface, the only way for me to install Minix was to transfer an existing system onto a Compact Flash. My first tentatives to install it inside a QEMU virtual machine did not go well because of this bug in the floppy drive emulation in QEMU.

This is where the disk images of Minix QD prepared by David Given came to the rescue. I went straight to the Minix 1.7 image and didn't even bother playing with the Minix 2.0 one. I booted it in QEMU with the following command:

/usr/bin/qemu-system-i386 \
    -monitor stdio \
    -cpu 486 \
    -k fr-be \
    -machine accel=kvm \
    -m 64 \
    -hda /path/to/minix-qd-1.7-hd-64MB-test.img \
    -boot once=a,menu=off \
    -net nic \
    -net user \
    -rtc base=localtime \
    -name "Minix QD 1.7.5"

That allowed me to have a quick look at the content of the image, then I transfered it to a new Compact Flash and started BB-88. At this stage, I spent an insane amount of time chasing red herrings, trying to get it past the bootloader. In the end, all these issues were caused by not only one, but two defective Compact Flash cards! Once I switched to a known good Trancend one, the MBR executed fine, the partition boot sector executed fine and loaded the monitor, that I could interrupt by pressing ESCape.

Booting Minix

I needed to be able to interrupt the monitor to change the boot parameters. The Compact Flash might be IDE compatible, it is at a non-standard base address, and it uses what's referred to as the 'Chuck mod'. This is a change that improves the performance of the IDE interface on an 8-bit bus, but the software needs to be adapted accordingly. Instead of making all the changes in the at_wini driver in Minix, I instructed Minix to use the BIOS functions to access the disk.

>hd=bios
>boot

It looked like it was able to start, but after the initial loading, the screen would stay desperately empty.

Back in the VM, I edited /etc/ttytab to enable the console on the serial line so that I could get a shell, then re-imaged the Compact Flash and booted BB-88 again, this time to be greeted with a login prompt in Minicom! I got Minix running on my breadboard computer!

Armed with my serial console, I quickly found the cause of the black screen: my BIOS wasn't setting the I/O port address of the CRTC in the BIOS Data Area. Minix's console driver uses this to determine whether the console is color (CGA) or monochrome (MDA) when there's no EGA or VGA adapter. Once the firmware was fixed, the console came to life and worked beautifully.

Some improvements and a new font

With the system running, it was time to play with it and take advantage of BB-88's hardware.

The first, simple, change was to make a Belgian keymap. That was reasonably straightforward.

The second modification was to make the console use a slightly different video mode, showing 30 lines of text in 640x480 instead of the 25 lines shown in 640x400. It was a good warm-up for the next step, and I had to rebuild and reboot on the new kernel quite a few times before I got it working correctly.

Then, building upon that freshly acquired knowledge, I decided to adapt and improve the loadfont program. This required modifications in console.c and tty.c part of the kernel. To avoid interfering with the existing code for the more standard video adapters, the boot parameter 'video' must be set explicitely to 'bbga'. This is handled in glo.h and start.c.

In BB-88, the character generation ROM is actually a RAM, mapped in memory at address 0xA0000. Four different fonts can be stored in memory, each in its bank, and two bits of the Mode Register are used to select the active bank. My version of the loadfont program leaves the default font untouched in bank 0 and uploads the new font in bank 2. This ensures an easy way back to a readable console in case the loaded font is all garbled.

But the new feature I like the most is that it also reprograms the CRTC to adjust the display to the height of the new font. With this 12x8 font, I now get 40 lines of text instead of the classic 25 lines. I also had to implement the actual support for the change of geometry of the console, making sure the tty's winsize structure was correctly updated every time a new font was loaded.

You can download the font if you like it. This is a text-mode font that you can open in Fontraption.

I now have a nice Minix environment that I can use on BB-88, in addition to MS-DOS. So, what's next?

Experiments in VGA colors

2024-06-20T17:52:00+02:00

This is a log entry about BB-88. See the project page to know more about it.

Now that the VGA RAMDAC has been removed from the VGA signal generation circuit, I need to find a way to output the correct levels for the red, green and blue outputs. The idea here is to get the same colors than the first 16 colors of the official VGA palette. These colors are very close to the CGA and base EGA palettes as well (with a grain of salt, see this article about the true color values of the CGA palette on int10h.org)

My goal is to get something close to what they describe as the canonical mapping, with intensity levels of 0x00, 0x55, 0xAA and 0xFF.

Fortunately, the translation from a color index to the actual color is reasonably straightforward. Out of the 4-bit color value, bits 0, 1 and 2 each refer to blue, green and red; then bit 3 means "hi-intensity", for a lighter, brighter color. The brown color is a special case, but I'll get to it later.

Output signal

The full scale for VGA is from 0.0V for black to 0.7V output for full bright color channel, with a 75Ω termination inside the monitor.

Considering that 0xFF translates to 0.7V, we can assume that 0xAA is 0.47V and 0x55 is 0.23V. All that is left to do is to find a nice driver chip and figure out the right resistors combination that will result in the correct voltage being applied.

It's worth noting that the current resulting from sourcing 0.7V into 75Ω is close to 10mA¹, which cannot be achieved with many LS or CMOS IC families. With this in mind, I've decided to use the 74AC244, an octal buffer with strong drivers, capable of more than 20mA per output, which should be plenty. The fact that it is actually split in two, with an Output Enable pin for each half is also a big advantage, as we'll see.

Output circuit

At first, I struggled a lot trying to find the correct combination of resistors, but it became way easier when I realized that instead of using the input value of 0V or 5V, I could also use the tri-state nature of the buffer's output. After some quick fiddling, I finally had something working in the simulator².

The base for the output circuit of each channel would look like this (thus repeated three times, for red, green and blue):

For the first half of the palette, where the Intensity bit is not set, only the 487Ω and 150Ω resistors are used. The resulting voltage going out into the monitor will be around 0.46V, very close to the intended level.

When the intensity bit is set, the 820Ω resistor comes into play and brings the signal up to the desired 0.7V for full brightness, or to 0.26V when only the Intensity bit set, which is close enough to the desired 0.23V.
When Intensity is not active, the buffer is disabled, leaving the 820Ω resistor floating, having no effect at all.

Brown correction circuit

This is already very nice, but one color of that palette is not exactly the one we want: at the moment, color 6 looks more like what's often called "olive", or "dark yellow", instead of brown.

An additionnal circuit is thus needed to reduce the level of green for color 6, to get a more reddish tint. I did it with a resistor pulling the green signal down, activated by a 74AC139 selector.

Here is the adapted schematics for the green channel:

There is no need to check if we're currently in active display state here because we're just pulling to 0V anyway, so we can get away with half a 74AC139.

Actual result

I only had to wait a few days for the components to be delivered, and then, as is often the case, life got busy for several months. Until now...

I first built the circuit on a separate breadboard, just to test with the multimeter that the outputs acted as expected when I played with the inputs. It was also the opportunity to assign the physical slots of the ICs to keep the connections short and simple. The layout looks promising, it should need only minimal rework.

So, how does it perform? To test it in situation, I just put it next to BB-88's main circuit and connected it with long wires, bypassing the crude temporary DAC.

The colors on the LCD are showing just as expected, although there is a slight vertical banding, mostly in the bright colors.

Here's a close-up view that better shows the banding:

On the other hand, the result on the CRT is excellent!
The text looks sharp, and there are no jailbars, no shadows and very little echo!

I'm super happy with the result!

That's how the circuit now looks like on the breadboard:

I had to be creative to squeeze it in the available space, by using (and sometimes abusing) free gates on various ICs already present in the build, but that was really worth it. Because that also means I won't have to remove the OPL2 section! And I just found out yesterday that you can find small DC-to-DC modules that convert a single 5V supply into a dual ±12V output, which is exactly what I'm missing since I replaced the ATX power supply with a Meanwell one!

Full schematic

I thought I'd publish the full schematic of the prototype output stage for reference (click the image for a larger version), because I think it might be of use to anyone wanting to convert a 4-bit RGBI to analog VGA levels:

As you can see, the circuit as it is implemented also uses the remaining half 244 buffer to try and get the timing slightly more consistent between the channels, but I reckon it shouldn't make any visible difference in practice.
I also used one of the available NAND gates as an inverter in the prototype instead of adding another chip.

And yes, I'm aware that the output impedance does not match the monitor's input impedance, but that doesn't seem to be much of an issue.

I = U/R = 0.7V/75Ω = 9.33mA ↩
I've been using KTechLab for this, despite some annoying shortcomings. ↩

A PS/2 adapter box for the HP 715/80

2024-05-06T22:20:00+02:00

The HP 715/80 workstation has an unusual port for input devices that requires the use of an adapter box: the HP HIL A4022-62005. This module sells at an insane price, even without its cable, so the only reasonable thing to do was to make one myself.

At the back of the station is a socket for a modular connector, much like a network plug, but with 10 pins instead of 8.

If you look closely, you can see that it is also keyed on the left, certainly to prevent anyone plugging a network cable in there.

Thanks to nater1217 on the VCFed forum, the pinout is known! and has also been submitted to pinouts.ru.

Many thanks also to Anders Gustafsson for sharing his Adventures with HP HIL, especially for the part numbers of compatible connectors.

The good news is that, in addition to HP HIL, PS/2 keyboard and PS/2 mouse signals are both directly available on this connector, and the adapter box doesn't need any logic. This was confirmed with a quick prototype on breadboard:

Now I know it's working, but I'd rather have all that in a nice box, so I designed a PCB that would fit in a small 10cm by 6cm box.

The schematic is extremely simple:

And the PCB isn't very complex either:

Note that I have included the HIL connector, but I give absolutely no guarantee that it will work, this is entirely untested and the order of the pins could very well be swapped! Use it at your own risk.

The gerber files were then sent to JLCPCB and the printed circuit boards arrived after a few days.

Assembly was straightforward. In hindsight, I wish I'd used a right angle pin header instead of soldering the wires directly to the board, but I don't have any in stock. Well, I have ordered some, and I can always change it later. (The box is too small for vertical pin header).

The cable I used comes from a PS/2 extension cord and has only 6 conductors (plus shielding, that I didn't use); that's just enough to get the two PS/2 connections working!

The two holes are used to firmly secure the cable with a zip-tie.

Enjoy a few more pictures of the circuit assembled and put in its box.

The schematic was made with Lepton EDA and the PCB with pcb-rnd.

You can download an archive of the sources of the project or go to the project page on framagit.

BB-88 stability issues

2024-01-07T15:39:00+01:00

This is a log entry about BB-88. See the project page to know more about it.

When I was building BB-88, it was sitting on my electronics bench, right below the roof window. And as you may suspect, it rained on it a few times, especially during summer when I tend to leave the window open. I don't know for sure if it's the main reason, but with time, the breadboard computer has become quite unreliable.

I've sprayed contact cleaner everywhere and tried to play with all the wires, hoping they would make better contact. I have also brushed the legs of all the ICs with a fiberglass pen, but with very little success.

Something else that I have noticed is that the ATX power supply I've been using doesn't seem able to regulate correctly with a load this light. Asides from the OPL2 "sound card" that needs ±12V, the entire computer runs on 5V, and it gets loaded to a mere 1.3A. When unloaded, the power supply gives a very neat 5.02V but it drops down to about 4.7V when powering BB-88. I have tried loading the other rails with biggish resistors: 4Ω on the 3.3V and 2.5Ω on 12V, but unfortunately it didn't help the 5V rail. Testing with two other power supplies showed an even larger drop on the 5V line.

Another part that causes a lot of problems is the palette RAMDAC. Sometimes it works, but most of the time the output is very noisy and the colors aren't setup correctly. Then if I replace the chip with another one from my components stash, it sometimes works for some time, or fails with different bad colors. This could indicate a component failure, but the behaviour seems to be consistent with two different brands (IMS and Analog Device). I do not exclude the possibility that I'm doing something wrong with the chips.

Hardware simplification

All these issues developed over time, and now that I know that I could build it, I'd rather make the computer more stable, at the expense of features that I don't actually use.

The first modification I made was to replace the ATX power supply with a small 5V MeanWell power supply¹. That alone made the computer much more stable, but it also means that the OPL2 sound section is no longer powered, as ±12V is no longer available. Ripping this section apart later on will give room to make a more advanced color video output circuit, but for now let's keep things simple.

This is the VGA palette DAC that must go away to be replaced with a very crude circuit that converts the RGBI (Red, Green, Blue and Intensity) signals to VGA levels. This is far from perfect, and isn't even consistent across monitors.

I used the circuit from http://boginjr.com/electronics/rad/rgbi/ but I adapted the resistors' values in order to try and get a slightly better image quality (although with very limited success, as seen below). Please don't mind the flying wires, this is only a temporary setup.

The LCD shows lavish bright colors with very strong jailbars (that don't render well in the picture, but believe me, this is disgusting to look at).

When driving the CRT, it seems like the intensity has nearly no effect on primary colors (pure red, green or blue), a little effect on colors that mix two channels (cyan, purple and yellow), and full effect on light gray, that uses all three. Dark gray is barely visible.

Note that the picture of the CRT, above, doesn't render the colors very well either. It is much darker in reality, and the yellow actually looks like a dirty dark yellow, not at all like this nice brown color.

Conclusion

The system is now very stable. I haven't experienced a single freeze or failed boot since I changed the power supply, even in Turbo mode.

The colors are seriously off, but at least they do show up on screen! With the randomly failing RAMDACs, that was never a given.

Next step, I intend to remove the OPL2 section and replace it with a more robust VGA output, if possible with the correction circuit for brown color!

Exact reference is Model RS-25-5, rated for 5 Amps. ↩

A word on function calls and returns

2023-04-04T00:00:00+02:00

If you've read my previous post about control hazards, you may have noticed that I talked about branches and jumps, but did not write a single word about function call or return instructions. This omission may be a bit surprising if you are not familiar with RISC-V or architectures with a similar instruction set.

The reason is that JAL (jump and link) and JALR (jump and link register) already cover these use-cases, because both of them can store the address of the instruction following the jump (PC+4) into the destination register. The register x0 can be used as the destination when that return address is not needed. Remember, x0 is the zero register, it is always equal to zero and writes to it are always discarded.

start:
  jal   x0, somewhere   ; direct jump, discard return address
  ...

somewhere:
  jal   x1, f           ; call function f, save return address into x1
  ...

f:
  ...
  jalr  x0, 0(x1)       ; Return to the address x1 (and no offset)

But seriously, don't you find that a bit... unreadable?

The convention set by the proposed ABI is to use register x1 as the return address, this register being refered to as ra. There are also pseudo-instructions that the programmer can use to take advantage of these conventions.

The same code using pseudo-instructions and register alias would look like this. Note that it is 100% equivalent to the snippet above and expands to the exact same instructions.

start:
  j     somewhere       ; unconditional direct jump
  ...

somewhere:
  jal   ra, f           ; call function f
  ...

f:
  ...
  ret                   ; Return from subroutine

Using a register instead of the stack to store the return address (as is the case in the x86 family, for instance) has several advantages.

First, it simplifies the design of the processor a lot, keeping it true to the Load/Store architecture.

Second, it can make the code more efficient, as it is now up to the subroutine to determine if the return address needs to be pushed onto the stack, or if it can simply be left in a register when there are no nested calls. Especially in our case, where the Fetch and Memory units cannot both access the RAM during the same cycle.

Finally, although the convention is to use x1, nothing stops you from using any other register to save the return address. The official specification even suggests using x5 as an alternate return address for millicode routine calls to common prologue and epilogue code for functions. Of course, the subroutine that is called must also know which register has been used, in order to return to the correct address!

Now you know why I didn't mention call and ret in the previous article: they are actually just plain jumps.

Control hazards with jumps and branches

2023-04-03T00:00:00+02:00

I've talked about the data hazards in a previous installment, now let's talk about control hazards. A control hazard is when we need to find the destination of a jump or a branch and can't fetch any new instruction until this destination is known.

When a branch instruction is fetched, it must then be decoded in the second cycle before the condition can be evaluated in the Execute stage during the third cycle. Only then can the CPU determine the new value for the PC.

The same happens with jump instructions: the destination of a JAL instruction is the sum of the current PC and an immediate value, the destination of a JALR instruction is the sum of a general purpose register and an immediate value. In both cases, this addition can only be performed after the instruction has been decoded.

But if the instruction is a jump or if it is a branch that must be taken, it means that the previous stages of the pipeline contain instructions that should not be executed. The processor needs to have a way to abort them before they reach any point where they could commit a change in the state of the machine. This operation is called "Flushing" the pipeline.

The signal for that is generated when the instruction moves from the Execute stage to the Mem stage.

If the instruction is a jump or a branch that is taken, the signal Flush@EX is active during the first half of the cycle, and is used to clear all the pipeline registers in previous stages IF/ID and ID/EX. phi2 is the complement of the clock signal. It goes high when the clock goes low, and in this case it is used to reset the flip-flop that sends the flush signal in the middle of the cycle. We don't want this signal to stay active for too long, or we would risk clearing the next instruction when it is fetched if the timing gets too tight!

In the case of a branch instruction that is not taken, the processor simply does nothing and continues as if it was a NOP instruction.

Anything else ?

I have only mentionned jumps and branches here, but there will be other reasons for the flow of instructions to be interrupted: interrupts, exceptions (maybe), breakpoints, and system calls, also known in the RISC-V world as environment calls. But these need the introduction of another bit of hardware in the processor, the Control and Status Registers (CSRs).

I want a hardware multiplier

2022-07-05T00:00:00+02:00

I'm currently working on the data multiplexer, the part that comes between the CPU and the memory and is responsible for putting the right byte at the right place, but I can't stop thinking about what comes next.

And let me tell you, there's still quite a lot of development to do and many topics to cover!

The next article will probably be about branches and jumps, leaving out everything related to exceptions and interrupts handling for the moment.

On the development side, and in no particular order, there's waiting for slower memory or IO device, actual memory mapping, CSR's and all the system instructions, exceptions and interrupts, global reset circuitry, ...
And then the peripherals.

There is also one thing that may come much later in the project but that I don't want to rule out: a hardware multiplier. (And while at it, why not put a division unit along with it? But that is another story.)

In any case, there's just no way that it will run in a single cycle, so it will require some sort of mechanism to freeze the pipeline at the Execute stage while the "MulDiv" unit does its job. I expect this mechanism to be very similar to what I'll have to implement for the slow memory access anyway.

Regarding the multiplier itself, chances are that I will go for simplicity and do the slowish shift-add method because all the other ways I know are just too expensive to build with discrete gates at 32 bits.

And before you ask, no, I will not go out of order. The instruction following a mul will have to wait in the Decode stage!

Now, honestly, wouldn't it be very sad to have to draw the Mandelbrot set using only software multiplication?

Of data hazards, bypasses and stalls

2022-06-28T00:00:00+02:00

Remember that a data hazard occurs when an instruction waits for the result of a previous instruction.

In the following example:

        add a0, t0, t1         ; a0  ←  t0 + t1
        sub a1, a0, t2         ; a1  ←  a0 - t2

the add instruction stores the result into register a0 when it reaches the Writeback stage at clock cycle 5,
but the sub instruction wants to read a0 when it reaches the stage Decode in clock cycle 3.
Of course, at cycle 3, the result of the first instruction has not been written into the register file yet.

Instead of waiting two cycle for the value to be available, we could instead create a shortcut, a way for the second instruction to get the value of a0 directly out of a subsequent stage of the pipeline. In other words, a bypass.

In practice, it's not just one bypass that we need but several of them!

The forwarding unit

The Execute stage needs to know the correct value for both rs1 and rs2 and each of them can come from three different sources:

The register file. That's the canonical source for the value, no bypass is used.
The output of the previous instruction. This means the value is present in the EX/MEM pipeline register, which is equivalent to say that it comes from the Memory stage.
The output of the instruction before that. In this case, the value is in the MEM/WB pipeline register, or in the Writeback stage.

Any instruction before that will have had the time to go through the Writeback stage.

Here is how we determine the correct source for the value of rs1:

The forwarding unit is always active, it does not care whether the register is actually needed by the ALU operation or not.

The logic is not very complex. First, a comparison is made between the the source register number and the destination register number of the previous two instructions (the one in MEM and the one in WB). Then it is also checked that these previous two instructions do actually want to write a value back. A store instruction, for instance, does not write anything back in the register file, so cannot be the source of a bypass.

After these two tests, we know if rs1 is present in MEM or in WB (or both), and it is only a question of priority to know where we want to take it from. Highest priority is MEM, then if not present there, try to take it from WB, and otherwise default back to what was fetched from the register file.

The logic is exactly the same for rs2:

There is another place where a bypass is required, it's in the Memory stage. When a load into a register is immediately followed by a store of the same register, this value must be forwarded as well.

The bypasses

All right, we have all those signals coming out of the forwarding unit, but what do we do with them?

We wire the bypasses, of course!

The first bypasses are the ones in the EX stage, and they look like this:

The selection signals will enable only one buffer for each of rs1 and rs2, so that the correct value can be sent to the ALU or further down the pipeline.

In the Mem stage, it's the same principle, only simpler because there is only one register and two sources:

The stall logic unit

There's one situation where we cannot rely just on a bypass, though, it's the use of a register by the ALU in an instruction directly following a load. The second instruction needs to wait for the value to be loaded from memory, and for that it needs to be stalled.

We stall if the ALU wants, as one of its input, the content of a register that would come from the previous instruction, and that previous instruction is a load. All the other cases are covered by the bypasses we just implemented above!

The stall mechanism

Let's keep things simple for now and consider that a memory access can always be done in one cycle. As a consequence, the instruction present in the EX stage cannot advance and must stay in there, while the load instruction in MEM stage moves to the WB stage. That leaves a bubble between them.

If the instruction in EX cannot advance, neither can thoses in the previous stages Decode and Fetch.

On all the pipeline registers between EX and Mem, a stall signal will prevent a new value to be clocked in by disabling the Write Enable input:

The same signal is applied to the other pipeline registers in ID/EX and IF/ID, as well as to the fetch unit so that the PC does not get incremented.

There is just one pipeline register that we need to treat differently: the register that conveys the actual instruction's actions from EX to MEM, that one must be cleared to become a nop, our bubble.

This concludes the part on how the data hazards will be handled in Astorisc. Stay tuned for the next part where we'll tackle the control hazards induced by the jumps and branch operations.

Astorisc: The simulation begins

2022-05-09T00:00:00+02:00

These last few weeks, I've been working on implementing the CPU in Digital.

My initial intention was to stay as close as possible to what will be the actual implementation, but in practice, it may not have been a good idea, because it didn't always play well with the simulation. Most of the time, when trying to start the simulation, Digital would complain that more than one output was active on a wire, causing a short circuit in the shifter unit.

The problem went away when I switched from pairs of buffer driven by two complementary signals to plain old multiplexers. For the physical implementation of the processor, selection between two possible values will likely be implemented using the following logic:

When the Sel input is low, the buffer for the A input is active, while the buffer for B is kept in high impedance (meaning its outputs are like disconnected). When Sel is brought high, it's the opposite, and the output is equal to the value on the B input.

But for the moment, the simulation will use multiplexers, like this:

When Sel is low (0), the Output mimics A. When it's high, the Output mimics B. Technically, this is equivalent and will work just like the one above.

Running the first program

Here's how our processor looks like right now (click to enlarge).

The Fetch, Instruction Decode, Execute, Memory, and Writeback stages appear clearly separated with the pipeline registers in cyan between them.

The Decode logic outputs a whole bunch of simple signals that will tell the next stages what action they must take.

On the top will be our control logic, currently very primitive. On the bottom will come the RAM and I/O access, for now only represented by a single RAM, not even ready to handle byte or half-word access.

As you can see, there's no bypasses and forwarding unit yet, and no stall/flush control logic. So how can we make our first program work? Simply by inserting nop instructions in our program where the processor would have needed to wait for a value to be available, or where it would have needed to flush the pipeline (to discard the instructions right after a jmp or a branch). By definition, nops do nothing, and there is no harm to execute them even if they come from the wrong wode path.

This allowed me to run the following program that computes the Fibonacci series until the result gets above 1000:

_start:
        li a1, 1               ; start with first number = 1
        li a2, 1               ; and second number = 1
        li a3, 0               ; Useless, but we'll store the result in a3
        li a5, 1000            ; Set our upper limit

fib:
        nop                    ; the next value in the sequence is
        add a3, a1, a2         ;  the first number + the second number

        mv a1, a2              ; new first number is the old second one
        nop
        mv a2, a3              ; new second number is the computed value

        bltu a3, a5, fib       ; loop if we are not yet at 1000
        nop
        nop
        nop


_end:
        j _end                ; endless loop

Maybe there are too many nops, but who cares? It runs... And soon, it will run without all those pesky nops!

Just a few components ordered

2022-04-14T00:00:00+02:00

I had some components to buy at Mouser for an unrelated project, but my order wasn't going to reach 50€ and I wouldn't get free shipping...

So I added a few of nearly every logic gate from the AUC family in the basket. These are like the usual 74 LS or 74 HC family but they can work at very low voltage and are super fast ! They aren't cheap, though, so I ended up with an order waaay above 50€. Well, that's the price to pay for starting the actual R&D.

These logic gates exist in traditional 4 gates per package, or 6 gates for the inverters, but also in Little Logic that offer just a single or a double gate per package. This is what I ordered, because it makes prototyping much easier. But what did I get exaclty?

SN74 AUC 2G 00 DCU

SN74 is the typical prefix for these types of logic gates (there are other groups that we'll ignore here).
AUC is the Advanced Ultra-low-voltage CMOS family. It works from 0.8V to 2.7V and its inputs tolerate a signal up to 3.6V.
2G means it packs two gates,
00 is the code for the NAND function,
DCU represents the physical package. It's pretty small, about 2mm x 3mm with the leads.

It means these are dual NAND gates.

SN74 AUC 2G 02 DCU

These look a lot like the ones above, but they are dual NOR gates.

SN74 AUC 2G 04 DBV

04 is the numeric code for the inverter,
DBV is another package. That makes sense because inverters have only one input, not two, so only six pins are needed to pack two of them.

SN74 AUC 2G 08 DCU

We are back with some DCU packages, and 08 is the code for AND gates.

SN74 AUC 2G 32 DCU

You know the drill. Here, 32 means OR gates.

SN74 AUC 2G 86 DCU

And here is the last classic logic gates: the XOR gate, represented by the 86 code.

SN74 AUC 2G 53 DCU

Now, here is something new ! This is the famous analog FET switch that will help us build various higher level blocks like the adder.
Here's how the datasheets presents it:

Admittedly, that logic diagram looks a bit more complex. Here's what it does.

It connects COM with either Y1 or Y2, depending on the input A. Unless the input INH is high, in which case COM is not connected to anything (both switches are open).

The key point is that the connection between COM and Yn is really just like a switch, meaning the propagation delay is very, very short. While it can take up to 2.2 ns to switch from one Y to the other, or to enable or disable the switch, it can transmit a signal in less than 0.1 ns !

This is the property that will help us build very fast chains, or ripple, as we have in adders or in AND gates with a lot of inputs.

SN74 AUC 1G 74 DCU

Only one gate in this package, as can be seen from the 1G part of the name.
74 is the code for a D-Flip-Flop.

There's no reason to include the logic diagram for the flip-flop. I also won't explain how it works, I'm sure many people have already done so.

SN74 AUC 16 244 DGG

The 244 is nothing more than a buffer, or a driver, whose outputs can be disconnected (tri-stated).
16 because that device is 16 bits.
DGG is the largest package available for this device, but don't be fooled. The leads pitch is a mere 0.5 mm.

SN74 ALVCH 16 823 DGG

Here, we change family for a ALVCH device, for Advanced Low Voltage CMOS with Hold. This can work with slightly higher voltage than the AUC, up to 3.6V. This can be useful to drive the lines a bit stronger, for instance from board to board.
Be aware that 16 is a trap, this part is actually 18 bits!
The 823 is a bus interface Flip-flop, with three usefull features:

3-state outputs,
a clock enable pin, that can be used to prevent clocking in a new input value,
an asynchronous clear pin, that set all outputs low independently of the clock.

I'm pretty sure various parts of our processor will make use of one or the other of the last two feature.

That's all

That's all the parts I've ordered this time, unless we count the thousand 100 nF capacitors, and a mere hundred 10 nF ones :)
These are 0402 in imperial, or 1005 in metric. That means they are 1mm long by 0.5mm wide. This is the smallest size I have ever soldered by hand, and the experience wasn't too painful.

Notes

The diagrams in this article have been copied from their respective datasheets and are © Texas Instruments Incorporated. The logic diagram for the dual XOR gate has been edited from the dual OR gate.

Links to the datasheets of the gates described above:

Astorisc: Building blocks and components

2022-03-29T00:00:00+02:00

Throughout the entire processor, there are a few basic building blocks that will be used in various places. Let's have a look at some of them.

Registers

By far, the block that we'll use the most is the register. Not only in the register file, but also between each stage of the pipeline.

Typically implemented with D-Flip-Flops, a register has input pins, output pins, a clock line and an output enable line.
When the clock transitions from one state (let's say low) to the other (high), the device "saves" the inputs internally in its flip-flops and provides the same values on its outputs.
The output enable line can be used to put the output in high-impedence mode, which effectively disconnects the outputs without affecting the internal operation of the flip-flops inside the device.

Some components also have a clock enable line. When not active, the clock transitions have no effect and the internal flip-flops do not change. This could prove usefull in the register-file for instance, where only one register (at most) needs to be written to during the Writeback stage.

Some other devices have a synchronous or asynchronous clear signal, to set all the flip-flops at zero (low level). Synchronous means that it only happens on the clock transition, asynchronous means that the effect is immediate. Maybe that could be used to "kill" instructions when flushing the pipeline: set the entire decoded instruction to just a bunch of zeros.

Constructing a register is fairly easy: there are components that do exactly that already. They will often be only 8 or 16 bits wide, which is too small for our 32 bits register, but it is only a matter of using one of them for the low half-word (bits 0 to 15), another for the high half-word (bits 16 to 31), and tying together the clock and other control lines.

Adders

We will need at least three 32 bits adders in our processor. Well, the first will only ever compute PC+4 in the Fetch stage, so that one could be implemented as a 30 bits incrementer. We'll see later how an incrementer can be constructed using a simplified version of the adder.

The second one is part of the ALU, in the Execute stage. That one needs to do substractions and signed arithmetic as well, so might need some poking at its inputs, depending on the function we want it to perform.
Quick reminder: in order to subtract in two's-complement, we just need to bitwise invert the second operand and set the carry-in to 1.

The third adder is found in the same stage, but its role will be solely to compute the next PC in case of a jump or a branch. Branches and the jal instruction will compute PC + some offset, while jalr needs an arbitrary base register + the offset.

All these will be constructed following the "FET-switch adder" idea that emerged from the 6502 forums.

For speed consideration, we may end up implementing a carry-select stage.

I was also pondering about implementing the jal instruction during the Decode stage (using a fourth adder), since that one does only require PC and an immediate offset, and no source register. I then ditched this idea, though, because it will be incredibly easier to do all our jumps, branches and interrupts all at the same stage! Trust me, we don't want to take a shortcut here.

Comparators

The ALU will need what I'd call a full arithmetic comparator, capable of doing magnitude comparisons for both signed and unsigned integers. In the Risc-V ISA, the branch comparisons are either equal, not equal, less than, or greater or equal. There is also the "set if less than" family of instructions that need to do signed and unsigned comparisons.

Many other comparators, as far as I can imagine at this point, will be binary equality comparators, most of them in the Decode stage where they will be matched against parts of the instruction to make the decoded signals.

More equality comparators will be needed in the forwarding logic. These would only be 5-bit, comparing the destination register of the first instruction with one of the source registers of the next instructions to determine if a bypass needs to be activated.

Also, equality comparators will likely be used to determine which memory or IO space is active, based on the address.

Here again, the comparator can be built with FET-switches for the speed. We will also see how smaller comparators can be cascaded to build one that is 32 bit wide.

Decoders/selectors

Selectors (or decoders) take a binary number as their input to set a single one of their outputs to a given state. A typical example for this function is the classic 3-to-8 decoder, the 74LVC138, that has 3 inputs and 8 outputs. In order to be cascaded to build wider selectors, these devices often have one or more enable pins. For instance, the 74LVC138 has three of them, one active high and two active low.

Astorisc will need a few 5-to-32 selectors in the register file, and will also need some yet undetermined selectors in the RAM modules, to access the right chips.

Astorisc: The pipeline stages and hazards

2022-01-18T00:00:00+01:00

I would like to go more into detail about each stage of the pipeline, what they do and how they work. I know I said in the previous installment that I would not go into the details of hazards, but it looks like I will need it to document my choices in the processor architecture. So let's start with that.

Pipeline hazards

Inside our pipeline, the instructions interact with each other.

An instruction may need a resource currently used by another instruction.
→ structural hazard
An instruction may depend on the result value of a previous instruction.
→ data hazard
An instruction may depend on the calculation of a new address for the Program Counter (jumps and branches),
→ control hazard

Structural hazards

The most prominent structural hazard in our implementation is the access to the memory. To resolve it, whenever an instruction wants to load or store data into memory during the Mem stage, we have to tell the Fetch stage that it can not get the next instruction from memory during this cycle and has to stall.

This type of hazard could also be solved by using dual-ported RAM, so that both Mem and Fetch stages have concurrent access to the memory, but the price for several megabytes of dual-ported RAM is simply prohibitive.

Another way to resolve this hazard, often used in microcontrollers, is to have different, dedicated memory spaces: one for the instructions and another one for the data. This is perfect fine when the program running is well defined beforehands, but not really appropriate in the case of a general purpose processor that needs to load the programs into memory on demand.
Interestingly enough, modern processors do actually use a similar approach, by using distinct caches for instructions and data.

Data hazards

Data hazards occur when an instruction needs as one of its input the result of a previous instruction that has not gone through the Writeback stage yet.

  addi r4, r0, 30
  addi r5, r4, -12
  addi r6, r4, 25

When the second instruction enters the Decode stage, where it will also read the values of the source registers, the value of the register r4 has not been updated yet inside the register file. Two solutions exist to resolve this type of hazard:

Wait (stall) until the register file has been updated, or
Bypass the register file: if the result is available from one of the pipeline registers, get it directly from there.

In our example above, as soon as the first instruction has gone through the Execute stage, the resulting value for r4 is available in the next pipeline register. One clock cycle later it is present in the Writeback register, then after half a clock (more on this later) it gets written to the register file. If we were to stall the pipeline, that would induce a penalty of two clock cycles.

Similarly, the third instruction also depends on the result of the first one. If we were to wait for the correct value to be present in the register file for r4, only one clock cycle would be needed, though, because the other one was spent executing the middle instruction. But just as we did for the second instruction, we could use a bypass and forward the correct value directly from the Memory stage.

For any instruction after that one, the value for r4 would be present in the register file and there would be no hazard.

But does that mean all data hazards are covered with these two bypasses ? Now, consider the following example:

  lb   r7, 10(r8)
  addi r8, r7, 42
  xori r9, r7, -1

In this situation, the data for r7 will be available in one of the pipeline registers only after the first instruction has completed the Memory stage. When we have a register dependency on a load instruction, we have no choice but stall the next instruction (addi in this case) for one clock cycle. After that, the correct value for r7 will be present in the Writeback register, from which it can be forwarded.

The third instruction does not need to be stalled, and can make use of the bypass from the Writeback register.

Control hazards

Control hazards happen for jump and branch instructions because in either case, we need the result of the Execute stage in order to compute the new value of the program counter.

For conditional branches, the ALU has to do the comparison to know wether the branch is taken or not. It means that in all situations, the target of a branch instruction will only be known after the instruction has gone through the Execute stage.

For jump (jal) and jump register (jalr), the ALU computes either the sum of the PC and the offset or the sum of the PC and the register, respectively.

Note: if the cycle time permits, and the hardware for an adder is fast enough, we could consider the use of a dedicated adder inside the Decode stage of the pipeline. Remember however that our register file is updated during the first half of our clock cycle, which means the register values are guaranteed to be correct only during the second half of the cycle. For now, let's consider that we don't have the time to do it, and that the jump target is indeed only known at the end of the Execute stage.

This means that in both jumps and taken branches, the two instructions that were feeded into the pipeline now need to be killed, they do not correspond to the correct codepath anymore.

Next time

I don't know yet what topic will be covered next time. Actual components selection, building blocks, details of some pipeline stages, ...

Astorisc architecture overview: pipeline

2021-10-10T00:00:00+02:00

This article is mostly a high-level overview of the Astorisc architecture, do not expect implementation tricks and gory details in here.

As I said in the presentation, I'd like to make Astorisc a pipelined processor. But what does this actually mean? I could send you to the article on Wikipedia, but I may as well try and explain it myself.

In a nutshell, pipelining will make the processor execute the instructions in a series of steps (or stages), each step running in a different unit, allowing processing multiple instructions in parallel.

The pipeline in Astorisc will be the well documented canonical 5-stages pipeline, that is perfectly suitable for a RISC architecture:

Instruction Fetch
Instruction Decode and register load
Execute
Memory access
Register writeback

How the pipeline works

At each clock cycle, the instruction will advance to the next unit of the pipeline, keeping all the stages busy. At least, that's the theory. In practice, there are situations where an instruction must be delayed until the resource it needs becomes available.

When the clock ticks, each intermediate register will store the result of the unit before it, and make it available to the next unit in the line, keeping its value stable until the next cycle.

The pipelined RISC-V datapath

Here is an extremely simplified datapath diagram for our pipelined RISC-V processor.

Pros and cons ?

The main advantage of a pipelined architecture is that each step, taken individually, is comparatively simpler and needs a much shorter amount of time to execute, meaning the processor can run at a higher clock speed.

The downside is that the processor gets more complex, because of all the intermediate registers and the control logic.

Hazards

In a pipelined CPU, an instruction starts being executed before the previous one is finished. That can cause problems, for instance when the second instruction needs the result of the first one before it is actually available. Those problematic situations are called hazards.

I will not go into the details of the various types of hazards, nor when or why they happen. Instead, I will shortly describe the solutions that I can implement to resolve the issues.

Stall: This is probably the easier solution. When an instruction needs a previous instruction's result that is not yet available, make it wait until it is. In some situations, there is just no way around it.
Bypass: A more complex, but more efficient solution, is to provide an alternative path for the data to be routed immediately when it is available. I intend to implement this operand forwarding at least at the Execute stage.

Note that I do not intend to implement out-of-order execution ;-)

There is also the question about accessing the memory that can happen at both Fetch and Memory stages. Probably the easiest way to solve this issue will be to deny the fetch when an instruction accesses the memory. This is a bit like a stall, although it happens at the very first stage of the pipeline, so nothing actually stalls.

For the jumps and branches that are taken, I will need a way to discard the instructions that have already been loaded into the pipeline but must not be executed.

But how to do all that?

In future articles, I'd like to go into the details of some of the components that I've shown as simple boxes in the diagram above. The ALU symbol may look quite simple, but the reality far from that!

A RISC-V processor from logic circuits

2021-09-22T21:43:00+02:00

Now that BB-88 is more or less complete, let me tell you about another project that has been on my mind for a few years now: a homebrew computer featuring a RISC-V processor made of 74 series logic.

There are already a few projects to make a RISC-V processor from scratch in various stages of completion:

The first one I've heard of was Robert Baruch's LMARV-1 (Learn Me A Risc V), a series of youtube videos. The first iteration of the project apparently hit a hard stop at some point, but got rebooted in late 2020. These videos cover many interesting topics like various ways to implement the register file, the ALU, etc.
The second one was a project on Hackaday.io by Phil Wright: World's first 32bit Homebrew CPU
The latest one is the Pineapple ONE, by Filip Szkandera. This is probably the most advanced of these projects, and perhaps the only one that can actually be used to run some real code.

Also, not a RISC-V, but close enough, there is the Spaceage 2, a university project that implements the MIPS ISA.

All of these projects aimed for different goals, and each one follows its own path, which make them all very interesting to study.

I don't know if mine will ever see the light of day, not even speaking of being complete, but I'll try¹ to keep some notes about my research and progress here.

Goals

My main goal for this project is simple to state: make it as fast as I can!

At the moment, I envision a pipelined CPU running maybe at 30MHz with register forwarding between some stages of the pipeline to avoid stalls. The main path in the pipelined would not be microcoded, unlike most projects I've seen. That said, if I ever implement hardware multiplication and division, they will take multiple cycles to execute and would probably be microcoded.

My second goal is to make it a Von Neuman architecture, where there is a single memory space for both code (instructions) and data. This goes against the first goal because instructions that need to access the memory will prevent the CPU from fetching the next instruction during the same clock cycle, but I reckon this is the price to pay for the flexibility of a "real" computer.

Finally, I'm not only thinking about the processor here, but also the peripherals and the way they communicate together to make an actual computer. That means there will be some kind of bus, probably like the ISA bus but wider, wait-states to cope with slower devices, etc.

How do we call it ?

Unless I find a better name in the future, I'm still undecided between Astorisc and Castorisc. The first one is for Alrj's take on RISC-V and is similar to the word Asterisk. The second one doesn't stand for anything, it only evolved from the first idea and could use a castor as a logo.

Sometimes, finding project names is even harder than finding hostnames.

Where does it happen ?

Right here! There will be a project page where I will hopelessly try to organize my thoughts.

Stay tuned!

If you used to follow my defunct blog or even this very website in the past, you will assume there is a fairly high probablility that I will stop publishing anything about the project very soon. and you may very well be right about it. We'll see... ↩

BB-88 is the new Bidule88

2021-09-22T18:17:00+02:00

This is a log entry about BB-88. See the project page to know more about it.

Soon after my last post about Bidule88 in 2014, I realized that four breadboards would definitely not be enough to complete the project. I quickly tore it down to restart from scratch, this time on a much larger scale: two columns of seven breadboards each.

This time it took me a bit longer, but again, the project reached a point where a larger set of breadboards was needed. Two columns of seven breadboards next to each other were dedicated for the core of the computer and most of its extensions, while a third column separated from the first two by a few vertical bus lines was reserved for the video display adapter alone. All together, they thus make for an impressive total of 21 breadboards.

That was also the opportunity to rename the project. Goodbye Bidule88, welcome BB-88, the BreadBoard 8088!

Restoration of a Criko THD-16 drill press

2015-10-01T21:00:00+02:00

I recently bought a Criko THD-16 drill press from 1992. It is in good general shape, except for the quill pulley bearings that get fairly noisy when I tension the belt. I thus decided to take everyhting apart, clean it thoroughly, remove the rust, and replace all the bearings. You know, just in case.

Some more details (in French, sorry) in my post on the forum of Copain des Copeaux.
Also, more pictures available here.

An End-Grain Cutting Board

2015-10-01T20:00:00+02:00

For my father's 60th birthday, I made an end-grain cutting board.

It's made out of walnut and maple and took me some serious hours of work!

Pictures are here if you want to see the making of, but don't expect a real build log. Some steps are unfortunately missing.

And in case you were wondering, yes, he liked it very much!

Parcels arrived

2014-09-22T18:00:00+02:00

Today, two parcels arrived.

The first one is a hard cover copy of The 8088 Project Book by Robert Grossblat. It seems that it is a reference on the subject, I'm eager to start reading it. Stay tuned for more Bidule88 posts in the future!

The second one is much lighter, it is a t-shirt from Qwertee that is absolutely cute and geeky. I'll update this post with a picture as soon as I can.

Bidule88 Part 02: It runs!

2014-09-18T21:40:00+02:00

First achievement with Bidule88: it is actually running some code that I've written and uploaded into its EEPROM! Here is the result:

The parts are connected as described on Homebrew8088 except that the EEPROM I used is bigger. Not that it is needed, though, the code is only a few bytes...

The 74hc373 on the left will latch the value written to any I/O port, it simply ignores the address.

What surprised me was how few loops I had to do for a 1 second delay between the counts. Clearly, that CPU isn't fast, and some instructions need a lot of cycles.

Next time we will start playing with a small LCD. Having some correct feedback will definitely ease debugging.

Bidule88 Part 01: Introduction

2014-09-08T21:00:00+02:00

Several months ago, while casually browsing the web from link to link, I ended up on the Veronica project page. I've played with computers for some years now, but never thought I'd ever be able to actually make one. That is, until I read Quinn's posts. Granted, she uses a 6502 instead of a 8088, but that can't be that different, can it ?

So I started to think about it, and after having read a lot of documentation and countless web pages, I was finaly confident that I could do... Well, that I could do something that could be called a computer without stretching the definition too much. With that in mind, I went to Ebay and ordered components from a dozen different sellers. The majority of them has now arrived but I'm still waiting for a few parcels to show up.

These days, whenever I've got some free time, I go back to my breadboard, or cut and strip some left over twisted-pair network cable, and try to add another element to the project. It is fairly clear in my mind where I'm heading to, and the steps I need to make to get there are quite well defined. We'll see how it turns out! In any case, that will be a nice opportunity to learn new things (new for me at least, as some of them were already pretty much obsolete 10 years ago or more).

As I forsee it, most of my design will be compatible with the original IBM PC, except for the graphics card, if I ever get that far. I don't rule out the possibility that an off-the-shelf VGA adapter could be plugged in an ISA slot, though.

The next part will be about the components I (intend to) use in this project.

Carbonnades de dindonneau à la Kriek

2010-02-08T22:07:00+01:00

(Ceci est une republication d'un billet posté précédemment sur mon défunt blog)

Voilà la recette complète du plat que j'ai servi aux amis français (et au belge) pour le souper de la veille du FOSDEM. Oui, parce que chez nous, le repas du soir s'appelle le souper.

Ingrédients

Note: les ingrédients sont donnés pour trois personnes.

600g de carbonnades de dindonneau
1 Kriek (Lindemans, 37cl)
4 ou 5 échalottes, peuvent être remplacées par 2 oignons
200g de chataignes cuites au feu
1 grosse cuillère à soupe de gelée de pommes
1 cuillère à soupe de farine
3 pommes (Golden, qui tiennent à la cuisson)
beurre
thym, sel, poivre

Préparation du plat

Couper les échalottes en morceau et les faire revenir dans la casserole avec la viande, sur un beau filet d'huile d'olive. Lorsque l'extérieur des morceaux de viande est cuit, ajouter la farine et faire encore revenir quelques minutes en mélangeant bien.

Verser la Kriek et un peu d'eau (au pif, entre 5 et 15cl, je ne sais pas trop :p ). Ajouter le thym, saler et poivrer. Porter à ébullition, puis laisser mijoter 45 minutes.

En fin de cuisson, ajouter la gelée de pomme et les chataignes. Si les chataignes sont emballées dans du plastique sous vide, il vaut mieux les chauffer au bain-marie préalablement. Dans le cas contraire, laisser mijoter pour qu'elles atteignent la bonne température.

Peler et couper les pommes en douze quartiers. Faire dorer les quartiers à la poêle dans du beurre.

Servir avec des pommes-de-terre fermes (charlottes, nicolas, ...) et bien sûr, une Kriek !

Bon appétit.

Une petite recette de pâtes pas du tout diététique

2008-08-21T21:13:00+02:00

(Ceci est une republication d'un billet posté précédemment sur mon défunt blog)

Rien que le titre, ça donne envie, vous ne trouvez pas ?

Pour la petite histoire, c'est une recette que j'ai goûtée au café/resto le Onlywood, à Louvain-la-Neuve. J'ai tellement aimé que je me suis senti obligé d'en manger aussi à la maison !

En avant pour les ingrédients. Les quantités sont absolument approximative, et c'est donné pour une personne :

100g de lardons allumette ;
250ml de crème fraîche (ouais, par personne) ;
une belle grosse cuillère à soupe de miel (liquide) ;
vinaigre balsamique ;
mozzarella râpée ;
et bien sûr, des tagliatelles.

Dans une poêle large, faire revenir les lardons à feu vif sans oublier de les tourner, jusqu'à ce qu'ils prennent une belle couleur foncée qui indique qu'ils sont prêts.

Retirer tout liquide qu'ils auraient pu dégorger (ah! saleté de viande aux hormones pleine de flotte) et déglacer avec une grosse cuillère à café de vinaigre balsamique. Attention, surtout ne pas mettre trop de vinaigre, sinon il va sauvagement faire tourner la crème, et je vous assure que c'est mauvais (expérience n° 1... peu concluante). D'un autre coté, s'il y en a trop peu, ça ne colorera pas assez et ce sera moins joli.

Ajouter la crème et le miel dans la poêle, bien mélanger le tout et faire réduire lentement, mais longtemps. Très longtemps. Vraiment longtemps. Jusqu'à obtention d'une sorte de pâte gluante, collante, plutôt bien colorée.

Recouvrir de ce slime aux grumaux les tagliatelles que vous n'aurez bien sûr pas oublié de faire cuire pendant que ça réduisait sagement et couvrir avec la mozzarella râpée.

Bon appétit, et bon régime !

Ah, et si vous avez une idée pour une verdure capable d'accompagner un tel monstre, je suis tout ouïe. Généralement, après un truc pareil, je me sens juste la force d'avaler quelque chose comme une demi feuille de salade.