Zeus assembler - code generation?

The place for codemasters or beginners to talk about programming any language for the Spectrum.
User avatar
Seven.FFF
Manic Miner
Posts: 340
Joined: Sat Nov 25, 2017 10:50 pm
Location: USA

Re: Zeus assembler - code generation?

Post by Seven.FFF » Fri May 17, 2019 2:06 am

It isn’t! What’s already been added will
Stay for compatibility, and new instructions will be considered in a more unified way.

This is actually real hardware, not fantasy software, btw. I have one sitting on my desk right here, and I promise it is pure hardware:))
0 x
Robin Verhagen-Guest
SevenFFF / Threetwosevensixseven / colonel32
seven-fff.com/blog

User avatar
djnzx48
Manic Miner
Posts: 553
Joined: Wed Dec 06, 2017 2:13 am
Location: New Zealand

Re: Zeus assembler - code generation?

Post by djnzx48 » Fri May 17, 2019 2:14 am

Yeah, I know that it's real ;) I was just making a comparison.

Good to know that the current instruction set is fixed. It'd be a pain for compatibility if stuff kept getting changed.
1 x

User avatar
Seven.FFF
Manic Miner
Posts: 340
Joined: Sat Nov 25, 2017 10:50 pm
Location: USA

Re: Zeus assembler - code generation?

Post by Seven.FFF » Fri May 17, 2019 2:17 am

The philosophy so far has generally been to make things easier for newcomers to make programs and get involved, by pragmatic means. Jim will be happy to tell you this at length if you get talking to him.

I realise that there is also a competing purist approach, where people get satisfaction from recreating life in the 80s and living authentically. But if you look at the progression of the Sinclair, Timex, Amstrad, MGT and later Russian clones, nothing really ever stood still. The whole thing was a continuous progression of new developments with sometimes slightly flawed back-compatibility.

Any of those designers in the moment would find “future us” telling them their particular iteration is the one true authentic holy relic as very odd indeed :)
0 x
Robin Verhagen-Guest
SevenFFF / Threetwosevensixseven / colonel32
seven-fff.com/blog

User avatar
Seven.FFF
Manic Miner
Posts: 340
Joined: Sat Nov 25, 2017 10:50 pm
Location: USA

Re: Zeus assembler - code generation?

Post by Seven.FFF » Fri May 17, 2019 2:18 am

Yeah, it has to be fixed, because people started releasing physical games on SD early on, and tons of people have bought them.
0 x
Robin Verhagen-Guest
SevenFFF / Threetwosevensixseven / colonel32
seven-fff.com/blog

User avatar
RMartins
Manic Miner
Posts: 392
Joined: Thu Nov 16, 2017 3:26 pm

Re: Zeus assembler - code generation?

Post by RMartins » Fri Jun 21, 2019 6:18 pm

Seven.FFF wrote:
Fri May 17, 2019 12:50 am
The instructions are realistic in the sense that they’re implemented as fast as is possible with a 28MHz master clock and an extra 4Ts for the prefix fetch. Things can happen on every rising and falling edge of that clock, which the Z80 designers did not have access to in their design. They had four times fewer edges, and more limited internal space.

Is there really any point in artificially slowing them down to make them authentic to something that didn’t actually exist in the 70s?
But if new very fast instructions are being implemented using all the features of the FPGA, why then just the new instructions get this treatment ?
Specially, if there is going to be 2 distinct implementations, one that is pure Z80, and one that is not.

Probably for retro compatibility, in timing critical code, on old games.
But this seems like an exercise in trying to please everyone, without actually fully pleasing anyone.

This is starting to look more and more like the old days of Javascript Browser wars.
The ZX Next, is a moving target ... you never know if your game will run, in the next iteration ...
0 x

User avatar
Seven.FFF
Manic Miner
Posts: 340
Joined: Sat Nov 25, 2017 10:50 pm
Location: USA

Re: Zeus assembler - code generation?

Post by Seven.FFF » Fri Jun 21, 2019 6:28 pm

You do, because backwards compatibility with earlier Next cores is being strictly maintained.

The early games that were published well over a year ago still work, no breaking changes are deliberately made, and every core build is tested quite rigorously against existing software to guard against accidental regressions or bad builds.

It’s not rocket science to do it this way and get it right, despite what you’re suggesting.
0 x
Robin Verhagen-Guest
SevenFFF / Threetwosevensixseven / colonel32
seven-fff.com/blog

User avatar
Seven.FFF
Manic Miner
Posts: 340
Joined: Sat Nov 25, 2017 10:50 pm
Location: USA

Re: Zeus assembler - code generation?

Post by Seven.FFF » Fri Jun 21, 2019 6:41 pm

And yes, the original Z80 instructions have to be 100% timing critical, as does the other virtual hardware like ULA, divMMC, multiface, etc.

People are wanting these machines precisely because there are an exact number of Ts per line and lines per frame, with known instruction timings, for all the models that are simulated. And they’re wanting esxDOS to run just like it does on a physical divMMC, etc. Which it all currently does.

Slipping a perfectly Zilog-accurate Z380 in there might fit somebody’s purist idea of how a Z380 should behave, but for timing reasons it ain’t going to run Spectrum games and the machine is not going to behave as a Spectrum, even though the instruction set is binarily back-compatible.

Adding a small number of individual extra instructions that expedite working with specific hardware does nothing to detract from meaningful Z80 compatibility or Spectrum compatibility, OTOH.

For the entire lifetime of the Spectrum, additional hardware has always used custom mechanisms to talk to it, be that I/O address mappings, RAM address mappings, RAM/ROM execution traps, NMI, magic opcode sequences, magic BASIC variable usage, etc. All mechanisms have always had the potential to fail in environments where the hardware isn’t present, or to be theoretically incompatible with other hardware when the two hardware designers hadn’t considered mutual compatibility. Or when some earlier dev accidentally strayed into the control mechanism of a later piece of hardware like the Stampers did with the 128K paging port. Yet the entire affair has largely remained a non-issue for decades apart from a few edge cases.

You’re not obliged to use instructions, or the divMMC, multiface, RTC, UART, or NextBASIC if you want to stay living in 1982/1985/1987. Just as it should be. And quite honestly, the Next will still serve you well, and you wouldn’t know or care custom features were there if somebody hadn’t told you they were.
0 x
Robin Verhagen-Guest
SevenFFF / Threetwosevensixseven / colonel32
seven-fff.com/blog

Post Reply