[!][!][!]

Press RESET immediately, Alex! 21 Oct 00 21:05, Alex Gerasimov wrote to Kirill Frolov: AG> You once threw a circuit into the echo that allowed you to turn on any bank AG> RAM in any place from #0000 to #ffff, so... you have a scheme AG> supported only 256 kilo... could you make such a circuit AG> which supported 1024 kilos... Of course, you can do it on 4Mb - this is the maximum for 8-bit registers. But 256kb was precisely because it provided a very simple and uniform connection to any Soviet zx-spectrum clones with memory >=128kb. What if If I make the register width not 4, but 8 bits, then it will be completely different connect to different zx-spectrum clones, even for example in the case of Scorpio With 1Mb of memory, different options are possible. AG> I have a scorpion...And I noticed that when reading from the screw into the area AG> #8000-#c000 data is sucked in at a speed of 80-100 kilos per second... AG> and now if the banks are substituted not with #c000, but with #8000, then the result is AG> face... If it doesn't break, of course... do it, plzzz... Speed problems are generally not solved using exactly the same methods. As for supporting 1Mb, then expand the existing scheme to 8 bitsI will never do it, for the reason described above. I only agree to A universal and fast-working method for all zx clones. With circuit on register 4x4 256kb this is the limit and works quite slowly. If you have any ideas on how to implement ^^^ what I am here wrote, then write, I’ll think about it. If you’re not too lazy to still work with a soldering iron, then write too, I have my own ideas, a fundamentally new way, maybe be a little difficult to implement. The idea is not to switch commands out (x), x jars and spend precious processor time on this -- loading registers and executing the out command. Banks can be switched shorter commands, for example 2 bytes in 8 clock cycles, single byte in 4 beats. Moreover, switching jars is not efficient at all, I want make it so that you can access any data memory, assuming that the same addresses will contain executable code. In fact, the desired bank will be turned on for a very short time, just to read or write an operand from memory and it won’t take anything away processor time. I'm just expanding the address space of the processor over 64kb. How I imagine the implementation of the above nonsense: Option 1: Fast-acting PLM - the ideal way. Option 2: ROM capacity ~64kb, there is a maximum limitprocessor clock frequency determined ROM speed. Option 3: Fine logic and possibly fast ROM small volume. It will be a complex scheme. I like the second option better: I don’t understand anything about programming modern PLMs and I can’t even imagine how this could be implemented. I'm also not sure that the circuit according to option 3 will be easy to assemble and debug. And if you use a large ROM, the circuit can be assembled by any pioneer with a soldering iron and she will either make money or not. How will it work: the ROM connected to the data bus will analyze the stream of commands read by the processor and in a certain way respond to individual commands by controlling the switching of memory banks. From the processor's point of view it should (I think) look like this: some unused commands will be used to control the circuit memory management and also during the execution of individual commands switch memory banks. For example, 7 commands ld r8, r8, almost not used in meaningful code, can be used to control memory switching circuit. You can also use 8-byte commands ED XX, but they are 4 measures longer, which is not very good. Also when execution of memory operating commands (push, pop, ldi, cpi, ld r, (hl),inc (hl), rl (hl), lf (hl),N...) depending on the circuit configuration memory management, it is possible to replace a bank with another one. You can for example replace the jar only if there was a prefix before the command (command ld r8, r8) or always when executing certain commands, for example operating with index registers. All of the above could make it possible to easily work with volumes memory more than 64kb without spending a lot of time switching control schemes memory. In fact, you can switch different memory areas in almost every team with relatively small productivity losses. *Crossposted in REAL.SPECCY *Crossposted in HARDWARE.ZX