How we held a hardware hack contest at Chaos Constructions 2015
Hello!
This weekend in St. Petersburg, the next Chaos Constructions festival was held, which brought together fans, programmers and developers to compete in the skill of creating demo.
You can read about the demo on the website of the organizers . And if in brief, the participants are given the task to do something impressive on the spectrum or similar retro-hardware, and at the same time set limits on the size of the programs and the duration of the demo. For example, I was very impressed with this one on the Spectrum, which fit just 256 bytes ! Yes, the demo is displayed on a big screen with a great sound, so the spectacle is impressive!
')
Our company sponsored the festival, and my colleagues and I organized and held a hardware hack competition, the goal of which was to determine the processor architecture, with a minimum of knowledge about it and a modest set of tools.
About how the competition was held, how and what we prepared for it and there will be my article. Who cares, I ask under the cat.
So, the aim of the hardware hack competition was to determine the processor architecture, with a minimum of knowledge about it and a modest set of tools. After the architectural excavations, it was necessary to make changes to the original program or program something different. In the end, estimated time spent and the wow factor of what happened.
An important caveat - in the hands of "players" should have got some piece of iron (and, better than retro), and not the usual comp. And, as they say, "use what is at hand, and do not look for something else for yourself." So we took the motherboard from our device Berkut-ET , did some work on the file (as well as a little bit on the cutter, screwdrivers, etc.) and instead of the usual device we got a cool gadget:
On the reverse side (the interface board, where there is 1G ethernet and FPGA, we did not connect):
On board the board is quite old-school stuffing (in fact, the new Bercut-ET already has a more modern, ARM marketing platform):
Since before the controllers did not have such a developed periphery as now (plus we didn’t know something many years ago), we got everything we could on the FPGA, and then we programmed interfaces at our discretion. So on the periphery of the FPGA got LCD, LEDs, keyboard.
AVR resources are very limited - he already has a million measurement management tasks, etc. things. Therefore, the FPGA has a graphics controller. Own, withpreference and professional mesh frames and Brezenham lines, as well as rectangles, sectors, circles, sign-generator (three sizes of characters + spread) and even dotted lines. This controller allows you to display graphics on the screen almost at lightning speed, because it, unlike AVR, operates at 50 MHz. For example, such a picture appears in a split second:
However, with all the wealth of functions there is one bottleneck - the memory capacity of the framebuffer. Enough for only 8 colors. Therefore, for each pixel, 3 bits are used, which are neatly packed into bytes for optimal memory usage.
The situation is similar with the keyboard: FPGA generates pulses to the matrix and tracks keystrokes, while the processor takes only the interrupt and the status register of the pressed buttons. And with diodes - the processor writes to the FPGA register, and the register outputs are already connected to the diodes.
Architecture (enlarged) is:
But something I became interested in architecture. I just wanted to give an idea about the exhibits, so that they were not a black box for the reader.
Thus, we already had a piece of iron with all the necessary I / O peripherals for holding a competition (as many as five), and it was quite suitable for the format.
As planned, we had to provide for the "excavation" a processor, whose architecture is not known to the participants beforehand. In practice, this meant that we had to give a tool that would allow us to study memory, variables, stack, etc. and experiment with changing its contents and, therefore, the algorithm. Giving a debugger for AVR seemed too cumbersome and a dreary decision - after all, it took only 3 hours to dig, and I didn’t really want to connect to each board with a debugger and computer ...
And then we decided to write our lightweight stack interpreter, which, in addition to working with the stack and mathematical / logical operations, would be able to display graphic primitives on the screen, squeak and “light” the LEDs. Why exactly stack? It seemed to us rather simple, and besides, it was just interesting to try to do something like Forth, but with a limited set of commands, but also a transparent interface for expanding the system of commands.
Well, for the "tinkering" in the memory decided to write a debugger. What is there to grind: do, so in an adult;)
I did not plan to talk in detail about the stack interpreter in this article (let me know, I will write a separate article with all the details, code and compiler). Limited to a brief excursion.
The stack interpreter reads the program memory and, depending on the operation code, performs certain actions on the top of the stack. As a rule, 1-2-3 is taken from the top of the stack, rarely 4 values ​​(and generally, as many as you like) and the result of the operation is put back on the stack. This architecture is very simple to implement, and not only programmatically.
At the same time, the program looks somewhat unusual, because there is no “familiar” record (instead, the reverse Polish one is used). For example, to sum up two numbers, you must perform two operations “put a number on the stack”, and then the operation “sum”. As a result, the result of summation will be at the top of the stack, and two operands from the stack will be removed. In short, the brain needs a little break.
For our interpreter, we took the most necessary set of commands (a total of just over 20):
Such a set makes it possible to organize cycles, conditional transitions, increments of counters and other essential construction. From the definition of functions (as in FED) we refused
right away so as not to complicate. Variables also did not implement, as it turned out - in vain.
At first they wrote an interpreter in C for a regular Linux machine. At the same time, a “compiler” in python appeared, which translates text commands into bytecode.
When with the interpreter (by the way, they called it funfte, since forth is “fourth”, and the English “fifth” is already taken under another interpreter) everything became clear, it only remained to develop a debugger, and then put everything together.
This is what we did (do not forget that for the participants everything should be as confusing as possible, so there can be no signatures on the screen itself), schematically:
Due to the fact that funfte has only two memory areas - software and stack, two columns automatically appeared in the debugger. In the first - a printout remembering programs, and in the second - the stack. The PC is displayed at the bottom right, and the input line at the bottom allows you to enter write and read memory commands from the built-in keyboard, as well as manage breakpoints and listing.
All numbers, of course, in hex.
Controlling the debugger and entering commands was moved to the buttons:
And our debugger taught the most necessary:
As a result, when everything was encoded and transferred to the AVR (of course, they used all the developments from the “native” project, including the keyboard, diodes, LCD-controller and a lot of ready-made objects), they wrote a simple example on the resulting language, which “sets fire” in the cycle diodes, displays the line "DEMO" and causes the green cube to run across the screen from left to right and back.
Cheers, Earned! And here is how it looks in interactive
On Saturday, August 29, with five stitched devices, we arrived at chaos construction and located in the hack space zone.
What pleased us: we didn’t even have time to wait for the official start of our competition, because our mysterious devices fell into the hands of burned-out memory-diggers.
My colleagues and I were very afraid that we came up with something too complicated and no one could figure it out. And, fortunately, made a mistake! Within ten minutes, one of the participants was able to change the color of the displayed rectangle and ran a whisper about “stack”, “fort” and the like.
An hour later, the rectangle, which was supposed to move from left to right and back, changed its behavior (not itself, of course, but with the help of one of the contest winners). To do this, it was necessary to reverse the list of commands, understand the algorithm in the cycle where the rectangle changes the X coordinates, change the Y coordinate.
Moreover, hackers already had a complete list of commands of our mega-processor on the tables, including (attention!) Even those commands that were not used in the example.
At the next call, after two hours of excavation, we were given a device in which a program of only 16 bytes was stitched(, Karl) ! In the overall standings, this work won first place.
And here is another interesting work:
The result of the first day: more than ten people participated, almost everyone managed. Fine!
Well, the next day we decided to change the task a bit.
Now the participants were open the whole system of commands and, what is already there, the interpreter code. It was necessary to write something impressive. And again, the result exceeded expectations: after a couple of hours, I already had a pull request for 4 new commands for the interpreter in github that allowed me to access any stack and memory cell. Those. in fact, it was possible to declare variables. They certainly did not have a name, it was necessary to remember their address, but still.
After the merge, building and uploading the firmware, we have a new demo that changes its own code during execution. She took 52 bytes and second place in our competition.
Also on the second day we were helped to find and fix a few bugs, for which we thank all the participants!
At the end of the day, at the official closing of the festival, we presented prizes to the winners.
Prizes, of course, also made with their own hands
What I would like to say in conclusion. Thanks to the organizers of the festival for the cool, driving event, for the opportunity to participate in it and for the pleasure of communicating with people who are really enthusiastic. Thanks to everyone who participated in our competition: we were very pleased to see that we did not try in vain. Of course, the interpreter in this form is not very practically useful, but allows you to escape from high-level programming, in which 90% of the interesting details are hidden from the developer, and to practice a little memory and attention, as well as learn something new and have fun.
And, of course, I thank my colleagues for the teamwork in preparing for the competition.
PS: we made one big omission: we didn’t do full beeper management. We gave the opportunity to manage only the duration, but it was also necessary to lay the frequency control. Then the demos could be with music. Well, nothing, next year we catch up!
This weekend in St. Petersburg, the next Chaos Constructions festival was held, which brought together fans, programmers and developers to compete in the skill of creating demo.
You can read about the demo on the website of the organizers . And if in brief, the participants are given the task to do something impressive on the spectrum or similar retro-hardware, and at the same time set limits on the size of the programs and the duration of the demo. For example, I was very impressed with this one on the Spectrum, which fit just 256 bytes ! Yes, the demo is displayed on a big screen with a great sound, so the spectacle is impressive!
')
Our company sponsored the festival, and my colleagues and I organized and held a hardware hack competition, the goal of which was to determine the processor architecture, with a minimum of knowledge about it and a modest set of tools.
About how the competition was held, how and what we prepared for it and there will be my article. Who cares, I ask under the cat.
So, the aim of the hardware hack competition was to determine the processor architecture, with a minimum of knowledge about it and a modest set of tools. After the architectural excavations, it was necessary to make changes to the original program or program something different. In the end, estimated time spent and the wow factor of what happened.
An important caveat - in the hands of "players" should have got some piece of iron (and, better than retro), and not the usual comp. And, as they say, "use what is at hand, and do not look for something else for yourself." So we took the motherboard from our device Berkut-ET , did some work on the file (as well as a little bit on the cutter, screwdrivers, etc.) and instead of the usual device we got a cool gadget:
On the reverse side (the interface board, where there is 1G ethernet and FPGA, we did not connect):
A little bit about architecture and board interiors
On board the board is quite old-school stuffing (in fact, the new Bercut-ET already has a more modern, ARM marketing platform):
- AVR ATmega256 8 MHz + as many as 40 kilobytes of memory (the external chip is connected to 32, and the built-in 8) and 256K programs!
- FPGA Cyclone II, connected to the AVR via a parallel bus (separate chip select), 5000 logic cells
- LCD 320x240, operating in eight-color mode (see below), connected to FPGA
- matrix keyboard connected to FPGA
- 8 LEDs
- beep'er
- ftdi USB to uart converter
Since before the controllers did not have such a developed periphery as now (plus we didn’t know something many years ago), we got everything we could on the FPGA, and then we programmed interfaces at our discretion. So on the periphery of the FPGA got LCD, LEDs, keyboard.
AVR resources are very limited - he already has a million measurement management tasks, etc. things. Therefore, the FPGA has a graphics controller. Own, with
However, with all the wealth of functions there is one bottleneck - the memory capacity of the framebuffer. Enough for only 8 colors. Therefore, for each pixel, 3 bits are used, which are neatly packed into bytes for optimal memory usage.
The situation is similar with the keyboard: FPGA generates pulses to the matrix and tracks keystrokes, while the processor takes only the interrupt and the status register of the pressed buttons. And with diodes - the processor writes to the FPGA register, and the register outputs are already connected to the diodes.
Architecture (enlarged) is:
But something I became interested in architecture. I just wanted to give an idea about the exhibits, so that they were not a black box for the reader.
Thus, we already had a piece of iron with all the necessary I / O peripherals for holding a competition (as many as five), and it was quite suitable for the format.
And what will reverse engineer'it?
As planned, we had to provide for the "excavation" a processor, whose architecture is not known to the participants beforehand. In practice, this meant that we had to give a tool that would allow us to study memory, variables, stack, etc. and experiment with changing its contents and, therefore, the algorithm. Giving a debugger for AVR seemed too cumbersome and a dreary decision - after all, it took only 3 hours to dig, and I didn’t really want to connect to each board with a debugger and computer ...
And then we decided to write our lightweight stack interpreter, which, in addition to working with the stack and mathematical / logical operations, would be able to display graphic primitives on the screen, squeak and “light” the LEDs. Why exactly stack? It seemed to us rather simple, and besides, it was just interesting to try to do something like Forth, but with a limited set of commands, but also a transparent interface for expanding the system of commands.
Well, for the "tinkering" in the memory decided to write a debugger. What is there to grind: do, so in an adult;)
A little about the stack interpreter
I did not plan to talk in detail about the stack interpreter in this article (let me know, I will write a separate article with all the details, code and compiler). Limited to a brief excursion.
The stack interpreter reads the program memory and, depending on the operation code, performs certain actions on the top of the stack. As a rule, 1-2-3 is taken from the top of the stack, rarely 4 values ​​(and generally, as many as you like) and the result of the operation is put back on the stack. This architecture is very simple to implement, and not only programmatically.
At the same time, the program looks somewhat unusual, because there is no “familiar” record (instead, the reverse Polish one is used). For example, to sum up two numbers, you must perform two operations “put a number on the stack”, and then the operation “sum”. As a result, the result of summation will be at the top of the stack, and two operands from the stack will be removed. In short, the brain needs a little break.
Stack interpreter funfte
For our interpreter, we took the most necessary set of commands (a total of just over 20):
- to work with the stack (push, drop, swap, etc ...)
- for mathematical operations (add, sub, mul, inc, dec, etc ..)
- for conditions and transitions (if, jump, cond. jump)
- and, of course, for output to the screen, to the squeaker and diodes
Such a set makes it possible to organize cycles, conditional transitions, increments of counters and other essential construction. From the definition of functions (as in FED) we refused
right away so as not to complicate. Variables also did not implement, as it turned out - in vain.
At first they wrote an interpreter in C for a regular Linux machine. At the same time, a “compiler” in python appeared, which translates text commands into bytecode.
When with the interpreter (by the way, they called it funfte, since forth is “fourth”, and the English “fifth” is already taken under another interpreter) everything became clear, it only remained to develop a debugger, and then put everything together.
Debugger: only in hex, only hardcore!
This is what we did (do not forget that for the participants everything should be as confusing as possible, so there can be no signatures on the screen itself), schematically:
Due to the fact that funfte has only two memory areas - software and stack, two columns automatically appeared in the debugger. In the first - a printout remembering programs, and in the second - the stack. The PC is displayed at the bottom right, and the input line at the bottom allows you to enter write and read memory commands from the built-in keyboard, as well as manage breakpoints and listing.
All numbers, of course, in hex.
Controlling the debugger and entering commands was moved to the buttons:
- F1 - restart, execute the entered program from the beginning
- F3 - continue
- F4 - next
- Enter - execution of the entered command
- 0..9 - input of numbers and symbols (as on push-button phones)
- X - delete the last character entered (backspace)
- reboot (button on the right, it is not visible on the photo) - reboot the device and get the initial state
And our debugger taught the most necessary:
- execute the program step by step (next): to the F4 button
- set breakpoint: b addr
- remove breakpoint: d addr
- continue execution (continue): to the F3 button
- write value to memory: w addr data
- change program counter: p new-pc-value
- make a listing starting at the address in memory: l addr. The source will be automatically executed from the address p c, if after the command l the program continues.
As a result, when everything was encoded and transferred to the AVR (of course, they used all the developments from the “native” project, including the keyboard, diodes, LCD-controller and a lot of ready-made objects), they wrote a simple example on the resulting language, which “sets fire” in the cycle diodes, displays the line "DEMO" and causes the green cube to run across the screen from left to right and back.
Cheers, Earned! And here is how it looks in interactive
First day of the festival
On Saturday, August 29, with five stitched devices, we arrived at chaos construction and located in the hack space zone.
What pleased us: we didn’t even have time to wait for the official start of our competition, because our mysterious devices fell into the hands of burned-out memory-diggers.
My colleagues and I were very afraid that we came up with something too complicated and no one could figure it out. And, fortunately, made a mistake! Within ten minutes, one of the participants was able to change the color of the displayed rectangle and ran a whisper about “stack”, “fort” and the like.
An hour later, the rectangle, which was supposed to move from left to right and back, changed its behavior (not itself, of course, but with the help of one of the contest winners). To do this, it was necessary to reverse the list of commands, understand the algorithm in the cycle where the rectangle changes the X coordinates, change the Y coordinate.
Moreover, hackers already had a complete list of commands of our mega-processor on the tables, including (attention!) Even those commands that were not used in the example.
At the next call, after two hours of excavation, we were given a device in which a program of only 16 bytes was stitched
And here is another interesting work:
The result of the first day: more than ten people participated, almost everyone managed. Fine!
Second day of the festival
Well, the next day we decided to change the task a bit.
Now the participants were open the whole system of commands and, what is already there, the interpreter code. It was necessary to write something impressive. And again, the result exceeded expectations: after a couple of hours, I already had a pull request for 4 new commands for the interpreter in github that allowed me to access any stack and memory cell. Those. in fact, it was possible to declare variables. They certainly did not have a name, it was necessary to remember their address, but still.
After the merge, building and uploading the firmware, we have a new demo that changes its own code during execution. She took 52 bytes and second place in our competition.
Also on the second day we were helped to find and fix a few bugs, for which we thank all the participants!
Winner's reward ceremony
At the end of the day, at the official closing of the festival, we presented prizes to the winners.
Prizes, of course, also made with their own hands
Small conclusion
What I would like to say in conclusion. Thanks to the organizers of the festival for the cool, driving event, for the opportunity to participate in it and for the pleasure of communicating with people who are really enthusiastic. Thanks to everyone who participated in our competition: we were very pleased to see that we did not try in vain. Of course, the interpreter in this form is not very practically useful, but allows you to escape from high-level programming, in which 90% of the interesting details are hidden from the developer, and to practice a little memory and attention, as well as learn something new and have fun.
And, of course, I thank my colleagues for the teamwork in preparing for the competition.
PS: we made one big omission: we didn’t do full beeper management. We gave the opportunity to manage only the duration, but it was also necessary to lay the frequency control. Then the demos could be with music. Well, nothing, next year we catch up!
Source: https://habr.com/ru/post/265873/
All Articles