Screw for ZX

Aaa, it's time to relax, All. In a few months I will probably install the subject. Since there is nothing about Neos I can’t hear it, then I see the only way out is to support the file system MS-DOS. TR-DOS programs are planned to be kept as .trd files and in DOS access the screw/MS-DOS floppy disk if the program reads/writes some information, and it doesn’t matter how: through #3D13 or through ports. I plan to do everything on one 62256 (32Kb static) and connect power to it 3..5 V, so that the information is constantly stored there. In one half there will be there is a modified DOS, and in the other there is a file system and a program that will start after reset. Control 62256 can be hung on, for example, port #CFF7. What do you say to this? Well, till next time... ██▓▓▓▒▒▒░░░ ╔══ Sergey aka Cyber from Cobra Software ══╗ █▓▓▓▒▒▒░░░ ╚═══════ 500:322/62 ═══ 2:462/167.62 ══════╝

Press RESET immediately, Dmitriy! 09 Jan 01 10:19, Dmitriy Nesmachny wrote to Valerij Kozhevnikoff: DN> I’ve been wanting a screw for myself for a long time, but what should I install? I would like to use TRDOS DN> I went, but it’s only a scorpion, I don’t want to put a professional qualification on my pent, DN> as far as I understand, firstly the floor of the scheme is to plow up, secondly it DN> it’s not quite like there will be a Pentagon... SS promised, promised, I DN> I waited and waited, but alas... DN> P.S. Or maybe you and SS can team up and write software together? In your DN> this is a lot of experience, as I understand it, there is more than one driver for the screws on yours DN> conscience? ;-) The driver is the latest thing, isn't it clear? The driver can also be from take it desperately. Think about how you will store the disks on the screw and what you will what to do if your super-spectrum dies and you need to get the file. Look, the Scorpio people are suffering... I’m giving you an idea, now you’ll say again that pissing it is very: put trdshniks inside imgshnikov (disks from is-dos), and imgshniks in in turn put in a regular veil. Well, or immediately put it in a veil. And celebrate the veil as primary and extended screw partitions. Only for gigabyte sizes will have to fat32 to master. DN> P.P.S. Shouldn't we go to HARDWARE with such markets?.. From iron, someone wrote me such a clever idea: to build a circuit that would forbade appeal to VGshka and pulled NMI when accessing VGshka ports in the TR-DOS region ROM. Well, change the ROM a little. On my own behalf, I can add that reworking the ROM can consist only in installing a jump to a program in RAM that is previously there should be loaded and writing a loader for example is-dos from BASIC-128. Without memory (can minimum) It will be very difficult to emulate tr-dos. It’s better to keep its emulator in RAM - it's easier that way install new versions, no need to bother with reprogramming ROM.

Press RESET immediately, Sergey! 03 Feb 01 10:32, Sergey Selev wrote to Kirill Frolov: DN>>> the super-spectrum will not be repaired... By the way, why "super"? KF>> Because such a skein of MGTF is no longer easy KF>> computer... SS> What other skein of MGTF is this? Have you seen my computer? Quite decent SS> looks, the wires lie neatly on the board and under it. I haven't soldered much yet... KF>> Software... What for? Buy a pussy and don’t suffer. It will be cheaper. SS> Of course! 80% of them will immediately become unnecessary. What echoes? KF>>>> Someone wrote me such a clever thought from iron: KF>>>> build a circuit that would prohibit access to the VGshka and pull KF>>>> HMI when accessing VGshka ports in the TR-DOS ROM area. SS> I actually went the other way: I made myself open ports and that’s it. You didn't understand anything at all! How do you make programs work with turbo loaders? Whether they are open or closed, it makes no difference. KF>> There are two options here: either a pure software implementation, KF>> when you only need to flash the ROM but have a larger one KF>> incompatibility with old programs, or partially hardware related KF>> when you can install a separate part of RAM. I'm afraid the second solution KF>> will be unpopular. For example, for owners of Kayev s SS> Both decisions disgust me. Is there a third one? I don't see any other options (except for buying a pussy). KF>> ROM only. That is, only the circuit remains from the hardware KF>> which generates NMI when accessing BETA-DISK ports KF>> interface. SS> Why is all this? Then, so that you can force music downloaders to start from the propeller (probably with a wild howl...) SS> I made myself a port that manages the cache and open ports. SS> IN (%a11110bc) SS> a=0 cache open SS> a=1 cache closed SS> b=0 drive controller ports SS> b=1 computer ports SS> c=0 lower 16Kb SS> c=1 top 16Kb ^^^^^^^^^^^^^^^^^^ What is this crap doing with kilobytes? :-/ SS> Here's what I tried: SS> in (#79) SS> ld a,8 SS> out (#1f) SS> in (#7b) SS> This program does what was previously done with SS> ld bc,#2fc3 SS> push bc SS> jp #3d2f Well, what is the practical benefit of this? SS> Only if you need to do it from the cache, then you will have to here SS> resident write or something like that. And all I need is SS> replace #79 -> #f8, #7b -> #fa. And you also don’t know Spectrum hardware. From the cache you can get access to TR-DOS ports is elementary! Like this: org xxx call open_trdos in... out... ; format A: call close_trdos .... org 0x3dxx open_trdos: ret org >=0x4000 close_trdos: ret SS> Now you need to write a BIOS for the cache and everything will be cool. Old SS> programs will run unchanged, and new ones can use SS> BIOS routines. Just don’t say that this piece of iron SS> is difficult to do. So you don’t need to do any hardware. But you don’t have the old ones from the screw they'll go. KF>> Well, what am I talking about? :-/ TR-DOS should only load KF>> boot sector which in turn loads the system. And it will be there KF>> is-dos or tr-dos emulator is up to the user. SS> Exactly! The BIOS installer is loaded from a hard diskette and in it SS> you need to make a function to load the boot sector from a screw, for example. It's stupid to just boot from a diskette when there is a screw.

Hello Kirill! Saturday 17 March 2001 00:11:28, Kirill Frolov -> Dmitriy Nesmachny: DN>>>> This little thing made me happy: what if we are a screen DN>>>> loaded? How to determine BEFORE a disk operation, which DN>>>> areas DN>>>> memory will be affected (we mean that all procedures DN>>>> not DN>>>> are standard and data for them can also be pushed DN>>>> on DN>>>> stack before DN>>>> by calling #3D2F)? KF>>> You need to know in advance. Or keep the stack above 0x3fff: DN>> How do you know in advance? By the method of predicting the future? KF> How will you know in advance what address it will be from KF> go read/write? KF> Exactly the same. Maybe I didn’t understand something: you are a method for newly developed programs are you making this up, or for #3D2F emulation? If the first, then everything is clear with you, but if the latter, then there is such a feature (if you don’t know): address of the reading procedure pushed onto the stack, the write address was pushed, the address of the POP HL:RET combination was pushed, the address of something where we need HL was pushed, the return address was pushed and on#3D2F jumped. The ROM switched, the program called up, spoiling HL, then "returned" to POP HL:RET, pushed HL, "returned" to read, then return in RAM. Tell me what kind of clever analysis can be used to calculate where we should read what? will we be after the #3D2F challenge? KF>>> push 0xc9 KF>>> ld hl, 0 KF>>> add hl, sp KF>>> call xxx KF>>> xxx: jp (hl) DN>> IMHO, a hash purely for the TR-DOS emulator on a screw is better DN>> cook up: KF> ^^^^^ KF> Do you mean RAM? DN>> well, TR-DOS has its own ROM, so let him have it DN>> there will be an emulator and RAM, at address #C000 for example DN>> connected... Everything will be saved in it. KF> IRRATIONAL! Not so much... IMHO... KF> Not reliable. Why? Will it overweight and cause the computer to fall off the table? ;-) KF> Expensive. Not more expensive than cash. KF> Just stupid. Well, of course, the smartest one is you, the great one, what do we care about, boars... ;-)KF> Buy an 8MB SIM card for the same money and connect it. Scheme for KF>connection KF> I gave any cans to any place. You gave it, but there are a couple of complaints about it: Not rational. Not reliable. Expensive. Just stupid. (c) K. FROLOV. Best regards, Dmitriy.

Press RESET immediately, Dmitriy! 19 Mar 01 10:25, Dmitriy Nesmachny wrote to Kirill Frolov: DN>>>>> loaded? How to determine BEFORE a disk operation which DN>>>>> memory areas will be affected (we mean that the procedures are all DN>>>>> are not standard and data for them can also be pushed DN>>>>> on the stack before calling #3D2F)? KF>>>> You need to know in advance. Or keep the stack above 0x3fff: DN>>> How do you know in advance? By the method of predicting the future? KF>> How will you know in advance what address it will be from KF>> go read/write? Exactly the same. DN> Maybe I didn’t understand something: you are a method for newly developed programs DN> are you making this up, or is it for #3D2F emulation? If the first, then everything is with you DN> is clear, but if the latter, then there is such a feature (if you don’t know): address DN> read procedures pushed onto the stack, write address pushed, address DN> POP HL:RET combinations have been pushed, the address of something is where we need HL DN> pushed, pushed the return address and jumped to #3D2F. Switched DN> ROM, a program called up that spoiled HL, then “returned” to POP HL:RET, DN> pushed out HL, “returned” to reading, then returned to RAM. I'm trying to understand what you wrote: push (read procedure address) push (record address) push (pop_hl:ret address) push (address of something) push (return address) jp 0x3d2f 0x3d2f: pop hl ret return_address: .... Glitch? DN> Tell me what cunning analysis can be used to calculate where we should read what DN> will we be after calling #3D2F? Will your program read? If so, then she should know where and from where. If not, why are you so worried about the address? I don’t understand why emulate 0x3d2f at all. It's damn hard practically unrealistic. It’s easier to instruct frequently used procedures in tr-dos transitions to their emulation programs. In fact, there are only a few programs: reading array from the controller, writing an array to the controller, emulating registers and signals interrupt requests. In general, in the original letter I wrote how to access registers from the cache beta disk interface, how this relates to controller emulation (on a hard drive?) I don’t know. :-/ DN>>> well, TR-DOS has its own ROM, so let him have it DN>>> there will be an emulator and RAM, at address #C000 for example DN>>> connected... Everything will be saved in it. KF>> RATIONAL! DN> Not so much... IMHO... Neither in the sprinter, nor in Scorpio, nor in any other way is this done. You understand why? The program for the Spectrum costs practically nothing, unlike the excess (EXTRA!!!) iron KF>> Not reliable. DN> Why? Will it overweight and cause the computer to fall off the table? ;-) More chips means less fault tolerance. KF>> Expensive. DN> Not more expensive than cash. Let's count: $2 ROM, $1 RAM, $2 logic and other small items, $2 printed circuit board. Is your work soldering this device to the Spectrum free? KF>> Buy an 8MB SIM card for the same money and connect it. Scheme for KF>> I gave connections to any can to any place. DN> You gave it, but there are a couple of complaints about it: DN> Not rational. Rational for what? Play with Spectrum toys? Of course not rationally, it's not needed there. On the Spectrum in general there are programs that need such no possibilities observed (due to the lack of these capabilities). DN> Just stupid.Justify. It wasn’t just invented for the heck of it. It gives fundamentally new possibilities for implementing programs on the Spectrum that for the classic ZX-48,128...1024 it is IMPOSSIBLE to implement. Regular Spectrum can change all 64kb memory banks available in a few microseconds microprocessor? I hope you can guess how this can be applied? DN> Expensive. Less than $2. DN> Not reliable. Much more reliable than your miracle controller. And as for rationality - here explain Why is this miracle controller needed if almost everything is the same (visually not you can tell the difference) you can do it and without him? For some, emulating 0x3d13 in SMUK is quite enough - MMD there works and most programs start. And the most important thing is for users to collect this for themselves they won't. I'm telling you exactly. But if you can buy from Hemo kai with a controller and stick it in more different ROM then it will be a completely different matter.

Hello Kirill! Monday 26 Mar 2001 00:12:46, Kirill Frolov -> Dmitriy Nesmachny: DN>>>> How do you know in advance? Prediction method DN>>>> of the future? KF>>> How will you know in advance what address it will be from KF>>> go read/write? Exactly the same. I see. I just didn’t understand you: I thought you were making a TR-DOS emulator, transparent to (old) programs. Do you offer it purely for new programs? Not I see the point. [skip] KF> I'm trying to understand what you wrote: KF> push (read procedure address) KF> push (record address) KF> push (pop_hl:ret address) KF> push (address of something) KF> push (return address) KF> jp 0x3d2f KF> 0x3d2f: pop hl KF> ret KF> return_address: .... KF> Glitch? Well, sorry: I mixed up the order. PUSH (return address) PUSH (read/write address) PUSH (address of the buffer that we will read/write) PUSH (POP address HL:RET) PUSH (address of something else) JP #3D2F Then everything is ok. DN>> Tell me what kind of cunning analysis can be used to calculate where we are DN>> what to read DN>> will we be after calling #3D2F? KF> Will your program read? If yes, then she should KF> know where and where. KF> If not, why are you so worried about the address? My program knows that. Only she won't tell you. Just because it's about yours I’ve never even heard of a piece of iron. KF> I don’t understand why emulate 0x3d2f at all. It's the same KF> damn difficult, practically KF> is unrealistic. Easier on-site frequently used procedures KF> tr-dos instruct transitions KF> to their emulation programs. In fact, it turns out everything KF> several programs: reading an array KF> from the controller, writing an array to the controller, emulation KF> registers and interrupt request signals. Well, at least this way. KF> In general, in the original letter I wrote as if from cache KF> access beta-disk registers KF> interface, as it relates to controller emulation (on KF> hard drive?) I don’t know. :-/Ah... Yes, the little ones have moved out... ;-) We need to keep an eye on the subjects even more right... ;-) DN>>>> well, TR-DOS has its own ROM, so let him have it DN>>>> there will be an emulator and RAM, at address #C000 for example DN>>>> connected... Everything will be saved in it. KF>>> RATIONAL! DN>> Not so much... IMHO... KF> Neither in a sprinter, nor in a Scorpio, nor in any other KF> done. Do you understand why? KF> The program for the Spectrum costs almost nothing KF> differences from superfluous (EXTRA!!!) KF> iron. In any, ANY, Spectrum with a Beta-Disk Interface, it is done on this principle. And ZX-LPRINT-III also works the same way. Only they substitute the ROM, but which one? the fundamental difference between ROM and RAM in terms of circuit complexity? KF>>> Not reliable. DN>> Why? It will outweigh and the computer will be removed from the table DN>> fall? DN>> ;-) KF> More chips means less fault tolerance. Well, there is no escape from this. Spectrum has 80-120 microcircuits in approximately differentmodels. 5-8 extra ones won't change much. Especially if this bullshit is on a separate board and it can be tested and repaired separately from the computer. KF>>> Expensive. DN>> Not more expensive than cash. KF> We count: $2 ROM, $1 RAM, $2 logic and other little things, $2 KF> printed circuit board. Does the ROM cost 60r? IMHO less... Although I won't argue. But I would like these I gave the money easily: this thing is very necessary. At least I need it. KF> And your work on soldering this device to the Spectrum KF> free? Absolutely. No one will give me money for this... ;-) KF>>> Buy an 8MB SIM card for the same money and connect it. Scheme for KF>>> I gave connections to any can to any place. DN>> You gave it, but there are a couple of complaints about it: DN>> Not rational. KF> Not rational for what? To Spectrum toys KF> play? Of course not rational KF> it is not needed there. On the Spectrum in general there are programs for those in need KF> in such possibilities is not KF> is observed (due to the absence of these capabilities).Well, there are no such programs. No. Kirill, if Sir Clive had made this thing Sinclair, that would be cool, everyone would focus on that, software would be written, and so only you have it, so I’ll make it, so what? I write software not only for myself (although this thing would help me a lot, frankly speaking: it would remove the main problems, but this program will not be needed by anyone except you and me, and since If you don't use EMS, then you don't need it either. Well, why should I suffer? what if no one needs this program except me? DN>> Just stupid. KF> Justify. It wasn’t invented just for the heck of it. KF> It provides fundamentally new possibilities for implementation on KF> Spectrum of such programs that are for classical KF> ZX-48,128...1024 is IMPOSSIBLE to implement. Regular Spectrum KF> can change all memory banks in a few microseconds KF> 64kb available to the microprocessor? How this can be applied KF> I hope you can guess it yourself? It’s cool, it’s cool, it’s worldbest, but see above: you’re not Clive Sinclair, but It's not 1986. :-((( DN>> Expensive. KF> Less than $2. I evaluate the ratio of price to actual (not potential) expectedusefulness. Alas, I don’t expect any benefit from it (real, that is, supported programs and users for whom I could write these programs). DN>> Not reliable. KF> Much more reliable than your miracle controller. What about KF> rationality - explain here KF> why is this miracle controller needed if almost everything is the same KF> (visually indistinguishable) can be done KF> and without it? For some, emulation of 0x3d13 in SMUK is quite good It’s not that it’s so necessary... I’d like at least #3D13, but for the Pentagon, and not for Scorpio. KF> enough -- MMD works there and KF> most programs run. And most importantly - users KF> they will not collect this for themselves. KF> I'm telling you exactly. But if you can buy from Hemo kai s KF> controller and plug it into it KF> more different ROM then it will be a completely different matter. I don't want kai. I am disgusted by this approach to users like Hemo's. I I believe that if I bought a computer, I have the moral right to modify it so as I need, but Nemo denies it. And anyway, what does Kai have that wouldWas it worth buying it? If I buy a new spec, I'll buy a green scorpion or sprinter. Best regards, Dmitriy.