Writing a new SDRAM controller – part 3 – 2021-07-25
In the previous instalments I talked about improving throughput by interleaving read and write transactions to different banks, as well as access patterns I need to avoid and some subtle timing issues which need to be considered.
The challenges remaining to be solved are ensuring that the controller responds in good time to incoming requests on multiple ports, and making the controller run fast enough that it meets timing at the desired speed. For the PC Engine core the desired clock speed is 128MHz
Writing a new SDRAM controller – Part 2 – 2021-07-10
Last time I talked about the form of a typical SDRAM read cycle, and how we can improve the overall throughput by interleaving reads to different banks.
The same principle applies to write cycles, too.
Part 1 – 2021-07-04
In my last post I talked about the need to adjust the SDRAM controller used by the Megadrive core to make it work on the TC64V2, and having released that port it was time to turn my attention to the PC Engine core.
This one has actually been on the back burner for months. I started to port it at the beginning of the year, found that it didn’t work on TC64V2 and didn’t yet understand why not. With plenty of other projects to keep me busy I neglected this one for a while, but revisited it recently, armed with fresh knowledge about why it wasn’t working.
To recap, I had chosen the MiST Megadrive/Genesis core as my next project in porting to Turbo Chameleon 64 – in theory a simple task since the core leaves enough logic and block RAM free to simply bolt on the DeMiSTify component and go.
Well, nothing’s ever simple, is it? The port worked fine on the Turbo Chameleon 64 V1, worked fine on DE10-lite, and failed on Chameleon 64 V2.
I’ve finally turned my attention to porting the updated version of the Megadrive/Genesis core to the Turbo Chameleon 64. Since I last had any input into this core it’s come on in leaps and bounds, and adding the DeMiSTify module to make it run on controllerless boards would be next to trivial.
Or so I thought…
Exploring audio DACs in simulation – Part 3 – 2021-04-03
Having set up a simplistic testbench in Verilator, I want to be able to use it to evaluate several different DACs. The ones I will be testing are:
- The simple 1st-order Sigma Delta I included in my last post.
- A 2nd order DAC found on Github: https://github.com/hamsternz/second_order_sigma_delta_DAC/blob/master/second_order_dac.v – however, I’ve adapted this to halve the input volume by discarding the lowest bit, since second- (and higher) order 1-bit sigma delta DACs are unstable at the extremities of their input range – they require some headroom. Since the Amiga application only requires 15-bit input this is not a problem.
- A 3rd-order DAC found in Mark Watson’s Atari 800 repository. I’m not sure where it originally came from or what its copyright status is, since it’s not listed in Mark’s otherwise comprehensive list of which license applies to which files. The 3rd order DAC already attenuates the signal to maintain stability so I didn’t need to modify this one, except as detailed below.
- Finally, the simplest form of my hybrid DAC.
Exploring audio DACs in simulation – Part 2 – 2021-04-02
Having rambled on a little longer than I intended while setting the scene for these experiments, I’m going to set up a simple testbench with verilator to evaluate the performance of several different DACs.
Exploring audio DACs in simulation – Part 1 – 2021-03-21
When I was developing EightThirtyTwo I made good use of GHDL, which allowed me to run the CPU’s VHDL code in simulation and output traces of internal signals for viewing in GTKWave.
Now I’ve started exploring Verilator for simulating Verilog code, and it’s safe to say I’m very impressed!
So a little back-story is in order: [Ok, it turns out there’s so much back-story I didn’t actually talk about Verilator – next time, I promise!]
Some years ago I spent some time trying to improve the audio output on Minimig, and encountered some strange counter-intuitive problems. Originally the DAC used by Minimig was a simple 1st-order Sigma Delta DAC. These have pros and cons:
…three useful things about Quartus – 2021-03-14
Porting a Core, DeMiSTified – Part 6 – 2021-03-12
When I created a ZPU-based control module for the MSX and PC-Engine cores way back when, I created a menu system which used a tree of static menu structures, in which each elements could be one of several types.
I supported function callbacks, checkmarks, cycles and even sliders. It worked fairly well and the footprint was reasonably small – but it doesn’t lend itself to building a menu dynamically.
In order to build an arbitrary menu from a MiST config string using this system I would need to support memory allocation, which means managing a memory pool, and if the menu ever needs to be re-generated, potentially dealing with fragmentation. Doing any of this without bursting through the self-imposed 12k limit is unlikely to happen!