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 

Thierry Atheist

Posts 644
22 Oct 2016 07:10


Oooohhh.

Okay, so, you're saying that "compared to TODAY'S available computers, an Apollo Core AMIGA is slow. However, the people in the video, well, they don't really care about what 'today's computers' can do compared to a REALLY REALLY fast AMIGA, but nonetheless, slow compared to what someone could easily buy at any store down the street".

I am TOTALLY in that boat too.

Combine the unbloated OS and LEAN AND MEAN TIGHT coding.... It really goes a long way to delivering unbelievable performance!


Roman S.

Posts 149
22 Oct 2016 13:42


Gunnar von Boehn wrote:

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.

What about 68040 MMU? AFAIK it is simplified... The problem with new design MMU is, that no old software knows how to use it.


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
22 Oct 2016 13:47


Roman S. wrote:

Gunnar von Boehn wrote:

  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.
 

 
  What about 68040 MMU? AFAIK it is simplified... 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!

You have to mind that our MMU can control the memory controllers.
Your old software would not be aware of this - and you would and with a not working system.




Manuel Jesus

Posts 155
23 Oct 2016 13:57


Quote:
"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. "

This ought to be done. I think many Amiga users secretly salivated over the Falcon. An expanded Falcon-esque type system on a bog standard ST would be pretty Amazing and TUG at the heart strings of old Atari fans.



Ingo Uhlemann

Posts 35
24 Oct 2016 06:31


I think, all this could be possible but all step by step. The first step is to bring the cpu core working, next step is bugfixing and integrate Alternate memory, and when this is working the core could extend to integrate Video output.

Let the developers do there job guys ;)

Ingo


Captain Zalo

Posts 71
24 Oct 2016 07:01


Being able to vhdl-program a system from Amiga Everything to equivalent Atari Falcon Droolness and back would expand the market and community for the Vampire/Apollo standalone. Having a bootable SD card slot for OS would and internal sata slot for speed would make the platform futureproof too. I'm excited for what the future brings (back).


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
24 Oct 2016 07:19


Captain Zalo wrote:

Being able to vhdl-program a system from Amiga Everything to equivalent Atari Falcon Droolness and back would expand the market and community for the Vampire/Apollo standalone. Having a bootable SD card slot for OS would and internal sata slot for speed would make the platform futureproof too. I'm excited for what the future brings (back).

The Vampire and the new standalone offer bootable  IDE/CF slot and SDcard slot. SATA connector is not directly on the board but SATA drives can be used with inexpensive SATA to IDE adapters.



Captain Zalo

Posts 71
24 Oct 2016 08:16


Great news, Gunnar. Thanks for the update.


Alan Haynes

Posts 140
25 Oct 2016 05:07


Captain Zalo wrote:

Great news, Gunnar. Thanks for the update.

Ditto from me


Simo Koivukoski
(Apollo Team Member)
Posts 601
26 Oct 2016 08:41


EmuTOS running with Vampire 500 V2 on an Amiga 2000:
 

 


Vincent Rivière

Posts 87
27 Oct 2016 21:09


I couldn't be more happy than seeing EmuTOS running out of the box on Vampirized Amiga, moreover with these nice scores :-)


Vincent Rivière

Posts 87
27 Oct 2016 22:09


Ok. You want to make the Vampire cards compatible with Atari hardware. Here are the issues you will face.

1) Form factor
As I understand, Vampire cards are plugged on the CPU slot. I'm not a hardware guy, but other people reported that the various Atari computers have very different mainboard layouts. Including several very different revisions among same series. Some people accept to extract the mainboard and put it into a different case in order to fit additional boards. Some don't.

2) Fast CPU on Atari
Again, I'm not an hardware guy. But people reported that RAM access was tightly interleaved between CPU, Shifter (video), DMA (ACSI hard disk + floppy) and STe digital sound. I don't know what would happen with a faster CPU, probably dreadful wait states. There are hardware hacks on ST to run the 68000 at 16 MHz (instead of 8), I don't know what are the side effects. This RAM speed issue only affects the ST-RAM (similar to Amiga Chip-RAM). Unfortunately, there is no other RAM type on stock ST.
The situation is certainly better with Falcon 030. Accelerator cards up to 68060@100MHz (or more) are available, most popular being CT60/CT63. I can't speak personally about Falcon 030, as I don't know much about it, but for sure a lot of Atari people could provide very valuable information about it.

3) Run TOS (Atari OS) on better CPU
ST/STe comes with TOS 1.x, which only supports plain 68000. Using any higher CPU (with 68010+ exception stack frames) would require patching.
Mega STe comes with TOS 2.06: it supports 68010+ CPU, and it is compatible with the whole range of ST/STe. I have very poor knowledge about that TOS version, but once again other people know it very well.
Falcon 030 comes with TOS 4.04, it is compatible with 68030 only.
Here is where interesting things occur. Accelerator cards with 68040 or 68060 patch that TOS to make it compatible with their CPU. Those patches are well known by Falcon hackers.
The Hatari and ARAnyM emulators (both Free Software) also patch TOS 4.04 to allow it running with 68040. Newer Hatari also supports 68060.

That being said, the easiest way to start debugging the Atari+68080 hardware is to use EmuTOS as ROM OS. EmuTOS has explicit support for 68000/68010/68020/68040/68060, and even ColdFire V4e. Recent tests shown that EmuTOS for Amiga worked fine on Amiga hardware with Vampire cards, as expected (I had already debugged CPU issues with WinUAE). Once the hardware is debugged thanks to EmuTOS, efforts could be made to patch Atari TOS for 68080 (for people preferring Atari TOS to EmuTOS).

Beware of one pitfall: Bus Error.
Unlike Amiga, Atari hardware issues a Bus Error exception when software tries to read or write at an invalid address (pointing to neither RAM, ROM, or I/O). This Bus Error mechanism is extensively used by EmuTOS on Atari to autodetect the presence of optional hardware. Any accelerator card for Atari must implement that Bus Error feature, otherwise EmuTOS auto-detection mechanism will fail, resulting in wrong initialization. Of course, as EmuTOS is Free Software, that Bus Error stuff could be completely disabled at compile time.

My feeling is that, if hardware is OK, it will be a piece of cake to run EmuTOS on Atari+68080. To run Atari TOS on it, it will require more or less patching (depending on TOS version), but Atari hackers know how to do that.


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
27 Oct 2016 23:26


Salut Vincent

Vincent Rivière wrote:

Ok. You want to make the Vampire cards compatible with Atari hardware. Here are the issues you will face.

 
Yes I think as Vampire seems to fit in some ATARI.
Allowing ATARI users to use the Vampire/68080 as Accelerator would be nice.

For testing compatibility and or testing some ATARI applications, also running EMUTOS in an Vamparized-Amiga makes good sense.

Vincent Rivière wrote:

  1) Form factor
  As I understand, Vampire cards are plugged on the CPU slot. I'm not a hardware guy, but other people reported that the various Atari computers have very different mainboard layouts.

You are right.
But as far as I saw in some 1040 and 520 the cards fit already.

Vincent Rivière wrote:

  2) Fast CPU on Atari
  Again, I'm not an hardware guy. But people reported that RAM access was tightly interleaved between CPU, Shifter (video), DMA (ACSI hard disk + floppy) and STe digital sound. I don't know what would happen with a faster CPU, probably dreadful wait states.

You are correct of course - as long the software runs physically in the old ATARI memory - the speed up will not be maximal.
The Vampire comes of course with on board memory.
Running applications from this will result in faster speed.

Vincent Rivière wrote:

  3) Run TOS (Atari OS) on better CPU
  ST/STe comes with TOS 1.x, which only supports plain 68000. Using any higher CPU (with 68010+ exception stack frames) would require patching.
  Mega STe comes with TOS 2.06: it supports 68010+ CPU, and it is compatible with the whole range of ST/STe. I have very poor knowledge about that TOS version, but once again other people know it very well.
  Falcon 030 comes with TOS 4.04, it is compatible with 68030 only.
  Here is where interesting things occur. Accelerator cards with 68040 or 68060 patch that TOS to make it compatible with their CPU. Those patches are well known by Falcon hackers.
  The Hatari and ARAnyM emulators (both Free Software) also patch TOS 4.04 to allow it running with 68040. Newer Hatari also supports 68060.
 
  That being said, the easiest way to start debugging the Atari+68080 hardware is to use EmuTOS as ROM OS. EmuTOS has explicit support for 68000/68010/68020/68040/68060, and even ColdFire V4e. Recent tests shown that EmuTOS for Amiga worked fine on Amiga hardware with Vampire cards, as expected (I had already debugged CPU issues with WinUAE). Once the hardware is debugged thanks to EmuTOS, efforts could be made to patch Atari TOS for 68080 (for people preferring Atari TOS to EmuTOS).

This is valueable information. Thanks!
We have only very small knowledge about TOS.
So guidance here is welcome.

Vincent Rivière wrote:

  Beware of one pitfall: Bus Error.
  Unlike Amiga, Atari hardware issues a Bus Error exception when software tries to read or write at an invalid address (pointing to neither RAM, ROM, or I/O). This Bus Error mechanism is extensively used by EmuTOS on Atari to autodetect the presence of optional hardware. Any accelerator card for Atari must implement that Bus Error feature, otherwise EmuTOS auto-detection mechanism will fail, resulting in wrong initialization. Of course, as EmuTOS is Free Software, that Bus Error stuff could be completely disabled at compile time.
 
  My feeling is that, if hardware is OK, it will be a piece of cake to run EmuTOS on Atari+68080. To run Atari TOS on it, it will require more or less patching (depending on TOS version), but Atari hackers know how to do that.

Thanks for the input.
This is something we just need to test.
Bus-Error handling should work - but it was never tested in real live as AMIGA does not throw it. So testing and if needed adjusting/correcting need to be done on real hardware.

We appreciate your feedback.
I think working with EmuTOS would be good.
Maybe you could join our IRC and help us to asnwer some more question?

Cheers
Gunnar


Christian Z

Posts 14
28 Oct 2016 07:38


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?


Vincent Rivière

Posts 87
30 Oct 2016 19:02


To run Atari computers with an Apollo Core 68080, I propose the roadmap below:

1) Make Apollo Core 68080 compatible with EmuTOS for Amiga (and reciprocally)
This way, it will be proven that the Apollo Core 68080 can run a TOS-like operating system. And this will be a foundation to run classic Atari programs on Apollo Core. Of course, not all Atari software will work, because:
- some software require Atari hardware
- some software require a specific CPU
- some software are incompatible with EmuTOS
- some software don't support monochrome video mode
But this will leave a lot of Atari software (mainly utilities) which should work fine. They will be good real-world testcases for the Apollo Core CPU.
Another big advantage of EmuTOS for this first task (instead of Atari TOS) is that EmuTOS already supports the whole range of 680x0 CPUs. And most of all: EmuTOS is Free Software and can be easily modified. Also, the EmuTOS development team (mainly me, for this task) wishes to officially support the Apollo Core.
This task is already well advanced.

2) Run an Atari Computer with Apollo Core 68080 and EmuTOS
First, it has to fit physically (Vampire Board?).
Then the CPU must support Atari-specific electronic constraints (clock sync with other devices, etc). I have no idea how to do that, but I fully trust the hardware team.
EmuTOS is a good choice as OS, because it is already compatible with most Atari computers, and (after passing step 1) it will also be compatible with Apollo Core. So the only possible issues at that time will be hardware issues, so hardware people will be able to focus on their task without any doubt regarding to the OS.
After that, it will be proven that an Atari computer can run with an Apollo Core. This is a crucial step, as it will demonstrate to Atari people that it is possible. And they will like that.

3) Run an Atari Computer with Apollo Core 68080 and Atari TOS
It is a fact that "real Atari hardware" users don't like EmuTOS very much. Even if EmuTOS embeds more and more features which were not supported by Atari TOS (IDE driver, support for big FAT16 partitions...), its desktop does not look exactly like Atari TOS. And it is currently graphically inferior to Atari TOS: no support for hardware blitter, and no support for Falcon truecolor mode. EmuTOS can be run from floppy, but this is not handy. And it wastes memory. On the other hand, replacing the ROM is not easy, and people don't want to lose their original TOS.
This is enough to keep most Atari users away. And most of all, some software are not compatible with EmuTOS. Either because they are badly written (use TOS version-specific internals, relocate to absolute addresses...), or because they need features not yet supported by EmuTOS (fewer and fewer, fortunately).
So basically, you will need to run Atari TOS (same version as the one present in the machine) in order to seduce Atari people.
- TOS 1.x present in ST/STe supports only 68000, it will need to be patched to support the Apollo Core 68010+ exception stack frame. Cache issues will also have to be considered.
- TOS 2.x present in Mega STe supports both 68000 and 68030.
- TOS 3.x present in TT supports 68030.
- TOS 4.x present in Falcon supports only 68030.
As I already said elsewhere, TOS 4.x has already been patched to support 68060 (for Falcon accelerator cards), so the issues are well known.
Note that except the exception stack frame issue in TOS 1.x, the only issue in higher TOS is cache management (which is different on every CPU model). As the Apollo Core transparently manages the cache, maybe there is no issue at all, and no patching required.
Another issue is MMU usage by TOS. I'm not an expert in that domain, but as far as I know the only useful usage is to mirror the $00ffxxxx address range to $ffffxxxx address range, when a 32-bit address bus is used. This is because ST software used to access the I/O ports with either $00 or $ff in the high byte. Do that in some way, patch TOS to avoid any MMU initialization, and both TOS and Atari software will be happy.

4) Add a hardware switch to either use the original CPU, or the Apollo Core. This way, you can make your add-on card completely transparent, so 100% of the software will continue to run, even hardcore games and demos. For turbo mode, the switch can enable the Apollo Core. Well-written software will take advantage of that extra speed, other ones will fail. Not a problem as they can still be run with the switch disabled.

Lots of explanation for not much tasks, finally.

Trust me: do all the above, then all Atari people will *need* your accelerator.


Vincent Rivière

Posts 87
31 Oct 2016 23:17


In order to help making the Vampire board compatible with Atari computers, here is some information which may not be obvious for Amiga users.

1) ROM mirror at addresses 0 to 7
On Amiga, at startup, the ROM is located at address $00fc0000 and mirrored at address 0. When powered on, the 680x0 picks up the entry point at address 4 (mirror of $00fc0004) and starts running the code at the address indicated there (usually $00fc00d2). Then the RAM is initialized, and mapped to address 0 (removing the ROM mirror). Then the OS continues booting. It is worth to notice that on Amiga, after initial startup, the addresses 0 and 4 are normal RAM. This is particularly important for AmigaOS, as applications retrieve the Exec Base from address 4.

On Atari machines, that address 0 stuff is sensibly different. There is no memory remapping in early initialization. Instead, the mapping is *permanently* done like this:
- ROM is mapped at $00fc0000 on ST/STf (192k), or at $00e00000 on STe and later machines (256k or 512k).
- RAM is mapped at address 0, with the exception below
- The first 8 bytes of RAM at address 0 are permanently shadowed and inaccessible. Instead, the first 8 bytes of the ROM are permanently mirrored at address 0. This is a key feature to understand the boot of an Atari computer.
So at startup, the CPU picks up the entry point at address 4. It will read the mirror of address $00fc0004 or $00e00004. Typical values are $00fc0030 or $00e00030. Then ROM execution will continue.

A side effect of this behaviour is that the RAM at addresses 0 to 7 is inaccessible for Atari machines. That would be a big headache if some people would try to implement AmigaOS on Atari machines, as the address 4 is not writable.

2) Bus Error on invalid address
On Amiga, accessing an invalid address not mapped to any device (ROM, RAM, or I/O port) has no effect.
On Atari, this causes a Bus Error exception (well known "2 bombs").
Usually, this Bus Error is a hint for software bug. Very few user programs use that feature to do something useful.
An exception is EmuTOS (for Atari) initialization routines. As EmuTOS can support many different hardware, it autodetects hardware at startup. The obvious way to detect optional hardware is to try to access its I/O registers. If a Bus Error occurs, the hardware is missing. Otherwise, it is present.
AFAIK, Atari TOS does not exploit the Bus Error feature. At least, not as much as EmuTOS. But some hacky user software might use that for hardware autodetection, too.
Note that EmuTOS could also be compiled to completely disable optional hardware. In this case, no Bus Error is triggered at all.

3) Bus Error when accessing I/O ports from user mode
On Amiga, all the I/O ports can be accessed from user mode.
On Atari, I/O ports can only be accessed from supervisor mode. Any attempt to access I/O ports from user mode cause a Bus Error. This is quite a nice feature, as normal user programs can't erroneously trash the I/O ports.

4) Bus Error when writing to ROM
On Atari, trying to write to the ROM causes a Bus Error. This is also true for the ROM mirror at addresses 0 to 7. A side effect of this hardware feature is that a bogus supervisor program trying to write to a NULL pointer will crash instantly.

5) Bus Error when accessing the $000 to $800 area in user mode
On Atari, that low memory is not accessible to user programs. This way, the CPU vectors as well as extended vectors ans OS variables are protected against bogus programs. This way, any user program trying to read or write through a NULL pointer will instantly crash. This is a nice debugging feature.

6) FastRAM
On Atari computers, the FastRAM is always mapped at $10000000. It is only available on TT and some accelerator cards. The actual size is detected by testing 1 byte every megabyte until a Bus Error occurs.

7) I/O ports are located at both $00ffxxxx and $ffffxxxx
With a 24-bit address bus, this is a side effect. But as many software access the hardware using either $00 or $ff as MSB, this must be explicitly enabled on 32-bit address bus. AFAIK, this is done by TOS by using the MMU. But it could be transparently done by the Core.

Finally, I realize that the process to boot an Atari or Amiga ROM is very similar:
- read the entry point at ROM offset 4
- mask out with $ffff0000 to get the expected ROM address
- map the ROM to that address
- mirror the ROM at address 0 (different between Amiga and Atari, see 1) )
- jump to entry point

That's enough for today.


Christian Z

Posts 14
01 Nov 2016 09:08


Atari TOS also makes use of the bus error to detect hardware, though not as much as EmuTOS. (It doesn't have to detect that many different hardware configurations.)

Consider for example the following code from TOS 2.06 very early startup that checks if running on an STE. Bus error will ensure that the flag (at $a02) is only set on an STE.

$00e00210 : move.l    #$e0024a,$0008.w
$00e00218 : clr.w    $ffff8900.w
$00e0021c : st        $a02

However, given that Gunnar has repeatedly stated that the "Apollo" core is 100% 68K-compatible, I think startup or bus error handling won't be an issue, or will it?

Another thing to add to the list of things to be aware of is maybe Line-A. I don't know if or how that's used on Amiga, but on Atari graphics primitives are accessible via CPU opcodes $A0xx, that cause the Line-A exception to be taken on the 68K.

Also TOS 1.0x makes extensive use of Line-F i.e. opcodes in the range of $Fxxx. This was dropped in TOS 2 and later to support FPUs. Since TOS 1 expects 68000-style short stack frames and thus won't run anyway, I don't think Line-F support is that important on Apollo, though.


Vincent Rivière

Posts 87
01 Nov 2016 10:24


Very true, Line-A and Line-F are also special Atari oddities. Note for people not familiar with that: it is about CPU opcodes in the form of $Axxx and $Fxxx. This is a 68000 feature: such opcodes triggers an exception (like trap), then the corresponding handler is executed in supervisor mode.

Line A: it is indeed used for low-level graphics primitives. A very common example is "dc.w $a00a" to hide the mouse pointer. Even if Line A is considered obsolete on newer TOS, the mouse example above is still very common. I'm not even sure that all Line A functionality has been superseded by something else.
This Line A issue was a headache on ColdFire, because it uses some $Axxx opcodes for new instructions (MAC unit). We chose to change the API, using different $Axxx opcodes, but breaking existing software.
EmuTOS provides the Line A API, just like Atari TOS.

Line F: It is said there (http://toshyp.atari.org/en/the_system_vectors.html) that it was used internally by GEM (graphical part) up to TOS 1.04 (in other words, used on ST/STf, then unused starting with STe). I don't know what these Line F routines were supposed to do, it is private internal GEM stuff.
It was a very bad choice from Atari to use that Line F API, because it conflicts with the FPU opcodes. Probably a reason why it has been changed later.
EmuTOS does not use Line F at all.


OneSTone O2o

Posts 159
01 Nov 2016 10:36


@Vincent, can you please send me PN in atari-forum.com? (User: 1ST1)


Christian Z

Posts 14
01 Nov 2016 10:59


Line F was Atari's way to squeeze TOS 1.00 - 1.04 into 192 kBytes of ROM. (You know how little space that is...) So instead of using a BSR or JSR, which needs four or six bytes, to call internal subroutines, they used $Fxxx opcodes (just two bytes) and a Line-F dispatcher. Note that even small code blocks like "RTS and clean-up stack" were replaced by $Fxxx opcodes.

However, this all was discontinued when Atari started using 256 kByte ROMs. So as long as the Vampire doesn't want to support TOS 1.00 - 1.04, possible conflicts with new instructions also in the $Fxxx range won't matter.

Does the Apollo core also use $Axxx opcodes for new instructions? I couldn't find an opcode reference for it.

posts 159page  1 2 3 4 5 6 7 8