29 September 2016, 18:45 | #21 |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,351
|
Why adding support of something that changes all the time ?
|
29 September 2016, 18:48 | #22 |
AmigaDev.com
Join Date: Mar 2016
Location: Stockholm, Sweden
Age: 35
Posts: 625
|
|
29 September 2016, 19:31 | #23 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,553
|
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.
Exactly. 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!) |
29 September 2016, 20:14 | #24 | ||
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,351
|
Quote:
Quote:
|
||
01 October 2016, 20:24 | #25 | |
Banned
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
|
Quote:
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. |
|
01 October 2016, 21:29 | #26 |
Registered User
Join Date: Jun 2008
Location: Boston USA
Posts: 466
|
A vampire faster at executing 68k code faster than a modern CPU running a 68k JIT? LOL!
|
02 October 2016, 22:52 | #27 |
Registered User
Join Date: Dec 2007
Location: Szczecin/Poland
Posts: 424
|
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.
|
03 October 2016, 08:21 | #28 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,553
|
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!)
|
21 February 2017, 11:39 | #29 |
Registered User
Join Date: May 2016
Location: Philadelphia, USA
Posts: 67
|
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.
Last edited by Xebec; 22 February 2017 at 20:16. Reason: meant FPU not GPU |
27 February 2017, 03:54 | #30 |
Registered User
Join Date: Aug 2001
Location: Connecticut USA
Posts: 617
|
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.) Last edited by Shadowfire; 27 February 2017 at 05:51. |
02 March 2017, 11:26 | #31 |
Registered User
Join Date: Aug 2007
Location: berlin/germany
Posts: 1,054
|
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. |
02 March 2017, 11:32 | #32 | |
Registered User
Join Date: Nov 2011
Location: Nuernberg
Posts: 816
|
Quote:
@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. |
|
02 March 2017, 15:27 | #33 |
Registered User
Join Date: Aug 2007
Location: berlin/germany
Posts: 1,054
|
|
02 March 2017, 16:02 | #34 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,553
|
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. |
02 March 2017, 16:42 | #35 | |
Registered User
Join Date: Aug 2007
Location: berlin/germany
Posts: 1,054
|
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 Quote:
|
|
05 March 2017, 14:45 | #36 | |
Registered User
Join Date: Aug 2001
Location: Connecticut USA
Posts: 617
|
Quote:
|
|
11 March 2017, 13:14 | #37 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,553
|
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.) |
14 March 2017, 21:30 | #38 | ||
Banned
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
|
Quote:
Quote:
|
||
18 March 2017, 01:49 | #39 |
m68k all the way
Join Date: Aug 2011
Location: Koalaland
Posts: 523
|
Please don't do it, Toni.
|
25 March 2017, 11:00 | #40 | |
Registered User
Join Date: Nov 2014
Location: Italy
Posts: 2,435
|
Quote:
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). |
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Thylacine emulation in WinUAE? | analogkid | support.WinUAE | 2 | 13 January 2016 22:22 |
WinUAe A590 Emulation | Mad-Matt | support.WinUAE | 8 | 09 November 2014 15:23 |
PPC emulation for winuae | marauder | request.UAE Wishlist | 25 | 04 November 2014 06:13 |
Need help with CD32 emulation on Winuae | trydowave | support.WinUAE | 9 | 31 August 2012 10:07 |
WinUAE + CD32 Emulation | MechUnit | support.WinUAE | 7 | 25 November 2003 17:04 |
|
|