Zeus assembler - code generation?

The place for codemasters or beginners to talk about programming any language for the Spectrum.
animaal
Berk
Posts: 6
Joined: Sat Mar 09, 2019 5:14 pm

Zeus assembler - code generation?

Post by animaal » Sat Mar 09, 2019 5:19 pm

I'm using the Zeus assembler to build a little program. It's about 3K in size so far.
The code runs works fine in Zeus' built-in emulator.
When I assemble it, the generated Z80 file won't work with Spin or Spectaculator.
The Z80 files load, but the results are corrupted. sometimes, I see a few of the graphics appear before the spectrum crashes hard.
For any particular z80 file generated, the results are identical in Spin and Spectaculator.
Generating TZX files produces similar results.

The code below shows the top of my main ASM file.
Can anybody please tell me what I'm doing wrong? I'm sure it's something simple but I don't see it.
Thanks.

Code: Select all

zeusemulate "48K"
Zeus_PC=Start
Zeus_SP=$0000
output_z80 "testapp.z80",$0000,Start

org $C350  ; 50000

attr_start equ #5800
stepsize equ 4
TIMER equ 23674



Start: di
       im 1
       ei
       ...
0 x

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

Re: Zeus assembler - code generation?

Post by djnzx48 » Sun Mar 10, 2019 12:10 am

Hmm, it works alright for me, in both Spin and Spectaculator. What version of Zeus are you using? Could it be the rest of the code that's affecting it? Does it work if you remove everything but those top few lines from the source?
1 x

animaal
Berk
Posts: 6
Joined: Sat Mar 09, 2019 5:14 pm

Re: Zeus assembler - code generation?

Post by animaal » Sun Mar 10, 2019 11:51 am

Aha, problem solved. Or at least identified.

In my code, I had quite a few instances where I tried to increase HL by using e.g.:
ADD HL, 224

Zeus translates it to "ED 34 E0 00", which indicates that it's an extended instruction with extended opcode 34. This is not a valid instruction for the Spectrum, but is valid on the Spectrum Next.

So I'm trying to use Spectrum Next instructions on a 48K Spectrum, and only the embedded Zeus Spectrum emulator (or a Spectrum Next) could execute it.

Thanks for the suggestions.
0 x

dfzx
Microbot
Posts: 170
Joined: Mon Nov 13, 2017 6:55 pm
Location: New Forest, UK
Contact:

Re: Zeus assembler - code generation?

Post by dfzx » Sun Mar 10, 2019 3:04 pm

animaal wrote:
Sun Mar 10, 2019 11:51 am
Zeus translates it to "ED 34 E0 00", which indicates that it's an extended instruction with extended opcode 34. This is not a valid instruction for the Spectrum, but is valid on the Spectrum Next.
Dumb question from the uninitiated: why would an invalid Z80 instruction work on a Spectrum Next? I haven't really followed the Spectrum Next story, but isn't a Z80 a Z80?
0 x

animaal
Berk
Posts: 6
Joined: Sat Mar 09, 2019 5:14 pm

Re: Zeus assembler - code generation?

Post by animaal » Sun Mar 10, 2019 3:32 pm

My limited understanding is that the Spectrum Next is new hardware. The processor is a programmed FGPA rather than being a true Z80 chip. It's programmed to act like a Z80, and behave like a true Z80.

Since it is a relatively powerful device, acting like a Z80, the capability exists for the designers to extend it (e.g. increase its speed, add instructions), and that's what was done. It's backwards-compatible though, so a Spectrum game can still run on it.
1 x

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

Re: Zeus assembler - code generation?

Post by djnzx48 » Sun Mar 10, 2019 9:02 pm

Wow, interesting. I'll have to watch out for that. I know there's an option to prevent extended instructions from being used, but I think it disables more sensible instructions like the ones operating on IXH and IXL, which you would usually want to have available.
0 x

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

Re: Zeus assembler - code generation?

Post by Seven.FFF » Thu May 16, 2019 2:11 pm

Yes, the Next has a smattering of Next-specific extended opcodes, all starting with the $ED prefix, chosen for compatibility because they execute as NOPs on a standard Z80.

They're chosen strategically to support some of the Spectrum Next features, such as calculating the screen addresses quickly and easily without worrying about row and screen third boundaries, drawing a single pixel strip down the side of the display after doing sideways hardware scrolling in the 256-colour mode, making uberfast jump tables for the streaming SD card feature, a bunch of LDIR variants with selective copying to support transparency and stenciling, and fast writes to registers (which are the Next's internal version of I/O ports for hardware and feature control, that aims to reduce clash with existing I/O ports). A few other more general things are also added, such as barrel shifts, fast 16 bit adds, fast 8 bit multiplication, etc.

Strategically, because only ones that could be implemented using a small amount of FPGA space were considered. Other perhaps more obvious extensions, like some found in the Z380 or Rabbit next-gen Z80s, weren't considered because they were space hogs.

So the Next has a quirky extended instruction set, mostly driven by developer feedback rather than being a grand unified design. A few people have criticised this, and it's broadly valid criticism. But rightly or wrongly, it's part of the Next's ecosystem now, and it's resulted in better released and WIP software, that really pushes the envelope. Standard Z80 code works 100% as expected, including all undocumented opcodes, but invalid opcodes that would produce NOPs might not. You'd really have to go out of your way to write a NOP that way on purpose in standard Z80 code, although of course anything's possible.

There will be an alternate FPGA core available that implements only standard Z80 and standard Speccy features, if people feel strongly enough to use that instead. And of course people can make their own core versions including mods of the official Next core. The mult-core nature of the Next means that switching cores for a particular task will be pretty quick and straightforward, so hopefully it's win/win and everyone is happy.

Having Zeus allow Next instructions when not in Next configuration was a temporary oversight, I recall, corrected by Simon in the latest test (bleeding-edge) versions. He doesn't generally publicise those, but I can attest the version at http://www.desdes.com/products/oldfiles/zeustest.exe seems as stable as the last official release.

Image
0 x
Robin Verhagen-Guest
SevenFFF / Threetwosevensixseven / colonel32
seven-fff.com/blog

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

Re: Zeus assembler - code generation?

Post by djnzx48 » Fri May 17, 2019 12:32 am

Yes, I suppose that's one of my main criticisms of the Next ;) Some of the instructions they added seem really random with oddly specific behaviour. It does feel as though they were just added whenever somebody wanted an instruction for something, rather than designing them for general purpose use.

And some of the instruction timings seem a bit unrealistic. According to the wiki, MUL is a two-byte instructions that runs in 8 T-states and multiplies two 8-bit numbers. Assuming it takes 4 T-states to read the instruction prefix, that only leaves 4 T-states to read the opcode, perform the multiplication, and put the result back into the DE register. Which seems a little unfeasible on an 8-bit CPU? It's as if these instructions are doing some 'magic' to compute values faster than would normally be possible.

Oh well, this discussion has probably been done to death already, and it's too late to change things now. So we'll just have to accept that they're in there.
Seven.FFF wrote:
Thu May 16, 2019 2:11 pm
Standard Z80 code works 100% as expected, including all undocumented opcodes, but invalid opcodes that would produce NOPs might not.
Not according to these tests ;) Or have they fixed the inaccuracies by now? At least the Z80 core can be modified to fix bugs and add/remove instructions, so it isn't as big of a deal as if the hardware were static.
0 x

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

Re: Zeus assembler - code generation?

Post by Seven.FFF » 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?
0 x
Robin Verhagen-Guest
SevenFFF / Threetwosevensixseven / colonel32
seven-fff.com/blog

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

Re: Zeus assembler - code generation?

Post by djnzx48 » Fri May 17, 2019 1:56 am

You're right, I guess there's no particular reason. But the more of these 'magic' instructions they add, it starts to look less like a Z80 and more like one of those fantasy architectures that only exist in software.

The new instructions are also inconsistent. Why is there OUTINB but no OUTDNB? Why PIXELDN but not PIXELUP? Why does TEST only operate on immediate values?

I get that these instructions are needed to make proper use of the new hardware and screen modes. But it doesn't seem like the most elegant solution.
0 x

Post Reply