Described how to install Quartus, but it was only a step towards the task. In order to make sure that FPGA and the programmer is working, the first one had to be flashed.
It turned out that this can be done in two ways, the first is through JTAG interface, in this case the configuration information is sewn directly to the FPGA. The disadvantage of this method is that FPGA memory is volatile and the firmware needs to be loaded into the FPGA every time after power up.
The way out of this situation suggests itself and it consists in the fact that place a memory chip next to the FPGA and load the firmware from it every time after power is applied. The only thing worth adding is that the firmware is not stored in an ordinary flash drive, but in a special microcircuit - sequential configuration ROM. At Altera are microcircuits of the series EPCS or EPCQ, programmable by interface Active Serial. This is the second way, its meaning is to program the serial configuration ROM chip, and after power is applied, the FPGA subtracts the firmware from it.
But here another question arises, does it turn out that a separate connector is needed to program the serial configuration ROM chip?
It turns out that the FPGA developers took care of this and the FPGA can act as an intermediary between the interfaces JTAG And Active Serial. That is, she receives the firmware by JTAG interface, and writes it to ROM using Active Serial. With the theory sorted out and you can begin to practice.
At my request, the seller sent me a debug board diagram and a few simple projects by mail. In one of the projects, a file was found with the extension .sof, which is necessary for the firmware.
In order to flash the FPGA by jtag necessary:
In the same folder where the .sof file was taken from, a file with the extension .pof. Files with this extension must be flashed by connecting directly to the ROM, but I wanted to flash the board without unnecessary gestures through jtag. To do this, it was necessary to obtain a file with the extension from the .sof file .jic.
To convert a .sof file to .jic, you need:
7 / 8 121
print version
RAM-related faults occupy an "honorable" niche among the various reasons for the inoperability of Spectrums. Memory chips are relatively unreliable and prone to burnout (especially if there are power problems). And especially if the power source of the Spectrum transformer. How many times has it been noticed on my Leningrad-1 computer with a transformer power supply - you accidentally short-circuit the computer's power supply (+ 5V and ground), and one or two KR565RU5 microcircuits have already "taken off".
As a rule, the memory chip burns completely. Those. not that one bit does not work in it, but in general the entire microcircuit stops working. The Spectrum's memory is organized in such a way that each RAM chip is responsible for its own bit of memory (for a 48K Spectrum, these are 8 chips of one bit each, for a total of 64KB of addressable memory). When the computer starts, the ROM performs its own memory test, and if any RAM cell "fails", the computer sets the limit of available memory to the address of the cell previous to the faulty one. In this case, the value of the limit of available memory is set in the P_RAMT system variable (it is located at addresses 23732-23733 in RAM. In a healthy computer, the value of this system variable will be #FFFF (that is, the numbers 255 will be written in both memory cells). If the system variable contains a number that is not equal to #FFFF, for example, if there is #F000, then this means that the memory cell #F001 is already defective.
All this is very good, but only if the detected defective memory cell is not at the beginning of the available RAM. The fact is that BASIC-48 also requires some available good memory. And if a memory defect is detected at the beginning of the RAM, then BASIC simply will not start, and we will not be able to find out anything. In the event that one of the RAM chips burned out completely, the computer will not start BASIC.
Then there are only "dances with a tambourine" to find what actually burned down. Applicable to memory chips, you can try a primitive, but sometimes useful diagnostics. The fact is that a defective memory chip (KR565RU5) may differ in temperature from other working microcircuits. During operation, the KR565RU5 RAM heats up. If you put your finger on the RAM chips, you can feel that the chips are noticeably warm. A faulty microcircuit can heat up like an iron, or it can even be cold. This will not necessarily be the case, but this method can be remembered and applied on a case-by-case basis.
In general, in the production of Spectrums, the rules of good form are the installation of a ROM chip and a processor on the panels. This makes life a lot easier when repairing a computer. In this case, we are interested in a ROM chip. In the "ancient" Spectrums produced in the late 80s (early 90s), as a rule, two ROM chips were installed. This is dictated by the fact that it was not so easy to get a ROM chip with a volume of 16K (bourgeois name 27128) at that time, so it was easier and cheaper to replace it with two microcircuits with a volume of 8K each, since they had a domestic analogue KR573RF4, KR573RF6. And usually one of the microcircuits (usually it is ROM-0) was placed on the socket. Why ROM-0? Because The ROM is assembled on two microcircuits, its address space is divided into two parts. The total amount of ROM is 16K. Therefore, the first 8K are considered as ROM-0, and the second 8K are considered as ROM-1. When the computer starts, the processor starts executing the program located at address #0000, and this is exactly the area addressed by ROM-0.
So yes, we really need at least one ROM to be on the socket. If there is generally one ROM on the socket on the computer board, this is also very good. The thing is that the ROM can be removed and replaced with your own ROM, in which the memory test is "flashed". Then, when the computer is turned on, the memory test we need will be launched, which will clearly show what is happening with the memory in the computer.
A very, very long time ago, when I didn’t have a ROM programmer yet, I had to go to the radio market and there harsh guys for the appropriate bribe would flash anything into the ROM. They also had memory tests for Spectrums. Yes, it was a good time...
So, having bought the treasured flashed ROM chip, you could test your computer. However, first it was necessary to solve the question - how to correctly insert the ROM into the socket? The fact is that the ROM test is flashed into a 2K chip. It has 24 pins. The Spectrum uses 28-pin ROMs. In this case, pins 21 and 24 were raised from the microcircuit with the test and combined as follows:
Such a microcircuit is inserted into the socket as shown in the photo:
I think it's clear in the photo. Pin 12 of the ROM (GND) must match pin 14 in the socket. And the protruding output of the test ROM should fall into the 28th contact of the socket (power + 5V).
You can not disfigure the ROM, but make a riser. From above we put a socket for 24 pins for a test ROM, from below there are pins for installing the board into a 28-pin socket in a computer. All required changes in the connection of 21 and 24 ROM pins can be made directly on such a board:
In my practice, I often use the following test firmware:
As the name suggests, it tests 48K of RAM. It works very slowly (about 12 minutes). First, the screen attributes are cleared, then the screen is painted over and cleared in turn, then the results of the RAM test are shown. After that, there is a ROM test, but it always ends with an error, but for us this does not play any role. The main thing is to check the RAM.
ATTENTION!
This test has one "trick" - if you hold a space at the start of the test, then the graphic part with the attributes filled in is skipped and the RAM test begins directly. A check for a pressed space is done at the moment when the enumeration of the border colors at the beginning of the test ends.
Passing the test, if one of the RAM chips is faulty, can be seen in the first issue of Byte Tales #01:
BYTE Tales #01 - We repair the computer "Byte"
I'm not entirely satisfied with the 48K memory test from the previous section of the page, so when I had free time and desire, I disassembled this test and, based on it, "cut down" my version, in which I tried to implement my "Wishlist".
As a result, I got a slightly more advanced memory test, in which I added several memory testing algorithms, threw out the extra code from the test (there is enough of it), and also made a "jammer" of the synthesizer on the KR580VI53 in case the test was used on the "Byte" computer.
You can download the test firmware along with all the sources for iS-DOS (the test is written in iS-Assembler) at the end of this page.
The peculiarity of the test is that it does not display text on the screen - all information about the health of the RAM is displayed as lines on the border. This can be useful in case of complete inoperability of the RAM, when nothing will be visible when displaying text on the screen, and the lines on the border will be perfectly visible (output of information to the border does not depend on the operability and availability of RAM in general).
After the end of the test, 8 white stripes are displayed on the border, symbolizing 8 bits of RAM. The first bar from the top shows the health of the D0 bit, the second - D1, the third - D2, etc. In the case of a healthy corresponding bit of RAM, the band will be narrow:
In the case of a bad bit, the bar will be twice as wide:
The disadvantage of the test is to check only the first 16K of RAM (at addresses #4000-#7FFF). However, this is easily fixed by changing the test source.
The test takes place in 4 stages (filling and checking for bytes #00, #FF, #55 and #AA). If desired, you can add to the source text and other options for checking RAM.
As an example, I finalized the test to check the entire amount of 48K RAM, and also inserted the KR580VI53 jamming procedure for the Byte computer into the source code. Firmware of two variants of the test and source code can be downloaded at the end of this article.
This test allows you to quickly check the memory in the 128th ZX-Spectrum.
How the test passes on a working computer can be seen in the following video:
There should be a video here, but it won't work unless you enable JavaScript for this site
After a message about a successful ROM test, a loop occurs, you can ignore this.
When working on some computers with a connected drive controller may experience glitches during the test. The fact is that when the drive controller is connected, a refinement is made that prohibits the selection of any ports during the operation of the controller. For example, as it is recommended to do when connecting the C-48 controller to the ZX-Spectrum:
The wire leading from the /IORQ output of the processor to the computer circuit is broken, and a logical element switching the /IORQ signal is included in the gap.
This is done in order to disable possible computer ports that conflict with the ports of the drive controller. First of all, this is a port of the Kempston joystick. However, no one will look for a specific computer model for what may conflict with the drive controller, therefore it is easier to disable access to ports altogether at the time the drive controller is working.
Second point: again some computers modified in this way will immediately launch TR-DOS upon reset. This is done so that every time from under BASIC you don't have to type the RANDOMIZE USR 15616 command to start TR-DOS.
Third point: again some computers, the BASIC ROM is combined with the TR-DOS ROM in one chip. For example, as in this computer Leningrad-1:
Microprogram automata represent the next step in increasing the complexity of the intelligence of digital circuits. On the basis of microprogram automata, it is possible to build devices that operate according to rather complex algorithms, perform various functions determined by input signals, and issue complex sequences of output signals. At the same time, the algorithm microprogram machine can be easily changed by changing the ROM firmware.
Unlike the previously considered devices based on "hard" logic, the principle of operation of which is uniquely determined by the elements used and the way they are connected, microprogram automata using the same circuit can perform a variety of functions. That is, they are much more flexible than "hard" logic circuits. Moreover, design microprogram automata From a schematic standpoint, it's pretty simple. The disadvantage of any microprogram machine compared to circuits based on "hard" logic, there is a lower maximum speed and the need to compile a ROM firmware map with firmware are often quite complex.
Most common structure microprogram machine(Fig. 11.15) includes only three elements: ROM, a register that works on the edge, and clock generator.
Rice. 11.15.
ROM has (L+M) address bits and N data bits. The register is applied with the number of digits (N + L). ROM data bits are written to the register on a rising edge clock signal from the generator. Some of these bits (M) are used to form the ROM address, the other part (N-M) is used to generate output signals. The input signals (L) are fed to the inputs of the register and are used in conjunction with a part of the output ROM bits to obtain the ROM address.
The scheme works as follows. In each cycle, the ROM issues a data code, thereby determining not only the state of the output signals of the circuit, but also the ROM address, which will be set in the next cycle (after the next positive edge clock signal). This next address is also affected by input signals. That is, unlike the signal sequencer discussed in the previous section, in this case, the addresses can be sorted out not only sequentially (using a counter), but also in an arbitrary order, which is determined by the ROM firmware, called firmware.
The condition for the correct operation of the circuit will be the following. For one period clock signal the register and ROM must have time to work. In other words, the sum of the register delay and the ROM address fetch delay must not exceed the period clock signal. Note also that the input signals microprogram machine cannot be applied directly to the address inputs of the ROM (without a register), since their asynchronous (with respect to the clock signal) change can cause a transient process at the ROM data outputs at the very moment when the ROM output signals are written to the register. As a result, incorrect information may be written to the register, which will disrupt the operation of the entire circuit. The register, on the other hand, synchronizes changes in input signals with the clock signal, as a result of which all bits of the ROM address code change simultaneously - on a positive edge clock signal. The register must necessarily operate on the front, the use of a latch is not allowed, as it can cause an avalanche transient.
The possibilities of such a simple scheme are very large. For example, microprogram machine can produce sequences of output signals in response to a certain change in input signals. It can also temporarily stop producing output signals before input signals arrive. It can analyze the duration of the input signal and, depending on it, produce certain output signals. He can also do many other things.
Let us formulate several elementary functions that can form the algorithms of the microprogram automaton (Fig. 11.16):
As an example, consider the execution of some elementary functions firmware automaton shown in fig. 11.17.
The ROM has a 64x8 organization (it can be two PE3 chips or one RT18 chip), the number of register bits is ten (it can be two IR27 chips). The circuit has two inputs and four outputs. Such an organization microprogram machine the good thing is that its firmware (that is, a ROM firmware map) is very visual, easy to compose and read.
| Address | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | A | B | C | D | E | F |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 00 | FF | FF | FF | FF | FF | FF | FF | FF | FF | FF | FF | FF | FF | FF | FF | FF |
| 10 | FF | FF | FF | FF | FF | FF | FF | FF | FF | FF | FF | FF | FF | FF | FF | FF |
| 20 | FF | FF | FF | FF | FF | FF | FF | FF | FF | FF | FF | FF | FF | FF | FF | FF |
| 30 | FF | FF | FF | FF | FF | FF | FF | FF | FF | FF | FF | FF | FF | FF | FF | FF |
The output bits of the ROM data are divided into two groups of 4 signals: the lower ones go to form the next ROM address, the older ones form four output signals. The input signals are received (through the register) to the two most significant bits of the ROM address. If we depict the ROM firmware map in the usual form of a table of four rows and 16 columns (Table 11.7), then in this table both the state of each of the internal signals and the reaction of the circuit to any input signal, as well as the states all output signals in each cycle.
First of all, it is easy to see that the choice of one or another row of the table is made by the upper digits of the ROM address code, that is, by the input signals microprogram machine. Thus, any change in the input signals leads to a transition in the firmware map to another line. For example, line 00 will match zero inputs microprogram machine, and line 30 is for single inputs.
| Address | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | A | B | C | D | E | F |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 00 | 11 | 22 | 33 | 44 | 55 | 66 | 77 | 88 | 99 | AA | BB | CC | DD | EE | FF | 00 |
| 10 | 11 | 22 | 33 | 44 | 55 | 66 | 77 | 88 | 99 | 55 | BB | CC | DD | EE | FF | 00 |
| 20 | 10 | 21 | 32 | 43 | 54 | 65 | 76 | 87 | 98 | A9 | BA | CB | DC | ED |
programmer- a hardware-software device designed to write / read information into a permanent storage device (writable once, flash memory, ROM, internal memory of microcontrollers and PLCs).
programmer- a device that enters the information necessary for operation into programmable non-volatile digital circuits, such as PROM (ROM), EPROM (EPROM), EEPROM (EEPROM), flash, PAL, gal, FPGA And microcontrollers. The recording process is often referred to as "", "", "", "".
"Flash ROM"- write information to ROM.
Back when computers were big, from the mid-1950s to the mid-1970s, computers used magnetic core memory. Such memory was used both as RAM and as ROM. In the manufacture of the ROM, the wire either passed through the ring or bypassed it. The wire was passed through a ferrite ring using a special needle. That is "stitched" memory matrix in the literal sense. Therefore, this process is quite naturally assigned the definition "flash ROM". In order to get it right "flash", created a technological document "firmware card" in which it was indicated through which rings to pass the wire, and through which not. Memory on ferrite cores is a thing of the past, however, the term "flash" And "firmware" in relation to the process of writing to ROM is still used. And the word "firmware" used as a verb in relation to the process of entering information into the ROM, and as a noun in relation to the information or file itself being entered.
Unlike semiconductors, magnetic cores are not afraid of radiation and electromagnetic radiation, and, therefore, magnetic core memory continued to be used in military and space systems for some time. It is authentically known that it was used in the on-board computers of the Shuttle until 1991. Perhaps such memory is still used in some older systems. At present, semiconductor memory resistant to special effects has already been developed, and the era of magnetic cores is gone, but the term "firmware" remained.
"Burn ROM"- Entering information.
The memory on ferrite cores was replaced by semiconductor RAM memory, and microcircuits with matrices of metal, more often nichrome, jumpers inside began to be used as ROM. To enter information into such microcircuits, extra jumpers must be burned with a current pulse. Subsequently, jumpers began to be used not only from metal, but also made of semiconductors, in the form pn junction or polysilicon, but the principle of physical destruction of the jumper or breakdown of the junction by
the impact of the current pulse was preserved. In military and aerospace systems, such ROMs are still used today. All ChipStar programmers for special purpose chips are precisely "burn through" such ROMs.
In consumer and industrial applications, where requirements for environmental resistance are lower, and the requirements for cost and memory space are higher, fusible jumper chips have been supplanted by electrically programmable EPROM chips and electrically reprogrammable EEPROM ROM chips, and, more recently, by microcircuits on based on FLASH. With the change in technology, the terminology has also changed: more often they began to talk about ROM "writes", or "loading", and the term is more often used in relation to the internal ROM of microcontrollers, and "record" is more often used in relation to stand-alone memory chips.
"ROM or microcontroller programming"- Entering information into ROM or microcontroller.
Term "programming" also very often applied to the process of writing to ROM. And, if in relation to ROM it is always perceived unambiguously, then in relation to microcontrollers there is an ambiguity: "Program the microcontroller" can mean both writing a ready-made program code (image) into the ROM of the microcontroller using a hardware device (programmer, download cable), and the process of developing the program itself.
You will say that it is so easy to get confused in all this terminology, and you will be absolutely right. But in the English-speaking environment, everything is no better! Not only are they all the same "burn" ("burn"), "downloads"("download"), "record"("write"), so also the terms "programmer"- the person who develops the program and "programmer"- the device that writes this program to the microcircuit is designated by one word: "programmer".
