|
01 апреля 2001 |
|
Project: Describe Your Disk Interface
By Mac Buster
More and more I'm hearing strange things about 'those stupid
Russians who are doing their games and demos for "Beta
128" disk interface, all releases are "protected" and so they
don't care about other disk systems'.
Why am I thinking this is strange ? Well, first of all it's
strange that most of you who say this don't know that the
former Soviet Union included over 180 different nations, most of
these nations dislike it when you call them "Russians", but
you don't notice this and so you're insulting them.
The Soviet Union united 15 countries, most of them are
independent now, some wanted to stay a part of Russia. Almost
ten years passed since the dismissal of the Soviet Union, you
had enough time to learn where each country is and what it's
nation's name is. Second thing is these "protected" loaders.
This is not true! Only ~5% of releases are really protected,
others are just compiled under the "monoloader" scheme.
"Protected" and "monoloader" aren't the same thing.
"Protected" means use of "hack-stop" techniques to prevent
hacking and changing something in original release (some
strange people like to change original text and insert their
own names into releases when they did nothing). Some of these
protected loaders use some very interesting and unexpected
ways, e.g. using of sound-coprocessor and FDC registers which
will clear its contents if it was not read back in a defined
amount of t-states.
The "monoloader" scheme has nothing to do with real
protection. Why use it then? Because TR-DOS (the disk
operating system in the EPROM of the "Beta 128" disk interface)
is very SLOW when working with separate files one-by-one. Let
me explain what a monoloader is and how it works. TR-DOS takes
about 1 to 3 seconds to locate and start reading a files
contents. Not because of complex FAT or BAM (there's nothing
similar to these things in TR-DOS at all, all files are
sequential, and this is one of things which made monoloaders
possible), it's just because of one very long delay for
compatibility with very old disk drives (remember - "Beta 128"
was made in UK in 1986). If you have more than three or four
files to load then the whole process may take up to one
minute which is five times longer than sequentally reading
the same amount of sectors from disk to memory. Monoloaders
became available thanks to TR-DOS which loads only the
amount of bytes written in the BASIC length field of the
file descriptor into memory and doesn't care about the rest of
the data. You may write the BASIC part of your program
(there must be a machine-code loader in it because the
monoloader can't be processed from BASIC), a picture file
(compressed), the main code (compressed), and some other
data, one after another on the disk, and then just change
the 'file length in sectors' field of file descriptor. Copy
the first file to another disk and so you have just made
the monoloader. TR-DOS will load only the BASIC bytes from
disk and start it as a BASIC program. The BASIC part will
start the machine-code part which loads and decompresses
the picture, the main code, and any other data if there are
any. By this way we're saving up to 3 seconds on each part
of data! Another advantage of monoloaders is the reduction of
the amount of needed spare file entries in the root directory
on the disk (TR-DOS can see only the first 128 files on a
disk), and saving time which is required to copy this program
to another disk. Also there's no way to forget an important
file when you're copying this program to another disk
in hurry. Games usually save their state inside the
monoloader file, there are several parts of sectors, which
are not used, to store file data (several bytes at the end
of the last sector of each block of data). Some loaders use
special 'turbo loaders' to reduce the time needed to load
data. They work on the direct FDC access principle. This cuts
out the whole pointless 'delay cycle' present in the TR-DOS
code, and increases loading speed by 2 to 4 times. But
again - this is not protection. That was my answer to 'why use
monoloaders?'.
Now lets talk about 'why "Beta 128"-only?'. In 1988 a scheme of
the Soviet clone "Beta 128" disk interface was released. This
interface is very cheap and easy to make, and - the most
important thing - it was the ONLY disk interface there was at
the time! People started to use it alot. And more and more
programs with "Beta 128" support appeared (games mainly).
Sure we knew there are other disk interfaces (FDDЗO00 in
Poland, +3 and MGT in other countries). But nobody owned it
here and nobody knew how so support it.
So why spend time supporting something which nobody used,
especially when you don't know HOW to support it? But this is
just the first half of "why", let me tell you about second
half. Since the end of 1992 when we almost lost connection
with Speccy software importers in other countries
(because production of Speccy software was stopped by 99% of
the software houses) we thought that only citizens of Russia
and other countries of former Soviet Union where using Speccy.
It was a great shock to see that in 1995 someone still uses
Speccy in Europe. This was the time when Internet access became
cheaper. We started uploading our files to sites and then
the most interesting thing happened - someone for the first time
asked us why we're doing programs for "Beta 128" and not
doing support for other disk systems. Note - "asked why",
but not explained "how"! Five years passed since then but
we're all at the same point - one part asks "why", instead of
tell us "how". Sounds funny ? I don't think so. Strange
"genetic creatures" even thought that this was done
especially and started releasing "anti-Beta-128" protection
releases. So, who is stupid ? I do not know how to answer
this question. I tried to change the situation and explain
"why" and "what for", and asked about "how", but not
many of those who I asked tried to understand it nor did
they try to help.
And even to this day I still haven't had much success, still
lots of people are talking about 'those stupid Russians' and
'stupid BETA 128 loaders'.
Now I've got one question to YOU. Yes, to YOU dear reader.
What have YOU personally done to change the situation, to help
us make our games, demos and utils work on your disk (tape,
HDD, CD, Flash card, Other media) interface? I bet YOU did
nothing. The only team who really tried to help us was
RAMSoft. They released a very nice document about programming
the MGT DISCiPLE and Plus D interfaces. The only thing
missing in their document was examples which can be
cut'n'pasted into our own assembler source codes to allow you
play games and watch demos without the need to spend several
minutes or even hours to convert it for your interface. But
doesn't this look strange - there are over 40 different disk
interfaces and only ONE description available?!?! I've
released documents about "Beta 128" programming and TR-DOS
system variables, but that's not enough. Where's YOUR help?
So what do you want? A reason to talk about how stupid
those who made productions for "Beta 128" only really are? Or
you really do want to see forthcoming productions working on
your interface? Have you chosen the first option? If so, excuse
me, but this looks like you have something wrong with your
mind. If you choose the second option, then, please, find
all your old programmers manuals and references related
to your disk interface and type-in/scan them! Take care with
translating them into english if they aren't translated yet
(ask a friend who is native english -speaking to fix it) and
send them to any Speccy related site to be published. Don't
have enough time to do that? I understand you, sometimes
it's really hard to find enough free time to do even
really important and urgent things. Just send your documents
to someone who can do this instead of you. Contact someone
who has connections to people who are releasing popular disk
magazines in former Soviet Union and ask them to publish your
document. This will be a real help for all of us, believe me.
So how exactly can you help and what should you do? Here is a
small list of things which are needed to be described:
* What is the EXACT name and version of the interface you own,
including the Disk Operating System (DOS) name and version.
* Who made it?
- When did you buy it?
- Why you bought this one, and not another interface?
- Features of this disk interface:
- disk capacity
- amount of files that can be stored on a disk
- disk access speed (how fast 48k program gets loaded)
- how many disk drives may be used
- limitations (48k RAM use, etc)
- Was/is there any community for this disk interface?
- Was/is there any newsletters published for it?
- Do you have copies of such news letters still?
* Do you have users/programmers manual?
- How much software support is there for this interface?
* How to detect that program was started from this interface?
* What is the disk format of this interface:
- disk sides
- tracks per side
- sectors per track
- standard sector length in bytes
- universal signature (how to detect that this disk is for
your disk system, not for another one)
- root directory descriptor
- sub-directory descriptor
- file descriptor
- file allocation table structure (if exists)
- Which FDC is used in your disk interface?
* How to have access to disk functions from BASIC?
- examples (load/save/cat/delete)
* How to have access to disk functions from machine-code?
- examples (ready-to-use examples if possible)
- How much RAM disk interface has and how to page it in/out?
- example
- How much ROM disk interface has and how to page it in/out?
- example
- How to have direct FDC access?
- example
- How to read disks of this format on other machines
(Amiga/PC/MAC)?
- Are you ready to help with testing?
The most important information is marked with a "*" symbol. Of
course this is just an approximate list, not complete. You
may add everything which will help those who will try to add
support of your interface to their own software and to those who
will try emulating your disk interface. Please, do not be
aggressive to those who don't make support, it's
very probably that they just don't know about your
system. Contact them and explain how to add support for
your disk interface. Do not shout how stupid they are, this
will not change the situation - in most cases you'll set
people into an aggressive mood and will lose the hope to
change situation _forever_.
Why tested and working examples are needed? Let me tell you a
story, it may sound funny now, but not back then. In 1995 I
was asked to join a team of developers who made a MIDI
interface for Speccy. They gave me several hundred
pages of photocopied sheets of paper titled
"technical information/programmer's reference", and shown how
it works. That was the first time when I saw and heard MIDI. It
was very impressive. So I agreed to work and asked
exactly what to do. They told me that I had to do everything
what will make a live musicial easier. Finally, it must be the
greatest MIDI sequencer for an 8-bit machine, and a small
control program to edit/save/load/send to/from synthesizer
state. I asked for this MIDI interface and for the
simplest synthesizer but it wasn't supplied, because any of
those devices, even the simplest synthesizer, was very
expensive for them, and attaching a MIDI interface required
some hardware work, which isn't a very well known thing for
me. So I told them to buy a modem for Speccy and told them
that this will save a lot of my money, because I'm not going
to spend an hour in one way when I need to test how well my
program works on real hardware. They agreed. Three months
later, the first simple version of the GUI and a small utility
to set the synthesizer's preferences editor was made. Here is
where the most fun thing happened. I phoned the man who
had both the MIDI interface and the Synthesizer, and of
course he had a modem. After transferring my program to him
and testing it, he told me that everything is very nice, but
some improvements need to be done. I did what he wanted in two
weeks. Again everything worked fine on his machine, but he
asked me make something to make a musician's life easier.
Over half a year we were working in this way: I write new
features or improve something and then send it to him where he
tests it and tells me what to fix and what to add. But then
one day he asked to add support for another MIDI protocol. I
did it and here started something very strange.
The synthesizer received a WRONG value, nothing which I sent
from the control program. I asked 'can I have the MIDI interface
and the synthesizer now?' He said 'no', also he told me that
it isn't possible to visit him now because he is very busy and
it is almost impossible to catch him at home. He also asked me
to trace what's wrong in my control program because he
did everything correctly.
Four months I spent trying to fix it, without any success. I
came to a madness border. Imagine it yourself: you have five
commands which send data to a port and something goes
wrong there because the synthesizer receives number 99
instead of 253! After four months you're looking at these
commands, changing them in a different way, totally rewriting
them, etc. But nothing helps! Until one day when the man phoned
me and told me that he has found the problem - he just forgot to
switch the transfer protocol! So I broke the contract
immediately after I heard his words, because earlier in the
contract the whole developers team told me that I'm a very bad
coder if can't write a sequencer which can control the
synthesizer. That's it. I spent almost one year working on
that project... That's how it looks when you don't have the
device but have to write support for it. So please add
tested and working examples!
(c) 2000 Mac Buster^Extreme Entertainment
http://bduc.nm.ru/
http://xtm.da.ru/
Other articles:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Similar articles:
В этот день... 21 November