Running Apollo Core

[cinar]

Hello. I know it's said before. I am still trying ways to boot from SD on MiSTer flashed with Apollo Core. It was risky but I have flashed the jic to the DE10 Nano. It only gives black screen as ofc there is no IDE controller. Right now I am trying to push the sagasd.device into a custom rom (custom scsi.device does well). I have compiled custom roms tons of times before but never dealt with BBS hunked ones. Can anyone remove BBS hunk from the sagasd.device on the Vampire SD boot image available in the Github? You can easily install WB31 with PFS3 ready to boot on SD on WinUAE. Thank you.

[lordoftime79]

Am I understanding you are trying to use your Mister as a Vampire?

[Caldor]

Not sure you are going to get much out of trying this. FPGA cores have to be designed for the specific chipset. Does the DE10-Nano even support that core? Getting it onto the DE10 is one thing, but getting it to run is another. On the DE10-Nano there are certain connections for display and such. The core needs to know this, or you wont f.ex. be able to get the display up. Or keyboard input.

Also on the DE10-Nano all of the MiSTer stuff, the cores are designed to interact with the Main core that runs the menus and helps with certain parts of it all. Overall things like certain display types.

I am no expert and some of this is just based on assumptions and speculation based on what I have seen on the forum so far and answers I have gotten when I asked about some of these things. Another thing is that the FPGA Apollo uses, is faster than the DE10-Nano... pretty sure it is anyway. Also does the DE10-Nano even have enough logic to store the full Apollo core?

But what it comes down to, is that if this has to have a chance of working, it has to be reimplemented on a pretty deep level to be able to work with the DE10-Nano. And I suspect Apollo would not like if something like that was done, at least not if it was made public. Doing this as one person, unless you are really experienced with coding FPGA cores, I do not think this is a one person project.

[lordoftime79]

Its not gonna work - the Vampire4sa is closed source why would you think you can flash a Vampire jic to the DE10 nano and have it work? Stupid.

[guibrush]

Flashing the V4 core on a Mister is like dumping a Golf motor in the trunk of a Clio and expect it to make the car move. It’s not possible without big adaptation work. And when I mean big, I mean like month of work.

[Hackshed_Carl]

Its not gonna work - the Vampire4sa is closed source why would you think you can flash a Vampire jic to the DE10 nano and have it work? Stupid.

I don't think it's fair to start throwing insults around.
Let's not call people names for misunderstanding the platform.

Like the great William and Theodore said, "Be excellent to each other"

[lordoftime79]

Im not saying it to be insulting, i am saying it because its true... to think this would work shows a fundamental lack of understanding of FPGA tech.

[throAU]

Im not saying it to be insulting, i am saying it because its true... to think this would work shows a fundamental lack of understanding of FPGA tech.

Not everybody here will have a fundamental, or necessarily ANY understanding of FPGA tech.

You can educate others in a positive manner or a negative one. Try to be positive.

[cinar]

First things first, I admit it was a silly way that was way too easy to be true. I at least knew the binary thing, one doesn't work on the other etc. and I am a newcomer to FPGAs. They are both Cyclone V (Vamp = 5CEFA5, Nano = 5CSEBA), and I thought they were also in the same family of Cyclone V just with different part numbers because the first letters were the same but apparently CE and CS turned out to be completely different families. I see that it is a jic file, it doesn't come before rbf, so can't be converted but I didn't know that, they weren't many resources about jic files. As I recall it was a silly attempt. I was fed up with 020 core and seeing another Cyclone V could do better than 060, I desperately tried to find an easy way that no one ever thought before. I guess lots of people did it. I ended up spending all my savings on a CS060mkI CV3D/64 4000 and I am happy more than ever. It hasn't arrived yet, but when it does, I surely will have my Mister connected to the same peripherals with KVM.


There is a blog article by FPGAArcade stating DE10-nano was the faster one.

https://www.fpgaarcade.com/replay2-vamp ... no-mister/

[lordoftime79]

I think we all want faster on the minimig core - not sure why no one has done it!

[ByteMavericks]

There is no better 68k implementation available: there’s long discussions around this. The 68080 core from vampire isn’t available, it’s closed. There might be an option from Mike’s fpgaarcade work when that’s complete and people are working on offloading cpu to the arm side.

All of these things are seriously non trivial amounts of work. The 68060 has a transistor count of 2.5 million: that’s the level of complexity that would need replicating in the fpga. The 68020, by comparison, has less than 10% off the 060 with a transistor count of 190k…

Those are some of the reasons it’s not been done, which I’m sure have been discussed here many times. It takes pretty intense study of the existing chip to understand how to implement, and a deep understanding of how to get the best out of fpga architecture. If you have the skills and time - I am missing both of those! - roll your sleeves up and get stuck in.

Another alternative would be to incentivise the Apollo team to release their 080 implementation. Given the years of effort put into that, it won’t be trivial either.

Good luck if you choose to move forward with any route.

[cinar]

I think the best would be a shield or dock where you put your own 060 like the FPGArcade that might also help Falcon emulation. Or Apollo releasing the core generated for 5CSEBA. But both of those don't seem possible.

[lordoftime79]

Why not just make the 68020 faster?

[robinsonb5]

Why not just make the 68020 faster?

Of course! <slaps forehead> Why did none of the devs think of that already?!

Seriously, though - even doing that would be decidedly non-trivial.
Off the top of my head, to make the 68020 faster you'd "just" need to pick some items from this list:
* Make the pipelines deeper so that the slowest operations are split into more stages.
* Add branch prediction, to offset the penalty of having to flush those deeper pipelines when execution flow changes
* Add at least one extra execution unit, an issue queue and dispatcher
* Add register renaming to reduce hazards and stalls.
* Probably a few other things which I've forgotten.
None of those would be remotely easy to "bolt on" to the existing design - it would be more like starting from scratch.

Basically, we're talking months if not years of work - and for what? For games the Amiga core is more than good enough already. OK maybe a bit more speed would be nice for productivity software, but the core as it stands is certainly on a par with or better than what most people had in the 90s.
Maybe running '060 demos would appeal to some people - but personally the moment demos became about using the Amiga as a dumb framebuffer I lost interest - if that's the computer's only contribution then why write it for the Amiga instead of the PC in the first place?

[Bas]

A bigger 68k CPU would be an enabling step for systems other than classic Amiga. I do agree that the effort would be huge.

[lordoftime79]

Why not just make the 68020 faster?

Of course! <slaps forehead> Why did none of the devs think of that already?!

Seriously, though - even doing that would be decidedly non-trivial.
Off the top of my head, to make the 68020 faster you'd "just" need to pick some items from this list:
* Make the pipelines deeper so that the slowest operations are split into more stages.
* Add branch prediction, to offset the penalty of having to flush those deeper pipelines when execution flow changes
* Add at least one extra execution unit, an issue queue and dispatcher
* Add register renaming to reduce hazards and stalls.
* Probably a few other things which I've forgotten.
None of those would be remotely easy to "bolt on" to the existing design - it would be more like starting from scratch.

Basically, we're talking months if not years of work - and for what? For games the Amiga core is more than good enough already. OK maybe a bit more speed would be nice for productivity software, but the core as it stands is certainly on a par with or better than what most people had in the 90s.
Maybe running '060 demos would appeal to some people - but personally the moment demos became about using the Amiga as a dumb framebuffer I lost interest - if that's the computer's only contribution then why write it for the Amiga instead of the PC in the first place?

I didnt mean in such a complicated manor - I was thinking of just changing the clocks to higher frequenceys.

[robinsonb5]

I didnt mean in such a complicated manor - I was thinking of just changing the clocks to higher frequenceys.

Unfortunately we're not free to just use whatever clock frequency we feel like. At every clock tick the registers in the core latch their new values, which have travelled from other registers through logic gates such as 'and's, 'or's, adders, multipliers and multiplexers - and this takes time. If the next clock pulse comes before the signals have all finished propagating and become stable then the CPU stops working. The longest, slowest path between registers places an upper limit on the achievable clock speed and to increase clock speed beyond that point one would need to break up the slowest paths into multiple sections, thus adding extra pipeline stages.

[kolla]

There are ways the Linux/ARM side can be usefull also without CPU emulation, but rather through interfaces. For example media decoding, faster networking, audio via AHI, even video playback (overlay, pip) and “remote” programs over X11 or RDP.

(Some these can easily be implemented already, using fifo pipes on the shared filesystem)