Vampire emulation in WinUAE

[meynaf]

Why adding support of something that changes all the time ?

[Marlon_]

Originally Posted by Toni Wilen

If you have custom hardware, you should have also boot ROM that does the initialization.

The Vampire does have a boot rom.

[Toni Wilen]

Originally Posted by Marlon_

The Vampire does have a boot rom.

Even less reason for ROM patching. Yes, I know it is annoying if you also want exec/expansion in fast ram but just tiny bit of "slow ram" (which won't be slow) fixes it, the rest can be added with boot rom code. For example.

Originally Posted by meynaf

Why adding support of something that changes all the time ?

Exactly.

Originally Posted by Toni Wilen

But there is not enough developers, there is no compiler support, there is no debugging support. Everything needs to be done before actual support happens. It won't.

My point of this is that it seems this can make developers the "bad guys" from normal user point. "Why aren't those stupid developers doing anything for this perfect hardware, it is their fault that there is no software!" (Yes, I always expect the worst as usual!)

[meynaf]

Originally Posted by Toni Wilen

Even less reason for ROM patching. Yes, I know it is annoying if you also want exec/expansion in fast ram but just tiny bit of "slow ram" (which won't be slow) fixes it, the rest can be added with boot rom code. For example.

I think the rom patch is for saving extra registers in context switches, not for ram expansion.

Originally Posted by Toni Wilen

My point of this is that it seems this can make developers the "bad guys" from normal user point. "Why aren't those stupid developers doing anything for this perfect hardware, it is their fault that there is no software!" (Yes, I always expect the worst as usual!)

There was a time when a handful developers were in the team. They said a few things were wrong in the design. Guess what happened after...

[matthey]

Originally Posted by Toni Wilen

But there is not enough developers, there is no compiler support, there is no debugging support. Everything needs to be done before actual support happens. It won't.

I had an e-mail discussion with Frank "phx" Wille about this recently. He was wanting to add Apollo core support to vasm and asked me a few questions since I used to be part of the so called "Apollo Team". Support needs to start with basic tools like assemblers and debuggers and these need to be added to overcome the chicken and egg problem. The basic tools would eventually be used by higher level tools like compilers but there isn't really anything in the current Apollo ISA which could immediately or easily be used by compilers (certainly vbcc doesn't do much with SIMD instructions). Vasm would be adding SIMD instruction support just for an enhanced 68k FPGA CPU used by a handful of assembler programmers. Add to that the poor documentation and an ISA which has a history of changing often and it is aiming at a fast moving target. IMO, it is not time but please don't rule out that it will not happen even though the odds are with you. I was on the "Apollo Team" so there is a potential conflict of interest in my opinion even if I do try to be fair and unbiased.

Originally Posted by meynaf

There was a time when a handful developers were in the team. They said a few things were wrong in the design. Guess what happened after...

There are probably obedient new developers in his "Team" which agree with him all the time now. We shouldn't sabotage his project as he is perfectly capable of doing that on his own.

[frank_b]

Originally Posted by Romanujan

Compatibility-wise UAE can be better, but... somehow I have an impression, that games on real Amiga (or even MIST FPGA board) run smoother. I expect Vampire will beat the UAE with this regard.

A vampire faster at executing 68k code faster than a modern CPU running a 68k JIT? LOL!

[Romanujan]

Not the CPU - the graphics chipset. And not faster - just feeling more smooth in games. FPGA does the chipset in parallel to CPU, UAE does not - probably this is the reason.

[Toni Wilen]

That is not really anything to do with topic.. (and it also has nothing to do with emulation, it is just how PCs work. Low latency vsync fixes it 99%, 100% fix is g-sync or freesync display. Also don't talk about "feeling" when I am listening, hard technical facts only!)

[Xebec]

Vampire ammx instructions in UAE would be very useful for development. Same when the FPU comes out that may have functions other 68k CPUs don't have.

[Shadowfire]

Perhaps I'm missing something here, Tony, but I'm interpreting this as you wish that the Vampire used the Amiga's autoconfig protocol.

On an A500/A600, the _CONFIG line on the expansion slot is tied to ground. If you try and use auto-config on something like the vampire, it will work fine until you plug something into the expansion slot; at this point, both the cpu-socket device, and the expansion slot device, will be talking at the same time when the OS tries to enumerate the expansions (since neither one is aware of the other's presence, which would normally be arbitrated with the _CFGIN and _CFGOUT OR-GATE chains on the big box systems). The same thing applies to anything that isn't sitting on a Zorro bus or in a dedicated coprocessor slot.

So, you have to pick your poison when doing an expansion like this.

1. You can follow Autoconfig, which guarantees a bus collision (and likely nothing working at all) when anything at all is plugged into the expansion bus. This option renders the expansion bus or slot 100% useless, unless (on a slot architecture like the A500/A600; nobody would do this for a bus architecture like the A2000) the expansion slot device ALSO doesn't follow autoconfig and its hardwired assignments don't conflict with what autoconfig does with you.
2. You can hardwire your card address, and pray that the user doesn't plug anything in that gets assigned to the same area (which is what I did with my A500 IDE controller, I used the slot #6 64K I/O block that autoconfig/expansion.library would normally assign, allowing enumeration devices to slots 0-5 (IIRC) before it would conflict - slot 7 is where the devices initially appear before they are assigned an address). You can roll your own software to link a dummy expansion card structure into the system lists, so that the system can see it (which I needed to do to get auto-boot working, although for a RAM expansion you could conceivably skip this step and just AddMem() it if it isn't already in the system memory list and it would work just fine, it just wouldn't show up in Showconfig).
3. You can roll your own autoconfig-alike (in that you can disable it and map the address) hardware, and write an exec module and make sure it shows up somewhere in the memory map that Kickstart will be looking for run-time modules, so that it can get linked into the system lists at initialization time; Exec will call the Init() function, which you can use to set up software to configure your hardware after Autoconfig has done its thing; your software might need to build up a dummy expansion card structure and adds it in with the rest of the expansion.library cards.
4. You can put your device outside of the standard autoconfig assigned address ranges. There isn't a lot of address space like this on 68000 systems, and you also have to roll the configuration software, AND you REALLY don't know if there isn't some expansion memory already there in any given configuration; on top of that, the status of processor caching isn't clearly specified for these locations (or at least I haven't seen any documentation on this; although its pretty common-sense that data caches should be turned off for anything sitting in the Autoconfig I/O address slots and custom chip register spaces).

None of the "has a chance to work if something is on the expansion bus" options involves expansion.library doing the configuration, so I don't understand why you're upset about why they did things outside of Commodore's established protocols; the protocols were never designed for things that sit in the 68000 socket. (Fixing the system for Autoconfig would involve making the user cut the trace to GND on the _CONFIG line, and soldering a pickup wire to the _CONFIG line that runs to the expansion card - a completely unacceptable situation for something you expect to sell to the general public.)

Now, to add my $0.005 to the topic; I agree with Tony that the instruction set expansions are going to fragment the user base. That being said, I know that they want to make a "Modern" version of the 680x0, and this is the first hardware they have with widespread-ish distribution, and by definition, is the only one that has any chance of something resembling testing by people outside the core team, and I think that its a damned fine shoot-for-the-stars project goal. I think that 95%+ of the people that want a vampire, probably don't care about the extended ISA as long as it doesn't break existing software. This is why I'd be very, very skittish about it if I were using the Apollo core, because any changes to the stack frame (such as, extra registers being pushed onto the stack which don't exist on a 68020) are likely to cause serious compatibility issues with existing software, especially the stuff that throws the OS out... like 99% of the existing games do.

(Also, if I were in Tony's shoes, I also wouldn't even give it serious consideration until the Apollo team makes some sort of commitment to lock the implementation and make it work as documented; as our hobby projects, our time may be "free", but there is a finite amount of it, and nobody wants to spend several hundred hours on something only to have to tear it apart and rebuild it months later.)

[wawa]

i dont think that tonis main concern with vampire is if it has autoconfig or not. it may be thats simply not a priority for an overworked man, especially that the hardware is not (yet) set in stone for proper emulation.

what concerns autoconfig (ot here) we have had this discussion on a1k and matze, the autor of various expansions, cpu cards for a500 among others, has offered a solution that he developed and is working for his hardware;

http://www.a1k.org/forum/showthread.php?t=56133&page=16

post#304

i wont translate it, use google on it, the link to his github repo is available in his post.

[OlafSch]

Originally Posted by Romanujan

Compatibility-wise UAE can be better, but... somehow I have an impression, that games on real Amiga (or even MIST FPGA board) run smoother. I expect Vampire will beat the UAE with this regard.

not the only reason why a real hardware development like Vampire is needed... I had discussions with one of the NG game developer (AROS, MorphOS, AmigaOS) why not supporting 68k where most users and thus potential buyers are. He admitted that 68k on UAE might be fast enough but why using it in UAE if you can play the same game on windows. Hard to discuss about that but why using then something amiga-like at all? Besides from that he said he would look at Vampire if it is fast enough for future projects. Also many amiga users do not see emulation as real so there is a big market for it (obviously). Regarding Vampire... from what I know it will step by step replace existing extensions and hardware so finally all will run on the card and the amiga only be necessary as keyboard and for the interfaces. If you like it or not is a personal decision. Big box users with lots of cards inside already propably should better buy a accellerator card and not a vampire.

@Toni

your comments sound a little harsh to me. I think both real hardware (Vampire) and Emulation could benefit from each other because emulation could help to build up a bigger market in short time whereas Vampire potentially helps to create more interest than UAE alone could do.

[wawa]

Originally Posted by OlafSch

your comments sound a little harsh to me.

thats his style of communication. if you were one of few competent developers left and people were constantly bugging you about this and that (sometimes senslessly like me) you would have to grow some distance.

[Toni Wilen]

Why wouldn't autoconfig work? Just keep all autoconfig region accesses inside of CPU board (mainboard sees nothing happening when access range is $e8xxxx-$efxxxx. Even easier when using Z3 range, it would be outside of mainboard 24-bit space) until all onboard autoconfig board(s) have been configured by expansion.library.

--

Also: Why would I help or support commercial product for FREE, commercial product that is sold (just search eab and other forums) as a supposedly worlds best replacement for every Amiga model and emulators, even if you only want to run A500 demos/games or whdload games.

Sources are that way -> . Talking is easy, arguing is even easier.

[wawa]

Originally Posted by Toni Wilen

Why wouldn't autoconfig work?

there is an extensive discussion (in german) on the matter and the detailed quirks of implementation including gunnar, thor and others. it occures that mazzes proposal is not without caveats. gunnar and the team have apparently taken a working shortcut with some performance gain in perspective.

reading the posts i have noticed thors mention abot exec being built in the memory two times, first in MEMF_LOCAL (chipram?) and then in
autoconfig (accelerated?) ram. i aks myself btw if aros68k already does the same od does execbase remain in slow memory? maybe here is one of remaining speed penalties located? i know i should check myself. have not done that yet.

post #342:
http://www.a1k.org/forum/showthread.php?t=56133&page=18

Sources are that way -> . Talking is easy, arguing is even easier.

ack.

[Shadowfire]

Originally Posted by Toni Wilen

Why wouldn't autoconfig work? Just keep all autoconfig region accesses inside of CPU board (mainboard sees nothing happening when access range is $e8xxxx-$efxxxx. Even easier when using Z3 range, it would be outside of mainboard 24-bit space) until all onboard autoconfig board(s) have been configured by expansion.library.

Aha! Thanks for that insight, it wouldn't have applied to the IDE accelerator design (as it doesn't have any sort of bus interface other than an SRAM <> 68000 block, and didn't have the CPLD between the 68000 and mainboard control lines), but this is a great idea if you happen to be implementing a 68000 bus interface on your FPGA. Its giving me the urge to go back and redesign/fix it

[Toni Wilen]

Exactly. Another too obvious solution that is not done because most just copies old (bad) designs..

I blame Phase 5 for this, all their accelerators have stupid design. Amiga had autoconfig (which is very similar to PCI, minus few features), then later Amiga hardware designers decided that hardwired design is so much better.

Even worse are so called "autoconfig" boards that only work if they are the only board in system.

I'll accept hardwired design if it is meant to be very cheap and there is no logic space for full or partial autoconfig.

(As I have already said, there is big chasm between Amiga hardware and software people. I don't include those that think they know what they are doing, there is far too many of those.. Yes, I am software guy and there may be good reason for Phase 5 (and others) to do it that way but this is what happens when there is no good communication. Everyone just blames the "other side" for being stupid. "Here is the spec, now it is your turn do the software/hardware. Err? Didn't I have anything to say before you designed it? No. You don't need to know.". It happens both ways.)

[matthey]

Originally Posted by Toni Wilen

Exactly. Another too obvious solution that is not done because most just copies old (bad) designs..

Unfortunately, computer technology is all about following the leader and their bad ideas. From IBM choosing the 8088 for the PC when the 68000 was available to ARM with ARM32 (innovative but optimized too much for one CPU design), Thumb (first improved code density mistake), Thumb 2 (good code density but handicapped by 8 GP registers giving much increased instruction count and cache/memory accesses) and ARM64 (back to 32 GP register RISC which is a resource hog) modes with mode switching overhead and now using slower 64 bit pointers all in one CPU for embedded. These companies get a good reputation and then everyone follows them like lemmings. Yet IBM was far from a leader in PC performance then (they won market share by reputation and openness) and most modern "high performance" ARM processors are neither small and efficient any longer contrary to their reputation for small efficient CPU designs and energy efficiency.

Originally Posted by Toni Wilen

(As I have already said, there is big chasm between Amiga hardware and software people. I don't include those that think they know what they are doing, there is far too many of those.. Yes, I am software guy and there may be good reason for Phase 5 (and others) to do it that way but this is what happens when there is no good communication. Everyone just blames the "other side" for being stupid. "Here is the spec, now it is your turn do the software/hardware. Err? Didn't I have anything to say before you designed it? No. You don't need to know.". It happens both ways.)

Again, not unusual. This was one of my major criticisms of the Apollo core. I tried to bridge the communication gap between the hardware designers (Apollo core hardware designers), software writers especially compiler designers (vbcc's Dr. Volker/Frank Wille) and embedded needs (I approached InnovASIC's Fido 68k designer Dave Alsup) in creating an enhanced 68k CPU and ISA but nobody was much interested! Nobody was interested in researching and creating a new 68k CPU together! I took the initiative on my own to modifying ADis to collect 68k statistics from Amiga executables but Gunnar decided how the hardware would be because hardware designers know best. I believe UAE could have been modified to prototype and run traces for an even better look. You were one of the people I would have loved to contact when I was trying to form a healthy "Apollo Team" but Gunnar's authority was threatened already by my meek assertiveness (meek and assertive are not opposites as I am the gentle, sometimes invisible, hand that steers people in the right direction). Unfortunately, Gunnar has made choices which limit the chances of the Apollo Core being used outside of an FPGA in retro 68k computers. His design and ISA are too optimized for a particular hardware, not designed for future upgradability and does not exploit the potential of the 68k. Too bad you were not there to tell him about hardware mistakes but then you are just a "software guy" too. On the bright side, you didn't waste your time like I did and is so common for developers in the Amiga community. Only Amiga makes it impossible.

[B14ck W01f]

Please don't do it, Toni.

[Seiya]

Originally Posted by OlafSch

I think both real hardware (Vampire) and Emulation could benefit from each other because emulation could help to build up a bigger market in short time whereas Vampire potentially helps to create more interest than UAE alone could do.

UAE has already the maximum interest inside and outside amiga community. Any Operating System, any mobile devices, any computers and consoles has UAE to make retrogaming.

It seems, but i can wrong, that Vampire would be fighting against UAE to rule Amiga retro gaming.
Too many discussion about "vampire better than UAE", "Vampire faster than WinUAE" from Apollo Team.

Vampire should be an alternative to emulation so no need to ask help to UAE.
With AMMX they want to cut any relationship with 68k classic (included UAE).