Correspondence with Trident

Hello spensor I have been corresponding with Trident for several months. He helped open many secrets of SMUC and confirm the assumptions already implemented in the circuit. K Unfortunately, due to his reluctance to reveal his name, he was unable to register on forum. Therefore, information that may be of interest not only to me, I just I will quote. ┌─- code ─── Spensor: Who (SMUC) needs it? There are 1.5 people who want to have this, not counting me... Trident: Everyone needs it. Nobody needs it while it's gone, at least not yet accessible scheme in terms of repetition (not exotic like the original). No a common piece of hardware - there is not much software for it. There is not a lot of software for it - there is no particular need. I hope the chain is clear? Trident: And then, why does everyone perceive SMUC as just another IDE controller?! And endlessly compared to NEMO IDE?! NEMO IDE is just a banal 16 bit port for communication with the internal HDD controller and that's it! SMUC is a much more powerful device... I get it the impression that most people generally have a very vague idea of the subject conversation and, accordingly, the value of this development is not able to assess, hence the lackluster interest... Spensor: In essence, such a comparison is not far from the truth, for the reason that in Currently, the main application of SMUC is to work withIDE devices. The subsystem for working with virtual disk drives is not in demand, Trident: It’s in demand, it’s just implemented in one place. It’s inconvenient. Spensor: for the reason that work only occurs through #3D13 (#3D2F not processed), Trident: In theory, that's how it should be. To support #3D2F you will have to emulate VG93, and this is already too much... In addition, Maksogor said that on In practice, it turned out to be impossible to simulate VG when working from a hard drive. Therefore in ATM this is done from a RAM disk, which takes up almost all the memory. Spensor: and its own file system has some problems - on PC You can't put TRD images on such a HDD. Trident: Well, the file system is a special conversation. Spensor: There is a question - have you ever seen SMUC that would show version 1.2? Trident: No. Spensor: Is bit D3 of port #7FBA used? We need to read the state of the bit, by writing a number with the D3 bit cleared to the same port. Trident: #7FBA: 7 - 0 = HDD instead of drive B: / 1 = real drive B: 6 - 0 = HDD instead of drive A: / 1 = real drive A: 5 - always 1 4 - always 1 3 - 0 = no HDD / 1 = HDD present 2 - always 1 1 - always 1 0 - always 1 All involved bits are needed directly to emulate drives A: and B: (there are only two of them on the scorpion). Moreover, the software does not monitor their status. And if,for example, manually disable the HDD - out (#7FBA), #x7, then the shadow will do so show HDD settings, but TR-DOS will access real drives. Apparently, the state of this bit changes only once, immediately after RESET when searching for HDD. That is, that’s exactly what I did, turned on the machine, the hard drive was detected, from #7FBA read #xF, entered the number #x7 into #7FBA by hand, and TR-DOS began working with real disk drives, even though the software was connected virtual disks with which TR-DOS just worked. It is noteworthy that PP didn't even collapse because the beat changed! The HDD menu remains the same active, although it should have become blocked. In my opinion, this is where the bugs come from disk drives, TR-DOS is oriented towards the port, and PP is oriented towards some of its own settings. Spensor: Is there any confirmation in real SMUC that semi-kits ATA-IDE registers are switched by bit D7 of the #FFBA write port? We need to go to this port send a number with bit D7 set and check the signal levels at CS0 and CS1 (pins 37 and 38 of the IDE connector, respectively). Trident: I conducted a number of experiments here, both with real and with emulation, it turned out The following - bit 7 of the SMUC system register has a dual purpose: 1. It controls the RD/WR signal of the CMOS chip; 2. it really switches HDD registers! But! The software has a procedure for working with HDD (ROMDSK03:#1E74). She sets bit 7 to 1port #FFBA, after which writes #00 to the DeviceControl HDD register (port SMUC - #FEBE) and restores 0 in bit 7 of #FFBA. So, based on documentation, HDD has only two alternative registers - AlternateStatus and DeviceControl. The first one is read-only, and the second one is write-only, according to to the same address for SMUC this turns out to be port #FEBE. I conducted the following experiment, for brevity I write with Asma’s instructions: OUT (#FFBA),#7F ; enable main set (bit 7 = 0) OUT (#FEBE),#FF ; I write down an arbitrary number, now it should be a register HDD head numbers IN (#FEBE) ; reads #FF - everything is correct OUT (#FFBA),#FF ; switch to alternative set (bit 7 = 1) IN (#FEBE) ; reads #FF - which means this is the same number register heads, a should have been AlternateStatus, and should have been considered #00 OUT (#FFBA),#FF ; enable alternative set (bit 7 = 1) OUT (#FEBE),#55 ; I write down an arbitrary number, now it should be a register DeviceControl IN (#FEBE) ; #FF is read - no writing to the head register occurred, which means that's right OUT (#FFBA),#FF ; switch to alternative set (bit 7 = 1) IN (#FEBE) ; #FF is read - the same head number register. Hence the conclusion - bit 7 of port #FFBA switches only to writing to alternative HDD registers, it does not affect reading HDD registers in any way, they are always read basic.In general, nothing surprising - you can easily do without AlternateStatus. Spensor: Are bits D3 and D7 of the #FFBA read port used? If yes, then for what? do they answer? It is necessary to honor this port by grounding the IRQ pin of the IDE connector (pin 31), without connecting the HDD. Trident: Regarding reading bit 7 of port #FFBA: I disassembled the car, attached the wire to GND and probed the entire HDD connector with it. Result somewhat strange The first number is the number of the HDD connector contact being probed (in brackets - connector pin assignment), the second value read at this time from #FFBA. I threw the number #FF into the port in advance, it’s from there and is read if there’s nothing touch. 3 - #7F (D7) 5 - #BF (D6) 7 - #DF (D5) 9 - #EF (D4) 11 - #F7 (D3) 13 - #FB (D2) 15 - #FE (D1) 17 - #FE (D0) 31 - #7F (IRQ14) all others - #FF In general, IRQ14 is actually read through port #FFBA, this is bit 7! But why D0-D7 HDD began to be recalled is a mystery to me - it turns out that D7 and IRQ14 overlap each other. How does it work then?.. └── code ───