If RealX Ever gets released will it have the D80 and realdisk emulation?
I guess it won't have the non-standard disk bug fixed cuz it's a hardware error, not software :(
Sure, of course.
But make sure to add the NMI to didaktik emulation (I mean the SNAP button). Maybe you could also release it in a RealSpectrum update? ;)
Hmmm it could be, but I'm not sure I'm going to update RealSpectrum anymore. Cannot promise anything.
It appears that the different numbers are due to different offsets used to count t-states, that's all.
Anyway I've just received a mail from a guy who is testing the 48K timings with a logic states analyser and a CPLD circuit developed for the purpose, and the numbers are different from both ours and the FAQ's. We're working with this guy to repeat all the tests we made in 1999 with our own custom circuit; the goal is to find the real values for t-states offsets (first contention, electron beam offset, snow effect, floating bus) using more modern hardware, so that we can all have some reference for counting time. It's time to retrieve our old sheets of paper...
Luca, you'd be best off asking Woody about this - he made the tests, and the "snow contention" is definitely present in RealSpec but not in your Snow documentation, which goes as far as saying that no contention is applied during snow periods - why that would be, I have no idea.
With the work done on the 48k Speccy here, we're very confident that what Woody has discovered has revealed how the ULA snow works, which is down to individual machine cycles and therefore would require a lot of CPU power to emulate accurately. However, as I said, we have a reasonable approximation working in SPIN. Our snow contention is accurate based on our tests. Your algorithm for determining where the ULA reads display/attr bytes from the display memory is certainly wrong - what's amazing to me is how long it took me to figure it out, as the real algorithm was staring me in the face :-)
We have a number of test programs that Realspec fails on in all manner of contention/opcode mechanisms. I'm hoping to make them available when I've got them properly documented, so you'll be able to test RealSpec with them.
It will be nice to see that the new data from your friend matches the values Woody obtained from our real 48k - it's certainly very different to the timings that Realspec uses. We have conclusive proof of the first contention cycle, the snow mechanism and all our floating bus tests match the real 48k too.
Woody has sent a lot of this new information to the FAQ maintainers, so yourselves and other authors will be able to fix your emulation up. We must be getting close to 100% 48k accuracy by now, surely? What else is there left to do? To think it's 2006 and we still don't know all there is to know about the ULA!
Luca, you'd be best off asking Woody about this - he made the tests, and the "snow contention" is definitely present in RealSpec but not in your Snow documentation, which goes as far as saying that no contention is applied during snow periods - why that would be, I have no idea.
Then it isn't clear to me what do you mean by "snow contention".
Your algorithm for determining where the ULA reads display/attr bytes from the display memory is certainly wrong - what's amazing to me is how long it took me to figure it out, as the real algorithm was staring me in the face :-)
We only studied the 128K ULA directly, not the 48K one. We made many tests and I remember that all the results were in accord to the proposed formula, but of course we might have ignored something else; I'd like to repeat the tests now to see if our methodology was wrong. Should the original formula be confirmed for the 128K, I guess I could try to explain the difference from the 48K with the fact the the address lines of the ULA's private bus are crossed in the 48K but straight in the 128K. But that's only a (bad) guess until I know the real formula for the 48K discovered by Woody.
It will be nice to see that the new data from your friend matches the values Woody obtained from our real 48k - it's certainly very different to the timings that Realspec uses. We have conclusive proof of the first contention cycle, the snow mechanism and all our floating bus tests match the real 48k too.
Sure, expect a document from us as soon as enough data are available. From the preliminary tests, it seems that the first contention (6T) is applied when the Z80 starts a memory cycle at T=14337.
Woody has sent a lot of this new information to the FAQ maintainers, so yourselves and other authors will be able to fix your emulation up. We must be getting close to 100% 48k accuracy by now, surely? What else is there left to do? To think it's 2006 and we still don't know all there is to know about the ULA!
You might be surprised, but that's all very exciting to me! :D I'm happy that we still have to learn ;)
This time I agree, but nevertheless I did more in the last two years than everybody else since 1998. This week I'm going to dedicate all of my spare time to the official release of TZX v1.20.
Could you let me know where you posted the results of your recent work, as I can't see any updates anywhere?
It was intended to Luca in first place.
Sending patch? It is on sourceforge, and made not by me. There are better C programmers around than me.
Is problem in concept of whole updating, or in you, I really don't know/care.
Moaning constantly? Well, all my bad suspects about RealSpec appeared as thrue :(
@Kendall: I haven't done my homework yet, I had to work (in real life) until last week.
In the meantime I and Alessandro Poppi have cooperated to produce a full documentation of the 48K ULA using a logic state analyzer (lots of captures showing the real timings for everything). At the moment we have produced a document written in Italian which I'm going to translate into English.
@Piters: why don't you focus on a modern emulator instead of insisting to complain about RealSpectrum? Sorry you missed the gold age 2000-2003 when it was very actively developed, but now it's different and I have already explained my situation in many previous posts. Updates will come where there is something to update (hope soon).
@Piters: why don't you focus on a modern emulator instead of insisting to complain about RealSpectrum? Sorry you missed the gold age 2000-2003 when it was very actively developed, but now it's different and I have already explained my situation in many previous posts. Updates will come where there is something to update (hope soon).
You obviously not understand my points. But it is very common reaction of people to critic. Critic, which started good-willing from my site, but now it turned to pure sarcasm. Why? Because of your ignorance. Another typical reaction is recalling past - 'gold age'. I didn't miss that period, just was not on this forum.
Nobody here ask for your situation (or mine, or anyone's). I will repeat now myself - problem is your easy-made 'will do it' statements. And we have almost nothing done in last 2 years.
Problem is your website, where everything is frozen in last 2 years. OK, it may stay so, but then don't write there about sending bug-reports and similar. Write there something like: 'folks, that's it, and sorry that we can not fix bugs, improve program because of.... etc.' .
If you write there that something is emulated, but in fact is not emulated - because it simple not works - it is very iritating. Is it now clear where is your ignorance?
P.S. Yes, I use now 'modern' emulator, very focused :D
Dunny likes to call contention based on the IR register pair outside of M1 cycles as snow contention. But only when it causes the snow.
In RS source code there is no trace of contention applied during T3-T4 of a fetch cycle. We only do Z80_ABUS = IR at the end of the M1 phase (because that's what the Z80 actually does), which can possibly cause contention later, but certainly not during the refresh cycle. And the sentence you quoted:
...the ULA gets confused by the memory refresh cycles of the Z80 (performed during each instruction fetch), and it doesn't apply contention to take precedence as usual
... explicitly refers to the refresh cycle, in fact. Seems like you misunderstanded our statement :)
Concerning the new tests made by Alessandro (which I'm translating into English), he noticed that the INT signal is asserted by the ULA immediately after the rising edge of the Z80, which is also the time when the CPU samples it. This caused the CPLD to detect the INT duration sometimes as 32T and sometimes as 33T; so he moved the trigger on the falling edge of the clock. Could this be the explanation for the dual set of timings that we all know?
I wanted to contribute to Luca and RamSoft, to fix bugs in RealSpec, but now I feel like complete idiot. That is it...
Should I shut up, and forget all after many e-mails, explanations?
Problem is your website, where everything is frozen in last 2 years. OK, it may stay so, but then don't write there about sending bug-reports and similar. Write there something like: 'folks, that's it, and sorry that we can not fix bugs, improve program because of.... etc.' .
Well, the front page is two years old, but not other sections inside. And apart from that, I have repeated what you ask countless times on this forum and in replies to emails, and you've read that all.
If you write there that something is emulated, but in fact is not emulated - because it simple not works - it is very iritating. Is it now clear where is your ignorance?
Yes: you call me ignorant because you sent me a bug report and I didn't fix your bug. And I didn't put a big flash writing on the homepage saying "this stuff is old, sorry". Hope you won't turn yourself into some Annie Wilkes from Stephen King's "Misery", aiming to kidnap and torture me until I resume RealSpectrum :D:D:D
I wanted to contribute to Luca and RamSoft, to fix bugs in RealSpec, but now I feel like complete idiot. That is it...
Should I shut up, and forget all after many e-mails, explanations?
First, I always appreciate any kind of contribution, criticism included; second, you're not an idiot. But you can't force me to do something you want; you can be disappointed and complain, but there's a limit. You're turning this into a personal affaire...
Yes: you call me ignorant because you sent me a bug report and I didn't fix your bug. And I didn't put a big flash writing on the homepage saying "this stuff is old, sorry".
Then please remove section where problematic emulation is. There is too long list, some shortening will make it easier to follow.
Thank you for encouraging people to help your work...
What this means: 'and I didn't fix your bug' ? So, you think that bug is mine? This is really sad...
Luca, nobody's asking you to quit your job and embrace insane Spectrum zealotry making constant updates to RealX for the rest of your life. However, you have to accept the fact that the Realspectrum team has not really lived up to its promises in the last couple of years, and this has upset many people, myself and piters included. Our real lives will always come first, but it would be nicer of you to stop making any promises or announcements and just get on with your activities. If you can find the time for some Speccy development, fine, do the work and only announce it when it's 99.5% done.
Realspectrum was really fine in its day but now it's outdated and mostly outmatched by SPIN and FUSE, which are much more promising, not to mention also actively begin developed. We've seen this happen time and time again. Any emulator author will eventually quit developing his work after a couple of years, and most of the secrets involved will be lost. Our Speccy knowledge, of course, is constanly evolving, but it would be nice if we didn't have to constantly re-invent the wheel. FUSE is opensource, I gather, which is quite promising in that respect, although willing and competent developers will always be in short supply. I can't say much about its accuracy, as the only Win32 incarnation I could find was deemed as "buggy and missing a lot of features"...
However, you have to accept the fact that the Realspectrum team has not really lived up to its promises in the last couple of years, and this has upset many people, myself and piters included.
GOC, actually it's the opposite: I've spent the past two years repeating that I don't promise absolutely anything concerning RealX and RealSpectrum.
Realspectrum was really fine in its day but now it's outdated and mostly outmatched by SPIN and FUSE, which are much more promising, not to mention also actively begin developed.
Again, I'm repeating that RealSpectrum is obsolete since a long time, you can read my ancient posts recommending people to use a modern emulator (unless they need a specific feature of RS, of course), especially because I cannot maintain it actively anymore. Many other emulators have simply disappeared during time, nevertheless their authors have not been pestered this way despite their promises for never-seen updates. Why I am so special, I don't know...
Many other emulators have simply disappeared during time, nevertheless their authors have not been pestered this way despite their promises for never-seen updates. Why I am so special, I don't know...
Ahem :-)
I think the reason you get pestered is because every now and then you come along and say things like:
"RealX is coming very soon now"
"Yes, we'll maintain the TZX format"
"Updates to the RZX format will be posted soon"
And then nothing much actually happens. We all know you have a real life(tm), I myself am working in a fulltime (40+ hours/week, more often 7 days/week) job, doing a full time University course, managing a family *and* trying to find time to write SPIN and BASin.
It's very difficult to juggle all that, but the key thing is not to volunteer for jobs that you can't find the time for.
A simple post along the lines of "RealX probably won't see the light of day for quite some time now, let's wait until Vista comes out and then we'll see" would probably gain you more respect.
Luca, you act exactly as it would be my bug - because I care about, but you don't care. Well, I care no more. I see that all my talk to you was wasting of time. You learn nothing.
And you again reply selectively. But, it is your work, your site, and certainly not mine. Including all incorrect statements. At least, I never put on my site untested software, hardware project. And I listen to people who writes me.
To finish this chat: whether do something so complex like emulation with full effort, heart, or do it not at all. Nobody will care about second league.
Time never stops.
A simple post along the lines of "RealX probably won't see the light of day for quite some time now, let's wait until Vista comes out and then we'll see" would probably gain you more respect.
Dunny, that's exactly what I keep on repeating since many months now (apart from quoting Vista). Directly, not along the lines. And I also already acknowledged that I'm guilty for TZX and RZX.
But the RealSpectrum, RealX and MakeTZX business are totally mine and I can't be considered a criminal because I don't work on them at people's request.
In RS source code there is no trace of contention applied during T3-T4 of a fetch cycle. We only do Z80_ABUS = IR at the end of the M1 phase (because that's what the Z80 actually does), which can possibly cause contention later, but certainly not during the refresh cycle.
Hmm, thought I'd said the contention was outside of fetch cycles ;)
I know where it's applied, which opcodes are affected and which one you missed in the RealSpec source ;)
This caused the CPLD to detect the INT duration sometimes as 32T and sometimes as 33T; so he moved the trigger on the falling edge of the clock. Could this be the explanation for the dual set of timings that we all know?
General situation about disappeared and unfinished emulators and other software is theme for itself.
I don't think that anyone here tried to make comparisons. There is even lot of emulators with disappeared websites, unaccesible authors and similar. But it is in fact all normal.
What Luca didn't get in all this is that we like RealSpec. We respect it. Maybe way how myself show it is not as expected... ehm. life is not easy, especially not in 21-st century in Eastern Europe. There is too much PR infiltrated from more 'advanced' countries. We don't like it.
I've just noticed this use of this term in the forum and I'd like to report that I've registered "real life" as a federal trademark since 1987 and the use of it without prior permission or approval from me is illegal under US laws and covered under International Classification 9 of which the countries England and Italy are party to.
As such, anyone advertising, promoting, using or having a "real life" before or after 1987, deceased or alive, is liable to be sued by me for illegal use of trademark. Dunny, Luca, you shall be hearing from my attorney shortly. :P
Comments
Luca
Anyway I've just received a mail from a guy who is testing the 48K timings with a logic states analyser and a CPLD circuit developed for the purpose, and the numbers are different from both ours and the FAQ's. We're working with this guy to repeat all the tests we made in 1999 with our own custom circuit; the goal is to find the real values for t-states offsets (first contention, electron beam offset, snow effect, floating bus) using more modern hardware, so that we can all have some reference for counting time. It's time to retrieve our old sheets of paper...
Luca
With the work done on the 48k Speccy here, we're very confident that what Woody has discovered has revealed how the ULA snow works, which is down to individual machine cycles and therefore would require a lot of CPU power to emulate accurately. However, as I said, we have a reasonable approximation working in SPIN. Our snow contention is accurate based on our tests. Your algorithm for determining where the ULA reads display/attr bytes from the display memory is certainly wrong - what's amazing to me is how long it took me to figure it out, as the real algorithm was staring me in the face :-)
We have a number of test programs that Realspec fails on in all manner of contention/opcode mechanisms. I'm hoping to make them available when I've got them properly documented, so you'll be able to test RealSpec with them.
It will be nice to see that the new data from your friend matches the values Woody obtained from our real 48k - it's certainly very different to the timings that Realspec uses. We have conclusive proof of the first contention cycle, the snow mechanism and all our floating bus tests match the real 48k too.
Woody has sent a lot of this new information to the FAQ maintainers, so yourselves and other authors will be able to fix your emulation up. We must be getting close to 100% 48k accuracy by now, surely? What else is there left to do? To think it's 2006 and we still don't know all there is to know about the ULA!
D.
Luca
Dunny likes to call contention based on the IR register pair outside of M1 cycles as snow contention. But only when it causes the snow.
Could you let me know where you posted the results of your recent work, as I can't see any updates anywhere?
Updating website? It is very-very hard task. For some people indeed :D
Sending patch? It is on sourceforge, and made not by me. There are better C programmers around than me.
Is problem in concept of whole updating, or in you, I really don't know/care.
Moaning constantly? Well, all my bad suspects about RealSpec appeared as thrue :(
In the meantime I and Alessandro Poppi have cooperated to produce a full documentation of the 48K ULA using a logic state analyzer (lots of captures showing the real timings for everything). At the moment we have produced a document written in Italian which I'm going to translate into English.
@Piters: why don't you focus on a modern emulator instead of insisting to complain about RealSpectrum? Sorry you missed the gold age 2000-2003 when it was very actively developed, but now it's different and I have already explained my situation in many previous posts. Updates will come where there is something to update (hope soon).
Luca
You obviously not understand my points. But it is very common reaction of people to critic. Critic, which started good-willing from my site, but now it turned to pure sarcasm. Why? Because of your ignorance. Another typical reaction is recalling past - 'gold age'. I didn't miss that period, just was not on this forum.
Nobody here ask for your situation (or mine, or anyone's). I will repeat now myself - problem is your easy-made 'will do it' statements. And we have almost nothing done in last 2 years.
Problem is your website, where everything is frozen in last 2 years. OK, it may stay so, but then don't write there about sending bug-reports and similar. Write there something like: 'folks, that's it, and sorry that we can not fix bugs, improve program because of.... etc.' .
If you write there that something is emulated, but in fact is not emulated - because it simple not works - it is very iritating. Is it now clear where is your ignorance?
P.S. Yes, I use now 'modern' emulator, very focused :D
Concerning the new tests made by Alessandro (which I'm translating into English), he noticed that the INT signal is asserted by the ULA immediately after the rising edge of the Z80, which is also the time when the CPU samples it. This caused the CPLD to detect the INT duration sometimes as 32T and sometimes as 33T; so he moved the trigger on the falling edge of the clock. Could this be the explanation for the dual set of timings that we all know?
Luca
Seconded !
Should I shut up, and forget all after many e-mails, explanations?
Luca
Luca
Then please remove section where problematic emulation is. There is too long list, some shortening will make it easier to follow.
Thank you for encouraging people to help your work...
What this means: 'and I didn't fix your bug' ? So, you think that bug is mine? This is really sad...
Realspectrum was really fine in its day but now it's outdated and mostly outmatched by SPIN and FUSE, which are much more promising, not to mention also actively begin developed. We've seen this happen time and time again. Any emulator author will eventually quit developing his work after a couple of years, and most of the secrets involved will be lost. Our Speccy knowledge, of course, is constanly evolving, but it would be nice if we didn't have to constantly re-invent the wheel. FUSE is opensource, I gather, which is quite promising in that respect, although willing and competent developers will always be in short supply. I can't say much about its accuracy, as the only Win32 incarnation I could find was deemed as "buggy and missing a lot of features"...
Again, I'm repeating that RealSpectrum is obsolete since a long time, you can read my ancient posts recommending people to use a modern emulator (unless they need a specific feature of RS, of course), especially because I cannot maintain it actively anymore. Many other emulators have simply disappeared during time, nevertheless their authors have not been pestered this way despite their promises for never-seen updates. Why I am so special, I don't know...
Luca
Luca
Ahem :-)
I think the reason you get pestered is because every now and then you come along and say things like:
"RealX is coming very soon now"
"Yes, we'll maintain the TZX format"
"Updates to the RZX format will be posted soon"
And then nothing much actually happens. We all know you have a real life(tm), I myself am working in a fulltime (40+ hours/week, more often 7 days/week) job, doing a full time University course, managing a family *and* trying to find time to write SPIN and BASin.
It's very difficult to juggle all that, but the key thing is not to volunteer for jobs that you can't find the time for.
A simple post along the lines of "RealX probably won't see the light of day for quite some time now, let's wait until Vista comes out and then we'll see" would probably gain you more respect.
D.
And you again reply selectively. But, it is your work, your site, and certainly not mine. Including all incorrect statements. At least, I never put on my site untested software, hardware project. And I listen to people who writes me.
To finish this chat: whether do something so complex like emulation with full effort, heart, or do it not at all. Nobody will care about second league.
Time never stops.
But the RealSpectrum, RealX and MakeTZX business are totally mine and I can't be considered a criminal because I don't work on them at people's request.
Luca
Yes, yes, you are a criminal! I saw lot of American movies where main villain had name Luca. Now everything is clear :D :D :D :D
I could not resist to mention that some things could be fixed in all this time spent in this useless talk...
Hmm, thought I'd said the contention was outside of fetch cycles ;)
I know where it's applied, which opcodes are affected and which one you missed in the RealSpec source ;)
Could be I suppose. It'd be viable.
I don't think that anyone here tried to make comparisons. There is even lot of emulators with disappeared websites, unaccesible authors and similar. But it is in fact all normal.
What Luca didn't get in all this is that we like RealSpec. We respect it. Maybe way how myself show it is not as expected... ehm. life is not easy, especially not in 21-st century in Eastern Europe. There is too much PR infiltrated from more 'advanced' countries. We don't like it.
Luca
PS: Is the ULA48 document of any interest actually, or is it useless work? (A sincere question, not rethoric)
Nothing. But an additional comment at the bottom of the doc about IR contention, even if not directly related to snow, would've been nice.
Probably. Remind me after I've fixed a recently discovered IDE_IDENTIFY bug :)
Do bears shit in the woods? Course it'll be interesting!
I've just noticed this use of this term in the forum and I'd like to report that I've registered "real life" as a federal trademark since 1987 and the use of it without prior permission or approval from me is illegal under US laws and covered under International Classification 9 of which the countries England and Italy are party to.
As such, anyone advertising, promoting, using or having a "real life" before or after 1987, deceased or alive, is liable to be sued by me for illegal use of trademark. Dunny, Luca, you shall be hearing from my attorney shortly. :P
Bytes:Chuntey - Spectrum tech blog.