Overview Features Instructions Performance Forum Downloads Products Reseller Contact

Welcome to the Apollo Forum

This forum is for people interested in the APOLLO CPU.
Please read the forum usage manual.
VISIT APOLLO IRC CHANNEL



All TopicsNewsPerformanceGamesDemosApolloVampireCoffinReleasesLogin
The team will post updates and news here

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

Vincent Rivière

Posts 85
01 Nov 2016 22:39


And to finish this trip around the Atari usage of 680x0, here is some information related to the OS.

Amiga users may wonder why actual CPU type, format of exception stack frames matters for Atari people. I will give you my own subjective vision of things. Other people may complete this list if necessary.

When the Atari ST was released in 1985, it was fine. A 68000 CPU, and a simple but nice operating system, suitable for most tasks.
For the OS API, Atari chose to use the "trap" instruction to call the main OS layers. Mainly: trap #13 for BIOS, trap #14 for XBIOS, and trap #1 for GEMDOS. This was a a good choice, as trap handlers execute in supervisor mode, and as I/O registers can only be accessed from supervisor mode. But they also chose to pass parameters *on the trap stack*, which caused trouble on later processors.

As you know, the 68010+ exception stack frame is different from the 68000 one: it contains an additional format word (it is even worse on ColdFire). So, depending that the the CPU is a 68000 or a 68010+, inside the trap handler, the parameters are not located at the same offset. Not a huge problem, as this situation is correctly handled by the TOS itself. The caller code stays identical.

But problems occur when TSR programs want to extend the OS. The only way to do that is to hook the trap handlers, and jump to a special implementation for some values of the parameters. But depending on the CPU type, the offset of those trap parameters change. As a result, any TSR hooking the OS must known the actual CPU type.

At startup, the TOS detects the CPU, and puts the result in the _CPU cookie (some kind of global variable). Then user programs can use that value to know the actual CPU. And determine the right offset of trap parameters. This is one usage of the actual CPU type.

Another issue is cache management. Even if Atari correctly managed the instruction/data cache inside the TOS when the 68030 appeared (TT and Falcon), no new API was introduced to invalidate/flush the caches from user programs. It is a problem, because every time you read a file containing executable code, you need to flush the data cache and invalidate the instruction cache. The only solution is to detect the actual CPU via the _CPU cookie, and to use the right assembler instructions to manage the caches. Of course, this is automatically managed by TOS when loading standard executables. But there are other files containing programs. For example, old Mad Max soundchip musics were actually a mix of 68000 code and music data (and this became a standard). Loading and playing such music invariably requires manual cache management.

Another usage, much more uncommon, is to determine the actual CPU type to know how to program the MMU. AFAIK, only the FreeMiNT kernel does this (but probably also some hacky programs).

So you have seen a few reasons why, IMHO, the actual CPU type is important for Atari people:
- unfortunate choice of passing arguments on stack for trap calls
- missing cache management API

That being said, clean and standard user programs absolutely don't care about the actual CPU. Clean Atari programs compiled for 68000 work fine on any CPU, ans will do on 68080.


OneSTone O2o

Posts 159
02 Nov 2016 09:40


Notes to Vincent:

1. Cookies are not present in TOS 1.00, 1.02, 1.04, until an additional tool is placed in the AUTO folder to create them. Cookies only have been introduced with TOS 1.06 (STE), 2.0x (MegaSTE and addoncard for ST) and 3.0x (TT). Also Falcon TOS 4.0x, EmuTOS and MiNT creates the cookie jar.  Details about cookies at EXTERNAL LINK 
2. TT uses PMMU to mirror VME bus adress space in two base adresses, one in 24 Bit adress room, and one in 32 Bit adress room. (Gunnar has Profibuch to see the base adresses of VME and more details about this)

(Note: Also in standard ST there is a chip called "MMU", but this one is just a more or less thumb jar of TTL logics to manage/access/refresh DRAM, it's more or less a simple memory controller, and it contains some support logics for the shifter graphics chip)


Vincent Rivière

Posts 85
02 Nov 2016 12:31


We have covered most of the special usages of 680x0 on Atari hardware. Finally, what could be a problem for an Apollo Core inside Atari computer? Hmmm... nothing :D

1) ROM mirror stuff is not mandatory. The Vampire bootrom can just jump to the ROM entry point, that will be enough.

2) Correct Bus Error handling is necessary for the initialization routines of stock TOS >= 1.2 (Blitter detection?) and EmuTOS, but that could easily be patched if necessary.

3) Line F usage would conflict with future Apollo FPU, this would be a problem to run TOS <= 1.4. But in that case, the bootrom could detect such TOS and just disable the FPU. Problem fixed.

Here is the situation.

So, go ahead, hardware developers! Do your job to bring the Apollo Core to Atari machines, then the OS will run.


Gregthe Canuck

Posts 272
02 Nov 2016 12:39



Vincent thanks for helping the team with your generous knowledge-dump. :)

I learned a lot about Atari machines from your information.


OneSTone O2o

Posts 159
02 Nov 2016 13:56


There is a lot of hardware and OS documentation about ATARI online. For example:
  - dev-docs has a very complete collection of circuit diagrams and also a lot of original developer documentations, add on hardware manuals and so on: EXTERNAL LINK  - additionally a bit more: EXTERNAL LINK  - toshyp, a html converted hypertext TOS documentation, available in english and german: EXTERNAL LINK (it's not uptodate regarding emulators, no Hatari, no Aranym)
  - Profibuch ST, STE, TT, the german ATARI bible, unfortunatelly Falcon is not included: EXTERNAL LINK  - Compendium: EXTERNAL LINK  - Wikis: EXTERNAL LINK http://wiki.newtosworld.de/
  - ST internals documentation from 1995 EXTERNAL LINK  and much more where you can get help


Vincent Rivière

Posts 85
03 Nov 2016 14:18


About FastRAM:

Old TOS programs are not aware about FastRAM. This is because FastRAM was introduced later with Atari TT. To avoid breaking the compatibility with *some* old programs, Atari chose to not use the FastRAM by default. Such programs usually require ST/Chip-RAM capabilities, for example to use direct hardware access to disk DMA, Blitter, or just setup a second screen for double buffer. But this is very marginal, most programs (particularly Amiga-compatible TOS programs) can work without any trouble in FastRAM.

Fortunately, Atari executables can easily be flagged to use FastRAM. The simplest way is to open the executable (*.PRG...) with an hexadecimal editor. Go to offset $19, and replace byte $00 with $07. Then the program will be automatically loaded into FastRAM when run.

As all caches are disabled for Chip RAM with Apollo Core, and fully enabled for FastRAM, I predict a *huge* speedup of benchmarks when run from FastRAM.


OneSTone O2o

Posts 159
03 Nov 2016 14:46


There are also little tools to enable the TT-RAM-Flag in PRG files, so no need to use hex editor. There is for example setflags which can do that EXTERNAL LINK   
  Besides Quickindex you also should run GEMBENCH, this seems to be more realistic. Download version 4.04 from forum: EXTERNAL LINK and version latest ver 6 update from EXTERNAL LINK


Olivier Landemarre

Posts 59
03 Nov 2016 19:30


Another bench is Kronos, it is probably the most accurate bench on Atari when computer start to be fast because evaluation is done on constant time not constant loop. It not do only CPU, FPU, memory test etc.. as most bench but try to do some a bit more realist test with small software openGL test. Can work on any system from TOS B&W to mutitask in true color.

EXTERNAL LINK 
should work


Vincent Rivière

Posts 85
07 Nov 2016 10:12


Another special 68000 feature used on Atari computers is user-vector interrupts. AFAIK Amiga doesn't use that.

The video HBL and VBL use standard auto-vector interrupts. This will not cause trouble.

But all other interrupts are handled by an external MFP MC68901. When an interruption occurs, the MFP notifies the 68000 and provides its own exception vector number. This way, instead of using standard interrupt vectors at addresses $64 to $7c, MFP interrupts use vectors from $100 to $13c.

This is not going to cause any trouble, if the Apollo Core is really compatible. But it is worth to say.

More detailed information about interrupts on Atari ST can be found there:
EXTERNAL LINK


Amiten Store

Posts 24
09 Nov 2016 14:44


Hi guys,

Awesome Stuff , please continue the great Job!

I´m reading and stay tune on this implementation of Vampirised ST line in what I can test/help i will notify here.

@Gunnar the best luck for implement this
@Simo Koivukoski  Congratulations for the nice advances
and the rest for his contributions

Cheers!


Christian Z

Posts 7
12 Nov 2016 12:27


Christian Z wrote:

In the German atari-home.de forum, OneSTOne mentioned that he had been told that a Vampire had already booted TOS 2.06 to the desktop. That's good news, obviously, so I'm surprised this wasn't posted here as well. (Or did I miss a post?) Can you please provide more details -- or even a video?

Sadly, no comments on this question from two weeks ago.


Vincent Rivière

Posts 85
17 Nov 2016 18:42


EmuTOS 0.9.7 has just been released, it is the first Atari-like operating system with official support for Apollo Core 68080.
EXTERNAL LINK 
Even if this already works fine on Amiga, I can't wait to see that on Atari machines!


OneSTone O2o

Posts 159
17 Nov 2016 20:00


Merci beaucoup, Vincent, c'est super!!! On advance, je suis tres content. :)


Martin Soerensen

Posts 227
18 Nov 2016 08:00


Vincent Rivière wrote:

EmuTOS 0.9.7 has just been released, it is the first Atari-like operating system with official support for Apollo Core 68080.

Didn't it run on 68080 before or does that mean that it now utilizes some of the new instructions in the 68080 for a speed boost?
Any video of it in action?


Vincent Rivière

Posts 85
18 Nov 2016 10:03


Martin Soerensen wrote:

Didn't it run on 68080 before

Previous EmuTOS versions run well on Apollo.
On old cores, it was detected as 68020, due to a core bug.
On new cores, it was detected as 68060, as the core has all special registers.
Anyway, this was just a matter of identification: it worked fine and fast in every case.

In the new EmuTOS 0.9.7, the Apollo Core 68080 is properly detected and displayed on the welcome screen. Internally, it is handled just as if it was a 68040, as it was advised by the team.

Martin Soerensen wrote:

or does that mean that it now utilizes some of the new instructions in the 68080 for a speed boost?

No, it is not currently the case. But as the 68080 is now properly detected, its new features could be used later for something useful.


Jo Even

Posts 1
20 Nov 2016 20:15


Gunnar von Boehn wrote:

Roman S. wrote:

The problem with new design MMU is, that no old software knows how to use it.

 
  Yes that is the point of it.
  That old software SHALL not use it!

While that approach might make sense on the Amiga (I'm not very familiar with "modern" Amigas) it's very unfortunate on the Atari.

The dominant OS on powerful Ataris is FreeMiNT, and FreeMiNT use the MMU for memory protection. This means that each process only has access to it's own memory, which improves stability a lot.

The lack of memory protection on the Firebee is the main reason why I'm not using my Firebee anymore, but the considerably less powerful Milan060 and Falcon/Afterburner. I would ask you to please reconsider your strategy on the MMU. FreeMiNT currently supports the 030, 040 and 060 MMUs. Having a 040 MMU in the 68080 would therefore make the 68080 core a lot more usable in the Atari.


Markus (mfro)

Posts 91
27 Dec 2016 08:04


jo even wrote:
... The lack of memory protection on the Firebee is the main reason why I'm not using my Firebee anymore, but the considerably less powerful Milan060 and Falcon/Afterburner. I would ask you to please reconsider your strategy on the MMU. FreeMiNT currently supports the 030, 040 and 060 MMUs. Having a 040 MMU in the 68080 would therefore make the 68080 core a lot more usable in the Atari.

I'm not really familiar with the inner workings of the 68080, so I apologize upfront if the following statements are wrong, but would assume that an MMU would probably badly hurt the 68080's performance.

It's speed is limited by the achievable clock rates of current FPGAs, so its forced to gain as much as possible from pipelining (pre-process pipeline-length upcoming instructions from the instruction stream in parallel). The Apollo team apparently did pretty good on this already as they achieved a speed of more than one instruction per clock on average.

This requires predictive instruction streams. Everytime you decide to pre-process the wrong instructions upfront because you mispredict a branch or because the processor has to do exception processing, you get at least a pipeline stall or even the double penalty of a complete hazard (needing to "clean" and rebuild the pipeline from start with lots of addidional clock cycles).

An MMU (causing regular page faults) would probably add lots of complexity to the core since you needed to incorporate it's impact into pipeline processing, otherwise you'd potentially lose a lot of performance with every fault causing a hazard.
 


Account Sold.
(Needs Verification)
Posts 219/ 2
30 Dec 2016 01:34


Markus (mfro) wrote:

would assume that an MMU would probably badly hurt the 68080's performance.

Yes, that is very much my impression as well. The lack of an accessible MMU also makes the AC 68EC080 a lot less attractive to me, even as Amiga user, it means Vampire can never replace my existing 030+ systems.


Gunnar von Boehn
(Apollo Team Member)
Posts 4017
03 Jan 2017 21:12


Markus (mfro) wrote:

I'm not really familiar with the inner workings of the 68080, so I apologize upfront if the following statements are wrong, but would assume that an MMU would probably badly hurt the 68080's performance.

We have an MMU...



Markus (mfro)

Posts 91
03 Jan 2017 21:47


Gunnar von Boehn wrote:

Markus (mfro) wrote:

  I'm not really familiar with the inner workings of the 68080, so I apologize upfront if the following statements are wrong, but would assume that an MMU would probably badly hurt the 68080's performance.
 

  We have an MMU...
 

... and this MMU does what, exactly?

posts 159page  1 2 3 4 5 6 7 8