Dr.OG: I think you know György Szombathelyi ( slingshot ) ( Gyurco ) from Atari-forum.
I'm mentioning this because when Kyp and Rampa make the source code public, it's possible that he could make a port attempt to MiST / SiDi.

The biggest problem with these FPGAs is that they have very little BRAM (about 68KB), which is insufficient for this core to work. No problem with the cells, there's plenty of room.

Slingshot has previously ported cores like the ZX Next, so it has a great command of those instantiated in SDRAM. The same he can make it work so that all users of these FPGAs benefit.

And if not to wait a bit, since Kyp has some ideas to make it possible.

Anyway, enjoy the Enterprise on FPGA. Cheers

Hello. I've recently tried loading some games from tape and found that it doesn't work. Since the implementation of the SD card I had not tried. I think is something related to interrupts and sound.

Is there any difference between how 1KHz/50Hz timers and tome0/tine1 timers are treated? I am treating all the same. I have one counter and one flip-flop. The counter counts down from 250/5000/period0/period1 to 0, as specified in bits 6:5 of reg A7, and when it reaches 0 the flip-flop changes it state and interrupt 0 is triggered and is active until a 1 is written to bit 1 of reg B4.

What happens if sync of tone is high? The flip-flop changes when 0 is reached or when the count starts after sync goes low?

How is related audio interrupts and tape loading?

Any help would be really appreciated. Thanks!

Thank you again

Then...

If sync is 1 the counter of belonging channel is not running? Also in the middle of the count? Or only at the end?
Flip-flip of tone generator output is set to 0 at the end of the count?

I have to read the last paragraph carefully

Hi!

I noticed this core was not ported to MiST. I would try to do it, but can you open the source? Or just share with me on GitHub (I won't publish it if you don't want, I promise). BTW, I'm sure it's using some of my code, too, like the improved T80.

Hi!

I noticed this core was not ported to MiST. I would try to do it, but can you open the source? Or just share with me on GitHub (I won't publish it if you don't want, I promise). BTW, I'm sure it's using some of my code, too, like the improved T80.

I have sent you an invitation to the repo.

I don't have a MiST but AFAIK the main problem to port the core is it needs 64K of BRAM, that is all BRAM available so there is no BRAM left for the framewok.

For zxuno I have made a wrapper to convert SRAM into a dual port RAM so it doesn't need so much BRAM but it works because zxuno's SRAM is a lot faster than MiST's SDRAM. Also, pixel clock and CPU clock are not related at all and this complicate even more RAM accesses.

And yes, I use code from MiST repo, like T80 (with your improvementes, thanks!) and several modules from the framework.

As someone without any knowledge on FPGA programming, I have a probably very naive question. Is using such a valuable FPGA resource like BRAM for purposes like replacement of video memory a recommended practice or sheer laziness? Somehow, I cannot imagine any e.g. Amiga core to be built like that. Yet, MIST and its derivatives do run such cores fine.

I also have poor knowledge about the inners of a FPGA... Thanks that I have Kyp to explain me....

The BRam is important because 64KB are used to implement the Enterprise dual port video memory. Nick and the Z80 access the video memory at the same time, but Nick has priority over the Z80 on the real machine, so there is what Kyp names "contention", this is, the Z80 has to wait until Nick makes its chores. "Contention" is usual on other computers, like Spectrum and CPC, but for other reasons.

Said this, on the actual Enterprise implementation there is no "contention". This means that a program running on the video Ram segments(FC-FF) will be faster than on the real machine, because the Z80 access to video Ram is not delayed. This will change on a future.

The problem is not that Nick and Z80 share a part of the memory because that would be solved by implementing contention.

The problem is that in real hardware the Z80 can access the rest of the memory which is not contended independently of video accesses because it is physically on other chips but in the FPGA there is a single memory chip for everything and both the Z80 and Nick cannot access different parts of memory at the same time.

This is usually solved making two faster accesses in the time slot of one, but this requires twice as fast memory.

The problem with SDRAM is that at 14 MHz it is already at the limit of its speed and to access at 28 MHz it would be necessary to add wait states. This is a lesser evil in the case of the Z80 but it is unfeasible for screen refreshing.

SDRAM allows you to queue memory accesses and overlap part of the time it takes to have the data available (but I think that only works when accessing different banks) this could help, but...

All this works when video and CPU run at the same clock rate, or multiples of the same clock, but in the case of the enterprise this is not the case and the accesses must be synchronized in some way, which implies adding delays or what is the same, everything have to work even faster to keep data arriving on time.

My apologies, it's already difficult for me to explain it in my native language, much more in another language