Pentagon 2.666LE (part 1)

01 January 2025

Pentagon 2.666LE (part 1)

30vii

Studied the documentation for Pentagon 2.666LE. There is no JTAG for FPGA. Installed ADM MDK. Registration works only until 2020, do I need to change the clock?

31vii

Anyway, it compiles. I was able to compile the project for the board (build time 7 minutes 21 seconds: Quartus + cmd + Keil) and flash it (via Keil). Made a top module in Verilog (the project was in VHDL).

1viii

Transferring parts from one large VHDL module to Verilog to understand how much each of them takes up (89% of the FPGA is occupied). When flashing via Keil (Flash), do not agree to a firmware update under any circumstances!!! Otherwise, the programmer will break.

2viii

Transferring it further. The project exceeds the specified clock frequencies (the main clock is 114 MHz).

5viii

Understood the circuit. The longest signals are the data outputs for the RAM on the legs. But the frequency is violated by signals decoded from the processor outputs in the same cycle. I started to optimize them with regs.

6viii

The circuit operates at a calculated frequency of 30-34 MHz (it used to be 22, it worked at 28 by chance). 87% is occupied (it was 89%). 913 alarms. 39 clocks (it was 51).
I could not figure out the protocol between the FPGA and the microcontroller, any synchronization corrections cause glitches.

7viii

Applied author's changes to the firmware from the github website. The debugger was removed there, but I saved it - it will come in handy.

8viii

Tried to connect the TV80 processor core (T80 version on Verilog). It does not work.

9viii

Address signals do not pass, Quartus optimizes all these paths to nothing. Checked my wrappings - no errors.

12viii

At least the address counter should work, if reset_n is not stuck. Set reset_n=1. Did not help. At 0, Quartus optimizes even more. Reset other control signals - did not help. Only A[0] comes out.

13viii

Explicitly registered the width of the address bus everywhere, addresses 0..7 and 10..11 appeared.

15viii

Checked the data passage - no errors. Quartus crashes when trying to view the chip (Chip Planner).

19viii

Added additional paths from T80 project to TV80 project. Did not help, although the formation of all addresses inside TV80 is traceable.
Tried to issue a random signal to WR. Didn't help.
Same for A[15:0], IORQ, IOcycle, D[7:0] - didn't help.
Replaced iorq_after_bus (iorq of the processor, suppressed by the IORQGE signal from ZX-BUS) with virt_cpu_iorq (i.e. directly from the processor). Didn't help.

20viii

Tried to generate random signals at the top level of the project. It turned out that the M1 signal was not getting through.
Fixed it. Still something is being over-optimized (the processor is 500 cells smaller, the wrapping is 200), doesn't work (processor mattress, as if 0xff is being read from ROM).

22viii

Displayed the signals on the screen. The /MREQ signal is hanging at 0.

23viii

Tried to fix /MREQ using the old method. Still hangs at 0, but without the mattress. /RD is now also 0.
Returned the old /RD. Zeros were not fixed, but now you can see periodic /WR output (there was none before). Now the values ??in the ports change on reset.

29viii

Tried to run a simulation of my project in ModelSim. It didn't compile - had to change the order of lines and remove include. But the simulation didn't start (it didn't even compile for simulation).

30viii

Throwed out several modules (primarily memory), the simulator was able to compile and run, but what happened next is unclear.

4ix

Read the documentation for ModelSim in English.

5ix

Read the documentation further. Something related to memory simulation is found on page 256 of the manual.

9ix

Read further. On page 286 there is something about debugging race conditions.

10ix

Read further. On page 321 it starts about saving and using generated signals, with the possibility of processing (p. 362).

12ix

Read further. It turned out that in my project the output signals are not 0/1, but 0/X, because some input signals are not specified.

16ix

Checked the signal propagation time from corner to corner of the FPGA. On Cyclone I 17 ns (the longest), on Cyclone III 15 ns (the longest). I read the ModelSim reference manual.
It feels like Lisp is hidden inside, and the entire interface is controlled in Lisp, and wrappers for these control functions are brought out.

18ix

Finished reading the ModelSim tutorial. You can connect files to fill the memory (but not like in Quartus). Scripts (with a list of signals and starting the simulation for the desired time) cannot be launched by a button, only through do s.do.

19ix

I found articles about ModelSim in Russian and read them. In the testbench, you can read text files with settings that change over time.

20ix

Tried testbenches from KOE (T80, vg93 and video). Couldn't launch, complains.

23ix

Tried to make my own testbench project for T80. Seems to work.

24ix

Remade the testbench for TV80. It turned out that you can't combine Verilog with VHDL: "ALTERA version supports only a single HDL".

25ix

LVD says that this can't be, you need to take the Pentevo project as an example. Checked. Those tests don't work for me either.

26ix

Corrected the script to support systemverilog (-sv switch). Everything compiles, but ModelSim still says that you can't combine different HDLs.

This is version 6.0. Tried version 10.0 - couldn't find a license. I tried to download and install version 2021.1 - it doesn't grab the license, although its lmutil tool says that the license is there, it is written correctly, has the correct structure and has not expired. Running lmgrd does not help: "Unable to checkout a license. Make sure your license file environment variable (e.g., LM_LICENSE_FILE) is set correctly and then run 'lmutil lmdiag' to diagnose the problem". I did everything, the license is correct, LM_LICENSE_FILE points to it, but it does not pick it up.

Tried a short path, the path in the program folder, in win64 inside it - does not help.

Tried a slash in the path in the other direction - does not help.

Tried adding MGLS_LICENSE_FILE - does not help.
Tried reinstalling with license key support (files replaced) -
does not help.

27ix

KOE confirmed that my version of ModelSim is cut down,
recommended removing -novopt in the scripts. Could not find the
full one.
Remade the TV80 testbench in Verilog. Doesn't work.

30ix

Found a bug, it worked under the simulator, but there is no
/RFSH. Apparently, due to the lack of /RFSH (checked only in one
place), all calls to ports in the base project were thrown out.
Forgot /RFSH=1, flashed - does not work. There is some kind of
reaction to reset (writes to ports).

1x

Compared the diagrams of T80 (modified) and TV80: in TV80 rd,
mreq start half a cycle later (on the leading edge of clk, and
it should be on the trailing edge) and have a duration of not
one and a half cycles (rd, mreq not in m1 need two cycles on
trailing edges), but 1 cycle (it is clear that the write signal
takes a whole machine cycle).
wr, on the contrary, takes 3 cycles on trailing edges (wr needs
1 cycle on trailing edges).
rd, wr with iorq need 2.5 cycles (from leading to trailing). m1
is normal.
For wr (and, in theory, for rd outside m1?) mreq should be
extended by half a cycle.
It turned out that TV80 has incompatible tstate numbering -
running 1 instead of a counter.
Moreover, cycles are counted from 000010 (000001 only on reset),
in the iorq cycle there are two 000010 cycles.
Fixed wr, rd, mreq, iorq.
The project worked with TV80, but something is wrong with the
ports.

2x

Fixed the ports, now everything works with TV80.

7x

Moved the interface with the video controller outside, to the
Verilog part. Removed unnecessary video settings buttons.
Doesn't work (the screen is completely black).

8x

Fixed. Moved the interface with the palette outside. The entry
in the palette fell off. Tried to write this entry again.
Doesn't work.

9x

Fixed the palette. NedoOS hangs when initializing HDD/SD.
Tried replacing the TV80 kernel with T80. Quartus crashes during
assembly. Configured Fitter with the specified seed. It doesn't
crash (Quartus crashes many times later, I changed the seed
every time in such cases). The same hangs with T80. I looked for
the version that broke it (I will do this many more times later
regarding various glitches. I constantly save intermediate
versions).
In 2.8.2024 version, the T80 interface was simply moved to
Verilog, and iocycle1, iocycle2 were commented out. Returned
iocycle1, iocycle2. NedoOS loads.
Changed to TV80. NedoOS does not load.
iocycle = 4 cycles, but wr with iorq is too long, ends after
iocycle (should be synchronous with iorq). Fixed iorq. NedoOS
started working.
The image sticks to the left edge, several leftmost symbols are
missing. Fixed (shifted the SSI by 32 small pixels).

10x

Rewrote YM2149 in Verilog.

11x

Rewrote the video controller in Verilog. Black screen. Problem
with reading from memory or from the buffer, because it outputs
constants.
Tried to reduce the M1 cycle timing to 3 cycles - does not work
(the second machine cycle of the memory write command is
missing). Does not work even when reducing one nop command
(after it, the m1 signal was not generated, because last_mcycle
was not generated).
The discrepancy started with a short impulse on last_tstate (at
that time mcycles_d=010 was updated (and should be)) -
tstates=100 was reassigned (tstate continued to count for
another 2 cycles!!!). It is unclear how the short impulse could
have appeared:

tv80_core captures the command code (IR) by posedge clk
tv80_mcode asynchronously decodes the command (IR), forms
tstates
last_tstate is asynchronously formed from there
T_Res is asynchronously formed from there
tstate <= #1 7'b0000010 is reset by posedge clk; mcycle <= #1
7'b0000001 is reset by last_mcycle;
Added statesshifter, which (until it clicks with shift to the
right) is compared with tstate, which is registered with shift
to the left.
Works the same way. When trying to reduce nop by 1 cycle, there
is still a short impulse and m1 is inoperative (in reality,
important signals for the next machine cycle are prepared in the
4th cycle, and decoding in the 3rd, but there is also additional
chaos in the 3rd).

14x

Tested all video modes, tried to replace signals.
Textmode reacts to the screen attribute, but incorrectly; hires
is black; EGA is displayed, but crookedly, with incorrect
timings.
Fixed (there was = instead of == in the condition).

15x

The monitor began to shift the screen to the right (only auto
adjust helps when the screen is completely filled). I made the
hsync timing average between what it was and what I set. Shifts
to the left (again, only auto adjust helps). Apparently, the
problem is in the monitor.
Moved the debugger screen to Verilog.
The keyboard fell off. Fixed it (one process and a couple of
signals were not brought out).
The ret command was 1 t-state too long. Fixed.
TV80 has a dirty bus during interrupt (no iorq+m1 clock?). Made
a crutch inside.
Register R does not work. Fixed.
Optimized the video controller. 83% is occupied, Fmax=38 MHz.
Half of the firmware compilations are unstable.

16x

Moving the real-time clock to Verilog, simultaneously
optimizing.
128K menu does not work. Fixed.

17x

Accelerated Fmax to 43 MHz (buffering ports before reading). At
the same time, only 30 with T80! (and NedoOS does not load -
hangs after mount, in two different builds). The logic itself
fits in 46 MHz.
Writing time to the clock does not work (seconds are not
written, 0x30 is written to the hour).
Reverted I2C as it was, without synchronization - it works, but
you need to wait until half of the number is written before
entering the second (data is not updated in the FPGA until the
MCU sends them back, and it sends them rarely). Sometimes the
entire contents of the additional clock memory suddenly change
(and with different numbers every time) and you can't write to
either the clock or its memory. After reset, the functionality

is restored. eff7 bit 7 disappeared? It also goes wrong with
T80! Due to asynchronous address decoding, port eff7 was
selected instead of bff7 or dff7? (no! there is synchronous
decoding by negedge virt_cpu_clk) - did the glitch disappear
after the implementation of full synchronicity?
There are very complex calculations tied to pixel_clock (114
MHz) that will definitely not fit into 114 MHz, including in the
video controller (although there are many comparisons with
boundaries that can be replaced with masks).
114 is from PLL (*19/3).
For comparison, I rebuilt the version from github - 6429 LE
(78%), 20 MHz, the logic itself is 34 MHz (without a debugger),
949 warnings (I have 796), MCU 19 warnings (with a debugger it
was 45). Something is wrong with the programmer settings in the
project, I flashed it from my project.

18x

Accelerated to 44 MHz (simplified textmod, RAM addressing
conditions, etc.), the logic itself fits into 52 MHz (56 MHz in
another build).
In the debugger, characters randomly flash across the screen
(they did not flash before my changes). The debugger screen is
flipped entirely, in 64-byte blocks. The same letters blink,
which are 64 apart - if the lower addresses are all 0's or all
1's. Characters are taken from the adjacent block of 64.
textbuffer_rd_addr and textbuffer_clk are registers. Moreover,
the letter is displayed incorrectly as a whole, although it is
read several times (on each line). I tried to put more registers

it does not help. The problem is due to different clocks for
reading and writing to the textbuffer. Fixed.
Since version 16.10.2024, cmosbuf writes time to the MCU, but
does not write to the FPGA. Fixed.

21x

Removing negedge pixel_clock usage - Fatall doesn't work. I do
hardware_reset processing by pixel_clock - fixed it. But at the
same time, writing to the clock and clock memory broke.
negedge pixel_clock is left only in the signals of the memory
itself. Removed. The clock shows not the current cell, but the
one addressed earlier (does not apply to cells with time). Fixed
by clocking cmosram from pixel_clock. Reading from cmos memory
broke (0, if you return just the cell number, only cells with
time are read).
Optimized the conditions of memory signals and the video
controller. Already 6757 LE, 25% device routing resources.

22x

Moving i2c to the pixel_clock domain. Even the initial screen
stopped working several times (apparently, synchronous i2c added
extra clock cycles).
Fixed reading from cmos memory and writing to the clock (all by
posedge pixel_clock).
Interrupt is broken (with T80 too). Fixed it (line number reset
is in the wrong place).

23x

Video modes are broken - fixed it.
NedoOS does not boot with T80 processor - hangs after mounting.
Hanging can be on OS_SETSYSDRV and then in FatFS. The thing is
that I simplified the data bus mux. Tried to return ports
without intermediate register - NedoOS started to boot on T80.
Left only spi without register - does not work. Added kempston
and cmos - does not work. Betadisk instead of them - does not
work. AY, kempston, betadisk, spi - does not work. Without AY,
but with mouse - does not work. Everything except unused page
reading ports - does not work. In other combinations too.
Requires all branches. Apparently, unpredictable glitches due to
asynchronous design. Too fast logic in one place causes problems
in another.
When it freezes, it is clearly not spinning in the OS addresses.
Tried to enable 57 MHz for the processor. Doesn't work.
Tried to enable 28 MHz always. Access to the SD card is broken.
Tried to make it without a delay - Fitter crashes. Instead, I
removed IDE - i2c is broken. Returned the old i2c - Quartus
Fitter crashes. Returned both - a record, TV80 assembled at 50
MHz (the rest at 44), but the SD card does not work.
Transferred parts of the circuit to dvixel_clock (57 MHz). The
port buffer was transferred normally (maybe to 129 MHz), but the
SD card still does not work.

24x

I transfer the memory to dvixel_clock. To maintain the phases, I
made negedge everywhere (the counter changes according to it).
The SD card works.
6912, 16s: frame is lagging behind by 1/2 px - fixed.
Textmode: attribute switching is lagging by 2 pixels - fixed,
but now there is black border.
The processor crashes even at 3.5 MHz in some builds.
Some builds have no screen at all.
VG93 does not work for writing and reading. VG93 turned out to
be on pixel_clock, and also using negedge. Switched to negedge
dvixel_clock. Black screen (the processor works! the debugger
works! the border works!)
Returned pixel_clock to VG93, but only posedge. The screen
returned. When trying to read from VG93, the processor freezes
at 3f27, only a reset saves, and even then it does not respond
every time.

25x

Made a mock instead of VG93. The number of warnings decreased by
half. But still a black border.
Tried to set a stable 28 MHz on the processor - no screen, the
processor does not work.
Tried to set stable 14 MHz on the processor - no screen,
processor does not work.
Tried to set latching by negedge dvixel_clock instead of
latching by posedge pixel_clock - no screen, processor works.
Removed the border buffer. The border appeared, but the screen
was black (and in text mode all symbols are equal to 0,
attributes are normal).
The same with a constant 28 MHz - no screen, processor does not
work.
Returned the flexible frequency - no screen, processor does not
work.
The same without delays from VG93 - black screen, processor does
not work.
It would seem, why can screen signals disappear and be
distorted? They are tied only to dvixel_clock! It seems that you
can not synchronize by the 0th digit of the prescaler (i.e. by
dvixel_clock) and at the same time use the 1st digit of the
prescaler - they are out of sync. Made a separate counter from
the 0th digit, it is used to switch the memory phases. It
worked.
Returned the border buffer and attributes. Set a constant 28 MHz
from the memory phase. The processor does not work.

Set a constant 28 MHz from the prescaler (what difference does it make when it is then latched by dvixel_clock?). The processor works, the SD card does not work.
Made the SD card read past the port buffer. Even the initial screen does not load.
Changed pixel_clock to dvixel_clock in a couple of places. The processor works, the SD card does not work.
Too fast access to the SD card? Made wait in groups of 8 57 MHz cycles (4 28 MHz cycles) (wait was not used in the circuit before. wait in the processor is taken into account only in tstate[2]) - a processor mattress.
Set 3.5 MHz - the processor hangs at address 0 (it catches wait all the time?).
Set 14 MHz - a processor mattress, the processor is most often at address 38.
T80 instead of TV80. The same thing.
Replaced wait with cen (clock enable, all actions are wrapped in it, it was stably 1) - black screen, the processor is most often at address 0. Somehow it reacts to reset - writes to ports.
Made cen in the cpu_clk domain - the processor runs across all memory. Somehow it reacts to reset - writes to ports.
Set 3.5 MHz - the same thing.
Removed cen, returned the flexible frequency - everything works.
Connected VG93 back (by pixel_clock) - the commander says NO DISK, Fatall hangs when trying to write.

28x

I'm trying to remove VG93 signals to find out what affects it. I removed reading from ports - it hangs on reset, then it works. Reset does not work every time (hangs at 0).
Made synchronous decoding of xxf7 addresses by negedge virt_cpu_clk (readable ports are decoded by negedge dvixel_clock, but they should not greatly affect the behavior of the computer), returned the ports of VG93.
CMOS fell off (only preset cells and ADC are read). When accessing VG93 - NO DISK.
Why does not "cen" processor stopping work? This is the only correct synchronous method! There is nothing suspicious in the source. Tried cen every second clock cycle. The processor hangs at 0, does not respond to reset. In the source, the reset lasts many clock cycles, ends on command. Made a 5-bit counter - a processor mattress. Replaced the vg93 module with a dummy vg93fake - the same thing. Wrapped external processor signals (which I did) also in cen. So the reset works intermittently (sometimes it writes nonsense to the ports).
Set 57 MHz always (cen on every second clock). The menu works, the SD card does not work. Writing to the border does not always work.
Set cen in 3/4 clocks (equivalent to 14 MHz) - the SD card worked.
Made equivalent 7 MHz by iocycle, otherwise 28, removed unnecessary resynchronization signals. Processor mattress.
Made equivalent 7 MHz always - sometimes it resets and works (CMOS works, writing to other ports is unstable).
Now the processor is synchronized mainly by posedge dvixel_clock, and the rest mainly by negedge dvixel_clock.
I redid everything on posedge dvixel_clock - the video controller does not read the memory (it also does not show the initial splash screen).
Removed main_state_counter - video controller works. Reset and writing to ports (and possibly reading) are unstable.
Made negedge virt_cpu_clk dependent on cen not now, but at the time of posedge - the same.
Found another synchronization from negedge virt_cpu_clk, replaced it with posedge dvixel_clock - the same.
Made equivalent 7 MHz by iocycle, otherwise 28 - the same.
Made equivalent 7 MHz by iocycle, otherwise 57 - does not work (vertical colour stripes).
Optimized IncDecZ via I_DJNZ_reg.

29x

Transferred cmosram and debugger to posedge dvixel_clock.
Optimized conditions for writing to the registers. Debugged in ModelSim. Interconnect usage is 20-22%. Fmax reaches 50 MHz. Design Space Explorer cannot determine the operating frequency and does not write seed on the fly.
Tried to allocate a region for the processor (in Quartus 11 it is no longer the same as in 7) - does not help to speed up.
35x10 does not compile. With Auto only 38 MHz (suggests a region of 15x13, minimum 15x11 - says it will not be optimal).
Interrupt timing is incorrect, the divisibility of t-states by 4 is lost. Removed Auto_Wait in interrupt capture - the number of t-states was corrected.

30x

Optimized the last_mcycle condition. In ModelSim, everything fell apart (although it works in hardware). In theory, the discrepancy should only be on the 3rd clock of the 1st machine cycle (where the command is decoded), I made a separate condition there. In ModelSim it's ok, although with a needle between the 3rd and 4th cycles. It works in real life too.
The left pixel in hires is not visible - fixed it.
Signed signals with reverse logic as _n.
At 3.5 MHz the keyboard does not work and KOT freezes. The int signal is generated synchronously and taking into account cen. The commander was fixed, but the keyboard test and Fatall freeze (the basic works at 3.5 MHz). KOT started working, but the border autosynchronization does not work.
Interconnect usage 19%.
With T80 - processor mattress (the estimated frequency is 32 MHz, but it should be 57 MHz, and on TV80 the estimated frequency is always 42..50). I tried to make separate paths in the registers for ex de, hl - 38 MHz for some reason (sometimes 45).

31x

Also optimized the calculation of last_mcycle.
Fixed recalculation of machine cycles on commands with index addressing (a number was made from a bitmask, although a bitmask is needed).
Moved incdec16 to clock 4 (it was in 3, only sp in 4) - 46 MHz. But now the brakes are no longer in the main registers, but in the address and data buses (the IR -> do chain is hidden somewhere), and also in the P flag.
Optimized the P flag - now 50 MHz.
Reduced the port logic.
Reduced breakpoint_event (only 8 breakpoints instead of 16) - 52 MHz.
Moved the bf port to posedge dvixel_clock - 57 MHz (for the first time), but the reset sometimes goes to the wrong place, Fatall and sd_boot crash.
Returned tapein, added a dos reset - 54 MHz, but everything broke.
Made dos for 1 clock cycle (immediately in the clock cycle of

writing to the bf port or accessing the address), and not for 3 - 54 MHz, the crashes were fixed, but the border and reset are unstable, Fatall still does not work, although NedoOS works.

Made 57 MHz with biting off the clock cycle after detecting the start of /MREQ. Does not work (vertical stripes, does not respond to reset, addresses tick).

Made 28 MHz with overclocking to 57, when there is no clock after detecting the start of /MREQ. The same.

Made biting off asynchronously from the start of /MREQ. Assembled at 55 MHz. Hangs, does not write anything to the screen, does not respond to reset.

To make it during the start of /MREQ and at the same time to not fly out of the dvixel_clock domain, pulled the promise of /MREQ from the processor on the next clock cycle. Assembled at 55 MHz. The same.

Tried to simply allow 57 MHz when memcycle=0 (made it for the whole clock cycle, but did not check). Build at 56 MHz. Writes nonsense to ports and memory.

Tried to tie to cpuram_flag (now the clock cycle biting counter is independent) - same thing.

Made megaturbo switching on reset and promisemreq before each mreq clock cycle, even with a reserve (clock cycles 1 and 2 (i.e. before 2 and 3), except for the iorq cycle). Same thing.

Looked in ModelSim - promisemreq is issued simultaneously with mreq on the falling edge of clk, and on the next rising edge of clk a decision is made to press cen. In theory it should work, but it does not.

ModelSim shows that the processor is not working correctly! It seems that it really works only when there are not two cen clock cycles in a row. Made a slow last_tstate (this is how it works in ModelSim). 54 MHz. Still doesn't work.

1xi

Checked with substitution of values instead of memory - works with both border and screen (read and write).

Made the debugger to show not just the processor address bus, but the command address.

Checked with interrupt enabled - doesn't work (most often ffxx addresses - how does it get there? 38 can also happen).

But if you connect memory, it instantly gets filled with 00 3d.

Removed the rd,mreq abbreviation in m1 - didn't help.

Made ret always to address 3 (suddenly it can't read from the stack) - works.

Without interrupts, but with rst 0x38 - doesn't work.

Put the stack in the screen to see - is it writing nonsense there?

Reset is unstable - something with the first command. Tried to shift (first di) - same thing (build was at 60 MHz).

Added mreq to the cen condition - same thing.

Made ret always to address 6 - works and writes to the stack correctly, reset is stable.

Is there something wrong with DI_Reg in last_tstate? (latches to tstate[2] by posedge clk, as well as dinst - both taking cen into account).

Added busak_n to the latch condition in DI_Reg - does not help, reset is unstable again.

Tried to make stack memory in internal regs - works and writes to the stack correctly, reset is stable.

The same with a delay per clock (including for commands) - works, reset is stable.

What could be wrong with the real memory? The delay in memory is also 1 clock!

Fixed cen_buffered - worked in ModelSim. With rst 0x38 it writes incorrectly. Replaced with nop - writes zeros in memory (or reads ff?). Tried writing numbers - writes.

Expanded promisemreq back to tstate[2] - test works (but ModelSim gets an extra brake cycle).

Returned rst 0x38 - doesn't work at 57 MHz, reset is unstable (although it worked at 57 MHz).

The address is set at the beginning of the machine cycle, before mreq. After all the muxes, it latches at the beginning of tstate[2], and then the control signals.

At the end of tstate[2], the result latches - a total of 2 cycles from setting the address.

Trying with raining (the processor has priority over everything when mreq) - works unstable even at 28 MHz, writes nonsense.

Tried to simulate an address delay of 2 cycles in pseudo-memory - doesn't work at 57 MHz.

In ModelSim it doesn't work like that either, they process di, ld sp, and the next command code is read 0x40 - from the previous address (0003)!

address 0004 was set simultaneously with m1, latched at the beginning of tstate[2].
all the time tstate[2] didata is read 0x26 (correctly).
at the end of tstate[2] the memory output data is latched - didata_r.
at the beginning of tstate[3] di is formed by mux - goes directly to dinst, latched in IR at the end of tstate[2]!!!

Tried to make asynchronous reading of RAM, without latching - does not work even at 28 MHz.

Inverted cpuram_flag (for 3.5 MHz it was already correct) - 28 MHz works, 57 does not (reset does not pass - addresses do not switch at all).

Reset some signals in the processor - now the addresses are going, but nothing is written to the memory (it is written to the ports correctly, judging by the palette! and at 28 MHz it is incorrect).

Made promisemreq taking into account wr. At 57 MHz it writes, but it works unstably (build at 53). The demo Reset + D started.

Optimized mreq. At 57 MHz now almost everything works, but it glitches. The SD card is not available at 57 MHz.

Added a speed of 14 MHz for working with the SD card. It glitches even on builds with Fmax = 58 MHz.

The computer works at 57 MHz (with an average delay of half a cycle per machine cycle - equivalent frequency of 52 MHz), but with glitches!

2xi

Extra reset at computer startup: the processor works, the ROM is flashed on the fly, then reset, and the debugger starts working. This is because I previously removed the "remove reset" command and replaced it with a counter. Returned it as it was (now synchronously).

The Board does not work at any speed (includes hires). This is due to the replacement of the dos_n signal behavior - done synchronously. Tried by negedge - did not help (build on 55). Tried by m1 (without mreq, but taking into account rfsh) - did not help. Tried by the m1 front - does not work at all. Tried by the m1, mreq, rd front (as it was) - did not help at 28, broke 57. Returned it as it was yesterday, only rewritten it differently - works.

Fatall hangs at 57 MHz (works at 28).

Edge Grinder hangs on the splash screen. These are the changed conditions for writing to ports. Returned full dff7 decoding - did not help. Returned the old code - did not help and the SD card fell off. With new decoding 7ffd - Edge Grinder does not work. Fixed 7ffd in today's version - Edge Grinder works at both frequencies, but the SD card fell off (build on 53). Replaced seed (build on 54) - SD card works.

Reducing the number of complex signals that are on the verge of getting into 57 MHz.

Optimized "di" of RAM (more precisely, "do" of the external part of the processor). 58 MHz, unstable, SD card does not work.

Made writing in the main ports through buffering of all signals - unstable, SD card does not work.

Made all ports this way - unstable, SD card does not work.

Made memwr_n signal in the processor - unstable, SD card does not work.

Took into account z80_to_ram_n = '0' in vg93_rd/wrtransaction - build at 59 MHz - unstable, SD card does not work.

Removed do optimization - build at 52 - no SD card, 57 MHz does not work.

Tried via write_buf_negedge - build at 59 - no SD card, at 57 in CMOS setup the keyboard arrows are pressed glitchily (in the keyboard test it is normal).

Returned the ports to the old way - the SD card works, but 57 MHz is glitchy.

Made switching megaturbo by button. The Board works at 57 (if you switch on the fly). NedoOS does not work at 57. Something with interrupts or with switching pages?

Made dos_n on nededge - didn't help

Made dos_n on nededge and only m1 - helped with Edge Grinder and NedoOS, but SD card doesn't work on 57, Fatall hangs on 57, even if you turn it on on the fly.

Made 28 MHz when accessing SD card on 57 MHz (31 cycles).

First stable build on 57 MHz, but without VG93 and ZX-BUS, SD card only on 28 and lower (p2666_megaturbo.zip)!

5xi

Added ebl_n (blocking ports from the bus) to decoding when reading ports. Fixed reading external ports (not tested).

Tried reading SD card in the previous cycle - doesn't work.

Made the SD card synchronous with dvixel_clock - not all builds work, and after trying to access at 57 MHz, the SD card drops out at 28 MHz (build at 59 MHz). Made a single read of a byte from the SD card. Build at 57 MHz - the SD card does not drop out (but does not work at 57 MHz either), 57 MHz works unstably.

6xi

It seems that a delay of 31 clock cycles is not enough for the SD card, since it works with 8-bit bytes, each bit for 4 clock cycles, and there are 12 clock cycles between operations (in Fatall can be even 11 (out (77),a: out (57),a), other cases are 16 between operations, but in NedoOS 12! How does it work on 28?).

Made 63 cycles. Didn't help (build on 59 MHz).

Made the start of the delay 1 cycle earlier - didn't help. After switching frequencies in Fatall, it spins on 71d0 "in a,(57):cp e:jr nz" (e = ff?).

Tried to return reading the SD card in the data bus multiplexer - this makes 57 MHz very unreliable, doesn't help.

Tried to read data from the SD card not by address, but by all signals (the iorq cycle allows you to make 2 cycles) - didn't help.

On 57, Fatall and sd_boot don't work, but NedoOS works now (if you turn on 57 after all mounts).

x86.com crashes in Livin and Digger (I for start) during the process (doesn't crash in the emulator), once the system hung on Chess (1 for start) and once in Ratillery (doesn't hang in the emulator) (build at 61 MHz).

Tried sd_clock 28 MHz, not 14 - the SD card stopped working at a processor frequency of 28 MHz. 57 MHz is unstable (build at 60).

Tried sd_mojno0 not after the first clock cycle, but immediately, and resetting the sd_clock phase when accessing the port - does not work.

Left only the phase reset - it became as before.

Made all the resets and settings in one clock cycle with port decoding - nothing changed.

Simplified the conditions for forming SPI without any sd_mojno - it works only at 28 (all these builds at Fmax=57 MHz and higher).

Made a complete stop of the processor at 63 clock cycles from the moment of accessing the SD card - works (build on 58), but 57 MHz is glitchy.

Made a complete stop of the processor during reception/transmission - everything works (build on 56).

The same only in 57 MHz mode - works (unstable build on 61, 5806 LE).

28 MHz during reception/transmission - it works (build on 56).

Connected VG93 - hangs when accessing the disk, does not reach "no disk".

Made VG93 write to registers synchronously from dvixel_clock - the same thing.

Replaced the data when writing to VG93 with buf_cpu_d - the same thing.

Fixed delays in VG93 for dvixel_clock (instead of pixel_clock) - the same thing.

Removed VG93 access to RAM - same thing.

SD card works at 57 MHz (p2666_sdwait_56_stable.zip)!

7xi

Disk access mainly spins on:

3ef5: in a,(ff)
      and c0
      jr z,3ef5
      ei
      ret m
      di
      in a,(7f)
      jr 3ef5

(i.e. 01111111 = {vg93_intrq, vg93_drq, 6'b111111} is read from ff, as if the sector never ends (no intrq)).

Put comments and _n in signals with reverse logic.

8xi

Fixed work with external bus.

Rewrote request from VG93 to memory on negedge dvixel_clock. Doesn't work.

Rewrote the request from VG93 using primisenomreq - did not help.

Made a skip reading of bytes in VG93 - does it hang? It still hangs, the byte number does not tick.

At this time, read_addr_flag=0.

Made a crutch in reading the address - exit immediately. Shows Disk Error.

Removed the skip reading of bytes - during reading the screen goes out, hangs on sector=9, read_byte_number=0 (sometimes 3).

Only removed the skipping of the delay, in reading the address reduced the delays to 57 MHz - everything is as originally.

Reduced the delays to a minimum, replaced the processor signals in VG93 with buffered (synchronous with cs) - still hangs.

Returned the delays for 57 MHz, made both readings synchronously from dvixel_clock - still hangs.

Made the output of cs for one clock cycle.

Made delays for 57 MHz in sector reading, changed the order of conditions - still hangs.

As if cs does not come at all during the address reading command. Fixed cs at rd - reads solid ff.

Made the VG93 data register always available for reading, without synchronization by cs - did not help.

11xi

Made synchronization of the start of the VG93 request by negedge - reads numbers like 0x74, 0x64, 0x24, 0x34 (Fmax=54 MHz).

Optimized delay_vg. Does not work at all - dots on the boot screen (all on D7). Reassembled with another seed (56 MHz). Dots disappeared. Reads the same numbers.

Made VG93 request signals not by regs, but by logic. Assembly at 56. Reads numbers 0xf5 (possibly also 0x75).

Rewrote the data reception condition for VG93. From this moment almost all assemblies on Fmax=57 MHz and higher. VG93 works (reads and writes), 57 MHz mode is buggy.

Simplified VG93 data reception and output cycles (waiting just by counter) - so reading does not work. Returned reading wait by processor, fixed negedge. Writing does not work. Returned writing wait by processor. Did not help (assembly on 57).

Returned request capture check (I do not check request processing - this is 1 clock, it is always processed) - fixed. But VG93 does not work for reading on 57 MHz (NO DISK, address 2f8f was visible for some time - caller 48 from DOS, for break), although it works for writing (assembly on 55). Made 28 MHz in DOS. VG93 works completely.

Made motor synchronously by dvixel_clock. Issued cs VG93 for one clock cycle, returned 57 MHz in dos - did not help. Therefore left 28 MHz in dos.

59 MHz, 6458 LE (initially was 7171, in github 6429 without debugger), interconnect usage 19%.

3094 dhrystones/s.

Made promisemreq by posedge.

Converting I2C to synchronicity. Described the protocol.

VG93 works (p2666_vg15.zip)!