Apollo Team announces developing of Vampire standalone version to run as AMIGA and ATARI ST

[joska]

I thought the majority would be also interested in the graphics part of this FPGA card, but there I'm mistaken. One wants overclocked CPU to feel power and manhood, but not be at ease with a colorful and large screen?

How did you get that impression? For sure, there's little point in having a superfast (relatively speaking) 68000 with stock graphics.

[vido]

I thought the majority would be also interested in the graphics part of this FPGA card, but there I'm mistaken. One wants overclocked CPU to feel power and manhood, but not be at ease with a colorful and large screen?

Problem here is the frame rate, and all this PAL/NTSC switching on the 100% compatible cores.

You can have a 4K display, but then you would have to go for EmuTOS, or, whatever, leaving the compatibility route ...

This is what I cant get it! Who cares about hardware compatibility with such CPU power?!? I want big desktop with a lot of colours and good GEM software and Hatari ported for old games compatibility. Rajah is coding new (GEM) software to utilise new posibilities and that route I like to see new hardware and software development. I like to play OpenTTD, ScummVM, 2048, DGEM, ... and other ported software together with Papyrus X, NetSurf, PHGmap, ...
I like to see new productions utilise such power.
For compatibilit I use MiST. But I dont care about games much anyway. For that I have Jaguar

[joska]

You can have a 4K display, but then you would have to go for EmuTOS, or, whatever, leaving the compatibility route ...

Not sure what you mean here... A 4k display is incompatible with the shifter, regardless of what TOS or TOS-replacement you run.

[joska]

This is what I cant get it! Who cares about hardware compatibility with such CPU power?!? I want big desktop with a lot of colours and good GEM software ...

There is a reason why I don't use my Milan060 for everything. You want a certain level of hardware compatibility. You want a graphics card that supports the same interleaved bitplanes as the shifter, and the same 8- and 16-bit modes as the Videl. You want an YM, an MFP and a 1772 to allow the surprising amount of "serious" software that access these directly to run correctly.

[ex68k]

You can have a 4K display, but then you would have to go for EmuTOS, or, whatever, leaving the compatibility route ...

Not sure what you mean here... A 4k display is incompatible with the shifter, regardless of what TOS or TOS-replacement you run.

If you leave the compatibility route, you can make you own shifter implementation ...

[joska]

If you leave the compatibility route, you can make you own shifter implementation ...

You are talking nonsense. There is a point between 100% compatible and 0% compatible. You make it sound like "nothing" will work as soon as the CPU speed is modified or *optional* graphics modes are made available.

Of course you attempt to preserve as much compatibility as possible. The more original hardware you leave in the more compatible. An ST with a Vampire (fast 68000, RAM, ROM and graphics card with shifter and Videl modes) will be very close to 100% compatible with a stock ST when running "productive" software, 40-80% compatible when playing games (depending on whether you're playing originals or HD/Falcon adapted versions) and almost 0% compatible when watching demos. The key is of course that as soon as the CPU speed deviates even the slightest from the stock ST then 98% of all demos fails. Does that mean that accelerators are pointless?

A Vampire is of great interest to me, because it will not only run "productive" software faster but will also do it with the comfort of a larger screen. My Milan can already do that, but a Vampire will be a *lot* more compatible with existing software. It will even be a lot more compatible in general than my Falcons.

[vido]

There is a reason why I don't use my Milan060 for everything. You want a certain level of hardware compatibility. You want a graphics card that supports the same interleaved bitplanes as the shifter, and the same 8- and 16-bit modes as the Videl. You want an YM, an MFP and a 1772 to allow the surprising amount of "serious" software that access these directly to run correctly.

Here I agree with you. But those arent features where you need cycle exact CPU. That are features needed to run "clean" coded Atari software (mostly GEM software). On Milan I miss only Videl Compatible modes for very small amount of the software.

[BlankVector]

The key is of course that as soon as the CPU speed deviates even the slightest from the stock ST then 98% of all demos fails.

A faster CPU is only a problem for code which :
- use the CPU slowness for frame synchronization
- use exact CPU timings to do things inside a frame (open borders...)

The situation with a faster CPU can easily be checked with Steem: Options > Machine > ST CPU speed.

- Demos not doing overscan just work fine.
Example: Flip-O-Demo

- Games/Demos doing overscan or sync scroll does not display correctly
Example: Enchanted Land

- Games not using frame VBL synchronization become unplayable because far too fast
Example: Prince of Persia

- Games using the CPU slowness for gameplay will become significantly faster
Examples: Bubble Bobble, Back to the golden age

- Games with proper frameskip keep the same speed and become smooth
Example: Saint Dragon

So the situation is not so bad.

For new software, if programmers care just a bit, they can easily take advantage of more CPU speed.

[ex68k]

If you leave the compatibility route, you can make you own shifter implementation ...

You are talking nonsense. There is a point between 100% compatible and 0% compatible. You make it sound like "nothing" will work as soon as the CPU speed is modified or *optional* graphics modes are made available.

You misunderstood what I was trying to say. Let's try again:

If you don't need the 100% compatibility, you are free to do with the "shifter", whatever you like, expand it, improve it, whatever.
And you are also free, to do whichever resolution on your screen you like ...

[joska]

But those arent features where you need cycle exact CPU.

That is exactly my point. There really is only one thing you break with a CPU that's not a cycle exact 8MHz replica of the 68000, and that's border-busting/syncscroll stuff. And that means demos. Almost everything else will just work, but faster. Yes, there will be trouble with games too. Some may run too fast, some use synctricks. That's the price you pay for compiling your project in seconds instead of hours

[christos]

The ct60 breaks almost every falcon/st game and demo there is. But it works with most GEM apps (some of them break too, signum comes to mind). Most accelerators that change the cpu will have that effect. They are not for game/demo usage, but for GEM usage. The only problem I see with the vampire as a GEM machine is a statement I once read, that they don't emulate uncommon 68k instructions. If that statement is true then it can break a lot more programs then we expect because an uncommon instruction might be used only once in a program, but if it doesn't exist it will break it. The Firebee adds a compatibility layer in software to fight this. But if that is also needed for the vampire, it kind of defeats the purpose.

[joska]

The ct60 breaks almost every falcon/st game and demo there is. But it works with most GEM apps (some of them break too, signum comes to mind). Most accelerators that change the cpu will have that effect. They are not for game/demo usage, but for GEM usage.

That's because the 060 is quite different from the 68000. Missing instructions, cache, different PMMU than the 030, different FPU and most importantly different stackframe than the 68000. The Vampire is basically a 68000 with additional features, so it should be a lot more compatible than the 060.

The only problem I see with the vampire as a GEM machine is a statement I once read, that they don't emulate uncommon 68k instructions.

The Apollo team has stated that the CPU-core used in the Vampire implements all 68000 instructions.

[1st1]

You can have a 4K display, but then you would have to go for EmuTOS, or, whatever, leaving the compatibility route ...

Not sure what you mean here... A 4k display is incompatible with the shifter, regardless of what TOS or TOS-replacement you run.

Vampire has integrated graphics chipset (graphic chipset is the thing which takes some system memory for bitmap graphics and outputs it throuh a connector to the monitor). Vamipre's graphics chipset is called "SAGA" (comes from Super AGA, AGA is the chipset of Amiga 1200) which is able to emulate Videl (that is the graphics chipset of Falcon 030) and even "SuperVidel". Emulate means: The Apollo team has only to implement (Super)Videls hardware registers for video mode settings and so on and then SAGA is (Super)Videl compatible. That means if they implemented that you only need to load SuperVidel VDI and you see a desktop in high resolution. And besides this, it can handle all tricks of Amiga AGA graphics (like copper blitter and so, one olnly need to write VDI driver for this), so it could bring Amiga graphics capabilities to GEM. SAGA and SuperVidel can handle Full HD resolution (which is 1960 x 1280 in 24 bit colour, that is 16 million colours).

So with vampire you have besides a fast like hell processor also a graphics card which makes forgetting the good old shifter. I think this combination makes a lot of sense, specially for modern GEM applications.

I hope, this was not too much information at once.

[ex68k]

SAGA and SuperVidel can handle Full HD resolution (which is 1960 x 1280 in 24 bit colour, that is 16 million colours).

Typo, right? Full HD is 1920x1080, WUXGA is probably better on the desktop (which is 1920x1200) ...

[1st1]

There is a reason why I don't use my Milan060 for everything. You want a certain level of hardware compatibility. You want a graphics card that supports the same interleaved bitplanes as the shifter, and the same 8- and 16-bit modes as the Videl. You want an YM, an MFP and a 1772 to allow the surprising amount of "serious" software that access these directly to run correctly.

Here I agree with you. But those arent features where you need cycle exact CPU. That are features needed to run "clean" coded Atari software (mostly GEM software). On Milan I miss only Videl Compatible modes for very small amount of the software.

Vampire/Apollo discussion is not about cycle exact CPU. Vampire/Apollo discussion is about a very fast code compatible 68000 replacement with enhanced graphics capabilitys. (It's even planned to implement a soundcard in the Vampire, the requred analoge audio output signals already seems to be there, but no VHDL logics behind it yet.)

Ps: Also Falcon, TT, Mega STE (in 16 Mhz mode), Milan, Hades, Eagle, Firebee are not ST-68000-8 cycle exact.

I think everyone who is only interested on original ST/STE games and demos is out of this discussion.

[1st1]

SAGA and SuperVidel can handle Full HD resolution (which is 1960 x 1280 in 24 bit colour, that is 16 million colours).

Typo, right? Full HD is 1920x1080, WUXGA is probably better on the desktop (which is 1920x1200) ...

It is a typo, but maybe even these resolutions are supported.

[1st1]

The ct60 breaks almost every falcon/st game and demo there is. But it works with most GEM apps (some of them break too, signum comes to mind). Most accelerators that change the cpu will have that effect. They are not for game/demo usage, but for GEM usage. The only problem I see with the vampire as a GEM machine is a statement I once read, that they don't emulate uncommon 68k instructions. If that statement is true then it can break a lot more programs then we expect because an uncommon instruction might be used only once in a program, but if it doesn't exist it will break it. The Firebee adds a compatibility layer in software to fight this. But if that is also needed for the vampire, it kind of defeats the purpose.

Here is the complete list of instructions which are supported by Apollo core: http://www.apollo-core.com/index.htm?page=instructions

Please make a list of missing rarely used instructions which you miss and forward the list to Apollo team with some explanation for what it is used (popular software trick, application name, etc.) on ATARI computers. Please note that our friends on the other side (Amiga) didn't miss anything yet, and Amiga OS 3.x is using a lot of instruction what Coldfire can't execute. (Gunnar told me that Apollo FPU misses some instructions like to calc tangens function, they didn't implement because it needs 400 clocks in original FPU and it is possible to get the same result with other code in less than 300 clocks, so nobody uses these slow FPU operations)

Firebee has this compatibility layer, but that is very very slow, and there seems to be other problems as well (not open source licence of the compatibility layer, or something like this?).

If you forward such informations to the Apollo team, that is the kind of help they have requested (see my initial post). Everybody interested in Apollo in ST will be very appreciated if you do. Thanks in advance.

Here for example you can post such experience, they will read: http://www.apollo-core.com/knowledge.ph ... 2&z=zqORnA (and look, vincent riviere already posted a lot, also czietz and mfro, good guys!!!)

[Cyprian]

Please make a list of missing rarely used instructions which you miss and forward the list to Apollo team with some explanation for what it is used (popular software trick, application name, etc.) on ATARI computers.

What about Line-A? Is it implemented or not?

[1st1]

Every undefined instruction also produces an exception on Apollo core. Check the instructions list if any of them uses $A... or $F... opcode and you are done. As EmuTOS works on Apollo core (booted on Amiga 2000), this might already be the answer. Anyhow, Line-A functions are only usable for the 3 original ST screen resolutions. If you have an Apollo you have higher screen resolutions. Also TT does not use Line-A except of presence for compatibility with old applications. On modern ST like computer with high resolution graphics and fast CPU who cares on Line-A for ST-Low/Med/High resolution?

[Frank B]

Vampire/Apollo discussion is not about cycle exact CPU. Vampire/Apollo discussion is about a very fast code compatible 68000 replacement with enhanced graphics capabilitys.

It's very fast in the same way a pentium 120 is very fast. Faster than an 060 yes but not a modern chip. More like circa 1996.

[Frank B]

Every undefined instruction also produces an exception on Apollo core. Check the instructions list if any of them uses $A... or $F... opcode and you are done. As EmuTOS works on Apollo core (booted on Amiga 2000), this might already be the answer. Anyhow, Line-A functions are only usable for the 3 original ST screen resolutions. If you have an Apollo you have higher screen resolutions. Also TT does not use Line-A except of presence for compatibility with old applications. On modern ST like computer with high resolution graphics and fast CPU who cares on Line-A for ST-Low/Med/High resolution?

Lina-A is used on the TT for high, medium and low.

[1st1]

Vampire/Apollo discussion is not about cycle exact CPU. Vampire/Apollo discussion is about a very fast code compatible 68000 replacement with enhanced graphics capabilitys.

It's very fast in the same way a pentium 120 is very fast. Faster than an 060 yes but not a modern chip. More like circa 1996.

It's faster than any other ATARI compatible hardware, that's enough.

[1st1]

Every undefined instruction also produces an exception on Apollo core. Check the instructions list if any of them uses $A... or $F... opcode and you are done. As EmuTOS works on Apollo core (booted on Amiga 2000), this might already be the answer. Anyhow, Line-A functions are only usable for the 3 original ST screen resolutions. If you have an Apollo you have higher screen resolutions. Also TT does not use Line-A except of presence for compatibility with old applications. On modern ST like computer with high resolution graphics and fast CPU who cares on Line-A for ST-Low/Med/High resolution?

Lina-A is used on the TT for high, medium and low.

http://toshyp.atari.org/en/006001.html

In the TT030 the Line-A functions are present only for the sake of compatibility.

Line-A is not a requirement for an acellerated ST running at Full-HD resolution.

http://dev-docs.atariforge.org/files/Th ... endium.pdf

in chapter 1.8

LINE-A is the only operating system component that has become out of date and incompatible. Atari recommends that software developers avoid using LINE-A as it will be supported less and less as hardware advancements make its use more incompatible. LINE-A is documented briefly in this reference for completeness.

in chapter 8.3

The Line-A system is included in this document for completeness only. It is recommended that its use be avoided and that the counterpart VDI calls be used instead. Atari has not guaranteed that it will maintain Line-A compatibility in future systems. Its functionality has already been limited as video capabilities have advanced beyond its design

ATARI Profibuch about Line-A, page 305/306

Die A-Opcodes dienen hingegen zum Aufruf der wichtigsten Grafikroutinen - man kann also sagen, daß die Line-A-Routinen auf Maschinenebene die Befehle eines imaginären Grafik-Chips emulieren. Die Architektur des Betriebssystems spricht allerdings eindeutig gegen die Benutzung der Line-A-Routinen. Diese stellen nämlich die untere Ebene des VDI-Bildschirmtreibers im ROM dar. Mit ihrer Verwendung verbaut man sich also eine eventuelle Nutzung eines anderen (schnelleren) Bildschirmtreibers!

Auch ist eine Existenz der Line-A-Routinen nur für die ST-Modi (also 320 * 200, 640 * 200 und 640 * 400) garantiert. Schon bei 256-Farbgrafik (spezielle Grafikkarte bzw. TI in der
"niedrigen" Auflösung) sind die Möglichkeiten der Line-A-Schnittstelle erschöpft (siehe "COLBITO" bis "COLBIT3").

(...)

Es spricht also alles gegen die Verwendung der Line-A ~ R o u t i n e n . Wer will schon Programme haben, die bei Hardwareänderungen oder neuen Rechnern dank der Verwendung von L i n e ~ A-Routinen nicht mehr funktionstüchtig sind?

Zitat aus den TI030 TOS Release Notes: "Tbe Line-A graphics interface is maintained for backward compatibility with existing ST programs only. It should not be used for new programs. It will not keep pace with future hardware or software improvements. Tbe VDr should be used." Also: Finger weg von den Line-A-Routinen, wenn es sich nicht gerade um ein systemnahes Progrannn handelt, das sowieso nur auf den drei Standard-Grafikmodi des ST funktionieren.

It says: Line-A is limited to ST-Low, ST-Med and ST-High, even on TT. It recommends to not use it as other graphics modes and graphics card do not support Line-A.

To my understanding this means: Forget Line-A. It's old ST-style, untidy programming. Use VDI calls. With Apollo core we want NEW style ATARI. No Line-A. Do you understand?

[Frank B]

[
To my understanding this means: Forget Line-A. It's old ST-style, untidy programming. Use VDI calls. With Apollo core we want NEW style ATARI. No Line-A. Do you understand?

No. I think you misunderstand. Think about this. Think of an ST app running in an ST mode on the TT that uses Line A and not the VDI.
What happens if the line a interface isn't there? The app stops working properly in ST modes. Compatibility suffers. I'd also be amazed if TOS 1.x to 2.x would work without the linea interface. BTW the Line A is actually more flexible than the VDI in some ways!

[Frank B]

Vampire/Apollo discussion is not about cycle exact CPU. Vampire/Apollo discussion is about a very fast code compatible 68000 replacement with enhanced graphics capabilitys.

It's very fast in the same way a pentium 120 is very fast. Faster than an 060 yes but not a modern chip. More like circa 1996.

It's faster than any other ATARI compatible hardware, that's enough.

But you are setting expectations that it will match a modern chip! It won't. A pentium one will clobber it speed wise.
Please be realistic.