Welcome, Guest. Please login or register.


Author Topic: Enterprise Deployment Attempt Over FPGA. (Read 92372 times)

Offline ron

  • User
  • *
  • Posts: 85
  • Country: es
    • RetroWiki & Cacharreo [RW]
Re: Enterprise Deployment Attempt Over FPGA.
« Reply #240 on: 2022.May.02. 13:23:33 »
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

Offline Dr.OG

  • Global Moderator
  • EP lover
  • *
  • Posts: 742
  • Country: hu
  • dr.
Re: Enterprise Deployment Attempt Over FPGA.
« Reply #241 on: 2022.May.02. 15:35:11 »
Thank You! I pointed previously Gyurco's attention to this project, as soon as the source code will be available, he will investigate the option of porting. He migrated the SNES and Sega Genesis/Megadrive cores formerly, so I doubt that EP core could cause serious problems...
ÉN ekelek, TE keregsz, Ő gyeleg,
MI ákolunk, TI vornyáztok, ŐK lendeznek.

Offline Kyp

  • Beginner
  • *
  • Posts: 29
  • Country: es
Re: Enterprise Deployment Attempt Over FPGA.
« Reply #242 on: 2022.June.17. 22:34:11 »
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!
« Last Edit: 2022.June.17. 22:54:14 by Kyp »

Offline geco

  • EP addict
  • *
  • Posts: 7082
  • Country: hu
    • Támogató Támogató
Re: Enterprise Deployment Attempt Over FPGA.
« Reply #243 on: 2022.June.18. 18:45:59 »
Probably Bruce or Zozo can help, they know how EXOS loads from tape. :)

I checked the Dave addons by IstvánV.
A7h port
    b0-b2: sync on (high means)
        the counter of belonging channel is not running
        the counter is hold continuously on frequency values are set in A0h-A5h registers
        flip-flip of tone generator output is set to 0
    b5-b6: the interrupt is driven by the counter of belonging tone generator (not the modified (filtered, distorted)), after each run to 0 bit0 of B4h port change, and (if interrupt is enabled) bit1 is set.
1KHz interrupt is equal to 250-1 tone generator frequency, and 50Hz is equal to 5000-1, so it differs from the video interrupt, it 80000 Z80 T-State (or 120000 if bit1 of port BFh is set)

I saw that all Dave interrupt is set during loading, but i think only Dave programmable interrupt is used during reading tape signal, and sync bit set/reset, and when 4 KB chunk is loaded then it changes to 50Hz Dave interrupt, and when tape read starts again it is on 1000Hz dave interrupt, but after some instructions it changes to programmable interrupt with tone0 sync high and wait until signal starts, if it is started then it release sync bit, and reset Dave interrupt (ld a,03h  , out (0b4h),a  )
« Last Edit: 2022.June.18. 18:58:41 by geco »

Offline Kyp

  • Beginner
  • *
  • Posts: 29
  • Country: es
Re: Enterprise Deployment Attempt Over FPGA.
« Reply #244 on: 2022.June.19. 17:01:12 »
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 :)

Offline geco

  • EP addict
  • *
  • Posts: 7082
  • Country: hu
    • Támogató Támogató
Re: Enterprise Deployment Attempt Over FPGA.
« Reply #245 on: 2022.June.21. 17:37:11 »
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 :)
As i understand, when sync bit set, it stops immediately the counter of the channel, and the counter is hold ony frequency value which is set by it's belonging tone registers (a0h-a5h)

Offline gyurco

  • Newbie
  • Posts: 5
Re: Enterprise Deployment Attempt Over FPGA.
« Reply #246 on: 2022.November.07. 00:11:21 »
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.

Offline Dr.OG

  • Global Moderator
  • EP lover
  • *
  • Posts: 742
  • Country: hu
  • dr.
Re: Enterprise Deployment Attempt Over FPGA.
« Reply #247 on: 2022.November.07. 05:13:15 »
WOW! It would be awesome to try this core on MiST...
ÉN ekelek, TE keregsz, Ő gyeleg,
MI ákolunk, TI vornyáztok, ŐK lendeznek.

Offline Kyp

  • Beginner
  • *
  • Posts: 29
  • Country: es
Re: Enterprise Deployment Attempt Over FPGA.
« Reply #248 on: 2022.November.07. 15:24:37 »
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.

Offline ron

  • User
  • *
  • Posts: 85
  • Country: es
    • RetroWiki & Cacharreo [RW]
Re: Enterprise Deployment Attempt Over FPGA.
« Reply #249 on: 2022.November.09. 11:30:17 »
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 Gyurco. I would like to thank you very much for your proposal. It was precisely me who told Dr.OG if he could contact you, thinking of all the people who have a MiST, MiSTica or SiDi boards and who constantly ask me if there will be a version for these FPGAs.

The main problem that we detect is that the BRAM is insufficient, since 64K are necessary for VRAM and that it is accessed by the Z80 and by the NICK. The firmware and the core do not fit at the same time. So almost all the BRAM is used by the Enter and there is nothing left for the firmware it needs, at least 8K.

I couldn't tell you much more, maybe Kyp has more ideas. If Nick accesses 14MHz, I don't think SDRAM supports it and I don't think waiting states can be added to the video. It is possible that reading in burst mode is possible, but it escapes us. In the enter, video and cpu use independent clocks and without any relationship between them.

Anyway thanks a lot for your help !!!
« Last Edit: 2022.November.09. 11:34:17 by ron »

Offline ergoGnomik

  • EP addict
  • *
  • Posts: 1291
  • Country: hu
  • Stray cat from Commodore alley
Re: Enterprise Deployment Attempt Over FPGA.
« Reply #250 on: 2022.November.09. 12:07:38 »
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.

Offline ron

  • User
  • *
  • Posts: 85
  • Country: es
    • RetroWiki & Cacharreo [RW]
Re: Enterprise Deployment Attempt Over FPGA.
« Reply #251 on: 2022.November.09. 12:46:46 »
For example, György did an amazing job porting the ZXNext core to MiST. That was a milestone.
Sometimes I have come to think that they use black magic to achieve these milestones

Nobody believed that György had made it work entirely in the MiST, among many other things and other cores that he has left very fine.

Thanks György

Offline gflorez

  • EP addict
  • *
  • Posts: 3607
  • Country: es
    • Támogató Támogató
Re: Enterprise Deployment Attempt Over FPGA.
« Reply #252 on: 2022.November.09. 12:52:56 »
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.
« Last Edit: 2022.November.09. 12:57:01 by gflorez »

Offline ron

  • User
  • *
  • Posts: 85
  • Country: es
    • RetroWiki & Cacharreo [RW]
Re: Enterprise Deployment Attempt Over FPGA.
« Reply #253 on: 2022.November.09. 13:09:13 »
Hey Super GFlorez! ! !

If Kyp has given György access to the Git, let the magic flow.
I don't know if it has anything related with it, but being György Hungarian it would be too strange if György didn't know about Enteprise,  being Hungary one of the countries with the most active users.

Offline Kyp

  • Beginner
  • *
  • Posts: 29
  • Country: es
Re: Enterprise Deployment Attempt Over FPGA.
« Reply #254 on: 2022.November.09. 23:26:23 »
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