@cdimauro

Vamos lacks about everything. It is just an 68000 instruction set interpreter. Something like this I write before breakfast
Oh, it can load libraries. This is badass. As long as don't do anything outside the 68000 emu.

Even if the chipset emu can live on a separate core, it will drain the battery. Productivity software usually does not use the chipset directly. This is why it can be dropped completely or held on such a low accuracy that it won't cost anything if not hit directly.

E.g. it could trap if the 68K code hit one of the 0xDBEF... registers and not crash, some of them could even react in a useful way, but it won't update if not tampered with.

Even the CIA's should not be emulated. A "native" timer.device should take the job.
Goal should be host 100% idle if Amiga is 100% idle.

_________________
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes and many more...
Homepage: http://www.hd-rec.de

@Wanderer

Jene = Just Enough Emulation
Gene = Gusto Enough Emulation

_________________
John 3:16

@Wanderer: Vamos is just a starting point, and a "workbench" where you can test the (new) native versions of the APIs. It's also good because currently can log many useful information (with some level of detail), which can give you a rough idea of what's happening "under the wood".

Call it a prototype, where you can quickly test your code / ideas. Then you can convert everything in C or whatever language you like to write the real application.

Don't underestimate the capability of modeling that Vamos can offer to you, because the project that you want to create is quite complex, especially because it's a very low-level stuff.

Last but not least, for maximum 68K performance the host o.s. should be removed, taking full control & advantage of the CPU. Existing o.ses doesn't allow to fully exploit the features of modern CPUs. Here AROS can be very useful, because you already have a lot of things which are natively implemented, so you "only" need to tunnel 68K APIs/libraries to the corresponding AROS (native) versions, where it's possible. You can also use AROS hosted at beginning, to fasten the prototype development.

@Wanderer

If you can't use chipset based software like dpaint you lose half of productivity...

_________________
"When the Amiga came out, everyone [at Apple] was scared as hell." (J.L. Gassée, former CEO of Apple France and chief of devs of Mac II-fx, interviewed by Amazing Computing, Nov 1996).

@Raffaele
Quote:

If you can't use chipset based software like dpaint you lose half of productivity...

Do not take my question as trolling or flamestarter, but is there any productivity software for 68k worth using these days? There weren't any updates or new releases for 68k for like a decade :( (well beside PPaint)

Last edited by ExiE on 10-Jul-2015 at 12:43 AM.

Any software which uses only the Blitter can work without problems. The Blitter is one of the few hardware components which can be emulated without problems even on an o.s-only software platform, without requiring a chipset emulation (I mean: no rasterlines or cycle exact emulation of the chipset).

Of course, it requires at least to intercept the access to the Blitter's registers. Depending on the techniques used, it can slow down a bit the 68K code execution, but it might be worth the effort.

@Wanderer

Personally I'd rather see work continue on A / AIDE.

_________________
OS4 Rocks
X1000 beta tester, Sam440 Flex (733)

Visit the Official OS4 Support Site for more help.

It may be that your sole purpose is to serve as a warning to others.

@cdimauro

Right. I think Vamos is interesting and I should "read" it before doing anything else. Basically this is what I would start with too, and then successively add more functionality.

> Existing o.ses doesn't allow to fully exploit the features of modern CPUs.
What feature of modern CPUs would be interesting for the emulation?

I think the Host OS is a very important "feature" for the emulation, and the reason why I switched from Amithlon to WinUAE some years ago - it is so much more convenient to have a host OS in the background, and it makes it run everywhere the host runs. AmigaOS does not cover all needs, and rebooting is not an option. This totally outweighs the few extra cycles you would gain from kicking it out. And remember, we are in multi-core age, the host OS will not really disturb the emulation anymore.

AROS is helpful to gain quick insights of the AmigaOS API. If the code can be used depends on the nature of the project, commercial or free. Commercial could accelerate development, but its questionable if there is enough market for it.

_________________
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes and many more...
Homepage: http://www.hd-rec.de

@Raffaele

Haha. Yeah. Luckily we have still PPaint.

_________________
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes and many more...
Homepage: http://www.hd-rec.de

@ExiE

> is there any productivity software for 68k worth using these days?
There is. Of course you can have a replacement probably for everything under Windows/Mac.
But this is true for OS4/MOS and the PPC hardware too.
We do it because we like it and because we can It's more a technical challenge than an act of reason.

_________________
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes and many more...
Homepage: http://www.hd-rec.de

@cdimauro

If it helps compatibility, chipset emu can be done as long as it does not cause permanent CPU usage. E.g. strobe registers like Blitter has are totally fine. They won't slow down anything either.

_________________
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes and many more...
Homepage: http://www.hd-rec.de

@Severin

I am constantly improving AIDE. It is pretty good for Amiblitz3 already. I had it working for C/C++ too, but without intellisense yet.

"A" is put on hold at the moment. I doubt there is much interest and I believe this is more work than an Amiga emulator. Some part of it, e.g. the VM that can run "V" code (the virtual, intermediate code), is pretty much already a 68K interpreter, just with a different instruction set.

_________________
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes and many more...
Homepage: http://www.hd-rec.de

@Wanderer

Quote:

Wanderer wrote: @cdimauro Right. I think Vamos is interesting and I should "read" it before doing anything else. Basically this is what I would start with too, and then successively add more functionality.

You can try quickly adding them to Vamos, creating a proper test suite, and when they are mature/solid enough, you can convert the code to C, C++, or whatever you want, and recycle the test suite for testing the "native" code.

That's what I'm doing with my 8086 emulator written in Python (my final goal is to port it in C, when it's done).
Quote:

> Existing o.ses doesn't allow to fully exploit the features of modern CPUs. What feature of modern CPUs would be interesting for the emulation?

Well, for example there are some new instructions which let to solve the Blitter emulation problem which we discussed, in an a very quick and efficient manner, using one core for the it which is frozen and wakes-up only when a new blit operation has to be performed.

The "little" problem is that they run only on ring-0, and probably are exclusively used by the o.s..
Quote:

I think the Host OS is a very important "feature" for the emulation, and the reason why I switched from Amithlon to WinUAE some years ago - it is so much more convenient to have a host OS in the background, and it makes it run everywhere the host runs. AmigaOS does not cover all needs, and rebooting is not an option. This totally outweighs the few extra cycles you would gain from kicking it out. And remember, we are in multi-core age, the host OS will not really disturb the emulation anymore.

See above. And that's only one example of how an o.s. can compromise the fully exploitation of a processor.

However it depends on the goals. If the final target is to squeeze the maximum for a 68K emulator/o.s., an host o.s. has to be removed, losing its commodities, unfortunately: you have to write a new o.s. and its drivers.

If the goal is to get very good performance, you can use an host o.s. and take advantage of its built-in services. Of course, this is the easy way to get something ready and function in less time.
Quote:

AROS is helpful to gain quick insights of the AmigaOS API. If the code can be used depends on the nature of the project, commercial or free.

AROS license is similar to LGPL.
Quote:

Commercial could accelerate development, but its questionable if there is enough market for it.

Honestly I don't think that there's enough market. You can see it here, with the post-Amiga community, which can count around 10,000 peoples putting all communities members together.

If you want to start this is project, is primarily for fun.

Quote:

If it helps compatibility, chipset emu can be done as long as it does not cause permanent CPU usage. E.g. strobe registers like Blitter has are totally fine. They won't slow down anything either.

Emulating only the Blitter can increase the compatibility and the CPU usage is only related to realize the Blitter operation.

That's enough IMO, because emulating other hardware parts isn't useful, or can hurt CPU usage. I mean, almost perfect audio emulation implemented to let some programs like AudioMaster reach 56Khz sample rate on playback doesn't make sense, because other programs allow to go over the 28Khz (circa) using AHI instead. Disk emulation isn't useful.

What else? Nothing really important. For everything else it means that you want to just play games, and that's where (Win/FS)UAE is good for.

@cdimauro

>> What feature of modern CPUs would be interesting for the emulation?
I don't think the blitter emulation is problematic, since it is passive. What would cause active CPU usage are the timers and copper mainly, maybe Paula will cost a bit. This is why I would do them only on a level where the program won't crash, but e.g. Paula will stay quiet to not cost CPU.

Kicking the Host OS out means writing Gazzilian times more code for the last 1% of performance. This is not worth it. PC Games don't kick the OS out and still work fine, right?
And besides, portability is a big issue. It should not just run on "ASUS5500 with NVIDIA Geforc256MX, and Sound Blaster Live1024", if you know what I mean. Ideally, it runs on all modern platforms with more or less a recompile. Of course, a JIT is CPU dependent and needs adjustment, and so will some details, but I would try to avoid to go low level.

For modern hardware, the problem is not the hardware, it's the drivers. So writing your own is probably not a good idea, and even direct HW access will not compensate for a good driver.
E.g. Amithlon, if you didn't have the NVIDIA driver, Amithlon GFX was painfully slow (VESA mode). And the NVIDIA driver was probably far from perfect.

So goals are (for me)

1. Maximize performance like Amithlon
2. Use the host OS even more than WinUAE
3. Keep things simple and portable
4. Drop or bypass hardware emulation to achieve 1-3 (for games, use UAE)

_________________
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes and many more...
Homepage: http://www.hd-rec.de

@Wanderer

Quote:

Wanderer wrote: @cdimauro I don't think the blitter emulation is problematic, since it is passive.

Yes, but there's the possibility to offload its work to another core, to let the 68K "core" run at the maximum speed. The same for some other graphic(s.library) requests, that can be offload as well.

What I think, in general, is that currently there's practically nothing in the emulation domain which makes use of available cores of modern-and-not-modern processors. AFAIK only PCSX2 makes partially use of a second core.

That's really a shame, since PCs have multiple cores (or at least hardware threads) from several years. My 5 PCs range from a couple of Atoms which have one core and two hardware threads to the last i7 which has 4 cores and 8 hardware threads.

It's time to make seriously use of them, but I'm aware that it requires a lot of effort. Changing an existing emulator like WinUAE or MAME requires so much work to do, that it's easier to rewrite the basic multi-core system and then import only what's really needed (e.g.: some routines which emulates specific parts of the emulated hardware).

But right now it isn't important for you, and you can focus only to squeeze the most from one core.
Quote:

What would cause active CPU usage are the timers and copper mainly, maybe Paula will cost a bit. This is why I would do them only on a level where the program won't crash, but e.g. Paula will stay quiet to not cost CPU.

It depends on how much precision do you want to achieve for the Paula emulation. Remember that the audio channels can also generate interrupts, and in general they are synced with the chipset clock and their exact behavior is modeled by a FSM. All of this requires resource, but what's worse is that if the CPU has to sync with the chipset clock, you'll lose a lot of computing power checking at regular intervals if you have to do something for the audio subsystem.

My suggestion is to leave this out, and focus only on rewriting the following libraries: exec, graphic, layers, intuition, dos. It's better to stick with an old Kickstart version, like 1.2, and have something working. After that you can add what's needed for supporting more modern versions.

You don't have to rewrite every single APIs of such libraries. My idea was (because I though something similar some time ago, since I'm fascinating by the Amiga emulation ) / is that you natively implement only the most important & needed APIs, and use the 68K ones for the APIs which aren't implemented.

You have to provide also a minimal (or empty) implementation of the following devices: audio, input, keyboard, timer. Implementing the trackdisk can be useful for introducing ADFs support.
Quote:

Kicking the Host OS out means writing Gazzilian times more code for the last 1% of performance. This is not worth it. PC Games don't kick the OS out and still work fine, right?

PC games haven't the requirements and problematics of an emulator.

As I stated before, I think that the o.s. prevents to use some tricks which can be very useful for improving the emulation performance. And I don't spend my time on thinking about such argument, if I have no feeling that it's possible to gain more than a miserable 1%.

However such things are quite complicated and require a lot of work. Leave them right now.
Quote:

And besides, portability is a big issue. It should not just run on "ASUS5500 with NVIDIA Geforc256MX, and Sound Blaster Live1024", if you know what I mean. Ideally, it runs on all modern platforms with more or less a recompile.

Absolutely.
Quote:

Of course, a JIT is CPU dependent and needs adjustment, and so will some details,

Try to use a TDD and/or unit-test approach: it'll reduce A LOT the hassles, and allows you to experiment with new ideas reducing the risk of breaking something.
Quote:

but I would try to avoid to go low level.

It's fine. Since the project is already huge by itself, first let it at least run.
Quote:

For modern hardware, the problem is not the hardware, it's the drivers. So writing your own is probably not a good idea, and even direct HW access will not compensate for a good driver. E.g. Amithlon, if you didn't have the NVIDIA driver, Amithlon GFX was painfully slow (VESA mode). And the NVIDIA driver was probably far from perfect.

I agree. However for the VESA mode it might be that the graphic functions weren't optimized. Today using SSE, AVX/2, and the upcoming AVX-512 (with Intel's Skylake), even a normal CPU can do a good job on handling 2D graphic.
Quote:

So goals are (for me) 1. Maximize performance like Amithlon 2. Use the host OS even more than WinUAE 3. Keep things simple and portable 4. Drop or bypass hardware emulation to achieve 1-3 (for games, use UAE)

That makes absolutely sense.

@cdimauro

I think we are on the same page now.

Maybe a stupid question, how does kickstart run? Is there a fix address the execution starts?

All I know so far is that address #0 is illegal, and address #4 has the pointer to the exec library base. And then, there are the hardware registers starting at 0xDFF000 . Any prerequisites I forgot?

_________________
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes and many more...
Homepage: http://www.hd-rec.de

@Wanderer: I think that you don't need to know such information, because your purpose is to "just" run 68K applications. If you rewrite the needed libraries and devices, you can forget at all about the hardware.

Anyway, the Amiga memory map is here: http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node00D2.html

At the reset, the PC of the 68000 is set to $0, but the Amiga hardware logic remaps the ROM ($FC0000 for Kickstart = 2.0) at this address. After the CPU takes control, usually it jumps to the correct (and "safe": at the right address) ROM address, and then disables such mapping (so chip mem is mapped again at $0).

But, as I already said, you need nothing of that. At the startup, you only have to initialize the memory as a 68K application expects (I mean, ExecBase, GfxBase, etc.), and trap the library calls to execute the native code.

@Wanderer

I'd be pretty interested in this for running PageStream. FInalCalc, DrawSrudio and a few other applications, provided the list of host OSs included AROS...

Cheers,
Nigel.

@Wanderer

I would pay twice as much for a JIT chipset emulation if you can do it.

Doh, I picked the wrong option I wanted to click "Existing emulators are good enough for my purposes" but I selected "hardware only". Oh well.

Last edited by elwood on 12-Jul-2015 at 02:21 PM.

_________________
Philippe 'Elwood' Ferrucci
Sam460 1.10 Ghz
AmigaOS 4 betatester
Amiga Translator Organisation

@elwood: what do you mean with "JIT chipset emulation"?