Spectrum of tomorrow....

August 25, 1999, Roman Milukov writes to Renat Mamedov:

RM> [about 1M on #7FFD]
RM>>>> And most importantly, it is both software and hardware more convenient than all the others!
AI>>> the stump is clear. :)
RM>> Programmatically... and how to programmatically determine this very mega without
RM>> drowning a car that doesn’t have it?
RM> Well, not to death?! :)

Until the reset :) almost to death :)

RM> Everything written at 512K works on the meter without problems. Everything written
RM> under 1M does not work at 512K. A completely normal situation. ;)

That's not the point. I'm talking about 'the software is more convenient than all the others'.

RM> Software
RM> you can only determine the presence of 1M by looking at CMOS. Rough testing

Kmos may not exist. Its absence is also not an indicator.

RM> no need! It’s better to use only half a meter, isn’t it enough for you? For

Of course it’s not necessary - after all, it’s impossible :)
For me personally, no. But there may be a situation in which the amount of memory
is important. for example, a mod player...

RM> Homer-2 is enough. And the system software should be done in such a way that it is configured
RM> manually by the user.

I think it is necessary to make the hardware so that the programmer does not have headaches.
Stop repeating previous mistakes :)
Especially if we are talking about future hardware :)
I propose my own method:
Managing the upper memory through the latch of the second bit#eff7. If the latch
is turned on, access to control of 5,6,7 bits #7ffd (more than 128) is only possible
from the tyrdos ROM (or just look at a14 and a15). in this case, with locked
memory (only 128), the virtual disk is relatively safe, and, most importantly, there is free access to it.
A megabyte is, in principle, identified by the size of the virtual disk, or by the
tyrdos version. but this is also unreliable. The surest thing is to ask the user.

Sincerely,
Renat

RM> I think it is necessary to make hardware in such a way that the programmer does not have headaches.
RM> Stop repeating previous mistakes :)
RM> Especially if we are talking about future hardware :)

Yes. That's right.
The main headache for programmers is to cover a bunch of different RAM standards
over 128K. ;)

RM> I propose my own method:
RM> Managing the upper memory through the latch of the second bit #eff7. If the latch
RM> is enabled, access to control of 5,6,7 bits #7ffd (more than 128) is possible
RM> only
RM> from the tyrdos ROM (or just look at a14 and a15). in this case, with locked
RM> memory (only 128), the virtual disk is relatively safe, and what
RM> is most important, there is free access to it.

Gee, that’s what I have on my computer! For a long time already.
The second bit #EFF7 is always set for me, RAM above 128K is always closed. That's when I launched your Homer - opened it. :)
Why more?
A virtual disk is a very useful thing!
Ah! Maybe I’ll open it for the new Storm and editor for 512*192. I hope.
;)
True, there is still a problem - when I launch some kind of “smart” program from the ramdisk
the RAM is open at that moment. I'm spitting a lot. :)

RM> A megabyte is, in principle, identified by the size of the virtual disk, or by the
version
RM> of Tyrdos. but this is also unreliable. MostThe sure thing is to ask the user.

You see, it turns out that you understand everything, you’re just pretending often!..
;)

All the best.
Sincerely, Roman.

RM> Yes. That's right.
RM> The main headache for programmers is to cover a bunch of different
RM> RAM standards beyond 128K. ;)

Yes. The most important thing is not to create new standards, but to build further extensions
on the basis of existing ones.

RM>> the disk is relatively safe, and what is most important, there is
RM>> free access to it.

RM> Gee, that’s what I have on my computer! For a long time already.

:( I wanted to forget my copyright :)

RM> I always have the second #EFF7 bit set, RAM above 128K is always
RM> closed. That's when I started your Homer - I opened it. :) Why more
RM>? A virtual disk is a very useful thing! A! Maybe for
RM> I will open a new Storm and an editor for 512*192.
RM> I hope so. ;) True, there is still a problem - when I launch some thread
RM> "smart" program from the ramdisk - the RAM is open at that moment. I'm spitting a lot
RM>. :)

What do you mean? Trouble only if this smart program pulls the port through tyrdos.
But this is in the morgue.
How else? It will switch from RAM to low power - tyrdos is not connected, the port is blocked...

RM> mean? Trouble only if this smart program pulls the port through tyrdos.
RM> But this is in the morgue.
RM> How else? From the RAM it will switch to low power - the tyrdos is not connected, the
RM> port is blocked...

You can probably forget the copyright. :) I didn’t immediately understand that you
offer RAM over 128 only under TR-DOS. Then screw it, screw it!

Or do you mean that the “latch-128K” works in SOS, but not in DOS? Yes, it will
be convenient. But this extra element must be added... reluctantly. Although no, you can
just a resistor and a diode... I’ll have to try it, see how many
Very “smart” programs exist. :)

And when Andrey Isaev made TR-DOS 5.13Fm, he asked: “Is it necessary to reset bit 2 #EFF7 when accessing the ramdisk?” Then they decided that it was not necessary... or maybe it was already necessary? After all, why hang up extra iron parts if it can be solved by software? But of course, it’s not so simple - there’s still a ton of everything there except
the castle...

RM>> tyrdos. But this is to the morgue. How else? It will switch from RAM -
RM>> tyrdos is not connected, the port is blocked...
RM> Anyway, you can probably forget about the copyright. :) I didn’t immediately understand that
RM> you are offering RAM over 128 only under TR-DOS. Then screw it,
RM> screw it!
RM> Or do you mean that the “latch-128K” works in SOS, but not in DOS?
RM> Yes, that will be convenient. But this is an extra element that needs to be installed... I’m reluctant.
RM> Although no, you can just have a resistor and a diode... I’ll have to try,
RM> see how many very “smart” programs exist. :)

No, not like that. When the #eff7 bit is set, access to the upper memory is possible only from DOS. crowds of dead hares :)

RM> And when Andrey Isaev made TR-DOS 5.13Fm, he asked: “Is it necessary
RM> to reset bit 2 #EFF7 when accessing the ramdisk?” Then they decided that
RM> was not necessary... or maybe it was already necessary? After all, why hang up extra iron parts
RM> if it can be solved by software? But of course, it’s not that simple -
RM> there’s still a shit ton of everything except the castle...

Or so. But Isai is a long time...

RM> Barbarian. :) and don’t you feel sorry for these programs, placed in the Procrustean bed of 128k?

With very rare exceptions, they feel very comfortable there. :)
Example ZX-ZIP - packing a V/S ramdisk is much faster than using
more than 128K RAM.

RM> As I understand it, you don’t like auto-detects. Explain why?

You understand incorrectly.
Autodetect in Homer is one thing, but, for example, in Lara it is another. Do you agree?
Or some kind of Khobeta thread - 4 kilograms of prog and 5 kilograms of autodetection? Which will also kill the ramdisk
by accident.

RM> Castration to 48 and an add-on from it? For what?

This path, of course, is somewhat radical, but it would dramatically simplify life for
programmers, users, and manufacturers.
I’m just sure that sometimes you need to get rid of the extra burden of unnecessary
add-on weights.
However, this will no longer be Spectrum. :)
And it’s probably better to hush up this question?

RM> This path, of course, is somewhat radical, but it would dramatically simplify
RM> life for programmers, users, and manufacturers. I'm just sure that
RM> sometimes you need to get rid of the extra burden of unnecessary add-ons. However,
RM> it will no longer be Spectrum. :) And it’s probably better to hush up this question?

Well, why. 128 (or 256) - available via #7ffd (for compatibility),
and for new programs the option is to have all the memory on one port. That is, this one port can connect any page. #7ffd just for
compatibility...

[Saturday September 18, 1999] at [17:05:12] Renat Mamedov wrote a letter to
Roman Milukov.
They discussed the topic “Spectrum of tomorrow...”. Let's continue what we started...

[skip]

RM> The driver doesn't rule either

It does rule. :) Because a program with such access to the top
memory will work even on the most pathology, with the crooked
configuration ports. The setup and config will obviously take up more space and there will be room for a glucodrome. A program comes out, and with it
a set of drivers for the *most* common hardware (if, of course,
the author has a complete understanding of writing
them) or/and “instructions” on how to write such a driver.
Very convenient. There is one exception, IMHO, if the program wants to climb to the top memory as quickly as possible. In this case - yes, the driver
(even optimally written) can create unnecessary brakes.

A typical example of such software is 'TRMSHOB+'.

Sincerely, Felix.

[I ZX]

FK> Exactly rulez. :) Because a program with such access to the top
FK> memory will run even on the most pathology, with the most

Plug-and-Play BIOS the Spectrum needs.

Kirill Frolov. [ZX]

RM> Well, why. 128 (or 256) - available via #7ffd (for compatibility),

...or 1M, it’s nearby, on the same port. ;)

RM> and for new programs the option is to have all the memory on one port. That is
RM> this one port can connect any page. #7ffd just for
RM> compatibility...

Well then you need to do 1M for compatibility.
But I thought it would be simpler. In general, you can do without these ports if you use the Z380.

RM> Well then we need to do 1M for compatibility.
RM> But I thought it would be simpler. In general, you can do without these ports, since
RM> use the Z380.

It was given to you...
On the old z80, not everything has been mastered yet :)
Sincerely,
Renat

FK>> Exactly rulez. :) Because a program with such access to the top
FK>> memory will run even on the most pathology, with the most

well, yes! and also take out'9x.. :E

at least he gave reasons for his statements, damn it..

With best wishes, Artur. [ZX]