Self-made drive emulator for Amiga
Many have preserved Amiga computers at home. But here floppy disks for them were not preserved by everyone. This problem can be solved by assembling a drive emulator. On how to make such a drive emulator for the Amiga, I will discuss in this article.
I thought for a long time where to place this article - here or on geektimes. On the one hand, it concerns the development of microcontrollers, and on the other hand, it will focus on developing a device for a very old computer, the topic of which is geektimes. However, geektimes describe the devices themselves and the programming for them on their API, but here, after all, the device is assembled on an almost modern element base.
Some of the houses still have Amiga computers, someone could just give up such a computer (like me), and someone specifically bought it. And sometimes it happens that there is a computer, but there is no hard drive on it (for example, I don’t have it on the Amiga 500), but I want to run something on it. Messing with floppy disks (which can only be written to a PC using special devices) is not an option. So people choose drive emulators. Now they offer quite a lot, but a few years ago there were almost no such devices. As far as I know, the first Amiga drive emulator made tnt23. It was possible, of course, to buy an emulator from him, but I still wanted to try my hand at creating my own, especially since in trying to start this computer at that time I had already created a simple device for recording floppy disks, and the overall format of the diskette is not represented by The described article was once written for Dogma magazine, but did not get into the issue of this magazine because it was simply forgotten about it. However, I know there are amizhniki here and I think it will be interesting for them to read how you can make your own drive emulator. Perhaps this information will push someone to create their device, much more perfect. So, let's begin.
The drive emulator described below is fairly simple to assemble and does not contain any parts in short supply. The problem can only arise with the search for 30 SIMM contact modules with a capacity of 1 MB. However, such modules were widely distributed and, most likely, they can be found on the radio market. At Juno in St. Petersburg, they certainly were.
')
List of parts for assembly:
The brand of capacitors, diodes, resistors, choke, buttons and SD card holder used does not matter. Diodes are required with a voltage drop at a junction of at least 0.5 V. The display may be with other letter indices.
The emulator is connected to the external drive connector and allows you to play the selected image of a floppy disk. Floppy images are stored in the root directory on an SD card with the FAT16 file system. The files are created by a special ADF file converter program and are byte data of a standard 80 track floppy disk encoded with MFM encoding. No headers such files do not contain. Due to the simplified circuit design, the emulator does not have the hardware ability to switch the drive lines to the Z-state, depending on whether drive A or B is selected. This means that all Amiga drives need to be hardware disabled during operation with the emulator. However, the ability to recognize the address of the drive is theoretically provided by software - this requires that the microcontroller recognizes the address and translates the outputs to the Z-state if the address does not match the desired one. Lines for reading the address of the drive on the diagram are provided, but this possibility is not implemented programmatically.
Emulator scheme (in the archive it is in full quality).
The appearance of the emulator from the display.
Circuitry emulator consists of two parts. Each part is based on an Atmega16 microcontroller. The first part of the microcontroller is engaged in displaying information on the display, processing buttons, reading information from an SD card using hardware SPI, forming part of the drive lines. The microcontroller of the second part deals with the regeneration of the dynamic memory and forms the remaining signals of the drive lines. Both parts exchange information on the SPI bus. For the D2 controller, the SPI bus is used to communicate with the D3 software, while the D3 uses hardware SPI.
Let us consider in more detail the purpose of the elements. Chip D1 provides power to the SD card with a voltage of 3.3 V. Diodes VD1-VD6 reduce the voltage of the SPI lines from 5 to 3.3 V. Resistors R1-R6 and R8-R9 attract the lines to ground. RC-chains R7-C3 and R11-C5 form the initial reset signal of microcontrollers. Elements Z1, C1 and C2 provide 16 MHz generation on the first microcontroller (D2). The second microcontroller (D3) operates in the external synchronization mode from the clock generator of the first microcontroller. Resistor R10 controls the contrast of the image on the display. Elements L1 and C4 provide power supply voltage filtering.
The hardware part of the drive emulator is assembled on a 220x125 mm board. Printing one-sided, performed by any available method, for example, LUT. On the opposite side of the board, you need to put a number of jumpers with wire (indicated by the blue tracks in the enclosed PCB file in Sprint Layout 4.0 format).
The software part of the emulator consists of two programs for microcontrollers. The program for the microcontroller D2 is in the folder MK1, and for the microcontroller D3, respectively, in the folder MK2. After the microcontrollers are flashed with the appropriate HEX file in any way possible (including, for firmware, you can use the “five wires to the computer LPT port” scheme together with the Uniprof programmer program), you need to set the FUSE bits of the controller configuration. Using these bits, you need to disable JTAG in both controllers, switch D2 to clocking from an external 16 MHz crystal, switch on D2 for increased signal amplitude from the output oscillator (CKOPT bit), and switch D3 to clocking from an external source. If your programmer does not have its own clock, the controllers will not be available for programming after this operation. In order for them to become programmable again, you need to connect any external generator with a frequency of several hundred kilohertz to the XTAL1 controllers. Be sure to read them from the controller before modifying the FUSE bits. Note that different programmers interpret the on and off bit differently.
The emulator does not require adjustment after assembly. However, perhaps not all SIMM 30 PIN modules will work with it correctly. For this purpose, in the emulator menu there is an item “MEMORY TESTING”.
To facilitate understanding of the operation of the emulator software, you need to know the following. On a standard diskette, Amiga stores recorded data on 80 tracks on both sides. Each track consists of 11 sectors of 512 bytes. Therefore, the total data volume of a floppy disk is 901120 bytes. This is the volume of ADF-files of floppy images. This file does not contain headers, and the data inside is simply listed as follows: (track 0, side 0), (track 0, side 1), (track 1, side 0), (track 1, side 1) ... (track 79, side 0), (track 79, side 1). Each track is a record of 11 sectors of 512 bytes, starting from sector 0. To emulate a floppy disk such a file in its pure form is not suitable. The fact is that the ADF file stores only useful data without any overhead information and without modulation. Consider how the modulation of the signal in the Amiga computer.
Any drive is nothing more than an analog tape recorder. It does not encode the recorded data. You select a track and modulate the current (and, therefore, the magnetic field strength) through the drive head to record information. When playing in places where the magnetic field strength has changed, the drive reads a short pulse. Amiga uses when writing to floppy disks modified frequency modulation, the so-called MFM (Modified Frequency Modulation). With this modulation method, the change in current through the coil depends not only on the value of the bit being written, but also on the value of the previous bits, as shown in the table below. In the “coded” column, R means a change in magnetization (giving a pulse to a disk drive), and N means that the magnetization does not change. Further, in order to write the MFM file in binary format, we take R equal to 1, and N equal to 0. Two bits of magnetization change are written to the MFM file for one data bit. Thus, the data size of the MFM file compared to the ADF file will be doubled. But you can't just convert ADF to MFM. Amiga uses its own format for writing to floppy disks, which need to be taken into account.
We agree on the track number to name the track number on one of the disc sides (i.e. the track number varies from 0 to 79), and the track number to ((2 * track number) + disc side number). The track number varies from 0 to 159, the disk side number varies from 0 to 1, the sector number changes from 0 to 11.
In Amiga format, each track contains:
Each sector contains:
The identifier and sector data are encoded by permuting the bits. For the identifier, 4 bytes are taken and bits are swapped. The odd bits come first (the numbering of the bits, as usual, with 0) —it will be 2 bytes. Then come the even bits - just 2 bytes. The table illustrates the above. The top line is the standard order of bits (numbers in the cells), the bottom is the result of the permutation.
Sector data is grouped by 2 bytes, and the permutation occurs within this pair in the same way:
The checksum is an exclusive OR (XOR) operation of all bytes of sector data or a header (taking into account the permutation of bits!), Grouped in 2 bytes. The checksum itself is not subject to permutation of bits. Although the field for the checksum is 4 bytes, the checksum itself will be two bytes.
In addition to the 544 bytes of data encoded using MFM coding, each sector contains a special data start marker. A marker is a combination of zeros and ones that cannot be obtained with MFM coding. Such a combination is the combination 01000100100010010100010010001001 before recording of which 4 bytes are written with the combination 10101010. The first byte of the combination 10101010 depends on the previous bit issued by the MFM coding. If the last sector bit issued was 1, then this byte will be 01000100, and if there was 0, then 10101010.
Given all the above, the floppy disk track in MFM format looks like this:
Total, each track in the MFM-coding takes (1080 + 8) * 11 + 128 + 704 = 12800 bytes of code. If now this code is output to the data line from the drive, taking into account the temporary sweep of the track, then Amiga will be able to read the data of this track.
The problem is that the data pulse duration is from 0.15 to 0.8 μs. In this emulator, a pulse duration of 0.5 µs is selected. This means that at a frequency of 16 MHz, we will have 32 clocks per bit of the MFM code. During these 32 clock cycles, the microcontroller D3 must regenerate the dynamic memory, read the MFM code byte, issue a magnetization change bit on the drive line. To meet the 32 clock cycles, this part of the program is written in assembler and strictly aligned with the bars. The byte read and memory regeneration operations are separated in time. This means that as long as the MFM coding byte is issued, for each bit there are 32 clocks and for each output bit it is strictly defined what operations we are performing in these 32 clocks. For example, when issuing bit 0, we can set a dynamic memory string (RAS signal). When issuing bit 1, we can set the dynamic memory column (CAS signal). When issuing bit 2, we read the next data byte issued. And so on. This way, the entire floppy image is issued.
Actually, that’s the simplest drive emulator.
Emulator video:
Archive with printed circuit boards, firmware, diagrams and programs.
I thought for a long time where to place this article - here or on geektimes. On the one hand, it concerns the development of microcontrollers, and on the other hand, it will focus on developing a device for a very old computer, the topic of which is geektimes. However, geektimes describe the devices themselves and the programming for them on their API, but here, after all, the device is assembled on an almost modern element base.
Some of the houses still have Amiga computers, someone could just give up such a computer (like me), and someone specifically bought it. And sometimes it happens that there is a computer, but there is no hard drive on it (for example, I don’t have it on the Amiga 500), but I want to run something on it. Messing with floppy disks (which can only be written to a PC using special devices) is not an option. So people choose drive emulators. Now they offer quite a lot, but a few years ago there were almost no such devices. As far as I know, the first Amiga drive emulator made tnt23. It was possible, of course, to buy an emulator from him, but I still wanted to try my hand at creating my own, especially since in trying to start this computer at that time I had already created a simple device for recording floppy disks, and the overall format of the diskette is not represented by The described article was once written for Dogma magazine, but did not get into the issue of this magazine because it was simply forgotten about it. However, I know there are amizhniki here and I think it will be interesting for them to read how you can make your own drive emulator. Perhaps this information will push someone to create their device, much more perfect. So, let's begin.
The drive emulator described below is fairly simple to assemble and does not contain any parts in short supply. The problem can only arise with the search for 30 SIMM contact modules with a capacity of 1 MB. However, such modules were widely distributed and, most likely, they can be found on the radio market. At Juno in St. Petersburg, they certainly were.
')
List of parts for assembly:
The brand of capacitors, diodes, resistors, choke, buttons and SD card holder used does not matter. Diodes are required with a voltage drop at a junction of at least 0.5 V. The display may be with other letter indices.
The emulator is connected to the external drive connector and allows you to play the selected image of a floppy disk. Floppy images are stored in the root directory on an SD card with the FAT16 file system. The files are created by a special ADF file converter program and are byte data of a standard 80 track floppy disk encoded with MFM encoding. No headers such files do not contain. Due to the simplified circuit design, the emulator does not have the hardware ability to switch the drive lines to the Z-state, depending on whether drive A or B is selected. This means that all Amiga drives need to be hardware disabled during operation with the emulator. However, the ability to recognize the address of the drive is theoretically provided by software - this requires that the microcontroller recognizes the address and translates the outputs to the Z-state if the address does not match the desired one. Lines for reading the address of the drive on the diagram are provided, but this possibility is not implemented programmatically.
Emulator scheme (in the archive it is in full quality).The appearance of the emulator from the display.
Circuitry emulator consists of two parts. Each part is based on an Atmega16 microcontroller. The first part of the microcontroller is engaged in displaying information on the display, processing buttons, reading information from an SD card using hardware SPI, forming part of the drive lines. The microcontroller of the second part deals with the regeneration of the dynamic memory and forms the remaining signals of the drive lines. Both parts exchange information on the SPI bus. For the D2 controller, the SPI bus is used to communicate with the D3 software, while the D3 uses hardware SPI.
Let us consider in more detail the purpose of the elements. Chip D1 provides power to the SD card with a voltage of 3.3 V. Diodes VD1-VD6 reduce the voltage of the SPI lines from 5 to 3.3 V. Resistors R1-R6 and R8-R9 attract the lines to ground. RC-chains R7-C3 and R11-C5 form the initial reset signal of microcontrollers. Elements Z1, C1 and C2 provide 16 MHz generation on the first microcontroller (D2). The second microcontroller (D3) operates in the external synchronization mode from the clock generator of the first microcontroller. Resistor R10 controls the contrast of the image on the display. Elements L1 and C4 provide power supply voltage filtering.
The hardware part of the drive emulator is assembled on a 220x125 mm board. Printing one-sided, performed by any available method, for example, LUT. On the opposite side of the board, you need to put a number of jumpers with wire (indicated by the blue tracks in the enclosed PCB file in Sprint Layout 4.0 format).
The software part of the emulator consists of two programs for microcontrollers. The program for the microcontroller D2 is in the folder MK1, and for the microcontroller D3, respectively, in the folder MK2. After the microcontrollers are flashed with the appropriate HEX file in any way possible (including, for firmware, you can use the “five wires to the computer LPT port” scheme together with the Uniprof programmer program), you need to set the FUSE bits of the controller configuration. Using these bits, you need to disable JTAG in both controllers, switch D2 to clocking from an external 16 MHz crystal, switch on D2 for increased signal amplitude from the output oscillator (CKOPT bit), and switch D3 to clocking from an external source. If your programmer does not have its own clock, the controllers will not be available for programming after this operation. In order for them to become programmable again, you need to connect any external generator with a frequency of several hundred kilohertz to the XTAL1 controllers. Be sure to read them from the controller before modifying the FUSE bits. Note that different programmers interpret the on and off bit differently.
The emulator does not require adjustment after assembly. However, perhaps not all SIMM 30 PIN modules will work with it correctly. For this purpose, in the emulator menu there is an item “MEMORY TESTING”.
To facilitate understanding of the operation of the emulator software, you need to know the following. On a standard diskette, Amiga stores recorded data on 80 tracks on both sides. Each track consists of 11 sectors of 512 bytes. Therefore, the total data volume of a floppy disk is 901120 bytes. This is the volume of ADF-files of floppy images. This file does not contain headers, and the data inside is simply listed as follows: (track 0, side 0), (track 0, side 1), (track 1, side 0), (track 1, side 1) ... (track 79, side 0), (track 79, side 1). Each track is a record of 11 sectors of 512 bytes, starting from sector 0. To emulate a floppy disk such a file in its pure form is not suitable. The fact is that the ADF file stores only useful data without any overhead information and without modulation. Consider how the modulation of the signal in the Amiga computer.
Any drive is nothing more than an analog tape recorder. It does not encode the recorded data. You select a track and modulate the current (and, therefore, the magnetic field strength) through the drive head to record information. When playing in places where the magnetic field strength has changed, the drive reads a short pulse. Amiga uses when writing to floppy disks modified frequency modulation, the so-called MFM (Modified Frequency Modulation). With this modulation method, the change in current through the coil depends not only on the value of the bit being written, but also on the value of the previous bits, as shown in the table below. In the “coded” column, R means a change in magnetization (giving a pulse to a disk drive), and N means that the magnetization does not change. Further, in order to write the MFM file in binary format, we take R equal to 1, and N equal to 0. Two bits of magnetization change are written to the MFM file for one data bit. Thus, the data size of the MFM file compared to the ADF file will be doubled. But you can't just convert ADF to MFM. Amiga uses its own format for writing to floppy disks, which need to be taken into account.
We agree on the track number to name the track number on one of the disc sides (i.e. the track number varies from 0 to 79), and the track number to ((2 * track number) + disc side number). The track number varies from 0 to 159, the disk side number varies from 0 to 1, the sector number changes from 0 to 11.
In Amiga format, each track contains:
- The initial gap (128 bytes of MFM code 0x00).
- The data of 11 sectors is 544 bytes per sector.
- End gap (704 bytes of MFM code 0x00)
Each sector contains:
- Marker start sector.
- Sector ID (4 bytes: 0xFF, track number, sector number, sector offset. Sector offset is calculated as 11 minus the sector number on the track.)
- Sector label (16 bytes 0x00).
- Header checksum (4 bytes).
- Checksum data (4 bytes).
- Sector data (512 bytes).
The identifier and sector data are encoded by permuting the bits. For the identifier, 4 bytes are taken and bits are swapped. The odd bits come first (the numbering of the bits, as usual, with 0) —it will be 2 bytes. Then come the even bits - just 2 bytes. The table illustrates the above. The top line is the standard order of bits (numbers in the cells), the bottom is the result of the permutation.
Sector data is grouped by 2 bytes, and the permutation occurs within this pair in the same way:
The checksum is an exclusive OR (XOR) operation of all bytes of sector data or a header (taking into account the permutation of bits!), Grouped in 2 bytes. The checksum itself is not subject to permutation of bits. Although the field for the checksum is 4 bytes, the checksum itself will be two bytes.
In addition to the 544 bytes of data encoded using MFM coding, each sector contains a special data start marker. A marker is a combination of zeros and ones that cannot be obtained with MFM coding. Such a combination is the combination 01000100100010010100010010001001 before recording of which 4 bytes are written with the combination 10101010. The first byte of the combination 10101010 depends on the previous bit issued by the MFM coding. If the last sector bit issued was 1, then this byte will be 01000100, and if there was 0, then 10101010.
Given all the above, the floppy disk track in MFM format looks like this:
- Initial clearance: 128 bytes 00000000.
- Marker start data sector:
10101010 (this byte depends on the last bit written and maybe 01000100)
10101010
10101010
10101010
01000100
10001001
01000100
10001001 - Sector data without marker: 1080 bytes per sector.
- Repeat from step 2 for all 11 sectors.
- End clearance: 704 bytes 00000000.
Total, each track in the MFM-coding takes (1080 + 8) * 11 + 128 + 704 = 12800 bytes of code. If now this code is output to the data line from the drive, taking into account the temporary sweep of the track, then Amiga will be able to read the data of this track.
The problem is that the data pulse duration is from 0.15 to 0.8 μs. In this emulator, a pulse duration of 0.5 µs is selected. This means that at a frequency of 16 MHz, we will have 32 clocks per bit of the MFM code. During these 32 clock cycles, the microcontroller D3 must regenerate the dynamic memory, read the MFM code byte, issue a magnetization change bit on the drive line. To meet the 32 clock cycles, this part of the program is written in assembler and strictly aligned with the bars. The byte read and memory regeneration operations are separated in time. This means that as long as the MFM coding byte is issued, for each bit there are 32 clocks and for each output bit it is strictly defined what operations we are performing in these 32 clocks. For example, when issuing bit 0, we can set a dynamic memory string (RAS signal). When issuing bit 1, we can set the dynamic memory column (CAS signal). When issuing bit 2, we read the next data byte issued. And so on. This way, the entire floppy image is issued.
Actually, that’s the simplest drive emulator.
Emulator video:
Archive with printed circuit boards, firmware, diagrams and programs.
Source: https://habr.com/ru/post/330668/
All Articles