Enterprise Forever

:UK => Hardware => Topic started by: ron on 2020.May.05. 11:26:09

Title: Enterprise Deployment Attempt Over FPGA.
Post by: ron on 2020.May.05. 11:26:09
Greetings to all users and lovers of the Elan Enterprise.

Not long ago, we formed a small team of retro computer enthusiasts and were able to implement several things, including Oric's core with Microdisc. Anyway, in the group there are users with great knowledge of Z80 and Enterprise HW.

Currently we have a fairly solid group and we are open to anyone who can contribute documentation and knowledge.

The main objective is to achieve an Enterprise 128 implementation that works on FPGA boards like MiST, MiSTica and SiDi and so that later FPGAs like the MiSTer can be ported.

Two of the main pitfalls to overcome are the ASICs or Custom:  Nick and Dave, since there is no implementation and all we have are the emulators and the documentation that we all know.

How could it be otherwise, Glorez is on the team as he is one of our best Enterprise ambassadors. GFlorez will be our interface with EntepriseForEver and RetroWiki and the Telegram group.

Without haste but without pause, no matter how long it can consume, it is something done totally altruistically, unconditionally and without any kind of profit.

We have to focus our efforts to get the best possible implementation from Nick and Dave. It is key, because the rest of the core is more or less already defined.
The first things we need is to have the Nick's Video base to start painting on the screen and gradually add all the development. Dave's part seems more affordable.

We hope you find this project interesting and we invite you to participate. We will create a thread in Spanish on RetroWiki to be able to exchange knowledge and impressions.

This is all for now, we will inform you promptly and we hope you like it.

Best Regards.
ron.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: ron on 2020.May.05. 11:45:47
Here is the post at RetroWiki in Spanish:
http://www.retrowiki.es/viewtopic.php?f=108&t=200035693

Saludos !
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: geco on 2020.May.05. 13:49:08
Great news, if it is ready, i will interested about buying a hw :)
Zozo posted schematics of Nick few days ago somewhere in the forum, and probably source of IstvánV's great EP128emu (https://github.com/istvan-v/ep128emu) can help a lot.
As i know there is a HW project also in Hungary where EP is included also, unfortunately i do not remember who makes it, i just know i saw the working hw once, but Nick emulation was not perfect.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: gflorez on 2020.May.05. 14:27:05
Yes, but FPGA is not emulating, it is the real thing implemented inside a programmable chip. Nothing to do with R-Pi emulation.

All the discrete chips of the EP can easily be implemented, but are the ASIC chips, Nick and Dave what are a mystery inside. The designs we have are not the definitive versions.

Of course, IstvanV's great emulator will be invaluable in the task due to the perfection it has achieved. But at the end is the real machine what will be cloned.

All aid will be welcomed in this project, if you find the makers of the Hungarian project, please put them in contact.

Thanks!.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: ergoGnomik on 2020.May.05. 14:35:08
If the project geco is talking about is Z80MU, then that's not a hardware emulator but a software implemented for a custom hardware.

Obviously, ep128emu can't be used as a direct base for VHDL programming, but as it is a cycle-exact emulation, it can be used as an information source of what, when and why happening in those ASICs.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: geco on 2020.May.05. 14:52:21
Yes, sorrry, i thought it is a hw stuff.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: gflorez on 2020.May.05. 15:31:09
I have thought-out.... if this project goes on.... It would be a great enjoyment for the old guy that designed the Nick chip to know about it. Maybe even participate, but this is an open project and involving him has to be considered by all.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Dr.OG on 2020.May.05. 16:22:49
Hi!

There are some older topics related to this subject:

https://enterpriseforever.com/hardware/one-chip-msx-mkii-a-chance-for-an-enterprise-in-fpga/

https://enterpriseforever.com/hardware/enterprise-vhdl/

https://enterpriseforever.com/hardver/programozhato-logikai-aramkorok/

https://enterpriseforever.com/hardver/fpga-ep/
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: ergoGnomik on 2020.May.05. 16:28:51
the old guy that designed the Nick chip

I do understand that you had no such intention, but referring to Mr. Nicholas Toop as the old guy seems a bit disrespectful.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: gflorez on 2020.May.05. 20:23:54
Do you think it? Not for me, and not just when I am writing about how he would enjoy knowing this project. I can't at the same time be insulting him.

Take it as an affectionate nickname, my admiration to a man on that privileged status, a man that has lived intensely and that has a knowledge.

----

But I want to explain the motivations I have when I come here to this web page that I consider my home.

I come here to lean from others, even the most humble user of the page can amaze me with some topic, from the Enterprise or not. I have found here people that have shared their knowledge without asking me how much I know, who I am or from where I come. I think I have acted  the same with others, with courtesy, humour and respect.

Only a short number of members here have the English language as their native language, so it is possible that a British speaker can found a lot of incorrections on the messages we share. That is the reason why we can't take all expressions as literals, because then we could start the Third World War in few seconds

Better let's take the words on the context, reading carefully, forgiving us for the mistakes that we sure make when expressing ourselves. It is only my desire.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: ron on 2020.May.05. 20:49:00
Dr.Og ! very nice ! Thanks for the links. !

I hope no one bothers about a loving nickname. I have no doubt that GFlorez has cited Mr Toop ( if that's the case ) with the utmost respect and with all appreciation and love. I would be very happy to know that Mr. Toop could help us to preserve the Enterprise in FPGA, just as many of us will surely be.

Let's go for the core !

Regards
ron
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: ron on 2020.May.05. 21:38:13
To do a first approach to the core, I will try to explain what we plan to do.

There are two coders who do great things. They are Gyorgy (Gyurco aka slingshot) and Sorgelig. Both are among the most representative in MiST and MiSTer. Both have two separate Sam Coupé cores implemented.

Calm down, let's be calm. Yes, I said Sam Coupé. But I will explain what all this means. Everyone knows that the Enterprise is a better micro than the Sam Coupé. Enter is a design from 1983, Sam is almost 1989.

Isn't it strange to have the Sam Coupé instead of the Videoton as a base?. The Videoton is similar in software, but not in hardware, which is what it's all about here. We believe that Miles Gordon Technologies must have looked sideways at the Enterprise, because coincidentally, there are many circumstances that make it optimal to take advantage of what has already been done.

This is the Sorgelig's git: https://github.com/sorgelig/SAMCoupe_MIST
This is the gyurco ( slingshot) git: https://github.com/gyurco/SAMCoupe_MIST

Obviously the core of Enteprise once it is ready to implement Nick and Dave is not going to look anything like the original.

The rom is already loading it by ioctl_download to the sdram, paging to 16Kb blocks ... it is not so different ... with the appropriate changes we do not see any impediment to use them as a base on which to implement. It is a good start. From what we see the way of reading the keyboard is very similar to that of AY. About Dave, it's very similar. At The moment we have clear audio records, it will not be very difficult to prototype that chip and the paging based on outs is cpm type.

In a later phase it is a question of supplanting the ASIC of Sam by Nick and SAA by Dave.

It is an initial stage it is about prototyping until the nick is able to start generating and painting video. We have to see how far we can go, since in other cores the parts that were missing until the schemes were obtained or decapped, were based on what was written in emulators.

Feel free to comment and add what arouses your interest or points of view.

Regards
ron

Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: dangerman on 2020.May.06. 22:40:18
Wow - this is very exciting news. :mrgreen:

I guess the hardest bits will be programming the Nick chip's line parameter table. And of course getting cycle exact emulation (but that can always be worked out later).

The official Nick and Dave chip documentation provides a very good start: 
http://ep.homeserver.hu/Dokumentacio/Konyvek/EXOS_2.1_technikal_information/hardware/Nick.html
http://ep.homeserver.hu/Dokumentacio/Konyvek/EXOS_2.1_technikal_information/hardware/Dave.html

And IstanV knows a lot about the undocumented behaviour!
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: gflorez on 2020.May.07. 11:29:17
Thanks dangerman.

These links are extracted from the official Nick (http://enterprise.iko.hu/technical/ET1-3_Nick_Chip_Programmers_Guide.pdf) and Dave (http://enterprise.iko.hu/technical/DAVE_ISSUE5.pdf) documents that we are already managing. Do they have any fixing over the originals?

Yes, of course we want IstvanV advice and collaboration.



Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: ergoGnomik on 2020.May.07. 11:50:12
These documents may also be somewhat interesting:
ELITE (NICK) Rev.E (final) Sheet 1 (http://enterprise.iko.hu/schematics/3006-0000-22_Sheet-1.pdf)
ELITE (NICK) Rev.E (final) Sheet 2 (http://enterprise.iko.hu/schematics/3006-0000-22_Sheet-2.pdf)
ESPRIT (DAVE) Rev.D (final) Sheet 1 (http://enterprise.iko.hu/schematics/3007-000-22_Sheet-1.pdf)
ESPRIT (DAVE) Rev.D (final) Sheet 2 (http://enterprise.iko.hu/schematics/3007-000-22_Sheet-2.pdf)
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: gflorez on 2020.May.07. 12:22:24
Thanks ergoGnomik.

Yes, there are invaluable documents on Zozo's page. I hope that the geniuses on the project could translate all that little boxes on the design.

The sheets seem to be modified on some parts. If they are effectively the latests revisions E and D(the fixed NICK?), maybe they will lead to a good implementation of the chips.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: dangerman on 2020.May.07. 12:49:15
These links are extracted from the official Nick (http://enterprise.iko.hu/technical/ET1-3_Nick_Chip_Programmers_Guide.pdf) and Dave (http://enterprise.iko.hu/technical/DAVE_ISSUE5.pdf) documents that we are already managing. Do they have any fixing over the originals?

Great stuff. Those will probably be the best place to start. I'm not totally sure but I don't believe there are any fixes in the HTML version.

Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Tutus on 2020.May.07. 13:13:49
Greetings to all users and lovers of the Elan Enterprise.
The main objective is to achieve an Enterprise 128 implementation that works on FPGA boards like MiST, MiSTica and SiDi and so that later FPGAs like the MiSTer can be ported.

Hi ron!

We also had such a plan two months ago, but due to lack of money and specialist, we gave it up ...
So, yours is the "track", if we can help you with anything, let me know!
We have a Hungarian Enterprise Club community behind us. You can count on us! :)
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: ron on 2020.May.08. 09:04:28
Thank You very much !
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: ron on 2020.May.09. 22:25:55
Hi there, fellows !

We have some progress, much more than we could expect. Our friend rampa069 has not given us time nor to assimilate all that he has already managed to do. Amazing !

Because the FPGA's SDRAM has 24 addressing bits, rampa069 has successfully reduced the Enterprise MMU in a very smart way. First 8 bits (Content of the port pointed to by the two high lines as a bank) +2 bits (The active port (B0, B1, B2, B3)) + 14 low bits of the address bus..., as soon as a Pseudo_NICK can start painting, there are a lot of possibilities that it will start working right away.

So, Kyp is redoing the control signals but since kyp uses a 28MHz master clock,  with clock enables it is more messy. There are a lot of clocks out of combinatorics and that doesn't like the FPGA. The advantage of FPGA implementations is that as milestones are achieved, you can start testing.

Now ROM loads OK, just using a EP128.ROM file at SD's root in where you can concatenate all ROMS you want. It loads from SD at address 0.-

Also the disc controller is working.

[attach=1]
[attach=2]

Surely tonight ramp069 will enable the Git and all the part already converted to EP128 will be deployed. More or less these are the news we have, it seems that everything is going faster than expected.



Best Regards
ron
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Dr.OG on 2020.May.10. 05:28:40
Good news! :smt041 :smt038
That was quick!!!
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: ron on 2020.May.11. 07:30:14
... and pseudo-Nick started painting.
[attachimg=1]
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: geco on 2020.May.11. 08:20:04
Cool :smt041
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Zozosoft on 2020.May.11. 10:32:14
Some other documents which were not mentioned previously:
http://enterprise.iko.hu/technical/NICK-Old-VDC-ELITE-description.pdf
http://enterprise.iko.hu/technical/NICK-Internal-timing-of-VDC-Elite.pdf
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: gflorez on 2020.May.11. 10:40:01
Thanks, Zozo. Now they are working more with the timings that these 2 documents describe.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Zozosoft on 2020.May.11. 13:55:11
Another important thing: clocks calculations by IstvanV (https://enterpriseforever.com/programming/what-is-the-number-of-clock-cycles-per-rasterline/msg63481/#msg63481)
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Zozosoft on 2020.May.11. 13:59:32
Some scope measurements about Nick-Z80, VRAM access (in Hungarian forum :oops: )
https://enterpriseforever.com/kijelzo/nick/msg32713/#msg32713
https://enterpriseforever.com/kijelzo/nick/msg32717/#msg32717
https://enterpriseforever.com/kijelzo/nick/msg32723/#msg32723
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: gflorez on 2020.May.11. 15:13:44
Great! Thanks Zozo.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: ron on 2020.May.11. 20:06:44
After the improvements, the pseudo Nick says HELLO! and you already use the EXOS font

[attachimg=1][attachimg=2]
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: gflorez on 2020.May.11. 20:29:49
[attach=1]

@Kyp:

"No solo se ve, está 'procesando' la LPT, leyéndola de la RAM. En esa imagen están las dos bandas del borde superior e inferior, 28 bandas en modo CH128 (cambiando el puntero a donde empieza el texto) y las dos bandas en modo VSYNC para el sincronismo vertical :grin: "

----

"It not only sees, it is 'processing' the LPT, reading it from Ram. In  this image there are the two bands, upper and lower, 28 bands in CH128 mode (modifying the pointer where starts the text) and the two bands on VSYNC mode for the vertical synchronism :grin: "
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Kapitany on 2020.May.11. 22:11:54
Will there be a design for a nice case and keyboard, so that in the trails of the Spectrum Next there could be a Nexterprise? :D If the proof of concept is OK, there should be a Kickstarter project for this as well, don't you think so?
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: ergoGnomik on 2020.May.12. 10:25:59
That Kickstarter would be sentenced to death. People know what a Commodore 64 or a ZX Spectrum is, but they don't know what an Enterprise 64/128 computer is. People are seldom interested in yet another thing they have no clue about.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: ron on 2020.May.12. 11:27:58
The aim of this project  is to preserve the Enteprise in FPGA. It is time to do it.



We are developing the Enterprise core on the MiST / MiSTica / SiDi platform but with the intention that once it is functional, can be ported to other fpga boards such as the MiSTer or those where it fits. There is no point in kickstarting or crowfounding, in this case all that is useless.

This project is public, open-source, totally independent, non-profit and is done unconditionally for pure fun and learning.

So, preservation. Emulation already takes care of this purpose, but we consider that an implementation on gate arrays can offer a more exact and precise view of the Enteprise, without detracting from everything that already exists, since without it this would not be possible. Anyone can help and contribute to improvement

As soon as we have news we will gladly share them with you.

Thanks for all documentation, maybe we will transfer you some questions about timings and specific things, all in due time.

Thank You
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Zozosoft on 2020.May.12. 11:47:05
Is possible when the development done, create new Nick and Dave chips which can be used for repair dead Enterprise machines?
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: ron on 2020.May.12. 12:04:02
Is possible when the development done, create new Nick and Dave chips which can be used for repair dead Enterprise machines?

Knowing the number of logical gates that each custom chip occupies, you could look for a cpld or fpga that has enough capacity and the necessary pins and could be mounted on a socket or an adapter.

What I couldn't tell you right now is how to take advantage of what is already in place, but I pass the question on to colleagues.

And to the question of whether it can, if the implementation actually meets all the requirements that the Enterprise needs, is YES.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: gflorez on 2020.May.15. 21:23:24
Here I bring you a little video of what is actually happening with this development.

My friend Kyp has some restrictions on his actual FPGA, only 64KB of internal Ram, perfect for Video Ram, but he also needs to put the EXOS Roms there, because he has 4MB of external Ram but no way to put Roms on that space.

A member of the development group has donated Kyp a better FPGA, so on some days we will see more advances. Think that all this work is done on free time.

Kyp:


Details...
I am using the BRAM to share the memory with the CPU and still without timing contention but, just because I have the (EXOS)Rom on the BRAM, I only have 32K of ROM and 32K of VRAM, I have searched which two segments of VRAM the ROM uses to draw on the screen to be able to show some text(still only hardware text mode). And then it can't start... because it needs a pressed key and by now there is no keyboard at all.

Kyp says that the keyboard hardware seems trivial, but to continue he also needs to implement the interrupts.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: ron on 2020.May.16. 11:18:46
Thanks GFlorez !

From this moment on and depending on the time that rampa069 may take, things will start to go faster and then a point will be reached where the debugging and testing phase will enter.

Remember that core's structure and other elements were already implemented and running.

It is a slow and tedious process, since with FPGAs there is no way of knowing what is happening and it becomes difficult.

Anyway, now is when this turns really interesting. Stay Tuned !
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Kapitany on 2020.May.19. 10:06:38
Wonderful news! It's nice to see that EXOS can now open graphic channels and display them in windows on the screen, no matter that the graphics mode is a bit glitchy. :) Well done, keep up the good work!
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: gflorez on 2020.May.19. 10:25:04
The graphic modes aren't still implemented.... Is for it that the flashing big letters are shown as 0s and 1s, because the "pseudo Nick" thinks it is hardware text mode...

Now a keyboard and interrupts have to be implemented. Also the memory is not properly managed.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Zozosoft on 2020.May.19. 10:32:29
The graphic modes aren't still implemented....
Palette colors are also not :oops: This is why visible the ERROR at the memory test. It is using the second color pair, and normaly set to black letters, only changed to red when memory error found.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: gflorez on 2020.May.19. 11:06:07
Great clue! Thanks Zozo, I am going to inform about that.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Kapitany on 2020.May.19. 21:39:41
So that's why it's worth to show us status videos more and more frequently, so that Zozo can spot such clues that lead to things that might be debugged for endless hours. :D "Who can see into the soul of the EXOS?" :D
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: ron on 2020.May.23. 19:23:47
HI there, good news !!!

[attachimg=1]
[attachimg=2]

Thanks to Kyp !!!
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Zozosoft on 2020.May.23. 19:43:08
Looks good! :smt038
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Dr.OG on 2020.May.23. 20:09:45
Amazing progress!
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: gflorez on 2020.May.23. 21:13:59
Still not totally good interruptions. And no Basic.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Tutus on 2020.May.24. 08:52:57
Still not totally good interruptions. And no Basic.
Great!!! :smt041
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: geco on 2020.May.24. 12:45:24
Looks cool :)
And the progress is amazing.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: dangerman on 2020.May.24. 14:19:53
Wow. This is really fast progress. Fantastic!!! :smt041 :smt041
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Kapitany on 2020.May.26. 07:42:43
Wow! This is really nice! Right on Commander! :)
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: MrPrise on 2020.May.26. 10:58:12
Looks great, keep up the good work! Kyp is on his way here :-) (his account has been created today)
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: gflorez on 2020.May.26. 15:27:14
Yes, that way he can make you all a lot of questions directly.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Kyp on 2020.May.26. 19:10:17
Hello everybody!

I never had an Enterprise so I have little to tell about me and these computers. I knew about them just in publications and lately I have seen gflorez computers in action. I had and still have Spectrums and Amigas.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: geco on 2020.May.26. 21:59:24
welcome here, and congratulation for the fast and good result you achieved: -)
I had ENTERPRISE and C64 and i still have ;-)
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: gflorez on 2020.August.18. 13:27:39
Kyp is hardly still developing the core. This is his last post:

"The biggest problem the EP has is that many of the things it does with signals are managed in a 'incompatible' way with FPGAs. It has lots of latches and registers that work with clocks coming out from other logic gates and FPGAs don't like that at all."
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Tutus on 2020.August.18. 13:39:04
Kyp is hardly still developing the core. This is his last post:

"The biggest problem the EP has is that many of the things it does with signals are managed in a 'incompatible' way with FPGAs. It has lots of latches and registers that work with clocks coming out from other logic gates and FPGAs don't like that at all."
It is very sad :(
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: elmer on 2020.August.18. 15:31:49
It is very sad :(

Yes, very sad. :(
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: gflorez on 2020.August.18. 15:48:50
You have not understood him. It is hard but he continues.

He only is explaining the difficulties he is finding.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: ergoGnomik on 2020.August.18. 18:07:05
You have not understood him.
I'm sorry to say this, but it is actually you who made Tutus misunderstand. You see, working hard and hardly working are very different things. Working hard means that somebody makes great efforts to achieve the goal. Hardly working means doing not much or barely anything. Yes, hardly and hard can be used as equivalents, but that is not the usual or most common meaning of hardly.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: BruceTanner on 2020.August.18. 18:19:08
Yes, I misunderstood too. Also "This is his last post" I took to mean his last post ever, his final post. "...his latest post" would be better.

I say this just for information, not to criticize, I am in awe at people's ability to use English on this forum :bow: it puts my language skills to shame :oops: :oops: :oops:
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: elmer on 2020.August.18. 19:36:45
I say this just for information, not to criticize, I am in awe at people's ability to use English on this forum :bow: it puts my language skills to shame :oops: :oops: :oops:

I agree, I'm amazed at all of the posts in English from people for whom it is a 2nd or 3rd language. It makes me ashamed of my poor language skills.

I'm really glad to hear that the development is continuing. :-)
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: szipucsu on 2020.August.18. 21:04:01
hardly and hard can be used as equivalents
I think they cannot be used as equivalents. But you are right saying "hardly" means "very-very little" or "almost not". As I know "hardly" can have nothing to do with "hard". But correct me if it is not true.
(Hard - hardly are exceptions. A lot of other words like this have similar meanings, e.g. soft - softly or happy-happily.)
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: gflorez on 2020.August.18. 22:51:51
Apologies.... You all are right....

When I have received my friend's message I was doing shopping. I was eager for sharing it after so much time without news, so I have put the Spanish text on google and directly to this forum the translation.... My own text also was defective, so I also have some culpability....

Later, still shopping... I have read the answers and I have tried to change the sense of my earlier commentary.... and maybe some of you have been offended.


Yes I wanted to mean "working hard", not "hardly working". Some times on Spanish the order of the adjective is not significant on the sentence, and this is one of these cases: "duro trabajo" and "trabajo duro" is practically the same.

Also, the meaning of "último"("last") is not so definitive as in English, it is only the more recent in a succession of events, not the last of this era, never, the end, etc.

So yes, the development continues. Kyp means that the Enterprise chips will be the harder part to implement and trim, but there is a team behind to support him..

Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: ergoGnomik on 2020.August.19. 10:22:07
/OFF
hardly:
Google Translate (https://translate.google.hu/#view=home&op=translate&sl=auto&tl=hu&text=hardly)
topszótár (https://topszotar.hu/angolmagyar/hardly)
MorphoLogic (http://www.webforditas.hu/szotar.php?S=hardly&l1=en&l2=hu)
/ON
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Kyp on 2020.September.07. 13:35:35
I've been busy with other things but the project is still alive. Be patient.

I have a question.

ROM boot test doesn't show CPU speed, I think it's because I haven't implemented interrupts yet. I'm right? Well I just wired the VSYNC interrupts directly to the INT signal of the CPU, but I guess it's not correct. I'm not sure about how interrupts work in general. I have read about Dave's registers, but I am not sure how they work. For example, what is connected to INT1 or INT2?
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: geco on 2020.September.07. 18:37:11
yes, the cpu speed is calculated based on numbers of 1KHz Dave interruts within 1 50Hz Nick interrupt. Dave speed is increasing with the CPU speed.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: geco on 2020.September.07. 18:41:55
as i saw Nick interrupt is on int1, and nothing on int2
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: dangerman on 2020.September.12. 11:00:49
as i saw Nick interrupt is on int1, and nothing on int2

It's been a while but I seem to remember that int2 is connected to the network port, so that networked Enterprises can be alerted if another machine is sending data.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: dangerman on 2020.September.12. 11:19:17
Well I just wired the VSYNC interrupts directly to the INT signal of the CPU, but I guess it's not correct. I'm not sure about how interrupts work in general. I have read about Dave's registers, but I am not sure how they work. For example, what is connected to INT1 or INT2?

On the Enterprise, interrupts are connected to the DAVE chip and then DAVE controls the INT signal of the CPU. Interrupts are latched by DAVE so they can get passed to the CPU (eventually) even if they occur when Z80 interrupts are temporarily disabled.

DAVE has 4 sources of interrupts...

1. Variable frequency interrupt - either 50Hz, 1kHz or a variable frequency specified by the tone generator (ie the pitch of sound)
2. An interrupt at 1Hz
3. INT1 - this is connected to the Nick chip interrupt
4. INT2 - I think this is connected to the network port, so you probably don't need to worry about it.

You can find out what interrupts have occurred by reading DAVE register $B4.
You enable/disable the different interrupt sources and clear interrupt latches by writing to DAVE register $B4.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: ron on 2020.September.21. 23:25:29
All info about Enter interruptions is very appreciated.
The core is getting a great shape. :-)

See you soon. Regards-.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Kyp on 2020.October.11. 20:08:02
Its alive!
[attachimg=1] (https://youtu.be/AH6Wm9jSnnI)

It still needs a lot of work, but at least it boots to BASIC :D
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Dr.OG on 2020.October.11. 21:23:23
Nice progress!
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: geco on 2020.October.11. 21:34:43
cooooooool !
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: dangerman on 2020.October.11. 23:27:16
Excellent stuff!!!
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Trefe on 2020.October.12. 12:30:53
Amazing. 0.87MHz NMOS Z80? ;-) Like...
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: gflorez on 2020.October.12. 13:04:05
Yes... Zozo's routines to calculate the Z80 frequency need correct interrupts. The real clock in the video is 3.5Mhz.

[attachimg=1]
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Tutus on 2020.October.12. 13:53:43
This is fantastic! :smt038  Giant! :)
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Kyp on 2020.October.12. 17:15:12
Only video timings are accurate. CPU timings are far from exact. Z80 is clocked at 3.5 MHz and there is no contention. I'd rather have something that works first and tune-up it later.

I have already done a very accurate implementation of a Sinclair ZX Spectrum. It was very useful to have lots of test programs that check almost every detail of Spectrum's operation. Is there something similar to test the Enterprise?
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: ergoGnomik on 2020.October.12. 19:40:53
Is there something similar to test the Enterprise?
You may try to ask IstvanV (https://enterpriseforever.com/profile/?u=80) of ep128emu (https://github.com/istvan-v/ep128emu) fame if he had something around those lines during the development of his emulator.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: gflorez on 2020.October.12. 20:22:46
Another video, loading a Basic listing(still without audio):


[attachimg=2]
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: gflorez on 2020.October.12. 20:31:20
Sorry, this one is loading from TAPE:
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: ron on 2020.October.13. 19:49:21
It's Working.
At the moment is Enterprise 64, looking for wav files to test.

Regards
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: ron on 2020.October.13. 20:18:07
[attachimg=1]
[attachimg=2]
[attachimg=3]
[attachimg=4]

Hurra !!!
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Dr.OG on 2020.October.13. 20:30:32
Very impressive!
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: ron on 2020.October.13. 23:30:35
https://www.twitch.tv/videos/769376277
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: geco on 2020.October.14. 08:34:46
Impressive progress, did i see well an attribute mode picture was started to load also?
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: gflorez on 2020.October.14. 08:56:48
Yes, amazing. Kyp only has implemented  TEXT 40 and GRAPHICS LOWRES 256, necessary for booting EXOS, show the flashing letters and start Basic, but it seems that it can also show HIRES, TEXT 80 and other colour modes....

Attribute? I think still not. But Ron once loaded part of a screen with a lot of colours... It can be.

Probably you have noticed that only 8 colours can be seen on the 256 colours demo... This is not a defect of the core, but from the ZXUNO FPGA device, intended to manage the Spectrum core. Soon the team will port the Enterprise core to other more powerful FPGAs.

Other aspect was that a lot of programs failed to load, but I think that it was due to lack of Ram space. Kyp says he will add more on the next update.

As a proof of concept I think it is very impressive.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Kyp on 2020.October.14. 09:48:09
Video modes 000 (VSYNC), 001 (PIXEL, partially) and 100 (CH128, including ALTIND0 and ALTIND1) and the four color modes are implemented. The FIXBIAS registry is not implemented yet.

The problem with colors in 256 color mode is not a limitation of the ZX-Uno board. It must be a bug in the implementation.

My ZX-Uno board has 512K of SRAM (can be expanded up to 2MB). 64K are reserved for ROM. The rest can be used as RAM easily.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: geco on 2020.October.14. 13:26:07
Other aspect was that a lot of programs failed to load, but I think that it was due to lack of Ram space. Kyp says he will add more on the next update.
Yes, most programs are not running on EP64, old Speccy ports because they are using fix segments (F8-FB) except Zozo's conversions, most of newer ones need more memory.
Almost all programs which runs on EP64 (http://ep128.hu/Ep_Games/Games_Ep64_eng.htm) lister here except those which run, but slowly.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Kyp on 2020.October.14. 18:10:28
ZX-Uno board has 512K of SRAM but I need to reserve 64K for ROM leaving just 448K free. It is possible to have 448K of RAM? Or must be a power of two? BTW, I already have 128K of RAM :D

[attachimg=1]
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: geco on 2020.October.15. 09:27:43
Yes, you can define any of x16KB of RAM which is greater than 64KB
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: ron on 2020.October.15. 12:38:32
Enteprise core is being deployed on Altera boards, such MiSTer, MiST, MiST
Now to implement Dave and more things....

https://www.twitch.tv/videos/770392152

Bye !
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: gflorez on 2020.October.16. 22:47:53
More advances, more stuff:

[attachimg=2]
[attachimg=3]
[attachimg=4]
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Dr.OG on 2020.October.17. 06:57:26
WOW!!!
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: geco on 2020.October.17. 18:00:25
I think it is a dream only ;-)
It seems Nick is close to perfect, and there is extra memory.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: ron on 2020.October.17. 20:09:53
is there any tool to convert TAP to WAV in order to load via Audio ?

If not, we need TAP format information.

Thanks very much. ron.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Dr.OG on 2020.October.17. 20:49:24
Here you find two older tools as well, EPTE and TAPir, but better solution is EP128emu's TAPEEDIT:

http://www.ep128.hu/Ep_Emulator_eng.htm
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: geco on 2020.October.17. 20:49:47
tapeedit is part of EP128emu, you can try that, i hope it can generate WAV files also.
As i remember EPTE (http://www.ep128.hu/Emu/EPTE.RAR)  can create WAV file, or at least it creates WAV file during tap conversion into a folder.
As i see TAPir (http://www.ep128.hu/Emu/TAPir.rar) can create WAV files.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: ron on 2020.October.19. 18:58:55
All right. Thank You. Let's go with more advances: Attribute Mode

[attachimg=1]
[attachimg=2]
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: dangerman on 2020.October.19. 22:35:20
Amazing!!!!
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Kapitany on 2020.October.20. 16:14:02
Amazing! I always used TAPir to convert programs to WAV format. I have converted a bunch of games to WAV, maybe you can use them for something... https://www.dropbox.com/s/lh80oycdb5s1vx8/EP_GAMES.zip?dl=0
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Dr.OG on 2020.October.20. 17:46:02
Some more WAVs & mp3s converted by me earlier (didn't test all of them, some might be faulty):

https://mega.nz/file/RNMV2IIY#TlU7_QJVZ7kj84PoU3_BfNmqqvuH0CyefWTXpq3nLIU
https://mega.nz/file/wBEBSSYD#7-gVJedwwwBg5070bbrLt3lindm1xAuaG_gWjAWYkAM
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Kyp on 2020.October.24. 18:38:05
I have been loading some games... Thank you for the WAV files :)

(https://i.postimg.cc/R3BLRrk0/01-bruce-lee.jpg) (https://postimg.cc/R3BLRrk0) (https://i.postimg.cc/qhBcPsMV/02-bruce-lee.jpg) (https://postimg.cc/qhBcPsMV) Bruce Lee does not work :(

(https://i.postimg.cc/2bHdr1Vq/01-highway-encounter.jpg) (https://postimg.cc/2bHdr1Vq) (https://i.postimg.cc/23KdtLsM/02-highway-encounter.jpg) (https://postimg.cc/23KdtLsM)

(https://i.postimg.cc/QHKgZxst/01-jetpac.jpg) (https://postimg.cc/QHKgZxst) (https://i.postimg.cc/KKDrpqbD/02-jetpac.jpg) (https://postimg.cc/KKDrpqbD) (https://i.postimg.cc/7CwSz3zG/03-jetpac.jpg) (https://postimg.cc/7CwSz3zG)

(https://i.postimg.cc/HrGwYDst/01-nodes-of-yesod.jpg) (https://postimg.cc/HrGwYDst) (https://i.postimg.cc/Yj9f8zsQ/02-nodes-of-yesod.jpg) (https://postimg.cc/Yj9f8zsQ) (https://i.postimg.cc/Mc5Vmn0s/03-nodes-of-yesod.jpg) (https://postimg.cc/Mc5Vmn0s)

(https://i.postimg.cc/wR7Xv9mw/01-saboteur.jpg) (https://postimg.cc/wR7Xv9mw) (https://i.postimg.cc/Yv11jnvB/02-saboteur.jpg) (https://postimg.cc/Yv11jnvB)

There are some graphics glitches but overall it looks good
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: ron on 2020.October.25. 00:47:07
Yes yes YES ! Many of the games loads and playable !!!
In MiSTer fpga we're still fighting to normalize the audio loading, it's still buggy.

In any case, the core itself is already a reality, it is true that there is still a long way to go and that there are many difficulties to overcome, but this is very emotional because a lot of love is being given so that the Enteprise will remain well preserved.

[attach=1]
[attach=2]
[attach=3]
[attach=4]
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Dr.OG on 2020.October.25. 05:09:43
AVESOME!!!
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: geco on 2020.October.25. 07:11:19
Incredible effort !!!
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Trefe on 2020.October.26. 19:15:07
Amazing. :shock:  Does this work for SIDI?
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: gflorez on 2020.October.26. 20:58:57
Yes, Mist, Sidi, Mister, etc. The development is being done on a ZXUNO, with a smaller FPGA, and then converted to the other ones.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: ron on 2020.October.27. 07:17:26
There is a small hurdle to overcome in MiST. The MiST needs Quartus 13 to synthesize the cores, and instead both MiSTer and SiDi use the Quartus 17 versions. Our preferred manufacturer (manuferhi.com) will port to MiST. Actually I would love for the MiST port to be a success.

Remember that SiDi carries a Cyclone IV and the MiST a Cyclone III, yes, both have similar characteristics, memory, cells, but it is much easier to port to SiDi right now than to MiST.

Regarding the state of the core right now. You have to finish the Nick and start preparing the Dave. Later, depending on how the BUS can be implemented, it is necessary to think about either the disk controller or the SD-Card.
It shouldn't be a problem to equip the core with up to 4 MB of ram. Right now the audio upload works very well in ZXUNO but in MiSTer it is giving some problems due to the DAC converter.

We will keep you informed, thanks for all the support.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: ron on 2020.December.01. 22:39:38
Hi, Disk controller is comming
Soon more news...

[attachimg=1]
[attachimg=2]
[attachimg=3]
[attachimg=4]
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Dr.OG on 2020.December.02. 05:49:06
WOW! Incredible! I can't wait to test it!
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Trefe on 2020.December.02. 16:43:38
WOW! I want a SIDI. Later... :-)
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: ron on 2020.December.03. 08:41:02
Hello, how are you there?, some news for today.

Just a nuance, for the MiST, MiSTica and SiDi boards there is a small drawback. They do not have SRAM, since the RAM they have is SDRAM. Be patient that it is only a matter of time.

In BRAM these FPGAs have approximately 60 or so KB and between the VRAM and the OSD it will possibly be achieved, although it will take work.

Currently the development continues, on the one hand Nick is being rewritten and on the other hand finishing the Dave implementation. In addition to the EXDOS Controller that is very close to going live.

Finally a WD1772 has been implemented and there are still tests to be done, when I have more news I will let you know.

Cheers
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: ron on 2020.December.09. 19:09:11
Hi there ! Gentlemen ! Some Help and advice needed.

We're having some trouble implementing the WD1772 EXDOS Controller. We would like to know : In what condition does the "controller not ready" error occur and what does it look for to get the 193 exdos1.4 error ?

in theory the 1.4 goes fixed over the range 0x10-0x13 + 0x18

In a new approach we have used the rom EPDOS1.9 together with EXDOS 1.3, which lacks the 193 error, but the controller keeps crashing.

How does enterprise know that the controller is connected, do we know the ports and signals?, is not clear at all. We need a bit more information.

[attachimg=1]
[attachimg=2]
[attachimg=3]
[attachimg=4]
[attachimg=5]

Any help is greatly appreciated, thank you very much.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: ron on 2020.December.09. 19:30:19
Here one more screen with DEVS ( EPDOS ) output:
[attachimg=1]
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: BruceTanner on 2020.December.09. 21:23:22
In what condition does the "controller not ready" error occur and what does it look for to get the 193 exdos1.4 error ?
It outputs test values to ports 11h and 12h, and checks that the values can be read back at 15h and 16h (ports 10h-13h are mirrored at 14h-17h if the EXDOS card is there.) The test values are 55h and aah but then the test is repeated with the values swapped ie. aah and 55h.

Code: [Select]
; Return Z if an EXDOS card is there, NZ if no EXDOS card
WDCHECK: LD A,55H
OUT (11H),A
LD A,0AAH
OUT (12H),A
PUSH BC
PUSH BC
POP BC
POP BC
IN A,(15H)
CP 55H
RET NZ
IN A,(16H)
CP 0AAH
RET NZ
LD A,0AAH
OUT (11H),A
LD A,55H
OUT (12H),A
PUSH BC
PUSH BC
POP BC
POP BC
IN A,(15H)
CP 0AAH
RET NZ
IN A,(16H)
CP 55H
RET
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: ron on 2020.December.09. 21:41:05
Thanks a LOT Bruce !
Giving it a try !
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: BruceTanner on 2020.December.09. 22:24:01
I should add that the EXDOS code relies on the port 10h-13h mirroring at 14h-17h for actual operation, not just for testing whether the EXDOS card is there! :lol:

These days the EXDOS card is always at 10h-13h (and 14h-17h :mrgreen:) but originally there was a expansion card scheme that meant the EXDOS card could be at 20h-23h, or 30h-33h, or.... So all I/O is done through IN r,(C) and out (C),r instructiions. During sector reading and writing, to get C from pointing to the WD1770 data port at 13h to the status port at 10h very quickly, and then back to the data port again, the code uses INC C/DEC C, thus relying on the port mirroring!

B.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: ron on 2020.December.09. 22:31:20
Thanks again, very helpful!
We already have the mirroring of the ports, at this moment we only need the fdc to respond, we will see what it says in the tests.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: C5484 on 2020.December.17. 17:01:13
This is great!

I hope i can test the Enterprise 128 core on my MiSTer soon!
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: ron on 2020.December.18. 13:45:53
Hi Folks !

At this moment we already have the core working in BRAM (256K ram ) and SRAM (1 MB ram) made by Yo_Me. (Works for MiSTer)
EXOS 2.4 + EXDOS + ISDOS and whatever the ROMS setting. Kyp is finishing rewriting the Nick as he felt he could improve it, although right now we have the old version working which works perfectly.

So, rampa is racking his brain with the disk controller. The EXDOS disk controller is already working and the first directory is very close. We are having some problems because when reading discs it tells us that NOT A DOS DISK.
We are working to find out if it is a question of timers or is it because Dave lacks some implementation, in principle the controller communicates with the enterprise but refuses to read the disks.

To say that any help is very much appreciated, if you can tell us what the enterprise does when requesting the reading of the floppy, there is something that escapes us and we will try to find it.

[attachimg=1]

Regards, ron
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: BruceTanner on 2020.December.18. 16:01:00
Hi Ron,

When you first go :dir EXDOS will try and read the first sector ie. side 0 track 0 sector 1, the "boot sector", although EXDOS does not actually boot from it (note sectors are numbered from 1 not 0 :lol:). If there is a WD1770 error the read operation will be retried but eventually EXDOS will give up and report the error to the user.

If the boot sector is successfully read (ie. no WD errors) then EXDOS checks the data in the sector for various file system features which should be present on a MS-DOS type disk. "Not a DOS disk" means one of these features is not present.


But all the above assumes a formatted disk. From your screen shot it looks as though the first problem is that you cannot format it, and get a "Not ready" error? The first thing :format does is lots of head steps in and out to work out if it is a 40 or 80 track drive. Then it does a WD1770 "Read Address" command, which could cause a Not Ready error, could this be the problem? It does not matter what data is read - EXDOS is doing this just to test if there is a disk in the drive - Not Ready means no disk. After the Read Address is successful it should start doing WD Write Track commands to format the disk.

B.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: gflorez on 2020.December.18. 16:07:03
Thanks Bruce!
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: ron on 2020.December.18. 18:02:18
OK Bruce, let's taka a look !
Thank You
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: keyboardjunkie on 2021.February.13. 17:32:56
Hi folks,

I've just stumbled across this thread and am amazed at the progress here!

I wondered (since the last post in the thread was back on 18/12/2020) if there were any further updates from the team on this project?  It is fascinating reading and I would love to be able to try this out on my Mister..

Please keep up the great work!

KbJ
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: ron on 2022.January.14. 21:20:47
[attachimg=1]

Tonight starting at 10 pm, we are going to premiere Kyp's core live. This is a very preliminary version but it already has SD support.

We are still working on the disk controller.

You can see the stream, in Spanish on Twitch: https://www.twitch.tv/retrocrypta

A lot of thanks to rampa069, GFlorez and Kyp by the effort
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: geco on 2022.January.15. 09:11:34
Cool, keep on the great work :)
I wait the FPGA EP.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: MrPrise on 2022.January.15. 12:42:49
Whoa, nice!
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Tuby128 on 2022.January.15. 16:23:49
(Attachment Link)

Tonight starting at 10 pm, we are going to premiere Kyp's core live.

You can see the stream, in Spanish on Twitch: https://www.twitch.tv/retrocrypta


 At time 41:50, as the "VERP" closes and IS-BASIC starts. The size of the free memory is very low for my eyes.

 A fenti idôpontnál a videóban, ahol "VERP" véget ér és IS-BASIC elindul, a szabad memória mérete eléggé kevés az én szememnek.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Tuby128 on 2022.January.15. 16:33:53
I was watching the Raid over Moscow at about 49:00 and I can clearly see a problem with the horizontal scroll.
I am curious what horizontal SYNC frequency the FPGA produces. Is it the original 15 khz?

I would suggest to test EXOLON 1 game.
This is very special. The vertical resolution is about 100 lines, and every line has a record in the NICK Line Parameter Table.
It uses Spectrum-type attribute mode graphics.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Kyp on 2022.January.15. 22:03:49
I was watching the Raid over Moscow at about 49:00 and I can clearly see a problem with the horizontal scroll.
I am curious what horizontal SYNC frequency the FPGA produces. Is it the original 15 khz?

The pixel clock is currently 14.0000 MHz. I know it should be 14.2375, but it's hard to produce such exotic clocks from the FPGA PLL.

I would suggest to test EXOLON 1 game.
This is very special. The vertical resolution is about 100 lines, and every line has a record in the NICK Line Parameter Table.
It uses Spectrum-type attribute mode graphics.
It works :D (Yes, I know, there is a problem with the last pixels in every line ;) but it happens always in this video mode)
[attachimg=1])
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Tuby128 on 2022.January.16. 08:33:55
 Try to do the following use a PLL to convert your base 50MHz or whatever base frequency to 100MHz. And divide it with 7, which makes 100/7= 14,2857 MHz
 If the devider with 7 is not supported in the PLL, you can make an async logic divider as well.

 Anyway, are you using Altera (intel) or Xilinx FPGA? Verilog or VHDL?
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Kyp on 2022.January.16. 17:29:55
It's not that easy, in addition to the 14.xxx clock you have to get the 16,000 MHz one and there is no MUL/DIV combination that produces both.

I can use two PLLs, but most modules are designed to use a common high-frequency clock with clock-enables and this is not compatible with clocking from different PLLs.

Anyway, I prefer to complete the implementation first and then refine it. There is still a lot of work to do.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Tuby128 on 2022.January.16. 17:35:03
I don't understand you, because I did not see your FPGA schematic circuit, can you show me please.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Kyp on 2022.January.16. 21:45:48
It is a neptUNO board:
https://github.com/neptuno-fpga/Main_nepUNO/wiki
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Tuby128 on 2022.January.16. 22:08:54
- FPGA frecuencia del cristal: 50MHz-

 So your board has a 50 Mhz christal.
 Probably you are making 16 MHz with PLL via 8/25 multiplier. Am I right?

 According to the data of the FPGA you can use a second PLL.
 You have to place the Nick in separated clock domain anyway.

 The EP board is using a so called "clock streching" where the Nick is providing the clock signal for the Z80. Every time, when the nick accessing to its 64k memory, and the Z80 wants to access to the same memory, the nick delays the clock of the Z80.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: gflorez on 2022.January.17. 00:00:39
The NeptUNO has the same front-end for all the possible implemented machines, then it takes only for itself one of the PLLs. It works at 14.000, so the same clock has been also used for the EP implementation as the easier solution. This way the other PLL is saved for other purposes, at least in this preliminary stage.

The front-end manages a lot of common peripherals, like floppy, SD or HD images, joystick ports, mouse and keyboard, audio and video outputs, and even Internet connection. This approach, common also on other popular FPGAs, discharges the different computer implementations from a lot of possible common code.

On the other side, actually there is no contention of Nick over the Z80. It will be implemented later. Also, Nick needs to be completely re-written.

Perfection will take a while.... but now Kyp will go faster with the SD cartridge operative.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Tuby128 on 2022.January.17. 00:06:53
I understand. He leaves it as it is now. And concentrates on the next hardware.
 Is the vhdl or verilog code about the nick chip he wrote available somewhere? I am courious to see it.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: gflorez on 2022.January.17. 00:10:47
Maybe, ask him privately.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Tuby128 on 2022.January.17. 09:18:36

I thought there is a sourceforge or similar webpage where he puts the code, where anyone can access it.
I can fully understand if he decides too keep his intellectual property.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: gflorez on 2022.January.17. 11:16:44
Nah... the group will release it for free, but when the implementation will be correct. I personally think that there is no place here for own intellectual propriety... when we are playing with others intellectual propriety...

Kyp is one on the developers group, he has created the implementation from the documentation on Zozo's page(he doesn't own an EP...). Other aspects, like Dave's sound capabilities, are being developed by Rampa. Others do intensive beta-testing, like Ron. There are also others, doing things that I don't understand. I only observe what they do...

Until now they had the barrier of the lack of a massive storage. Having it will give them more time for the important and difficult aspects. Think that they are normal guys, with little time for the hobby, with families and work...
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Tuby128 on 2022.January.17. 11:42:18
Until now they had the barrier of the lack of a massive storage.

What do you mean under this sentence? Storage of what? Computer HDD, or free FPGA logic (LUT) or what?
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: gflorez on 2022.January.17. 11:53:40
I meant that 1 year ago only TAPE: was implemented, and it was hard to test some software on the FPGA EP.

Now, as you can see on the videos (https://www.twitch.tv/retrocrypta), the SD cartridge works like a charm.

And, for me, even being preliminary, Nick and Dave do an acceptable work, with great compatibility.

Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Tuby128 on 2022.January.17. 12:00:02
Now I understand you.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: gflorez on 2022.January.17. 20:25:47
Just because some of you are asking me where to find a Neptuno FPGA, you should understand that this group is not a FPGA seller or provider.

Kyp uses the Neptuno for his own convenience, because it has composite video output and is fast when synthesizing the "core" of the computer(similar to compiling a program). It could be that the definitive implementation would be bigger than the Neptuno possibilities, so better keep calm and wait for further development.  

If you still want to enter just now in this new world,  the target FPGAs for the Enterprise will be these with enough capacity to be valid for some years. Yes, they also get obsolete, because some cores continue growing, or because other computers more complex are tried. I am writing here "FPGAs" in plural, because another speciality of this group is to port the cores to all available FPGAs with enough space.

The EP is a computer that, except for the Z80 or the WD177x, has no custom chips in common with other computers, so its development will take some time, because it shares less implementation. This means that the size of its implementation could be bigger than other contemporaneous computers, because these tested common modules can't be used as bricks to build the Enterprise.

The FPGA contenders can be Neptuno, MiST, MiSTer, MistiSIDI and other new ones that can appear on next years. But the actual chip crisis has also raised the price of these programmable chips, so it is not recommendable to buy them now.

Here in Spain there are two main FPGAs builders, Antonio Villena and ManuFerHi, but I think you have a builder in Hungary, I don´t know his name.

On the other side, I am not an FPGAs specialist, there are other better forums where to find information about the subject.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Tutus on 2022.January.18. 12:13:43
(Attachment Link)
You can see the stream, in Spanish on Twitch: https://www.twitch.tv/retrocrypta
A lot of thanks to rampa069, GFlorez and Kyp by the effort

Fantastic! :bow:  Congratulations and we look forward to continuing :)
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: ron on 2022.January.22. 14:10:13
[attachimg=1]

Tonight, starting at 9:30 p.m.

Live stream: https://www.twitch.tv/retrocrypta
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: gflorez on 2022.January.23. 01:32:17
I want to explain one issue Ron had today with the video on his twitch channel.

He uses a RGB to HDMI to show the machine(any device that he needs to review) to make the Twitch stream in a good resolution and quality, for nowadays. But something odd happens with these converters that refuse to manage Pal interlace video, showing incorrect colours and resolution.

Ron has realised it on a moment of today video, and he has rescued his old composite video converter to try it on the Enterprise.

It is the reason why suddenly all seems to have changed to much better...
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: geco on 2022.January.23. 08:31:30
Aha, so that was the reason why the resolution of interlace seemed to be good later, but after the change i think we saw colour problem also. Ex. Exolon had a total orange palette, and Operation Alexandra had also some strange color, can this cause by the converter?
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: SlashNet on 2022.January.23. 09:45:29
Color palette is still weird, both via HDMI and composite.

Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: ron on 2022.January.23. 19:06:38
Thank you very much for the captures.
They perfectly show what I was referring to last night.

The Nick still lacks a couple and a half video modes.
Dave still needs improvements
Interruptions must be reviewed

In general, there is still a lot of work to be done. It is true (as Geco said last night) that the fattest and most difficult part is already done and somehow the core is already functional.

Kyp is doing a very fine job. Surely the more we know and the more doubts we can solve, the faster and better it will be finished with all your help. Thanks a lot.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: gflorez on 2022.January.23. 20:20:56
The colour problems you see are produced because bias is not totally implemented.

I hope the next version will cover all video modes. It was funny to see the "gracha" mode working.

Also, Dave sound needs some effort on interrupts, to work with sampled sound, and to lower the playing rate, that is double as fast now.

------

For me, all this work seems incredible, when one thinks that this is not a program emulating the EP, but a lot of discrete components(inside a programmable chip) making the same things that the custom chips.

So, in a future it could be possible to clone Nick and Dave following the VHDL code.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: ron on 2022.January.27. 20:36:44
Dear friends

From 21 hours local spanish time, we're going to present Elan Enterprise Core Preview on MiSTer FPGA.

[attachimg=1]

at RetroWiki's retrocrypta on Twitch: https://www.twitch.tv/retrocrypta

Üdvözlettel.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: geco on 2022.January.29. 22:53:07
Sorry, i wanted to logon yesterday, but forgot, today i watched it :)
4x6 internal DAC did not work in DTM player, because it uses speciality of Dave, it initiailize the 4 channels to be able to play samples on 4 channels without loosing volume level, without this special initialization the volume is lower, so until if DAVE is not fully complete in FPGA 4x5 bit DAC can be used id DTM player.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Dr.OG on 2022.January.30. 05:52:38
Just now noticed the word "Elképesztő" on the advertisement, that's amazing ;-) !
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: ron on 2022.January.30. 13:20:31
Just now noticed the word "Elképesztő" on the advertisement, that's amazing ;-) !

Dr.OG, is a nod  ;-)   from the Spanish fans of Enterprise to the Hungarian community, who are highly respected and valued, in fact you will see the logo of the Enteprise Forever forum.

Az Ön segítsége és tanácsa nagyon fontos számunkra.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Dr.OG on 2022.January.30. 14:18:07
I really appreciate that, thank You!
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: MrPrise on 2022.January.31. 11:08:37
Dr.OG, is a nod  ;-)   from the Spanish fans of Enterprise to the Hungarian community, who are highly respected and valued, in fact you will see the logo of the Enteprise Forever forum.
I did notice the forum's logo there :-) I'm always amazed by how many EP fans there are all over the world. I'm happy our forum could help these people to reach each other.
It is also great privilege to see awesome projects to born and progress like this one.

Keep up the good work!
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Tutus on 2022.February.01. 11:55:16
Dr.OG, is a nod  ;-)   from the Spanish fans of Enterprise to the Hungarian community, who are highly respected and valued, in fact you will see the logo of the Enteprise Forever forum.
Az Ön segítsége és tanácsa nagyon fontos számunkra.

I know you still have a lot of work to do with the FPGA project. :bow:
I can’t wait to post it as a sensation on the cover of Enterpress magazine when it’s done :)
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Kyp on 2022.February.09. 21:45:15
I've been improving Nick implementation

Some screnshots from Geco's Fred (https://enterpriseforever.com/spectrum-rol/fred/)

[attach=1]
[attach=2] 4 colours
[attach=3] ATTR mode
[attach=4] 16 colours

The random lines on the left are caused by my image capture card...
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Kyp on 2022.February.09. 21:55:43
Bricky looks better but bricks looks bad
[attach=1]

Any idea what is wrong?

The game does not start, no music either, I think something related to interrupts. There is a good explanation (other than The_Dave_Chip.PDF...) about how interrupts works?
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: geco on 2022.February.10. 09:09:13
Looks better and better :)
I think something is wrong in the palette, or with color assignment, i saw your code, and that seems to be good, but in Fred i see also some wrong colours, for exampla the bottom of col16 and attribute game screen should be yellow. (it seems to be bias 9 instead of bias 11)
in col16 picture bias 0 gray is missing from the brick, bottom of torch is bias 4 blue instead of bias 9.
So i think the colour assigment has problems from bias, i think bricks at Bricky screen uses also mainly bias colours.

I sent a mail to you about 1-2 weeks ago, about some other links, just before my mail about 4 colour character mode, did not you get it?
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Kyp on 2022.February.10. 09:58:22
in Fred i see also some wrong colours
That was a quick test, I'll compare it against Emu128 for differences.

I sent a mail to you about 1-2 weeks ago, about some other links, just before my mail about 4 colour character mode, did not you get it?
Yes, I got it and made some tests with weird results :mad:

I just can't see what I'm doing wrong, why sometimes the colors look good and other times they don't.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: geco on 2022.February.10. 10:53:19
I just can't see what I'm doing wrong, why sometimes the colors look good and other times they don't.
Yes, it is strange, because there are programs which have quite good colour assignment, and some which strange, ex Exolon CPC conversion, and from the pictures what you posted below, i see that there is a problem with bias colours, i do not see too much problem on Fred main screen, but the attribute picture use few bias colours.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Kyp on 2022.February.10. 11:33:27
In ATTR mode my implementation works this way:

fetches data at addr1 -> data1
fetches data at addr2 -> data2

data1 is attr value
data2 feeds shift register clocked depending on colour mode (should be 2 colours for ATTR mode)

for each pixel...
if bitmap bit is 1 palette index is attr[3:0] else attr[7:4] (0 is lsb, 7 is msb)
if bit 3 of palette index is 0 final colour is the value stored in that palette index
if bit 3 of palette index is 1 final colour is, bits[7:3] = bits[4:0] from reg $80, bits[2:0] = bits[2:0] from value stored in that palette index
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: geco on 2022.February.10. 12:31:36
I mean it is a general colour assignment problem somewhere, because colour 16 mode also contains "bad" colours, and why i think it effects only Bias, because i did not see any colour problem in 4 colour mode. Please try BIAS.BAS on FPGA EP and in EP128emu, and compare the output, you can change the bias value by space.

Probably i misunderstood the colour assignment in your last 2 rows, but it seems to be strange for me.
Bitmap attribute selection is perfect, and if bit3 of palette index is 0 also, then the colour is chosen from the defined colours 0-7 in the LPB (line parameter block = acutally read LPT line), but if bit3 set then colour index bits[2:0] should be chosen from $80 specified palette.
ex:
lpb colours: 0,1,2,3,4,5,6,7
bias: HW value: 1fh, exos value: 0f8h
bitmap data: 10000001b
attr data: 0f1h

result:
background colour is chosen from bias, because bit7 is set, and colour is 0ffh (white) = 0f8h + 07h
foreground colour is chosen from LPB because b3 is 0, and colour is 01h (red)

result on screen: rwwwwwwr
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Kyp on 2022.February.10. 13:24:09
background colour is chosen from bias, because bit7 is set, and colour is 0ffh (white) = 0f8h + 07h
¿BIAS value is added to colour value or replaces bits in colour value?
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: geco on 2022.February.10. 14:12:43
¿BIAS value is added to colour value or replaces bits in colour value?

it works on both way, because if bias 11h is set to 80h port then our bias palette will be 88h-8fh, so if colour 0bh set for a pixel then it will get 88h or 03h = 88h + 03h = 8bh colour.

HW bias X ---> 8 * X gives the bias start colour, so if you replace the colour bits, it gives the same result, because last bit7-bit3 is bias specified palette for colour 8-15, and b2-b0 is the colour selected from bias.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Kyp on 2022.February.10. 15:04:20
Perhaps I have misunderstood how bias works. This is how I think bias works:

Col0   00.000.000  Black
Col1   00.000.100  Dark Blue
Col2   00.000.001  Dark Red
Col3   00.000.101  Dark Magenta
Col4   00.000.010  Dark Green
Col5   00.000.110  Dark Cyan
Col6   00.000.101  Dark Yellow
Col7   00.000.111  Dark White
       ^^_^^^____  these bits were be replaced by bias


if BIAS = 11111

Col08  11.111.000  Bluish Gray
Col09  11.111.100  Bright Blue
Col10  11.111.001  Bright Red
Col11  11.111.101  Bright Magenta
Col12  11.111.010  Bright Green
Col13  11.111.110  Bright Cyan
Col14  11.111.101  Bright Yellow
Col15  11.111.111  Bright White


And it is independent of video mode or colour mode.
It is right?
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: geco on 2022.February.10. 15:24:42
I think we found the mistake:
if BIAS is 00h
Col8   00.000.000  Black
Col9   00.000.001  Dark Red
Cola   00.000.010  Dark Green
Colb   00.000.011  Dark Yellow
Colc   00.000.100  Dark Blue
Cold   00.000.101  Dark Purple
Cole   00.000.110  Dark Cyan
Colf   00.000.111  Dark White

if BIAS = 1fh

Col8  11.111.000  Bluish Gray
Col9   11.111.001  Bright Red
Cola   11.111.010  Bright Green
Colb   11.111.011  Bright Yellow
Colc   11.111.100  Bright Blue
Cold   11.111.101  Bright Purple
Cole   11.111.110  Bright Cyan
Colf   11.111.111  Bright White

So bias was properly set up, just after the colour assignment were mixed a bit with colour index.
Yes the bias is mode independent.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: geco on 2022.February.10. 15:49:26
about interrupts:

Interrupts are controlled by 0b4h register, that sets up which interrupts are enabled.
write:
bit0 - enable Dave defined interrupts (50Hz/1Khz/frequency of tone generator 0 or 1)
bit1 - resets Dave interrupt request flag (if interrupt occurs, interrupt flag is becomes active, it has to reset "manually")
bit2 - enable 1Hz interrupt
bit3 - resets 1Hz interrupt request flag (if interrupt occurs, interrupt flag is becomes active, it has to reset "manually")
bit4 - enable Nick interrupt (video interrupt)
bit5 - resets Nick interrupt request flag (if interrupt occurs, interrupt flag is becomes active, it has to reset "manually")
bit6 - enable INT2 - it is not used, i think it was for future implementation
bit7 - resets INT2 - it is not used, i think it was for future implementation

read:
bit0 - Dave defined interrupts flip/flop(50Hz/1Khz/frequency of tone generator 0 or 1)
bit1 - gives back Dave interrupt status flag (if interrupt occured 1, if not 0 it remains active until it is not reseted by writing bit1 to port 0b4h, and iterrepupt generating until reset)
bit2 - interrupt flip/flop
bit3 - gives back 1Hz interrupt status flag (if interrupt occured 1, if not 0 it remains active until it is not reseted by writing bit3 to port 0b4h, and iterrepupt generating until reset)
bit4 - it contains the value of VINT flag of avtual LPB
bit5 - gives back Nick interrupt status flag (if interrupt occured 1, if not 0, it remains active until it is not reseted by writing bit5 to port 0b4h, and iterrepupt generating until reset)
bit6 - INT2 - it is not used, i think it was for future implementation
bit7 - gives back INT2 - it is not used, i think it was for future implementation

bit0 and bit2 flip/flop are changes when "interrupt time is reached" ex for 1 Hz interrupt it changes in each sec from 0 to 1 and from 1 to 0.
bit1 changes to 1 (interrupt occurs) , if bit0 is changed, and remains in 1 until it is not cleared by setting bit1 of 0b4h port
bit3 changes to 1 (interrupt occurs) , if bit2 is changed, and remains in 1 until it is not cleared by setting bit1 of 0b4h port
bit4 contains the VINT (video interrupt) flag of actually read LPB
bit5 changes to one if LPT pointer starts to read next LPB after LPB which contained VINT flag
This means that if we want to place more working interrupts into LPT, after each LPB contains VINT need to insert an LPB without VINT to activate that place for interrupt.

Standard EXOS LPT with 1 video interrupts, Int occurs when Nick starts to read content of line BAD0

>B900  F7 08 0B 73 B8 FE E9 01 00 36 00 49 FF 24 2D 36
>B910  F7 08 0B 73 C5 E0 E9 01 00 92 00 49 FF 24 2D 36
>B920  F7 08 0B 73 5D E4 E9 01 00 92 00 49 FF 24 2D 36
>B930  F7 08 0B 73 35 E4 E9 01 00 92 00 49 FF 24 2D 36
>B940  F7 08 0B 73 0D E4 E9 01 00 92 00 49 FF 24 2D 36
>B950  F7 08 0B 73 E5 E3 E9 01 00 92 00 49 FF 24 2D 36
>B960  F7 08 0B 73 ED E0 E9 01 00 92 00 49 FF 24 2D 36
>B970  F7 08 0B 73 15 E1 E9 01 00 92 00 49 FF 24 2D 36
>B980  F7 08 0B 73 3D E1 E9 01 00 92 00 49 FF 24 2D 36
>B990  F7 08 0B 73 65 E1 E9 01 00 92 00 49 FF 24 2D 36
>B9A0  F7 08 0B 73 8D E1 E9 01 00 92 00 49 FF 24 2D 36
>B9B0  F7 08 0B 73 B5 E1 E9 01 00 92 00 49 FF 24 2D 36
>B9C0  F7 08 0B 73 DD E1 E9 01 00 92 00 49 FF 24 2D 36
>B9D0  F7 08 0B 73 05 E2 E9 01 00 92 00 49 FF 24 2D 36
>B9E0  F7 08 0B 73 2D E2 E9 01 00 92 00 49 FF 24 2D 36
>B9F0  F7 08 0B 73 55 E2 E9 01 00 92 00 49 FF 24 2D 36
>BA00  F7 08 0B 73 7D E2 E9 01 00 92 00 49 FF 24 2D 36
>BA10  F7 08 0B 73 A5 E2 E9 01 00 92 00 49 FF 24 2D 36
>BA20  F7 08 0B 73 CD E2 E9 01 00 92 00 49 FF 24 2D 36
>BA30  F7 08 0B 73 F5 E2 E9 01 00 92 00 49 FF 24 2D 36
>BA40  F7 08 0B 73 1D E3 E9 01 00 92 00 49 FF 24 2D 36
>BA50  F7 08 0B 73 45 E3 E9 01 00 92 00 49 FF 24 2D 36
>BA60  F7 08 0B 73 6D E3 E9 01 00 92 00 49 FF 24 2D 36
>BA70  F7 08 0B 73 95 E3 E9 01 00 92 00 49 FF 24 2D 36
>BA80  F7 08 0B 73 BD E3 E9 01 00 92 00 49 FF 24 2D 36
>BA90  F7 08 3F 74 B8 FE E9 01 00 92 00 49 FF 24 2D 36
>BAA0  F7 08 3F 74 B8 FE E9 01 00 92 00 49 FF 24 2D 36
>BAB0  F7 08 3F 74 B8 FE E9 01 00 92 00 49 FF 24 2D 36
>BAC0  F2 92 3F 00 00 00 00 00 00 00 00 00 00 00 00 00  --- vint
>BAD0  FD 10 3F 00 00 00 00 00 00 00 00 00 00 00 00 00
>BAE0  FE 10 06 3F 00 00 00 00 00 00 00 00 00 00 00 00
>BAF0  FC 10 3F 1C 00 00 00 00 00 00 00 00 00 00 00 00
>BB00  F0 12 06 3F 00 00 00 00 00 00 00 00 00 00 00 00
>BB10  EB 13 3F 00 00 00 00 00 00 00 00 00 00 00 00 00


Modified EXOS LPT with 3 interrupts, Int occur when Nick starts to read BA90, and BAB0, and BAD0

>B910  F7 08 0B 73 C5 E0 E9 01 00 92 00 49 FF 24 2D 36
>B900  F7 08 0B 73 B8 FE E9 01 00 36 00 49 FF 24 2D 36
>B920  F7 08 0B 73 5D E4 E9 01 00 92 00 49 FF 24 2D 36
>B930  F7 08 0B 73 35 E4 E9 01 00 92 00 49 FF 24 2D 36
>B940  F7 08 0B 73 0D E4 E9 01 00 92 00 49 FF 24 2D 36
>B950  F7 08 0B 73 E5 E3 E9 01 00 92 00 49 FF 24 2D 36
>B960  F7 08 0B 73 ED E0 E9 01 00 92 00 49 FF 24 2D 36
>B970  F7 08 0B 73 15 E1 E9 01 00 92 00 49 FF 24 2D 36
>B980  F7 08 0B 73 3D E1 E9 01 00 92 00 49 FF 24 2D 36
>B990  F7 08 0B 73 65 E1 E9 01 00 92 00 49 FF 24 2D 36
>B9A0  F7 08 0B 73 8D E1 E9 01 00 92 00 49 FF 24 2D 36
>B9B0  F7 08 0B 73 B5 E1 E9 01 00 92 00 49 FF 24 2D 36
>B9C0  F7 08 0B 73 DD E1 E9 01 00 92 00 49 FF 24 2D 36
>B9D0  F7 08 0B 73 05 E2 E9 01 00 92 00 49 FF 24 2D 36
>B9E0  F7 08 0B 73 2D E2 E9 01 00 92 00 49 FF 24 2D 36
>B9F0  F7 08 0B 73 55 E2 E9 01 00 92 00 49 FF 24 2D 36
>BA00  F7 08 0B 73 7D E2 E9 01 00 92 00 49 FF 24 2D 36
>BA10  F7 08 0B 73 A5 E2 E9 01 00 92 00 49 FF 24 2D 36
>BA20  F7 08 0B 73 CD E2 E9 01 00 92 00 49 FF 24 2D 36
>BA30  F7 08 0B 73 F5 E2 E9 01 00 92 00 49 FF 24 2D 36
>BA40  F7 08 0B 73 1D E3 E9 01 00 92 00 49 FF 24 2D 36
>BA50  F7 08 0B 73 45 E3 E9 01 00 92 00 49 FF 24 2D 36
>BA60  F7 08 0B 73 6D E3 E9 01 00 92 00 49 FF 24 2D 36
>BA70  F7 08 0B 73 95 E3 E9 01 00 92 00 49 FF 24 2D 36
>BA80  F7 88 0B 73 BD E3 E9 01 00 92 00 49 FF 24 2D 36  --- vint
>BA90  F7 08 3F 74 B8 FE E9 01 00 92 00 49 FF 24 2D 36
>BAA0  F7 88 3F 74 B8 FE E9 01 00 92 00 49 FF 24 2D 36  --- vint
>BAB0  F7 08 3F 74 B8 FE E9 01 00 92 00 49 FF 24 2D 36
>BAC0  F2 92 3F 00 00 00 00 00 00 00 00 00 00 00 00 00  --- vint
>BAD0  FD 10 3F 00 00 00 00 00 00 00 00 00 00 00 00 00
>BAE0  FE 10 06 3F 00 00 00 00 00 00 00 00 00 00 00 00
>BAF0  FC 10 3F 1C 00 00 00 00 00 00 00 00 00 00 00 00
>BB00  F0 12 06 3F 00 00 00 00 00 00 00 00 00 00 00 00
>BB10  EB 13 3F 00 00 00 00 00 00 00 00 00 00 00 00 00

Modified EXOS LPT, it contains VINT in 3 lines, but only 1 interrupt will occur when Nick starts to read content of BAD0

>B900  F7 08 0B 73 B8 FE E9 01 00 36 00 49 FF 24 2D 36
>B910  F7 08 0B 73 C5 E0 E9 01 00 92 00 49 FF 24 2D 36
>B920  F7 08 0B 73 5D E4 E9 01 00 92 00 49 FF 24 2D 36
>B930  F7 08 0B 73 35 E4 E9 01 00 92 00 49 FF 24 2D 36
>B940  F7 08 0B 73 0D E4 E9 01 00 92 00 49 FF 24 2D 36
>B950  F7 08 0B 73 E5 E3 E9 01 00 92 00 49 FF 24 2D 36
>B960  F7 08 0B 73 ED E0 E9 01 00 92 00 49 FF 24 2D 36
>B970  F7 08 0B 73 15 E1 E9 01 00 92 00 49 FF 24 2D 36
>B980  F7 08 0B 73 3D E1 E9 01 00 92 00 49 FF 24 2D 36
>B990  F7 08 0B 73 65 E1 E9 01 00 92 00 49 FF 24 2D 36
>B9A0  F7 08 0B 73 8D E1 E9 01 00 92 00 49 FF 24 2D 36
>B9B0  F7 08 0B 73 B5 E1 E9 01 00 92 00 49 FF 24 2D 36
>B9C0  F7 08 0B 73 DD E1 E9 01 00 92 00 49 FF 24 2D 36
>B9D0  F7 08 0B 73 05 E2 E9 01 00 92 00 49 FF 24 2D 36
>B9E0  F7 08 0B 73 2D E2 E9 01 00 92 00 49 FF 24 2D 36
>B9F0  F7 08 0B 73 55 E2 E9 01 00 92 00 49 FF 24 2D 36
>BA00  F7 08 0B 73 7D E2 E9 01 00 92 00 49 FF 24 2D 36
>BA10  F7 08 0B 73 A5 E2 E9 01 00 92 00 49 FF 24 2D 36
>BA20  F7 08 0B 73 CD E2 E9 01 00 92 00 49 FF 24 2D 36
>BA30  F7 08 0B 73 F5 E2 E9 01 00 92 00 49 FF 24 2D 36
>BA40  F7 08 0B 73 1D E3 E9 01 00 92 00 49 FF 24 2D 36
>BA50  F7 08 0B 73 45 E3 E9 01 00 92 00 49 FF 24 2D 36
>BA60  F7 08 0B 73 6D E3 E9 01 00 92 00 49 FF 24 2D 36
>BA70  F7 08 0B 73 95 E3 E9 01 00 92 00 49 FF 24 2D 36
>BA80  F7 08 0B 73 BD E3 E9 01 00 92 00 49 FF 24 2D 36
>BA90  F7 08 3F 74 B8 FE E9 01 00 92 00 49 FF 24 2D 36
>BAA0  F7 88 3F 74 B8 FE E9 01 00 92 00 49 FF 24 2D 36  --- vint
>BAB0  F7 88 3F 74 B8 FE E9 01 00 92 00 49 FF 24 2D 36  --- vint
>BAC0  F2 92 3F 00 00 00 00 00 00 00 00 00 00 00 00 00  --- vint
>BAD0  FD 10 3F 00 00 00 00 00 00 00 00 00 00 00 00 00
>BAE0  FE 10 06 3F 00 00 00 00 00 00 00 00 00 00 00 00
>BAF0  FC 10 3F 1C 00 00 00 00 00 00 00 00 00 00 00 00
>BB00  F0 12 06 3F 00 00 00 00 00 00 00 00 00 00 00 00
>BB10  EB 13 3F 00 00 00 00 00 00 00 00 00 00 00 00 00
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: geco on 2022.February.10. 17:09:18
what i forgot to write:
bit0,2,4 are updated even if the corresponding interrupts are disabled.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Kyp on 2022.February.10. 18:39:08
Regarding bias...

I don't understand.

I said Col2 = 00.000.001 = Dark Red so, with bias h00, ColA should be the same = 00.000.001 = Dark Red, is not it?
Why do you say that ColA = 00.000.010 = Dark Green ?

And the same with bias = h1F, ColA = 11.111.010 = Bright Green ?
I understand that 11.1111.xxx is bias but why xx.xxx.001 turns into xx.xxx.010 ?

Is this correct?
Col8 = Col0 & 0x07 | (bias << 3);
Col9 = Col1 & 0x07 | (bias << 3);
...
ColF = Col7 & 0x07 | (bias << 3);
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: geco on 2022.February.10. 21:54:15
Sorry, i used col8-colf, because colours 8-15 are using bias values, and col0-7 use palette value from LPT, if we check 8 colours from bias view only then


Col0   00.000.000  Black
Col1   00.000.001  Dark Red
Col2   00.000.010  Dark Green
Col3   00.000.011  Dark Yellow
Col4   00.000.100  Dark Blue
Col5   00.000.101  Dark Purple
Col6   00.000.110  Dark Cyan
Col7   00.000.111  Dark White


if bias is 00h then the following is the sequence of the bias colours
00h,01h,02h,03h,04h,05h,06h,07h
and because the colour bit setting from bit7-bit0 is grbgrbgr (bias is the bit7-bit3 grbgr and colours are bit2-bit0 bgr) the colors are the following
black,red,green,yellow,blue,purple,cyan,white

Now i checked, your colour assignment uses the speccy method, bit2-0 grb, this mixed the bias colours.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Kyp on 2022.February.10. 22:25:26
Some improvements with interrupts thanks to @Geco explanations :D

[attach=1] Now CPU speed is correct

[attach=2] Symbos finally works and mouse can be moved with keyboard (or at least starts, I have not tested too much)

I have started some games an timing appears to be good but Bricky does not starts yet.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: geco on 2022.February.10. 22:45:36
cooool. Bricky uses Dave programmable interrupt for playing the samples, probably it is not implemented.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Zozosoft on 2022.February.11. 18:52:56
Now CPU speed is correct
Not fully, it is 4.06 instead of 4.00 Mhz :oops:
Also possible because the Nick chip speed are not fully correct.

My CPU speed do INC HL instructions between two video interrupt.
This is the routine:
Code: ZiLOG Z80 Assembler
  1. 0038: JP (IX)
  2. ...
  3.  
  4.                 LD HL,0
  5.                 LD IX,IRQ1
  6.                 LD BC,30B4H
  7.                 OUT (C),B
  8.                 EI
  9.                 HALT
  10. IRQ1            LD IX,IRQ2
  11.                 OUT (C),B
  12.                 EI
  13. IRQW            INC HL
  14.                 JP IRQW
  15. IRQ2            DI
  16.  
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Kyp on 2022.February.11. 21:41:40
Not fully, it is 4.06 instead of 4.00 Mhz :oops:
Also possible because the Nick chip speed are not fully correct.
Sure, Nick's pixel clock runs at 14,000 MHz, I'll fix that sooner or later :roll:
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: ron on 2022.February.11. 21:43:37
Tonight 22:30 CET

https://www.twitch.tv/retrocrypta

[attachimg=1][attach=2]
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Kyp on 2022.February.21. 21:45:09
CPU clock: 4.0000 MHz
Pixel clock: 14.2375 MHz

[attach=1]
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: geco on 2022.February.22. 10:16:56
:smt041 :smt041 :smt041 :smt041
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: ron on 2022.February.23. 20:15:14
At 20:20 Streaming Live
First Alpha Test , MiSTer and NeptUNO

https://www.twitch.tv/retrocrypta

Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: ron on 2022.February.25. 20:29:59
Tonight 22:00 hours CET.

https://www.twitch.tv/retrocrypta

FPGA core, MiSTer and NeptUNO VERSUS Enterprise 128 ( 512K ) (SD Reader)

I'm loading food for Geco xD ;-)

Rampa, Kyp, Gflorez and me will be there waiting for you.

Cheers
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Kyp on 2022.February.26. 16:27:47
BIAS implementation fixed at last!
[attach=1]
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Dr.OG on 2022.February.26. 18:11:17
Amazing! ;-)
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: gflorez on 2022.February.28. 00:26:06
Some very good news.

Here (https://www.twitch.tv/videos/1408930992) and here (https://www.twitch.tv/videos/1410052951) you can see Twitch Retrocrypta sessions from days 26 and 27 of February where the Bias colour error has been corrected by Kyp. Other cores are reviewed, so you should search the parts that apply to the Enterprise core.

Also.... on RetroWiki Spain (http://www.retrowiki.es/viewtopic.php?f=107&t=200037978), they have released the first Beta versions that can be tested by the happy owners of Neptuno (http://www.retrowiki.es/download/file.php?id=200027235&sid=7645a532f83a0758bbb7599573bb2b4a) or Mister (http://www.retrowiki.es/download/file.php?id=200027236&sid=7645a532f83a0758bbb7599573bb2b4a) FPGAs.

Remember: If you still don't own one of such FPGAs, do not rush to buy one, because it is not yet known which one of all will be the best for this core.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: geco on 2022.February.28. 10:08:49
Cool, as is see not only bias colour order was fixed, interlace mode also. Congratulation :)
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: ron on 2022.February.28. 21:07:18
Hello. Those of you who have a MiSTer or a NeptUNO board can now try the core.



And for those who have a MiST or a SIDi, as soon as the core is finished testing, debugging and sources are released, you'll need to talk to SlingShot (Gyurco) ( György Szombathelyi ) about making a MiST fpga port. Dr.OG knows from Atari-Forum.

Currently the core does not work on MiST / SiDi because the lack of BRAM. These fpga boards only have 70KB of BRAM and it is insufficient for the framework and VRAM, which would have to go in SDRAM.

He has made much more complex ports. Would be a way to make this core work on MiST.

FeedBack testing the core is really appreciated.

Cheers !
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Dr.OG on 2022.March.01. 05:50:05
Supercool!
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: ron on 2022.March.02. 10:53:35
New versions with audio improved.

MiSTer: http://www.retrowiki.es/download/file.php?id=200027279
NeptUNO: http://www.retrowiki.es/download/file.php?id=200027280

Cheers
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: gflorez on 2022.March.02. 16:42:07
Yesterday's (https://www.twitch.tv/videos/1412297821)(01-03-22) Twitch emission of Retrocrypta by Ron.

Today he promises another session....
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: geco on 2022.March.02. 16:44:57
Yesterday's (https://www.twitch.tv/videos/1412297821)(01-03-22) Twitch emission of Retrocrypta by Ron.

Today he promises another session....
Coool, when will it start? if after 20:00 CET, i will join also with some beers :D
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: gflorez on 2022.March.02. 19:14:02
The new member of EnterpriseForever, Rampa (https://enterpriseforever.com/profile/?u=542)(Ramon Martinez) is the guy that is working on the Dave chip(Sound), while Kyp (https://enterpriseforever.com/profile/?u=472) works on the rest of the computer.



Ron says: next "Twitch session at 19 hours some minutes", but they are still preparing a version with some enhancements in audio.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: geco on 2022.March.02. 20:23:14
Welcome Ramon , and good luck for the Dave emulation, FPGA EP becomes better and better :-)
I joined lately for 10 minutes, when Fred was loaded, and left after Adios a la Casta were loaded, i hope next time i will arrive at time :-)
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: rampa on 2022.March.02. 23:23:09

 Yes. Dave is starting to sound as "dave" :-) tonight i have some success with fred. seems fred is using every option in the sound chip... :-)
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: geco on 2022.March.03. 08:33:45
Yes. Dave is starting to sound as "dave" :-) tonight i have some success with fred. seems fred is using every option in the sound chip... :-)
As I remember it uses only the polynomial counters, filters and ring modulation is not used, but Szipucsu can correct me, he created the music from Midi.
If you wish, i can search some music which uses ring mod and filters also.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: rampa on 2022.March.03. 10:09:13

 Yes please.... One question (still tring to compile ep128emu on mac m1)  Does fred sounds ok on ep128emu?
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: geco on 2022.March.03. 12:03:20
Yes please.... One question (still tring to compile ep128emu on mac m1)  Does fred sounds ok on ep128emu?
I will check converted midi's :)
On windows ep128emu version it sounds ok :)
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: gflorez on 2022.March.03. 12:39:22
I remember Tutus trying to compile it on Mac, because it is the same machine he uses to edition.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Zozosoft on 2022.March.03. 13:31:02
Does fred sounds ok on ep128emu?
ep128emu are 99.99% accurate.
The missing 00.01% are:
-WD1772 timing not emulated (Zero command execution time, DRQ immediatly ready, and can't be missed)
-DAVE clock not hardly connected to Z80 clock: on real Turbo machine the System Clock (Dave Clock) raised for higher CPU clock, on emu can set both independently.
-SET TAPE SOUND OFF (Port B5h, bit5 set to 1) on emu make a full silent tape loading, but on real machine some (about 5-10% volume level) sound remain.
-Sound of tape relays not emulated.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: geco on 2022.March.03. 14:19:44
Yes please....

I collected some songs which uses special features of Dave, i did not find midi which uses Low Pass Filter, Szipucsu know if there is any of EPM's which uses LP filter, I used the snapshot for checking musics in EP128emu, so the file pathes are from RAM Drive, but you can download music files separately also, and snapshot also from here (https://enterpriseforever.com/letoltesek-downloads/midi-songs/)

E:\C64\CAULDMET.EPM
chn1    ring mod with chn3, later ring mod+4­bit polynomial counter distortion
chn2-3    4­bit polynomial counter distortion
and it changes polynomial counter length alsoregister A6 bit2,bit3

E:\C64\INSIDE2.EPM
chn1   5­bit polynomial counter distortion

E:\C64\RASPUTIN.EPM
uses 5­bit polynomial counter distortion and 7­bit polynomial counter distortion on all chanels

E:\GAMES\CYBERUN2.EPM
chn1 high pass filter using tone channel 2 as clock.
chn3 ring mod with chn 1

E:\MOVIE\AIRWOLF.EPM
register a6, bit0,bit1 change noise clock frequency, bit3,bit2 Select polynomial counter length and bit4 Swop 17­bit and 7­bit polynomial counters.

E:\TECHNO\CAMILLA.EPM
Enable 4­bit polynomial counter distortion,ring mod, Select noise clock frequency, Select polynomial counter length,  Swop 17­bit and 7­bit polynomial counters

E:\TECHNO\ELTRLOVE.EPM
ring mod and high pass filter on more channels during the music, Enable 4­bit polynomial counter distortion also, and Select polynomial counter length (all 4 option is used), Swop 17­bit and 7­bit polynomial counters

E:\TECHNO\MEMORIES.EPM
ring mod, high pass filter on chn1 and chn3 in the same time, and Select polynomial counter length (all 4 option is used)
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: rampa on 2022.March.03. 18:32:38
what player and extension do i need for playing?
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: rampa on 2022.March.03. 18:38:24
I remember Tutus trying to compile it on Mac, because it is the same machine he uses to edition.

  I asked because i've found 3 clock speeds for PN counters. in all the official documentation, it says 31.25Khz, in the ep128emu sources, it says 62.50khz, and here (https://enterpriseforever.com/hardver/dave/msg19278/#msg19278) says 250khz.... the correct value seems 31k25. now all the PN sound fine. but have another problem. Somebody knows how the basic command "wait delay" gets its timings?
 
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: szipucsu on 2022.March.03. 19:13:42
As I remember it uses only the polynomial counters, filters and ring modulation is not used, but Szipucsu can correct me, he created the music from Midi.
You are right. Only 4bit distortion is used in Fred music. No filters, no ring modulation.

I collected some songs which uses special features of Dave, i did not find midi which uses Low Pass Filter
You are right, no low pass filter.

To get the most features of Dave, I suggest the Szipucsu and Techno folders among midi songs.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: geco on 2022.March.03. 20:39:27
Somebody knows how the basic command "wait delay" gets its timings?
As i see from debugger, it uses the 1 Hz interrupt for WAIT DELAY x, where x is delay value in seconds.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: geco on 2022.March.03. 20:51:10
what player and extension do i need for playing?
From Midi tools package (https://enterpriseforever.com/letoltesek-downloads/enterprise-software/?action=dlattach;attach=25293) you need MIDIDISP.COM to play EPM files FILE system extension is also needed, but i think you uses a ROM config which contains it.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: geco on 2022.March.03. 21:07:03
I created a snapshot for Low Pass filter example, it gives good aircraft sound :D
port settings:
0a4h: 1ch
0a5h: 00h
0a6h: 20h
0abh: 1fh
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: rampa on 2022.March.04. 01:31:02
From Midi tools package (https://enterpriseforever.com/letoltesek-downloads/enterprise-software/?action=dlattach;attach=25293) you need MIDIDISP.COM to play EPM files FILE system extension is also needed, but i think you uses a ROM config which contains it.

 Thanks very much. spotted the bug and fixed.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: rampa on 2022.March.04. 17:06:49
I created a snapshot for Low Pass filter example, it gives good aircraft sound :D
port settings:
0a4h: 1ch
0a5h: 00h
0a6h: 20h
0abh: 1fh

how do yo load this on the ep?
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: rampa on 2022.March.04. 17:10:01

 in the fred ingame, there is a sound like an acoustic bass. how is this done?
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: geco on 2022.March.04. 19:14:14
how do yo load this on the ep?
There are more method, i used the BASIC CODE command to insert small binary code, both file will give the same result, 1st was saved as text, 2nd in tokenized format.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: szipucsu on 2022.March.04. 19:47:33
in the fred ingame, there is a sound like an acoustic bass. how is this done?
It is simply 4bit distortion (SOUND STYLE 16,SOURCE x in IS-BASIC, where x can be 0, 1 or 2).
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: ron on 2022.March.04. 20:27:59
https://www.twitch.tv/retrocrypta
22:00 CET

[attachimg=1]
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: ron on 2022.March.05. 20:20:24
20:30, streaming live.
Now Dave almost 100%, it sounds great !!!
Downloads : http://www.retrowiki.es/viewtopic.php?f=107&t=200037978

Cheers !
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: geco on 2022.March.06. 11:02:14
Yesterday i could not attend on the live show, I did not see the short notice :)

Congratulation Rampa, Dave sounded great in the video, Fred was perfect, as i see sometimes still only 2 channels are initialized for digi play :)

I was surprised on MODPLAY, because the screen were blank, at left bottom were there screen of real EP?
The screen should be in text mode, and display mod specific stuff.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: rampa on 2022.March.07. 16:03:34
Yesterday i could not attend on the live show, I did not see the short notice :)

Congratulation Rampa, Dave sounded great in the video, Fred was perfect, as i see sometimes still only 2 channels are initialized for digi play :)

I was surprised on MODPLAY, because the screen were blank, at left bottom were there screen of real EP?
The screen should be in text mode, and display mod specific stuff.

 Thanks very much! still looking for the randmly missed channels.

  The 17bits PN can be used on the a,b and c channels. but i dont understand how its done... only swapping the pn7 and pn17 on the noise channel affects the other channels? and how the 9,11 and 13 bit PN are selected? on the noise channel?

Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: geco on 2022.March.07. 17:21:02
 The 17bits PN can be used on the a,b and c channels. but i dont understand how its done... only swapping the pn7 and pn17 on the noise channel affects the other channels? and how the 9,11 and 13 bit PN are selected? on the noise channel?

Here you can find an extended Dave documentation with IstvánV's extra information, unfortunately it is hungarian, but i hope google translate will give a readable result:
http://www.ep128.hu/Ep_Konyv/Exos.htm#240

as i see:
7 bit PN (selected on tone channel) can be changed to 17/15/11/9 bit PN (specified on port 0a6h)
and now i understand why 7 bit PN selected on a tone channel and setting 10h to 0a6h gives noise, because noise channel is a 17 bit PN at 31KHz this generate pseudo white noise, and by this setting we set 17 bit PN to the tone channel, and it's frequency can be changed, not fix like on noise channel.
4,5 bit PN's are valid only on tone channels.
if bit 4 of 0a6h is not set then tone channels uses the 7bit PN, and noise channel uses the 17/15/11/9 bit PN based on bit3 and bit2 setting of 0a6h, if bit4 is set on 0a6h then tone channels uses the 17/15/11/9 bit PN based on bit3 and bit2 setting of 0a6h and in this case it's clock will be 250KHz and noise channel uses 7 bit PN on the noise channel clock (31,25 kHz) or selected tone channel clock by bit1 and bit0 of 0a6h.

Length of PN series: 2^N-1 (it can not be 0, it would cause forever loop with 0 (0 XOR 0 = 0))
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: rampa on 2022.March.07. 18:54:18
Here you can find an extended Dave documentation with IstvánV's extra information, unfortunately it is hungarian, but i hope google translate will give a readable result:
http://www.ep128.hu/Ep_Konyv/Exos.htm#240

as i see:
7 bit PN (selected on tone channel) can be changed to 17/15/11/9 bit PN (specified on port 0a6h)
and now i understand why 7 bit PN selected on a tone channel and setting 10h to 0a6h gives noise, because noise channel is a 17 bit PN at 31KHz this generate pseudo white noise, and by this setting we set 17 bit PN to the tone channel, and it's frequency can be changed, not fix like on noise channel.
4,5 bit PN's are valid only on tone channels.
if bit 4 of 0a6h is not set then tone channels uses the 7bit PN, and noise channel uses the 17/15/11/9 bit PN based on bit3 and bit2 setting of 0a6h, if bit4 is set on 0a6h then tone channels uses the 17/15/11/9 bit PN based on bit3 and bit2 setting of 0a6h and in this case it's clock will be 250KHz and noise channel uses 7 bit PN on the noise channel clock (31,25 kHz) or selected tone channel clock by bit1 and bit0 of 0a6h.

Length of PN series: 2^N-1 (it can not be 0, it would cause forever loop with 0 (0 XOR 0 = 0))

 Redone the chip exactly as the document says.... seems to sound a bit better (fred and so) but still missing channels (sometimes) in bricky

the first load, in the records screen. only two channels. after the ingame, the records screen has the 4 channels.....
may be the problem is not in the audio?
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: geco on 2022.March.07. 19:35:05
the first load, in the records screen. only two channels. after the ingame, the records screen has the 4 channels.....
may be the problem is not in the audio?
I got 2 ideas:
1st z80 timing is not perfect, and this cause sometimes we have 4 channels ,and sometimes 2, because the Dave initialization routine uses z80 instructions in wait loop.
2nd initialization routine resets the oscillators by ld a,07h out (0a7h), a (to zero phase and output state) and this does not happens on FPGA.
But i think it is not a major issue, since sometimes it is good, and sometimes it is not. Do we have a sequence? ex every 2nd is good? Or is it total random?
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: rampa on 2022.March.07. 23:24:22
I got 2 ideas:
1st z80 timing is not perfect, and this cause sometimes we have 4 channels ,and sometimes 2, because the Dave initialization routine uses z80 instructions in wait loop.
2nd initialization routine resets the oscillators by ld a,07h out (0a7h), a (to zero phase and output state) and this does not happens on FPGA.
But i think it is not a major issue, since sometimes it is good, and sometimes it is not. Do we have a sequence? ex every 2nd is good? Or is it total random?

 no, i'm resseting all registers as h00!
is there any other register initialized on reset?

 
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: rampa on 2022.March.07. 23:43:31
I got 2 ideas:
1st z80 timing is not perfect, and this cause sometimes we have 4 channels ,and sometimes 2, because the Dave initialization routine uses z80 instructions in wait loop.
2nd initialization routine resets the oscillators by ld a,07h out (0a7h), a (to zero phase and output state) and this does not happens on FPGA.
But i think it is not a major issue, since sometimes it is good, and sometimes it is not. Do we have a sequence? ex every 2nd is good? Or is it total random?

on reset now, i am writting 07h to 0a7h.  the pattern has changed a bit.

after load : 4 channels.
records screen: 2 channels (an atmosferic pad and the bass)
ingame OK
record screen: 4 channels.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: geco on 2022.March.08. 08:34:26
As i see from István's addon:
Setting syncronization bit means (bit0-bit2) on 0a7h:

Counter of the channel is not running where the bit is set
The counter is keept on the frequency value which is set on the appropriate tone channel (reg 0a0h-0a5h)
Flip-flop output of tone generator is set to 0.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: rampa on 2022.March.09. 16:15:41

 about the sound... i'm going to wait for bricky showing the bottom part of the screen (may be related) as it is the only program with random channel problems.


 I started today with the FD controller. all seem ok, but i'm getting "controller not ready" looking at the fdc chip all seems ok, but 1 bit ......

 Seems i'm not replying on time to the DRQ request.

 Somebody know the exact contents (input and output) of the 0x18 status port?

Thanks in advance.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Zozosoft on 2022.March.09. 17:13:18
Do you also simulated the shadow of I/O ports?
10-13H mirrored at 14-17H, and also used by EXDOS.

If you using EXDOS 1.4, theres is my WD check routine at the start, testing register mirrorings for WD presence. Original EXDOS freeze without WD. Then I added WD check, and the new Controller not ready error, then EXDOS 1.4 can be used without floppy hardware, for example SD only system.

This is my test routine:
Code: ZiLOG Z80 Assembler
  1. WDCHECK:        LD A,55H
  2.                         OUT (11H),A
  3.                         LD A,0AAH
  4.                         OUT (12H),A
  5.                         PUSH BC
  6.                         PUSH BC
  7.                         POP BC
  8.                         POP BC
  9.                         IN A,(15H)
  10.                         CP 55H
  11.                         RET NZ
  12.                         IN A,(16H)
  13.                         CP 0AAH
  14.                         RET NZ
  15.                         LD A,0AAH
  16.                         OUT (11H),A
  17.                         LD A,55H
  18.                         OUT (12H),A
  19.                         PUSH BC
  20.                         PUSH BC
  21.                         POP BC
  22.                         POP BC
  23.                         IN A,(15H)
  24.                         CP 0AAH
  25.                         RET NZ
  26.                         IN A,(16H)
  27.                         CP 55H
  28.                         RET
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: rampa on 2022.March.09. 17:53:15
Do you also simulated the shadow of I/O ports?
10-13H mirrored at 14-17H, and also used by EXDOS.

If you using EXDOS 1.4, theres is my WD check routine at the start, testing register mirrorings for WD presence. Original EXDOS freeze without WD. Then I added WD check, and the new Controller not ready error, then EXDOS 1.4 can be used without floppy hardware, for example SD only system.

This is my test routine:
Code: ZiLOG Z80 Assembler
  1. WDCHECK:        LD A,55H
  2.                         OUT (11H),A
  3.                         LD A,0AAH
  4.                         OUT (12H),A
  5.                         PUSH BC
  6.                         PUSH BC
  7.                         POP BC
  8.                         POP BC
  9.                         IN A,(15H)
  10.                         CP 55H
  11.                         RET NZ
  12.                         IN A,(16H)
  13.                         CP 0AAH
  14.                         RET NZ
  15.                         LD A,0AAH
  16.                         OUT (11H),A
  17.                         LD A,55H
  18.                         OUT (12H),A
  19.                         PUSH BC
  20.                         PUSH BC
  21.                         POP BC
  22.                         POP BC
  23.                         IN A,(15H)
  24.                         CP 0AAH
  25.                         RET NZ
  26.                         IN A,(16H)
  27.                         CP 55H
  28.                         RET

yes, mirroring is implemented, a for loop in basic, shows the same values at startup as the real hardware except for port 0x10 (and mirrored port) the real ep has a 0x00 and the fpga controller a 0x04

Also what the "controller not ready " condition really is? 
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: rampa on 2022.March.09. 19:14:12

 Testing your routine, seems my controller is latching the value. each time i peek the port, got the previous value.

 Looking at it. thanks
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: rampa on 2022.March.09. 19:47:34

 Ok. changed timings on the signal and now, ports are ok and the controller is ready.... now struggling with "not a dos disk"
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Zozosoft on 2022.March.09. 20:24:58
now struggling with "not a dos disk"
This means: reading boot sector successfully, but the readed data not a valid FAT boot sector.
I suggest use EPDOS Disk Editor (http://www.ep128.hu/Ep_Util/Pic/EPDOS_2.gif), for easy view what readed.
After enter EPDOS, press Abort on disk error, navigate to the D-EDIT, start it, Abort on disk error, press CTRL+F8 for switch Track/Sector mode.
ALT+Up/Down track change, ALT+Left/Right sector change, CTRL+Left/Right side change.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: rampa on 2022.March.09. 21:40:03
This means: reading boot sector successfully, but the readed data not a valid FAT boot sector.
I suggest use EPDOS Disk Editor (http://www.ep128.hu/Ep_Util/Pic/EPDOS_2.gif), for easy view what readed.
After enter EPDOS, press Abort on disk error, navigate to the D-EDIT, start it, Abort on disk error, press CTRL+F8 for switch Track/Sector mode.
ALT+Up/Down track change, ALT+Left/Right sector change, CTRL+Left/Right side change.

 Thanks for the tip.... all 00.... back to code diving....

-ramon-
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: rampa on 2022.March.14. 17:57:04

 Still fighting with the fdd controller... :(

 i was thinking in problems with the disk image. so i have tried to format it.  (reading still getting "no OS disk") it seems to start the format and afer two or three seconds. "not ready"

Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: BruceTanner on 2022.March.14. 18:33:27
In case it is any help, this is the loop within EXDOS that reads disk data:

Code: ZiLOG Z80 Assembler
  1. ;   READ COMMANDS  -  READ SECTORS, READ ADDRESS and READ TRACK
  2. ;
  3. ;
  4. READ:   CALL    GET_CMD                 ;Get FDC command and timeout
  5.         OUT     (C),A                   ;Give command to FDC chip
  6.         SET     3,C                     ;Point to external status port 
  7. ;
  8. ; WAIT FOR FIRST DRQ WITH TIMEOUT.  138T (34.5us) per loop.
  9. ;
  10. RD_WT1: JR      $+2             ;13T    Padding
  11.         LD      A,0             ;8 T    Padding
  12.         IN      A,(C)           ;14T
  13.         JP      M,RD_LP         ;11T    Jump if got DRQ
  14.         DEC     DE              ;7 T    Decrement timeout count
  15.         IN      A,(C)           ;14T    Padding
  16.         IN      A,(C)           ;14T
  17.         JP      M,RD_LP         ;11T    Jump if got DRQ
  18.         LD      A,D             ;5 T   
  19.         OR      E               ;5 T
  20.         JP      Z,TIMED_OUT     ;11T    Jump if timeout expired
  21.         IN      A,(C)           ;14T
  22.         JP      P,RD_WT1        ;11T    Loop if still no DRQ   
  23. ;
  24. ;
  25. RD_LP:  DEC     C               ;5 T   
  26.         IN      A,(C)           ;14T    Get byte from FDC data register
  27.         LD      (HL),A          ;8+8T   Store it in RAM (clock stretch!)
  28.         INC     HL              ;7 T    Bump disk transfer address
  29.         INC     C               ;5 T
  30. RD_WT:  IN      A,(C)           ;14T   
  31.         AND     82H             ;8 T    Look at DRQ and INTRQ bits
  32.         JR      Z,RD_WT         ;8/13T  Wait if neither set
  33.         JP      M,RD_LP         ;11T    Jump if DRQ is set
  34. ;
  35.         JR      DONE_X          ;Exit when INTRQ occurs  
  36.  
  37.  
  38. GET_CMD:
  39. ;
  40. ;    Determine correct FDC command by including "settle delay" flag if
  41. ; required.  Also determine correct timeout delay for read and verify
  42. ; depending on "motor on" flag.  Write will ignore this value.
  43. ;
  44. ;
  45.         BIT     2,(IY+DELAY_FLAGS##)    ;Test "settle delay" flag
  46.         JR      Z,NO_SET
  47.         SET     2,A                     ;If required then set bit-2
  48. NO_SET:
  49. ;
  50.         LD      DE,09331h               ;Short timeout of 1.3s if motor on
  51.         BIT     7,(IY+DELAY_FLAGS##)
  52.         RET     NZ
  53.         LD      DE,0                    ;Long timeout of 2.3s if motor off
  54.         RET
  55.  
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: BruceTanner on 2022.March.14. 18:37:05
I don't know what happened there, and sorry the tabs size is mixed up but hopefully it is usable. Ignore the bit at the end that says ". str_ireplace(' [ Attachment Invalid Or Does Not Exist ] '" I did not add that, the "system" did! :lol:

B.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Zozosoft on 2022.March.14. 20:09:30
I don't know what happened there, and sorry the tabs size is mixed up but hopefully it is usable. Ignore the bit at the end that says ". str_ireplace(' [ Attachment Invalid Or Does Not Exist ] '" I did not add that, the "system" did! :lol:
It is a forum bug :oops:
At the code block start with code=z80, then working.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: BruceTanner on 2022.March.14. 20:33:16
:shock: surely not! :lol: Thanks for fixing!
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: rampa on 2022.March.16. 11:58:13

 Still in the same point.... but some doubts.

  In the real hardware, each time i change unit (from A: to B:) the ep ask me to put a disk in the drive (there is a floppy in the drive) but the FPGA simply try to read the drive. Also, i only have one drive, but the fpga try to access inexistent drives. How it detect the drives?

Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: BruceTanner on 2022.March.16. 12:47:15
In the real hardware, each time i change unit (from A: to B:) the ep ask me to put a disk in the drive (there is a floppy in the drive) but the FPGA simply try to read the drive. Also, i only have one drive, but the fpga try to access inexistent drives. How it detect the drives?
It does a WD1770 "Restore" command, waits for the WD to become non-busy in the status resgister (bit 0 == 0), and then looks at bit 2 of the status register, which should be 0 if the drive head is now at track 0.

After testing drive A: in this way, it repeats for drive B:. For emulating a one-drive system, bit 2 of the status register needs to be 0 for drive A: and 1 for drive B:. after a "Restore" command.

B.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: BruceTanner on 2022.March.16. 17:44:55
Still in the same point...
Just a thought... are you using a FPGA Z80? If you are, does the IN A,(C) instruction set the flags? The code I posted earlier relies on this but it is probably not the most frequently used Z80 feature!
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: rampa on 2022.March.16. 18:45:14
Just a thought... are you using a FPGA Z80? If you are, does the IN A,(C) instruction set the flags? The code I posted earlier relies on this but it is probably not the most frequently used Z80 feature!

  As far as i recall i have used it in the past. T80 is a good Z80 implementation. I think the problem is in the 1770 controller. seems it is seting the tr00 bit without "inserted disk" (really a monted image)
Title: Candidate Releases: Enterprise Deployment Attempt Over FPGA.
Post by: ron on 2022.May.02. 01:54:12
Here:
http://retrowiki.es/viewtopic.php?f=107&t=200037978&p=200154151#p200154146

and here:
https://misterfpga.org/viewtopic.php?t=4645
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Dr.OG on 2022.May.02. 05:06:41
WOW! Thanks for your efforts!
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: ron 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
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Dr.OG 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...
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Kyp 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!
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: geco 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  )
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Kyp 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 :)
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: geco 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)
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: gyurco 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.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Dr.OG on 2022.November.07. 05:13:15
WOW! It would be awesome to try this core on MiST...
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Kyp 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.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: ron 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 !!!
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: ergoGnomik 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.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: ron 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
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: gflorez 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.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: ron 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.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Kyp 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
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: gyurco on 2022.November.12. 15:30:11
I already checked your sources, and the asynchronous clocks of NIC and the CPU are indeed a problem, but not unsolvable.
The original machine also shares the video RAM page (Dave generates the WAIT_N signal to the CPU - I see it's not implemented (yet), but not a big problem, except for cycle-accuracy).

The 4 MHz Z80 expects the RAM speed (without wait states) at most 2.6 MHz rate (M1 cycle is 1,5 cycles long), so it's no problem for the SDRAM controller.
Nick (should) not use a bigger rate also (as the original DRAMs are not faster). I didn't check the details of your Nick implementation yet, but if it requires the data available after the address setup in 1-2 master cycles, then it should be changed (the displaying pipeline will be longer, but also more faithful to the original). This one also a common problem with lot of cores, while the time between the address setups can be 8-16 pixel clock cycles, the data is expected to be returned in 1 cycle. It's clearly for BRAM, and not really how the original hardware worked.

Finally the Amstad CPC uses a similar display access rate, and it has no problem with the SDRAM controller @64MHz.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: gyurco on 2022.November.12. 16:36:10
From the schematics of the Dave chip, it looks like the WAIT_N generator only uses the port BF(?), and doesn't consider if it's VRAM page access or not. Is it true that the CPU throttling is applied to all RAM pages on the original machine?

BTW, it's interesting they choose a design with asynchronous CPU and video clocks. Even the Amiga was designed with synchronous clocks, as making them async can give serious headaches with synchronizing and timing checks (even today, with FPGA designs). Maybe it was one of the reasons why the machine was delayed? It would be more simple if they simply choose a 8MHz pixel clock (16 MHz master clock for the Nick).

Upd.: Seems I was wrong, and the design is even more complicated than I first anticipated: while WAIT_N is generated by Dave, the CPU clock itself is generated by Nick, which can simply disable it (hold at a level - similarly to ZX Spectrum) while it wants to access the VRAM.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Kyp on 2022.November.14. 15:31:26
An horizontal line of about 63.7us is divided in 57 columns of 1117ns. A column takes 16 clocks. Nick reads two times in the first 10 clocks, and CPU is allowed to access memory in the last 6 clocks.

My Nick implementation put addresses during all 5 clocks and reads at the negedge of the last one.

Dave wait states are independent of memory contention, I think is safe to ignore it at least for now. As you said, contention is similar to Spectrum, holding Z80's clock.

AFAIK only shared video memory is contended.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: geco on 2022.November.14. 16:54:51
AFAIK only shared video memory is contended.
Yes, only Video RAM is contended, others are not.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: gyurco on 2022.November.14. 18:41:18
Thanks for confirming.
As I suspected, the SDRAM has no problem with serving both the CPU and Nick (even without contention):
https://ibb.co/mvkLxJc
https://ibb.co/8YfsTpQ

Now it's time to learn about the machine :)
(My friend from elementary school had one, but I only saw playing Last Ninja II).

@Kyp: When I'll complete the port, I'll push my changes to your repo in a separate branch if it's OK to you. Then merging with master can be decided later on.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: ron on 2022.November.14. 22:04:14
What a wonderful post !
Sounds a bell !
Thanks a lot.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: ron on 2022.November.14. 23:36:39
it does not synthesize. Even with latest MiST modules
it takes more than 20 minutes, I have stopped , isn't it too much ?
Using Q13.

Regards
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: gyurco on 2022.November.14. 23:47:24
It's a very small core, synthesizes in less than a minute:


Fitter Status   Successful - Mon Nov 14 21:11:22 2022
Quartus II 64-Bit Version   13.1.4 Build 182 03/12/2014 SJ Web Edition
Revision Name   enterprise
Top-level Entity Name   enterprise_mist
Family   Cyclone III
Device   EP3C25E144C8
Timing Models   Final
Total logic elements   5,966 / 24,624 ( 24 % )
Total combinational functions   5,279 / 24,624 ( 21 % )
Dedicated logic registers   2,345 / 24,624 ( 10 % )
Total registers   2404
Total pins   72 / 83 ( 87 % )
Total virtual pins   0
Total memory bits   43,008 / 608,256 ( 7 % )
Embedded Multiplier 9-bit elements   9 / 132 ( 7 % )
Total PLLs   1 / 4 ( 25 % )


Do you have Quartus 13 updates installed? The latest is 13.1.4.
Also I noticed that on very new Linux distros, the fitter simply hangs forever.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: ron on 2022.November.16. 17:42:28
Please, here are first testing versions.
Feedback is very appreciated.

Enjoy the Enteprise on the MiST. Thanks to Gyurco.
Regards.

[attachmini=1]
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: ron on 2022.November.25. 14:15:38
http://www.retrowiki.es/viewtopic.php?f=106&t=200038931

[attachimg=1]

For all the friends of Enteprise, next Sunday we will broadcast a live show in which we will present a demonstration of Zozo's new EXDOS 3.0.
Running on real Enteprise hardware and several FPGA boards.

19:30 CET: https://www.twitch.tv/retrocrypta
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: gflorez on 2022.November.25. 15:01:41
(Sorry, I have explained Ron that Zozo is working on the SF3 driver and Bruce Tanner on EXDOS3.0)
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Zozosoft on 2022.November.25. 15:31:34
(Sorry, I have explained Ron that Zozo is working on the SF3 driver and Bruce Tanner on EXDOS3.0)
Yes, most of work on EXDOS 3 done by Bruce. But now my previous EXDOS fixes and enhancements are officially included in the code.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: ron on 2022.December.09. 14:39:41
After spending a reasonable time, I have been able to test the Enterprise core on several fpga boards such as: ZXuno, N-Go ( ZXNext), MiSTer, NeptUNO, MiSTica and SiDi.

I would like to know what your impressions and opinions are (if you have been able to try it). At the end, it is about putting an Enterprise in the hands of everyone who has an FPGA board, I am convinced that it has to help disseminate and publicize such a powerful machine that every hobbyst should know about.

Regards
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: rampa on 2022.December.27. 10:49:24

 FDC not Ready and ready problems.


 I have the FDC almost done. It works both reading and writting, but dont understand how the enter get the ready and not ready states.... :(


   All my drives seem to be always ready. i can get at the start drive A and B mapped (via track00). but drives C and D, are ready! ("Unformatted disk"  if i execute a dic c:)
  The format command is not working on the online drives.... "Not ready" message :-)

 Looking at the docs, the /ready line goes to bit 0 on port 0x18, but the docs also says the /ready line is optional.

 Any clues?

 
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: geco on 2022.December.27. 11:08:33
I hope Zozo can help, he knows nearly everything how EXDOS handles the drives.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Zozosoft on 2022.December.27. 12:02:36
I suggest to try DRVTEST (https://enterpriseforever.com/programming/drvtest-1780/msg78152/#msg78152) for testing all signals.

Anyway, on real machines the FORMAT say not ready when problem with Index pulses. Drive with faulty Index signal can Sector Read/Write, but fail at FORMAT.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: rampa on 2022.December.27. 21:29:10
I suggest to try DRVTEST (https://enterpriseforever.com/programming/drvtest-1780/msg78152/#msg78152) for testing all signals.

Anyway, on real machines the FORMAT say not ready when problem with Index pulses. Drive with faulty Index signal can Sector Read/Write, but fail at FORMAT.

 If i had this before... :-)

  Thank you very much. seems that i have all the lines working as expected now... but still problems with format.

   I am sending index pulses at 300rpm (drvtest reports 294~300)
 
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Zozosoft on 2022.December.28. 11:20:49
When executing Step/Seek/Restore commands, motor also will turn on, and drive become ready?
Format firstly do SD/DD check. Do 50 STEPIN then counting how many STEPOUT needed for a Track 00. Also report Not Ready if still no Track 00 after 256 STEPOUT.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: rampa on 2022.December.28. 19:32:57
When executing Step/Seek/Restore commands, motor also will turn on, and drive become ready?
Format firstly do SD/DD check. Do 50 STEPIN then counting how many STEPOUT needed for a Track 00. Also report Not Ready if still no Track 00 after 256 STEPOUT.

 Yes, motor is turning on.. (not on restore, should it?) and the ready signal is on. may be it is too short? cannot see changes on DRVTEST on pin 2 and 34 (always blue)

 
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Zozosoft on 2022.December.28. 22:26:00
not on restore, should it?
Yes.

Quote
and the ready signal is on. may be it is too short? cannot see changes on DRVTEST on pin 2 and 34 (always blue)
I will try make video on a real machine for see signal changes.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Zozosoft on 2022.December.29. 12:16:24
cannot see changes on DRVTEST on pin 2 and 34 (always blue)
Probably there are the problem. The default state of these are RED.

Video of Ready signal operation. (https://drive.google.com/file/d/1qx_YqSY8rDo8kwDwz9Te10OPQX1l282V/view?usp=sharing) (Note in this video the 2 constant blue because the 1.2M drive forced to 300rpm mode by Pin2 soldered to GND).
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: rampa on 2022.December.30. 00:26:23
Probably there are the problem. The default state of these are RED.

Video of Ready signal operation. (https://drive.google.com/file/d/1qx_YqSY8rDo8kwDwz9Te10OPQX1l282V/view?usp=sharing) (Note in this video the 2 constant blue because the 1.2M drive forced to 300rpm mode by Pin2 soldered to GND).

 cant get red on any of this :(  i'm sendig the value to  0x18 i/o port on enterprise. tried to send 1 and 0 (bypassing the controller) and still on blue....
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: rampa on 2022.December.30. 01:54:43

 ops. found it... was unconnected on a intermediate module......  But still no format....
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Zozosoft on 2022.December.30. 09:46:56
The firstly test Read Address command in DRVTEST.
Needed display data, and got a OK.
If head at wrong position the different data marked as red.
[attach=1][attach=2]

Then test Read/Write Track. Put EPDOS 1.x ROM to your configuration, start it and enter to DISK EDITOR.
Switch to TRACK EDITOR mode.
Track readed, usually got a Data error, because now all data handled as raw data, including CRC bytes. Don't care about it :-)
[attach=3]

Then make a new FORMAT template to buffer, for example with FORMA9. Then press WRITE. It is needed to be completed without error.
[attach=4]
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: rampa on 2022.December.30. 11:51:09
The firstly test Read Address command in DRVTEST.
Needed display data, and got a OK.
If head at wrong position the different data marked as red.
(Attachment Link) (Attachment Link)

Here i have the same as you. the first "ENTER" track number red... but with oner HOME,STEPIN,STEPOUT,etc all the respones GREEN (just like you)

Quote
Then test Read/Write Track. Put EPDOS 1.x ROM to your configuration, start it and enter to DISK EDITOR.
Switch to TRACK EDITOR mode.
Track readed, usually got a Data error, because now all data handled as raw data, including CRC bytes. Don't care about it :-)
(Attachment)

Then make a new FORMAT template to buffer, for example with FORMA9. Then press WRITE. It is needed to be completed without error.
(Attachment)

Similar, but "sector not found" instead of "data error" and if i write the track.... Not ready.....
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Zozosoft on 2022.December.30. 12:07:55
Similar, but "sector not found" instead of "data error" and if i write the track.... Not ready.....
Ok, now we know why not works the FORMAT :ds_icon_cheesygrin:

Then look about your track command emulations. Are these implemented at all?
In ep128emu Read Track not implemented, but this is not too important.
At Write Track, it is gather the sector addresses and sector data fields from the raw track byte stream and write the data for the right sector in the disk image.
Then formating will work, just you can't use different format than the existing format of disk image format. For example you can format 720K disk to 720K, but can't to 800K.

Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: rampa on 2022.December.30. 20:00:06
Ok, now we know why not works the FORMAT :ds_icon_cheesygrin:

Then look about your track command emulations. Are these implemented at all?
In ep128emu Read Track not implemented, but this is not too important.
At Write Track, it is gather the sector addresses and sector data fields from the raw track byte stream and write the data for the right sector in the disk image.
Then formating will work, just you can't use different format than the existing format of disk image format. For example you can format 720K disk to 720K, but can't to 800K.

 looking close at your screens, your home command, changes sector to 2..... Mine  to 0..... :-(
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Zozosoft on 2022.December.30. 20:22:02
looking close at your screens, your home command, changes sector to 2..... Mine  to 0..... :-(
0 are wrong value, because the sectors numbered from 1... :oops:

The current value are "random", it is return with a firstly found sector header, soo depending the current disk position while rotating. But with 720K disks need it from 1 to 9.
On a non rotating disk images :lol: practicaly will be 1 the first, if more addresses readed, then 1,2,3... until max sector, then start again from 1.

Anyway the Track and Head fields are the most important data. Head used for a check for single sided drive at Format. And also when read disk information: if it is two sided disk, check for one head drive, and report Incompatible disk if this is the situation.
Also at disk check do some Step In, and read address and verify Track number. If it is right, then nothing to do.
If it is 1/2 value, then 40 track disk in 80 track drive needed to use double stepping.
And if 2x value the 80 track disk in 40 track drive, report Incompatible disk error.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: rampa on 2022.December.31. 20:16:28
0 are wrong value, because the sectors numbered from 1... :oops:

The current value are "random", it is return with a firstly found sector header, soo depending the current disk position while rotating. But with 720K disks need it from 1 to 9.
On a non rotating disk images :lol: practicaly will be 1 the first, if more addresses readed, then 1,2,3... until max sector, then start again from 1.

Anyway the Track and Head fields are the most important data. Head used for a check for single sided drive at Format. And also when read disk information: if it is two sided disk, check for one head drive, and report Incompatible disk if this is the situation.
Also at disk check do some Step In, and read address and verify Track number. If it is right, then nothing to do.
If it is 1/2 value, then 40 track disk in 80 track drive needed to use double stepping.
And if 2x value the 80 track disk in 40 track drive, report Incompatible disk error.

 So it is OK to return 1 as sector....

 
What EPDOS is doing just after ALT F8? only a small flash on the drive led and "sector not found"
is EPDOS looking at CRC value? (not sending CRC... but never needed it.)
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: rampa on 2023.January.01. 18:10:26
So it is OK to return 1 as sector....

  
What EPDOS is doing just after ALT F8? only a small flash on the drive led and "sector not found"
is EPDOS looking at CRC value? (not sending CRC... but never needed it.)

 Found it... read track... seems my read track is broken... but the emulator has a stub on it (setting RNF???)
Title: WD1770 working OK!
Post by: rampa on 2023.January.01. 22:37:19


   Thanks very much to everybody. Disk controller is working ok now....
 
Title: Re: WD1770 working OK!
Post by: Zozosoft on 2023.January.02. 02:30:59
Thanks very much to everybody. Disk controller is working ok now....
Great!
What is the final solution?
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: rampa on 2023.January.03. 10:41:58

 Not sure what fixed the problem (may  be a compund)

- Implemented exact seek times.
- Got all the floppy lines from the "virtual" floppy
- Reimplemented the track functions.
- Implemented CRC calculation.

Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Zozosoft on 2023.January.25. 22:59:51
Now when the full machine working right in FPGA...
Possible to put FPGA core of Nick and Dave to any FPGA chip, and produce replacement chips which can be installed to real chips place? Repair dead machines.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Kyp on 2023.January.25. 23:28:19
It's possible but it's not that easy, doing an FPGA implementation is much easier than doing an actual chip replacement :(
To do a real chip replacement needs a lot of extra work.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: ergoGnomik on 2023.January.26. 16:33:19
And it is even harder to make it fit in the space and volume of the original QFP package.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: gflorez on 2023.January.26. 17:05:08
I think the main problem is to "tie" the modern technology with the old. The two devices behave the same on video or sound, but they are very different inside.

Kyp says that FPGA is easier, I think because in some way it is schematic. But he also says that a physical device made of real components can be created with the information. After all what he manages to design a FPGA core is a hardware descriptive language.

Imagine the possible turnarounds taken by the designer to make the chips real on the 80's, It can be that the contemporary FPGA circuit doesn't need so much pins for Dave and Nick, but you still need all the signals to "transplant" the hypothetical clone chip to the real Machine, to be able to return it to life...

-

I am not the best source of FPGA knowledge, sorry if I can't give a better explanation.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: ergoGnomik on 2023.May.01. 19:52:06
After spending a reasonable time, I have been able to test the Enterprise core on several fpga boards such as: ZXuno, N-Go ( ZXNext), MiSTer, NeptUNO, MiSTica and SiDi.
Reading that the second ZX Spectrum NEXT batch is about to start being manufactured reminded me that there were attempts running  the Enterprise FPGA core on NEXTs or N-GOs. Are there any news about that?
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: gflorez on 2023.May.02. 08:30:23
Yes, there is a preliminary core for the Next(N-go), but it is very old now. Kyp is actually adding EXDOS(floppy controller) and better SD-cartridge management.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Tuby128 on 2023.May.02. 11:15:18
Now when the full machine working right in FPGA...
Possible to put FPGA core of Nick and Dave to any FPGA chip, and produce replacement chips which can be installed to real chips place? Repair dead machines.

 There is several fpga implementation on the internet, where DIP socket chips are replaced with fpga.
 The problem is with nick and dave, that the package is hard to realise. There is not much space.
It is impossible to get an Fpga with that package. On the data/adress lines some level shifter from 5V to 3,3V needed, because the fpga cannot recive 5V on its pinouts. The input burns out.
 What I can imagine, is to open a fpga package, remove the die, put it into a nick/dave package, and make the bonding with golden wires. But this does not solve the problem with 5V -> 3.3V.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: gflorez on 2023.May.16. 09:05:31
Yesterday, a beta of the Enterprise core was presented on the Retrocrypta Twitch channel (https://www.twitch.tv/videos/1820709873), with SD, Floppy and mouse working all at the same time on a NeptUNO FPGA. The video can be long and boring for non Spanish viewers, because a lot of the time Rampa(EXDOS floppy controller and Dave sound) and Kyp(Video, SD and main), are discussing with Ron , the  speaker, about some aspects of the implementation.  This while a just launched FPGA system named ZX3+ is discussed. Probably not the definitive Enterprise FPGA, but time will tell. Maybe if one version is launched with a full keyboard, not the shortened one of the N-Go FPGA.

On Twitch the old videos have a limited time to be shown, so hurry up.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Tutus on 2023.May.16. 09:28:10
:smt038 :smt038 :smt038
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: SlashNet on 2023.May.16. 14:09:02
Wolf? WOW! :shock:
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: MrPrise on 2023.May.16. 15:43:10
Awesome!
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: geco on 2023.May.17. 11:00:36
Wolf? WOW! :shock:
Just a demo version :D (https://www.youtube.com/watch?v=EePP2jNzSs8)
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: SlashNet on 2023.May.17. 14:19:15
Just a demo version
Probably I should add your channel to the monitoring list after all.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: geco on 2023.May.17. 20:35:07
Probably I should add your channel to the monitoring list after all.
I do not think is necessary, i do not think i will upload more videos :-D
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Kyp on 2023.May.19. 18:53:28
I have just released the first official release for neptUNO FPGA and published the source files:
https://github.com/Kyp069/ep
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: gflorez on 2023.May.19. 19:56:44
Yes, and a new Retrocrypta Twitch program is scheduled today:

(http://retrowiki.es/download/file.php?id=200032144) (https://www.twitch.tv/retrocrypta?lang=hu)
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: neurox on 2023.June.26. 19:38:34
Where should I look for the latest core for the MiSTer FPGA? I'm running the 20220501 version I found on https://misterfpga.org/viewtopic.php?t=4645 - is that the latest one available? :-)

Thank you for pouring your time into this - it means a lot to an old Enterprise fan, and as my physical Enterprise machines are slowly dying off because of various issues, it's nice to know that the FPGAs will preserve it! :-)
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: gflorez on 2023.June.27. 18:58:58
I have already notified Kyp your question, He will answer soon.

The Mister is property of sorgelig, so new EP core versions will mandatorily go through his approval. The Mister Main feature or drawback is its front-end and included Arm processor.

The developers of the EP core are the Spanish RW group, and they work on other easier FPGAs, like the Neptuno, without a special firmware or front-end.

Of course there are newer versions of the EP core, and they will slowly surface.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: gflorez on 2023.June.27. 19:18:18
Sorry, I have confused the Mist sorgelig's project with the Mister open project, sorry....

Better wait for Kyp...
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Kyp on 2023.June.29. 10:20:47
I'm half way through the MiSTer version but got stuck trying to use the SDRAM, apparently it's a bit special. I'll get back to it at some point.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Zozosoft on 2023.June.29. 10:28:57
my physical Enterprise machines are slowly dying off because of various issues
What happened to your machines?
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Judge on 2023.July.04. 19:25:37
What happened to your machines?

I would be curious to know. It's gotten to the point where almost everything except the Nick chip and the Dave chip can be fixed on the Enterprise.
Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: gflorez on 2023.November.02. 11:46:11
Kyp has finished his Enterprise core for the MISTer FPGA. Those of you that own such FPGA can download from here (https://github.com/Kyp069/ep).

In the case you are interested on such devices but don't have a MISTer, don't run in a hurry to buy that expensive FPGA, the time has arrived that other better and cheaper alternatives are at hand, with capacity for bigger cores and better specifications. 

These new FPGA platforms are being actually designed by MANUFERHI (https://manuferhi.com/) with special petitions of the Core developers members of the Spanish RetroWiki FPGADEV team.

I will add more information on near future, but by now you can translate some Retrowiki web-page threads.

http://retrowiki.es/viewtopic.php?f=120&t=200039734&hilit=poseidon

http://retrowiki.es/viewtopic.php?f=121&t=200039702&hilit=sidi128

Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: Tuby128 on 2023.November.11. 15:24:59
Kyp has finished his Enterprise core for the MISTer FPGA. Those of you that own such FPGA can download from here (https://github.com/Kyp069/ep).

The custom chip NICK's HDL code is under:
EP/HDL/VIDEO.v
The DAVE (especially the audio part of it) is under:
EP/HDL/AUDIO.v

 The HDL language which used is called "Verilog".

Title: Re: Enterprise Deployment Attempt Over FPGA.
Post by: gflorez on 2023.November.11. 21:11:07
Ok, but this core still needs more development to behave exactly like Nick and Dave.

Also, I already explained that having a "silly box" that behaves like the Enterprise, this not means we have a Verilog description of all the signals and their correspondence with the chip pins to then be able transplant a clone to the EP. There is still a long path to achieve that.