Zeus assembler - code generation?

[Seven.FFF]

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:))

[djnzx48]

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.

[Seven.FFF]

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

[Seven.FFF]

Yeah, it has to be fixed, because people started releasing physical games on SD early on, and tons of people have bought them.

[RMartins]

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 ...

[Seven.FFF]

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.

[Seven.FFF]

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.

[szilvasyz]

Hi All,

I am new here, so please forgive me if my question is not at the most appropriate place, but I could not find better.
So I am working on hardware test program for a specific Z80 based microcomputer in order to help starting/troubleshooting the machine after building it from scratch.
One of the first test steps is checking if reading the ROM are is working without errors. I thought to write a macro to populate all the ROM area with pseudo-random data beyond my test code (this is already working), and my test code should read all ROM data for calculating somewhat CRC or similar and comparing it to a stored copy. My only problem is how I can generate such a CRC or other checking value with Zeus in compile time for example into the last 2 bytes of my ROM area. I see the main difficulty in calculating the checksum with also the compiler generated machine codes at the beginning of the ROM (the pseudo-random filled areas can be calculated within the macro that fills it).

Have you got any idea to solve the problem?

Thank you in advance,
Zoltan

[djnzx48]

You could try using the two built-in functions, XOR_MEM and SUM_MEM for simple single-byte checksums. They take two arguments, the start address and the length of the memory area to be checksummed, and return the bytes XORed or ADDed together respectively.

[szilvasyz]

You could try using the two built-in functions, XOR_MEM and SUM_MEM for simple single-byte checksums...

Thank you very much, it might be useful. However, byte wide XOR and ADD do not perceive order of the bytes, therefore swapping of memory areas cannot be detected (for example swapped 2nd and 3rd 4k ROM within the 4x4k ROM area). I will think about how I can utilize these functions for my purpose.

[djnzx48]

If the basic checksum algorithms aren't enough, I suppose you could use XOR_MEM and SUM_MEM with a length of 1 to read individual bytes from memory, and utilise them in a loop to calculate a proper CRC. Or if ADD/XOR based checksums are adequate, calculate checksums of the four memory regions separately and store those.

[szilvasyz]

you could use XOR_MEM and SUM_MEM with a length of 1 to read individual bytes from memory, and utilise them in a loop to calculate a proper CRC

It is a brilliant idea [thumbs up]

calculate checksums of the four memory regions separately and store those

Yes, the actual workaround had been programmed exactly this way. It works perfectly.