Overview Features Coding ApolloOS Performance Forum Downloads Products Order Contact

Welcome to the Apollo Forum

This forum is for people interested in the APOLLO CPU.
Please read the forum usage manual.
Please visit our Apollo-Discord Server for support.



All TopicsNewsPerformanceGamesDemosApolloVampireAROSWorkbenchATARIReleases
The team will post updates and news about our project here

Running ATARI On 68080page  1 2 3 4 5 6 7 8 

Gunnar von Boehn
(Apollo Team Member)
Posts 6207
17 Oct 2016 19:46


Thanks for the reset vector post. :)
 
 
The behavior of blending the Vector0/1 into address 0/4 is the same on AMIGA and ATARI.
Also both AMIGA and ATARI use the same address range for their ROMs.
 
 
 
 
To give you an overview what the Vampire 500 currently includes
 
 
Apollo 68080 CPU  (100% 68K compatible)
Apollo fully supports _EVERY_ CPU instruction of the 68000/68010/68030/68040/68060
 
Apollo 68080 supports _ALL_ 68000/68020/680x0 Ea-modes.
 
Apollo 68080 supports selfmodify code operations.
So code doing this which worked fine on 68000, but fails on 68030/68040 .. can work again on 68080.
 
Apollo 68080 can max execute up to four 68k instruction per clock cycle.
In Amiga benchmarks the Vampire scores like an 68060 @100-160 MHz
 
It obvious that APOLLO 68080 is very fast, sometimes for running ancient games the best compatibility comes when running slower.
We test right now a user-selectable "turtle-mode" which allows running e.g Games in a aspeed much closer to original.
 
 
Vampire2 comes with 128 MB fastmem (memcopy speed ~ 300 MB/sec)
 
The Vampire2 includes a FAST-ATA IDE-controller, with peak 16 MB/sec. In AMIGA HD benchmarks we measured up to 13 MB/sec peak doing real transfers.
 
The Vampire2 includes an SD-Card interface for easy data-exchange.
 
The Vampire2 has digital Video out - SAGA.
Which support many different GXF modes
Up to 1920x1080 with up to 24/32bit per pixel.
 
I had a quick look on the ATARI ST GFX Chip.
Its nice to see how simple it is in design.
Adding this our SAGA will be very easy for us.
 



OneSTone O2o

Posts 159
17 Oct 2016 20:27


Yes, the ST GFX chip is simmple (and bitplane based). Please take care that DMA transfers (floppy, harddisk) can be done directly into video memory, so some chips on the ST mainboard must be able to adress the memory (the lower 4 MB) on the turbo card) If you want to do something spectacular, then integrate new video modes with higher resolution. You can do it in the same way as shifter (I think MiST already does it with a special ST core), or try to contact the SuperVidel guys. See EXTERNAL LINK for details. With that you can enhance an ST to Falcon's graphics capability at up to FullHD res. But this would need TOS patches and extra memory. Years ago I also have read about a VHDL core which is compatible to Tseng ET4000 VGA chipset. There are vdi-drivers for ST for this solution. ET4000 was integrated in ST by a simple 68K bus to ISA converter, there were different of these adapters (Vova, Nova ET4000, ...) just using different base adresses.

I think the first step would be that you get a desktop and can run some benchmarks in originbal resolution. After that, with enhanced graphics, IDE support (TOS 2.06 or EMuTOS required) and so on you would need support by the ATARI community. There are several specialists. But my impression is that they jump on the running train only if you can present some first successfull results.

Besides the MiST ST cores you should also have a look onto Suska. EXTERNAL LINK , check also the suska folder in the download section.


OneSTone O2o

Posts 159
17 Oct 2016 20:34


Additional question about the Apollo Core:
  - does it support MMU as 68030++?
  - quite interesting would also be integration of 68882
 
  (Note to above: Many parts of the Suska design also has been used for the Firebee, but this is based on Coldfire. But I think you know it, there seems to be a loose contact between you and them.)


Daniel Sevo

Posts 299
17 Oct 2016 22:16


oneSTone o2o wrote:

Additional question about the Apollo Core:
  - does it support MMU as 68030++?

No, but it has something similar:
CLICK HERE 
oneSTone o2o wrote:

  - quite interesting would also be integration of 68882

The current goal (I think) is a fairly accurate implementation of the 040FPU. Lots of stuff in 68882 is almost never used by any relevant software or already handled by software math libs.
It would mostly be a waste of FPGA space to try to recreate the 68882 in its entirety, and of course, its a very complicated chip. (Both 040 and 060 had simplified FPUs and yet for all relevant purposes they ran faster. (I used to render a lot in Imagine 3D and the move from 030+882@50MHz to 060@50MHz was something like 5 times faster.)Pretty much all software that required FPU was at some point optimized for the 040 FPU...




Myzar Alcor

Posts 27
17 Oct 2016 22:27


you're playing with the vampire a500 with a st, but the vampire a600 fits the ste is that right?

EXTERNAL LINK


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
17 Oct 2016 23:38


oneSTone o2o wrote:

  Additional question about the Apollo Core:
    - does it support MMU as 68030++?
 

  Apollo has its own MMU.
  It has more/partly other features than 68K MMU.
 
  As you certainly know previous 68k CPUs had 1 bus.
  Apollo is different.
  Like some DSP designs APOLLO supports using 2 buses fully in parallel. This more advanced bus design also requires a different MMU.
 
 
 
oneSTone o2o wrote:

    - quite interesting would also be integration of 68882
 

68882 is a quite old and very slow FPU design.
 
APOLLO has an 68k compatible FPU which is fully pipelined - and is much more advanced then even the 68060 FPU.
 
APOLLO's FPU is fully code compatible to 68K FPUs.
The FPU is currently under testing.
 
 


Amiga 4Life

Posts 101
18 Oct 2016 06:05


Gunnar von Boehn wrote:

    It obvious that APOLLO 68080 is very fast, sometimes for running ancient games the best compatibility comes when running slower.
    We test right now a user-selectable "turtle-mode" which allows running e.g Games in a aspeed much closer to original.
 

thank you...
whats most important for me is compatibility with Workbench apps,legacy ports,Zii/Ziii bus and
Paula...Temporarily losing compatibility with ocs/esc/aga games in order to gain speed on the
desktop is the best mode (imo)..... Thats what RTG was all about, redirecting the OS calls
  to a faster/bigger gfx card...this mode is for productivity apps...



OneSTone O2o

Posts 159
18 Oct 2016 08:10


As long as the FPU is 68882 enough binary compatible that's Ok. There is not so much software on ST using the FPU, except of "TT only" software which is quite rare. Some DTP, CAD, scientific software and so can use it.
 
About MMU your target must be that it's software compatible to 68K MMU because MiNT can use the MMU for memory protection and so. As soon you boot an MiNT 68030 Kernel it uses this MMU. (It's also possible to use 68000 MiNT kernel, but with a lot of disadvantages).

Linux 68K and NetBSD 68K also could be a topic for MMU and FPU. Both OS are not very commonly used on ATARI but this might change with such a turbo card.
 
Anyhow your project is looking very promising, looking forward to an ST versions which will put anything elese in it's shadow.

One more thing about graphics: Another graphics mode which should be quite easy to support is the so called "Viking card" for Mega ST system bus. That was a graphics card directly from ATARI, well known for it's ECL monitor SM-194, 19 inches, 1280x960 monochrome. Same resolution also on TT ("TT high resolution") with integrated ECL mode chipset. You should find everything about it in Profibuch.
 
@Amiga 4Life: I understand you, but this is the ATARI thread. CPU is the same but the rest is slightly different.


Methanoid UK

Posts 1
18 Oct 2016 18:15


I assume the Vampire STE would come first since the STE uses PLCC 68000 same as A600 and I believe the STE sold more units than the other STs?


OneSTone O2o

Posts 159
18 Oct 2016 19:12


There are many more standard ST than STE. The STs were sold from 1985 until maybe 1991. STE was sold from late 1989 to about 92. Additionally there is also the Mega-STE with 16 MHz and some hardware addons (mainly new interfaces), and Mega STE is the base of Falcon (see Sparrow prototype as 1st step towards Falcon)
   
    Unfortunatelly STE came quite late. But a vampire for it would need some different core as ST, because of the enhanced graphics chip (more colors, scrolling), also the ST(E) blitter is a must as many STE software is using it even if the 68080 will be much faster. (This blitter is even available in Falcon for compatibility issue). If you need to reconstruct the ST(E) blitter, the full circuit diagram of it recently has been recovered. On that website you also see the full circuit diagram of the so called "blossom" graphics chipset used in ATARI Transputer Workstation ATW 800 and abandonned ATARI game console "Panther". EXTERNAL LINK There is also the opinion that Falcon's graphics chip Videl is based on a reduced Blossom. Blossom with its 64k color palette crys about to be realized in VHDL. The author of that website is present here in the forum, I have seen a hand full of his postings.

By the way, about ST-Shifter graphics chip. It might not be so easy to fully reconstruct by your own, because there are some software tricks to make things with shifter which originally it is not capable to do, like more than 16 colors (up to 512), overscan and tricky hardware scrolling. The overascan for example is done by tricky and rapid switching between color and mono mode at the right moments to confuse the pixel drawing counter. Before to try to make it at your own, look for the MiST ST core, it does it quite well.


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
18 Oct 2016 19:57


Let us try to answer some open questions
and explain some facts which might not be obvious.

APOLLO 680080 is a very long time planned project.

The development on Apollo is continues since over 8 years now.
All the features of Apollo were planned long time ago and we are executing this plan.

This means our developments,  also on features which might not be announced yet, is going on since very long time.

Apollo is currently about 10-20 times faster than "other" FPGA-68K cores.
According to Mac Emulator developers like Jim Drew, Apollo is  the only FPGA 680x0 Core which is fully compatible to allow execution of MAC OS - all other FPGA cores fail on this.

Also if you look at features like the FPU - you have to mind that there is an development effort of several years behind this.

Its of course very easy to "wish" for something here in the forum. But you have to realistically see that the Apollo team will continue to finish the planned and already started tasks.

And even simple stuff like an 68K compatible MMU might only need a few month to develop - if we work on other already started tasks - we will not just pop in 3 month of work for an MMU for little benefit to the whole community.

All developments need to make sense.
And frankly we have a have a todo list for the next year already.

Regarding the ATARI.

That the Vampire card fit physically well into the ATARI is nice. This means we can provide Vampire to ATARI fans for not that much effort.

Which means that the ATARI fans could get easy access to most compatible 68k FPGA core and the worlds most advanced 68K CPU.

That the original Video logic is very simple in design - could allow us to include it into SAGA for only few days of work.
It might be that Videl and SAGA have a lot in common and that making SAGA look to ATARI like Videl is also very simple.

But this does not mean that we plan to include whole ATARI/FALCON designs now.
We might at some point - but do not hold your breath for this.

So if you want to use the Vampire in ATARI and want to help develop driver etc - we will welcome this.

We are also working on several new hardware cards.
Also we will bring out a Light weight Natami (tm) very soon.
Here the addition of a complete ATARI chipset might make a lot of sense.



Brian Robotham

Posts 52
19 Oct 2016 00:40



  I am trying to find an Atari so i can take a look at the physical dimensions of it (them) in order to try to make some form of adapter to make the Vampire fit in the awkward locations the cpu is in on some moterboards, if i have any luck i will post news


Ingo Uhlemann

Posts 35
19 Oct 2016 09:29


Thanks for your feedback.
 
  I am very happy that you do this great stuff. I will talk for the Atari Community, that its a millestone for it and every step what we do is the right step.
 
  Maybe you Know Wolfgang Förster, he created a full implementation of all Atari Custom Chips in VHDL
 
  EXTERNAL LINK   
  He has a lot of work done, maybe you could participate from his work.
 
  I am a Hardware developer too, still working on a Video/USB Card for the Atari TT at the moment. If you need some help, i will trie to help where i can. Also i am in direct contact to the Pak68/3 developer. He is a great man and he is also able to patch Tos to fix some problems. Maybe he is open to help.
 
  Best Regards Ingo


Petari Peter

Posts 3
20 Oct 2016 16:07


I'm one of those who likes 68000 ASM. so still doing some SW in it. Beside that did lot of Atari ST game adaptations, patches to make them work on Falcon, TT, from mass storage.
68080 seems fascinating. But I want to clarify some things tight now in my first post here.

"Apollo fully supports _EVERY_ CPU instruction of the 68000/68010/68030/68040/68060"
"So code doing this which worked fine on 68000, but fails on 68030/68040 .. can work again on 68080"

There are some details to clarify:  is it possible to set 68080 to specific CPU mode ? Because there are differences in stackframe, in reading SR, for instance. Then, self modifying code - concrete code, what modifies very close ahead - some of next 3-4 following instructions - what I called pipeline bug - because fails on 68030. So, in possible 68000 mode it should not use pipeline, or should be able to modify content of it :-)
Is there full PMMU of 68030 support ?
Is there possibility to slow it down on speeds  of real 68000 at some 8 MHz ? Some 68030 at 16 ...  ?
And worst question: what about cycle accuracy ?

As you may see, questions are most compatibility related.
Thanx ahead.



Gunnar von Boehn
(Apollo Team Member)
Posts 6207
20 Oct 2016 17:36


Hallo Peter,
 
Petari Peter wrote:

  I'm one of those who likes 68000 ASM.

Nice, so do we ;-)
 
Petari Peter wrote:

 
Gunnar wrote:

  "Apollo fully supports _EVERY_ CPU instruction of the 68000/68010/68030/68040/68060"
  "So code doing this which worked fine on 68000, but fails on 68030/68040 .. can work again on 68080"
 

 
 
  There are some details to clarify:  is it possible to set 68080 to specific CPU mode ?
 

Not at the moment.

You have to mind that APOLLO 68080 was designed
to run Software for AMIGA/MAC/ or maybe ATARI-FALCON like.
None of such software depends on an NOP taking exactly 480 ns.

So for us this was never a sensible requirement.
The CORE as it works now - works perfectly for AMIGA and MAC OS.

For some legacy games on ATARI-ST there is maybe a slightly different need. For applications of course the NOP can be any speed - so here APOLLO 68080 can open new horizons.
And there might be ATARI developers which like to develop /test /ports software now. And that the Vampire physically fits in some ATARI as of today already will allow this now.

 
 
Petari Peter wrote:

  Because there are differences in stackframe,
 

Apollo is used in AMIGA and MAC as 68040.
Therefore it offers the same stackframe as 68040
 
 
 
Petari Peter wrote:

  in reading SR,
 

Yes Apollo, DOES ALLOW reading of SR in user-mode.
 
 
 
Petari Peter wrote:

  for instance. Then, self modifying code - concrete code, what modifies very close ahead - some of next 3-4 following instructions - what I called pipeline bug - because fails on 68030.
 

This will also fail on Apollo in normal speed mode of course.
This is just the by the nature of a pipelined CPU.

But there is a fix - to also enable this.
 
Saying this.
There are 2 types of selfmodify.
A) Accidental selfmodify like done in a DOS loader.
Apollo is supporting this. And such code works fine.
B) On purpose - next instruction selfmodify like in a copy protection. Here is depends a lot if this code is executed with enabled caches / or loaded first time etc. This code might work or not. You can force it to work with "turtle" Switch.

 
 
Petari Peter wrote:

  So, in possible 68000 mode it should not use pipeline, or should be able to modify content of it :-)
 

Yes when we run in "turtle mode" ~ 68000 Speed.
Then even pretty dirty copy protection like self modify can work.
 
 
 
Petari Peter wrote:

  Is there full PMMU of 68030 support ?
 

We have our own MMU design with more/other features.
68030 MMU compatibility is not planned atm.
There are good technical reasons why a old style 68030 MMU is not sensible atm.
 
 
 
Petari Peter wrote:

  Is there possibility to slow it down on speeds  of real 68000 at some 8 MHz ? Some 68030 at 16 ...  ?
 

Yes, we are currently testing a new "turtle mode" which does slow down.

Actually for our "market" this is not that important.
AMIGA Software or MAC software is _NOT_ depending on this.

I assume generally that ATARI applications and all FALCON and Firebee Software will also not depend on this.

 
 
Petari Peter wrote:

  And worst question: what about cycle accuracy ?
 

 
Apollo is about 200 times faster than 68000.
With the "turtle mode" we can lower the speed,
and optionally also create bus-cycles on the slow memory bus
to sync us down to 68000 like behaviour.
 
This makes us cycle accurate for some instructions.
E.g NOP takes 4 original 68000 cycles then.
 
But its NOT cycle accurate for all instructions and so far NO effort was taken in this regard - is we did not need it so far.

I think you can not eat the Cake and still have it.
If you want fast applications like DIVX video playback.
Or like browsing the internet and watching Youtube videos.
Then at the same time taking exactly 6 clocks for a ADD.L - does
  not work..

APOLLO will in the 1st place offer you speed and excellent instruction compatibility.
It will of course not be as slow as the original.

Cheers


OneSTone O2o

Posts 159
21 Oct 2016 08:49


I think cycle exact is not a must. You can still have a 2nd ST with original 68000 CPU to use that kind of old software. Mainly this software is doing dirty tricks to make things on the ST(E) which it normally is not capable of doing because of hardware limitation. These cycle exact tricks are things like opening the screen borders (overscan) by cycling 50/60 to 70 Hz screen frequency and back for a short moment while the screen is drawn what confuses the shifter so much that it forgets that next thing would be border frame to draw, instead it continues to draw pixels with user content, the border is open. There are many tricks like this, also for more than 16 colors at one time, digital sound on the Yamaha and they need exact timing. Such things don't work on a 68020, 68030, even if they are slowed down to 8 Mhz and/or cache disabled. I don't see a must have here on Apollo Core.

The more interesting is to accelerate MiNT / Magic / Debian68K /NetBSD68K OSses and their applications on an ST, like Photoline, Calamus 2015, Cubase, ideally together with some enhanced graphics (STE, TT, Falcon, Viking; SuperVidel, ET4000 modes), and maybe add STE-DMA-Sound or even Falcon Sound to a standard ST. Making something what turns any ST into something what can compete with Firebee or even PC.
 
Looking forward to this.
 
Question and offer: I have all kinds of ST machines, 260ST, 520ST, 520ST+, 520STFM, 1040STFM (early and later models with different board layouts), Mega 1, Mega 2, Mega 4 (early and later models with different board layouts) and Stacy. If I would have an 1:1 model of a Vampire 500 card, I can check if it fits mechanically in these. Maybe not Stacy as it is a lot of work to open this. The thing can be a dummy, printed on paper, just the correct size, height, thickness and so.


Petari Peter

Posts 3
21 Oct 2016 13:17


I think that there was misunderstanding about "specific CPU mode".
I meant not some speed, cycle counts there, but as said different execution if some instructions, interrupts. Like mentioned SR reg. read, then stackframes. There is lot of SW doing diverse stackframe tricks, and it is for 68000 6 byte stackframe. Will crash on CPU with 8 byte stackframe. Regardless of speed.

Right, cycle accuracy is not relevant in most of SW. But I just went thru with my questions related to compatibility with old SW.

I think that considering oldies, more people will be interested to have some reliable clone, what will replace now very old and problematic machines, instead of some huge speed, what is still pretty bad in compare with new computers, smarties. Although may be that some think not so - well, that was my impression watching Majsta's presentation at YT.


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
21 Oct 2016 13:32


Petari Peter wrote:

  but as said different execution if some instructions, interrupts. Like mentioned SR reg. read, then stackframes
 

 
  APOLLO 68040 behaves 100% like an Motorola 68040.
 
All 68040 instructions are supported.
 
Stackframe is like 68040.
Including the 040 F-trap stackframe.
 
The behaviour of instruction is like on 68040.
 
Flags of instructions are set, exactly like on 68040.
 

So 68080 does primary behave like an 68040.
Of course the 68080 does add on top some new enhancements.
Like for example the AMMX instructions - which 68040 or course did not support.



Thierry Atheist

Posts 644
21 Oct 2016 15:03


Petari Peter wrote:
I think that considering oldies, more people will be interested to have some reliable clone, what will replace now very old and problematic machines, instead of some huge speed, what is still pretty bad in compare with new computers, smarties. Although may be that some think not so - well, that was my impression watching Majsta's presentation at YT.

Hi Petari,

Could you try rewording what you wrote in the underlined part. I don't quite understand what you are saying.


Petari Peter

Posts 3
21 Oct 2016 19:21


Thierry Atheist wrote:

Petari Peter wrote:
  Although may be that some think not so - well, that was my impression watching Majsta's presentation at YT.

  Hi Petari,
  Could you try rewording what you wrote in the underlined part. I don't quite understand what you are saying.

Watch this:  EXTERNAL LINK 


posts 159page  1 2 3 4 5 6 7 8