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/