Games behaving differently on the Next

[TheSMoG]

I thought the manual was a collaborative thing on a Google Docs @TheSMoG ? I remember making some minor changes. Were you the one who put all of it together.

It started life as this but very soon it was understood that the result lacked cohesion (for many many reasons, none to do with all the guys involved which helped immensely). Moreover as NextZXOS and NextBASIC were being enhanced, the core changed and things were being constantly added, a one-person "team" (especially one that never slept much) was needed to respond to such changes. Suffice it to say I redid everything from scratch 27 times before we got to what we have now.

[PeterJ]

So, are you Phoebus Dokos from.Greece? It's a very good job [mention]TheSMoG[/mention] . Can I ask if you considered adding a credit to Stephen Vickers, as the new manual has very much the same feel as the original.one? Also why is the forward from Henrique being removed out of interest.from the next release.

Thanks for answering all the questions.

[TheSMoG]

So, are you Phoebus Dokos from.Greece? It's a very good job @TheSMoG . Can I ask if you considered adding a credit to Stephen Vickers, as the new manual has very much the same feel as the original.one? Also why is the forward from Henrique being removed out of interest.from the next release.

Thanks for answering all the questions.

Aye, I am he
Originally (and if you recall the early texts) it was going to be his name up there with all of ours; then the text diverged so much from the original and it ended up being written basically from scratch (not everywhere; why change a good thing?)
Anyway the full story is that Henrique was supposed to put his name in the acknowledgements which is one of the few things I didn't touch; just dropped in its place when I typeset the thing. But it's a grand omission and one I will correct once the second edition is out (and add Cliff Lawson there as well because he too deserves one).
Regarding the forewards: Simply put I will remove both because I need the space as I need to cover even more and there's a hard limit on the pages because once you increase them, then the ring in the binding increases as well and then the manual just won't fit the box. Production choices are a b*tch let me tell you! The situation with the space was so dire that I had to make the cover thinner than I wanted. I don't regret any of the choices I had to make although they were difficult except the one where I didn't start all chapters on the right side. That drove me insane and it still does but such is the nature of the beast

[Pegaz]

I would have thought at the time, the Spectrum 48K Rubber Key was the most compatible Spectrum ever as it run everything available at the time.

It still is.
Never underestimate the power of good old rubber Spectrum, my son.
https://omega.webnode.com/news/mqm5-effect/

[djnzx48]

Originally (and if you recall the early texts) it was going to be his name up there with all of ours; then the text diverged so much from the original and it ended up being written basically from scratch (not everywhere; why change a good thing?)

That doesn't really make sense. The manual clearly copies the text of the original manual extensively. Why remove the names of the original authors just because some changes were made? It seems a bit strange to require attribution in the license if you don't credit those authors yourself.

[TheSMoG]

Originally (and if you recall the early texts) it was going to be his name up there with all of ours; then the text diverged so much from the original and it ended up being written basically from scratch (not everywhere; why change a good thing?)

That doesn't really make sense. The manual clearly copies the text of the original manual extensively. Why remove the names of the original authors just because some changes were made? It seems a bit strange to require attribution in the license if you don't credit those authors yourself.

The manual did follow our original directions by SpecNext and that's to keep the original's organization as it was and still is one of the best introductory manuals for any microcomputer. So to that extent I did copy SOME of the text. Extensively? No.
Not that it matters because I know the amount of work I did, but It just so happens that I have the numbers So out of a total of 342 pages, 75 only are based on the original 48K and/or +3 (which is what we used to base the very first text prior the rewrite) and of these only 10 have no changes whatsoever (but they will in the next edition as well as things have now changed yet again). I've also redone every single graphic from scratch (Even the music chapter which I did include in the 75 pages and it's basically an amalgam of the +3 and 48K manual is still modified for the 3AY capability of the Next and ALL THE graphics were done from scratch there too). Examples were made anew for the new PRINT capabilities etc etc etc.
Regarding the actual manual (because much more was written that had to be cut, the total size of the final manual which will find its way into a second volume) was over 500 pages.
-EDIT- I actually spent some further time on this (you never know until you double check yourself) and I went over my files. Original unmodified Vickers text is less than 7% of the total text, so if you call that "extensively" I'll have to politely disagree
That being said, not attributing Vickers is an omission which clearly fell through the cracks as I've admitted many times and it <EDIT>is ALREADY FIXED in the source text and will be released in the PDF version soon<END EDIT>

[djnzx48]

Yes, I would call 75 pages of text 'extensive'. But even if it wasn't, it only takes a few seconds to add someone's name to the credits if you use their work. That includes Penny Vickers and Robin Bradbeer, who contributed to the original manual as well.

[TheSMoG]

Yes, I would call 75 pages of text 'extensive'. But even if it wasn't, it only takes a few seconds to add someone's name to the credits if you use their work. That includes Penny Vickers and Robin Bradbeer, who contributed to the original manual as well.

Well admitting one has made a mistake which is already fixed I think solves any issue. That being said (and I'm not making any excuses); you manage a task of this size and are suddenly told that you have 3 days to wrap up ALL corrections, typeset, print AND bind a book and arrange for its transport across Europe, because out of the blue finally all pieces fell together and the machine is assembling and unless a manual is delivered by x date, people will have to wait for the next window of manufacturing which was 4 months down the road, doesn't leave one second to spare and mistakes WILL HAPPEN and they did. Post facto it's easy to say "it takes a few seconds". It also took a few seconds to fix LINE x TO y but we didn't. Corrections wise 9 people were working 4 days straight to wrap up while having to deal with their day jobs too. So this falls under that category too if you really must know what happened. I just didn't think twice about it because it was supposed to be acknowledged in the foreward anyway and I just didn't look; I had editors for that. Does that excuse it? Absolutely not; does it explain it? Yep; I think it does
EDIT: Anyway for the PUBLIC record attached below is the updated first page with FULL reference to all authors whose work I did use. The next version of the manual will be available in mid-May after I enter all corrections for errors we've found this far and it will include this.

[garryl]

I would have thought at the time, the Spectrum 48K Rubber Key was the most compatible Spectrum ever as it run everything available at the time.

Interestingly, this isn't entirely true either as there were several ULA and board revisions in the rubber-key models. In particular, the change from issue 2 to issue 3 rendered a significant number of games incompatible. This was because the unassigned bits on the keyboard i/o ports were no longer guaranteed to be 1, and some software had been written assuming they were. There was quite a hoo-hah about this in the magazines at the time, IIRC.

So, you might need to revise your claim to only include issue 1 & 2 rubber-key Spectrums

[PeterJ]

I understand your point [mention]garryl[/mention], but I still think the 48K has to be classed as the most compatible.

However, looking at your previous work Garry, I'm not going to argue the point! Nice to have you here. I assume you are the same Garry responsible for 3e?

We have one of your early Sinclair User type-ins here!

https://spectrumcomputing.co.uk/index.p ... 6&id=23307

[1024MAK]

I would have thought at the time, the Spectrum 48K Rubber Key was the most compatible Spectrum ever as it run everything available at the time.

Interestingly, this isn't entirely true either as there were several ULA and board revisions in the rubber-key models. In particular, the change from issue 2 to issue 3 rendered a significant number of games incompatible. This was because the unassigned bits on the keyboard i/o ports were no longer guaranteed to be 1, and some software had been written assuming they were. There was quite a hoo-hah about this in the magazines at the time, IIRC.

So, you might need to revise your claim to only include issue 1 & 2 rubber-key Spectrums

Err, there are hardware problems with issue 1 and some issue 2 boards, due to a problem with the design of the first ULA, machine code programs running in lower RAM that use I/O may not work correctly...

Mark

[4thRock]

I had a TC2048 and never run into any incompatibility problems.
For all practical purposes, it was fully compatible with the Spectrum 48K

[PeterJ]

Apologies if I moved this thread off-kilter, I was just querying the suggestion that the Next was the most compatible Spectrum machine ever. I have never studied in detail the differences between the board revisions.

[1024MAK]

I had a TC2048 and never run into any incompatibility problems.
For all practical purposes, it was fully compatible with the Spectrum 48K

Any software that was released after Sinclair introduced the issue 3 board, should run without problems on any issue 1 or issue 2 board (that use the first ULA version and have had the hardware deadbug fix applied or where a later ULA version is fitted) through to the final 48K board version (6A).

Mark

[Ast A. Moore]

This was because the unassigned bits on the keyboard i/o ports were no longer guaranteed to be 1, and some software had been written assuming they were.

Actually, it was never guaranteed. Any games that masked those bits off had no problem detecting keystrokes. That “incompatibility” was squarely on the early coders. Why they assumed that the three highest bits will would always be set is anyone’s guess. The Spectrum’s ROM routines certainly didn’t.

[Sokurah]

I'll see if I can find the source and make some changes. Don't expect it this week though

I don't know if you're thinking about a special fix for HDMI, but if so then it might not be worth it as the Next HDMI issue is being fixed. If you mean stopping the slowdown on a normal speccy, then no pressure—I love this game and it's become one of those cute little flaws

Well, the plan was only to see if I could eliminate the slowdown by tweaking the sfx.

So, since I'm currently at home with a fever, I've had a little fun optimising Dingo a bit for space and I've cleared enough room to put in an interrupt driven sfx routine ... but now I can't be bothered to actually do it, lol
Oh well, should I ever decide to do it there is room now

[R-Tape]

Well, the plan was only to see if I could eliminate the slowdown by tweaking the sfx.

So, since I'm currently at home with a fever, I've had a little fun optimising Dingo a bit for space and I've cleared enough room to put in an interrupt driven sfx routine ... but now I can't be bothered to actually do it, lol
Oh well, should I ever decide to do it there is room now

Howbe? PM sent.

[PeterJ]

Even though it's an USB connector on it, I'm fairly certain the keyboard has to support the PS/2 protocols in order to work.

I appreciate this is off-topic, but I wanted to reply to [mention]andydansby[/mention]

You are quite right. I tried all my standard USB keyboards and none worked. I spoke to [mention]antoniovillena[/mention], and he suggested this keyboard from AliExpress. I was a bit nervous as the description mentions nothing about support for PS/2 protocols, but it arrived today and it works just fine.

https://www.aliexpress.com/item/4000510910225.html

[Alcoholics Anonymous]

Apologies if I moved this thread off-kilter, I was just querying the suggestion that the Next was the most compatible Spectrum machine ever. I have never studied in detail the differences between the board revisions.

The definition of most compatible seems to be different for different people The claim is also made in comparison to previous spectrum models. The uno is also a highly compatible machine, eg.

The claim is made because:

There are two kinds of 48K spectrums. Pre-issue 3 and issue 3 and higher. Some programs from pre-issue 3 cannot run on issue 3 and higher because of the keyboard difference already mentioned here. The number of affected programs is tiny but there are enough that a switch exists in most emulators to choose pre-issue 3 keyboard emulation and the same sort of switch exists in the Spectrum Next for the same reason. Naturally a 48K spectrum cannot run programs written for the 128Ks and later (which includes the Pentagon).

The tc2048 was mentioned here. It completely decodes the ula port and does not have floating bus behaviour on port 0xff which affects quite a few programs. We did run across one program that wrote to port 0xff for some reason and this caused the Next to change to a timex video mode -- the tc2048 would see the same thing. It could very well be the only program that does that but there is a small set out there that write to unused ports probably for debugging hardware. Of course it can't run 128K or later programs.

The 128K cannot run some 48K programs. It also cannot display some programs with effects written for the 48K because of different display timing. The 128K is incompatible with some +2A/+3 programs because of differently contended banks. ROM differences can mean some snapshots taken of basic programs cannot run on the +2/+2A/+3 and vice versa. Such a case was identified in this thread where someone's +2 snapshot of a basic program did not run on the Next because a 128K rom was being used to run it (since fixed). The 128Ks cannot run Pentagon programs properly because of different display timing and contention, which the Pentagon does not have.

The Pentagon cannot run 48K, 128K programs exactly because of differences in the video frame and contention.

However the Next can run all the programs above properly with proper timing, contention and correct roms in place. The number of programs found not to run correctly is tiny so far -- I have five on my to-do for example and two of those are testers designed to identify esoteric differences already argued about in this thread. Correct video timing currently relies on VGA 50Hz but it will come to 50Hz HDMI as well. There is minor willy demo program about that runs on a 48K and relies on analog effects to display different brightness on the screen -- this sort of thing is not going to display properly on the Next.

Beyond that something new can be done for peripherals. Because the divmmc and multiface are implemented internally in the Next we can make them compatible with each other which is not possible on any other system so far (this is something possible to do on any fpga computer, like the uno, if the devices are implemented internally). So you can, for example, run esxdos and use the multiface at the same time. By being able to specify a separate set of internal peripheral enables when the expansion bus is on, we can also allow the divmmc interface to function in parallel with attached and incompatible external peripherals. For example, normally the microdrives are incompatible with the divmmc interface but with this arrangement you can load something from sd card using esxdos, press a key to turn on the expansion bus and save the program to microdrive. This works in the reverse order too. You can load something from microdrive, press a key to turn off the expansion bus and then save it to sd card. Since the multiface can work with both, you can load a running program using esxdos, bring up the multiface, press a key to turn on the expansion bus and then use the multiface to save a snapshot to microdrive. This sort of thing has not been done before.

[Heimdall]

The 128K cannot run some 48K programs. It also cannot display some programs with effects written for the 48K because of different display timing. The 128K is incompatible with some +2A/+3 programs because of differently contended banks. ROM differences can mean some snapshots taken of basic programs cannot run on the +2/+2A/+3 and vice versa. Such a case was identified in this thread where someone's +2 snapshot of a basic program did not run on the Next because a 128K rom was being used to run it (since fixed). The 128Ks cannot run Pentagon programs properly because of different display timing and contention, which the Pentagon does not have.

The Pentagon cannot run 48K, 128K programs exactly because of differences in the video frame and contention.

However the Next can run all the programs above properly with proper timing, contention and correct roms in place. The number of programs found not to run correctly is tiny so far -- I have five on my to-do for example and two of those are testers designed to identify esoteric differences already argued about in this thread. Correct video timing currently relies on VGA 50Hz but it will come to 50Hz HDMI as well. There is minor willy demo program about that runs on a 48K and relies on analog effects to display different brightness on the screen -- this sort of thing is not going to display properly on the Next.

Could you please elaborate a bit on 128K ? I'm asking as I would love to have a parallel [to Next] codepath for a 3.5 MHz rasterizer. Save for 1-bit vs 8-bit, most of rest of the code should be same.

I plan to use a few larger LUTs, hence 128 KB. From what I've seen so far, cycle differences between Pentagon and regular Spectrum aren't huge - well as long as one is only doing low-framerate game, anyway. Couple thousands cycles per frame difference shouldn't matter in a ~10 fps scenario, I reckon.

Is there anything specific one should take care of, to ensure that the 128K version runs on each Spectrum that has so much RAM ?

[Alcoholics Anonymous]

Could you please elaborate a bit on 128K ? I'm asking as I would love to have a parallel [to Next] codepath for a 3.5 MHz rasterizer. Save for 1-bit vs 8-bit, most of rest of the code should be same.

I plan to use a few larger LUTs, hence 128 KB. From what I've seen so far, cycle differences between Pentagon and regular Spectrum aren't huge - well as long as one is only doing low-framerate game, anyway. Couple thousands cycles per frame difference shouldn't matter in a ~10 fps scenario, I reckon.

The 128K Spectrums have 70908 T in a frame and the Pentagon 128 has 71680 T. A big difference is that the Pentagon has no contention so that difference is actually larger than it seems if a good deal of time is spent accessing contended memory like the display file.

A couple of websites that give an overview of differences between the models can be found below. They're not complete and not too in depth but they give a good idea about the main issues.

https://faqwiki.zxnet.co.uk/wiki/ZX_Spectrum_128
https://spectrumforeveryone.com/technic ... ty-issues/

For the 128K machines the main thing is that the contended banks are different. The original 128K and +2 contend odd memory banks 1, 3, 5, 7 due to a hardware bug (the intention was to contend banks 4, 5, 6, 7). The +2A/+3 contends banks 4, 5, 6, 7. Amstrad was likely following the original design spec instead of the reality of the first 128K models when it made the +3.

The contention method is also different between the 128K/+2 on the one hand and the +2A/+3 on the other. The former stops the cpu clock and the latter uses the /wait signal and in a different set of circumstances. This leads to different secondary behaviour when programs affected by contention run.

Lastly the floating bus behaviour is different. The 128K/+2 sees the same sort of floating bus behaviour as the 48K and a small number of programs used that to snoop on the ULA to find out which part of the screen was being drawn. Until recently it was thought the +2A/+3 had no floating bus behaviour but it turns out it does, though it must be detected in a different and incompatible way.

If you're writing new software the main thing to worry about is which memory banks are contended because accessing data or executing programs out of contended memory is a lot slower. Because the 128K/+2 and +2A/+3 contend different banks, programs oblivious to this will run more slowly on one machine than the other. There is a huge gotcha in connection to contended ram however --- if the I register points at contended memory and you're executing code out of a contended memory bank, you can cause the machine to crash. I don't know the exact mechanism for this but it has been seen in modern day games, tested on a 128K spectrum, but found to crash on a +2A. Anyway the main outcome of all these words is that you should point I at uncontended memory and you may want to change what memory banks you load stuff into depending on the model so that your code/data sits in (un)contended memory as you intend irrespective of the model.

[Patrik Rak]

For the 128K machines the main thing is that the contended banks are different. The original 128K and +2 contend odd memory banks 1, 3, 5, 7 due to a hardware bug (the intention was to contend banks 4, 5, 6, 7). The +2A/+3 contends banks 4, 5, 6, 7. Amstrad was likely following the original design spec instead of the reality of the first 128K models when it made the +3.

Where does this info (that it was a bug) come from?

I was under the impression that the choice for 128K was deliberate. They only needed to contend two banks, for normal and shadow screen. But they wanted to make it cheap, so they have chosen just single line to select it, rather than using two lines and a gate. The fact that they have chosen the lowest bit and made it odd and even is as good choice as choosing the topmost bit. (It is also consistent with why they have chosen the banks 2 and 0 to be mapped in by default, rather than 1 and 0, and why the normal and shadow screen is 5 and 7, rather than 6 and 7. I mean, this is a hint they were very much aware of what was contended and what wasn't.)

IMO the only reason why Amstrad changed it later is that they wanted to have one of the all-ram modes entirely uncontended. It's natural that they wanted to have all ram modes for linear blocks, so 0,1,2,3 and 4,5,6,7 make sense (the remaining 4,5,6,3 is just one way of making it possible to switch between the two, and 4,7,6,3 is just that with shadow screen mapped in). Because 5 and 7 must be contended, they have chosen to contend the 4,5,6,7 block. Again, they could have chosen to contend just 5 and 7, but you know, those gates don't come free.

Patrik

[Alcoholics Anonymous]

Where does this info (that it was a bug) come from?

It's coming from the Derby design spec (which I have never seen nor can I find it in a quick google search) and the 128K service manual. The 128K service manual clearly documents banks 4,5,6,7 as contended (VA14 and VA15 are not in a don't care state for those banks) even though the reality is banks 1,3,5,7 are contended. So I think it's very likely Amstrad used these documents for the +3 and produced the 4,5,6,7 contention that it got.

It seems likely Amstrad never understood how contention was applied on the Spectrum either and just gave up to produce the /wait method they actually used. This is more in line with how the CPC machines work which round up the machine cycles to 4T using the /wait signal.

Everything else you said makes sense but the same could have been achieved with 1,3,5,7 contention by using different bits as input to the hardware

[Patrik Rak]

Thanks for the info, one learns something new every day. I never had a 128K myself, and neither that manual. I am in fact surprised they mentioned contention at all, I don't remember something like that ever mentioned in a 48K manual. For us, it was a matter of trial and error to find out that you really can't have a sound routine below 32768 . Good old days...

[AndyC]

There is a huge gotcha in connection to contended ram however --- if the I register points at contended memory and you're executing code out of a contended memory bank, you can cause the machine to crash. I don't know the exact mechanism for this but it has been seen in modern day games, tested on a 128K spectrum, but found to crash on a +2A. Anyway the main outcome of all these words is that you should point I at uncontended memory and you may want to change what memory banks you load stuff into depending on the model so that your code/data sits in (un)contended memory as you intend irrespective of the model.

It's actually the other way around, pointing I at uncontended memory is fine on a +2A/+3, but causes issues on a 128 or original +2. The +3 manual suggests it can theoretically cause a crash although I don't think anyone has successfully proved a guaranteed repro case for that. It certainly does cause snow issues on the display. Best avoided in any case.