emulsion on plugins
ZXNet echo conference «zxnet.pc»
Hello, All
..an unoriginal idea came to mind for a zx emulator made on plugins, then
there is a flexible architecture, alternative modules for all sorts of peripherals...
I looked at the description of the plug-in interface of the Shalaev emulator and realized that everything was there
too tied to a specific architecture that can be expanded, but
it is almost impossible to change. I couldn’t find a description of the emuzwin plugin system,
as well as his website on rinet.ru. something in life passed me by O__o
In general, I propose to develop a simple and flexible architecture for a plugin
emulsion. For now it’s just words, and then you’ll see what’s written ;)
I currently see the most ambiguous point as the need (?) for modules (plugins)
communicate not only with the emulator core, but also with each other. for example, a video controller
need access to extended memory...
and isn’t it better to do without a core in the usual sense (z80, INT and
etc)? let the kernel be just a plugin manager (much like the kernel in
microkernel OS - process manager only). then we get more or less
a universal platform for emulator writing.
Hello, boo_boo
The site moved to kolmck.net yesterday. All files have been transferred, there is a redirect at the root
abandoned.
Hello, boo_boo
misunderstood. There are output plugins including sound and image on each
frame. But the output is focused specifically on sound and image. I don’t remember to enter,
to somehow do something. But you can add. Questions about what this is for anyone
no need. In the sense that I have to make these plugins myself. So to me
then it’s easier to stuff everything inside the kernel.
Hello, Vladimir Kladov
oh thank you :)
yeah, as far as I understand, emuzwin plugins are only for working with images.
oh, it's a pity that J. The needle is silent in a rag. there is clearly something in the performance
interesting things are piled up in terms of modularity....
Hello, boo_boo
Such an emulator already exists. It's called MESS http://www.mess.org/. Open source.
The monster is simply awesome. Emulates about a hundred platforms at the moment. B
including a herd of speckled iron (SamCoupe too). How high quality - not
I know. I played around with it as a C-64 emulator for the sake of enlightenment about what it is
such a car.
But it is precisely completely abstract. Core and locomotive plugins describing
architecture.
Hello, ram_scan
ram> Such an emulator already exists. It's called MESS http://www.mess.org/.
ram> Open source. The monster is simply awesome. Emulates about a hundred
ram> platforms at the moment. Including a herd of iron speck
ram> (SamCoupe too). I don’t know how high quality it is. I was playing around with him
ram> as with the C-64 emulator for the sake of enlightenment about what kind of machine this is.
ram> But it is completely abstract. Core and locomotive plugins
ram> describing the architecture.
in mess plugins? I collected it, looked at the sources... IMHO it’s not abstract at all,
just a bunch of separate emulators using a common video/sound/control framework and
processor emulators.
Is it possible, for example, to add trdos to the existing Spectrum emulation,
not cutting down the sours, but just adding your own?
Hello, boo_boo
What's the point of plugins if the project is open source? Plugins are made in those
projects where the sources are closed, so that a program with closed sources can be
expand with binary modules. And if the project is open source, then just
the next module (.c/.cpp file) is added to the project and that’s it, then the project
recompiled.
Hello, boo_boo
boo> judging by the comments in this thread, no one needs it, and I myself do
boo> I can dig into some sources, so the idea is shelved and goes
boo> forest
sorry :(
The beauty of the plugin approach is that even a non-programmer like me can
screw something on. and I don’t pay any price for the source code of the same unreal
I can handle it
Hello, boo_boo
boo> anyway... judging by the comments in this thread, no one needs it, but I myself
boo> I can dig into the sources, so the idea is shelved and
boo> walks through the forest
But in vain, it’s better to make one emulsion that supports everything you need than
produce 10 pieces, where one supports one thing, and the other supports something else. B
in this regard, it would be more logical to develop unreal (since SMT has given up on it (he himself is in
I admitted this in a forum thread about my emulsion)). Nobody bothers you to shovel
Unreal varieties because you want, because the author doesn’t support it anyway.
Hello elf/2
I would understand if in unreal everything was crammed into one long, very long
text file without end or edge. But there is modularity there. Everything is broken down by
sections. Here's the sound, and here's the tr-dos emulation. Separately kernel emulation, and
separate video signal generation. You can’t handle it, right? Can you manage to write your own?
And how many years will it take you? What will be the way out of this? Then he will come
hour, you will learn to master such projects in no time at all, rivet them like
hot cakes, and you will find that in addition to this you have 10 more projects, and
at least 2 of them (but not the emulsion) are priority and more important. And then you
as SMT say, yes I scored. Or as I say: I don’t have time. Wait with
one year old...
A small imho: deal with unril, everything is simple there. It's just simpler
do nothing at all.
Hello, Vladimir Kladov
Vla> ...Everything is divided into sections. Here's the sound, and here's the emulation
Vla> tr-dosa. Separately emulation of the kernel, and separately formation
Vla> video signal. You can’t handle it, right? Can you manage to write your own? And how much
Vla> years will you need? What will be the way out of this? Then he will come
Vla> hour, you will learn to master such projects in no time at all, riveting them
Vla> like hot cakes, and you will find that in addition to this you have 10 more
Vla> projects...
it's simple for monsters like you, boo_boo or SMT himself :) sit down
half an hour to understand what is where and correct a couple of lines of code. and most importantly then
I've been supporting this for many years.
my limit is a hundred lines of code using the standard API. preferably
written in one or two evenings... I won’t have enough for more.
but if boo_boo makes a reasonable API and several examples of plugins, then
people like me can at least somehow help with further development
Hello, Vladimir Kladov
Vla> Little imho: figure out the unril, everything is simple there. Easier
Vla> just do nothing at all.
I absolutely support it, everything is done in the form of separate files, and the fact that they are all
are included in one main file - so as not to depend on global
intermodule optimization. You can figure out the source code in one evening, I
it was necessary to make magik work correctly on scorpion (SMT me then
gently sent him away, saying - do it yourself), I did it in just 15
minutes, although I had never even seen Sorts before. There are sorts of "cat"
cried”, these are not Windows NT sources, where there are hundreds of megabytes.
What is missing in Unreal is recording video to an avi file (this was written in
thread about demos) and I think you can find a lot more that someone is missing.
Hello, Vladimir Kladov
Vla> Little imho: figure out the unril, everything is simple there. Easier
Vla> just do nothing at all.
I've had to shovel other people's trash so many times at work that it makes me sick
this matter :rolleyes;
A; if essentially, then
1) Anril cannot be called modular in any way (except in comparison with emuls like
zx32), only the sound in the latest versions is taken out separately
2) it is written in a mixture of C and C++, and under win32/visualC (it only seems
that there is only one S everywhere, and I ported the VG-shku for a week to juniors)
about plugins - I’m thinking of not making it all a plugin emulsion, but attaching it to
a monolithic emulator with basic functionality, a sort of analogue of the zx system connector.
like the one from Shalaev.
although first, of course, it comes down to the basic functionality.
Hello, boo_boo
IMHO: in C/C++ there is no concept of a module. There are classes and namespaces and this
not modules at all. But by modularity I mean a breakdown into parts that
corresponds to the idea of modularity. The contents of the part are intended for
performing some coherent tasks, or putting together some groups of code,
which can be combined into a category and said in one phrase - for this reason. B
In this sense, there is modularity in unril, and it does not depend on the language. And in general
A module is an extra-linguistic concept, what does C and C++ have to do with it. And in Pascal you can do this
screw it up, scatter one module among different units, and several modules in
mix in one module. It just depends on the programming style. At SMT
the style is excellent. I wish there was a normal shell for C/++ to make it more convenient
find a description of this name by name, otherwise you have to search through files
rummage. In this sense, the same MSVC is more difficult for the specialists than for us, the Pascalists.
fails in most cases, cannot indicate what grows from where.
Hello, Vladimir Kladov
Vla> I wish there was a normal shell for C/++ to make it easier to find
Vla> by name description of this name, otherwise you have to search through files
Vla> rummage
There are corresponding plugins for FAR. And also all sorts of editors like
Ultraedit/UltraeditStudio which support ctags.
Hello, Vladimir Kladov
Vla> the same MSVC fails in most cases
Well, this program solves all these problems http://www.wholetomato.com/.
In it you can see where which function is called from and go to
declarations and implementation of any function/macro.
Hello, Vladimir Kladov
Vla> IMHO: in C/C++ there is no concept of a module. There are classes and
Vla> namespaces and these are not modules at all. But by modularity I mean
Vla> breakdown into parts that corresponds to the idea of modularity.
Vla> The contents of the part are intended to perform some related tasks
Vla> or brings together some groups of code that can be combined into
Vla> category and say in one phrase - for this reason. In this sense
Vla> there is modularity in unril, and it does not depend on the language. And in general the module
Vla> is an extra-linguistic concept, what does C and C++ have to do with it. And in Pascal you can
Vla> screw this up, scatter one module among different units, and
Vla> mix several modules in one module. It's just a matter of style
Vla> programming depends. SMT has great style. I wish there was
Vla> normal shell for C/++, to make it easier to find by name
Vla> description of this name, otherwise you have to search through the files. B
Vla> in this sense, the same MSVC is harder for us, PascalistsVla> fails in most cases, cannot indicate what is growing from where.
C and C++ have nothing to do with it, I’m just saying that in Enril there is a vinaigrette of two languages,
which imply a completely different approach to writing programs.
IMHO a module is a thing in itself that can be used through a set
abstract interfaces, without delving into what is happening inside.
classes can be considered modules, but then there must be encapsulation, and in anril
a bunch of pseudo-classes (pseudo, because there is no encapsulation or inheritance in Anril
are used, that is, classes are used as a way to visually combine functions and
data) related to each other directly (up to direct access to
data fields), and through a bunch of global variables.
So I can’t agree with SMT’s excellent code organization style...
but his approach to optimization is really excellent, and the algorithms
implemented cool, I care about this like I care about a heavenly star :rolleyes;
MSVC-shnaya; The shell is a nightmare, but there are a ton of third-party refactoring programs. only
IMHO code with well-designed interfaces (structural or object -
not the point) the good thing is that you can figure it out anyway.
Hello, boo_boo
boo> I have had to shovel other people's trash so many times at work, which is bad
boo> already from this matter :rolleyes;
boo>; and if essentially, then
boo> 2) it is written in a mixture of C and C++, and under win32/visualC (this is only
boo> it seems that there is only one C everywhere, and I ported the VG-shku for a week to juniors)
boo>
A mixture of C and C++ is not so scary. The worst thing is the continuous sharpening for x86 and
little-endian. This is where you'll break your head trying to figure out where to go
rotate bytes and where not. :v2_crazy: