Z8000 modular computer

[Tadeusz Pycio]

After five years of putting this project off, I decided to take a chance and realise the idea in a minimal form, as an SBC module with the weakest CPU in the Z8K family - Z8002.
The module will serve as a teaching aid, a completely alien architecture to the Z8000 for me, so it will not represent the possibilities offered by the processors of this family.
I have already made some design assumptions specifying the construction of a modular computer on the 16-bit Zilog architecture. Module PCB size 100x100mm, DIN41612 64-pin AB connector. The basic system will consist of a backplane, a CPU module containing a clock, a RESET circuit and partial signal decoding for the I/O modules, a memory module and an I/O module.
Ultimately, this computer is to run under CP/M and Linux. An interesting feature could be the use of the Z80 (via the Z8038 FIO) or the Z280 as an auxiliary processor.

I hope I will have enough time to realise these plans, especially as I do not intend to abandon RCBus development.

[Tadeusz Pycio]

Assembled version, on a Z8002 clone made in GDR ;)

[Ronny Ribeiro]

It's a beautiful gadget!
Congratulations, Tadeusz!

Em seg., 24 de mar. de 2025 20:51, Tadeusz Pycio <ta...@wp.pl> escreveu:

Assembled version, on a Z8002 clone made in GDR ;)

--
You received this message because you are subscribed to the Google Groups "retro-comp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to retro-comp+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/retro-comp/3b61d303-2e1e-4965-a59b-dbd6e693bb43n%40googlegroups.com.

[Bill Shen]

Tadeusz,
Very cool!  I'm interested in your progress.  I have 4 ceramic Z8002 with gold lid dated 7946 and 7947.  I hope to power them up one of those days.  I also have two Z8001 of similar vintage.
Bill

[Ed Porter]

On 24/03/2025 12:33, Tadeusz Pycio wrote:
> After five years of putting this project off, I decided to take a chance
> and realise the idea in a minimal form, as an SBC module with the
> weakest CPU in the Z8K family - Z8002.

Also interested in this. Will the pcb files be available anywhere?

-ed

[Tadeusz Pycio]

I will make the production files available once the design has been checked for errors. Currently I have already checked the clock circuit, single step operation, I am currently testing the memory glue logic. I didn't expect that there might be interest in building this SBC, however, it is a Z8K version with a limitation of 64kB of supported memory. Personally, I am treating this SBC as a testing ground and to check the sense of the placed signals on the bus (I have some doubts and would like to clear them before final approval). Perhaps someone has comments, I'd love to hear them.

[Tadeusz Pycio]

It's been a long time since I've had such problems getting my own project off the ground. It took me four evenings to finally get it working. In my justification, I can say that I had three unknowns.

• Hardware correctness
• GAL equations
• Software (completely new architecture, no assembler documentation)

I'll admit I'm angry with myself because I made a reprehensible mistake when connecting the data bus to memory, admittedly the situation is saved by the fact that I have to split the resulting binary file into even and odd parts, so reversing bits in a byte is not a problem. I don't know how I didn't notice this during the design. The SBC works, it displays the prompt, so it's time to write monitor.

[Alan Cox]

On Sat, 29 Mar 2025 at 23:13, Tadeusz Pycio <ta...@wp.pl> wrote:

It's been a long time since I've had such problems getting my own project off the ground. It took me four evenings to finally get it working. In my justification, I can say that I had three unknowns.

• Hardware correctness
• GAL equations
• Software (completely new architecture, no assembler documentation)

I'll admit I'm angry with myself because I made a reprehensible mistake when connecting the data bus to memory,

Everyone does it. I did that with a TI chip, only in the TI case your diagram above would have been correct because they numbered the bits the other way. My HC11 board still has a step where you swap bit 0 and 2 before flashing the ROM ;)

What I am curious about though is what you are going to use as a toolchain for the Z8000 ?

[Tadeusz Pycio]

Hi Alan,

This is what I had the biggest problem with, I checked several assemblers (under DOS, CP/M, Linux) and it looks like the GNU Bintools package will be the primary environment for now (I even have a version of it compiled under Windows). Ultimately, I want to set up a virtual machine with RedHat 9 where I can also use GCC. Currently, the Monitor programme is already successfully compiled using as-coff, ld, ... and the unfortunate odd-even split program with bit reversal. 

[Ed Porter]

There is some z8000 support in a prehistoric version (2.9) of gcc, and
it's still part of the rest of gnu binutils, but I don't know of any
newer compilers. If there are any others I'm interested to know that too.

https://www.z80ne.com/m20/index.php?argument=sections/download/z8kgcc/z8kgcc.inc
http://www.mirrorservice.org/sites/sources.redhat.com/pub/ecos/releases/ecos-1.2.1/

-ed

[Mark T]

I think the use of DIN41612 ab connectors is a good choice for the 100x100 modules, takes up slightly less space than ac type. Do you have a backplane and any plans for a card frame?

I’m trying to create a frame using 1020-3.3 extrusions 150mm length available on aliexpress, so the backplane is 10 connectors on 15mm spaceing instead of 0.6 inch. Pinout is not committed other than 5v on a1, b1, c1 and 0v on a32, b32 and c32. I included row c but not planning to use it for now.

[Tadeusz Pycio]

Hi Mark,

The use of the DIN61412 ab connector was dictated by the economy of the PCB footprint, but it does carry certain limitations. I still don't know what signals should be on the bus, as I am missing a few signals with a 64 pin connector.
The idea presented earlier forces, for systems with MMU, to place this IC on the memory module (A16-A23 and SN0-SN7). The A16-A23 address bus signals in systems without MMU can be obtained from SN0-SN7 (so in fact A16-A23 are redundant).
A second solution is to place the A8-A15 and A16-A23 signals (instead of SN0-SN7), but this forces the MMU and DMA chips to be on the CPU module (the PCB is small and these chips are DIP48).
This dilemma is delaying the design of the backplane and further modules, as I need to decide on a concrete solution. At the moment I can only design the I/O modules, as these will not be a problem.
So this is an early outline of the design of this system and I'll admit about the rack I haven't thought about it yet, although I've already looked at the PCB slides BT-90 (attached).

[Tadeusz Pycio]

I didn't mention the third solution, the most revolutionary one, rebuilding the whole bus, without A16-A23 (because basically what module is supposed to generate these signals?), and in their place adding DMA-REQ, DMA-ACK, two additional signals related to the coprocessor cascade (low priority) and I would probably find something missing there. The existing solution would go in the bin, but the MMU still on the memory module. I am missing 8 pins. :)

[Mark T]

I think BT-90 might be too long to suit the 1020-3.3 rails, these are 20mm wide, overall depth of the rack is 112-115 mm. 

I’m planning to use these type which seem quite common, also the 4 mm depth works with the 2.75mm edge of the rails.

https://www.amazon.ca/dp/B07N2HXCCP?

3d printing of rails would be better, but I don’t have a 3d printer and probably too much time to learn how to design the parts, though that would avoid having a plate between the rails to hold the guides.

Allpcb have a deal on new orders of 6 layer board up to 150mm by 100mm, which spurred me into trying to get this to work. I’m still trying to get the board through their dfm review. One layer for each row of signals and 5 v, and separated by ground planes. A and B rows are buried, C is on component side, with ground between signals on each layer. 

I’ll need brackets to mount the backplane, moving from 150x100 to 150x120 for the backplane is a huge increase.

[Tadeusz Pycio]

I think I have already made my choice of what signals should be in the ZBUS. The solution with the MMU chip on the memory module is a very bad idea, so there is only one option left, with the A8-A23 address bus available on the connector. The segment signals (SN0-SN6) will only be within one main CPU module. In the extended version, the MMU and DMA chips must be there, in addition to the CPU. The CPU module will always have to provide the generation of the A8-A23 signals, and the modules that will need the youngest A0-A7 addresses will generate them themselves. I have dispensed with the generation of the vector interrupt acknowledge signal, as the I/O modules need to decode the IORQ signal from the ST0-ST3 signals anyway, so this will be possible within the same IC. I have added the EOP signal instead.

Below is a preliminary version where I have moved the most used signals to row B, the AD and control buses have been split using two other signals to make it easier to put the necessary buffers and latches in the DIP20. I now need to make PCB sketches of several modules to see if any adjustments are needed. I'm glad that the Z8000 family is a maximum clock of 10MHz, so I don't have to care about other aspects.

[Tadeusz Pycio]

First fixes, the Zilog-specific DMA controller cascade signals have been removed because the bus does not allow such chips to be added in other modules besides the CPU module. In their place, signals for handling the second DMA channel have appeared, which I am happy with. The next changes will be small enough for me to start working on a workshop version of the backplane. It will include 4 slots + 1 angled slot, which will be useful for launching new modules, and a 3A switching power supply (the SBC Z8002 draws 720mA).

   

[Bill Shen]

720mA is lots of current.  Is Z8002 responsible for that?  Do you have a hot spot?

Bill

[Tadeusz Pycio]

Hi Bill,

This is mainly due to the processor, it heats up quite a bit, regardless of the manufacturer used (I have a Z8002 MME clone and a Z8004 Toshiba, Zilog unfortunately does not). The Z-SCC also heats up. I don't think this is a worrying current draw, both of these chips catalogically should consume 300mA, and the high-speed SRAMs used can consume 100mA apiece. Although, on the other hand, the SBC runs at a clock of 3.68 MHz, so what happens at 6 or 8 MHz? NMOS Z8000 chips run at a maximum frequency of 8MHz, above that it's CMOS Z16C00.

[Bill Shen]

You’ve mentioned in your first post of using Z280 as auxiliary processor.  That sounds interesting.  I have a Z280 SBC operating in 16-bit Zbus mode; maybe it can be modified to work with Z8002.  What’s your concept regarding Z8002+Z280?

Bill

[Tadeusz Pycio]

Hi Bill,

I was referring to the mechanism built into the Z280 ( and described in the documentation ) related to global memory access. The Z280 has a local memory register, and any reference outside of it activates the GREQ line, which is connected to the BUSREQ of the Z8000 chip, allowing information to be exchanged between processors using Z8K system memory. This solution requires more memory than the sparse 64kB Z8002, so it is more likely to require the Z8001. For this reason, I didn't want an MMU on the memory module, because it would have prevented the use of this technique.
The Z8000 family had a lot of interesting peripheral circuits, one of the most interesting ideas was the Sharp LH8075 - Multi Task Support Processor, it is probably unobtainable, but it shows what hardware solutions were attempted in those days.

[Tadeusz Pycio]

In the Z280 documentation, I found a passage describing this mechanism.

[Bill Shen]

I remember that diagram.  In fact Z280 manual has a whole chapter on various multiprocessor configurations.  I didn't know what to do with that feature while designing Z280, but since Z8000 and Z280 both have ZBus signals, it may be interesting to check out some of Z280 multiprocessor features.  Since I already has a Z280 SBC, I thought it may be possible to append a Z8002 directly on the Z280.  Shut off Z8002 first and use Z280 to load Z8002 software then shut off Z280 and run Z8002.  Maybe it is possible to use Z280's serial port as the console.  Something to play with in this cold, blustery day.
Bill

[Tadeusz Pycio]

Yes, this Z280 functionality offers many possibilities and, according to the documentation, it can also operate in 8-bit mode. Among my unrealized projects there is a Z280 module that could work with any RCBus kit as a second processor using this technique. With the right address bus mapping, you could think of a Z8002 ROM-less kit, with Z8K memory loading via the Z280. The only disadvantage is the need for 4-5 buffers in DIP20, which takes up space on our small PCBs.

[Tadeusz Pycio]

Slowly this computer is developing, the important thing is that something is happening ;) The test SBC Z8002 has already been checked on a converted monitor (non segment) of the Z8001MB project, I also ran the monitor and BASIC presented in the book "Basic-Interpreter" by Rolf-Dieter Klein. Unfortunately my SBC has too little ROM for me to quickly check out the more extensive BASIC version from the SBCZ8002 project (I could adapt it so that it could be loaded into RAM, but for the moment I see no need to do so). 

I already have the backplane built and tested, so the next module I plan to make is an I/O module (SCC serial port, CIO counter/clock) and CF storage (16 bit) which I will be able to test with the SBC Z8002. The Z8001 processor module (minimal version, without MMU and DMA) and the memory module will be created once I have a working I/O module.

[MxArgent]

Ah, I'm excited to see where this goes! I've never actually used a Z8000 based machine that wasn't a Pole Position cab, so I'm eager for a good kitbuild option.

[Bill Shen]

Tadeusz,
You've motivated me to power up a Z8002 prototype board I built several months ago.  It is a modified Z280RC board which is populated with 16-bit DRAM, CPLD, and a adapter from Z8002 to Z280 socket.  I've programmed the CPLD to supply NOP instruction (0x8D07) to Z8002 and it seems to run OK, incrementing the addresses as expected.  So what was your next step?  Do you have a simple bootstrap code before installing a monitor?  What Z8000 assembler are you using?  Thanks for the inspiration.
Bill

[Tadeusz Pycio]

Hi Bill,

You infected me with the Z280, so we're even. ;) That Z8002 processor is a real monument, and then there's that ceramic casing.

Under Linux use the GNU Bintools package, for Windows I have prepared an assembler to download here (not sure where I downloaded it from before).

[Tadeusz Pycio]

I've found some SN74LS610 chips in my drawer and a thought is starting to cross my mind ‘what if I combined them with the Z8002?’. Maybe this is the right way to make a simplified substitute for a segmented version of the Z8001 out of the little useful 64kB space this processor offers. I am tempted to do so. :)

[Alan Cox]

On Tue, 29 Jul 2025 at 09:57, Tadeusz Pycio <ta...@wp.pl> wrote:

I've found some SN74LS610 chips in my drawer and a thought is starting to cross my mind ‘what if I combined them with the Z8002?’. Maybe this is the right way to make a simplified substitute for a segmented version of the Z8001 out of the little useful 64kB space this processor offers. I am tempted to do so. :)

Given the price those parts seem to go for I'd probably sell them for an obscene markup and use programmable logic to implement something similar or fast DP RAM to provide paged memory.

The TMS99xx was a 64K address space architecture, and the LS61x was originally the MMU for that processor line. Together they gave you a minicomputer on a board. No full system level protection but enough to support V6 Unix and the like. They were also pretty fast because the TMS99xx architecture used memory for registers so was *very* dependent upon fast (and thus expensive) RAM for performance even before adding the overhead of the MMU path.

I don't see why it wouldn't work on the Z800x and it's probably no less sane than the segmented model. It's not like you'd be trying to run an authentic Onyx Z8000 V7 unix image on it anyway.

Alan

[Tadeusz Pycio]

I was asked why the progress of the work was so slow. I will answer publicly - because of its complexity and the desire to keep the project on track, quite ambitious. Yes, I could have taken the lowest road and built a working computer, but many of the modules presented would not have been right. I set out the assumptions of the project below. I'm still struggling with the difficulty of putting all the through-hole components on cheap dual layer PCBs. I don't have room for a CF card slot and/or IDE connectors on modules (3) and (8) and I guess the only solution for both modules will be a piggyback board, which I don't like very much. That is why I have included module (4) in the figure, which does not solve the Z280 SBC problem anyway. Modules (3) - (7) are already pre-designed, I am making some bug fixes and will soon start creating PCBs for them. The Z8001 CPU module will simultaneously appear in a MIN version (CPU alone with the required glue logic) and a MAX version with MMU and DMA (here I have the unresolved problem of not knowing under what conditions the MMU frees up the address bus, and the logic for extending clock bars through the Z8581 clock chip). So much for clarification.

[Bill Shen]

You are way ahead of me, if it is any comfort.  I’m still deep down in the rabbit hole trying to figure out why the “in” instruction does not work consistently on my z8002 prototypes, plural for prototypes, I’m on my third prototype boards!

Bill

[Tadeusz Pycio]

Hi Bill,

Strange, your diagram looks correct. The IN instruction only needs to decode the I/O transaction (ST0-3 - 0010) and bind to the W/R signal. Are you sure you are reading from odd addresses?

I, for one, am trying to design a Z280 SBC module for the Z-BUS bus and cannot fit the required glue logic and the IDE connector itself (the CF card slot requires even more space). The render shown is the required ICs for the SBC itself and the global bus access buffer. I guess I will have to overcome my reluctance to such a solution and add this piggyback board after all.

[Tadeusz Pycio]

I found in my resources an interesting SBC on the Z8001. I have no idea where I got this picture from and can't find any mention of this project on the web. Perhaps someone has some information about this computer? 

[Ed Porter]

On 15/08/2025 18:20, Tadeusz Pycio wrote:
> I found in my resources an interesting SBC on the Z8001. I have no idea
> where I got this picture from and can't find any mention of this project
> on the web. Perhaps someone has some information about this computer?
>

> microbrain8000.jpg
That's mine. I never managed to get it fully working; in particular I
couldn't get the MMU working. I think my power supply is/was inadequate,
but also there are probably still errors in the pcb (the green wires you
can see are to do with address latching).

This thing being only a partial success is why I'm interested in yours;
maybe after I've seen your effort I can fix this one.

-ed

[Mark T]

I found this one instead

https://www.smbaker.com/scotts-z8000-cp-m-8000-clover-computer

[Tadeusz Pycio]

Hi Ed,

Congratulations, your project looks impressive. It's true, it's difficult to get this type of project off the ground without having some experience from others like it. I read somewhere that using an MMU introduces quite a lot of latency, which is why Zilog developed the Z8581 clock chip which stretches the clock so that the address latching problem is eliminated. Perhaps this is a clue?

@ Mark, Yes, I am familiar with this project. It is a monolithic structure broken down into individual elements in the form of modules. What I like about this design is the use of the hardware hack that was used on the Olivetii M20, to map the ROM in the upper address area. I also want to use it on the Z8001 MIN module, as it is a very convenient solution.

[Jaap van Ganswijk]

I  think I have such an Olivetti computerboard somewhere. Let the bidding war start!

--
You received this message because you are subscribed to the Google Groups "retro-comp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to retro-comp+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/retro-comp/1125bc98-b23b-4d06-b0f5-2afa7fd917a5n%40googlegroups.com.

[Tadeusz Pycio]

Today, I found an interesting project involving the conversion of NASCOM ROM BASIC Ver 4.7 from Z80 to Z8002. I know that such practices were used during the launch of 16-bit processors. I was interested in the assembler used in this project, and I managed to find it. Maybe this information will be useful to someone.

[Tadeusz Pycio]

It looks funny, and such a raw conversion that does not take advantage of the capabilities of the architecture is slow. Well, maybe that's when the marketing idea of ‘if the programme runs too slowly, buy a faster processor’ came about. :D

[Bill McMullen]

Wow ~5.3 MINUTES!  I know we were used to slow machines back then but that looks pretty slow for a 16-bit system.  I use that same program as part of benchmarking and under MBASIC 5.21 it runs in 30 seconds on a 33MHz Z8S180 and in 6.8 seconds on a 50 MHz eZ80.  While it will be interesting to see what an optimized BASIC interpreter can do on the Z8000, I'm going to stick with the 46 times faster eZ80 for now.

[Tadeusz Pycio]

I mentioned this as a curiosity, that such conversion operations were carried out, and that Zilog itself provided the tools for this. You can read more about it here.  
I don't consider this a tragedy. It should be remembered that this is 8-bit mapped code on a 16-bit processor, and its 16-bit registers operate on bytes corresponding to Z80 registers. The original Z80 processor running at the same clock frequency and with the same BASIC dialect achieves worse results.

[Bill McMullen]

No offense meant and I respect and appreciate those who are currently working on Z8000 projects.  Many times I've also considered starting a Z8000 project (probably with Z16C01) but other projects got in the way.  I'm just surprised that Zilog went to a lot of effort to create a new instruction and memory model yet there wasn't a significant performance increase.  I assume that part of the issue is their choice of a multiplexed AD bus which adds extra cycles.

[Tadeusz Pycio]

Another interesting fact that took me all day, without success. As I mentioned earlier, I have a working monitor and a monitor with BASIC RDK, but I started playing with the NASCOM BASIC presented here, which was quite capricious because it did not always start up. The suspicion fell on the SCC initiation, which used the OTIRB instruction (quite logically), while I had been using OUTIB and loops to load SCC registers. I decided that OTIRB might be too fast for SCC requirements and used my own solution. This caused the welcome screen to appear every time, which brings me to the crux of my unsolved problem – the CONIN procedure. The code is identical in my monitor and in NASCOM BASIC, except that in the latter it never exits the received character status loop. 

              CONIN:
3A04 00E1       INB RH0,WR0A
0600 0101       ANDB RH0,#01H
E6FB            JR Z,CONIN

I am conducting tests on the same computer and getting different results. One learns throughout their entire life and dies a fool, because I have no idea how to resolve this error. I understand Bill's frustration. Sorry for this post, but I had to vent my 8 hours of failures somewhere.

PS. Simply replacing long jumps with relative jumps shortened the execution of the presented programme to 303 seconds, and this is not optimisation.

[7alken]

all this is very interesting Tadeusz :-) thanks 

[Tadeusz Pycio]

Well, today I started checking again what could be causing this behaviour, made a few cosmetic changes to the code, and it started working as expected. I'm a little angry with myself because I don't keep copies of non-working programmes, and I have to go back to the previous state to understand why it wasn't working. The changes were really cosmetic (I didn't change anything in the procedures) and couldn't have affected the behaviour of the program. The only change was a different address for the SCC initialisation procedure. Could the location matter? (This is starting to resemble a witch hunt.).

Another code clean-up. I wonder if this will allow me to get below 300 seconds? The next step would be to completely rewrite the code for this architecture, but I'm not a big fan of BASIC to continue with that.

[Tadeusz Pycio]

I will leave solving the puzzle for later. Another code cleanup, this time using some of the capabilities of this architecture. I removed the subroutine for comparing emulated HL-BC registers as an instruction for comparing two Z8000 registers. The result of the ‘benchmark’ ;-) is below, along with the working code. Perhaps someone will find it useful and want to do something with it. 

PS. Achieving a 10% increase in efficiency using such simple methods is quite remarkable.

[Tadeusz Pycio]

After many days of searching, I finally managed to get hold of miniature switches, which are manufactured in locking and momentary versions. I do not know how durable and reliable they are, but at the moment they are the only reasonable solution for small PCB when three active contacts are required. I must admit that I did not expect it to be such a big challenge to find switches with an angled mount. It was the last missing piece that was holding me back from starting to design the PCB. Perhaps now this computer will begin to take physical form. Unless you can suggest a more interesting solution. :D

The photo shows the switches discussed and a comparison with a typical 6x6 push button.

[Tadeusz Pycio]

I managed to go back to the non-working code and compare it with the working one, and you can see the aforementioned cosmetic changes in the code. Now I have to solve the puzzle of whether the processor or the hardware is to blame (perhaps some incorrect decoding in GAL). Such strange cases undermine experience and skills, so I will continue to explore the subject until it is resolved.

PS. The presented BASIC has an error in the DIM instruction, but I have not yet checked whether this is the result of my ‘optimisations’ or whether it was already present before, after conversion from Z80 to Z8000. Once I have solved my puzzle, I will take a look at this too (you cannot play Star Trek... ;-).

[Bill Shen]

Tadeusz,
Thanks for the converted BASIC file for z8002.  I have a different Z8002 assembler (ZASM), so I reformated your BASIC file for ZASM.  I loaded it with Intel Hex loader into 0x200 and got this screen.  It is not all working, but is a good progress.  I thank you for the BASIC program.
Bill

[Tadeusz Pycio]

Hi Bill,

Congratulations on successfully starting up your computer. There may be more errors, so it is better to use the original source, because I made these “corrections” during my many hours of struggling with the inability to read the serial port. Fatigue may have reduced my attention to the correctness of the analysis of this code, and I probably made a silly mistake somewhere. By the way, I also recommend the assembler mentioned earlier. I am pleasantly surprised by it. I haven't encountered it before, but it is worth paying attention to because it is still being developed and is ideal for such basic purposes. After resolving this peculiar issue of the impact of the SCC initialisation location on the operation of the CONIN procedure, I will return to the analysis of the BASIC language. It keeps bothering me.

[Bill Shen]

I followed your suggestion and downloaded AS assembler; edited the original z8002bas to modify the console IO for my hardware.  Z8002bas now boot correctly on my Z8002 prototype and able to run the mandelbrot benchmark in 5 min 18 sec.  So somehow AS assembler generated different output than ZASM assembler.  Interesting to find out what are the differences.     
Bill

[Tadeusz Pycio]

Hi Bill,

It would be interesting to compare the binary files and match the differences to the programme listings. We cannot be certain about the quality of the assemblers used, as too few people have tested them. There may also be errors that arose during the adaptation of the sources to the specifics of a given assembler. Once I have dealt with my current projects, I will try to adapt the source to what I consider to be the reference assembler from the BINUTILS package.

[Bill Shen]

I will look into the differences between AS and ZASM.  It is bugging me.

Bill

[Bill Shen]

The ".byte" directive in ZASM is not generating correct output consistently.  Sometimes it will skip a byte to line up with word boundary, other time it doesn't.  It is inconsistent.  I don't think I'll use ZASM anymore.
Bill

[Mark T]

There is a recent project on hackaday that might be worth checking out if you haven’t already seen it.

https://hackaday.io/project/29613-stebus-z8000