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

Area for discussing ST(E) clones

Moderators: Mug UK, Zorro 2, Greenious, spiny, Moderator Team

OL
Captain Atari
Captain Atari
Posts: 395
Joined: Fri Apr 01, 2005 6:59 am
Contact:

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

Postby OL » Fri Mar 03, 2017 7:03 pm

BlankVector wrote:
1st1 wrote:Vincent has results of Kronos on his AMiga 500 with current EmuTOS and Vampire...

I didn't post that stuff myself here, as this runs on Amiga, and it is not (yet) related to Atari hardware.
My original post is on the Apollo Forum.

calimero wrote:What is MHz speed of Vampire CPU?

The CPU is Apollo 68080. Implemented inside Altera Cyclone III FPGA.
I'm not sure if we can really speak about MHz speed for FPGA stuff. Apollo / FPGA gurus could say more.

calimero wrote:and what is "Video" read/write in Memory test?

That's part of Kronos mysteries, OL should explain.


Hello I'm here to explain!

It is very simple there 3 video memory tests:
- read from video screen to TT ram (if available) with vro_cpyfm()
- write from TTRam to video screen with vro_cpyfm()
- read from video screen and write to video screen with vro_cpyfm() this is the photo display of the a french actress
OL

User avatar
Cyprian
Atari God
Atari God
Posts: 1395
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

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

Postby Cyprian » Fri Mar 03, 2017 9:41 pm

1st1 wrote:
Cyprian wrote:
1st1 wrote:
All these chips aleady have been syntetisized in VHDL. Look at MiST. Look at Suska. Look at Firebee.


nope you are wrong.


prove it...

MiST ATARI ST core is functioning and quite compatible
SUSKA also is working (never seen one by myself)
Frebee is also there, already seen some

So what is missing?

you are not able to prove that MiST or Suska has VIDEL/Combel emulation
you should know Firebee has no Combel emulation and Videl is buggy and very limited
also you should know emulation Shifter,MMU, GLUE, Yamaha is limited in MiST or Suska - isn't cycle exact.

Actually I'm waiting for Vampire for Atari.

And unfortunately, I have to say that you are discouraging people to this nice product.
Jaugar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
SDrive / PAK68/3 / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Aranym / Steem / Saint
http://260ste.appspot.com/

Faucon2001
Atari Super Hero
Atari Super Hero
Posts: 636
Joined: Sat Oct 26, 2013 11:19 pm
Location: Brasil
Contact:

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

Postby Faucon2001 » Fri Mar 03, 2017 10:23 pm

Falcon 56K DSP I guess.
If you know somebody who did it, it could be nice to send him to help the Firebee development.
Philippe

Firebee, Falcon, STE, Aranym Box, Hatari Pi Box.
My music http://www.philippeworld.net/
My photography http://phil-67.deviantart.com/
EasyAraMint, BeeKey and BeePi https://sites.google.com/site/emaappsarch/home

Sorgelig
Atari Super Hero
Atari Super Hero
Posts: 696
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

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

Postby Sorgelig » Sat Mar 04, 2017 1:03 am

1st1 wrote:What do you need?

to write emulator of other platform on Vampire, you will need a simple core source code where FPGA pins assignments and functions will be clearly visible.
Last edited by Sorgelig on Sat Mar 04, 2017 1:05 am, edited 1 time in total.

Sorgelig
Atari Super Hero
Atari Super Hero
Posts: 696
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

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

Postby Sorgelig » Sat Mar 04, 2017 1:04 am

del

User avatar
1st1
Atari Super Hero
Atari Super Hero
Posts: 662
Joined: Mon May 07, 2012 11:48 am

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

Postby 1st1 » Sat Mar 04, 2017 7:40 am

Cyprian wrote:you are not able to prove that MiST or Suska has VIDEL/Combel emulation
you should know Firebee has no Combel emulation and Videl is buggy and very limited
also you should know emulation Shifter,MMU, GLUE, Yamaha is limited in MiST or Suska - isn't cycle exact.

Actually I'm waiting for Vampire for Atari.

And unfortunately, I have to say that you are discouraging people to this nice product.


You can download the complete Combel VHDL code from Suska github. It's there.

And SUPER-VIDEL is completely VHDL.
Power without the Price. It's not a bug. It's a feature. _/|\_ATARI

1040STFM in PC-Tower (PAK68/2, OvrScn, 4 MB, 1GB SCSI, CD-ROM...) * 2x Falcon 030 32GB/14MB+ScrnBlstrIII * 2x TT030 73GB/20MB+Nova * 520/1040STFM * 520/1040STE * 260/520ST/+ * some Mega ST * 2x Mega STE 500MB/4MB+M.CoCo * Stacy * STBook * SLM605 * SLM804 * SLM605 * SMM804 * SH 204/205 * Megafile 30/44/60 * SF314 * SF354 * 5x Pofo * PC3

User avatar
mfro
Atari Super Hero
Atari Super Hero
Posts: 647
Joined: Thu Aug 02, 2012 10:33 am
Location: SW Germany

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

Postby mfro » Sat Mar 04, 2017 8:55 am

Guys, your arguments are starting to get more than ridiculous. Could you please get back to discuss facts rather than fiction?

Cyprian wrote:you should know Firebee has no Combel emulation and Videl is buggy and very limited

Yes, the FireBee doesn't have a 1:1 Combel implementation. But why should it (or any other modern design), actually?

Atari claimed the Combel would be the Falcon's "central system control". I'd rather say: it's the main culprit of the crippled Falcon design. Everything that didn't fit elsewhere has been thrown in there. You can basically say it's _the_ one chip that limits the Falcon's performance since it limits the design's capability to ST RAM only. I really wouldn't consider a "cycle exact Combel" something desirable for a modern design.

The FireBee has a 32 bit address bus to 32 bit wide DDR RAM providing 64 bit of data every 132 MHz cycle as opposed to the 24 bit address/16 bit data bus the Combel has at much slower speed. Why should anybody want to limit themself to the original? The Vampire's design is probably very similar except - at least to my knowledge - being limited to single data rate.

And yes, it's true the FireBee's Videl implementation still has some bugs that need to be fixed.
But what makes it "very limited"? All the Falcon registers are there, all standard Falcon/ST video modes are there. Additionally, you have 8 bit linear planes, 15 bit full colour and 24 bit true colour modes with freely programmable pixel clock and 128 Mbytes of fast video memory capable to do Full HD at reasonable refresh rate. What - except the Blitter that's not implemented yet (but not part of the Videl anyway) - are you missing?

Cyprian wrote:also you should know emulation Shifter,MMU, GLUE, Yamaha is limited in MiST or Suska - isn't cycle exact.

Probably true for the MiST, but not so for the Suska. But anyway, why does it matter? If you want to have a 1:1 Falcon replacement, it would. If you want a Falcon, go and get one, a real Falcon at real Falcon's speed is the most cycle exact replacement for a real Falcon. But just as slow as a real Falcon. You just can't stay cycle exact if you want more speed than the original.

Cyprian wrote:And unfortunately, I have to say that you are discouraging people to this nice product.

This, however, is sad, but very true.

1st1 wrote:You can download the complete Combel VHDL code from Suska github. It's there.

I've never seen a "Suska github". What's that supposed to be?
Can't resist on that one: "It's there. And it's great. You will love it".

1st1 wrote:And SUPER-VIDEL is completely VHDL.

That might be true, but I would assume it's something you can't know. To my knowledge, nobody except the SuperVidel team has ever seen the code.

User avatar
jvas
Captain Atari
Captain Atari
Posts: 437
Joined: Fri Jan 28, 2005 4:30 pm
Location: Budapest, Hungary
Contact:

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

Postby jvas » Sat Mar 04, 2017 2:15 pm

1st1 wrote:
Cyprian wrote:
1st1 wrote:
All these chips aleady have been syntetisized in VHDL. Look at MiST. Look at Suska. Look at Firebee.


nope you are wrong.


prove it...

MiST ATARI ST core is functioning and quite compatible
SUSKA also is working (never seen one by myself)
Frebee is also there, already seen some

So what is missing?


If you want a drop-in replacement, then all the pins/signals of the original processor must be present. This is not necessary the case in these implementations. Did you check that? You should also prove, that they can be used as-is.
Last edited by jvas on Sat Mar 04, 2017 2:17 pm, edited 1 time in total.

User avatar
1st1
Atari Super Hero
Atari Super Hero
Posts: 662
Joined: Mon May 07, 2012 11:48 am

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

Postby 1st1 » Sat Mar 04, 2017 5:18 pm

jvas wrote:If you want a drop-in replacement, then all the pins/signals of the original processor must be present. This is not necessary the case in these implementations. Did you check that? You should also prove, that they can be used as-is.


You are always search the hair in the soup. Why it must have all pins/signals, if all VHDL virtualized chips are flashed into one FPGA? Inside the FPGA a completely differernt bus interface is used. Compare for simple VGA modes like 800x600@256, you can have such Vesa mode on ISA card, on PCI card, on AGP card, on PCI-express, with the same software. The bus signal is not important, they are totally different between ISA, PCI, AGP, PCIe, but the software sees the same and you see the same result on monitor.
The only thing that is important is:
- the registers and memory must be seen on the correct adresses for the processor.
- these registers and memory must function the same way as in the original design
- the virtualized chips must return the same signals, like interrupts, back to the interrupt controller
That's it.
What's not important that is cycle exactness if you want to have a faster system, because then already the processor isn't cycle exact as it's faster. Cycle exactness is not modern programming.
Power without the Price. It's not a bug. It's a feature. _/|\_ATARI

1040STFM in PC-Tower (PAK68/2, OvrScn, 4 MB, 1GB SCSI, CD-ROM...) * 2x Falcon 030 32GB/14MB+ScrnBlstrIII * 2x TT030 73GB/20MB+Nova * 520/1040STFM * 520/1040STE * 260/520ST/+ * some Mega ST * 2x Mega STE 500MB/4MB+M.CoCo * Stacy * STBook * SLM605 * SLM804 * SLM605 * SMM804 * SH 204/205 * Megafile 30/44/60 * SF314 * SF354 * 5x Pofo * PC3

joska
Hardware Guru
Hardware Guru
Posts: 3503
Joined: Tue Oct 30, 2007 2:55 pm
Location: Florø, Norway
Contact:

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

Postby joska » Sat Mar 04, 2017 5:49 pm

1st1 wrote:Why it must have all pins/signals, if all VHDL virtualized chips are flashed into one FPGA?


Because it replaces the actual, physical CPU and needs to interface with the motherboard just like a real CPU?
Jo Even

Firebee - Falcon060 - Milan060 - Falcon040 - MIST - Mega ST - STM - STE - Amiga 600 - Sharp MZ700 - MSX - Amstrad CPC - C64

User avatar
1st1
Atari Super Hero
Atari Super Hero
Posts: 662
Joined: Mon May 07, 2012 11:48 am

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

Postby 1st1 » Sat Mar 04, 2017 9:25 pm

So it does only need a 68000 bus system towards the mainboard socket. All modelled chips inside the FPGA can talk to each other on any kind of interface what makes sense. The FPGA is a computer in the computer.
Power without the Price. It's not a bug. It's a feature. _/|\_ATARI

1040STFM in PC-Tower (PAK68/2, OvrScn, 4 MB, 1GB SCSI, CD-ROM...) * 2x Falcon 030 32GB/14MB+ScrnBlstrIII * 2x TT030 73GB/20MB+Nova * 520/1040STFM * 520/1040STE * 260/520ST/+ * some Mega ST * 2x Mega STE 500MB/4MB+M.CoCo * Stacy * STBook * SLM605 * SLM804 * SLM605 * SMM804 * SH 204/205 * Megafile 30/44/60 * SF314 * SF354 * 5x Pofo * PC3

User avatar
Cyprian
Atari God
Atari God
Posts: 1395
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

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

Postby Cyprian » Sun Mar 05, 2017 4:42 am

1st1 wrote:So it does only need a 68000 bus system towards the mainboard socket. All modelled chips inside the FPGA can talk to each other on any kind of interface what makes sense. The FPGA is a computer in the computer.


nope
Jaugar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
SDrive / PAK68/3 / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Aranym / Steem / Saint
http://260ste.appspot.com/

User avatar
1st1
Atari Super Hero
Atari Super Hero
Posts: 662
Joined: Mon May 07, 2012 11:48 am

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

Postby 1st1 » Sun Mar 05, 2017 10:01 am

Yes, Vampire works like that. Internally all function units use Altera or ARM defined bus. Nothing else. I have my information directly from developer.
Power without the Price. It's not a bug. It's a feature. _/|\_ATARI

1040STFM in PC-Tower (PAK68/2, OvrScn, 4 MB, 1GB SCSI, CD-ROM...) * 2x Falcon 030 32GB/14MB+ScrnBlstrIII * 2x TT030 73GB/20MB+Nova * 520/1040STFM * 520/1040STE * 260/520ST/+ * some Mega ST * 2x Mega STE 500MB/4MB+M.CoCo * Stacy * STBook * SLM605 * SLM804 * SLM605 * SMM804 * SH 204/205 * Megafile 30/44/60 * SF314 * SF354 * 5x Pofo * PC3

User avatar
mfro
Atari Super Hero
Atari Super Hero
Posts: 647
Joined: Thu Aug 02, 2012 10:33 am
Location: SW Germany

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

Postby mfro » Sun Mar 05, 2017 10:53 am

1st1 wrote:Yes, Vampire works like that. Internally all function units use Altera or ARM defined bus. Nothing else. I have my information directly from developer.


FPGA's cannot directly resemble (all) discrete logic 1:1 anyway, but only functional equivalents.

E.g. there is no way to implement a truely tri-stated or inout signal inside an FPGA as they just don't have the necessary logic to do that.

This doesn't really matter, however, as long as the implementation behaves identical.

User avatar
1st1
Atari Super Hero
Atari Super Hero
Posts: 662
Joined: Mon May 07, 2012 11:48 am

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

Postby 1st1 » Sun Mar 05, 2017 3:46 pm

Image
Vampire+EmuTOS in FullHD (1960x1080 1680x1050), still in 16 Bit color

Image
Vampire+EmuTOS half of FullHD (840x525), still in 16 Bit color (so one ST pixel is 4 TFT pixel)

Vincent was able to fix the screen blanking. It was not bandwidth issue of Vampire, but too high pixel clock for the monitor. But FullHD in 30 Hz is maximum, for 50/60Hz a faster FPGA would be needed.
Last edited by 1st1 on Sun Mar 05, 2017 9:20 pm, edited 1 time in total.
Power without the Price. It's not a bug. It's a feature. _/|\_ATARI

1040STFM in PC-Tower (PAK68/2, OvrScn, 4 MB, 1GB SCSI, CD-ROM...) * 2x Falcon 030 32GB/14MB+ScrnBlstrIII * 2x TT030 73GB/20MB+Nova * 520/1040STFM * 520/1040STE * 260/520ST/+ * some Mega ST * 2x Mega STE 500MB/4MB+M.CoCo * Stacy * STBook * SLM605 * SLM804 * SLM605 * SMM804 * SH 204/205 * Megafile 30/44/60 * SF314 * SF354 * 5x Pofo * PC3

BlankVector
Captain Atari
Captain Atari
Posts: 389
Joined: Wed Oct 24, 2007 7:52 pm
Location: Paris, France
Contact:

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

Postby BlankVector » Sun Mar 05, 2017 5:13 pm

1st1 wrote:Vampire+EmuTOS in FullHD (1960x1080), still in 16 Bit color

No, it is 1680x1050, the best that my 22" monitor can do. See file name.

1st1 wrote:But FullHD in 30 Hz is maximum

1680x1050 at 60 Hz is not stable on my monitor (random blanks), but at 30 Hz it is stable. Some other frame rates in the 30-60 interval should also work, I didn't care to check. And the situation might be different with other Vampire or monitors.

User avatar
1st1
Atari Super Hero
Atari Super Hero
Posts: 662
Joined: Mon May 07, 2012 11:48 am

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

Postby 1st1 » Sun Mar 05, 2017 9:18 pm

Oh, yes you are right, I was a bit in hurry when I posted this. This resolution is quite rare today.
Power without the Price. It's not a bug. It's a feature. _/|\_ATARI

1040STFM in PC-Tower (PAK68/2, OvrScn, 4 MB, 1GB SCSI, CD-ROM...) * 2x Falcon 030 32GB/14MB+ScrnBlstrIII * 2x TT030 73GB/20MB+Nova * 520/1040STFM * 520/1040STE * 260/520ST/+ * some Mega ST * 2x Mega STE 500MB/4MB+M.CoCo * Stacy * STBook * SLM605 * SLM804 * SLM605 * SMM804 * SH 204/205 * Megafile 30/44/60 * SF314 * SF354 * 5x Pofo * PC3

Sorgelig
Atari Super Hero
Atari Super Hero
Posts: 696
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

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

Postby Sorgelig » Mon Mar 06, 2017 1:07 am

mfro wrote:
1st1 wrote:Yes, Vampire works like that. Internally all function units use Altera or ARM defined bus. Nothing else. I have my information directly from developer.


FPGA's cannot directly resemble (all) discrete logic 1:1 anyway, but only functional equivalents.

E.g. there is no way to implement a truely tri-stated or inout signal inside an FPGA as they just don't have the necessary logic to do that.

This doesn't really matter, however, as long as the implementation behaves identical.

FPGA CAN resemble any logic if exact schematic is known.
There is no tri-state logic inside FPGA, but buffers connected to pins are tri-stated. There is absolutely no requirement of tri-state elements. They exist in real world just to simplify some inter-connections. FPGA inside doesn't need such helpers.
FPGA has another "issue" - it doesn't work well in asynchronous mode (where any signal can be a clock) - but this also doesn't prevent recreating 1:1 schematic.

FPGA can resemble schematic on a base logic/triggers level which is enough to make 1:1 replica of any digital circuit. The problem is in getting original schematic on the same gate levels which is in most cases unavailable. Some people do chip de-caping just to get this gate-level schematic and recreate some retro-chips as 1:1 replica.

User avatar
jvas
Captain Atari
Captain Atari
Posts: 437
Joined: Fri Jan 28, 2005 4:30 pm
Location: Budapest, Hungary
Contact:

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

Postby jvas » Mon Mar 06, 2017 8:47 am

Can anybody confirm these test results of the AMIGA 500 Vampire 500 V2+:

"*Gauntlet II whdload - Game play is slow and choppy frame rate.
*Ghosts and goblins – whdload Game play freezes randomly for 1 or 2 seconds throughout the game. Parallax - scrolling starts to get glitchy after extended game play.
*Klax – whdload Game play is too fast.
*Loom – whdload Slow choppy frame rate.
*No second prize – whdload Major gfx glitches in polygons.
*Obliterator - whdload. Gameplay has no speed increase (This game really needs acceleration).
*R-type 2 - whdload. Major gfx coruption. Sprite trails and crash. Causes recovery error unless hard reset is done.
*Switchblade 2 - whdload. Major gfx coruption.
*Armour-geddon - whdload.Blank screen. Hard crash. Reboot required.
*Hybris - whdload game Music plays at double speed and some sprites have gfx coruption in higher levels.
*Dynablaster - that don't work On the Vampire
*Elfmania - that don't work On the Vampire
*Zany Golf – that don't work On the Vampire
*Hybris - There is errors in the IRQ's of the vampire. The games and demos that don't work are .....
*Jim power - There is errors in the IRQ's of the vampire. The games and demos that don't work are .....
*Vroom - There is errors in the IRQ's of the vampire. The games and demos that don't work are .....
*Super monaco grand prix - There is errors in the IRQ's of the vampire. The games and demos that don't work are .....
*Space harrier - There is errors in the IRQ's of the vampire. The games and demos that don't work are .....
*Hardwired demo - There is errors in the IRQ's of the vampire. The games and demos that don't work are .....
*World of commodore demo – Whdload Exception "line 1010 emulator" ($28) at $569F8 occurred.
*State of the art demo – whdload Music plays at double speed.
*Rink-A-Dink Redux Demo – whdload Gfx coruption in plasma part of demo then hard crash. Requires cold reboot."

User avatar
mfro
Atari Super Hero
Atari Super Hero
Posts: 647
Joined: Thu Aug 02, 2012 10:33 am
Location: SW Germany

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

Postby mfro » Mon Mar 06, 2017 9:31 am

Sorgelig wrote:There is no tri-state logic inside FPGA, but buffers connected to pins are tri-stated. There is absolutely no requirement of tri-state elements. They exist in real world just to simplify some inter-connections. FPGA inside doesn't need such helpers.
FPGA has another "issue" - it doesn't work well in asynchronous mode (where any signal can be a clock) - but this also doesn't prevent recreating 1:1 schematic.

FPGA can resemble schematic on a base logic/triggers level which is enough to make 1:1 replica of any digital circuit. The problem is in getting original schematic on the same gate levels which is in most cases unavailable. Some people do chip de-caping just to get this gate-level schematic and recreate some retro-chips as 1:1 replica.


That's basically what I said - no contradiction.

Because of the lack of tri-states, you e.g. can't really 1:1 describe a bi-direcional bus (like our m68k address/data buses, for example) connecting components inside the FPGA in HDL. But you can describe a functional equivalent that consists of input and an output buses that are connected to the tri-state capable FPGA pins at the top level - than it looks like the real thing to the outside (besides some possibly tricky differences in timing, as two buses can have different timing while one single bidirectional bus obviously can't).

Sorgelig
Atari Super Hero
Atari Super Hero
Posts: 696
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

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

Postby Sorgelig » Mon Mar 06, 2017 10:11 am

So-called tri-state buses of M68K are also two buses inside the chip. One input and one output. They are connected together to minimize amount of chip pins. Basically it's exactly what FPGA does.

BlankVector
Captain Atari
Captain Atari
Posts: 389
Joined: Wed Oct 24, 2007 7:52 pm
Location: Paris, France
Contact:

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

Postby BlankVector » Mon Mar 06, 2017 10:22 am

jvas wrote:Can anybody confirm these test results of the AMIGA 500 Vampire 500 V2+:

I can just say that the Apollo Team has many game testers on Amiga, and I fully trust them to provide precise results, like the one you quoted. WHDLoad is an Amiga hack which allows to run old games on new hardware. It has to cope with issues like different CPU, faster CPU, disrespectful memory access, etc. Different hardware/CPU can lead to different results. Apollo developers work hard to improve Vampire compatibility with that stuff on Amiga.

User avatar
1st1
Atari Super Hero
Atari Super Hero
Posts: 662
Joined: Mon May 07, 2012 11:48 am

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

Postby 1st1 » Mon Mar 06, 2017 10:56 am

jvas wrote:Can anybody confirm these test results of the AMIGA 500 Vampire 500 V2+: ...


You should ask these questions in Apollo or an Amiga forum. Here would not be much experience with WHDLOAD.
Power without the Price. It's not a bug. It's a feature. _/|\_ATARI

1040STFM in PC-Tower (PAK68/2, OvrScn, 4 MB, 1GB SCSI, CD-ROM...) * 2x Falcon 030 32GB/14MB+ScrnBlstrIII * 2x TT030 73GB/20MB+Nova * 520/1040STFM * 520/1040STE * 260/520ST/+ * some Mega ST * 2x Mega STE 500MB/4MB+M.CoCo * Stacy * STBook * SLM605 * SLM804 * SLM605 * SMM804 * SH 204/205 * Megafile 30/44/60 * SF314 * SF354 * 5x Pofo * PC3

ijor
Hardware Guru
Hardware Guru
Posts: 2960
Joined: Sat May 29, 2004 7:52 pm
Contact:

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

Postby ijor » Mon Mar 06, 2017 12:33 pm

Sorgelig wrote:So-called tri-state buses of M68K are also two buses inside the chip. One input and one output. They are connected together to minimize amount of chip pins. Basically it's exactly what FPGA does.


The number of external pins is just a minor issue for using tri-state buses. Imagine if all the chips would have two external buses, one for input and one for output. You have to mux and combine them, and you need control signals for the mux selection. The ST has something like a dozen different components writing to the data bus. You would need a huge external mux that besides the cost and the complications, it would probably be too slow. And even worse, it would make adding new bus components (IDE, fast RAM, etc) extremely complex and expensive.

Btw, it is not entirely true that FPGA don't have tri-state signals. They used to have until not too long ago, and speed was one of the main reasons to use them. Many (most?) modern FPGAs still have the hardware, just that for several reasons (including possible damage to the device), the vendor tools don't let you configure them as such.

Anyway, I don't think that tri-state signals is the main issue when translating old school logic to FPGA. As Sorgelig said, a non fully synchronous design by modern standard, is the main issue. The ST chipset has plenty of cases that violate modern synchronous design rules.

Sorgelig
Atari Super Hero
Atari Super Hero
Posts: 696
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

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

Postby Sorgelig » Tue Mar 07, 2017 3:09 am

ijor wrote:The ST chipset has plenty of cases that violate modern synchronous design rules.

almost any real life digital circuit "violates" synchronous design. Actually it's not an issue as well and doesn't prevent making 1:1 replica using synchronous design. When you just come from traditional programming (like C/C++) you start to program FPGA in asynchronous way and at some point you realize the synthesized circuit go out of control which is impossible to fix. Synchronous design at first look is strange and hard to use. And then after couple of tries you realize it's easy, actually! You can go to much larger models and keep things in good control. And then you realize you can simulate traditional digital schematic by synchronous design very precise.

For purists who thinks that 1:1 replica is only when the same gate is used: Even basic logic elements like 7400 went through big transformations to become 74HCT00. Function is identical, but if you will look inside the IC, you will see that 7400 is based on BJT, while 74HCT00 is based on CMOS with different circuit inside. But 74HCT00 acts the same as 7400 and can be used as a direct replacement (if current is not too high). Even some CPUs went through big transformations inside with reducing the die size and power consumption. So, FPGA is king of this improvement. If you have exact schematic of chip (through de-capping or original documentation) you can make 1:1 verilog replica.


Social Media

     

Return to “ST(E) Clones (Suska / MiST)”

Who is online

Users browsing this forum: No registered users and 5 guests