Release: Better memory management, shifter wakestates, MMU configuration

This new zeST release brings a major fix in memory management, introduces “shifter wakestates” , properly implements MMU configuration, and includes other small fixes.

Memory management

zeST now includes a much better manager for accessing the main DDR memory of the Zynq board it’s running on. This is not strictly related to the Atari ST implementation, but rater to the management of the host hardware to be able to use it with the best performance. I tend to consider the zeST hardware implementation in two distinct main parts: one that handles the hardware of the board it is running on (the platform part), and the other that implements the Atari ST hardware on top of that platform part (the core part). Clearly, this new upgrade concerns the former, the platform.

So what does this upgrade do? In this old article, I explained how memory access management works in zeST, which basically consists in performing one access to the DDR at each RAM request from the ST (for the 68000 bus and the video system). To deal with latencies related to how the DDR memory is handled on the Zynq platform, I sort of skew the ST clock so memory accesses seem to perform in one cycle from the ST point of view, but many cycles of the platform. So we’ve got “long cycles” when waiting for a memory access to finish, and “short cycles” when memory is not used. Under different circumstances of use, we were lucky enough that the repartition in time of “long” and “short” cycles was such that we could maintain a simulated 8 MHz clock frequency so the ST just works correctly. However, there were scenarios, such as “fullscreen with nops” in which too frequent memory accesses drove zeST to stop working. At the time, I proposed a possible future fix as a cache mechanism on DDR accesses. This new release includes exactly that.

So, how does it work?

The platform memory manager in zeST now includes a 16 KB cache memory, that helps drastically reduce the number of direct accesses to the DDR memory, saving a lot of time in most memory accesses by the Atari ST core. This cache memory is implemented using a few block RAMs that are present on the FPGA. The cache management policy is “write-through”, which means all write accesses are done to the main memory. This is the simplest policy, which has the advantage that is reduces FPGA resource consumption, and it seems to be sufficient when running code with the highest possible memory access rates.

Memory reads are now done in bursts, which optimise how DDR memory works. A burst is a sequence of accesses to several words (32-bit words in our case) in consecutive addresses in memory. Dynamic RAM such as DDR allows very efficient burst accesses: you get latency only for the first word in the burst, then all subsequent words are accessed in one cycle. And I am talking about platform cycles, not the simulated 8 MHz cycles for the core part. In current versions of zeST, the platform runs at a frequency of 100 MHz.

The cache memory is organised in lines of 256 bits each. For each read access request from the ST core, the corresponding cache line is fetched from the cache memory, along with a state and address tag. If it occurs that the line contains valid data for the request address, the data value can be returned directly and the read access is done. Otherwise, the existing line is replaced with data that is fetched from the RAM in a single burst, and then the read request can be fulfilled. Caching usually works well, because programs are made of instructions that are executed in sequence in memory, and also the video is displayed by reading memory in a regular, sequential order. So once a cache line is fetched when accessing one word, there is great chance that other words from the same cache line will be accessed soon.

I am confident this new memory management will solve most memory access issues in previous releases of zeST. It also opens the path to the implementation of more memory-demanding platforms such as the STe, the Mega STE or even the Falcon. Porting of other existing FPGA cores using the zeST platform should also be made easier.

Shifter wakestates

This new release also includes Shifter wakestates.

These are two possible wake up states in which the Shifter, the chip that converts video data into pixels that are displayed on the screen, can be on. This is due to the fact that the 8 MHz clock it uses is not the same as the 8 MHz clock of the CPU and bus of the ST: it can be either in phase (both clocks are 1 (and 0) at the same time) or in anti-phase (one clock is 1 while the other is 0). I am not sure of the real consequences of being in one state or the other, but there are developers over here that might find this interesting. This will not be of any use to most users.

MMU configuration

On the original ST, the MMU is responsible for handling the memory chips that are present. Depending on the diffeent possible hardware configurations (128 kB to 4 MB of RAM), including the fact that smaller memory chips do not have the same number of address pins as larger ones, the MMU is able to produce a single, contiguous memory space. At the boot of the ST, one of the first tasks in the system code in ROM is to configure the MMU, by performing a series of tests to detect the type of RAM chips that are present. This is based on detecting which address pins are connected or not. Then, the ST properly configures the MMU depending on the detected memory configuration. After that, since some ambiguity may persist in some specific cases that can not be differentiated by just reading the memory configuration value, a memory testing loop starts to determine the actual available amount of memory. After that test, the proper system variables are set to the correct memory size.

The previous zeST releases included a very simplified MMU management. Since we already have got a contiguous memory space, we could just ignore changes made to the MMU configuration and let the OS detect the set up memory size. This was working well, until a new demo by Newline pushed zeST a bit beyond its limits.

Ika Y Compofylla introduced an amazing new effect based on bus noise, that had just been implemented in the previous release of zeST. It actually worked well in configurations with less than 4 megabytes of RAM, but not on 4 MB. This new release fixes this problem.

Other fixes

You can now configure a RAM size of 8 megabytes. Until now, there was no intermediate RAM size setting between 4 and 14 MB.

Minor changes have been made to the system menu, allowing the setting of extended RAM sizes and Shifter wakestates.

Conclusion

That’s all folks! The next steps will involve other bug fixes and improvements. One of the major necessary changes will be to fix the menu system for ergonomic improvement.

As usual, download and setup instructions are available on the Getting started page.

For any comments, do not hesitate to do it by replying to the dedicated Fediverse post.