Forwarded by Arseniy Astapenko (500:17/1)
AZX-Monstrum [1/2]
RUSH> Incredible! Another "monster"... no comments...
Dear programmers and circuit designers. This file was written to inform users, programmers, and hardware developers about the project of REANIMATOR Creative Computing & Research Ltd - the AZX-Monstrum 512K computer. I hope this file will be distributed through the ZX networks of St. Petersburg and made available for download on the internet. Now, directly to the machine.
1. Idea. The AZX-Monstrum 512K is compatible with ZX-Spectrum 48/128 (tm) computers, as well as all its Soviet counterparts, both programmatically and hardware-wise. It is only compatible with Scorpion ZS256(tm), KAY-128/256/1024(tm), Profi(tm), and ATM-Turbo 512 computers in terms of extended memory addressing (16KB pages in Sp-128). The architecture of the machine is modular. There are a total of 12 slots and 3 connectors, including:
- 4 slots for peripheral connection,
- 4 slots for extended memory connection (up to 1024 KB),
- 4 slots for upper memory connection (up to 4 GB),
- 1 core slot (or connector) for connecting the processor (see below),
- 1 connector for connecting IDE-HDD (Master/Slave),
- 1 connector for connecting FDD (drives A: and B:).
I do not claim copyright on this machine, IT IS FREE FOR REPRODUCTION BY EVERYONE! All components are domestic. The number of cases is hard to say for now; it all depends on how well and reasonably we develop the peripherals together. I can only say that the motherboard already counts about 40 cases. You can find all the parts in any of the Soviet clones of the Spectrum. The refusal of the chipset is primarily made for easy replication, as most chips can be found in your old machine.
2. Processor. On the motherboard (hereafter MB), there is one special slot - core slot for the processor. Thus, by changing only the board on which the processor is soldered, you can immediately replace a weak processor with a strong one, a slow one with a fast one, etc. The idea is not new, borrowed from IBM-compatible machines, but very convenient, in my opinion. The main processor planned for the AZX is the Zilog(r) Z380, as this processor has:
Data bus - 16 bits
Address bus - 32 bits
Operating voltage 3.3V-5V
Clock frequency up to 33MHz (regarding speed, the information is a bit outdated; I believe there is a version up to 50 MHz)
Maximum addressable memory (without banks and directly) 4GB
Full hardware compatibility with Z80, Z80A, Z80B, Z80H
Full software compatibility with these processors, with the same commands supporting both 64KB and 4GB memory. This processor is produced as an extension of the Z80 model. An alternative is the Zilog(r) Z180. It differs from the Z380 in that its address bus is 20 bits (thus, maximum memory is 1MB), data bus is 8 bits, and clock frequency is up to 25 MHz. The compatibility is the same as with the Z380. I do not know what processors are available in Russia and if there are Soviet analogs; if there is any information on this, please write to me. On the MB, thanks to the use of the core slot, it is possible to install any processor compatible with the internal architecture and instruction set of the Z80. Since the forms of cases and pin layouts of the Z80, Z180, and Z380 are different, I came up with the idea of using a core slot. The operating voltage and type of processor are set by rearranging jumpers on the MB (just like on PC). The OS must provide the corresponding kernel versions to eliminate malfunctions (if you want to know, MS-Windows 95 does not support AMD-K6-2 processors with speeds of 350MHz and above; it turns out it is too slow for them! This was a real sensation worldwide. However, it handles Pentium-II at any speed very well. I do not know if this is some agreement between Microsoft and Intel - in any case, users suffer from this. Therefore, I do not want this to happen to us).
3. Motherboard. As mentioned, the MB has a bunch of slots. This was done (or rather, intended) for many reasons. With expansion slots, the more the better. However, a Midi-Tower is not rubber, and in my opinion, 4 is quite enough (below is another reason why). The core slot is also clear, although it would be interesting to hear the opinions of real circuit designers (I am just a small programmer with a big dream of having a Speccy with good capabilities). Now to the main point - four slots for extended memory and four for upper memory. Gentlemen, everything that is outside the processor's address space is EXTENDED memory, and in our case, everything above 64 KB is UPPER memory. Our extended memory consists of 16 KB pages, which we can use as we want and stretch up to 1MB! Now, gentlemen programmers, a question for you. Have you thought about how much time the processor loses on switching pages? When you use a huge data array, you have to switch back and forth because one page is not enough for your data! Yes, you might say, but there is no other option, and you would be right - at least not yet. Now imagine a continuous array of 4GB. The heart rejoices, right? Well, mine did when I read the technical description of the Z380, as well as its command descriptions for working with memory. By the way, anyone who wants to read it (the description) can download it from the Zilog page at www.zilog.com. The description is in Adobe Acrobat format, quite extensive and in English. I plan to translate it and send it to your sites, but first, I need to contact Zilog. Now back to the MB. To be honest, I just took and copied a lot of things from the PC. In my opinion, there is no point in reinventing the wheel, and what has been tested for years on various platforms we can also use. This is how it happened with the MB. The idea is simple - everything that manages or reacts to user actions must be stuffed into the MB. I am talking about numerous joysticks on the Spectrum, mice, etc. All of this needs to be combined into one device, standardly located on the MB and accessible to everyone. We just need to think and choose which joystick and mouse will be standard. In my opinion, it should be the Kempston-Joystick and Kempston-Mouse, as they use the same port and are supported in all programs. Thus, it is quite reasonable and realistic to intercept any calls to other devices (Sinclair, Cursor, Keyboard Joysticks, etc.) and transfer control to the real Kempston. I used the same principle in the Port Selector, which is responsible for compatibility with memory management ports. Over time, all programmers will switch to this type of manipulator, and old programs will simply be redone by everyone who wishes. The printer interfaces and standard Speccy devices are naturally also on the MB. I cannot say anything about printers yet. Initially, I was oriented towards the standard ZX-Lpt III, but I do not know how many users use this type of interface. Any information on this would be very helpful; I ask you all to assist me. The MB also contains the HDD, FDD, and system bus controllers. I want to say right away about the system bus. I settled on the ZX-BUS because it seemed the most convenient to me, and there are probably already many users with this bus. But any criticism and suggestions are accepted and discussed - the project is open; everyone has a say. The FDD controller - Beta-Disk Interface, is available to all and will remain so. Perhaps something new will appear over time, but for now, I would not interfere in this area due to the large number of programs and OS for this device. Now about the painful topic - the HDD controller. I have come across three schematics from Nemo, ZX-Next, and one from Yugoslavia. The differences are significant. For example, the Nemo schematic does not pay attention to the data bus of the Speccy, as it is 8-bit, while any hard drive operates on 16 bits (which, by the way, is its problem). The ZX-Next controller looks at both 16 and 8 bits, but writing a driver for it is a troublesome task. The controller from Yugoslavia is good in many ways, but it uses one PLM chip, making it difficult to replicate. I would initially focus on the ZX-Next controller or develop something new. This is also a huge amount of work for all of us. That’s all for now about the MB.
4. Memory. I have already said a lot about memory; I only need to add a few details. The Z180 and Z380 processors have a slightly different concept regarding lower memory. Their address space is divided into several segments (not like the terrible segments and A20-Gate of the PC) divided into main, lower, and upper segments. In our system, for now, the lower is the same as the upper, but in the future, this feature should be utilized. All memory, as mentioned, is divided into base (#0000-#BFFF), extended (#C000-#FFFF), and upper (#10000-#FFFFF, etc.). The extended and upper memory is clear, but the base is further divided into two sections - ROM and RAM. These are standard sections of the Speccy. All memory is managed by the Port Selector, which intercepts the addresses of the Pentagon, Scorpion, Kay, Profi, and Atm based on the principle that the first request received activates that port, while all other ports are deactivated. This means that, for example, during a program test on extended memory, the request to switch the page to port #7FFD came first. This port is available on all the aforementioned machines. The computer gives the go-ahead and activates #7FFD, while simultaneously blocking the ports of Atm, Kay, Scorpion, etc., and activating the 512KB mode via port #7FFD; the more, the better. In the future, it would be good to use extended memory as cache or additional graphics memory. Constructively, memory can be made in any way - you can use 30-pin SIP modules or simply make a board that can be inserted instead of such a module in the socket. For upper memory (above 64KB), it is advisable to use SIMM memory with an access time of 60-70 ns. This is quite normal performance for the Z180 and Z380 processors. Still, I would like to hear the opinions of experts on this matter. It is undesirable (ideally, it should not be done) to install upper memory with a processor lower than the Z180. It will only consume energy with no access. Better to stick with extended memory. Extended memory uses 4 separate slots on the MB for banks of 32, 64, 128, 256 KB. The upper memory should be made according to IBM standards. That’s all for memory.
That’s all for now. In the next email, I will talk about my thoughts on graphics, sound, modem and other communications, and a new OS for the Speccy. I again invite all interested circuit designers, programmers, and simply Speccy enthusiasts to participate in this project. Huge thanks to everyone who responded to my email and wrote me back - thank you very much. With respect to all of you, fellow Sinclairists, Andreas Kaiser Hamburg, den 31.03.1999.
Part two: About graphics, the new OS, and initial problems
1. Graphics. As I promised, in this part of my article, I will talk about the AZX-XGA graphics card. It is no secret that one of the drawbacks of the Spectrum that prevents it from becoming a more or less modern computer is its graphic resolution. However, this is also an advantage for this machine, as Speccy graphics allows for operation without additional modes and switching between text/graphics. Regardless of whether you are typing or drawing, you are always working with one area of memory. This ensures high graphics speed, of course for this class of machines, with quite low processor performance. I am certainly not the first to try to tackle and somehow solve this problem. Therefore, I have thought of the following points on this issue:
* The new card should not take up a single piece of system clock for its needs (similar to GS, but a bit differently)
* It should have its own memory that can be expanded gradually
* It should support the standard Spectrum mode
* It should not occupy a single byte of main memory for its subprograms
* It can use system variables of the OS for its purposes (I will explain why below)
* It should not conflict with any of the ROM pages; I mean the OS, TR-DOS, and perhaps shadow monitors (who knows, maybe this card will be successful enough to be included in the Scorpion environment instead of GMX)
* And most importantly, it should be easy to replicate and built on domestic components. "He has a lot of ideas," you might think, but strangely enough, all of this is quite real and feasible. I do not promise that the card will consist of two or three chips; according to my calculations, it can fit a maximum of 20 cases, including memory. Now, specifically for each of the above points.
2. Circuit design. First, to free the processor from the completely foreign task of drawing points, I have found only two ways so far - either we take a video processor for the card (which can, in principle, be made from a second Z80) or we create a circuit using a DMA controller (Zx80DMA, where x stands for 1 or 3, respectively Z180DMA or Z380DMA or Z80DMA) or a similar Soviet analog, which will independently, in a non-standard interruption mode for Speccy IM2, read information from some EMS page and output it to the screen. I chose the first option, i.e., using a video processor. To date, there are a huge number of highly integrated video processors that can build vectors, output windows, etc. As a last resort, this video processor can be "emulated" (a terrible word and quite scary in the world of Speccy). This can be done in the same way as the General Sound card was built. I would like to hear the opinions of specialists from this corporation, and it would also be nice to download their technology. Then General Video could emerge (you understand the implication - Sound Blaster, Video Blaster, Internet Blaster...). In short, you can take a second Z80, ROM, and make a card. The obvious downside is that it is possible to do this, but it requires too much knowledge of hardware and a lot of effort in selecting timing parameters. The same problem arises when executing other options unless, of course, there is some kind of sample or prototype, and who said that I don't have one? In any case, the processor should not be loaded with graphics calculations. So far, this does not particularly affect speed, thanks to turbo mode and the uniqueness of the graphics working algorithm in Speccy. But I see that our programmers are already eager to enter the realm of 3D graphics. Then the entire system clock will be spent not on code processing but on polygon calculations and others. Moreover, 7 MHz is quite insufficient. Ask PC enthusiasts how much they used to spend on direct programming of graphics card registers and how much they spend on graphics now? But this is all romanticism. I will write an email to the companies "X-Trade" and "Peters"; it will be interesting to find out how they solved these problems (although I am not sure that any of them will sell their technology for free). First of all, I am counting on your support and cooperation; I can do little or take a long time alone. In any case, I am already working on this, but from the hardware side, the card HAS ONE BUT...
3. Memory. The memory must be its own, not a single byte from the Speccy. Otherwise, we risk "shooting" every second program written today for the Speccy. Yes, the memory of the graphics card... There are several nuances: You can include the graphics memory in the address space of the Speccy, sacrificing a couple of EMS pages for this, but then it will be difficult to expand this memory, and sooner or later we will hit the limits, or you can introduce additional special ports (which will probably have to be done) through which information from the card's memory will be read independently of the system clock, but even then, special logic will be needed, like an arbiter between ULA and the processor in the original Speccy, or a DMA controller. If you use a video processor, you can bypass all this, and the number of cases will decrease, and the card will be easy to program. The size of the memory primarily depends on the maximum resolution and the number of colors, but it is worth adopting some standard for resolutions and colors (I mean, what resolutions are necessary and which can be avoided; or how many minimum colors should be in the system). The original Spectrum has 15 colors; colors after white are generated using brightness signals. Thus, using another byte for attributes and the FLASH bit of the standard attribute byte, you can get 8*8=64 colors. That’s already quite a lot, and if you splurge and install a RAMDAC (for those who don’t know, with this thing in PC cards, you can combine digital values of initial RGB colors and convert them into an analog color signal), you can reproduce at least 256 colors for each point. Yes, you might say, he has good dreams, but who will do all this? And I will answer - no one, except those who have the desire. No company in the world will engage in this, as it is believed that the Spectrum has long died, that no one needs it, and that it will never be economically viable. And they will, unfortunately, be right... Okay, what was I saying? This is not a funeral for the Speccy, but rather its baptism. As already mentioned, all of this is feasible. Now, regarding resolutions. I have already estimated how many resolutions we will need in the minimal option. Initially, there can be three - the standard Speccy screen, a medium resolution screen, and a high resolution screen. We just need to choose the sizes.
My proposal for medium resolution is a doubled Speccy screen and for high resolution is a quadrupled screen. Thus, we get - 256x192 pics, 512x384 pics (4 standard screens), and 1024x768 pics (16 standard screens). For this, we will need:
standard screen - 192*(256/8)=6144 bytes or 6 kbytes or 1 page,
medium screen - 384*(512/8)=24576 bytes or 24 kbytes or 1.5 pages,
high screen - 768*(1024/8)=98304 bytes or 96 kbytes or 6 pages.
256x192 512x384
+----+ +----+----+
! ! ! ! !
+----+ +----+----+
! ! !
+----+----+
1024x768
+----+----+----+----+
! ! ! ! !
+----+----+----+----+
! ! ! ! !
+----+----+----+----+
! ! ! ! !
+----+----+----+----+
! ! ! ! !
+----+----+----+----+
These calculations are only for data; the memory size for attributes can vary according to the number of colors. If you set the maximum number of colors displayed simultaneously at a resolution of 1024x768 to 256 colors, then you will need at least 512 kbytes of graphics memory. For this extravagance, we get photorealistic images. It is also possible to introduce at least 6 modes - three with the same attribute system as the Spectrum (i.e., coloring occurs by character positions) and three without attributes at all. Who will use this? Those who need it. But this is still in the development stage. The entire screen structure should remain the same, i.e., its construction, placement of data and attribute areas, their sequence, etc. This will allow using old programs in new resolutions, while this method of building images is one of the fastest! 17 years ago, Sir Clive Sinclair invented it, thus creating one of the fastest computers of this class.
4. Support for the standard Speccy mode. This question, in my opinion, is clear; it is needed for compatibility with programs that do not use the resources of this card. This support can be implemented in all modes.
5. Not a byte of Speccy memory. The card should operate on the rights of TR-DOS. This allows it to remain transparent for programs in Spectrum-48 or 128 format. This raises the question of where to place the Video-BIOS, on the card as a separate ROM or in the AZX-BIOS (see below). I would choose the golden mean: AZX-BIOS supports all the main functions of the card, while such things as vector construction, scrolling, etc., reside in the card's ROM. Thus, we can kill two birds with one stone (by the way, happy Easter to all of you) - we establish a hard standard that all subsequent cards must support, the second bird - we can build more powerful cards and expand its ROM and memory.
Most of you will find all of the above a complete nonsense. Naturally, the thought will arise - if this is all so easy to do, then why hasn’t it been done yet? Because most people try to profit from things related to the Speccy. But no one thinks that in Russia, they no longer chase "weak" goods. No one will buy "some unknown gadget" for money, which may or may not work with their computer. Therefore, "it is better to switch to PC, where everything has long been done, tested, and works" (ha-ha). And the number of people who truly love the Speccy is dwindling. Only they can do what was not done with the Speccy in England at the time. (I mean the Spectrum QL and Spectrum Loky).
New OS. As always, I start with my "I". I did, I thought, I... In short, I: Thought that the new OS should be just like the old one, i.e., it should also look the same. The new OS can consist of 2 parts - the standard Speccy OS itself and Speccy BIOS. In my version, the role of Speccy BIOS is performed by AZX-BIOS. It polls and sets the system configuration, provides subprograms for working with graphics, HDD, FDD, and more. After all this, it looks for the startup file on the HDD, then, transferring control to TR-DOS, looks for this file on the FDD, and if it does not find it, depending on the B-Disk switch, it either remains in TR-DOS or jumps to the standard Basic. In my opinion, this is the most optimal option, as in the absence of all the frills, the user eventually ends up in standard Basic. Where is the AZX-BIOS located? Good question, just don’t be surprised by my answer. I threw out Basic-128. Yes, I did that. Tell me, what compatibility can be discussed in this case? How many programs exist that use the PLAY and SPECTRUM operators? If there are any, then there are very few, and they are written in Basic, which can be rewritten! And the subprograms for working with printers and EMS banks can remain at the same addresses in the new BIOS. This solution also brings certain benefits - any Sp-128 starts precisely with this ROM, so any such computer can be easily updated by replacing the ROM (with machines where both Basics are in the same chip, the matter is a bit more complicated, but not particularly problematic). I mentioned above that the BIOS looks for the system startup file. This is indeed a revolution for the Speccy, but it was not made by me. Thanks to this, it is possible to have several versions of the OS on one hard drive, and to have a startup disk for TR-DOS, etc. I will not write more about the OS - the computer has not yet been made. I would like to see the new OS fully compatible with the old one and at least multitasking (multitasking os).
Lastly, I would like to express my gratitude to everyone who responded to my proposal and is willing to work with me, as well as to everyone who read these lines, weighed everything, thought it over, and decided to join this endeavor. For all questions, criticism, suggestions, and wishes, please contact me at:
Andreas Kaiser
Ohlestr. 36
22547 Hamburg
BRD
Tel.: 49-040-8315760
or by e-mail:
AKaiser@Comvers.de
With respect and wishes for success
REANIMATOR.
P.S.: Please do not write to my boss at Info@Comvers.de; he constantly asks me what these emails are about...
Contents of the publication: Rush #01
- AMIGA NEWS
Amiga Inc works on Amiga OS 3.5 with enhancements like CD drive and PowerPC support. Split development for M68K and PPC processors. Delayed release to late 1999 or early 2000.
- AMIGA NEWS
Description of the 'Fast JPEG 1.10' viewer for Amiga, focusing on its features, installation, and usage. It highlights advantages like fast processing without quality loss and provides user tips. Readers are encouraged to share their software experiences.
- AMIGA NEWS
Basic programming for classic Amiga, discussing challenges and sharing knowledge in Amiga coding. Overview of Amiga graphics capabilities and processor features. Introduction to Amiga assembly language specifics.
- AMIGA NEWS
Overview of events related to the Amiga platform from early to mid-1998. Highlights include new hardware, software releases, and notable company collaborations. Future updates and developments are scheduled for the next issue.
- AMIGA NEWS
Collection of cheats and secrets for classic Amiga games compiled by Postcard Man. Readers encouraged to share their findings on complex games. Selection of tips and level codes provided for various games.
- AMIGA NEWS
Discussion of Phase-5's graphics cards and Permedia 2 processor capabilities. Details on Permedia 2's 2D/3D acceleration and compatibility. Mention of GLINT Delta processors and comparison of prices and availability.
- AMIGA NEWS
Analysis of Amiga's survival in the 90s, highlighting community efforts and technological advancements. Discussion on hardware improvements and software development. Encouragement for further exploration and learning about the Amiga platform.
- Spectrum Programming
Explanation of a fast method for real-time 3D graphics on the ZX Spectrum. Introduces efficient rotation and deformation techniques for 3D objects. Emphasizes improvements over traditional methods with practical examples.
- Spectrum Programming - Ticklish Jim
Discussion of combining sound effects with music for Spectrum's AY chip. Examples from development of 'CSC: Deja Vu' and technical challenges faced. Contains practical guide and code examples.
- Spectrum Programming
Discussion on byte mirroring and background restoration in ZX Spectrum programming, with examples.
- Spectrum Programming
Comprehensive guide for system programmers with practical tips for creating efficient and user-friendly software, including coding techniques, device compatibility, and program testing strategies.
- Spectrum Programming
Advanced coding techniques and modern graphics methods for ZX Spectrum. Tips for optimizing graphical procedures and coding on assembly. Useful advice for programmers to improve performance and efficiency.
- The End
Reflections on the creation of the first issue of the magazine 'Rush', its goals, audience, and future development.
- ZX-SOFT - Вячеслав Медноногов
Development updates on Vyacheslav Mednoy's new game 'Black Raven II', including gameplay changes, new spell introductions, and performance improvements.
- ZX-SOFT
Overview of new features in the updated commander from REAL software for ZX Spectrum, including file management, autodetection, and media viewing. Improvements in text, font, and music handling. Questions addressed regarding future updates.
- ZX-SOFT
Debate on which demo deserved the top spot at Funtop'98: Forever by DR or Refresh by XTM. Discussions in the demoscene community highlight the clash between technical prowess and conceptual depth. Different opinions reflect on the evolution of demoscene preferences.
- Authors
Acknowledgment of contributors and partners in creating Rush magazine. Detailed roles of each author and collaboration insights. Recognition of technical support and media partnerships.
- Virtual Specky
Discussion on converting graphics from PC to Spectrum, featuring insights from various experts. Techniques for improving conversion quality and tools like Photoshop are detailed. Emphasis on post-conversion refinement in Spectrum graphics editors.
- Virtual Speccy
Discussion on the CBSpeccy emulator for ZX-Spectrum on Amiga, highlighting its features, community opinions, and technical performance. Criticisms and praises for its emulation capabilities, particularly compared to PC emulators. Examination of potential improvements and community debates around version updates.
- Virtual Speccy
FAQ on ZX-Spectrum emulation on PC, covering popular emulators and file formats. Instructions for using different emulators and managing file types like Hobeta and TR-DOS. Discussion on Russian ZX-oriented servers and resources for enthusiasts.
- Introduction
Introduction to the Rush magazine, emphasizing creativity, progressive scene, and the goal to create a superior information source. The magazine seeks to gather promising groups and offer a unique perspective. Focuses on content and atmosphere, welcoming creators to contribute.
- Introduction - Grunge
Introduction to Rush, a new scenemag for Speccy/Amiga enthusiasts, aims to provide quality content and news while encouraging reader feedback.
- Interview - Konex
Interview with ANTARES group after FUNTOP-98. Discussion on their demos, challenges, and future plans. Insight into the group's formation and dynamics.
- Interview - Kvazar, DUX
Interview with Alexander Seleznev (KVAZAR), discussing his history with computers, the state of the ZX Spectrum scene, and future plans.
- Interview - Kvazar
Interview with Vitebsk group POWER on demo 'Crazy Love', development experiences, and future projects.
- Informatorium
Exploration of a CD with emulators for various platforms, highlighting Spectrum. Details the content organization and diversity. Concludes with insights from the CD-ROM Project's Spectrum software collection.
- Informacrium
Compilation of interesting and useful Internet addresses related to Amiga resources, including magazines, hardware manufacturers, and software companies.
- Informacrium - Viator
Overview of existing and upcoming publications on the Amiga platform. Discussion of the availability and distribution challenges for Amiga literature. Appeal for collaboration with new publications.
- About the Magazine
Discussion on creating a multi-platform magazine focusing on Spectrum, Amiga, and PC. Emphasis on broader understanding of computer scene. Encourage professionalism and adaptation to changing technology.
- Parallel Worlds
Overview of the evolution of Windows OS and PC processors from 1981 to 2000. Development milestones of MS-DOS, Windows, Intel processors, and competition with AMD and Cyrix. Challenges in maintaining compatibility with new processor technologies.
- Parallel Worlds
Overview of Macintosh models and their relevance in design and graphics fields, covering prices and specifications from 1997-1998. Discussion includes the evolution of Apple's hardware, notably the PowerMac series, and compares new G3 processors with PC counterparts. It highlights the resurgence of Macintosh post-crisis and its ongoing influence in the market.
- Development of the Spectrum - Slider
The article discusses a new graphical extension for the ZX Spectrum that enhances color palettes without increasing resource demands. By using a modified flash signal, new colors are created without interfering with existing software compatibility. The article provides implementation details and addresses practical usage concerns.
- Development of Spectrum
Connecting a CDOS modem to the 'Compact-128' computer by addressing keyboard port conflicts. Description of hardware modifications to solve the issue. Solution includes automatic blocking using a transistor inverter.
- Development of Spectrum - Ars
Discussion on AZX-Monstrum 512K development, its hardware compatibility, processor options, and potential enhancements in graphics and OS.
- Development of SPECTRUM
Discussion of Clive Sinclair's new computer platform, the ZX2000, designed to outperform PCs with enhanced speed, affordability, and battery efficiency.
- Development of Spectrum - Андрей Савичев
Examination of the evolution and ongoing relevance of the Z80 processor, and its role in embedded systems. Comparison of Z80 with its successors, highlighting advantages like energy efficiency and command enhancements. Overview of integrated Z80-based CPUs and their peripherals.
- Advertisement
This article is an advertisement for Scorpion products including hardware for ZX Spectrum and Amiga software, along with pricing and ordering details.
- Advertising
Collection of advertisements for Amiga and ZX Spectrum hardware and software, with contact information for sellers and details about the new Amiga magazine subscription.
- Advertisement
Advertisement for X-TRADE's General Sound music board. Includes pricing, technical details, and purchase instructions. Features a FAQ section and compatibility info.
- Meaning Without Meaning - Viator
Philosophical reflections on existentialism, immortality, and human destiny. The narrative weaves through stories of ambition, the quest for eternal life, and a utopian downfall. A blend of introspection and speculative fiction.
- Scene vs Professionals
Exploration of the demoscene's creativity versus commercial game development. Discussion of potential for professional-quality programs by scene members. Call for collaboration with leading scene groups.
- Scene Chronicle - Андрей Савичев
Reflections on ZX Spectrum's enduring appeal, its community's resilience, and its potential resurgence in Russia.
- Scene Chronology
Overview of the Rush group's activities, including past projects, current endeavors, and future plans, with emphasis on software development and gaming.
- Scene Chronicles
The article discusses various ZX Spectrum scene news, including game releases, demoparties, and updates from developers and teams.
- Chronicles of the Scene
The article discusses the FUNTOP'98 international computer art festival held in Moscow, highlighting key events, notable attendees, and the various competitions held during the event.
- Scene Chronia
Discussion on Amiga scene development through collaboration, addressing user isolation and promoting network expansion.
- Shell Management
Статья описывает управление оболочкой для ZX Spectrum и Amiga, включая клавиши и функции для навигации. Упоминаются особенности работы на Amiga с PAL монитором и предоставляется контакт для поддержки. Также отмечено, что текстовые файлы имеют стандартную MS-DOS кодировку.
