CMOS

Hello, All!

I received a letter from DISMASTER about the subject. I decided to forward it almost completely.

---------------------------------------------------------------
* Fwd by Roman Milukov
* Orig.Area .NETMAIL
* Orig.From Denis Dmitriev
* Orig.To Roman Milukov
* Orig.Subj CMOS

Great, Roman!

I looked at the diagram of the subject recently, and something I was very
not happy with it. The most important thing is the ports. The fact is that there is port # EFF7 allocated for the data register, which we use to enable the extended
screen. Then, I don’t like the #FFFC port, which will 100% conflict
with
#xxFD.

On this occasion, I want to ask you to conduct a survey of people in
REAL.SPECCY, those who are planning to make or have already made
this scheme; It's not too late to change it.

More specifically, I want to suggest other port addresses for CMOS:

#EFF7 - bit 7 - enable/disable CMOSa sampling (was #FFFC)
#DFF7 - CMOS address register (as was #DFF7, and remains ;)
#CFF7 - CMOS data register (was #EFF7)

Actually, we need to find out whether there will be any objections
or other proposals on this matter, and if not, then I will paint a diagram for these addresses.

[skip]

I'm waiting for the results ;)

With the best, Denis.

- --- EarthED v1.02/B
* Origin: Combine on
processing C2H5OH ---------------------------------------------------------------

In my opinion, it would be necessarysupport exactly these new addresses. Although the whole problem is that when this scheme was made, its author, it seems, did not know about additional
graphic modes from V.M.G.
And IMHO it would be necessary to come to a common opinion. But is it possible? :(

All the best.
With respect, Roman Milukov.

I greet you from the bottom of my heart, Roman!

Wed Mar 18, 1998, Roman Milukov squeezed his keyboard, hoping that the following words would reach All
:

RM> On this occasion, I want to ask you to conduct a survey of the people in
RM> REAL.SPECCY, those who are planning to make or have already made
RM> this scheme; it's not too late to change it.

RM> More specifically, I want to suggest other port addresses for CMOS:

RM> #EFF7 - bit 7 - enable/disable CMOSa sampling (was #FFFC)
RM> #DFF7 - CMOS address register (as it was #DFF7, it remains the same ;)
RM> #CFF7 - CMOS data register (was #EFF7)

RM> Actually, you need to find out whether there will be any objections to this
RM> or other proposals, and if not, then I’ll paint a diagram for these
RM> addresses.

Realists, answer, it’s better, IMHO, to do so.

RM> In my opinion, it would be necessary support exactly these new addresses. Although the whole
RM> problem is that when this scheme was made, its author, it seems, did not
RM> know about the additional graphics modes from V.M.G. But IMHO
RM> it would be necessary to come to a common opinion. But is it possible? :(

God, there are always troubles with the spec! :) Anyone who wants good software will
use it as suggested. Thank God, they are still soldering the iron themselves, they can also resolder it :)

Hasta la vista.
Tim Kelly

Hello Roman!

18 Mar 98 Roman Milukov, hoping that everyone would read it, wrote:

RM> I received a letter from DISMASTER about the subject. I decided to otward
RM> almost completely.
RM> -------------------------------------------
RM> * Fwd by Roman Milukov
RM> * Orig.Area .NETMAIL
RM> * Orig.From Denis Dmitriev
RM> * Orig.To Roman Milukov
RM> * Orig.Subj CMOS
RM>
RM> Great, Roman!
RM>
RM> I looked at the subject diagram recently, and there were some things in it
RM> I was very
RM> not happy with. The most important thing is the ports. The fact is that
RM> there is port # EFF7 allocated for the data register, which we
RM> use to enable the extended screen. Then,
RM> I don’t like the #FFFC port, which will 100%
RM> conflict with #xxFD.
But no! the #FFFC port will not conflict with #xxFD unless, of course, #xx
is equal to #FF.

* Crossposted in REAL.SPECCY
* Crossposted in FROM_ME

I hit you with my forehead, Roman!

I saw that on Wed Mar 18, 1998 Roman Milukov wrote to All this:

RM> I looked at the subject diagram recently, and there was something in it that I was very
RM> not happy with. The most important thing is the ports. The fact is that there is port # EFF7 allocated under the
RM> data register, which we use to
RM> enable the extended screen. Then, I don’t like the #FFFC port,
RM> which will 100% conflict with #xxFD.
I think the same.

RM> On this occasion, I want to ask you to conduct a survey of people in
RM> REAL.SPECCY, those who are planning to do it or have already done it

TK> God, there are always troubles with spec! :) Whoever wants
TK> good software will use it as it will be
TK> proposed. Thank God, for now they solder the hardware themselves,
TK> they can resolder it :)
Yes, but it is necessary for software makers to _necessarily_ support some of the most
standard options, and preferably all the others. And the standard should be the one that least conflicts with the rest of Spec's hardware, so that the same thing doesn't happen
as with memory over 128K.

In my opinion, the moment when it is worth
changing something has been somewhat missed, because... it will be necessary
a) to rewrite and modify the ROM,
b) to rewrite drivers and .coms,
c) to turn on the soldering iron.

However, in PRINCIPLE I am not against it, but!

RM> More specifically, I want to suggest other port addresses for
RM> CMOS-a:
RM> #EFF7 - bit 7 - enable/disable CMOSa sampling (was
RM> #FFFC)
RM> #DFF7 - CMOS address register (as it was #DFF7, it remains
RM> ;)
RM> #CFF7 - CMOS data register (was #EFF7)

exactly The addresses don't suit me. It is more expedient
instead of #cff7 to use #bff7 - less composable
when replacing the circuit.

However, one should not (at least for me) lose
from sight the remaining bits of the port #fffc:
d0-extended attribute screen (byte per bytes)
d1-locking extended memory (more than 128)
d2-in version 5.2 I will control the turbo mode
d5-forced with a controller (/dos)
d6-connection instead of ROM rom disk
d7-access to the clock

East, when global change of addresses, the bits can be
mixed.

RM> here I am definitely (favorite phrase) against it. I already have the
RM> diagram (on paper), but it’s still worth thinking about, is it necessary
RM>? - let there be autoconfig in the programs - a modern
RM> solution.
Why create new standards? imho #EFF7 is on many people and #FFFC is only on
3 of them
RM> And going deeper into the essence of these rakes, I will say that they
RM> (rakes)
RM> will disappear if the #eff7 sample (your extended screen)
RM> is mixed
RM> signal
RM> clock samples (7th bit #fffc) - there will be no rake!
It is easier to change the #FFFC port because only three people need to change it, and #eff7 will have to
be modified by a bunch of people.

AI> Why create new standards? imho #EFF7 is used by
AI> many and #FFFC only by 3 of them
Very compelling argument! After all, when I made 512 dots in a line, I only saw the diagram from V.M.G. It was published in the electronic press. Have you made yours for yourself
again? (No offense taken, but that’s how you wrote your ROM in the dock? And
you don’t seem to want to change anything in it. And now MAD has started writing its own.
Commander Max P. will shove it in there, he’s already fixed it, I use it on mine.
If
it’s necessary, I can lather.)

RM> Yes, but it is necessary for software makers to _necessarily_ support some
RM> most standard option, and preferably all the others. And
RM> the standard should be the one that least conflicts with the rest of Spec's
RM> hardware, so that the same thing doesn't happen with memory over 128K.

The problem is that the spec doesn't have very much memory to support everything
in a row, although you can get around this with the help of installations or plug-in drivers!

I greet you from the bottom of my heart, Andrey!

Sat Mar 21, 1998, Andrey Isaev squeezed the keyboard, hoping that the following words would reach Roman Milukov
:

RM>> But IMHO it would be necessary to come to a common opinion. But is it possible?
RM>> :(
AI> Of course it’s possible.

Let’s quickly decide what’s what, so that it won’t be excruciatingly
painful later... :)

Hello! :) And who then is the moderator? :)

RM> Yes, since I’m here, I found out that I’m writing a game
RM> “Zhirinovsky” and I’m having troubles with the muse, and dear TK
RM> can help me - is this true???

No, it’s a complete lie, _I_ don’t write music! This can only be done by a
full-fledged member of our group, he himself will respond if he deems it necessary :)
I can only _ask him_ about this :)

Vita-a-alik! Where are you?! :)

I greet you from the bottom of my heart, Andrey!

Mon Mar 23, 1998, Andrey Isaev squeezed the keyboard, hoping that the following words would reach Roman Milukov
c) turn on the soldering iron.
AI> Nothing complicated, especially since this is your specialty :)

What is your specialty? I guess I’m not far from this either :)

ES> Of course it’s possible, I don’t think many people have had time
ES> to collect such joy for themselves.
Listen, don’t you know what you have in 465 with stones for CMOS? Availability, price?
You need 512VI1 or better bourgeois something - MS146818, or else there is one with
a built-in battery, like DALLAS1287, or something.

TK> The problem is that the spec does not have very much memory
TK> to support everything, although you can bypass this with
TK> using installations or plug-in drivers!
Everything can be bypassed, and very simply, the main thing is not to initially create difficulties for yourself (and
others), so that later you don’t have to heroically overcome.

ES> I think the same way.
Why are you bothering with #fffc, will it conflict with #xxFD, and if anyone
disagrees, then I ask you to give a reason.
ES> Indeed, so that there won’t be a bunch of “standards” again,
ES> let’s accept this proposal once and unconditionally.
We won’t do it accept.
RM> #EFF7 - bit 7 - enable/disable CMOSa sampling (was
RM> #FFFC)
RM> #DFF7 - CMOS address register (as was #DFF7, remains
RM> ;)
RM> #CFF7 - CMOS data register (was #EFF7)
ES> In my opinion, it’s just what the doctor ordered :)
well, that’s just in your opinion.

RM> A very compelling argument! After all, when I made myself 512 points
RM> in a line I saw only the diagram from V.M.G. She’s in the email press
Here I am talking about the same thing, but he still doesn’t listen.
RM> was published. Have you made yours for yourself again? (Don't
RM> take offense, but that's what you wrote in the dock on your ROM
RM>? And you don't seem to want to change anything in it. And
RM> now we have MAD to write our own. Commander Max P. will shove it in
RM>, he's already fixed it, I use it on
RM> mine. If necessary, I can lather.)
Here it begins!!!

Hello, Andrey!

24 Mar 98 Andrey Isaev, hoping that Eugene Safronov will read,
wrote:

AI> Why are you bothering with #fffc, will it conflict with
AI> #xxFD, and if anyone disagrees, then I ask you to give a reason.
At the Pentagon, when recording in port #**FC the program will also enter port #**FD. Or
not?

I greet you from the bottom of my heart, Roman!

Tue Mar 24 1998, Roman Milukov squeezed the keyboard, hoping that the following words would reach Eugene Safronov
Listen, don’t you know what you have in 465 with stones for CMOS?
RM> Availability, price? You need 512VI1 or better bourgeois something - MC146818,
RM> and then there is one with a built-in battery, like DALLAS1287, or something.

I can only say one thing - we sell dead trash mothers on the market,
there are a lot of useful things on them (CMOS, slots, some stones). Their price is 3
hryvnia, but, of course, there is not enough for everyone :), not a single plant wants to produce dead mothers :). I can tear Dallas out with mine, but it’s a bit of a shame :)

RM> Everything can be bypassed, and very simply, the main thing is not to initially create
RM> difficulties for yourself (and others), so that later you don’t have to heroically
RM> overcome them.

Uh-huh. Renat, take the soldering iron in your hands! They will redo it anyway, and there will be two
schemes :( Correct it like the author once and for all!

RM> On the Pentagon, when writing to port #**FC, the program will end up
RM> and to port #**FD. Or not?
If you write specifically to #fffc, then the program will never get into port #**FD, the only exception is port #FFFD.

TK> Uh-huh. Renat, take the soldering iron in your hands! All the same,
TK> will be remade, and there will be two schemes :( Correct it as the author once and
TK> forever!
Golden words!

Today we bought a couple of dead cartoons at the market - there are UM82C8167 there. It seems to be
the same as 512VI1? At least it's definitely CMOS (24 legs,
the battery is connected directly to it).

Come on, Roman, on it!

I greet you from the bottom of my heart, Eugene!

Fri Apr 03 1998, Eugene Safronov squeezed the keyboard, hoping that the following words would reach Roman Milukov
Today we bought a couple of dead cartoons at the market - there are UM82C8167 there.
ES> It seems that this is the same as 512VI1? At least that's for sure
ES> CMOS (24 legs, battery connected directly to it).

Yep. Power is supplied to the 12th and 24th legs, in the general sense - plus five
volts, respectively. The only question is, what died in those cartoons before they were sold to us? Maybe just CMOS? :)

Maybe a little off-topic, but what kind of controller is the UM8250B or WD8250-PL?
Parallel and com ports? Where can they be used?

TK> P.S. When will there be a redesigned CMOS circuit from
TK> DISMASTER?
What does Denis have to do with it? the revised scheme will be coming soon directly from Renat.

ES> cost UM82C8167. It seems that this is the same as 512VI1?
ES> At least, it is definitely CMOS (24 legs, the battery
ES> is connected directly to it).
I don’t know such a thing, maybe it is. But in general, the clock should be in the mother's box...

RM> - MS146818,
ES> ~~~~~~ This is the case for me friend on the
ES> market for 3 grams. I bought it, it’s used, but it’s working.
I wouldn’t want a used one... Well, maybe a very beautiful imported one... :)

ES> P.S. To All: Well, what are we deciding with Subj's ports, under
ES> what program addresses to write?
Wait a little. The mail from DISMASTER is slow. It seems to be clear already. There will be a
final version soon.

I greet you from the bottom of my heart, Andrey!

Sat Apr 04 1998, Andrey Isaev squeezed the keyboard, hoping that the following words would reach Tim Kelly:

AI> And what does Denis have to do with it? the revised scheme will be coming soon straight from Renat.

Go crazy! :)

RM> I don’t know this one, maybe that’s it. But in general, the clock should be in the mother
RM>...

No, CMOS was also installed in cartoons, the ones we have are binary. The battery for them, the diode decoupling of the power supply, everything is as it should be. Boom to collect.

RM> I wouldn’t want a used one... Well, unless it’s a very beautiful imported one... :)

There are practically no used imported ones. And the shortage of 512VI1 is terrible. What we took out with the cartoons was on the panels, everything was OK.

ES> P.S. To All: Well, what are we deciding with Subj's ports, under
ES> what program addresses to write?
RM> Wait a little. The mail from DISMASTER is slow.

TK> We are waiting, sir...
In general, these ports are new (I don’t remember right now), what Renat Mamedov last called,
only now bit D1 of port #EFF7 - enable graphics mode 512*192, and D4 -
lock memory over 512K. One of these days there will be a diagram and all the details.

I greet you from the bottom of my heart, Eugene!

Mon Apr 06 1998, Eugene Safronov squeezed the keyboard, hoping that the following words would reach Roman Milukov
:

RM>> I don’t know this one, maybe so. But in general, there should be a clock in the mother
RM>>...
ES> Not always, especially since the cartoons there were quite interesting -
ES> a bunch of COM ports and a clock, there were no screws or disk drives there.

They weren’t, but _are_! And they also have a parallel port :) This, IMHO, is the main thing on them. But we need _clocks_.

I greet you from the bottom of my heart, Roman!

Wed Apr 08 1998, Roman Milukov squeezed the keyboard, hoping that the following words would reach Tim Kelly
:

RM> 512*192, and D4 - memory lock over 512K. One of these days there will be a diagram
RM> and all the details.

I saw the diagram, but where are the details? Or did I overlook it?

I beg your pardon. Renat says, not D4, but D2 blocks memory above 512K. (I
am not going to block it at all.)

RM> there will be a diagram and all the details.

TK> I saw the diagram, but where are the details? Or did I overlook it?
Renat is preparing a detailed document, as far as I understand. He'll throw it here when he's done.

RM>> it’s already clear. Soon there will be
RM>> the final version.

KC> People, sorry for the question: have you seen the wiring diagram for the subject in 35 ZxNews
KC>? Quite simple, and polling/recording is also simple...
KC> And the circuit is not the least bit complicated (especially if connected to DALLAS) ;)

We saw it. There was a lively discussion about this and the author, under general
pressure, agreed to change something so that there would be no conflicts with the
_already existing_ hard.

I greet you from the bottom of my heart, Roman!

Sun Apr 19 1998, Roman Milukov squeezed the keyboard, hoping that the following words would reach Tim Kelly
:

TK>> I saw the diagram, but where are the details? Or did I overlook it?

RM> Renat is preparing a detailed document, as far as I understand. He'll throw it here as
RM> does.

We're waiting, sir :) Then the whole package, in case someone overlooked the diagram :)