At least it's free software and actually supports a truckload of archive formats. I could have used RAR but... well ya know
![Smile :)](./images/smilies/icon_e_smile.gif)
At least it's free software and actually supports a truckload of archive formats. I could have used RAR but... well ya know
We will offer a printed second edition IN COLOUR which will include a TOC and Index because unlike the one that ships with the cased version there's no hard limit on the pages the moment the Covid-19 situation subsides and we know where we all stand. Additionally I'm right now reorganizing the text a bit and since Phil and Henrique's foreward will be removed there's a good chance that the KS2 included copy will also have them (TOC and Index or at least a TOC). It was very difficult removing the dedication text for Rick from the manual for obvious reasons (one of the obscure reasons I was talking about)
Ant Attack! It was my first game when I got my original Spectrum way back in 83 then I downloaded and played Vallation just to feel good about myself.
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.
Aye, I am hePeterJ wrote: ↑Sat Apr 25, 2020 9:59 pm 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.
It still is.
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.djnzx48 wrote: ↑Sun Apr 26, 2020 12:54 amThat 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.
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
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.
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...garryl wrote: ↑Sun Apr 26, 2020 9:11 pmInterestingly, 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![]()
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).
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.
Well, the plan was only to see if I could eliminate the slowdown by tweaking the sfx.R-Tape wrote: ↑Sat Apr 25, 2020 5:56 pmI 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 flawsI'll see if I can find the source and make some changes. Don't expect it this week though
Howbe? PM sent.Sokurah wrote: ↑Tue May 26, 2020 1:11 pm 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![]()
I appreciate this is off-topic, but I wanted to reply to [mention]andydansby[/mention]andydansby wrote: ↑Wed Apr 22, 2020 11:50 am 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.
The definition of most compatible seems to be different for different people
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.Alcoholics Anonymous wrote: ↑Wed Jun 17, 2020 6:03 am
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.