ZXPRESS
ruseng

SMUC on discrete

ZXNet echo conference «hardware.zx»

From Aleksey Naboka To All 10 October 2005

Hello, spencer Yes WBR, hardy aka Aleksey Naboka

From Semchenko Vlad To All 7 November 2005

Hello Mick So my vacation is over :( During this time, some things happened to my project changes. There are some pleasant ones and some not so pleasant ones. The unpleasant ones are three errors in the scheme SMUC0.0a! And if two of them belong to the “mistake” category, then the third serious mistake. So bugreport: 1. The names of microcircuits D13 and D14 are mixed up in the list, it should be like this: D13 K1533ID7 D14 K1533ID14 (earlier, in the trade, the error was already mentioned); 2. The DS and R/W signals generated by DD14.2 are really mixed up:( It must be like this: vyv. 11 DD14.2 - R/W; vyv. 10 DD14.2 - DS; I assume that at the drawing stage, “on the fly,” I changed the signals at pins 13 and 14 DD14.2, but I forgot to correct the signals at the output of the decoder :( 3. A serious mistake - when reading the #DFBA (RTC) port on the data bus at the same time Both DD3 (RTC) and DD2 (data buffer) output data :( It can be treated by applying an inverted RTC signal to pin 12 of DD16.4 instead of /CSM. Either by connecting the RTC data bus not directly to the Z80 data bus, but through buffer DD2 (instead of D0-D7, signals DB0-DB7 are sent to the RTC).

From Semchenko Vlad To All 7 November 2005

Hello spensor ewg> Meanwhile, SMUK-2 moved from the alpha stage to beta... Well, for starters, SMUCv0.0a is still only in the state of transition to the alpha of the second version (SMUCv0.0a2) - RTS is not ticking yet :( It will become beta only after they are launched. But SMUC will exit stage 0.0 when all the “blank spots” with port allocation will be painted over, in particular, you should understand why they “disappear” mounted drives C and D. There was a suspicion - perhaps drives C and D displayed on port #7FBA, but with bit D7 of port #FFBA set. Request to those who know how to “open” ProfPZU, in particular Mick, check this proposition. P.S. So that there are no meaningless discussions about IR15, I will say that in the PS by mistake, It was said that it is difficult to get IR13. Since there is no such thing in the scheme at all, I I assumed that we were talking about IR15, but it turned out that there were difficulties with IR23 :) The latter (IR23) can easily be replaced with IR37 - they are functionally are similar, but differ only in the pinout.

From Ewgeny Ivanoff To All 8 November 2005

Hello spensor As a secondary character, I want to give some comments :) Regarding “alpha-beta” - I agree, it’s too early. Now I’ll try to clarify the situation with the clock a little. The most important thing... THEY I'M ALREADY FUCKED! :) But laughter is laughter, but we haven’t managed to launch them yet. The assumption about a clock conflict with the bus buffer was confirmed after turning on inverter to the AP6 sampling input, the signal conflict disappeared, which notified me "CMOS checksum error" message. Reading from RTC registers is a pleasure. We write 0 - we get 0; write 255 - get 179; write 179 - get 255... The numbers are given for example, but they are not random; when reading and writing again, they repeat. But I didn’t find any pattern in them. They can be either less or less and more recorded. If you are interested, I can attach a “printout”. At the same time, “strange behavior” was discovered in the DS signal (already “new”). He should only be triggered when recording, however, apparently, the signal also skips when reading (the /WR signal is not active, the level is high). Tried it change ID14, then “move” this half of the decoder to external ID7, then I replaced external ID7 with external ID14... The result is the same :( When checking signals I used a trigger probe on TM2 + LED. Everyone else the signals are normal, appear according to the “schedule”.Question to the public - HOW CAN THIS HAPPEN? Signals for ID14 are taken from ID7+ element 2I (RTC signal), fifth pin TM9, /WR. The AS signal goes to the clock through the DD11.5 inverter. Everything seems fine... Maybe try connecting the clock via a Motorola bus rather than an Intel one?

From Mick To All 8 November 2005

Hello spensor spe> There was a suspicion - perhaps drives C and D are displayed through the port spe> #7FBA, but with the D7 bit of the #FFBA port set. Request to those who can spe> "open" ProfFZU, in particular Mick, check this spe> additional location. Once again, here’s a piece from window 7 of the profPZU. It looks like there are some functions related to the disk drive and 7fbah is also mentioned. There was a mention of 7fbah on the TRDOS page, which I posted recently or a long time ago I don't remember anymore. File: primer0c.rar http://zx.pk.ru/attachment.php?attachmentid=1908

From Ewgeny Ivanoff To All 9 November 2005

Hello spensor >As far as I understand, there is a typo. That's right, what a mistake. :) >To understand the answer to the question, I would like to understand - DS and R/W signals >>at >do IN #DFBA operations, with D7=0 in #FFBA, occur simultaneously? >If so, then this is >obviously contradicts the logic of the decoder and there is only one diagnosis - microcircuit >faulty. How can this be with 3-4 microcircuits in a row?... If there is >the difference in the phases of these signals (a “needle” appears), then this will come in >understand. I'll try to "catch" the timing of these signals. >What about replacing the RTC with another chip? I have three of them, they fit into the socket, and with each experiment I change them :)

From Semchenko Vlad To All 9 November 2005

Hello, ewgeny7 ewg> As a minor character, I want to give some comments Well, rather not a secondary one, but a person acting as an alpha-beta circuit tester and designer-manufacturer at the same time. In this case, after development documentation (scheme), your role has become paramount, since now it is you driving force for development. ewg> At the same time, “strange behavior” was discovered in the DS signal (already ewg> "new"). It should only work when recording, however, judging by ewg> everything, the signal also skips when reading (the /WR signal is not active, ewg> level is high). As far as I understand, there is a typo here. The phrase should sound like "He should trigger only when reading, however, apparently, the signal also skips when recording." The datasheet says the following - "Intel bus" Implemented if, at the cutoff of the AS pulse, the DS input is high voltage. In this case, reading or writing information will occur in depending on the state of the DS and R/W inputs. Reading will occur when negative pulse at the DS input, and recording - with a negative pulse at R/W input. In this mode, the DS input can be called -RD and the R/W input can be called -WE." ewg> Question to the public - HOW CAN THIS HAPPEN? To understand the answer to the question, I would like to understand the DS and R/W signals during surgery IN #DFBA, with D7=0 in #FFBA, occur simultaneously? If so, it's obvious contradicts the logic of the decoder and there is only one diagnosis - microcircuit faulty. How can this be with 3-4 microcircuits in a row?... If there is the difference in the phases of these signals (a “needle” appears), then you will have to figure it out. I myself would like to know the assumptions of the “hardware guys”. ewg> Maybe try connecting the clock via a Motorola bus rather than an Intel one? It can be done, but it is very complicated (2-3 buildings), and besides, IMHO, this will not change the situation - the mikruha must work in both modes, but for It is more advisable for an Intel-like processor (Z80) to work in Intel mode. What about replacing the RTC with another chip? It is possible that she "glued fins":( This will not change the situation with DS, but for the sake of the purity of the experiment it’s not bad It would be nice to see the results. PS: I apologize for the mistakes.

From Semchenko Vlad To All 9 November 2005

Hello, ewgeny7 ewg> I'll try to "catch" a temporary time frame of these signals. Just in case, I’ll expand on my idea. In general, you need to understand whether DS and R/W signals simultaneously, or alternately in the IN port read operation #DFBA. That is, we catch it using the “OR” element. ewg> I have three of them, they are inserted into the socket, with each experiment I ewg> changing them I see. The purity of the experiment was maintained.

From Semchenko Vlad To All 9 November 2005

Hello, ewgeny7 A question was asked earlier, and although I already answered it for the author, for the rest I will repeat parts (maybe someone else is interested). ewg> RTC is still silent. I downloaded the documentation for K512VI1. Appeared ewg> two questions at once. ewg> First, the datasheet says that pin 20 has, to put it mildly, ewg> has a slightly different purpose compared to the schema. In the documentation it ewg> is described as an input that determines... ummm... the division factor ewg> clock frequency for issuing it to pin 21. About what's on it ewg> power is supplied from the battery - the datasheet is silent, just like a partisan. Regarding the assignment of conclusions, the question is rather slippery. The problem is that MC146818 and its clones (KR512VI1, BQ3287, DS1285, DS12885, DS1287, DS12887, DS1685, DS1687E) on the question of using pins 16, 20, 21 have their own, far immodest, IMHO:( And in particular, pins 20 and 16 are much more often used as Vbat and GND batteries, respectively. Pin 21, again, is more often used as RAM CLEAR input, for clearing memory cells. When developing the scheme I had to go compromise and do it more or less universally. According to the idea of UsparkF CKFS (20) and CKOUT (21) is an autonomous node (frequency divider) of the microcircuit and suchturning it on should not affect the operation of the clock.

From Ewgeny Ivanoff To All 9 November 2005

Hello Lounge Lizard It turns out that Spensor even scribbled about alpha and beta at the right time... :) 64 bytes CMOS found NVRAM found Interrupt controller not found IDE Hard Disc found at 270Mb If modesty serves me, then SMUC-2, in principle, has already taken place, since You can already use it in full. Almost complete. There are only some "inconveniences" with drives C and D... So, here are the changes to the scheme in terms of hours: 1. inverter with /RTC for 12 leg DD16.4 2. already known story with the “throwing” of /DS and /RW signals 3. capacitor C3 - 10N. It performs a memory saving function (or something about this) when resetting the clock via /RES. Noticed instability during initialization hours when quickly turning the computer on and off. With a new capacitor it looks like everything is fine, the clock does not reset. 4. and most importantly. The battery must be at least 4.5 volts. With less voltage, just turn off the computer for 10 seconds and again we get “CMOS checksum error". Now I turned off the computer for 15 minutes, turned it on - the clock is ticking like a cute little one, only The cuckoo is missing!

From Lounge Lizard To All 9 November 2005

Hello spensor spe> That is, we catch it using the "OR" element. spe> Just wondering how you were going to catch this situation using “OR”? By "XOR" or “AND” is understandable, but “OR”...

From Semchenko Vlad To All 9 November 2005

Hello, ewgeny7 Lou> Just wondering, how are you going to catch this situation using “OR”? Lou> By “XOR” or “AND” this is clear, but by “OR”... But I’m most interested in how you propose to catch the situation by “I” or "XOR"? Using "OR" the situation is calculated as follows: DS R/W 0 0 0 - glitch 0 1 1 - OK 1 0 1 - OK 1 1 1 - OK But with the options you proposed, the idea is not clear to me.

From Semchenko Vlad To All 9 November 2005

Hello, ewgeny7 Lou> Just wondering, how are you going to catch this situation using “OR”? Lou> By “XOR” or “AND” this is clear, but by “OR”... But I’m most interested in how you propose to catch the situation by “I” or "XOR"? Using "OR" the situation is calculated as follows: DS R/W 0 0 0 - glitch 0 1 1 - OK 1 0 1 - OK 1 1 1 - OK But with the options you proposed, the idea is not clear to me.

From Semchenko Vlad To All 9 November 2005

Hello, ewgeny7 ewg> Now I turned off the computer for 15 minutes, turned it on - the clock is ticking ewg> cute, only the cuckoo is missing! It’s not entirely clear - the problem has disappeared? So the problem was in the battery?

From Ewgeny Ivanoff To All 9 November 2005

Hello spensor spe> It’s not entirely clear whether the disks are connected one at a time or according to the principle spe> A+B+C+D? The drives are connected according to the "plus" scheme. But the pattern is visible. Disc A - bit 7, disk B - bit 6... but then this pattern is lost. When connecting C Bit 5 should be reset, but it doesn't. I was ready to believe that it was so and should have been, but according to the City Ace letter, SMUC stores the settings of everyone four disks. At the same time, both NVRAM and CMOS are now available for PCBs, that is, in In this regard, there are no differences from the original SMUC. Most likely this is a question "iron". Maybe it’s worth replacing IR15 with IR23? Although, it’s unlikely... :(

From Semchenko Vlad To All 9 November 2005

Hello, ewgeny7 ewg> Bits 7.6.5.3 are connected (as in the diagram). ewg> In the monitor, we “disable” all virtual disks. IN 32698 (FDC) = 255. ewg> Connect drive A. Read - 127. Seems logical... ewg> Connect drive B. Read - 63. I see... ewg> Connect drive C. Read - 63. We've arrived... ewg> Connect drive D. Read - 63. Curtain. It’s not entirely clear - are the disks connected one at a time or according to the A+B+C+D principle? ewg> But how does it “remember drives C and D? It’s still unclear. There is the same assumption. And the “memorization” of drives C and D clearly happens in NVRAM. It is not entirely clear in this case only duplication of information in NVRAM and #7FBA. Is there a tangible benefit when working with A/B compared to C/D? Also It’s not clear why C and D “fall off” if the information is in NVRAM. Or maybe the disk connection status is also stored in the RTC? People having real SMUC, not for service, but for friendship, remove the RTC from the socket and check how this will affect drives C and D!

From Semchenko Vlad To All 9 November 2005

Hello, ewgeny7 As for the D5 bit, you don’t have to invent it in the original circuit on Altera starts, but the purpose of D3 is not yet clear, how and whether it is involved generally in port #7FBA. It is worth experimenting with connecting disks via “or”, although I think we won’t see anything new, but still. There is an assumption that there is a switch that organizes the shadow register #7FBA (for C/D drives), as happens with the #DFBA port (switching with the D7 #FFBA bit). But for now we need to analyze Mick's last example.

From Ewgeny Ivanoff To All 9 November 2005

Hello spensor I only checked drive B. As expected, port 191 is read. As far as I understand, you may have to hang another IR15 with a sample from /FD + Bit7 TM9?

From Ewgeny Ivanoff To All 9 November 2005

Hello spensor And in the battery too (first of all). It turns out that if the clock was “empty” after a power failure, we will always get "CMOS checked error". Therefore When the battery voltage was low, this message always appeared. By the way, I checked DS - this signal also has a “split personality”. But it turns out that this is not so critical. The clock still jammed a couple of times. For the first time I noticed that they were just standing there (quartz is worthless?), while the monitor does not have a line at the bottom of the screen about the current time. Poking the quartz with a screwdriver, the clock started running again. The second time happened when I was fiddling around with a soldering iron on IR15. A tip, perhaps? Now I'm dealing with FDC. Bits 7.6.5.3 are connected (as in the diagram). In the monitor we “disable” all virtual disks. IN 32698 (FDC) = 255. We connect drive A. We read - 127. It seems logical... We connect drive B. Read - 63. I see... We connect drive C. We read - 63. We have arrived... We connect drive D. Read - 63. Curtain. Disconnect all disks. We read port - 255. We write to port from Vasik 127. We read - 127. We climb into the monitor - all disks are disabled. Trying to view the directory of drive A (remember that the port is 127) - we hang, there is no disk. Reset. We read the port - 255. Judging by the operating logic, the monitor uses the port to quickly check whether disks, and if they are connected, it already reads the “path” from the hard drive itself (orspecialist. memory areas). But how does it “remember drives C and D? So far unclear.

From Mick To All 9 November 2005

Hello spensor spe> There is an assumption that there is a switch organizing a shadow register spe> #7FBA (for C/D drives), as happens with the #DFBA port spe> (switching by bit D7 #FFBA). But for now we need to analyze the last one spe> Mick's example. By the way, very often this port twitches in TRDOS, an example is somewhere above. There by the way bit6 and bit7 are checked after reading from the port. Looks like it migrated here some of the functions of TRDOS and plus innovations.

From Ewgeny Ivanoff To All 10 November 2005

Hello Mick A sad thought came to mind. Since the FDC port is now selected whenever state of bit 7, then introducing another port will not change anything. If at installed “drive A”, “drive C” would be immediately selected, then the idea with "shadow" FDC would have the right to life. but this doesn't happen... :o

From Ewgeny Ivanoff To All 10 November 2005

Hello, ewgeny7 By the way, regarding storing information about connected disks. When "exposing" disks, as well as when they are “dismantled”, an exchange occurs directly with hard drive (the screw buzzes for a split second). There are no entries in NVRAM signs, because this procedure takes a couple of seconds and this delay would be noticeable. Even if you specifically save a dump of settings in NVRAM, and then quickly reassign the "tracks" and turn off Scorp, when you start it will restore only the latest connections. And direct reading from NVRAM these connections are not will change. Regarding saving in RTC - the tops are different, but the same :) The clock chip is completely optional, and there are no changes in the instructions work with disks is not specified. Moreover, by default this MS does not even was put. For some reason I remembered the still unexplored DB3. Maybe he is the “key” (or “switch”)... It’s a pity, I don’t have the original SMUK diagram at hand :(

From Lounge Lizard To All 10 November 2005

Hello spensor spe> 0 0 0 - glitch spe> 0 1 1 - OK spe> 1 0 1 - OK spe> 1 1 1 - OK spe> But with the options you proposed, the idea is not clear to me. I just thought that when there are two units, this is also a glitch. Then either XOR shows that everything is OK, or “AND” that there was a glitch.

From Vlad Semchenko To All 10 November 2005

Hello Lounge Lizard ewg> As far as I understand, you may have to add another IR15 s ewg> sampling from /FD + Bit7 TM9? If the above principle is actually used, then either this or IR26/IR32 (1 piece for two ports). ewg> A sad thought came to mind. Since the FDC port is now selected ewg> for any state of bit 7, then introducing another port does nothing ewg> will change. If, with “drive A” installed, and would be immediately selected ewg> "drive C", then the idea of a "shadow" FDC would have the right to life. but ewg> this doesn't happen... It's hard to say, in the example below (taken from primer0c.rar), something is visible similar to the one I suggested: ┌─- CODE ─── LAB_0CFF: ld bc,0ffbah ; set D7=1 in the SYS port 0d02 3ef7 ld a,0f7h 0d04 32f0df ld (0dff0h),a 0d07 ed79 out (c),a 0d09 01ba7f ld bc,7fbah ; access the FDC port 0d0c 3eff ld a,0ffh 0d0e 32eedf ld (0dfeeh),a 0d11 ed79 out (c),a └── CODE ─── So go ahead and figure out what this means. ewg> The clock chip is optional, and there is nothing in the instructionsewg> no changes in working with disks are indicated. Moreover, by default ewg> this MS was not even installed. It's true, but there are many surprises in life :) ewg> For some reason I remembered the still unstudied DB3. Maybe he is the one ewg> "key" (or "switch")... Anything can happen. Try to “play” with him, maybe something will become clearer. ewg> It's a pity, I don't have the diagram of the original SMUK at hand IMHO, it won’t help, but if you really need it, then look in the proto-topic of this topic “Ports” SMUC". Here is a link to the topic: http://zx.pk.ru/showthread.php?t=456&highlight=SMUC

From Vlad Semchenko To All 10 November 2005

Hello Lounge Lizard Lou> I just thought that when there are two units, this is also a glitch. Then either Lou> XOR shows that everything is OK, or “AND” that there was a glitch. I think I understand. I think you also realized that you were mistaken. For reference. A decoder is a thing that produces an active signal (usually log. "0") only to one of its outputs, while the rest are passive state (logical "1"), or a passive state is present at all outputs. Exceptions are code converters (binary to seven-segment, etc.) which according to the classification also belong to decoders.

From Ewgeny Ivanoff To All 10 November 2005

Hello spensor Then Spensor: Thanks for the diagram. There are a couple of interesting points on it... I just woke up after a night out, maybe I soldered something while asleep :)

From Sergey Sirotenko To All 10 November 2005

Hello, ewgeny7 ewg> Now I was dealing with FDC. ewg> Bits 7.6.5.3 are connected (as in the diagram). ewg> In the monitor, we “disable” all virtual disks. IN 32698 (FDC) = 255. ewg> Connect drive A. Read - 127. Seems logical... ewg> Connect drive B. Read - 63. I see... ewg> Connect drive C. Read - 63. We've arrived... ewg> Connect drive D. Read - 63. Curtain. ewg> ewg> Disconnect all disks. We read the port - 255. We write to the port from Vasik 127. ewg> We read - 127. We climb into the monitor - all disks are disabled. Let's try ewg> view the directory of drive A (remember that the port is 127) - hanging ewg> there is no disk. Reset. We read the port - 255. ewg> ewg> Judging by the operating logic, the monitor uses the port for quick checking ewg> are the disks connected, and if they are connected, then it already reads the “path” from ewg> of the hard drive itself (or a special memory area). But how did he ewg> "remembers drives C and D? It’s not clear yet. ewg> All connections are stored on the hard drive in sector 3 and in memory on page 8. Port 7FBA is used in tr-dos to quickly determine what is connected - real disk drive and image on the hard drive. But Scorpio only has 2 disk drives.

From Ewgeny Ivanoff To All 11 November 2005

Hello Blade Bla> And Scorpio has only 2 disk drives. It’s strange, I have a Scorpio, but for some reason it has four disk drives. However, like from the admin of this forum :)

From Stanislav Yudin To All 11 November 2005

Hello, ewgeny7 ewg> It's strange, I have a Scorpio, but for some reason it has four disk drives. ewg> However, like the admin of this forum In fact, I only have two physical drives.

From Vlad Semchenko To All 11 November 2005

Hello, CityAceE People, can someone check how things are going with C/D in Unreal Spectrum? The emulator matches this scheme almost completely, so I would like understand if there is a problem there.

From Sergey Sirotenko To All 11 November 2005

Hello spensor spe> People, can someone check how things are with C/D in Unreal spe> Spectrum? The emulator matches this scheme almost completely, here spe> and I would like to understand whether this problem exists there. Access to C/D drives via 3D13 always goes to the hard drive. Check the real disk or image comes only on drives A and B (7.6 bits of port 7FBA).

From Mick To All 11 November 2005

Hello Blade Bla> Access to C/D drives via 3D13 always goes to the hard drive. Bla> Checking the real disk or image is only available on drives A and B (7.6 Bla> bits of port 7FBA). In fact, if you look at the converted TRDOS sources before turning to port, it first takes the number of the disk drive for temporary operations (current). then the monitor goes to the shadow service on rst 08h (camouflaged call to the address 0826 - in my example LAB_0826) with function 81h. By the way, a hint. The last example has a table of function addresses. Yes here is the function 22h - IdHdd - hard disk identification, 23h - mounting disk subpartitions.

From Ewgeny Ivanoff To All 12 November 2005

Hello Blade Bla> Access to C/D drives via 3D13 always goes to the hard drive Where did you get this information from? All FOUR disks A,B,C,D are mounted. Another thing is that drives C and D are remembered only for the current session, i.e. after Turning the power off and on only restores drives A and B. I check all this myself, on real Scorpi, on ProfPZU and test SMUK. And an appeal to three de thirteen initiates an appeal to the internal subsections of ProfPZU, who already see for themselves whether it is a real disk or a virtual one. Need take into account that tyr-dos in Skorpi and in ... let's say, the original Specky - differ, mainly due to the removal of some procedures and additional ones. improvements in the shadow monitor.

From Ewgeny Ivanoff To All 12 November 2005

Hello Blade Bla> All 4 disks must be remembered. Mlyn... This is exactly what we are struggling with now... :( As for the rest - I confess, the information was very versatile sources. The authenticity of the Microsoft certificate, of course, is not confirmed. :) But damn, how does information about "ways" to connect the 3rd and 4th disks when starting the computer from scratch? Can you confirm or refute our assumptions that C and D are registered in the "alternative" #7fba, activated when: ver.1: Bit 7 of the system port SMUK, ver.2: Somehow controls this “layout” bit 3, which technically installed on Altera, but its functional purpose is still not known :( To obtain the truth, there is only one way out - digging ProfPZU. Or option number two - catching a signal on Bit3 on a real SMUK. But no one can help us in a hurry...

From Sergey Sirotenko To All 12 November 2005

Hello, ewgeny7 ewg> Where did you get this information? All FOUR disks A,B,C,D are mounted. ewg> Another thing is that drives C and D are remembered only for the current session ewg> i.e. after turning the power off and on they are restored only ewg> drives A and B. All 4 discs should be memorized. This was the case in Smuka 1.2, 1.3. Unreal 0.32 s Prof-ROM 4.01 also remembers all disks. ewg> And an appeal to three de thirteen initiates an appeal to internal p/p ewg> Professional ROMs, which themselves check whether it is a real disk or ewg> virtual. It must be taken into account that tyr-dos is in Scorpi and in ... let's say ewg> so, the original Specky - they differ, mainly due to the offset ewg> parts of procedures and additional. improvements to the shadow monitor. ewg> Not quite like that. here is a piece of disassembler: LAB_0A01: ld a,(5cf6h) 0a04 c5 push bc 0a05 01ba7f ld bc,7fbah 0a08 ed48 in c,(c) 0a0a fe01 cp 01h 0a0c 2808 jr z,LAB_0A16 0a0e 300a jr nc,LAB_0A1A 0a10 cb79 bit 7,c 0a12 2019 jr nz,LAB_0A2D 0a14 1808 jr LAB_0A1E LAB_0A16: bit 6,c 0a18 2013 jr nz,LAB_0A2D LAB_0A1A: cp 04h0a1c 300f jr nc,LAB_0A2D LAB_0A1E: pop bc 0a1f 51 ld d,c 0a20 c5 push bc 0a21 0e02 ld c,02h 0a23 cd2608 call LAB_0826 ; RST 8 0a26 81 db #81 0a27 c1 pop bc 0a28 dae73e jp c,LAB_3EE7 0a2b e1 pop hl 0a2c c9 ret LAB_0A2D: pop bc 0a2e c3eb1f jp LAB_1FEB This is from features 5/6 3D13. The current disk is taken, 7FBA is read, if disk A is bit 7 is checked, if drive B - bit 6 is checked. If they are set - transition to the procedures for working with VG93, if reset - RST8: DB #81. For C drives and D immediately switches to RST8. If you enable Prof-ROM and SMUK in Unreale, then 3D13 never accesses real drivers C and D.

From Stanislav Yudin To All 12 November 2005

Hello, ewgeny7 Maybe this letter will help in some way? ┌─- code ─── ─ REAL.SPECCY (2:5045/78.4) ───────────&# 9472;──────────^ 72;─────────── ;─── REAL.SPECCY ─ Message: 969 out of 1000 -947 +976 Rcv From: Ilya Vinogradov 2:5054/37.26 27 Jul 01 23:53:52 To: Stanislav Udin 28 Jul 01 20:46:18 Subject: SMUC ───────────&# 9472;──────────^ 72;─────────── ;───────────& #9472;────────── 472;──────────γ 2;─────────── I see you as if in reality, Stanislav! Thu, July 26, 2001, 21:56:42, Stanislav Udin -> Vlad Sotnikov subj: SMUC VS>> Maybe I dug poorly?SU> Searched at the beginning of the table for the first 6 bytes, no matches SU> found it. ROM version 4.01, exactly the ROM from my Scorpio SU> is included in the Z80stealth emyl kit (I used to be Kirill SU> Kolpakovy sent a ROM file), so the image is complete SU> worker. And yet I did not find the one I needed SU> sequences... If there is no table, we can assume that the CRC is calculated without it, if so, then in order to find this procedure (and split the algorithm) you can do the following: On page 8, find the place where the mount sector is located (probably there are first 22*4=88 bytes) and look for access to this address from ROM. SU> But the off-topic topic worries me the least. I'm trying SU> write a program, first of all, for your real SU> Scorpa and for real SMUC owners. This is good ;) Everything is fast on the emulator, and there’s no point in connecting it all there ;) VS>> The most universal way is to change the sector through VS>> ports, as I described in the news. SU> I agree. You can easily change this sector not through ports, but through the standard onerestart ld c=36/37:rst 8:db #81, just need to connect first "arbitrary section" by descriptor: ld a,drive_number (0..3) or #20 ;(%00100000)connection by descriptor (DE) ld de,desc1 ld c,35:rst 8:db #81 ret desc1 db #01 ;partition type db #00,#00,#00,#00 ;starting sector dummy section db #04,#00,#01,#00 ;end sector of dummy partition db "Name01" ;fictitious names here... db "Name02 ; -//- ds #04 ;four empty bytes ;total 25 bytes Connecting “fictitious” sections in this way, I remember I rummaged through the whole screw, and independently discovered the auto settings sector;) SU>>> How can I solve this problem? Waiting for advice. VS>> So decide. :) SU> I understand that the only correct way is still manual SU> change the sector on the screw, but calculating the amount is not good... SU> Or maybe our geniuses will still be able to rewrite the code SU> subroutine without a table? In the end, I want to believe, not SU> I am the only one who needs this command (TRDN). Imho, it’s better to take 2k from the copy buffer, but finish the commander using a tabular CRC calculation (the procedure itself can generally be on the pagesomewhere to sit, it won’t be necessary to call it very often). SU> Stanislav SU> -+- ZX-Spectrum SU> + Origin: Speccy rulez forever!!! (2:5045/78.4) Stanislav, don't be bored! WbW, .i┌i└/4D. -+- └a┌a (┌o╒╘ 4.50 -=- [I.ZX] [GoA] [And mine Speccy 2 gig screw!] -=- + Origin: Everyone in the world is doing something without me... (2:5054/37.26) └── code ───

From Ewgeny Ivanoff To All 12 November 2005

Hello, CityAceE Cit> Maybe this letter will help in some way? The information is interesting, using the described algorithm you can “comb” the screw in searching for hidden settings and mounting tracks. But, unfortunately, it is already known that these tracks are “saved” on the disk are present. Having tried to “register”, for example, drive C, Scorpi rustled with the screw, itself sets the previously installed “track” for drive D. And vice versa, accordingly. Those. with storage of service information on the hard drive - full order.

From SMT To All 16 November 2005

Hello spensor I checked different options for connected disks in the emulator. CMOS, NVRAM not is changing. The table of connected images is located on the screw in sector 2 (if count from 0). from the beginning of the sector there are 4 22-byte entries, each describing 1 logical drive TR-DOS. the first byte - 0/1 - determines whether the image is FDD or HDD this letter. These 22 bytes also contain the name of the section and the name of the image. at the end sectors 4 bytes KS, if they are not correct, the table is cleared, connected images are unmounted. so take any HDD doctor and see what is at offset #42 (=22*2 - i.e. drive D:) after connection. if 0 - the problem is in the recording code, if 1 - in the settings reading code. You can also try the same version of the professional ROM as in emulator (or vice versa - load into the emulator...)

From Vlad Semchenko To All 16 November 2005

Hello SMT SMT> checked different options for connected drives in the emulator Thanks for your help! Valuable research. Everything is clear, but it’s not clear why there are problems with only two disks - to what extent? you can understand the entry in the same physical sector of the screw, BADs are explicit nothing to do with it. On the other hand, why again does it fail only for two disks - They have a common algorithm for recalculating the CS. It's all strange somehow...

From Vlad Semchenko To All 16 November 2005

Hello, ewgeny7 The topic is “frozen” :( Okay, I’ll throw in some “firewood” if no one has any ideas :) So, to transition to the “beta” state, we need to find out why it is not saved Association of drives C and D TR-DOS with disk images on the hard drive. I'll list All (IMHO) possible reasons that can cause this problem: 1. System area on the hard drive; 2. Write to NVRAM; 3. Write to RAM CMOS RTC; 4. The presence of unknown nodes in the SMUC electronics (shadow register?). Anyone who can suggest other options will be worthy of eternal glory :) Now what do we have with these options: 1. According to Evgeniy, everything is fine with the region, but IMHO, perhaps there is still some troubles; 2. The most likely reason, although the "NVRAM checksum error" message is not displayed; 3. It could also be considered “the culprit of the incident”, but the thing is optional, that is, not all SMUCs have them. It is possible that on SMUC without RTC with drives C and D The same troubles are happening, but no one wants to check; 4. The reason is among the first, but there is one “BUT” - in the US emulator it’s like this the problem is not implemented, but drives C and D are supported :( And although to refuse Ideas with a shadow register are too early (an emulator is not a real piece of hardware and the difference in behavior can be strikingly different - as SMT told us in the US SMUC worked without version ports, which would never happen in real life), there is little hope for this.If we assume that the problem is in one of points 1-3, then the glitch is enough perverted - the association of all drives (A,B,C,D), IMHO, should be stored in one place, but we see a completely different result :( Since it is useless to wait “from the sea for weather” (help from well-wishers), I suggest test the assumption with shadow register. To do this you need: 1. Connect another IR15 (DD15') chip in the same way as the main IR15 (DD15) all pins except for FD circuits (pins 2,9,10); 2. Assemble a unit similar to DD17.1,DD17.2,DD11.6 (instead of LP8 you can use LL1, and there is no need for resistors), only instead of the /CSM signal you need start the primary signal FD (signal from pin 6 of DD14.1). Signals CS0 and CS1 in the circuit becomes FD0 and FD1, respectively; 3. Signals FD0 and FD1 are supplied to DD15 and DD15' similarly to FD in the "SMUC on discretes". This way we get the main (DD15) and shadow (DD15') registers 7FBA. The chances of success are low, but it's worth a try. It is true that it is possible that switching can occur not with bit D7 of the FFBA port, but with some other one.

From Ewgeny Ivanoff To All 16 November 2005

Hello spensor Latest information from the fronts... :) I launched the HDDoctor (HDDSmuc) program sent by a well-wisher. I looked at the 3rd sector of the screw. Preliminarily - what is “written” in my monitor: A: SystemDisk01 B: GamesDisk01 C:SystemDisk02 D: GamesDisk02 When viewing the 3rd sector I found the corresponding lines: SystemDisk01.a Games.Disk01.- SystemDisk02.b Games.Disk02!. The dot means "space". The section name is allowed six characters, so after Games there is a “blank filler.” But that’s what the incomprehensible words mean characters "a - b !"? It looks like drives C and D are simply not marked anywhere... Here is such a tops...

From SMT To All 16 November 2005

Hello spensor What is the version of profzu? Yes, and we need to see what was recorded on the screw

From SMT To All 16 November 2005

Hello SMT If you look not at the text, but at the hex, what is the first byte of each 22-byte block?

From SMT To All 16 November 2005

Hello, ewgeny7 maybe there is no partition analysis and the ROM thinks that sysdisk1 and gamedisk1 are one and the same So that’s why it doesn’t allow you to push it into 2 drives at once?

From Sergey Sirotenko To All 16 November 2005

Hello SMT SMT> the table of connected images is located on the screw in sector 2 (if SMT> count from 0). This is if the hard drive is operating in CHS mode. In LBA mode the table is in sector 3. ewg> Launched the HDDoctor (HDDSmuc) program sent by a well-wisher. ewg> I looked at the 3rd sector of the screw. Preliminarily - what is “prescribed” for me ewg> in the monitor: ewg> A: SystemDisk01 ewg> B: GamesDisk01 ewg> C: SystemDisk02 ewg> D: GamesDisk02 ewg> ewg> When viewing the 3rd sector, I found the corresponding lines: ewg> SystemDisk01.a ewg> Games.Disk01.- ewg> SystemDisk02.b ewg> Games.Disk02!. Is it possible to do the same thing in HEX form starting from sector address 0? Here is the connection table format: +0 - subsection type (0 - no emulation) +1-4 - disk/subpartition address. +5 - subsection type +6-9 - disk/subpartition length +10-15 subsection name (6 bytes) +16-21 disk/subpartition name (6 bytes) and so on 4 times.

From Mick To All 17 November 2005

Hello Blade Here's a guess about 7fbah. Bits 6 and 7 used mean only that drives A and B can be physical (bit set) or logical (bit cleared). Disks C and D are always considered logical. Therefore, this register seems to function like necessary (his task is to save two bits). The reason for not saving information about the mountability of disks, I think, lies in non-volatile memory. From which after the start the ROM cannot read about the configuration of the current disk and accept it accordingly By default, physical drive A (well, like in a regular Speccy). And there are two memories on SMUC: CMOS and NVRAM.

From Ewgeny Ivanoff To All 18 November 2005

Hello Mick Mic> So there was an assumption about 7fbah. Bits 6 and 7 used Mic> means only that drives A and B Mic> can be physical (bit set) or logical (bit cleared Mic> bit).Disks C and D are always considered logical. Therefore this register Mic> seems to function as it should (its task is to save two bits). It may very well be so. I think this assumption is worthy :) Mic> The reason for not saving information about disk mountability, I think, is Mic> is hidden in non-volatile memory. But here it’s unlikely. Version with electric memory has already been discussed in detail above. Now, probably, the most reasonable thing would be to see what the dump of the 3rd looks like sectors (with "mounting tracks") on another Scorp with the original SMUK, well or on a full-fledged emulator :)

From Vlad Semchenko To All 18 November 2005

Hello, ewgeny7 ewg> the most reasonable thing would be to look at what the dump of the 3rd sector looks like (with ewg> "mounting tracks") on another Scorp with the original SMUK It would be nice to also see what is in the system area on your screw. Maybe you can still give me a dump to look at - the topic is visited by people who could to suggest what's really wrong with discrete SMUC. I hope that in the near future there will be a beta version (that is, a version to catch small glitches) release.

From Ewgeny Ivanoff To All 18 November 2005

Hello spensor spe> Maybe you can still give me the dump Maybe I’ll give it to you, but in general I’m greedy! :) I started copying from the screen yesterday, but my wife reminded me that “you hesitated,” and in general, go to the store! :) I'll post a dump a little later.

From Ewgeny Ivanoff To All 18 November 2005

Hello, ewgeny7 Well, I copied Chagoto! It is not visible on the screen, so errors are possible (such as 8=B). So, the beginning of the third sector: 01 20 00 00 00 01 01 05 00 00 53 79 73 74 65 6D 44 69 73 6B 30 31 01 61 FF 00 00 01 01 05 00 00 47 61 6D 65 73 20 44 69 73 6B 30 31 01 2D 05 00 00 01 01 05 00 00 53 79 73 74 65 6D 44 69 73 6B 30 32 01 62 04 01 00 01 01 05 00 00 47 61 6D 65 73 20 44 69 73 6B 30 32 21 00 DB EB 11 07 00 C3

From Andreas Kaiser To All 22 November 2005

Hello spensor spe> If we are talking about functions whose numbers are transferred in the C register, then spe> there are several functions that are really "dummies". spe> It can be assumed that they were involved in TR-DOS versions spe> v1.00-v5.00. But I can’t find a ROM file for those, but I think it would be possible spe> is of interest to many. By the way, was TR-DOS used in the Delta Disk Interface? And if so, which one? version? After all, this version differed from BDI by the presence of 128K memory (according to ZX-Review). Maybe these functions were used there?

From Mick To All 22 November 2005

Hello, ewgeny7 The other day I compared the TR DOS of my ZX-777 and a professional ROM and found that the procedures were not removed from TR-DOS, but on the contrary were added: 7fbah processing, font, The processing of rst 8 and rst 66 has been changed. So there is still a lot of space left there. Therefore question there is a table of functions for 3d13h - so there are functions that not used. Are they used anywhere at all? Version TR-DOS 5.03

From Vlad Semchenko To All 22 November 2005

Hello Mick Mic> there is a table of functions for 3d13h - so there are functions there Mic> are not used. Are they used anywhere at all? If we are talking about functions whose numbers are transferred in the C register, that is several functions that are really "dummies". You can assume that they were involved in TR-DOS versions v1.00-v5.00. But find The ROM file does not work like that, but I think it would be interesting to many.

From SMT To All 23 November 2005

Hello icebear There is nothing suspicious in the dump, all 4 disks are connected. optimal for debugging connect this screw to the PC and make an image (or work directly in R/O), and see in the emulator whether disks with such a 2nd sector will connect. if not, finish in the debugger step by step, finding out what is missing. I just scored this one dump into the screw image, but it disconnects all 4 disks because it reads the data further and does not find partitions. PS The CRC there, by the way, is a real CRC-16, with a preferred 256-byte label (CRC reader in TR-DOS ROM at address #21E5)

From Vlad Semchenko To All 23 November 2005

Hello SMT 2 SMT thanks for supporting the project!!!

From Ewgeny Ivanoff To All 29 November 2005

Hello spensor I assembled an "alternative" FDC port. A diagram (drawn in haste, I enclose. The result is still negative :( File: FDC.JPG http://zx.pk.ru/attachment.php?attachmentid=2015

From Vlad Semchenko To All 2 December 2005

Hello, ewgeny7 Tell me, has no one downloaded the file http://www.zxspectrum.it/doc/smuc.pdf? File too big (~16MB) to download for curiosity reasons. But maybe there are answers to some questions that arise in this topic.

From Vlad Semchenko To All 2 December 2005

Hello icebear ice> This is a manual, version SMUC 1.2, 47 pages are impressive. If necessary, I can ice> look more precisely on the weekend (in this case, knock on the PS). That is, in principle, the same document that weighs ~0.5MB in .doc? PS 4 icebear: If I managed to get through to your PS, clean out the “box”!

From Stanislav Yudin To All 2 December 2005

Hello icebear ice> I don’t know what he’s missing anymore. You need to clean not only the inbox folder, but also the outbox folder. Yes limit of 50 letters in all folders.

From Andreas Kaiser To All 2 December 2005

Hello spensor spe> Tell me, no one downloaded the file spe> http://www.zxspectrum.it/doc/smuc.pdf ? The file is too big spe> (~16MB) to download out of curiosity. But maybe there spe> there are answers to some questions that arise in this topic. This is a manual, version SMUC 1.2, 47 pages are impressive. If necessary, I can look more precisely on the weekend (in this case, knock on the PS).

From Andreas Kaiser To All 2 December 2005

Hello spensor spe> PS 4 icebear: If I could get into your PS, clean out the “box”! I swear to my mother, yesterday there were only 10 messages in PM, now there are only two left. I don't know what he's missing anymore. Moderator, don't insult me for personal reasons. correspondence. Spensor, try again.

From Ewgeny Ivanoff To All 13 December 2005

Hello, ewgeny7 P.S. Since SMUK is already assembled and working, today I bought mikruhi for ProfPZU "on discretes". It wouldn’t hurt to try out this super device, or rather, compare it with "original" Prof :)

From Ewgeny Ivanoff To All 13 December 2005

Hello spensor The time has come to sum up some results of “communication” with SMUK in a new reincarnation :) First of all, I want to thank Vlad Semchenko for developing “in discretes” this wonderful device. I've been dreaming of purchasing this controller for a long time, but... The “build it yourself” option turned out to be much more interesting :) The SMUK was assembled gradually, in separate functional modules. This brought some puzzles in understanding the principles of its operation, for example problems with determining the presence of a controller. Skorpi saw SMUK only after he was NV-RAM module assembled. In the absence of SMUK flash memory, the computer simply cannot was determined. At the moment, SMUK is assembled and working conscientiously, mostly at night, because I only have free time after the midnight roosters :) The issue of “mounting” virtual disks has not yet been completely resolved. When working with SMUK, it was noticed that all four disks have some “pairwise” communication, i.e. drive C “remembered” its mount track when “moving” settings of drive A. A similar connection was observed with drives D and B. At the same time, drives C and D stubbornly refused to “restore the tracks” on their own after restarting the computer. But the situation changed dramatically after installation and subsequent removal of the additional alternative FDC port. Now it's alreadyno, but the question of its necessity still remains. When he was present on the board, I did not see any changes in the operation of the controller. But "closer to the body" :) After fiddling with the FDC port with a soldering iron, SMUK changed the logic of working with disks. Now all four disks are perfectly “saved” and “restored”, but only on the condition that it remains “mounted” until the computer is turned off at least one (any) disk. If you “erase” the tracks of all four disks, then... At this point, the “tracks” of any disk are no longer restored. The only way out is to connect the screw to the emulator (thanks SMT) and already in emulator to “register” virtual disks again. What is the reason for this "behavior" - I don't know. I am inclined to think that it is no longer the iron that is to blame, but software part. Generally speaking, I don’t have any of the ProfPZUs I have. I bought it officially, so we can only guess about possible glitches in the ROM :)

From Vlad Semchenko To All 13 December 2005

Hello, ewgeny7 ewg> P.S. Since the SMUK is already assembled and working, I bought mikruhi for today ewg> Professional ROM "in discretes". It wouldn't hurt to try out this super device, ewg> more precisely, compare it with the "original" Prof :) That is, if I understand you correctly, this is an offer to become a beta tester and ProfPZU? Very necessary! Your homeland will not forget you!

From Vlad Semchenko To All 13 December 2005

Hello spensor The scheme has been updated to version v0.0beta. Watch at the beginning of the trade.

From jtn To All 13 December 2005

Hello spensor spe> In addition, Maksogor said that in practice it turned out to be impossible spe> simulate VG when working from a hard drive. Therefore, this is done in ATM spe> from a RAM disk, which takes up almost all the memory. spe> Well, to put it mildly, someone is wrong here

From Alexey Korotkov To All 9 March 2006

Hello, ewgeny7 I couldn’t vote in the poll -) It’s already closed. I became the owner of Scorpa with SMUC 1.2, I am currently resuscitating it. I am interested in the possibilities and will subsequently try to help in any way I can. _________________________________________________________________ Now the question is a little off topic. Is it possible to connect a PC keyboard to Scorpio? And if possible, how. P.S. Sorry, the question is completely off topic, but I don’t want to create a new one, but searching somehow he didn’t give anything. If possible, please email mototeam(dog)nm.ru or ICQ 50925088, so as not to clog the forum-)

From Alexey Korotkov To All 9 March 2006

Hello, hero I went to the link - looked ... everything would be fine but the schemes, templates .. there are no ...

From Dmitry Demyanenko To All 9 March 2006

Hello Zerios Here is http://scorpion.ru/spectrum/hard/kontroller_IBM.htm dear. Plus Caro developed a more serious device called ZX Multi Card, there’s a mouse and keyboard and all PS/2 and also a carriage and a small cart.

From Alexey Korotkov To All 13 March 2006

Hello spensor My system doesn’t call itself anything at all yet, because the whole computer is solid ruins....reanimating. As soon as it works, I'll post it.

From Vlad Semchenko To All 13 March 2006

Hello Zerios How nice it is sometimes when your topic is “raised”! Zer> I couldn’t vote in the poll -) It’s already closed. Well, what can you do, it was relevant then, now there is already certainty. Zer> I became the owner of Scorpa with SMUC 1.2, I am currently resuscitating it. Zer> I am interested in the possibilities and will subsequently try to help in any way Zer> I can. ewgeny7 and I will not refuse help. If you have any questions about the device, ask! First question for you: does SMUC1.2 call itself “1.2” or “1.3” in the system? Bye the facts indicate that the even version cannot be "highlighted".

From Vlad Semchenko To All 11 August 2006

Hello, ewgeny7 ewg> Can anyone check the above information? Are there really no people who could help ewgeny7 (and me too)?! Sympathizers project, please check ewgeny7's assumption! This is necessary to complete device to a complete state - SMUC v0.0 has been in beta state for almost a year now... No programming knowledge is required here, everything is checked in the user's level using ProfPZU.

From deathsoft To All 17 September 2006

Hello, ewgeny7 > Analysis of two circuits of original (branded) ProfPZU boards forced > assume that there is/was supposed to be a mechanism for working with 32 > pages C in both circuits, pin 31 (for 27C040 this is A18) > is/can be started on the FPGA and connected via a ballast resistor > to +5V. Whether the guess is correct is unknown. In one of the manuals from the Scorpion company (I don’t remember which product, it seems like profPZU), it was written that for microcircuits 27040 the choice of halves of microcircuits carried out by a switch (which supplied either 0 or 1 to the high address), so if you look at the ROM firmware, you can see that the pages with BASIC trdos and monitor are present in both halves. The difference between the ROM halves was only in programs flashed into the ROM disk.

From Alexander Yudin To All 12 October 2006

Hello deathsoft What is the current state of affairs with SMUC, has it been possible to resolve questions with mounting? is it possible to route the board, assemble and Is it okay to use it? On the diagram there is a connector for CompactFlash. I understand correctly that if you connect only one card and work with it will be exactly How about a screw without any changes in the software?

From Vlad Semchenko To All 12 October 2006

Hello Costa Thank you for your interest, otherwise it seems that in addition to two or three no one needs this anymore... Cos> What is the current state of affairs with SMUC, has it been possible to resolve Cos> questions with mounting? is it possible to route the board, assemble it and Cos> is it okay to use it? You can collect and use. But it’s probably not worth breeding - logic the work seems to have been guessed, so you can switch again to FPGA, but with open "source codes". The issue with mounting disks seems to have been resolved. reported by ewgeny7 (incorrect operation of ProfPZU in LBA mode): http://zx.pk.ru/showpost.php?p=54927&postcount=220. It is quite possible that this the problem is observed only in its firmware version, but can no longer be tested on than and no one. Cos> On the diagram there is a connector for CompactFlash. I understand correctly that Cos> if you connect only one card and work with it will be exactly Cos> how to use a screw without any changes in the software? In theory, yes (the command system is ATA compatible and should work without problems), but need to be tested in practice. In general, this could be checked, but alas problem with the CF connector (it is not known where to buy the connector, but screw the Card-reader the hand will not rise).

From Mark Antonov To All 12 October 2006

Hello spensor spe> oh, alas, there is a problem with the CF connector (it is not known where to buy the connector, but spe> the hand will not rise to fool the Card-reader). [22:04:31] In Chupadips www.chip-dip.ru

From Evgeny Muchkin To All 13 October 2006

Hello spensor spe> Thank you for being interested, otherwise it seems that except spe> two or three people no one needs this anymore... spe> I'm following the topic. And I look forward to the completion of this much needed project. :) I would love to buy this wonderful device.

From Vlad Semchenko To All 13 October 2006

Hello, The Exploited The> In Chupadips The> www.chip-dip.ru Thanks for the hint. As far as you can understand, the connectors are called “CFC-...”!?

From Alexander Yudin To All 13 October 2006

Hello, ewgeny7 ewg> Now I “read” watches even from Barsik. And in the original it was also impossible to read from the bass?

From Ewgeny Ivanoff To All 13 October 2006

Hello, Evgeny Muchkin Evg> And I look forward to the completion of this much-needed project. I've been using SMUCse for quite some time. I can say that "discrete option" quite functional. Since I turned off the LBA, the controller has been working flawless. I didn't notice any difference in speed. Collect safely, or wait subsequent version with FPGA :) The only difference from Vlad Semchenko's scheme is that I cut off the DOS signal. Now I “read” watches even from Barsik.

From Vlad Semchenko To All 13 October 2006

Hello Costa Cos> And in the original it was also impossible to read from the bass? Yes, because access to the SMUC ports was only possible from TR-DOS, and work with ports were only possible through two entry points in the TR-DOS firmware (which use ProfPZU firmware procedures). In a word, read/write ports It was possible only from code; BASIC is incapable of this. SMUCse in this regard (in primary implementation) is identical to the original circuit. Cos> It’s also interesting why the Scorpio people made a watch for mikruhi Cos> external generator on LH2? In principle, this generator was not in any of the SMUC photographs that I had to see. I don’t know why it was introduced into the scheme, perhaps there were some RTC chips without an oscillator unit, or cases of poor starting have been known built-in generator.

From Alexander Yudin To All 13 October 2006

Hello Costa I also wonder what Scorpios are for Did you make an external generator for LH2? :v2_conf2:

From Ewgeny Ivanoff To All 16 October 2006

Hello Costa Cos> I also wonder what Scorpios are for Cos> mikruhi watches made an external generator on LH2? With an external generator from a standard battery, in my opinion, the hours do not pass for a long time

From Grand To All 12 November 2006

Hello, Evgeny Muchkin spe> People, can anyone help with disassembling and reworking the firmware spe> ProfPZU?! I believe that work on reworking the ProfPZU procedures should be publicly discussed on our Forum. For example, the TR-DOS ROM in ProfPZU V4.1 is so “plowed” that compatibility has seriously suffered, it would be desirable to correct all this. In addition, the disk BIOS and shadow monitor procedures also have serious errors - if necessary, I can attach a list of what I found.

From Evgeny Muchkin To All 12 November 2006

Hello Grand Gra> if necessary, I can attach a list of what I discovered Of course, post it, maybe you won’t need it right now, but then it will be easy to find.

From Vlad Semchenko To All 13 November 2006

Hello Grand Gra> I believe that work on remaking ProfPZU procedures should be universal Gra> to be discussed on our Forum. For example, TR-DOS ROM in Professional ROM V4.1 Gra> is so “plowed” that compatibility is seriously affected - Gra> it would be desirable to correct all this. In addition, disk BIOS procedures Gra> and the shadow monitor also have serious errors - if necessary, I can Gra> attach a list of what I discovered. You need any materials on ProfPZU (PP), be it just information from magazines (in your There have been publications in various E-magazines for a while, but it’s simply impossible to rummage through everything), PP firmware of different versions (but mainly starting from v.4.00, since only it received support from SMUC) or its own research! For any I would be very grateful for this kind of information!

From Grand To All 15 November 2006

Hello spensor I worked with versions of ROM 2.95 and ProfPZU 4.1. List of errors, with which I had to encounter in these versions is given below. If anyone has different results, or has information on other versions, then I propose to report in this thread for now ("SMUC on discretes"). Perhaps there will be a discussion on this issue, then we’ll ask the moderators create a new topic and move our messages there. :) Fatal errors V4.1 * Crash when calling function 8 (TR_DOS) "Disk identification for TR-DOS OS" disk BIOS (#81) * The Autostart option in the Disk utility menu does not work * The Disk option in the Print screen menu does not work * In the case of No disk, TR-DOS does not stop the operation (you must press BREAK) * Many programs do not work (for example, ADS V2.0p); doesn't work correctly MagOS V6.3c Non-fatal errors V4.1 * In the monitor command line, when you press the "down arrow" it is not called last line entered * In shadow monitor, when outputting a directory, the first character of the deleted files is not triangle, as in version 2.95, and "B" * In the monitor from the disassembler (SS/D) according to EDIT/C, sometimes a return to Main occurs menu, not the monitor command line * It is necessary that the monitor command "?" showed CP-866 symbols and in the range 128...255, if their display is enabled Fatal errors V2.95 * The Track command in the Set UpDisk Utility menu does not workErrors that migrated from the first versions up to 4.1. * The trap does not fire (instead of transferring control to the shadow monitor the standard BASIC error handler is called) if a memory bank is installed different from 0. * If there are 128 files in a directory, then the operation to display it on the screen "loops" (it can be interrupted by EDIT) * When displaying a directory, the presence in the names of symbols with codes not in the range 32...127 leads to a variety of video effects * The SPECTRUM command in BASIC 128 works, but instead of the message 0 OK, it displays nonsense * When entering the shadow monitor, the music processor is not completely muted * Whenever RST 8 is called, the screen becomes active according to bit 3 of the cell 23388 (in BASIC 128 this is the system variable BANKM), but it can contain also a random value * If Caps Lock is enabled on the monitor command line, then hot keys do not work keys in the disassembler command (SS/D) * If you type a command in the monitor command line, then move the pointer addresses from the dump, then press Enter, the message Working... will not appear. * Return from SetUpDisk Utility occurs in the Main menu, not in Set Up * In the ring buffer of the monitor command line, it would be necessary to remember only the lines with no syntax errors

From Evgeny Muchkin To All 15 November 2006

Hello, Mikka_A Mik> Useful and, alas, sad information... Don't be so upset :) Scorpio and relish still work despite this abundance :)

From Evgeny Muchkin To All 15 November 2006

Hello, Mikka_A Mik> there is simply no prospect of fixing bugs. Well, I think it’s not all that bad. I want to dig into the professional ROM myself (see the topic about 4 drive), in principle, if I run into the glitches described above, if possible I will fix it. Debug in emula. :)

From Vlad Semchenko To All 15 November 2006

Hello Grand 2 Grand and everyone who understands the issue: There is a point in the ProfPZU firmware by which you can find out the firmware version (not launching the emulsion, and just looking at the ROM dump)? Who has the revisions of version v4.x, how many there were and under what numbers. It is known that v5.x was already running under GMX, and versions before v4.0 did not have SMUC support. Are v4.1 and v4.01 the same thing or not?

From Mikhail Andreev To All 15 November 2006

Hello, Evgeny Muchkin Evg> Don't be so upset :) Scorpio and relish still work despite Evg> for this abundance :) Yes, that's understandable. there is simply no prospect of bug fixes. that's what I meant...

From Mikhail Andreev To All 15 November 2006

Hello, Evgeny Muchkin Evg> Well, I think it’s not all that bad. I want to dig into the professional ROM myself (see topic Evg> about 4 disk drives), in principle, if I run into the glitches described above, by Evg> I will correct the possibilities. Debug in emula. :) That would be great. I hope that your enthusiasm will not fade away! :biggrin; PS. Knock; in Asya....I have a couple of questions.

From Mikhail Andreev To All 15 November 2006

Hello Grand Gra> I worked with versions of ROM 2.95 and ProfPZU 4.1. List Gra> errors that I encountered in these versions, Gra> is shown below. Gra> [/list] Figase. Useful and, alas, sad information... :v2_down: