command BIT n,(HL)
ZXNet echo conference «zxnet.pc»
Hello, All
Does anyone know what ends up in the 3rd and 5th bits of the flag register after
performance of the subject? Sean Young in his "z80 documented" refers to some
internal Z80 register associated with 16-bit addition, where, they say, these
bits are taken, but - no specifics :(
Hello, boo_boo
I implemented it exactly as they said. This internal register receives
as the value the result of the most significant byte of any internal double-byte
operations, including operations to calculate the jump address in JR/DJNZ, not
ADD/SBC HL/IX/IY,rp only.
Hello, Vladimir Kladov
Vla> I implemented it this way
By the way, does EmuzWin pass ZEXALL?
Hello, Vladimir Kladov
I implemented Vla> exactly as they said. This internal register
Vla> receives the result of the high byte of any as its value
Vla> internal two-byte operation, including calculation operation
Vla> transition addresses to JR/DJNZ, and not just ADD/SBC HL/IX/IY,rp.
hmm...
I found something in more detail: http://www.work.de/nocash/zxdocs.htm
here, for example, it is said that any instruction with the operand (HL) MEMPTR is not
changes :o
Hello, boo_boo
boo> by the way, does EmuzWin pass ZEXALL?
what is this - zexall??? program - test???
Hello, Vladimir Kladov
Vla> It is possible to completely achieve 100% accuracy if you have it at hand
Vla> iron, but not interesting except for sporting purposes.
For me, an emulator is not a full-fledged emulator if it does not emulate a computer on
100% ;)
Hello, Vladimir Kladov
Vla> in this case, there are no full-fledged emulators. Enough for
Vla> website http://www.mdfs.net/Software/Z80/Exerciser/Spectrum/ view
Vla> and make sure that this test gives incorrect results on real hardware
Vla> results, hehe.
Vla>
Vla> But there are also differences between Z80 chips from different manufacturers...
If it gives incorrect results on real hardware, then what is it written for? ;)
As for the different Z80 chips, this is highly doubtful. At one time there was
there are a lot of debates on this topic, and as a result no one has been able to provide
chip different from the 'original'. I even remember MacBuster (formerly SAV-Soft)
I bought a bunch of samples from different manufacturers in order to find the differences, and,
Naturally, I found nothing.
p.s.: Naturally, we mean the Z80, and not its various 'continuations',','... Titus aka Andrey Aleksandrovich Titov
Hello Titus
in this case, there are no full-fledged emulators. Enough on the site
http://www.mdfs.net/Software/Z80/Exerciser/Spectrum/ look and make sure
that this test also gives incorrect results on real hardware, hehe.
But there are also differences between Z80 chips from different manufacturers...
Hello, boo_boo
No, it does not pass, and glory to the Almighty. Not a single emulator and not a single real one
iron does not pass it. Want the most reliable test? Turn on support
RZX files, download ready-made RZX records, make your own RZX records in others
emulators and drive until you are stupefied. That's when 99% of these recordings will work
(which run on at least 2 more emulators - there are records
“wrong” ones, which only work on the emulator on which they were
written down), then you can safely assume that everything is in order and is being done
almost 100% accurate for emulation purposes.
It is completely possible to achieve 100% accuracy if you have hardware at hand, but
not interesting except for sporting purposes. There is such a feature, it’s called ULA.
To account for delays and not slow down too much, most emulators work
according to the tables, and only take into account which bank the team starts in. A
if a 4-byte command, for example, starts in a slow bank and continues
in a fast bank of RAM, the cycles will be counted incorrectly. This also applies
the performer, and reel the spec (I did it right at home, but in order for this
show, you need to specially make a multi-color demo, but it’s a bummer for me).
Hello, Vladimir Kladov
Well, I don’t look at the letters OK, but at the results: I compare mine with those that
in real life they come out... everything matches, but this bit doesn’t... okay, what the hell with it - but
In the course of perversions, I “achieved” once that the ROM was buggy, but the test was fine
showed.. hehe :rolleyes:
Hello, Vladimir Kladov
funny test. Only I was never able to emulate the subject command.
True, I ran the test on different emuls, here
File: emuls-z80test.rar http://zx.pk.ru/attachment.php?attachmentid=2634
Hello Titus
There are differences, but no one will tell us what they are. However, John Needle
in my Spectator, I made an option to select the version of the crystal, and from this
At least 1 multicolor demo works differently. There is a choice of chips
would and RS.
Hello SMT
SMT> fun test. only I was never able to emulate the subject
SMT> command. True, I ran the test on different emuls, here
Not bad :) You can immediately see how much it costs ;)
Vla> there are differences, but no one will tell us what they are. However, John
Vla> Needle in his Spectacler made an option to select the version of the crystal, and
Vla> this makes at least 1 multicolor demo work differently.
Vla> There is a choice of chips, like RS.
While no one has seen these 'different' crystals, there is no point in saying that
they are out there somewhere. The most important thing in all this is that not one, at least more
less mass-produced ZX clone, no Z80 with crystal seen yet
different from the original. If anyone has met you, please come to the studio! ;)
Hello Titus
Tit> If it gives incorrect results on real hardware, then what is it written for? ;)
God knows. By the way, the author of yaze (and the test, respectively) is impudent for any BIT
does F=A&28h. and everything “fits together” for him. I scored these test "OK" and
I’m just comparing the CRC for my kernel with the CRCs that come out in real life.
about “100% emulation”: obviously, no one has really figured out what it is
for the "internal register", and what opcodes influence it - judging by
results that SMT posted...
moral: if you don’t want the program to run under emulators, just clog it
its flag register after bit n,(hl) ;)
Hello Titus
I wouldn't trust the results that much. And precisely because of the presence of that same
internal register. And what else could affect the result? No wonder on
on real hardware the test breaks down: its result for some commands may
depend on the result of completely different commands, which were executed in a completely different
moment in time. And if also from jump commands (internal register), by
It turns out that how and with what I compiled the program itself is what I got.
What if you run the test on real life once, and then another time, and compare
result? What if on 2 different realities?
And it also seems to me that this test works with interrupts enabled, i.e. everything
time intervenes (when it pleases) int38, and again spoils this
internal register No, that's not how tests are done.
Hello, boo_boo
something about disabling interrupts - I didn’t notice (when I started it,
stopped several times in the debugger, for some reason it is often at address 38
stopped. I'll have to take another look). But in an amicable way, in the test for bit it would be necessary already before
with each command do something like ADD HL,DE (and put zeros there).
Hello, boo_boo
Well! Well! so what's next? Is the author of the test an idiot or not?
Who has a real one - ran the test several times, as suggested?
SMT, what are the results of running on other emulators?
Hello, Vladimir Kladov
Vla> No wonder the test fails on real hardware: its result for
Vla> of some commands may depend on the result of completely other commands
Vla> which were executed at a completely different point in time. And if also from
Vla> jump commands
the author of the zexall port on spec thinks that he screwed up somewhere, so crc is not
converge. regarding bit n,(hl) this is definitely true, the assembly address is
changed.
Vla> And it also seems to me that this test works within the permitted limits
Vla> interrupts, i.e. interferes all the time (whenever he pleases)
Vla> int38
No, the author of the test is not an idiot - he disables interrupts.
Hello, Vladimir Kladov
Vla> something about disabling interrupts - I didn’t notice (I when
Vla> launched, stopped several times in the debugger, for some reason it
Vla> often stopped at address 38.
and it is immediately before the initialization of registers and execution of the test
instructions disables interrupts. however, in the case of the subject this is not so special
saves -- between call nz, test (which initializes the "esoteric register"
jump address) and di can skip the interrupt.
Hello, Witch Doctor
> Well... It can't be emulated on unreal - so, which one can it be emulated on? And what is this
> means ?
I didn’t understand the question, especially the last one. to understand what this means, read
accompanying document and texts from the person who ported it to the Spectrum.
it is clear that if the compilation address has changed, the flags that came from the address
registers too
Hello, Witch Doctor
> SMT, what are the results of running on other emulators?
Which ones are you interested in? I don’t have DOS, Linux or commercial ones
Hello, boo_boo
Hmm. How does call nz initialize the hidden register? I understand this one
the register gets the value after internal additions, for call and jp addition
it seems like it has nothing to do with it.
Hello SMT
Well... It can’t be emulated on unreal - so, but which one can it be emulated on? And what does this mean?
Hello, Vladimir Kladov
Vla> Hmm. How does call nz initialize the hidden register? I am so
Vla> understood, this register gets the value after internal additions, for
Vla> call and jp addition seems to have nothing to do with it.
The most detailed piece of information I found:
┌─- CODE ───
Internal MEMPTR Register
This is an internal Z80 register, modified by some instructions, and usually
completely hidden to the user, except that Bit 11 and Bit 13 can be read out at
a later time by BIT N,(HL) instructions.
The following list specifies the resulting content of the MEMPTR register
caused by the respective instructions.
Content Instructions
A*100h LD (xx),A ;xx=BC,DE,nn
xx+1 LD A,(xx) ;xx=BC,DE,nn
nn+1 LD (nn),rr; LD rr,(nn) ;rr=BC,DE,HL,IX,IY
rr EX (SP),rr ;rr=HL,IX,IY (MEMPTR=new value of rr)
rr+1 ADD/ADC/SBC rr,xx ;rr=HL,IX,IY (MEMPTR=old value of rr+1)
HL+1 RLD and RRD
dest JP nn; CALL nn; JR nn ;dest=nn
dest JP f,nn; CALL f,nn ;regardless of condition true/false
dest RET; RETI; RETN ;dest=value read from (sp)
dest RET f; JR f,nn; DJNZ nn ;only if condition=true
00XX RST n
adr+1 IN A,(n) ;adr=A*100h+n, memptr=A*100h+n+1
bc+1 IN r,(BC); OUT (BC),r ;adr=bc ii+d All instructions with operand (ii+d)
Also the following might or might not affect MEMPTR, not tested yet:
OUT (N),A and block commands LDXX, CPXX, INXX, OUTXX
and probably interrupts in IM 0, 1, 2
All other commands do not affect the MEMPTR register - this includes all
instructions with operand (HL), all PUSH and POP instructions, not executed
conditionals JR f,d, DJNZ d, RET f (ie. with with condition=false), and the JP
HL/IX/IY jump instructions.
└── CODE ───
Hello, boo_boo
I made a test on my knee for bit (hl)...
plz, whoever has real money at hand, run this thing there, and post the scr with
the chaos that formed on the screen.
let's compare ;)
File: btst.zip http://zx.pk.ru/attachment.php?attachmentid=2640
Hello, boo_boo
It was the author of the port who sent it to Spectrum. this lies in the same place where boo_boo took the text about
memptr. and the link was here somewhere. so scroll up the topic and you will see everything
Hello, boo_boo
very interesting info, bo-bo. By the way, SMT, your first column is yourself
did you drive real? (And when I only had time, perhaps only on turbo...)
Hello SMT
SMT> this is in the same place where boo_boo got the text about memptr.
Nope, here's the link: http://www.work.de/nocash/zxdocs.htm#z80garbageinflagregiste
Hello SMT
SMT, what port? Is this this one: http://www.work.de/nocash/zxdocs.htm
up... this is up for you, and down for me (my settings are as follows: well, I’m the original,
I do everything differently than others :) ).
I understand about the first column. I suggest (again) someone else to drive on
in real life Preferably 2 times and/or 2 reals. If there is a turbo, you can go turbo
(there may be some difference, though, due to the same int). I really want to do it again
make sure.
Hello, boo_boo
> port of what?
I understand, they ported from cp/m - bdos is mentioned in the source code, and the old address
compilation - #0100
Hello SMT
Here's the thing. I started looking at what was wrong with the CPD[r] commands in my test.
CPI[r]. I found a mistake and corrected it. It started to coincide. But on the way I downloaded the source
US 0.34b, and looked, he does the same as I do with these commands. It turned out that
not at all like that. In SMT's code for CP, for example:
void __fastcall ope_A9(Z80 *cpu) { // cpd
cpu->t += 8;
unsigned char cf = cpu->f & CF;
cp8(cpu, rm(cpu->hl--));
cpu->f = (cpu->f & ~(CF|PV)) | cf;
if (--cpu->bc16) cpu->f |= PV;
}
flags XF and YF are constructed based on the result of the comparison A-(HL). And I have
Yang: YF=bit1 of n, XF=bit3 of n, where n=A-(HL)-HF. The result of "comprehensive"
The test is nevertheless the same in both cases. What is it then?
"comprehensive" test?
Understanding how the Spectaculator executes the command bit 0,b (the first one in this
test, I came across this thing. [...cut: LD SP,(addr) not in the list
affecting memptr, we still need to find which command installed memptr before
hitting 9C09h, hmm] Fact, however: zexall test on the command bit n, (HL)
Spectaculator passes, i.e. its checksum matches the results
Z80(real) speakers for this command (note: the only one of all emulators.
True, he has other mistakes, but last week was truly the most
accurate among all :) ).
Now I’m also trying to “drive away” Spin. Yep, there are results. Here is the updated oneplate [http://bonanzas.rinet.ru/zx/emuls-z80test.zip].
(I haven’t updated my EmuZWin yet, I want to watch something else, and I need to
case fast CPIR/CPDR code correct).
By the way, if you have Linux at hand, don’t worry about replenishing information for the people there.
emulators? Personally, I’m especially interested in Fuse, you can also drive away the glitch (so,
seems to be called an alternative on that platform?).
Hello, Vladimir Kladov
Vla> By the way, if you have Linux at hand, don’t worry about replenishing information for
Vla> local emulators? Personally, I'm particularly interested in Fuse, you can also
Vla> drive away the glitch (that’s what the alternative on that one is called, I think
Vla> platform?).
There is no point in messing with the glitch - bits 5 and 3 of F are not emulated AT ALL.
Fuse is better, ~80% of the test points pass. My kernel (libz80ex) goes through everything,
except bit n, (due to bit n,(hl), which nobody knows how
emulate, and not a single radish has been able to run _my_ test in real life
:mad: )
Hello, Vladimir Kladov
Vla> downloaded source US 0.34b
I haven’t posted 34b2 yet, but it’s different there
Hello, Vladimir Kladov
Is it really possible to download the description of the z80 in some VHDL thread? will such a model lead
yourself as a brand. or kernel writers are in the same position and might have missed it
undocumented features
Hello, Vladimir Kladov
Maybe real people just don’t see us, because the “Emulators” section is not
are they stopping by? You need to post a request to the hardware section to look here. And then how in
We live in a modern high-rise building, what the neighbors on the site look like and how they breathe - not
we know...
Hello, Vladimir Kladov
Ha! In order for the bit n,(hl) test to pass and coincide with the Z80(real) column, you need to do
pen to Yang, and simply reset XF and YF after this command...
Either Young had the wrong processor on his hands, or one of two things. But that's exactly it
Spectaculator works. And apparently no matter what processor
selected. Hmm here. But even in some formats snapshots are saved now
the value of this register, with a comment that they say it affects the flags in
the result of the command is exactly bit n,(hl)
And with bit n,(ix+n) the trick is this. Young may be right here. But I tried
make a couple of feints. For example, nullify them. And the test still passes! (I,
Of course, I understand, maybe IX always points itself to such an address that
((IX+1)/256)&28h=0. But then such a test is worthless!).
In general, people. If there are no real people willing to cooperate in order
confirm or, on the contrary, dispel rumors about the MemPtr register, then we have nothing to do here
we will achieve it. At the moment, the results show: the very existence of this
register, perhaps the result of working with a specific (burnt? left?) Z80. Or
that test was not run on a real branded Z80, but on some fake
(from China?). It doesn’t even seem to affect the CPDr and CPIr commands. What other
teams supposedly take flags from it? (Now it turns out that the rumors about memptr are not
more than a myth, like Raksla in the Spek elite... ;) )I'll go and see where my shifts aren't working so well.
Hello SMT
SMT> is it really possible to download the description of the z80 in some VHDL thread? will there be one
SMT> model behaves like a proprietary one. or core writers in the same
SMT> position, and could have missed undocumented features
download for real, with opencores - t80/tv80... only Zilog sources z80 with
I didn’t share it with people, so the authors of these nuclei also worked according to the descriptions.
Hello, boo_boo
boo> what is written in * is either half crap or was checked for
boo> another crystal. Young has practically nothing written, but what he has
boo> matches...
boo> in general, no one knows anything. to figure it out, you need to drive a LOT
boo> tests, in real life, preferably on several reals O__o
Well, this myth about the presence of DIFFERENT crystals among the population is not true.
Maybe (and even then, deep hypothetically) there was some other crystal, but
there was no documentary evidence of this, and in Spectrums there was no such
There was no crystal noticed either! :|
Hello, boo_boo
thanks to Wlodek (here [http://zx.pk.ru/showthread.php?t=2586]) my undertest
bit 0, (hl) bore fruit. very strange fruits...
in each cell in the picture -- 3 and 5 bits F after clearing the flags, executing
specific command, and subsequent bit 0,(hl)
(hereinafter the asterisk denotes this
[http://work.de/nocash/zxdocs.htm#z80garbageinflagregister] document)
cells 1-3: LD A,(FFXX) -- flags are set. it looks like it really goes to memptr
the address (or address+1, as they say in *?), needs to be checked in more detail.
4-6: LD (FFXX),A for A=0,FF,AA -- empty. (that is * lying). or this command
does not affect anything at all, or simply resets memptr (by the way, it is LD
(addr),A at A=0 I do when clearing the flags, hoping that it is, as stated in
*, will make MEMPTR=A*0x100, that is, it will reset it to zero. seems to be one way or the other
this way it resets to zero O__o)
7-12: ld (FFFE),rp for BC,SP,DE,HL,IX,IY - installed, again it looks like
memptr goes to address or address+1.
13-18: ld rp,(FFFE) for the same registers - apparently the address is set again.
19: ex (SP),IX with SP=BFE6, (SP)=IX=FFFE -- enabled, who knows, or the address,
or (SP)
20: ADD HL,BC with HL=FF00,BC=1 -- enabled.
21: ADD HL,BC with HL=FFFF,BC=1 -- disabled. apparently for ADD HL,BC in memptr
the result of the operation is received.
22-23: similar for ADC, same result.24-25: similar for SBC, same result! wow, where do the zeros at 3 and 5 come from?
bits after subtracting 1 from FFFF?
26 -- rld for HL=FFFE, bits enabled
27 -- rld for HL=FFFF, disabled
28, 29 -- the same for rrd
30,31,32: JP, JR, CALL C3XX -- off, but this doesn’t mean much, since
I chose a stupid address -__-
33,34: JP z,FFFF and CALL Z,FFFF with reset Z. enabled. indeed for JP and
CALL memptr changes even if the condition is not met.
35,36: in A,(F0) and in A,(FF) at A=0. off.
37: in A,(C) at BC=FFF0. included.
38: in A,(C) with BC=FFFF. off. looks like memptr=bc+1 as in *
39-40: OUT (FF),A with A=FE and A=FF. off.
41: OUT (C),A at BC=FFF0. included
42: OUT (C),A at BC=FFFF. off. situation similar to in A,(C)
43-62: ldi,ldd,ldir,lddr,cpi,cpd,cpir,cpdr in several versions. empty.
63-70: ini,ind -- empty.
71-78: outi,outd -- empty.
79-86: inir,indr -- empty.
87-94: otir,otdr -- empty.
95: IM2, EI, HALT with I=FC -- __only__ 5 bits are set!
96: nonsense, I wanted to check JP IX, but forgot to do JP %)
97: inc (hl) -- empty
98: rlc (ix+1) with ix=FFFE. installed.
99,100: RLC (HL) for HL=40xx and FFFF. empty.
-+-----------------
conclusion: what is written in * is either half crap or was tested on another
crystal. Young has practically nothing written, but what is there coincides...In general, no one knows anything. to figure it out, you need to run a LOT of tests, on
in real life, preferably in several reals O__o
Hello, Vladimir Kladov
What's the point of running ALL tests? When I was debugging us, I ran it selectively. the most
long test - arithmetic-logical commands with an accumulator, it is difficult
does not cause any emulator. I think the bit n,(hl) test will take several
minutes in real life
Hello, Vladimir Kladov
Vla> And also, to understand how these tests correlate with zexall, you need to
Vla> run zexall on your computer (at Wlodek's).
Vla> and all this time regularly come up and write down the results from the screen
Vla> and press Enter when it’s time to scroll
Vla> AU! Wladek! especially with you.
I downloaded it and launched it. But I can guarantee that within 11 hours I can regularly
I'm afraid to control his condition :). Now, if it would be possible just for the night
leave...
Hello Titus
in fact, a “different” crystal could easily be obtained after its breakdown
soldering iron with poor grounding. It’s easy: everything (almost) works, but
sometimes behaves strangely. Since it works, people think it's "the same." A
glitches are attributed to lack of sleep or accident.
In addition, it is clearly known that the crystal was produced in different
manufacturers, and not just Zilog itself. Did they get the full
technical documentation? Why then can crystals alone only
3.5-4 MHz work, others at 12 MHz, and others chase right up to 20 MHz. And all of them -
identical? I kind of doubt it.
Hello, Wlodek
The point is to make a correlation with the run that the author did. It
you can do a separate test for bit n,(hl), no problem, that’s what I’m doing
adapted to my assembler to be able to skip only
necessary tests. But, in my opinion, the dog is buried deeper here. It is necessary at least
run on _several_ reals once in order to detect the difference, if it (not
God bless) there is.
Hello, boo_boo
Also, to understand how these tests correlate with zexall, you need to be on the same computer
(at Wlodek) drive away the zexall itself. If he agrees, of course, wait 11 hours
(with a turbo it can be faster, if you have one, but still 6.5 hours, and all this time
come up regularly and write down the results from the screen, and press Enter when
it's time to scroll). Here I made it in the form of TRD, if it’s more convenient in real life
drive (Sorry, I recompiled with some corrections in my
ZXAsm, but I hope everything matches: at least the results of running on emulators
seems to be the same as .z80).
The first time we got a test, which on the Pentagon reaches the first request for
Scrolling no longer responds to the start. I added EI in two places, before
calling 10h (pr-char), and ran the entire test again. Should go for real.
I'd really like to see the results of the live run... Someone, AU! Wladek!
especially you.
File: zexall1-trd.rar http://zx.pk.ru/attachment.php?attachmentid=2668
Hello, Vladimir Kladov
Vla> in fact, a “different” crystal could easily be obtained after
Vla> breakdown by a soldering iron with poor grounding. It's easy: that's all
Vla> (almost) works, but sometimes behaves strangely. It works, people
Vla> they think that he is “the same”. And glitches are attributed to lack of sleep or
Vla> randomness.
Vla>
Vla> In addition, it is clearly known that the crystal was produced in different
Vla> by manufacturers, and not just by Zilog itself. What did they get
Vla> complete technical documentation? Why then can only crystals
Vla> work only at 3.5-4 MHz, others at 12 MHz, and others chase right up to
Vla> 20 MHz. And are they all identical? I doubt it.
With the so-called 'breakdown with a soldering iron', in 99.99% either the entire crystal will die, or
any of the I/O gates...
As for the different manufacturers, it is natural that they did not agree
crystal yourself, but took a ready-made template, or simply packaged it
crystal obtained from Zilog. It’s unlikely that anyone would come up with a brilliant idea
the idea to design the crystal ALL AGAIN :D Yes, even if it came, then they would “float” in itnot only the undocumented bit x,(hl) flags ;)
Hello, boo_boo
boo> someone came up with this idea - see t80, r800, Soviet analogue... and u
boo> any hypotheses about the mismatch of bit (hl) emulation for 2x
boo> tested processors?
Once I had to test undocumented T80 flags - it turned out
one to one. I think there was a Zilog crystal inside. Although some are inclined
to the opinion that it was simply erased, reshot and reproduced again ;)
By the way, perhaps in Turbo processors released by Zilog later something
it was different if they touched the crystal topology.
Yes, and as for undocumented flags, 10 years ago I thought that
I know them all ;)
Hello, boo_boo
Excellent, 100%. To hell with DAA, he still doesn’t depend on XF, YF, and he couldn’t
it won’t match if everything else matches up to the number. But that person (who
adapted the test for the Spectrum) probably ran it on the branded Spectrum, and not on
Pentagon, so I understand?
The most remarkable thing is that this test was passed and gave absolutely the same result on
the same computer on which an equally remarkable test from boo-boo was carried out. Those.
we can say with certainty about the bit n,(hl) command that the test of this command is
this big test converges at all not because its flags are not affected
the desired memptr (because it cannot but influence, and this is proven by a small test
from boo boo). Conclusion: either the CRC in a large test is built using a stupid algorithm, and
different results can easily give the same CRC with a large
probability, or in a large test somehow it always ended up in
memptr is such a value that XF and YF are always zero.
As for the first one (stupid CRC) - this needs to be checked (I’ll look now, there’s
test bit n,(ix+1), so this is what makes me suspicious. If ix happens in
this test is very different, then it is not clear why the elementary flags are cleared
XF, YF leads to the same CRC. If IX is the same, then the author of the test (or the one who
adapted it) and really is an idiot (or simply didn’t know anything about memptr).But about zeroing (point 2 of my reasoning in the paragraph above) the flags in front
executing bit n,(hl). I found out that the closest team that could (and
should in any case) affect changing memptr before calling the test,
this is call nz,9BEFh at 99FEh. According to the source *, then in memptr
hits 9Bh&28h = 08h, i.e. at least XF=1, YF=0. Everything along the way, it seems
memptr should not be touched, according to *.
And now a very interesting picture emerges. Of all the emulators it wins
(ugh, passes) test bit n, (hl) only a showman who didn’t give a damn about memptr
at least for bit n,(hl) and always writes zeros to the YF and XF flags. And how
then would you like to be?
Boo-boo, I want to hear: have you figured out how to emulate bit n,(hl) correctly?
Hello Titus
Tit> It is unlikely that anyone would have come up with the brilliant idea to design
Tit> crystal AGAIN :D Yes, even if she came, they wouldn’t ‘float’ in it
Tit> only undocumented flags bit x,(hl) ;)
someone came up with this idea - see t80, r800, Soviet equivalent... and what do you have?
hypotheses about the mismatch of bit (hl) emulation for the 2 tested processors?
Hello, Vladimir Kladov
Vla> Boo-boo, I want to hear: you figured out how to bit n,(hl)
Vla> emulate?
(btw, boo_boo is read boo-boo ;) ) I think, but there’s not enough data :(
it’s especially muddy with interruptions and ld(nnnn),a for which the results differ by
different computers. Now I’m finishing the test in more detail/volume, based on the boot results
visible :o
Hello, boo_boo
boo> took part in testing:
boo> Wlodek's pentagon with an unknown crystal
boo>
I think it says "Z80A GoldStar" on it. It is unlikely that it will be possible to clarify, because
a radiator has been glued onto it for a long time.
Hello, boo_boo
boo> I am attaching an archive with the test results and the test itself (source for
boo> sjasmplus, quickly and on the knee, I apologize ,)
If you give me a test in TAP or TZX format, I’ll test it on the original ZX Spectrum+.
If necessary, I can see what the stone is worth in it.
Hello, boo_boo
boo> download for real, with opencores -- t80/tv80... only Zilog sources
boo> z80 was not shared with the people, so the authors of these kernels also worked on
boo> descriptions.
There can be no "source" Z80. By the way, this was discussed recently (about two months ago)
in comp.arch.fpga, I already gave the “link” here.
Hello icebear
With CPI/CPD/CPIR/CDPR it is clear:
the first 2 do not affect, the second affect if the command is executed more than 1 time,
the action is the same as for JP at the beginning of the command after each execution.
Boo-boo, confirm. I'll take a look at the 3rd test for now.
(Although of course, why is it different in LD[r]. Although, with logic in general
there may not be a connection. They did it as they had to).
Hello icebear
or the wrong register is in the CPI/CPD. Options: A, DE+1 (what if), BC-1 (then
otkel 1 took), (HL) - looked?, A-(HL). For CPIR/CPDR (and maybe CPI/CPD -
why not) maybe PC (the address of the CPIR/CPDR command itself), and also look
What byte is needed, high or low. I think these are the options
consider, do a thorough test for them, other versions are unlikely to fit
It makes sense to exaggerate now.
(Hmm, what if there is more than one MemPtr, and in several such registers in 1 clock cycle
several increments of several registers are performed, and getting to xy in
bit command can be from any, and not always the same)
Hello, boo_boo
If you look at test 3, then CPI/CPD does not reset anything. If it's correct of course
I realized that in the second pass @set@ means that before the test memptr is installed, and
The check also includes whether the team “resets” it altogether.
By the way, I was tired of looking at test 3. It’s inconvenient to compare. Would you like a memory
initialized somehow before the test, or something. Otherwise, run the test again
becomes uninteresting, + and - cease to coincide at all. Differ by + and -
even iron tests. The text file comparison simply considers everything to be a match
(when I want to compare my results), and I have to stare for a long time.
Horrible!
Hello, Vladimir Kladov
Vla> If you look at test 3, then CPI/CPD does not reset anything. Unless of course
Vla> correctly understood that in the second pass @set@ means that before the test
Vla> memptr is installed, and the check is also made to ensure that the command
Vla> generally “resets” it.
I look at the result of the last test, on the 1st pass, with memptr reset,
all cpi give 00, all cpd also give 00, on the second, with memptr installed, cpi
again they give 00, and cpd 11. Those cpi are reset to zero, but cpd doesn’t care.
initialize memory? O__o.... ok, I'll do it :rolleyes:
Hello, Vladimir Kladov
Vla> It’s clear with CPI/CPD/CPIR/CDPR:
Vla> the first 2 do not affect, the second affect if the command is executed more than
Vla> 1 time, the action is the same as for JP at the beginning of the command after each
Vla> execution.
Vla> Boo-boo, confirm.
about "how is jp" it seems
however, in the previous version of the test, CPI gave a similar result (I don’t remember
under what conditions, there is no source, it needs to be dissembled)...
I’m clarifying the hypothesis - CPI and CPIR reset memptr at BC=1 and initialize it
your address (?or address +1?) in other cases. CPD and CPDR are not touched
memptr when BC=1 and initialize it with the address in other cases.
Tomorrow I'll upload another version of the test - we'll check CP*, at the same time other block ones
teams under similar conditions (what if?), and a bunch of other things.
Hello icebear
ice> If you give me a test in TAP or TZX format, I’ll test it on the original ZX
ice> Spectrum+. If necessary, I can see what the stone is worth in it.
oh great, I'll do it tomorrow, along with a new version of the test :)
Hello, Vladimir Kladov
Vla> Comparison of text files simply considers everything to be a match (when I
Vla> I want to compare my results), and I have to stare for a long time.
Vla> Creepy!
I recommend the CompareIt utility! shows exactly the inconsistencies line by line, highlighting
their color. more convenient.
Hello Sinus
Sin> diff will help the fathers of Russian democracy?
Sin> or if under the name, then the total commander also compares well
Sin>
Take out the small and soft evil offtopics that still have WinDiff - everything is beautiful
colors, showing what has been moved where, etc.
Hello icebear
#ifdef OFFTOPIC
diff will help the fathers of Russian democracy?
or if you’re looking for something, then the total commander also compares well
#endif // OFFTOPIC
Hello Shaos
there are a lot of utilities (I prefer WinMerge), but the trick is that they all come across
to lines with different +/-, even if there were the same 0/1 in the flags. Inconvenient.
So initialize it. Pliz.
(of course it takes 10 minutes maximum to write a utility so that in all files
replaced all + with - in the first column, but it’s also interesting with these flags
look). And, by the way, there is little information in the comments on CPI / CDP (again in the debugger
climb). Well, I was daydreaming. So you say CPI resets to zero. Just resets it to zero, or
Still, does it come from somewhere else? Will there be a disassembly in the next test?
By the way, it seems to me that you can leave those commands that have already been clarified, and
deal only with CPxx, INxx, OTxx (or at least put them at the beginning so that
Is it easier to look at it with a debugger) Or is something else not joining up?
Hello, Vladimir Kladov
Vla> everyone comes across lines with different +/-, even if they are identical
Vla> 0/1 in checkboxes. Inconvenient. So initialize it. Please.
no need to initialize :) there is no need to output bits other than 5 and 3 at all - this is
the same flags after bit (hl), with which everything is clear, and from the previous command only C
remains. if you are interested in C, I can leave pluses, and in front of bit (hl)
set hl, otherwise this hl jumps around everywhere, it’s not surprising that the flags
always different :rolleyes:
iron theme in a couple of minutes
Hello, CHRV
CHR> I have a feeling we'll get a CPUid test soon ;).
oh, I was just thinking about this recently - add a fortune to the sum to be sure
flags _before_ bit (hl), also a DAA test, and as a result a good CPUid
it will work :rolleyes:
Hello icebear
ice> If you give me a test in TAP or TZX format, I’ll test it on the original ZX
ice> Spectrum+. If necessary, I can see what the stone is worth in it.
here it is :)
File: btest4_tap.zip http://zx.pk.ru/attachment.php?attachmentid=2704
Hello, boo_boo
boo> ...added detailed tests for block commands.... I'll post another one
boo> hardware test in a couple of minutes
I have a feeling we'll get a CPUid test soon ;).
Hello, boo_boo
a little about bits 3 and 5 is in the article 'system' spectrophone 11
Hello, boo_boo
boo> here :)
OK, I'll do it. Does this test store any results? I'll have to somehow
drive it back to TAP, but I don’t know how to do it yet. Therefore immediately
there will be no result, but I will try as quickly as possible, I’m interested myself :)
Hello, goodboy
goo> a little about bits 3 and 5 is in the article 'system' spectrophone 11
Young also has all this (and more and more detail). with 3 and 5 bits F that's all for a long time
understandable for all instructions... except bit n,(hl):rolleyes:
Hello icebear
ice> OK, I'll do it. Does this test store any results? I'll have to
ice> somehow drive them back into TAP, but I don’t know how to do this yet.
ice> Therefore, there will be no results right away, but I will try as quickly as possible
ice> I’m interested myself :)
yeah, writes a log at the end, the usual save -- the address/block length is indicated in
Vasike.
Hello, boo_boo
boo> z84 there? interesting... this is how trd is read/written on a sprinter like
boo> Will it all take a couple of minutes?
Z84C15. The sprinter is working, it will be possible to test it quickly. By the way, on turbo
or not? I'll take the latest version of the test (5), from which I have already made a WAV, so that
upload to ZX Spectrum+ :) Yesterday it didn’t work :(
Hello, boo_boo
boo> not bad! :) ...people, who has real money? maybe so?
By the way, I can check on the Sprinter which is Sp97. But it all comes down to time :(
Hello RamTop
Ram> Guys, do you need the Z80H for the test? It’s at home, now marked
Ram> I can’t look at it. True, I don’t have any real money left.
not bad! :) ...people, who has real money? maybe so?
Hello icebear
ice> By the way, I can check on Sprinter which is Sp97. But everything depends
ice> during :(
z84 there? interesting... that’s how they read/write on a sprinter like TRD, at most
Will it take a couple of minutes?
Hello icebear
ice> By the way, is it on turbo or not?
in theory, it doesn't matter. run this way and that, look at the amount - is it the same?
Hello, boo_boo
boo> By the way, I’m curious how the clones were designed? for example,
boo> I doubt that KR1858VM3 was made under the ZiLOG license, but memptr is there
boo> is there, and it behaves in the same way as on branded processes (although differently
boo> things like DAA, this die is different from the Z80).
In the docks describing bourgeois/Russian analogues - VM3 is the only one
a processor about which it is indicated that it is not an exact copy, but only 'functional'
analogue of Z80' :o
How is it different in terms of DAA?
Hello Titus
Tit> In the docks describing bourgeois/Russian analogues - VM3 -
Tit> is the only processor about which it is indicated that it is not an exact copy
Tit> but only 'functional analogue of Z80' :o
Tit>
Tit> How is it different in terms of DAA?
It’s strange why the developers of the “functional analogue” accurately imitated
an undocumented and incomprehensible feature (actually bit(hl)), leaving behind
there are more important things on board.
according to DAA - in general some kind of nonsense, not only undocumented flags, even S and H
don’t understand how they behave.
Hello, boo_boo
By the way, I looked at the t80 vhdl sources [http://www.opencores.org/cvsweb.shtml/t80/],
Something is wrong with 5 and 3 bits F for bit (HL) and bit (i+d). just not
I understand that - to understand, you need to understand vhdl :o
Hello, boo_boo
according to the results from CHRV [http://zx.pk.ru/showthread.php?p=40720#post40720]:
- LDIR/LDDR
does not affect memptr with BC=1 (those with a single execution)
when BC<>1 memptr=instruction address+1
-CPI
memptr=0 (?)
- CPIR
with BC=1 or A=(HL) as CPI,
in other cases it is unclear... (for this test both bits are 1, maybe
memptr=HL?)
- CPDR
when BC=1 or A=(HL) has no effect (like CPD)
in other cases memptr=instruction address
-INI
memptr=BC+1
- IND
memptr=BC
INIR/INDR
memptr=0 (?)
OUTI/OUTD
memptr=f(BC), what kind of f is unclear. the first thing that comes to mind, and with what
the result matches: memptr=BC >> 2, but somehow it’s wild O__o
OTIR/OTDR
memptr=0 (?)
By the way, I’m curious how the clones were designed? for example, I doubt
that KR1858VM3 was made under the ZiLOG license, but memptr is there, and it behaves
just like on branded processors (although for other things, like DAA, this crystal
different from Z80).
Hello, boo_boo
boo> it’s strange, why do the developers of a “functional analogue” exactly
boo> simulated an undocumented and incomprehensible feature (properly
boo> bit(hl)), leaving behind more important things.
boo>
boo> according to DAA - generally some kind of nonsense, not only undocumented flags
boo> Even S and H don’t understand how they behave.
So far, my opinion is this - either inside the VM3 there is again a bourgeois crystal
any modification of the Z80, or when grinding the crystal, followed by
reproducing it again, our craftsmen of something
changed/lost/overlooked ;)
Hello Titus
As for the difference between CPI/CPIR CPD/CPDR, this is somehow very suspicious to me.
How does the processor suddenly know that the previous executed command also
was CPIR or CPDR, and not some other one. (In the sense that he, after all,
does it alone) Or he keeps such a flag somewhere. Or how it turns out
that it resets only for CPIR which only works once, but takes
from HL (permissible) in other cases. After all, during repeated execution, if not
I knew that before this there was also a CPIR and would have reset it again. Everything with the CPDR team
It’s clearer if CPD doesn’t touch anything.
We should also add “double” tests when after a “reset” or “installation”
The checkboxes are filled in first with CPI, and then again with CPI or CPIR. In general, you need
see all combinations:
CPI: CPI
CPI: CPD
CPI : CPIR (BC=1)
CPI : CPIR (BC=2)
CPI : CPDR (BC=1)
CPI : CPDR (BC=2)
CPD:CPI
CPD: CPD
CPD : CPIR (BC=1)
CPD : CPIR (BC=2)
CPD : CPDR (BC=1)
CPD : CPDR (BC=2)
CPIR (BC=1) : CPI
CPIR (BC=1) : CPD
CPIR (BC=1) : CPIR (BC=1)
CPIR (BC=1) : CPIR (BC=2)
CPIR (BC=1) : CPDR (BC=1)
CPIR (BC=1) : CPDR (BC=2)
CPIR (BC=2) : CPI
CPIR (BC=2) : CPD
CPIR (BC=2) : CPIR (BC=1)
CPIR (BC=2) : CPIR (BC=2)
CPIR (BC=2) : CPDR (BC=1)
CPIR (BC=2) : CPDR (BC=2)
CPDR (BC=1) : CPI
CPDR (BC=1) : CPD
CPDR (BC=1) : CPIR (BC=1)
CPDR (BC=1) : CPIR (BC=2)
CPDR (BC=1) : CPDR (BC=1)
CPDR (BC=1) : CPDR (BC=2)CPDR (BC=2) : CPI
CPDR (BC=2) : CPD
CPDR (BC=2) : CPIR (BC=1)
CPDR (BC=2) : CPIR (BC=2)
CPDR (BC=2) : CPDR (BC=1)
CPDR (BC=2) : CPDR (BC=2)
Of course HL should point somewhere where A <> (HL) for all
comparisons (we can already assume that this case is equivalent to the last
execution). These tests include:
1) get confirmation that the processor has such memory of the previous command
there is;
2) find out if it distinguishes between 2 commands CPIR: CPIR, CPI: CPI, etc. or thinks
their continuation of the chain. By the way, you could also just plug it in just for fun
something neutral between and look at these triple tests:
CPI: NOP: CPI
CPIR (BC=1) : NOP : CPIR (BC=1)
CPIR (BC=2) : NOP : CPIR (BC=1)
CPIR (BC=2) : NOP : CPIR (BC=2)
3) does this hypothetical flag take into account two different LDIR commands
indeed to different addresses as one long LDIR command.
INI/IND/OUTI/OUTD together with R are not so interesting anymore. But CPI/CPIR is not very good
satisfied. At the same time, we should pull HL to different places in memory, let it show
Are the flags really taken from HL (from HL+1 in the sense?).
Hello, Vladimir Kladov
oops. Probably such a flag for the processor is PF. Those. he looks at PF,
and not on some other flag, assuming that PF = 0 is a sign of “beginning”
sequences, and then resets to CPIR memptr. And after LDIR in which
BC <> 0, PF=1, and then it doesn't reset. But PF can be = 1 not only after
CPIR. We also need to expand the tests in this direction: flags to the command too
try and reset and install. At least this needs to be repeated and
for CPD/CPDR and for LDI/LDD/LDIR/LDDR. Warmer? :)
Hello, Vladimir Kladov
Vla> About the installation time, a microsecond later, a microsecond earlier -
Vla> on the drum
Still, there is a difference, maybe you didn’t read it very carefully, most likely yourself
the memptr register is transferred to the flags register... how to say... by accident
or something, i.e. in general, the authors of the Z80 did not expect this to happen and therefore
This is how it turns out that this data gives a different CRC from series to series of CPUs.
As for the tests, I understand that you can only check whether it is an emulsion or not (or
maybe this is a completely defective version of the Z80), and the older the emulsion, as I understand it, the
it is less likely that this register is loaded there (((-:
And also, sports achievement or not, the work was done well ((((-:
P.S. Sorry, I slightly missed the question about Speck+ - here it is, I looked - to
unfortunately CRCs are unique http://zx.pk.ru/showpost.php?p=40776&postcount=50
P.P.S. I propose to award a gold medal to Boo-Boo and Vladimir Kladov for his unprecedented
Stakhanov's work to establish the true face of the glitch named memptr ((((-:
P.P.P.S. I don’t claim silver, but I wouldn’t refuse bronze ((((-:
Hello, Vladimir Kladov
Regarding taking into account the type of modification - they have already pulled it out for the original Speck+
computer test, so as I understand it, we need to focus on it. So how?
option to provide for a change of stone - well, so that there are the same results as for
of the specified CHRV percents, in other words, use a table to work with these
teams.
Possible variant of different operation of commands and influence on the memptr register and how
consequence on the flag register - maybe this is the problem. Register actually
There is a set of triggers that are assembled on the processor substrate in a single cycle. Before
setting a new value usually always uses a register reset and
respectively, reset triggers (asynchronous RS triggers and those based on them
asynchronous registers). The idea is this: it can be in different types
processors differs (can be nanoseconds) in the time the reset signal arrives at
memptr register? Those. in some cases it comes before its meaning
partially went into the flag register and in others - after that. Or - maybe it
varies? Those. even for one stone there can be either “0” or the notorious
"high_byte and 28"? And if you run the program in a loop, check these:
controversial (on different hardware) points, then you can get (on the same stone) different
results? And one more assumption in the same vein - the time of arrival of the signalreset differs for different revisions of processors in different ways, so most likely
In total, a series of processors will show the same results, while another series
will the same processors show different results using the same examples?
And immediately a question of this kind - what is the difference for existing programs (except
test ones) does it take the memptr register into account in emulators? Is it possible somehow
use this register while writing programs? What does it look like (except
test) use this knowledge about the memptr register?
Hello, Vladimir Kladov
Guys (boo-boo and Vladimir Kladov)
There is such a request - maybe make a clearly structured document
(file-text) with a description of the register and the influence of commands on it?
To be honest, there was a description a little higher there (from Vladimir Kladov), only this
greatly abbreviated.
Hello,GriV
where can I get more details? Boo-boo wrote everything that is known at the moment, and even
more. But with the influence of the HL register on the CPIR result, apparently
miss. Now I’m on my 5th, I’m fighting to get it in Fast mode too.
Everything works - within current limits. We should add a CPU selection. How are they
I don’t know what to name yet, but don’t list all the markings. I have an idea (about
"medals" :wink: ).
I would like it to be run on the “analogue”, which differs in DAA
test that I suggested. (Isn’t there anything else different? zexall test what
yes, also interesting).
Hello,GriV
what kind of test is this? “it’s already here” where is it, why don’t I know?
here they have already pulled out a test for the original Speck+ computer
If we're talking about zexall, then it doesn't help much, even if it sees
some difference (but he doesn’t see the difference at all with the bit n,(hl) command and won’t be able to
see - he is crooked). If he sees the difference on the command, then further on this
The team needs to do a separate test, its own, and then run it.
As for the installation time, a microsecond later, a microsecond earlier - according to
drum. The memptr value set in one command is used in
subsequent ones (and only in bit n,(hl)), so not a microsecond, much less
We are not interested in nanoseconds. There may be a reset, and there may even be an installation
(sort of like in CPIR). In any case, we can only be in a state
"the hypothesis is close to the truth because there is no disproving result
testing" - we accept it as truth. It's worth showing up for at least one
disproving result - the test has to be expanded and the hypothesis
modify.
I see only one application: you can clog up part of the code or data with flags
after the bit n,(hl) command executed after various commands affecting memptr,
and eventually get a program that will not work on old emulators or
incompatible chip clones. I don’t yet know a single demo or program forspec that would not work because of the bit n,(hl) command, more precisely, because of the flags,
which do not coincide with the iron ones.
So, the work done can be considered an excellent sporting achievement (although
and not the most absolute - there is still a chance to achieve even more accurate results),
but like sports in general, it doesn’t do much good.
Hello, Vladimir Kladov
oops, oops. My previous post is crap. PF has absolutely nothing to do with it. Checkbox
there is something in the CPU. I tried using the address as a checkbox
previous executed command, if it is the same, then the same command is executed,
and the reset is not done, i.e. the result from the penultimate execution of CPIR remains
(installation).
Now about where the installation comes from. If you take HL or HL-1 (i.e. after and before
command execution), then the pair of results does not converge. It came together when I just
started pushing FF into memptr. The result is strange. I'll try something else now.
Alas. I tried everything that came to mind: A-(HL), A-(HL)-F, A - nothing
fits. Only pure FF. We need to look at different HLs and find out what can
also influence memptr in CPIR. Since HL is not suitable.
Double (and triple) tests are still of interest. I would like to find out if it is enough
analyze the address of the previous command, or do you need to remember the command itself
(opcode) to act as a "continue" flag for CPIR. For
For other teams this is less relevant.
Hello, boo_boo
already there: I'm posting my EmuZWin 2.7 build 2.7, all the accumulated
material is already included.
There is no chance there, everything follows a clear algorithm. I think when
designing the first crystal or simply mixed up the source for the flag in
bit team, or vice versa, they hoped to get another source
"pseudorandom" numbers, sticking out the "tail" of a completely internal
register for intermediate calculations.
Hmm, ice - he made it for the original spec. I didn't look. But I think that's all there
same thing. Boo boo, if you take a look, tell me. And how will there be more tests (and
results), I will definitely take part. As a person far from reality (according to
there are 2 pieces lying around in the boxes, and my hands are not sharpened for a soldering iron), it has always been
It’s interesting to make the most realistic emulsion possible.
Hello,GriV
Gri> And immediately a question of this kind - what is the difference for existing programs
Does Gri> (except for test ones) account for the memptr register in emulators? Is it possible how
Gri> Should I use this register when writing programs? How
Gri> it seems (except for the test) to use this knowledge about the register
Gri> memptr?
as for the difference - we don’t really know :) maybe those few programs
which do not work on this or that emulator, they will suddenly take it and make it work,
was done somewhere LD A,hibyte:[opcode_exposing_undocumented
flags]:PUSH AF : POP IX : JP IX.
You can use it for protection - click on it, and the emulators are out.
to recognize the processor brand together with other tests for
undocumented flags and opcodes...
Well, to be honest, these studies have a by-product - I
I caught a few subtle glitches in the Z80 emulation core, I wouldn’t be surprised if not
I'm alone ;)
Hello,GriV
Gri> and therefore it turns out that this data is from series to series of CPU
Gri> give different CRC.
So far it doesn’t seem like anything has changed in the bit flags from series to series of CPUs
n,(hl).
Gri> And as for the tests, I understand that you can only check the emulsion or
Gri> no (or maybe this is a completely defective version of the Z80), and the older it gets
Gri> emulsion, as I understand it, the less likely it is that this register is there
Gri> is registered (((-:
So far there is no emulator at all where this feature is fully implemented.
Hello, Vladimir Kladov
Vla> As for the difference between CPI/CPIR CPD/CPDR, this is somehow very important to me
Vla> is suspicious. How does the processor suddenly know that the previous one
Vla> the command being executed was also CPIR or CPDR, and not another
Vla> some.
Vla> (In the sense that he does them one by one) Or he holds
Vla> I have a checkbox like this somewhere.
IMHO it’s very unlikely that the flag is there, as you can’t see any
necessary. CPIR from CPI (and CPDR from CPD) differs only in that PC
changes in case of repetition (after looking at ZF and PF). therefore,
this affects memptr. another thing is that in the case of CPDR everything is clear and
similar to CALL/JP, but CPIR is a bit of a mess. but most likely memptr is also a function
from the address. it could be a shift, but (as with OUTI/OUTD)
this is implausible... option - CPI does not just “zero” memptr, but puts
there is something good that is used later during the transition.
but checking about the flag is a good thing, why not check ;)
Hello, Vladimir Kladov
Vla> I would like it to be on “analogue”, which differs in DAA, after all
Vla> ran the test that I suggested. (Isn’t there anything else different there?
Vla> what the zexall test gives is also interesting).
it seems it's time to make a combined z80 test-pack ;)
Hello, Vladimir Kladov
Vla> Hmm, ice - he made it for the original spec. I didn't look. But I think
Vla> everything is the same there. Boo boo, if you take a look, tell me. And how will they be
Vla> more tests (and results), I will definitely take part. To me as a person
Vla> far from real (there are 2 pieces lying around in the boxes, but I don’t have hands under them
Vla> soldering iron sharpened), it was always interesting to make the most
Vla> realistic emulsion.
the result from icebear completely coincides with the results for both relatives
percent CHRV (and the sum does not add up due to OUT(0000),0 - obviously the CHRV test is 128
ran it in mode, and 0000 was decrypted in the same way as 7FFd, ROM0 was turned on and something
during this chaos it deteriorated %)
Vladimir Kladov, I’m currently doing the 6th version of the test, come on, as the author of the “flag”
theory", you will select from that pile a few of the most revealing tests
CPI/CPD[R] to confirm/refute this case?
Hello, Vladimir Kladov
Vla> already exists: I'm posting my EmuZWin 2.7 build 2.7, all the best
Vla> accumulated material is already included.
Vla>
Vla> There is no randomness there, everything is according to a clear algorithm. I think when
Vla> designing the first crystal or simply mixed up the source for
Vla> flag in the bit command, or vice versa, they expected to get another one
Vla> source of "pseudorandom" numbers, sticking out its "tail"
Vla> is a completely internal register for intermediate calculations.
Vla>
Vla> Hmm, ice - he made it for the original spec. I didn't look. But I think
Vla> everything is the same there. Boo boo, if you take a look, tell me. And how will they be
Vla> more tests (and results), I will definitely take part. To me as a person
Vla> far from real (there are 2 pieces lying around in the boxes, but I don’t have hands under them
Vla> soldering iron sharpened), it was always interesting to make the most
Vla> realistic emulsion.
the result from icebear completely coincides with the results for both relatives
percent CHRV, which is not surprising (and the sum does not converge due to OUT(0000),0 --obviously I ran the CHRV test in 128 mode, and 0000 was decrypted in the same way as 7FFd,
ROM0 turned on and something got spoiled during this chaos %)
Vladimir Kladov, I’m currently doing the 6th version of the test, come on, as the author of the “flag”
theory", you will select from that pile a few of the most revealing tests
CPI/CPD[R] to confirm/refute this case?
Hello, boo_boo
boo> the result from icebear completely matches the results for both
boo> native CHRV percentages (and the sum does not converge due to OUT(0000),0 - obviously
boo> I ran the CHRV test in 128 mode, and 0000 was decrypted in the same way
boo> 7FFd, ROM0 turned on and something got spoiled during this chaos %)
YES I confirm the mode was 128.
Hello, CHRV
CHR> YES I confirm the mode was 128.
heh, at first I was simply amazed - how are there some flags after OUT)
in the next version I'll switch to 48k out of harm's way :rolleyes:
Hello Shaos
Sha> But in the dock for ZX-Spectrum+ it is written that there is a Z80 marked there
Sha> NEC D780C-1 is the same Z80 or a clone or an exact license
Sha> copy?
You should ask NEC about this :) As for licensed production, I know
only about the Japanese (thanks to them the HD64180 appeared, and therefore the Z180) and SG. Like
Goldstar made more copies. How accurately did they all repeat the original?
I have no idea how such copies are made.
I haven’t promoted my ZX Spectrum+ yet, I’ll have to take a look. Sprinter
Today I’ll try to check, by the way, you or CHRV could do this too.
Hello, Vladimir Kladov
Unbelievable, but true! I ran several tests in a row and everything was OK!
The demo is called Blava demo. When moving to part 3 almost always
reset. 1st measure was not enough!
Hello, Vladimir Kladov
By the way, here [http://www.z80.info/z80architektur.htm] on the functional
In the diagram, the required register seems to be visible as "Temporary Inder Register".
Interestingly, all the inscriptions on the diagram are in German, but this one is in English.
Hello, Vladimir Kladov
And by the way, I found a document on Z80.info that shows how many cycles
what is done when following instructions. The most interesting thing is that in IM0 mode
the interrupt is done in 12 clock cycles, versus 13 in IM1 and 19 in IM2. (This is if
RST 38 is "substituted", and in the Spectrum, it seems, it is FF on the bus, so it will be
exactly 12 cycles and similar to RST 38. I mean, this information is not available anywhere, and 1
tact can sometimes be decisive. I have one demo... I'll have to
try.
Hello, boo_boo
boo> not everything turned out to be so simple with these CP*... yes, when executing chains
boo> from 2 commands the result is unexpected - for example CPD:CPD give 11,
boo> CPIR:CPI same result as just CPIR, CPIR : CPD --
boo> memptr=instruction_address_CPIR+1...
boo>
boo> [skip]
boo>
boo> PS, what if it affects some other commands that set memptr
boo> its initial value? :confused:
How about writing a letter to Mr. jw, who maintains z80-documented,
so that he includes the extracted information in the next version of the document (since he
is being updated)? What the hell do you say?
Hello, boo_boo
Come on, otherwise I thought we’d stop there. There are interesting things on z80.info
things, logical internal structure, there is even a power-point presentation for 4x
instructions on what's going on inside him. But so far it doesn’t clarify much. Like
photo of the process with a magnification of 100 times 8-]
Hello, Vladimir Kladov
Vla> How about writing a letter to Mr. jw, who maintains
Vla> z80-documented so that it includes the extracted information in the next version
Vla> of the document (since it is being updated)? What, boo-boo, do you say?
right idea :) ...it would be nice to bring the proceedings with memptr to
logical end, and then write, but CP* me, to tell the truth,
scared, I don’t really believe in the logical ending :rolleyes:
I think I’ll do one more test - to find out what’s wrong with outi and whether it affects
cleverly installed memptr on CP*, and write down what is there.
Hello, Vladimir Kladov
Vla> Incredible, but true! I ran several tests in a row and everything was OK!
Vla> The demo is called Blava demo. When moving to part 3 almost always
Vla> was reset. 1st bar was not enough!
maybe it was still missing because of something? very strange - in the official
the manual says that when requesting an interrupt vector, 2 wait-a are added (which
reflected in the diagram), z80undocumented directly states that IM0 with RST is 13
cycles... and according to the document with the scheduled cycles, for CALL - 2 waits,
and for RST, it turns out to be 1? The CPU doesn’t know what will come to it, where it comes from
discrimination? IMHO it looks more like a typo in a document with written
cycles, otherwise it’s generally unclear what’s what O__o
By the way, in my z80ex there are 13 clock cycles on im0-rst, and blava works stably (in
zemu)...
about the temporary index register - interesting.. it looks like someone knows something, but
silent :rolleyes:
By the way, here’s another interesting document:
http://www.funet.fi/pub/msx/mirrors/msx2.com/zaks/z80prg02.htm
it mentions some internal registers w and z used to work with
16-bit values (since the data bus is 8-bit)
Hello, boo_boo
Why for anyone. In Spectrum, only the RST38 instruction is possible. This area is
the screen is always on, the bus is always FF. Those. for us - for any RST38 instruction.
Hello, Vladimir Kladov
Vla> Why for anyone. In Spectrum, only the RST38 instruction is possible. This
Vla> the area behind the screen is always, on the bus is always FF. Those. for us - for
Vla> of any RST38 instruction.
I mean -- in this dock at IM0 the cycle M1 is the same length for RST and for
CALL, why? This is extremely suspicious and looks like a typo. that is, everything
it happens, but IMHO the fact that some demo worked does not prove anything,
You need to check it in real life.
Hello, boo_boo
again it’s unclear: if they don’t affect anything, then why say something about them?
find out?
Hello, Vladimir Kladov
Vla> again it’s unclear: if they don’t affect anything, then why talk about them
Vla> find out something?
by and large there is no need. although it is impossible to say 100% that they do not influence....
ok, 2 bits is a trifle, and so it will be clear what’s what. if this whole thing
it will work (it already works under the emulator, but what will happen in real life?), I wouldn’t be surprised,
if it turns out that after those commands that “zero” memptr, in the low byte
some kind of dregs remain :rolleyes:
Hello, boo_boo
This is easily verified by CPDR (it seems). 0-1=11111...11111. If after fasting
memptr=memptr-1 gives both bits set, then the least significant one is cleared.
Hello, Vladimir Kladov
Vla> this is easily checked by CPDR (it seems). 0-1=11111...11111. If after
Vla> clearing memptr=memptr-1 gives both bits set, then the low one
Vla> is reset to zero.
nothing, nothing, if only the CPD is really a memptr decrement, everything is fine
Let's check, using 14 bits :)
Hello, boo_boo
so, the poem about memptr - read it!
On this cheerful note, I propose to consider the case of BIT n, (HL) closed :rolleyes:
Thank you very much to all research participants :)
PS. I should also translate it into English - share it with the bourgeoisie ;) maybe
will anyone take it? I can too, but I don’t want to embarrass myself - it will come out in style
"ay have ze veri good family"...
File: memptr_win.txt http://zx.pk.ru/attachment.php?attachmentid=2984
Hello, Vladimir Kladov
Vla> Well, I translated it in general as best I could. And the source text was translated into win from
Vla> unix :) Otherwise you won’t be able to open it in notepad.
Vla>
Vla> Can I send a letter now? Should I send it? jw(@)dds.nl
oh great! fixed a couple of typos (before instead of after for one of the outi,
some other little thing), sent it. :)
At the same time I wrote to him about a bug with XF and YF in the description bit n,reg
Hello, boo_boo
Post it here too, I’ll remove mine with typos then.
Hello, Vladimir Kladov
Vla> post it here too, I’ll remove mine with typos then.
here
File: memptr_eng.txt http://zx.pk.ru/attachment.php?attachmentid=2989
Hello, boo_boo
I also thought: while he’s there, he’ll “publish” a new version of the book... Maybe on WoS
report to emuls section? At least the Spectaculator writers hang out there,
Spin and Fuse. We must give them credit: they laid out the whole document about timings,
having spent both their time and effort on this, and “broke” them with no less diligence.
Hello, Vladimir Kladov
Vla> I also thought: while he’s there he’ll “publish” a new version of the book... Maybe on
Vla> WoS report to emuls section? At least the authors hang out there
Vla> Spectaculator, Spin and Fuse. We must give them credit: about timings
Vla> they laid out the entire document, spending their time and effort on it, and
Vla> “broke” them with no less diligence.
yeah, let me know :) ...what's this about timings?
Hello, boo_boo
I mean a detailed picture of how delays occur on
contended memory for branded models. This information was also
undocumented and obtained through experimentation. They knew something and used it
demo makers to obtain their multicolor effects, but more often - just
We measured the time for each specific deme. It's a completely different matter to provide
a detailed description of what happens on each machine cycle of each command
processor, depending on whether access to
contended memory or ports or not. This is the only way to triple the emulator, which
will correctly reproduce all multicolors of branded models, with real
ULA.
I'll let you know. I just don’t know how to pin the text to them. I've never seen it there
something was pinned. I'll try to give a link to this thread in our forum.
Hello, Vladimir Kladov
Vla> I no longer have enough Russian or English to express
Vla> your indignation. It turns out that a certain Fraser already 2 years ago is ALL
Vla> KNOWN
Vla>
Is that really all? And about Russian processors?
We probably did a lot of work here after all.
So thank you - well deserved, I think.
Hello, Vladimir Kladov
Vla> I no longer have enough Russian or English to express
Vla> your indignation. It turns out that a certain Fraser already 2 years ago is ALL
Vla> KNEW and placed the information (or supposedly marked it) inside the archive with his own
Vla> cross-asm - see here:
In comp.sys.sinclair, someone Dunny has already broken it :) Mr. Fraser Ross investigated
behavior of commands from the group of 16-bit arithmetic operations. He was indignant
regarding the fact that he was not included in the text credits written by boo_boo, making
The bias is that you and boo_boo ripped off some of the information from the document he specified. On
which came under distribution from Dunny. So everything is fine.
Hello icebear
Personally, I haven’t written about this document yet and haven’t even seen it. Boo-boo
didn't mention him either. Besides, what's the point of his document: what he wrote, and
This was known for 16-bit addition-subtraction, at least from Sean
Young, long before his ASMA document was hidden in the wilds.
Hello, Vladimir Kladov
Boo-boo, remind me: INC rp / DEC rp do not affect MEMPTR? And then Fraser
arises again. Or answer it yourself, otherwise it’s time to sleep, it’s midnight
(after all, +6 GMT).
Hello, Vladimir Kladov
Guys! Don't pay attention! There will always be some... person...
who will say “they ripped me off” and will wave papers at the same time
proving his involvement. You did a great job - and that's all who
I've been following this thread at least a little bit, they can confirm. Maybe someone is there
and did something similar, only he 1) didn’t share 2) now wants to get on with it
to someone else’s success (cross out what is unnecessary from 1 and 2), so you know, well done.
:v2_tong2:
Hello, Wlodek
Wlo> Is that really all? And about Russian processors?
Well, yes, only for *VM1 there are differences in memptr. although if there are any more
Russian processors, you can test them too ;)
Hello, Vladimir Kladov
Why is it sharpened specifically for the Pentagon?
port #FF? makeshift for multicolors?
It’s just that there’s something here... like neither fish nor fowl (not Pentagon and not Scorpio).
maybe on it?
Hello,GriV
I was just sitting and finding out the history of the issue with INC/DEC rp. In order to
determine whether these instructions were accidentally forgotten. (Question asked by Fraser,
he thinks they do the same thing as ADD/SBC for rp). I understand that on
in the very first test nothing suspicious was noticed about them, and more in
they did not participate in the tests. But in vain. It wouldn't hurt to stick them (at the beginning)
the last test, and in general make the final test based on it,
which would show the non-involvement of any suspicious teams. After all, even if
some instruction does not set a completely new value in MEMPTR, it may
change it anyway. For example, why not inc rp execute M++, and dec rp
similar to cpd: M--. It is imperative to include ALL instructions with rp in the test, even
innocent LD rp,word. Let them show that they really have nothing to do with it.
Boo-boo?
Hello, Vladimir Kladov
To be more convincing, you can run this test:
LD A,(0000) ; MemPtr=0
BIT 1,(HL) : PUSH AF
DEC HL
BIT 1,(HL) : PUSH AF
LD A,(FFFF) ; MemPtr = FFFF
BIT 1,(HL) : PUSH AF
INC HL
BIT 1,(HL) : PUSH AF
And I also thought this: does the BIT n,(HL) command itself definitely not affect MemPtr?
(Suddenly she loads HL or HL+1 into it...) The last test proves
the non-involvement of this team, right? (So in a loop you need to check the flags,
and if HL got into MemPtr, then the flags would give the same thing all the time
meaning, in that case. It seems to be proof, as I understand it?).
For some reason I'm becoming suspicious...
Hello, Vladimir Kladov
Well, my last post is already late. Okay, otherwise I'm not that good at code.
I looked, I just didn’t see this command separately in the list.
Yes, if it had an effect, then in at least one case the test (probably)
would go in cycles - or show that Memptr is 0, or else give something strange.
By the way, I put a test for IM0 this evening
(http://zx.pk.ru/showpost.php?p=44285&postcount=75) - if anyone wants to drive away
Please, only the Pentagon.
Hello, Vladimir Kladov
Vla> Boo-boo, remind me: after all, INC rp / DEC rp do not affect MEMPTR? A
Vla> then Fraser appears again. Or answer it yourself, otherwise it’s time to sleep
Vla> midnight has come (after all, +6 GMT).
no, they don’t have an effect. in the MEMPTR decrement cycle I do INC/DEC BC, and
everything is fine :) I'll go take a look at WoS.
Hello, Vladimir Kladov
Vla> For some reason I’m becoming suspicious...
DEC/INC and BIT (HL) itself, yeah, they don’t affect it - otherwise the test would fail. but in general,
you can put more instructions there for reinsurance - I suggest drawing up
list...
Hello, boo_boo
boo> oh well, why check - just put it in the main test so that everything fits
boo> was hand :)
To be convincing. At least inc/dec rp. What if they really do for
memptr ++ or --, at least for some registers. By the way, INC/DEC INDEX
(INDEX=IX/IY) - it wouldn’t really hurt to check in both ways.
Hello, boo_boo
List - all commands with rp in at least some form:
INC rp:DEC rp
LD r,(HL):LD (HL),r
ADD/ADC/SUB/SBC/AND/OR/XOR/CP A,(HL)
RES n,(HL):SET n,(HL)
They should at least be checked first with the test that I suggested: reset
Memptr, then command, then setting MemPtr, then command. This is to
make sure that at least they don't do ++ or -- for MemPtr. And only then
For added credibility, you can add them to the main test loop.
P.S. I turned off the emoticons, the ASM Z80 is having fun again...
Hello, Vladimir Kladov
Vla> They should at least first be checked with the test that I suggested:
Vla> reset Memptr, then command, then set MemPtr, then command.
Vla> This is to make sure that at least they don't do ++ or -- for
Vla> MemPtr. And only then you can use them for greater persuasiveness in the main
Vla> add test cycle.
oh well, why check - just put it in the main test so that everything is at hand
it was :)
Hello, Vladimir Kladov
Vla> For credibility. At least inc/dec rp. Suddenly they really are
Vla> is done for memptr ++ or --, at least for some registers. By the way,
Vla> INC/DEC INDEX (INDEX=IX/IY) - it wouldn’t hurt to check with both
Vla> in ways.
The “second method,” that is, through CPD, completely replaces the first. let them at least
what they do with the mempter, we will see. the instruction is executed before the loop
decrement CPD, not in a cycle, so everything is ok.
Hello, boo_boo
What’s interesting is the “zeroing” of memptr at IM0, which Luca mentioned
from ramsoft. this would be tested, but then you need a device that INT
sets something harmless for memptr to the bus, for example 0. but who
will climb into his spec with a soldering iron for such garbage... or maybe it’s already in
things like this in nature?