News

News

by Alone Coder

This issue was originally planned for the New Year, but due to family circumstances it was delayed by the celebration :)

This issue is special - it is compiled from diary entries during the work on accelerating the Pentagon 2.666LE firmware (there was only a brief mention of this modification in Info Guide #14 ). It is known that hardware people rarely describe their work process, so I will fill this gap (even though I am not a hardware person). These descriptions should help those who will also start doing something similar or continue this work.

• before: the entire project in VHDL, with a T80 processor (modified).
• after: most of the project in Verilog, with a TV80 processor (modified).
• before: an asynchronous circuit with two different-phase clocks of 114 MHz and 42 additional clocks (synchronizing signals from each other).
• after: a synchronous circuit with one clock at 57 MHz.
• before: fixed grid of RAM accesses: processor, video controller, processor, video controller, etc. (the floppy disk controller used free processor cycles).
• after: adaptive grid of RAM accesses (priority arbitration).
• before: processor speed was regulated by a special clock calculated for it, no more than 28.5 MHz.
• after: processor works on a common clock of 57 MHz, processor speed is regulated by cen (allowed cycle) + Mode (shortened command timings), effective frequency up to 63 MHz according to dhrystone - the fastest ZX Spectrum clone at the moment.
• before: the debugger could not read memory, so it did not have a memory dump, only the processor address bus, breakpoint addresses and the state of the floppy disk controller.
• after: the debugger reads memory, registers, ports, displays the dump and disasm.
• before: the processor stopped after the breakpoint, the execution address (PC) could not be changed.
• after: the processor stops at the breakpoint, in the debugger you can change PC and memory contents. Can skip HALT when stepping.

Everything is done with small gradual changes. Experience, as usual, has shown that the greater the change, the more trouble with debugging.

ZX Spectrum speed growth chronology:

• the original 1982 model worked at 3.5 MHz with delays when accessing memory.
• in 1985, in Spanish 128K, the processor frequency was raised to 3.5469 MHz, and Investronica also released a 48K version without delays.
• in 1986, "Baltik" with a frequency of 4 MHz appeared in the USSR (it later became a prototype of the ULA for a number of clones).
• in 1988, SAM Coupe and Tim-S with 6 MHz appeared in Great Britain and Romania, respectively.
• no later than 1990, PLM Avtomatika with 7 MHz (without delays) and a turbo scheme for Leningrad at 7.25 MHz (with delays) appeared in the USSR.
• Profi+ of 1992 allowed to increase the processor speed to 12 MHz (with delays) by replacing the oscillator.
• no later than 1997, VMG (Kharkov) made a modification of Pentagon 128K to 14 MHz (with delays). At the same time, a prototype of the Sprinter computer with a frequency of 14 MHz was discussed.
• in 1997, Ivan Mak (St. Petersburg) released Sprinter with a frequency of 21 MHz (with delays).
• in 2006, ZX-Badaloc with a frequency of 21.25 MHz appeared.
• Pentagon 2.666, released in 2008, operates at 28.5 MHz (ZX Evolution 2009 at 14 MHz, but still faster than the mentioned modification for Pentagon 128K; Speccy2010 (2010) operates at 28 MHz, but with delays).
• in 2008, the author of "ZX-Badaloc reloaded" wrote about the virtual processor frequency of 42.5 MHz, and in 2013 there were rumors about an experimental firmware for ReVerSE board at 42 MHz.
• around 2017, firmware for MiSTer board appeared, implementing the ZX Spectrum core at 56 MHz. In 2017, VladimirS (Beryozovsky, Kemerovo Region) also experimentally tested the performance of the Z80-compatible KL5C8400C processor from Kawasaki at this frequency, which has a nominal frequency of 33 MHz and optionally enabled short command clocks.
• in 2024, Pentagon 2.666LE firmware (2009 board) added support for 57 MHz with shortened clocks (equivalent frequency of 63 MHz).

The Pentagon 2.666LE board is good because it has static memory with a response time of 10 ns. Of course, this is not the most ideal for speed records (Cyclone II - 2004 series, 90 nm technology), so my record can be broken quite quickly. In any case, this will benefit the Spectrum. On the other hand, the result for Cyclone II shows that on domestic FPGAs (5578ТС118) it is theoretically possible to achieve similar results. Moreover, the Pentagon 2.666LE itself can be accelerated further - due to the processor pipelining, but I can't do it.

So far, we have not even reached the maximum speed of the KL5C8400C, let alone the eZ80. But the current result has already raised two important questions:

1. Standardization of ZX-BUS. First of all - correct reactions to signals and restrictions on timings. So far, even the dimensions and location of the connectors are not documented!

2. With the system software and utilities everything is clear, but how to write games that use such speed? If we want 50 fps on the fastest computers, then on slow ones the logic at 50 fps will slow down a lot!

Regarding the second point, the problem has already been resolved in the patched version of the game Borsch, which (with the source code) can be downloaded from my website as part of the 3D engine. The movement of the player and the camera is tied to 50 fps (in the interrupt handler, so there are no lags with controls), and everything else (slow processing of objects) remained at 18 fps. The result looks nice. Although you can't record the game progress with this - there will be desynchronization during playback. There will also be problems with the network game. Does anyone have any ideas on how to fix this? Contact me!