Masjsta's A500 Vampire

[psxphill]

It's not software! :laughing:

It is software, by every definition. It's not a sequentially executed language like you feed CPU's & DSP's.

Apollo is software and more importantly it's an emulator, it happens to be a not very accurate one but that is by design.

your mileage may vary, there will be "software that takes care of it",

That is the standard line, it Apollo can't run exec.library then someone can just patch it or write a new one.

[psxphill]

That's right, my vampire system is far more stable that my A4000 with cyberstorm 060.

Sure it's better running some software, it unfortunately doesn't run the software I want to run so I won't buy one until it does. It would run 0 hours with Amiga BSD, Amix or Shapeshifter with TurboEVD video driver.

Then a sheet of paper coming out of a printer is software too.

No, paper is neither software nor hardware. But thanks for the straw man.

and if not, being "inacurate" its a field for improvment, that apparently is both possible and considered.

the actual problem would arise if there was no argumentation on thes subject allowed, or the issue was denied, but ist isnt the case, at least in my book.

Actually no discussion is allowed by people here and the issues are denied, the fanboi's won't let anything be said that isn't 100% positive. It's not just me who shares the same issues with Apollo.

[psxphill]

Clearly a sheet of paper i hardware. Postscript is an example of a language that is used to describe how the print on the paper will be. Same for 3D printing, you program the model. Same for FPGA, you program the layout.

You don't program the layout in FPGA, you configure switches. Which is what software is, a configuration of switches. The switches are volatile therefore the configuration is software, if you put it in an ASIC then it's hardware. There is a convention that if the software is executed from flash memory then it's called firmware (all firmware is software, not all software is firmware).

Postscript is software, it's passed through other layers of software and finally configures the print hardware. The paper is just passing by when this happens, the closest CS description for it would be a "storage medium".

So your argument is that because the Apollo core doesn't currently run those non-Amiga operating systems people shouldn't buy Amiga accelerators that use the Apollo core.

I'm pretty sure I haven't said people shouldn't buy anything. Those are three applications from the top of my head that would really use a faster cpu. There are other applications that require an MMU and FPU, but those in particular would be much harder for any software patching schemes to deal with.

Does your argument also apply to all the other Accelerators using Motorola/Freescale CPUs without MMUs?

If people want to choose to buy an accelerator without an MMU it's up to them, the problem is that Gunnar and all you fanboi's are saying that because you don't see a need for an mmu then I deserve to be mobbed for saying I do. Then after that childish behaviour you all then try to shut down any logical discussion with more mobbing and victim blaming.

Are they all incompatible/inaccurate too?

The incompatible and inaccuracy in Apollo is nothing to do with the MMU, so no.

Do you also go on Unix and BSD forums telling them not to buy x86 hardware as it can't run Amiga OS without emulation or classic Mac forums telling them their machines are useless because they don't have a the custom chips to play Amiga games natively?

Childish strawman.

I'm not sure you're argument will win over many people since the "failings" of the current Apollo core would seem to be insignificant to the vast amount of Amiga users who probably have no interest in running the software you want to.

Sure there are people who will vote for Donald Trump the same way a lot of people voted for Putin in the rigged elections and a lot of people screwed the UK's future by voting for Brexit. But being on the popular side is not the same as being on the right side, but you wouldn't understand as you just want to get in on the mobbing.

Ok lets discuss.

Lets start with a simple question. Which Amiga do you own.

So which specific part of the Apollo-Core do you believe to be defective or feature missing.

I own three A1200's, an a500 and an a500+ (I sold my A1500 a couple of years ago). I've got a phase 5 030/50 card in my A1200 with scsi and 48mb of ram and 2(ish) gb ide hard drive. For the a500 I've got a 28mhz 68000 and trifecta 250mb scsi drive.

Apollo is missing the fpu and mmu & the exception frames/what instructions it supports don't match any existing 680x0 design. While I understand that the mmu and fpu haven't been implemented yet, Gunnar was quite clear at the start that he has no intentions of ever providing a 100% accurate implementation of them. None of the statements made since give any indication that he has changed his mind, only that any issues will be dealt with by software. Which is fine for a lot of people, as you're so desperate to get anything that you'll accept what he says without question. So desperate in fact that any negative discussion is met with pure hostility, in case it upsets Gunnar & he leaves with his closed source core.

I just think it's all a real shame.

[psxphill]

I've a dream...a Vampire dream...V1200 with more than 512MB of RAM :banana:

An A1200 with 4gb of ram (with holes cut out dynamically for rom/io etc) with all of it available as chip ram would be cool.

[psxphill]

Not really. The problem is to find a way to handle the vampire *despite* the copyright situation of exec. Actually, if you look back, it was also possible to support the 68060 on AmigaOs, even though exec does not support this CPU.

Hence, if done correctly, there is no need to fiddle with the exec sources at all, or to provide alternative exec sources. A processor library is all it takes - provided the CPU has the necessary properties.

If the vampire FPU, all the exceptions stack frames etc are compatible with the 060 then we already have the software. If you are running old software then the new mmx registers don't need to be saved, obviously task switching would need to be patched to save/restore the registers if you're running new software (like fpu register saving is already patched when an fpu is detected). It may be possible (and even desirable) to include that in the applications that use mmx, to reduce overhead on all task switches. We already have software for fast patching of instructions missing in the 060 as well.

[psxphill]

All in all the 080 is far more compatible than any of 040 or 060.

It is impossible to be more compatible with an 040 than an 040, any deviation from an 040 makes it less compatible. It might run software that wouldn't run on an 040, but that is a different thing. oxypatcher/cyberpatcher/etc already solved the problem of emulated instructions years ago. So being more compatible in your sense isn't even true.

I've many years experience in emulation and one of the things I've found is that it sounds great to make one thing emulate more than one thing (i.e. a cpu that can run 030, 040 & 060 software), but you eventually run into problems and split it out. Or at least you do if you have the source, or the developer with the source cares about your issue.

[psxphill]

Some games/demos timing goes bad when running extreme speed. 040\040ec is not most widely used platform for games http://eab.abime.net/showthread.php?t=34854

I found the 28mhz 68000 was pretty good for old games. Although the switch on the back which could instantly slow it back to 7mhz was useful when there was an issue. Some demos were improved by running at 28mhz, at some point I need to resurrect that system. Of course the benefit is that it's using 68000 exception frames and instruction decoding. If you could switch between different cpu compatibility then it would be awesome. Is move sr privileged on the Apollo core?

Old games would usually be running from chip ram, so they shouldn't be running drastically faster anyway. Unless it's not waiting for the caches to be enabled.

Doesn't whdload solve all the issues running on an 040 though, how well is that running on Apollo?

[psxphill]

What's being referred to here, I believe, is the option of being able to implement all instructions directly.

Is it an option? Or is it enforced?

[psxphill]

Watch the Amiga 500, the PSOne, the N64... All these machines had great success with all the required stuff in rom...

Most games ignored the rom apart from reading the bootblock, but if you did anything with workbench then you needed to load a lot of things that weren't in rom.

IMO a flash chip with kickstart and a writable file system would be the best approach moving forward. ROM is kinda limited, you can't update it.