about the video controller
ZXNet echo conference «hardware.zx»
Hello, All
the idea arose to write an emulation of the subject, and not so that it would somehow work, but so that
worked more or less on the principle of a piece of iron. but I imagine these principles
vaguely. plz read and correct me where I'm wrong ;)
as I understand it:
Screen drawing begins at the edge of the frame sync pulse. screen
The image is displayed along the lines, two pixels per clock. along the edge of the quenching pulse
(which is formed by the decline of the horizontal sync pulse) drawing the next
line stops, the beam moves to the beginning of the next line, and in decline
The damping pulse (pentagon: 32 clock cycles) begins to draw it.
the upper part of the border is displayed (64 lines; what, I wonder, is this determined by?).
then the drawing of 192 lines begins, including the Spectrum screen
and border strips on the sides. first draw the left curb ear, width
which (pentagon: 36 clock cycles) is determined, it seems, by some kind of counter
controller, I'll call it "D"; then 256 pixels of the image -- the controller takes from
memory bytes of pixels, bytes of attributes, stores them in their registers, draws, and
so every 8 pixels. then according to counter D the drawing of the border begins again
- right ear, it ends with the arrival of a horizontal sync pulse, and so on
all 192 lines.
now the border is drawn again, its lower part, until then (pentagon: 48
lines) until the frame sync pulse arrives, upon the decline of which it beginsreverse vertical scanning (3584 clock cycles). and then everything repeats itself
first.
Now it’s unclear: the number of clock cycles per line (including backtracking) for all specs,
as far as I know, one. and the number of lines is different, that is, the size of the frame
different too. but you can’t order a CRT, it must work out its 50Hz... than
Is this really compensated by the frequency of the clock generator?
Hello, boo_boo
boo> now it's unclear: the number of bars per line (including backtrack)
boo> of all the specs, as far as I know, there is one. and the number of lines is different, then
boo> the size of the frame is different too. but you can’t order a CRT, it must
boo> work out your 50Hz... how is this compensated, really by frequency
boo> clock generator?
Firstly, the number of bars in a line is not the same for everyone,
and secondly, this is fully compensated by the different frame rates.
Those. for example, at the Pentagon, due to its 320 lines in the frame, instead of 312, personnel
the frequency is somewhat low. But the monitor doesn’t care - it synchronizes under
any within certain limits (45..55Hz, for example)
Hello, boo_boo
boo> I'm thinking of writing another spec emulator
For what platform?
Hello Titus
Titus said everything correctly. But in general, what is the purpose of all this outrage?
Hello, The Exploited
The> Titus said everything correctly. But in general, what is the purpose of all this outrage?
The goal is software emulation of the subject. I'm thinking of writing another spec emulator ;)
Hello, The Exploited
In addition, all those that are multicolor emulate scanning.
Hello, boo_boo
boo> the goal is software emulation of the subject. I'm thinking of writing a spec emulator
boo> next
There are a ton of them ready-made - emulators, and even with source codes. and there are also a lot of subjects
different
Hello, Black_Cat
Bla> For which platform?
for Linux and Windows at least...
The> there are a ton of ready-made emulators, and even with source codes. and subject
The> also a lot of different ones
a ton only for Windows, with sources half a kilo, with no clear sources
almost
Hello hero
her> In addition, all those that are multicolor emulate scanning.
yes, but this emulation is usually written according to the principle “so that all multicolor
worked." in the spirit - something has gone wrong here, I need to add a couple of bars. and figs
then you'll understand what's what
Hello, boo_boo
Will there be classic computers? and if not, then nothing interesting. Everything in unril
already exists for USSR clones, in terms of multicolor. And where is “a couple of bars”?
added?
Hello, Vladimir Kladov
Vla> will there be classic computers? and if not, then nothing interesting. B
Vla> unril everything is already there for the USSR clones, in terms of multicolor. And where
Vla> has a “couple of bars” been added?
classic ones are planned, but first something simpler, of course.
in Anril, emulation is focused on results, and not on repeating architectural
chips of the computer, it’s not noticeable from the outside, but it’s difficult to understand the code, everything in between
mixed up...
well, anril is only for Windows, but here in Linux I feel sad without a normal emulator
:rolleyes:
Hello, boo_boo
What are you going to write on?
Hello jager
Well, there is not much choice on what to write, the question is rather about frameworks/libs.
Hello NovaStorm
jag> What are you going to write on?
in pure C ;)
Nov> Well, there is not much choice on what to write, the question is rather about
Nov> frameworks/libs.
yes, there is more choice here. probably SDL, since it works on a lot of things, including
Nintendo ds, which I sharpen my teeth on
Hello NovaStorm
Nov> If in pure C, then what will happen to the GUI? The console is of course correct,
Nov> but, alas, it’s not always convenient.
Nov> SDL is of course a natural choice, but about NDS it seems you have to
Nov> wait, it seems a bit damp. Moreover, it is unofficial, and this is not the case
Nov> even in trunk 1.3?
What for in the emulsion is GUY? More precisely, let's rephrase the question: why is there a gui written in the emulsion?
not in the same SDL?
2boo_boo; Sound; also needed in SDL. I want to port this emulsion normally without
all sorts of torment with /dev/dsp...
Hello, boo_boo
boo> the idea arose to write an emulation of the subject.............
A little off topic - is there an emulsion for Pocket PeCe?
Hello, Mikka_A
Mik> .. is there an emulsion for Pocket PeCe?
Emulator for PocketPC!(PocketSpeccy) http://zx.pk.ru/showthread.php?t=3924
Hello, boo_boo
If in pure C, then what will happen to the GUI? The console is of course correct, but alas not
always convenient.
SDL is of course a natural choice, but it seems like NDS will have to wait,
kind of damp. Moreover, it is unofficial, and it is not even in trunk 1.3?
Hello, Q-Master
A separate GUI from SDL is needed to get rid of bicycle construction. And if
indicators and simple elements can be made even in SDL, for example in
guichan, then it’s still better to have normal settings and the file opening dialog.
PS; AND; yes, a normally written emulsion will not need porting,
only in recompilation =)
Hello NovaStorm
Nov> A GUI separate from SDL is needed to get rid of bicycle construction.
Nov> And if indicators and simple elements can be made at least in SDL, at least
Nov> for example in guichan, then the settings and file opening dialog are the same
Nov> it is better to have normal ones.
Nov> PS; AND; yes, a normally written emul does not need to be ported
Nov> will only be in recompilation =)
Take wxWidgets and build the whole guy on it, and then compile it to hell
bald. In general, cross-platform free gui-libs are like sand in the sea.
Hello NovaStorm
Nov> mind me. Moreover, the language is C, not C++. That's why I
Nov> inquired... There are fewer Sish guys, and the most developed of them(?)
Nov> GTK+ under win32 fear and horror.
Nov> Okay, that means the console =)
No sane guy would write in C. And it is God’s command to interfere with both languages,
because it's the steering wheel :)
Hello icebear
ice> Takes wxWidgets
mind me. Moreover, the language is C, not C++. That's why I asked...
There are fewer crazy guys, and the most developed of them(?) GTK+ for win32 is fear and horror.
Okay, so the console =)
Hello, boo_boo
boo> hmm, why isn't GTK+ a GUI library in C? a bunch of completely sane ones
boo> applications are written. although for the emulsion IMHO it’s better to make a gui yourself
It depends on which GTK :) if gtkmm, then it’s in C++. but in general, gui in C was enough for me
WinAPI, I don't want it anymore.
Hello NovaStorm
Nov> If in pure C, then what will happen to the GUI? The console is of course correct,
Nov> but, alas, it’s not always convenient.
Nov> SDL is of course a natural choice, but about NDS it seems you have to
Nov> wait, it seems a bit damp. Moreover, it is unofficial, and this is not the case
Nov> even in trunk 1.3?
GUI on a scale sufficient for the emulator is normally done manually on the same
SDL - just that, settings and dialogs for reading/writing files, and a debugger.
There will be no mouse support, everything will be done with buttons ;)
about NDS; To; By the time I make the emulsion, you'll see an SDL port for it
dry :rolleyes;
QMa>; The sound also needs to be in SDL. I want to port this emulsion normally without
QMa> all sorts of torment with /dev/dsp...
it would be better, but there will be such a lag... in general, still without support
no native sound.
ice> No sane gui will write in C. And God interferes with both languages
ice> punished because the steering wheel :)
hmm, why isn't GTK+ a GUI library in C? a bunch of quite sane applications
written. although for the emulsion IMHO it’s better to make it yourself
Hello icebear
ice> It depends on which GTK :) if gtkmm - then it is in C++. in general, gui on With me
ice> was enough in WinAPI, I don’t want any more.
that GTK, which is not mm ;) bullshit through WINAPI is full guard, that’s for sure, but
It's not C's fault, but the WINAPI designers' fault. It's ok to sculpt shit in GTK
quite.
but as for emuls, in 90% of the emuls I have seen with a convenient GUI, this GUI
was self-written.
Hello NovaStorm
Or maybe think in advance about using different GUIs? Those. GUI
on Qt, KDE, GTk... Otherwise, as always in Linux, the butts look like hell
what. In one there is one look and logic (philosophy) of the GUI in the other another.
And for some reason I don’t understand why write your own GUI (as I understand it, we are talking about another
library), if so much has already been written?!
Hello jager
If you suddenly decide to develop an architecture for different GUIs, i.e. GUI in the form
plugin, then I can start implementing the GUI in Qt/KDE. Experience with Qt, GUI design and
the taste (I draw a conclusion based on user reviews) is there. :-)
Hello, boo_boo
Can you provide an example of an emulator with a good GUI? And then something other than zsnes nothing
I don't remember anything normal...
And as for the bicycles - guichan looks pretty decent, works like a pure one
SDL and OpenGL.
If you make sound for “large” OS, then you can look at OpenAL.
Hello NovaStorm
Nov> Can you provide an example of an emulator with a good GUI? And then something other than zsnes nothing
Nov> I don’t remember anything normal...
Nov> And about the bicycles - guichan looks pretty decent, it works
Nov> on pure SDL and with OpenGL.
Nov> If you make sound for “large” OS, then you can look at OpenAL.
Well, for example, the good old z80 Gunter, x128. simple but functional.
guichan for C++, but IMHO it’s extremely bad to interfere with C and pluses. besides, all these
full-fledged (with mice, windows, etc.) guis are good in spreading graphic
program, for example CAD - there are a ton of modes and options, but the user has it in his hand
mouse, it’s all about poking at the buttons and controls. in the emulsion you just interfere
it will be simpler hot buttons, file selector and keyboard controlled
configuration editor. The debugger is again much more convenient to use with
keyboards.
openAL... hmm, why not :)
Hello jager
jag> Or maybe think in advance about using different GUIs?
jag> That is. GUI on Qt, KDE, GTk... Otherwise, as always in Linux, butts
jag> look like hell. In one there is one view and logic (philosophy)
jag> GUI to another other.
I'm leaning towards one idea here. namely, do not do any GUI in the emulator at all,
except for the file selector and debugger, and for editing the configuration just
you can write a separate editor in Qt or Gtk. there seems to be no downsides to this
solutions, only advantages. :rolleyes;
jag>; And for some reason I didn’t understand why write your own GUI (as I understand it, we are talking about
jag> another library), if so much has already been written?!
no, we are not talking about the library :D