Microwave Chapter one. SD card controller

Google

Idea.

In the network I saw several variants of SD boot loaders for similar Pecomok, I did not like the presence of microcontrollers in them, wanted to make according to «vintage, warm Dipotsova» scheme, that is why I decided to make on the domestic logic «KP1533».

And I used UT62256 as a dope. It’s the only import chip in the project. Of course, it was possible to deliver KP537R10 or KP537RU25A, but first of all, it would have to be not one, but two (I planned 4 kB of RAM) and second UT62256 I had and KP537 was not, and I didn’t want to order. So I took the liberty of importing, and then I came up with the idea of using all 32kB of extra RAM, with page switching.

He chose KP573RF5 for the ROM, just two clean ones.

Block diagram.

Here is an RAM chip, a ROM chip, and a «PORT» block. The «PORT» block has a parallel interface with 8 inputs and 8 outputs. When written to an EFFF address, the code to be written is displayed at the outputs, and when read from the same address, the read value corresponds to the state of the inputs. Three of the outputs and one of the inputs are connected to the SD card via a level converter.

RAM is represented by the UT62256 chip and has 32kB of memory. Since the range of E000-EFFE addresses is almost 4kB (4095 bytes), there are 8 pages that are selected by the «PORT» block, bits 1,2 and 3. That is, the entry at the EFFF address leads to the installation of the page according to these three bits. Also reading from this port shows which page is currently selected (in the same bits). Total, we have 32,760 bytes of additional RAM (4095x8p).

The ROM chip is CR573RF5. It is connected to the F000-F7FF address space, and contains the BSBB (BIOS) code, the task of this code to initialize the SD card, load the OS from it, and transfer the control to it.
Accordingly, after the PC is activated, the GF000 System Monitor is dialed and the VC is pressed.
Later, there is an idea to modify the native System Monitor ROM to automatically boot the OS from the SD card, and the PC comes out as a standard Monitor invitation if the boot failed or was aborted, for example by pressing a key.
I’ll think about it.

Diagram.

About two or three hours behind the computer, and I drew the following diagram at EAGLE.

Increase

I used the chips I had. It’s possible that the number of logic chips could be reduced if I used other valves, but I only had one. And in the future, I’m probably optimizing the schematic.

Low-Level Scheme Parse II

put it under the spoiler, I don’t think anyone’s interested in these morons.
Looking at cell I V3/1, it is connected to lines A14 and A15 of the address bus, which means that output N3 will have a logical unit when these two address signals are in log.1. The inverter V1/2 generates a signal with the conditional name G, which comes to the decipherer IC2. The inputs of this decryptor A and B are connected to the A12 and A13 lines, respectively. So it turns out that the decryptor is activated by the presence of units on A14 and A15, and its outputs show code on lines A12 and A13. We’re only interested in one option - 1110,
That is A15-1; A14-1; A13-1; A12-0. This signal is generated at the output of the N2 decryptor. Because there are two decoder cells, this signal should appear on conclusions 5 and 11, but because each cell has another input C, the state of this input will determine which cell is active. Input 1C activates output 5, and input 2C activates output 11. These inputs are sparaled, but the input 1C is straight and the input 2C is inverse, so if log.1 is present on them output 5 is activated, and at log.0 output 11 is activated.

In summary: If the bus has an address code Exxx and C=1, the «PORT» signal is formed, and if the bus has an address code Exxx and C=0, the «RAM» signal is formed.
The «C» signal is generated by the function of the logical I, from all the junior addresses (A0-A11). When the bus has xFF code, then C=1 or C=0. Total: «PORT» signal is called by EFFF address, and «RAM» signal by E000-EFFE addresses.

The signal «RAM» arrives at the input of the CS chip IC3, it is an RAM chip, and it means that the record at the addresses E000-EFFE will lead to an entry in this chip. Also reading to E000-EFFE addresses will lead to reading from this chip. When written to an EFFF address, the code will be recorded in IC4 register, and the output will be clicked. The recording signal is formed by signals «PORT» and «WR» with the aid of elements V1/5, V1/6 and V3/4.
Reading to the EFFF address will result in reading data from the IC5 buffer, and the code will depend
from the input state B0-B7.
A ROM chip is included in the address space of a PC by means of a standard address decryption device. For this purpose from the port «Internal Interface» the signal CS3 is taken and it is connected to the line of CS chip ROM.

Layout.

Now I don’t have the power to poison the board at home, and I took a piece of foil two-sided text, and I drank the necessary rectangle out of it.
This rectangle was tightly inserted into the slot «internal interface» of the PC, did not dangle and did not move. And then I scratched the contact pads on the back and front. That was pretty good. And then I got a rough set of chips, and I got a drill of holes. Put a large drill on the front side so the chip’s findings wouldn’t come into contact with the facial foil. On the other hand, he cut the perimeter of each contact row and divided it into contact areas.
The next step was to put all the chips (and the dashboard) and disappear from the back. It took a lot of time to mount what I did with the thin Mgtf. Wired from both sides, with the front, straight to the chip legs, with the back to the pads.


When the soldering process was finished, I decided to pay attention to the signal level converter. The thing is, the SD card runs at 3.3v. and the CP1533AP6 and CP1533IR22 TTL 5V chips. So we had to make a little transducer handkerchief, where the levels were limited to stabilisers.
The signal from the SD card to the controller I just pulled to the source 3.3. resistor 10k. This signal has proved to be unnecessary.

Although eventually I’ll probably make a backward converter based on the comparator.
The card holder used the microSD adapter in the SD.
In general, there was no problem in assembling the layout, although I was afraid that some of the chips might be faulty.

Mockup tests.

First thing I checked the work of OZU, wrote down in the area E000-EFFE with the help of the directive «F» of the System Monitor «AA», «55», «F0» and «0F» and checked them with the help of the directive «D». Everything was back to normal.
Then by the directive «M» began to write to the EFFF different values, and watch the multimeter changes on the legs of the register KP1533IR22, the states corresponded to the recorded codes. Also, when read from this port, the code contained the selected page, as intended, and when the MISO signal was closed to the ground, the lower bit was 0, and when the 1 was opened.
In fact, it was kind of suspicious that all the circuits were working properly and the installation was flawless.

Layout tests.

First of all, I checked the RAM operation, wrote “AA”, “55”, “F0” and “0F” patterns to the E000-EFFE area using the System Monitor directive “F” and checked them using the “D” directive. Everything turned out to be normal.
Then, using the “M” directive, he began to write different values ​​to the EFFF address, and watch the changes on the legs of the register КР1533ИР22 with a multimeter, the states corresponded to the recorded codes. Also, when reading from this port, the code contained the selected page, in accordance with the plan, and even when the MISO signal was closed to ground, the low bit turned out to be 0, and when opened, 1.
It was even somehow suspicious that all the microcircuits were working and the installation was successful without errors.

BSVV.

Of course, I didn’t have any special tools for writing programs for КР580ВМ80А. I had to write a program in a notebook (notepad), then translate it into codes manually.
Created a file in the editor under DOS “HIEW” and began filling it with codes. For the basics, I took my project under AVR, in which there was standard initialization of the SD card. The project was old, and it did not use any file system, just a logger.
First I wrote a low-level function of the SPI programming interface, and then a high-level SD card initialization routine.

It turned out something like this algorithm which is put under the spoiler, I think it is already known to everyone.

1. Raise the attempt counter (SP) to 90;2. Set CS to log 1 and send 10 times FF;3. Set CS to log.0;4. Send CMD0;5. If 01 is read, then go to 7;6. Reduce the SP. If SP = 0, then exit with an error, otherwise switch to 2;7. Send CMD8;8. Send ACMD41;9. If 00 is read, then jump 1110. Reduce the SP. If SP = 0, then exit with an error, otherwise go to 8;11. Send CMD58.12. Read the 2nd byte of the response and write to the EFFE address.13. Initialization is complete.

The OCR card register was also read in the initialization routine, and the 2nd byte in it was written to the EFFE address. This was necessary to determine the type of card.
In the case of SDSC - 80h, and in the case of SDHC - C0h.
If the initialization did not pass, then the message “SD CARD ERROR” was displayed and then the monitor went out without reset.
I converted this BSVV into WAV and downloaded it to the PC via the tape input, then debugged it, corrected the source code and downloaded it again.

Bridges.

Now I have additional RAM, 32,760 bytes in size, divided into 8 pages. But how to navigate between pages? How can a program running on the first page invoke a routine located on the fourth?
To solve this problem, I have provided software bridges. A bridge is a small area in ROM that mediates control transfer.
For example, executing code should transfer control to page number 3, to address E4B5. Then, the executing code places the lower 12 bits (4B5) in the register pair of the processor HL, and in the upper four bits puts the value 3 - the page number. Now in the register pair HL the value 34B5 is written. And the code jumps (JMP) to the ROM area called JMP-Bridge, it’s just going to a fixed address in the ROM. The code in this area extracts the page number from the high bits of the HL register pair and writes them to the register of the PORT block at EFFF. The third page of RAM is now displayed in the E000-EFFE area. The JMP-Bridge program resets the four high bits of the HL register pair and writes "E" there. Now the physical address E4B5 is already in the HL register pair, and here the JMP-Bridge program transfers control to it.
This transfers control between pages.
There is a CALL-Bridge, it is needed to call a subroutine with a return, and differs from JMP-Bridge by saving the current page on the stack, and the reverse procedure for returning.
The next two bridges are STA-Bridge and LDA-Bridge. As the names suggest, the first one writes the Battery register to a logical address (in HL), and the second one reads data from the logical address into this register.
Thanks to these two bridges, a program executing from one page can store data in another.

Download OS.

If you look at the boot sector of the SD card, you can see that the text “Disk error, press any key to restart” is located at addresses 1AC-1D4.


Yes, it’s so strange how it looks in the photo, because the character encoding of Mikroshi does not coincide with ASCII.
I decided to use this area to place the data there for downloading the PC.
First of all, I put the code 00 in position 1BA, and thereby cut the record. Now, just “Disk error” should be displayed and that’s it. The remaining bytes are mine. The principle is simple, a 6 byte MicrOS signature, and a 4 byte address on the SD card of the beginning of the file with OS. In BSVV I wrote, after receiving the boot sector from the SD card, the signature is checked, and if there is one, then take the next 4 bytes and use it as the sector address for loading the OS.
If there is no signature, the message “OS DOWNLOAD ERROR” is displayed and the System Monitor exits without reset.

Total.

And now, finally, everything works. BSVV is written, but I still need to write it to ROM.

And for this, I need to edit all the addresses of subprogram calls and jumps, since this processor has absolute addressing. And I wrote BSVV for the region 6000-67FF to load in RAM. But now we need to change all 6xxx to Fxxx.
In addition, I am in the “popanetsky” conditions. I have a ROM programmer, but it's an old one, under an LPT port. And there is not a single computer with LPT. But there is a pair of Atmega32A, in the PDIP40 package and a breadboard. You may need to emulate LPT using AVR. But maybe everything will work out.