playing with eZ80 on my RC2014 rig

[dean.ne...@gmail.com]

Hi all,

I started thinking before the announcement of the Z80 End-Of-life, of playing with the eZ80 processor.  I saw the Agon and wondered if it be possible to build a module for the RC2014.

I have never soldered or assembled any SMD stuff before - and oh my, those things are really tiny!.  

But despite my aging eyes and wobbly hands, I have managed to hand solder something together and today finally got RomWBW HBIOS to boot.

If anyone is interested in following along with me, I have a hackaday project:

https://hackaday.io/project/196330-ez80-cpu-for-rc2014-and-other-backplanes 

Any feedback suggestion would be very welcomed - this is perhaps the most challenging project I have tried to date - was never sure I would get this far.  Almost gave up a few times!  I have been learning a lot.

But I have had a bit of Retro Existential crisis.  Why am I doing this?  What is really the point? Is there a point?  Does it matter?  Should I not go outside and enjoy the sun! 

What ever the answer to those question might be, I sure do seem to be obsessed.  Its a lot of fun - well I think it is - sometimes is quite frustrating - but when it works - that really cool.  

Dean.

[Wayne Warthen]

I am thrilled to see this Dean.  You seem to have done exactly what I was contemplating as the most straightforward way to migrate to the eZ80.  It looks like you are using the Zeta 2 MMU, which is ideal as a mechanism for this.  The worst part is the need to use 16-bit I/O.  There is a lot of code in RomWBW that assumes 8-bit I/O.  A couple of decent macros may make this more palatable.

I hope to follow your lead on this in the near future.

Thanks! Wayne

[dean.ne...@gmail.com]

Thanks Wayne,

I do have a lot of questions.........  

I am happy to continue this discussion  here, or within an issue entry in your github project?  What's your preference?

> It looks like you are using the Zeta 2 MMU, which is ideal as a mechanism for this.

I am?  I basically just copied the standard config for RCZ80.  I went through and disabled all the drivers etc for the time being.  Then added mine for the eZ80 uart.  I also added a new CPUFAM and PLATFORM

Also went through the start-up code and just wrapped my changes in #IF (CPUFAM == EZ80)....

> A couple of decent macros may make this more palatable.

Yep - my thoughts also - part of the challenge is there is no assembly support for the new 24bit and other instructions of the eZ80.

1. In the implementation of HBX_BNKSEL, can I use the stack?

I need to use the OUT (C), r  instruction --- which is technically  OUT (BC), r.

This necessitated the use of BC register - so I had saved it onto the stack - then i was wondering if I was having a stack issue.  I did try saving it in the alt registers (EXX).  I think pushing onto the stack would work - but at the time of coding, I was having a hardware issue. (hardware issue since resolved).  But yet to test this fully.  But I do wonder if I can use the stack at all in the function?  What if the function is swapping the segment with the stack ?  If I cant use the stack, I can probably just use a couple of bytes in the on-chip's RAM.  

Just as I type, I am wondering if I can implement a pseudo function to enable doing the i/o with out need to set the B register  - hmmm - I think the ez80 even has hooks for illegal instructions - so hmm wondering... thinking....

2. I created a new CPUFAM and PLATFORM, but I am not sure what's the best conditional variable to use here

PLATFORM .EQU PLT_RCEZ80
CPUFAM .EQU CPU_EZ80

But I have only used CPUFAM for the conditional test --- as mentioned above, not sure what would be best approach here.

3. What function belong in the on-chip ROM and what belongs in the RomWBW image?

The eZ80 will boot into its on-chip ROM (its initially mapped at address $000000).  The on-chip ROM and RAM will be super fast - with minimal wait-states, unlike the external RC2014 ram module.

So I am thinking that the 'firmware' on the eZ80 is responsible for booting, setting up RAM/IO address ranges, wait states, address modes, and the configures all on-chip services (uarts, timers & counters, interrupts, the RTC, etc.).  It should be 'agnostic' of RC2014 module configurations.  

Once its ready, it then jumps to the first byte in the external 64K RAM address

Perhaps an interface within the firmware could be made available for code such as HBIOS/RomWBW to call.  This will be a table of jump functions --- allowing on-chip device configurations (baud rates etc).  Also maybe a feature to copy and execute a block of code in the fast on-chip RAM.

The RomWBW would just need to initiate a far call (CALL.LIL) to access these functions.

Dev tool chains could be targeted for the specific platform -- I understand that the preferred approach for developing eZ80 code is to use a variant of clang that targets the eZ80 -- similar to how what has been developed for the Agon.  I have not got that setup yet though.  Just using the Zilog IDE which has a very old version of C (C98) but it does have an assembler to target the eZ80 instructions.  This IDE is windows only (wine might work) - but it does have a nifty debugger.

4. No idea what i am going to do for interrupts

At the moment, I disabled INTs in the configuration.  But there will be some complexity with INT management.  The eZ80 mixed mode might work - but the handling of the correct version of RETI I think will be important. 

I will need to do some experimenting on this.

5. Dual CPU Mode

I dont have the hardware wired up for the Dual CPU  configuration.  Have no idea if my idea will even work. This will be a little bit down the track.  But the general idea will be the Z80 and the eZ80 can run side by side.  Only 1 processor has access to the bus (the Z80 is sent the BUSREQ to remove it, but when the Z80 is controlling the bus, the eZ80 will be isolated by buffers, with it continuing to run on its internal ROM/RAM).

Thanks again Wayne. 

Cheers

Dean

[Bill McMullen]

It's nice to see others working with the powerful but maligned eZ80.  I started a different PCB layout of my eZ-Tiny system using it's same features but on an RCBus "small" 4"x1.1" module which has roughly double the board area.  Project #73 is on a slow and low priority pace.

I've done a very QUICK scan of this project and would offer the following comments:

- As I understand it, the RC2014 RAM/FLASH board uses an AS6C4008 RAM which has a 55ns Taa (address access time) and 45ns Twp (write pulse width) requirements.  While the screenshot shows "0 MEM W/S", that would place the timing well outside the 18.432 MHz eZ80F92/F93 specifications.  According to Zilog specifications, worst case Taa would be (54.25-13-1)=40.25ns and the write pulse would be ((54.25/2)-6.5+1.6)=22.23ns.  The 55ns RAM *MIGHT* work under some circumstances but it is well outside the worst case specifications before even considering capacitance issues and any buffer or decoder delays.

- The eZ80 uses one cycle memory access and adding a single wait state doubles the memory access times.  One wait at 18.432 MHz would make for a roughly 9 MHz performance which would be noticeably slower than a zero-wait 33MHz Z180.

- In my experience, a four layer PCB is not required, even for a 50 MHz eZ80F91, and simply adds additional cost.  It might be different if you were designing commercially and required RFI testing but RCBus was never designed for that.

- If you're primarily using an external RAM & ROM card, including for banking, you can save a bit on the processor cost by using the F93 variant.

- If you're considering using the 50MHz L92 variant then you should seriously consider putting 10ns SRAM on the processor board.  A 55ns RAM would require at least two wait states (three to be fully compliant) and thus the system would effectively be reduced to about 12.5-16.7 MHz.

- Interrupts are very useful for faster processors but it should be noted that eZ80 interrupts are always entered in ADL mode.  For the F92/L92/F93 variants in ADL or mixed mode, the interrupt vectors are always located at physical address 00,I(7,0),IVECT(7,0) regardless of flash/RAM/external memory configuration.

- The IN0 / OUT0 instructions work fine for internal peripherals but macros for external I/O need to be aware that either the A or B register needs to be properly set before the I/O operation.

- The eZ80 will detect illegal instructions BUT unlike the Z180 it does not have a TRAP bit and thus it's much harder to differentiate a power-on vs RST 0 / JP 0 vs an illegal op-code.

[dean.ne...@gmail.com]

Hi Bill,

Ignorant am I - was the eZ80 maligned?

Thanks for the comments - I really appreciate it.  I think I mentioned before, I feel a little out of my depth!  So really appreciate the help/feedback.

>  "0 MEM W/S" 

This is just a mis-report of the boot message.  There is defiantly wait states applied.  The boot screen is generated by executing code in the external slow ROM.  At this stage I just applied the maximum wait states for the external memory and i/o requests.  Which I think is way more than what's required.  I intend to tighten this up to appropriate in-spec timings.

> In my experience, a four layer PCB is not required, even for a 50 MHz eZ80F91, and simply adds additional cost.  It might be different if you were designing commercially and required RFI testing but RCBus was never designed for that.

That's good to know.  I got my PCB made at JLCPCB, and the cost for the 2 layer and 4 layers were the same for Green boards.  If I wanted a different colour there is a one-off fee per run.  So I thought if 4 layers are so cheap, why not.  My understanding is that the solid ground layers help with a bit of capacitance - helping with decoupling power noise?  I not really sure I have the ability to truly and accurately measure this with my oscilloscope.  I also had a lot of confusion about the best decoupling caps to apply to the chip.  As I am hand soldering this, I went with 1uF caps around the chip's VSS/VDD lines, with some additional 10uf around the module to help.  As far as I can tell - it all seems to be working reliably.  I don't think there is a lot of bouncing of signals.

> If you're considering using the 50MHz L92 variant then you should seriously consider putting 10ns SRAM on the processor board.  A 55ns RAM would require at least two wait states (three to be fully compliant) and thus the system would effectively be reduced to about 12.5-16.7 MHz.

That may be down the track.  I am not too worry if its not fully optimised for performance.  I suspect with the chip's pipelining and other improvements, even with a few wait states, it will still be way faster than a normal Z80. 

> Interrupts are very useful for faster processors but it should be noted that eZ80 interrupts are always entered in ADL mode.  For the F92/L92/F93 variants in ADL or mixed mode, the interrupt vectors are always located at physical address 00,I(7,0),IVECT(7,0) regardless of flash/RAM/external memory configuration.

Yep - so I am not sure how best to map that to the Z80 compatible code.  I am assuming I can write a handler in the on-chip ROM, that will then forward to $0038 in the external ROM/RAM module's address - but I need to understand how the stack and RETI.?? need to work.  I am still learning how this chip works -- Am I right in that any existing code will need to change its RETI instruction, otherwise stack and ADL modes will get muddled?

> The IN0 / OUT0 instructions work fine for internal peripherals but macros for external I/O need to be aware that either the A or B register needs to be properly set before the I/O operation.

Yep

> The eZ80 will detect illegal instructions BUT unlike the Z180 it does not have a TRAP bit and thus it's much harder to differentiate a power-on vs RST 0 / JP 0 vs an illegal op-code.

Yeah - after thinking I might be able to leverage this, I figured out its not as helpful as I would have thought - and I don't think would be best way for what I need/want.

Last night I did an experiment with using RET.L 8 within compatible Z80 code.  Its just 2 bytes, I don't think it impacts the SPS (and doesn't need it for it to work).  I can then create a handler in the chip for this trap -- walk the stack and 're-interpret'' the next instruction:

so code such as:

RET.L  8

OUT (nn), A

would be effectively be interpreted as:

OUT ($FFnn),A

and so on for all other I/O. 

This could be a quick and easy way to modify RomWBW existing code. - I hope!

Dean.

[Wayne Warthen]

On Mon, Jun 3, 2024 at 7:51 PM dean.ne...@gmail.com <dean.ne...@gmail.com> wrote:

> Interrupts are very useful for faster processors but it should be noted that eZ80 interrupts are always entered in ADL mode.  For the F92/L92/F93 variants in ADL or mixed mode, the interrupt vectors are always located at physical address 00,I(7,0),IVECT(7,0) regardless of flash/RAM/external memory configuration.

Yep - so I am not sure how best to map that to the Z80 compatible code.  I am assuming I can write a handler in the on-chip ROM, that will then forward to $0038 in the external ROM/RAM module's address - but I need to understand how the stack and RETI.?? need to work.  I am still learning how this chip works -- Am I right in that any existing code will need to change its RETI instruction, otherwise stack and ADL modes will get muddled?

Interesting.  In the Zilog doc, it seems to indicate that under ADL or mixed mode, the mode 2 interrupt vectors would be located in physical RAM at I(15,0),IVECT(7,0).  Am I misunderstanding this?

RomWBW has a pretty structured interrupt management framework.  I don't think there should be any trouble accommodating this as long as it is possible to transition back to Z80 mode at the start of the interrupt.  Under interrupt mode 2, the eZ80 vectors could point to corresponding CALL.L statements which invoke the existing RomWBW interrupt framework.  Returning from an interrupt is done in a common location in RomWBW, so it is easy to change the RETI to RETI.L.

Thanks, Wayne

[Phillip Stevens]

On Sunday 2 June 2024 at 20:01:58 UTC+10 dean wrote:

I started thinking before the announcement of the Z80 End-Of-life, of playing with the eZ80 processor.  I saw the Agon and wondered if it be possible to build a module for the RC2014.

Hi Dean,

It might be useful to look at the way Dom added support for the Agon Light to z88dk.

I haven't followed along closely, but it is assumed to be running in z80 (ADL=0) mode, so I think most things would apply to your RC2014 application too.

At least z88dk-z80asm supports all the eZ80 instructions (look for ez80 or ez80_z80 in this list), so that you can use a cross platform assembler / linker that understands the LIL, LIS, SIL, and SIS suffixes.

Hope that's useful.

Phillip

[dean.ne...@gmail.com]

Hmm.  I wrote a reply to Phillip - but i don't see it now - did it get lost in the internet - or did I press the wrong button or something??

[Spencer Owen]

On 04/06/2024 10:15, dean.ne...@gmail.com wrote:
> Hmm.  I wrote a reply to Phillip - but i don't see it now - did it get
> lost in the internet - or did I press the wrong button or something??
>

Hi Dean,

There have been several Google Group messages that ended up in
quarantine over the past few days. I have been away, but tried to keep
an eye on them and let them through. I didn't see any from you in there
though, so it looks like it might have got lost somewhere I'm afraid.

Spencer

[dean.ne...@gmail.com]

Thank Spencer - but I think this was just me getting confused - I think i might have replied to Author  and not group.

[Bill McMullen]

Wayne: I don't use RomWBW but wrote my own interrupt-driven BIOS and utility routines in assembler for my eZ-Tiny (eZ80F92/F93) and Min-eZ (eZ80F91) designs.  I chose to use MADL=1 (mixed mode) and place things like the vector table, interrupt routines and disk routines plus buffers in ADL memory so as to keep the largest possible TPA (59K with CCP overlay) for application programs in CP/M 2.2.

The eZ80F92/L92/F93 with it's 8-bit I register handles interrupts slightly differently than the F91 variant which has a 16-bit I register.  The 92/93 interrupt vectors are based at 00,I(7,0),IVECT(7,0) unless in Z80 mode with MADL=0 in which case the vector is at MBASE,I(7,0),IVECT(7,0).  If internal flash memory is left enabled at 00,0000 with MADL=1 then it must include a level of interrupt vector indirectness to RAM which allows an application program to update vectors such as for timers or external interrupts instigated via a GPIO port.

The F91 variant with it's 16-bit I register uses 4-byte vectors versus the 2-byte vectors in the 92/93 variants.  Vectors are located at I[15:1],IVECT[8,0] UNLESS in Z80 mode with MADL=0 in which case they're at MBASE,I[7:1],IVECT[8,0].

All maskable interrupts on the F91/92/93 variants use vectored interrupts and thus the IM instruction is effectively a NOP.  Any interrupt scheme must be aware of the 24-bit internal flash & SRAM plus external memory configuration and also the MADL bit setting plus the possibility of ADL mode with interrupts enabled.  When MADL=0 the exit from an interrupt routine is via RETI whereas if MADL=1 the exit is RETI.L.

[Bill McMullen]

Dean:
<was the eZ80 maligned?>
There were those that were highly critical of the eZ80 for not being 100% compatible with the Z80.  There's the 8 vs 16-bit I/O difference by those who chose to ignore the Z80 capabilities and had simplified their hardware and software.  There's also the prefix instructions which replace the Z80 instructions "LD B,B", "LD C,C", "LD D,D " and "LD E,E".  Those instructions are effectively NOPs and in my opinion are simply meant to obfuscate code or set up for self-modifications, both of which I consider very poor programming practices.  Then again, the Z180 is also not 100% Z80 compatible but it's a simpler chip and much easier to understand.

<At this stage I just applied the maximum wait states for the external memory and i/o requests.>

The maximum wait states of 7 means that your memory access is taking about 434 nS which means the processor is effectivly running at about 2.3 MHz.

<I got my PCB made at JLCPCB, and the cost for the 2 layer and 4 layers were the same for Green boards.>

If you got 4 layer boards for the same price as 2 layers then it appears you probably got some kind of special deal. I just checked the cost at JLPCB and it's $2 / $7 and PCBWay is $5 / $25.97.

<I went with 1uF caps around the chip's VSS/VDD lines, with some additional 10uf around the module to help.>

You may want to look at Zilog's schematics for eZ80 boards.  In addition to providing a power reservoir, the VSS/VDD caps are meant to help prevent power spikes (ie noise) from getting back into the board's power rails.  Normally 0.1u caps are used but as frequencies increase, so do the noise spikes.  Zilog use a combination 0f 0.1u & 0.001u caps on each VDD pin of it's 50 MHz designs.  I use this on my 50 MHz Min-eZ but just 0.1u caps on my 18.432 MHz eZ-Tiny, both of which are two layer boards.  As to bulk capacitance, I use regulators with a fast response to transients and a single 10u bulk cap plus another one next to the SD card VDD pin.

<I am not too worry if its not fully optimised for performance.>

We obviously have different objectives and mine is to fully utilize the potential of processors that I use.  The benchmarks I've run on my Min-eZ show that it's in the range of a Z80 at up to 194 MHz.

<RET.L  8>
I'm not sure what assembler or language you're using but the eZ80 User Manual clearly shows that the RET instruction has no operands.  If you're relying on a fixed address already being PUSHed onto the SPL stack then that would preclude using your I/O technique in any ADL code or in an interrupt handler.  I'd suggest finding a different technique.

[Wayne Warthen]

Thank you Bill.  My primary mistake was that I did not see that the F92/93 has only an 8 bit I register.  I appreciate you pointing that out.

I think RomWBW will still adapt pretty easily because it already uses indirection during interrupts to handle bank switching.  It impacts performance of course.

Thank you, Wayne

--
You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/e36f6ab6-272d-48d6-92e7-61603974f69en%40googlegroups.com.

[Alan Cox]

> practices. Then again, the Z180 is also not 100% Z80 compatible but it's a simpler chip and much easier to understand.

The Z180 is compatible with the documented Z80 behaviour however,
which the ez80 is not. And as you have a proper UFO trap you can
actually make it very very close to compatible. Given how easy it
would have been to add some kind of trapdoor and a pure Z80 mode I can
only assume they were more than happy it wasn't important.

Certainly for CP/M it does not seem to be a problem.

[Bill McMullen]

Alan: Not to start an argument, but per Zilog's Q&A there are three instructions that are different between the Z80 & Z180, namely DAA, RRD and RLD.

As speeds increase, there will be different external timings among all three processors (Z80, Z180 & eZ80) which will necessitate different hardware designs.

  As someone who has actually written BIOS code and used the eZ80, I really don't understand the big deal that's made about it's compatibility.  The eZ80 in Z80 mode with MADL=0 and RAM + MBASE at 00,xxxx is very close to a Z80 while offering lots of new instruction options plus faster performance plus internal peripherals, all at 70% the price.  Even in mixed Z80 & ADL modes, CP/M 2.2 with all the utilities & applications I've tried and use on the Z180 will run without any changes.  Of course the BIOS drivers for peripherals are somewhat different as are any programs that directly access peripherals.  That's no different than the unique software requirements for a Z80/SIO versus Z180/ASCI.

[dean.ne...@gmail.com]

Thanks Bill,

> ...There were those that were highly critical of the eZ80 for not being 100% compatible with the Z80....

Oh right.  This is all new and wonderful to me :-) .  I guess, I will see how I feel in a few months --- how much will the the 'difference' annoyed me or helped me....

> If you got 4 layer boards for the same price as 2 layers then it appears you probably got some kind of special deal. I just checked the cost at JLPCB and it's $2 / $7 and PCBWay is $5 / $25.97.

You are right, there is a slight difference - and the special prices for the first order causing some more differences.  But in the grand scheme - not a big price difference for tiny orders.  But you have given me confidence that a standard 2 layer will be ok. Cool.

> We obviously have different objectives and mine is to fully utilize the potential of processors that I use.  The benchmarks I've run on my Min-eZ show that it's in the range of a Z80 at up to 194 MHz.

Yep.  First goal it to get good compatibility with the RomWBW/RC2014 modules/platform.  Later on, I can look at more optimised solutions.  I do want to, at some later stage, have a good amount of linear addressable RAM available for it.  Have some ideas -- but first just focusing on the compatibility.

> You may want to look at Zilog's schematics for eZ80 boards.  In addition to providing a power reservoir, the VSS/VDD caps are meant to help prevent power spikes (ie noise) from getting back into the board's power rails.  Nor....

Certainly have seen that - and other eZ80 design I could find. I have also tried to read up -- to try understand the theory of decoupling caps.  There do seem to be some conflicting expert opinions on it... as a very non-professional - it can get confusing....

>  ....User Manual clearly shows that the RET instruction has no operands.  I....

LOL - Arm yep ..... I had missed-typed.  I meant to refer to the RST.L instruction.  It seems to be a good way to 'break-out' of the Z80 Compatible mode when executing code in external RomWBW and to jump to code within the on-chip flash.  Have modified both RomWBW and my flash code and it seems to work nicely.  I can use this to help port the RomWBW code to support 16 bit I/O addressing and exposing other support logic with minimal changes in RomWBW.

I Do have a question for you Bill, if I may.  What tool-chain for code do you use? 

I have only been playing a few days, started with the ZDS IDE - its ok - but found a couple of issues already.  

* The simulator is very broken - I get real differences between it and real hardware.  Also encounter some assembly limitations.  

* The assembler does not seem to support LD.S C, (HL).  It does seem to work with the normal LD C,(HL).  I was able to just DB, the actual byte codes and the disassembler displayed the correct instruction....  Or maybe I am misunderstanding something here.

Cheers

Dean

[Alan Cox]

On Tue, 4 Jun 2024 at 21:16, Bill McMullen <mcmull...@gmail.com> wrote:
>
> Alan: Not to start an argument, but per Zilog's Q&A there are three instructions that are different between the Z80 & Z180, namely DAA, RRD and RLD.

I picked my words very carefully. The differences are not in the
documented guaranteed behaviour.

> As speeds increase, there will be different external timings among all three processors (Z80, Z180 & eZ80) which will necessitate different hardware designs.

Speed changes break compatibility for software too. There are several
CP/M games that are rather hard on an RC2014.

>
> As someone who has actually written BIOS code and used the eZ80, I really don't understand the big deal that's made about it's compatibility.

as I said

>> Certainly for CP/M it does not seem to be a problem.

The CP/M world generally doesn't rely on undocumented behaviour.
Trying to use ez80 in some other environments (or even Z180) is a
whole world of pain.

[Bill McMullen]

Dean,
re RST.L: That could work but whether ADL RSTs overlap with Z80 RSTs will depend on your memory configuration.  If MBASE=00 in your normal Z80 mode then RST.L = RST whereas if MBASE is non-zero the two will reference different locations in Z80 mode.  One of your first tasks should be to think about the internal flash & RAM 24-bit locations plus any external RAM & ROM locations.  That will define how you handle interrupts and where overlaps occur.

re tool-chain: I use the ZDS assembler as I wanted my source to be usable with a free and readily available package.  One of it's major shortcomings for me is the lack of a .PHASE directive which would allow for easy relocation of code from flash to RAM.  I've also had various other issues with perfectly valid constructs that it complains about but I found simple workarounds.

I spent a lot of time trying to get the linker to place code where I wanted and finally gave up as it didn't follow directives and also didn't give an error message.  My loader now relocates the .HEX data appropriately.

I've documented some of my ZDS issues but will summarize as saying I'm NOT impressed with the assembler, the linker or the code produced by the C compiler.  I simply found ways to make it work for what I wanted.

re "LD.S C,(HL)": The first question is whether you've issued an ".ASSUME ADL=0" or ".ASSUME ADL=1" directive.  In Z80 mode it shouldn't make any difference whereas in ADL mode it's ambiguous since C is always a byte.  I usually use the three character suffixes in order to be perfectly clear about what I'm trying to do.

[Bill McMullen]

Alan: I'll agree to disagree without getting into an extended semantic debate about the word "documented".  I simply go by documents that Zilog has published, including application note AN006601 which describes the differences.

If you're implying other environments use undocumented behavior then in my opinion, anyone who uses undocumented behavior deserves whatever pain they receive and it's no one's fault but their own.

[dean.ne...@gmail.com]

Hi Bill,

Thanks for the updates.

In regards to the LD.S C, (HL) issue:

> re "LD.S C,(HL)": The first question is whether you've issued an ".ASSUME ADL=0" or ".ASSUME ADL=1" directive.  In Z80 mode it shouldn't make any difference whereas in ADL mode it's ambiguous since C is always a byte.  I usually use the three character suffixes in order to be perfectly clear about what I'm trying to do.

Still very early days for me - so perhaps I am not understanding something here.  I want to load the byte @  {MBASE, HL[15:0} into C, whilst in ADL=1 mode.

The image above is from the manual.  Is this not the correct way to do this?  When I attempted to assemble that instruction, I get this weird error:  ERROR (501) AC_IY_indexed_byte4 expected in operand 2

As mentioned previously, I can manually inject the byte codes (DB %52, %7E) and it seem to work as i wanted.  So I was wondering if the assembler is just broken?

Dean.

[dean.ne...@gmail.com]

Sorry - muddled myself a bit in the last post - you might start to see a pattern from me here ;-)

so the relevant opcodes are %52, %4E

Hopefully i have it detailed correctly here!

Dean

[Bill McMullen]

Dean: I ran into some similar types of issues with the ZDS assembler and the fact that the error message is about IY indexing makes it appear to be in lala land unless there's an issue with your ending bracket or the end of the line.  Since you found a workaround, my thought would be to comment out the LD.S for now and follow it with the DB.  Once that sequence of code is working correctly you can go back and try fight the assembler.