Treatise on Emulators (1 from 3)

================================================================================ * Forwarded by Kirill Frolov (2:5030/946.25) * Area : RU.PHREAKS (Unknown area) * From : Ivanov Arthur - lead.engineer, 2:5020/400 (24 Mar 00 20:49) * To : All * Subj : Treatise on Emulators (1 from 3) ================================================================================ From: "Ivanov Arthur - lead.engineer" A TREATISE ON THE DESIGN OF PAYCARD CARD EMULATORS. /Beta release/ After I carelessly intervened in the discussion here, I received a certain amount of soap with requests to describe in more detail how make a phone card emulator. I want to answer everyone at once. I think it would be completely wrong if anyone published the working firmware of the emulator, thereby devaluing the received result. Then every lamer will be able to snort at your work - “That’s all You can download from the Internet...". If you fucked her for more than a year, you It will be very disappointing. And if you consider that “golden” telephone cards sold in St. Petersburg at a price of about a hundred tanks apiece, and even more so not worth it. In addition, the firmware will not help many people. Something that will work it doesn’t happen right away. There will be rakes. And to bypass the rake - you need to understand,what you do, how it all works and how it should work. In general case, it is enough to have admiration for two books - "Art programming" by Knuth and "The Art of Circuit Design" by Horowitz/Hill. A Most readers of this conference would do well to re-read the school course physics in the section "Electricity". To have fewer “brilliant” ideas, type of magnetic card lamination. Otherwise, for example, you will need to assemble a telephone reader cards. You solder all the wiring correctly, run the correct prog... And in the computer setup there is a bidirectional /EPP/ mode parallel port... And - ass... It won't work. And this is not even a rake, it’s just a rake. In this conference they constantly complain that they can’t read the card. I imagine the fields are strewn with rakes, where these guys got lost unhappy. But, I was just kidding, and I want to show you what it should look like emulator development. So that there are fewer non-specific questions on this topic. In this case, scraps of my first, sometimes funny, attempts in this area. Their value for me now is not great, since I myself don’t know whether they can be brought to a working result /it was a dead end branch of development/, but it would be a pity if there were some highlights will disappear, someday, without a trace, crushed by the F8 key. Let them be in the echo.To avoid disclosure of Know How, I will change the microprocessor platform, when discussing. Her choice will be more or less moronic. So that using this text as assembly instructions would be absolutely impossible. Only as a GUIDE TO ACTION. On Implement the emulator on the PIC processor yourself at your leisure... So, let's say you get it into your head to develop an emulator on the most inappropriate platform for this. For example, on a single crystal from MCS-48 family from Intel /i8048, KR1816BE48, i8035, i8039, etc./. Well, they stuck their heads and that’s it. Processors 8048, 8035, at a maximum clock frequency of 6 MHz execute one command in 2.5 or 5 µs. And the minimum pulse times and the interval between pulses of the Clk signal when reading a card defined at 8 and 10 µs. During the period of events in our system there will be there are 3-7 processor commands. It is clear that this is unacceptably small. The i8049 and i8039 processors are slightly faster. You can stick quartz to them 11 MHz and the command will be executed in 1.36 or 2.72 µs. Since, the payphone probably works with the card at a lower frequency maximum / for reliability /, maybe the speed will be enough for us. If We will save every processor cycle. In short, so strange the stone was chosen to make the battle forspeed, which is an indispensable development companion any emulator. Since a payphone, when a unit is taken away, removes power from the card and re-reads it again, and the built-in non-volatile memory in our If not, then it is clear that external power will have to be provided. And then, when When the power is removed, the processor will forget how many units are left. To The battery worked longer, we take the CMOS version of the processor. So that no additional small circuits, such as latch /IR22/ or ROM-chi /27C16/ not consumed excess current, take a percentage with a built-in flashable ROM. We will pour the program inside. In short, we choose i87C49 / it seems there is even an analogue of it KR1835BE49/. Maximum permissible frequency quartz for this processor is 11 MHz / one command in 1.36 or 2.72 µs/. But let's not forget that processors can be overclocked. Therefore experimentally let's select the maximum quartz frequency at which the processor will work no glitches. Let us not forget, at the same time, to control the generation frequency frequency counter on the leg XTAL2. Otherwise, when connecting too high-frequency quartz, generation can begin on parasitic R and C, and not at the resonator frequency. PIC processors, for example, are overclocked by as much as 2 times. My PIC16C84-4/SO worked at 10 MHz and occasionally glitched at 11.7. And PIC16F84-10I/SO is also I worked on 21 MHz and completely gave up only on 24.Since the emulator turns out to be battery-powered, the problem disappears, which torments the developer of an emulator powered by a payphone - minimizing processor startup time. Payphone, after power on, takes a terribly short shutter speed before starting to read the map. If, to At this time the processor did not have time to start and execute the section initialize the program and get to the main loop, then the data read by a payphone will represent absolute shit. But the processor needs to be given time to reset, and the clock generator get excited and calm down your hesitations. Let me remind you that quartz the resonator does not start oscillating immediately after it is applied nutrition. The PIR processor, for example, counts 1024 pulses at startup from quartz, as a shutter speed to stabilize its frequency, before start moving through the program. Obviously, the time between applying voltage power supply and the first impulse from quartz is simply dead time, uselessly increasing the time it takes for the processor to come to its senses. Dead time depends on the size of the capacitors connected to the quartz terminals and has a clearly defined minimum. It is big with too small and containers that are too large. For a ceramic resonator this time is on the order of tens of microseconds, and for quartz it is a few milliseconds! So,taking a dual-beam storage oscilloscope, preferably at least this dead time, for a specific instance of quartz, find by sorting the size of the containers connected to it. Again, since the emulator is battery-powered, there is no need optimize the program initialization section. You can, without haste, copy all or part of the data from ROM to RAM. In our case in RAM Only changeable data corresponding to the loan will be stored cards. Unchangeable data /card serial number, certificate, etc./ will be stored in ROM. To speed up data access we will, at startup programs, copy the data into RAM at the same addresses that they were in third page of the ROM. This will allow one pointer to be used for access to both changeable and immutable data. Now we invent a scheme. The circuit should always be designed so that the program for it had maximum performance. That is, the first stage of program optimization - CIRCUIT TECHNICAL. First, let’s see if it’s possible to detect any events in hardware /not programmatically/, sending signals to the microprocessor interrupt legs. Let the hardware, the hard logic, absorb part of the algorithm. Need make the most of the chip's hardware capabilities by processing pulses by interrupts, and not by polling the line in a cycle.Card, when reading, on the front Clk increases by one internal address counter. But the state of its output does not change. And issues a new one bit only on the decline of Clk. Our emulator, having detected Clk, will be within several processor commands to understand the program, what’s what and which bit to output. Therefore, it is clear that the emulator must work according to front Clk. It will output the next bit delayed from the edge. If the payphone will be very picky, you can insert NOPs, manipulate quartz frequency, as well as aligning the shoulders according to execution times, time this moment to coincide with the decline in Clk. Although really such subtleties are unlikely to be needed. That is, an interrupt on the Clk edge is necessary. But our damn processor has an INT input that is triggered by negative difference /from 1 to 0/. Well, don’t install the inverter in the very in fact. Willy-nilly, we have to say goodbye to the idea of ​​interruptions. We will poll the lines yourself. Where should I put this Clk? Some programmer would immediately blurt out - yes to the I/O port /for example p1.0/. And I would process the line like this: in a,p1 jb0 Clock_Prishel - 4 processor cycles And if a conditional jump were needed due to the absence of Clk : in a,p1 cpl a jb0 Netu_Clocka - 5 clocks / there is no jnb command in this barbaric command system / But a person professing the idea of hardware optimization of programswould put the Clk line on leg T0, and the Rst line on leg T1 and branch into two clock cycles for both conditions - jt0, jnt0, jt1, jnt1. There is nowhere to connect the Out line except to some port line I/O Moreover, he is an adherent of circuitry licking programs I would prefer the zero bit of some port /for example p1.0/. Why ? And this makes it possible to write as concisely as possible. pieces of code to manipulate this output. You will see it below. But first, the question is how to store card data for maximum quickly operating them. Firstly, how to present them at all - according to bit per byte or pack 8 bits per byte. If you store the entire dump cards in 16 bytes, then when reading, and this is the fastest operation cards, I would have to constantly check whether I need to read the next one byte or still rotate/shift this one. But how easy it would be to do WriteCarry - sent the FF byte to memory and that’s it. But the WriteCarry operation will occur in about 10 ms. Therefore, we optimize for performance in Read is beneficial, but with WriteCarry there is enough time to send 8 bytes. That is we store the card data in 128 bytes, and the meaning of the data will be only the least significant bit in a byte. At the same time, all operations are easy and at ease. -+- ifmail v.2.15dev4 + Origin: UNKNOWN (2:5020/400)================================================================================ Press RESET immediately, All!