New OC

GS> As for video, here it seems to me the most reasonable solution:
GS> the price
GS> of old IBM video cards has dropped significantly, and you can find them if
GS> you want
GS>. They, unlike the crafts of local craftsmen, are quite
GS> standard and
GS> well documented. And you can connect them without losing
GS> compatibility with
GS> standard Spectrum, just as a second video system (by the way, on IBM
GS> the same thing can be done,
GS>, but this is rarely used).

In principle, this is great. But you didn't take into account that there are already analogues that are not compatible with PC cards. For example, on Profi there is a 512x240 screen, on
ATM - 320x200, 640x200 and text 80x25. The Peters computer also has something like that. Finally, according to ZX-POWER N1 magazine, testing of a video system with each point in its own color is underway in Ukraine. Plus here's your
idea. And everyone will connect what they want. Only the drivers for all these options will take about 32 kb. What about other peripherals? So there won't be enough memory.

GS> Now about the most difficult part. About the "very cool OS". I hope everyone knows
GS> what
GS> is an OS? This is a tool that allows running programs access to
GS> all
GS> computer resources- RAM and external memory,
GS> input/output systems and
GS> etc., in some standard, reliable and convenient way. One of the most important
GS> requirements for an OS, if we want to make it for the Spectrum, is standardization.

This is exactly what I want to do.

GS> Now, if only it were possible to run Delphy under Windows...
GS> But you can safely forget about this on the Spectrum!

Lord! You wouldn't even dream of this!

GS> It's clear that writing real UNIX (even MINIX) on the Spectrum is not
GS> too promising. But the idea is important! After all, besides C, there is another
GS> abstract
GS> machine-independent language - Fort! Which (in my humble opinion) is still
GS> closer
GS> in its concepts to the ideas of UNIX-like OSs. There is no need to talk about the undemanding nature of
GS> Forth to
GS> equipment, it has no competitors!
GS> It’s a pity that I didn’t come across the Forth system for
GS> Spectrum at one time, it
GS> would have greatly reduced my problems when programming in Assembly. But
GS> now
GS> I have my own version of Modest FORTH for IBM, which, together with
GS> debugging
GS> tools and an editor with its block buffer, takes up 8700 bytes.
GS> A very sophisticated kernel - 3203 bytes! Language allowswork wonders, while
GS> hiding
GS> all the crookedness of the MS-DOS implementation under which it runs. In principle, its
GS> is very
GS> easy to transfer to another computer...

The idea is not bad. I also thought about the implementation of high-level languages ​​and the replaceability of the shell. The OS will be specially built so that the ROM will contain only the BIOS and the file system. The shell, i.e. the command interface and so on, will be located in RAM. This is made specifically for machines with
128 kb. After all, modern programs occupy all this memory. Therefore, the shell
can be thrown out of memory without harm, and upon finishing working with the program
loaded again (the idea was taken from MSX). In addition, the shell can be easily replaced - it could be Norton, Windows or something else - it's purely up to you.

GS> should be replaced by new programs. How about a debugger with
GS> a separate
GS> screen (80*25 characters) for debugging itself? With support for screw and
GS> even the possibility of remote debugging via a COM port... Or the prospects
GS> of a full-fledged multi-
GS> task on the Spectrum (such systems have been made on Forth for a very long time)...

Not bad.

GS> And what about
GS> text editors, indistinguishable in interface from those that
GS> use -
GS> are used on “real” oneson personal computers?

Why? I personally don't have any inconvenience that ZX-WORD is not like
Lexicon. This is already lame.

GS> Well, what's the idea?

Excellent! Thanks a lot. Only you could tell us more about the fort system. I
unfortunately I don’t know anything about her.

... UI120:ENHKAEAEAATGKFHGCIEGMDCNADABCIPCNBJKHJECCCF

GS> If only! This "standard" is actually a set of extremely diverse
GS> "compatible" machines, the differences between which are not really documented
GS>, but keep popping up, driving many users to despair. A bunch of
GS> software
GS> require a computer “certified” for it, and it happens that
GS> some
GS> two different programs “live” perfectly on two similar computers, one on
GS> one
GS> and the other on the other, but after rewriting to the neighboring one, all the illusions
GS> collapse like a cardboard house... Those interested can read the details in
GS> echoes on
GS> dedicated to IBM processors, motherboards, video systems, modems, etc.
GS> So there is no standard, but the market is really flooded with
GS> IBM-compatible
GS>, mainly due to their relatively low price and wealth of choice
GS>
GS> peripherals and software. How it all works is another story...

In principle, I agree. I'm just afraid that this is already off-topic.

GS> Uh-huh. And its prospects are also not bright, since the company
GS> Microsoft, the main supplier of software for it, is not competing by increasing
GS> quality-
GS> programs, but by buying up leading developers in competing companies
GS> (for example, in
GS> Borland). Is it necessary to explain what this will lead to...

This has already led to a dead end.

GS> So you wanted a standard? And a widespread one. Then the choice is for
GS> video cards-
GS> from IBM, they are quite affordable, and their capabilities (by
GS> Spectrum standards) are decent...

Unfortunately, IMHO it won’t work. There are already other standards. And if you make your own -
it will go again...

... UI120:ENHKAEAEAATGKFHGCIEGMDCNADABCIPCNBJKHJECCCF

FP> Lord! You wouldn't even dream this in a nightmare!

;)

[info about Fort has been skipped]

FP> Not a bad idea. I also thought about implementing high-level languages ​​and about
FP> shell replaceability. Just the OS will be specially built in such a way
FP> that the ROM will contain only the BIOS and the file system.

And this is correct!

FP> The shell, i.e. the command interface and so on will be located in
FP> RAM. This was made specifically for machines with 128 kb.

Forth's command interface will also easily fit into ROM. That is, on the Spectrum
it will be possible to install a "BASIC/Fort" switch. In the first position there is a standard machine on which all old programs should run. In the second, instead of BASIC, Fort will be launched (after all, it is also an interpreter and can be used as a calculator), and with a “system” floppy disk inserted, a boot
program (window shell, for example) will be launched. And in fact, it will be possible to implement
all this even on a machine with 48K of memory, or what, even with 16K... ;)

FP> After all, modern programs take up all this memory. Therefore, the
FP> shell can be safely thrown out of memory, and after finishing working with the
FP> program, it can be loaded again (the idea was taken from MSX).

The idea of ​​MSX was taken from CP/M, and that in turn from the ideas of UNIX. Everyone does it
whenthere is not enough memory...

FP> In addition, the shell can be easily replaced - it could be
FP> Norton, Windows or something else - it’s entirely up to you.

What about the standard for floppy disk formats, exchange protocols, etc.? The same
MSX uses floppy disks in the MS/DOS format, which eliminates the need for users to search
for something like Hobeta...
For some reason, Spectrum really liked to come up with its own formats and protocols,
overtaking most other machines. It would be necessary to at least provide in the OS the ability to access peripherals with a different format in a standard way for the system.
In UNIX this is called mounting the file system. Those. (hypothetical
example) the command line specifies the command to mount the file system
from drive 0 ( A ) to a specific directory of the main file system, and it is indicated that the floppy disk is in TR-DOS format. We insert the floppy disk and in the specified directory we see our “native” TR-DOS programs. Naturally
writing/reading will work (there will be no problems with characters, UNIX also distinguishes between capital
and small letters), but not execution. The only problem is the length of the names. File
names on UNIX can be up to 255 characters long, which is a problem even on
OS/2. But for us this is not important now...

GS> Those who buy a computer with a built-in “advanced” video system,
GS> will get what they get. Not necessarily what they want... The overwhelming
GS> majority of
GS> machines will have to be retrofitted to operate in advanced modes...
GS> Ease of modification, availability of documentation, choice of options
GS> differing
GS> in price and capabilities, all this speaks in favor of standard hardware from
GS> IBM.

And where can you find this hardware? This time. Secondly, are you sure that the layout of its ports will fit into the Spectrum architecture? On Profi this is exactly the situation - it seems to be convenient, the circuitry is simple, but the Kempston mouse, CDOS modem
and GS cannot be connected without modification... But I consider the ATM video system to be very
successful - it has a text mode 80x25, and two graphic modes - 320x200 and 640x200. There is even a palette of 64 colors. Why not make a card for
other machines that will be compatible with this system?

GS> How to ensure software compatibility? Firstly, why do we need
GS> drivers for _all_ variants? For each specific machine
GS> configuration you will need a specific
GS> driver. As a last resort, provide, as in Lprint, a separate
GS> ROM of a couple of kilobytes, in which it should"sit" a set of necessary
GS> drivers. Standardize
GS> procedures for accessing non-standard hardware and entry points
GS> calls (apparently via RST). Plus a dock for the most “advanced” in working with
GS> equipment
GS> directly...

Unfortunately, you will have to have drivers for all options, because you will also have to make
a bunch of versions of ROMs for different versions of cards, but this is insanity. Imagine
changing the BIOS after an upgrade. Even on PC they didn’t get to this point. There is, of course,
another original output, which was very successfully used on the MSX machine.
Each card has its own ROM, which can be turned on via the port as another
page. This ROM contains the BIOS for working with the card. The entry points
of different BIOSes are the same. This is how the problem is solved. But in our country it is
impossible to fully implement, because the existing subsystems do not have their own BIOS, therefore
you will have to push their drivers into the system.

GS> What about a standard for floppy disk formats, exchange protocols, etc.?
GS> The same MSX uses floppy disks in MS/DOS format, which eliminates
GS> users searches
GS> something like Hobeta...
GS> For some reason, Spectrum really liked to come up with its own formats and
GS> protocols, surpassing most other machines. It would be necessary to at least provide
GS> in the OSthe ability to access peripherals with a different format in a standard
GS> system way.
GS> In UNIX this is called mounting the file system. That is,
GS> (hypothetical
GS> example) on the command line the command is given to mount the file
GS> system from drive 0 ( A ) to a certain directory of the main file
GS> system, and it is indicated that the floppy disk is in TR-DOS format. We insert the
GS> floppy disk and in the specified
GS> directory we see our “native” TR-DOS programs. Naturally
GS> writing/reading will work (there will be no problems with characters, UNIX also
GS> distinguishes between capital
GS> and small letters), but not execution. The only problem is the length of the names.
GS> File names
GS> on UNIX can be up to 255 characters, which is a problem even
GS> for OS/2. But for us this is not important now...

I have already thought about this. It looks like it will have its own file system, MS-DOS, but it will be possible to suspend its own system, like on the Amiga.

GS> Well, I don’t like the Lexicon myself. But why not make the
GS> interface on the
GS> machine at home exactly the same as what you are used to at work?

In principle, this, of course, is a matter of taste...

FP> this situation seems convenient, the circuit design is simple, but only
FP> Kempston mouse, CDOS modem and GS cannot be connected without modification...

yeah, especially if you connect it where there is no bus, on which these
devices are designed for. KAY/SCORPION/PROFI has this tire. Therefore, we do without
modifications. For other cars, the modifications are very small. Solder the wiring and
make a blocking. Either on a resistor or on a microcircuit. Easier than steamed turnips. This applies to ALL completed designs that have system
connectors.

Good Luck...

... "If I wanted to listen to an ASSHOLE, I would've called an PeCe user!"