udo-munk / z80pack

A Zilog Z80 and Intel 8080 systems emulation

z80pack

z80pack is a mature emulator of multiple platforms with 8080 and Z80 CPU.

Full documentation is at https://www.icl1900.co.uk/unix4fun/z80pack

Ubuntu

Building

First install the needed dependencies:

sudo apt install build-essential libglu1-mesa-dev libjpeg9-dev

Then run

make

to build all the MACHINES mentioned in the Makefile.

Release vs Development

Sometimes I get asked questions why something doesn't work, and this might be caused by using an older version and not the latest current. Sometimes people miss it, that the repository most of the time has two branches:

master - finished and final releases
dev - latest sources still under development, but usually stable

To use the latest dev version you need to do this:

git clone https://github.com/udo-munk/z80pack.git
cd z80pack
git checkout dev

You now will build everything from the latest dev branch and not some older finished release.

Running CP/M 2.2

CP/M 2.2 is the ancestor of MS-DOS. Use this command to invoke CP/M 2.2 with two disks containing some sample programs and sources.

(cd cpmsim; ./cpm22)

Use DIR to see files on disk. Exit again with BYE

Sample execution in WSL under Windows 10:

#######  #####    ###            #####    ###   #     #
     #  #     #  #   #          #     #    #    ##   ##
    #   #     # #     #         #          #    # # # #
   #     #####  #     #  #####   #####     #    #  #  #
  #     #     # #     #               #    #    #     #
 #      #     #  #   #          #     #    #    #     #
#######  #####    ###            #####    ###   #     #

Release 1.38, Copyright (C) 1987-2024 by Udo Munk and others

CPU speed is unlimited, CPU executes undocumented instructions

Booting...

64K CP/M Vers. 2.2 (Z80 CBIOS V1.2 for Z80SIM, Copyright 1988-2007 by Udo Munk)

A>dir
A: DUMP     COM : SDIR     COM : SUBMIT   COM : ED       COM
A: STAT     COM : BYE      COM : RMAC     COM : CREF80   COM
A: LINK     COM : L80      COM : M80      COM : SID      COM
A: RESET    COM : WM       HLP : ZSID     COM : MAC      COM
A: TRACE    UTL : HIST     UTL : LIB80    COM : WM       COM
A: HIST     COM : DDT      COM : Z80ASM   COM : CLS      COM
A: SLRNK    COM : MOVCPM   COM : ASM      COM : LOAD     COM
A: XSUB     COM : LIB      COM : PIP      COM : SYSGEN   COM
A>dir B:
B: BOOT     HEX : BYE      ASM : CLS      MAC : SURVEY   MAC
B: R        ASM : CLS      COM : BOOT     Z80 : W        ASM
B: RESET    ASM : BYE      COM : SYSGEN   SUB : BIOS     HEX
B: CPM64    SYS : SPEED    C   : BIOS     Z80 : SPEED    COM
B: SURVEY   COM : R        COM : RESET    COM : W        COM
A>bye

System halted
CPU ran 3 ms and executed 1958078 t-states
Clock frequency 630.22 MHz

Running CP/M 3

CP/M 3 was the next generation of CP/M with features from MP/M to notably be able to use more RAM along with a lot of other nice features.

Run with:

(cd cpmsim; ./cpm3)

Sample run:

#######  #####    ###            #####    ###   #     #
     #  #     #  #   #          #     #    #    ##   ##
    #   #     # #     #         #          #    # # # #
   #     #####  #     #  #####   #####     #    #  #  #
  #     #     # #     #               #    #    #     #
 #      #     #  #   #          #     #    #    #     #
#######  #####    ###            #####    ###   #     #

Release 1.38, Copyright (C) 1987-2024 by Udo Munk and others

CPU speed is unlimited, CPU executes undocumented instructions

Booting...


LDRBIOS3 V1.2 for Z80SIM, Copyright 1989-2007 by Udo Munk

CP/M V3.0 Loader
Copyright (C) 1998, Caldera Inc.

 BNKBIOS3 SPR  FC00  0400
 BNKBIOS3 SPR  8600  3A00
 RESBDOS3 SPR  F600  0600
 BNKBDOS3 SPR  5800  2E00

 61K TPA

BANKED BIOS3 V1.6-HD, Copyright 1989-2015 by Udo Munk

A>setdef [no display]

Program Name Display - Off

A>setdef [uk]

Date format used     - UK

A>setdef *,a:,b:,i:

Drive Search Path:
1st Drive            - Default
2nd Drive            - A:
3rd Drive            - B:
4th Drive            - I:


A>setdef [order=(com,sub)]

Search Order         - COM, SUB

A>setdef [temporary=a]

Temporary Drive      - A:

A>hist

History RSX active
A>vt100dyn
(C) Alexandre MONTARON - 2015 - VT100DYN

RSX loaded and initialized.

Try

 A>DEVICE CONSOLE [PAGE]

to see if it works...

A>dir a:
A: CPM3     SYS : VT100DYN COM : TRACE    UTL : HIST     UTL : PROFILE  SUB
SYSTEM FILE(S) EXIST
A>dir b:
B: BNKBDOS3 SPR : CPM3     SYS : LDRBIOS3 MAC : SCB      MAC : RESBDOS3 SPR : BIOS3    MAC : PATCH    COM
B: GENCPM   COM : BDOS3    SPR : GENCPM   DAT : BOOT     Z80 : M80      COM : LINK     COM : L80      COM
B: WM       COM : MAC      COM : WM       HLP : BNKBIOS3 SPR : LDR      SUB : INITDIR  COM : CPMLDR   COM
B: COPYSYS  COM : CPMLDR   REL : RMAC     COM : SYSGEN   SUB
A>bye

System halted
CPU ran 14 ms and executed 10493728 t-states
Clock frequency 713.42 MHz

z80pack's Issues

Fix the hack in the Altair memory manager for running TDL Apple

Priority: high
Difficulty: easy

This monitor requires some continuous memory starting @ 0 for programs etc., then F000-F7FF for the monitor ROM, an that followed again by RAM @ F800-FFFF. Do this with system configuration like this:

ram0 248 (pages, 0000-F7FF)
rom 16 (pages, F000-FFFF)
ram1 8 (pages, F800-FFFF, overwrites last ROM pages from top of memory)

Add 8080 opcode table to z80asm

Priority: low, I'm using Intel's 8080 macro cross assembler
Difficulty: easy

Add the 8080 opcode table and the same PSEUDO ops as in the Z80 table. Add new PSEUDO ops .Z80 and .8080 to switch between the instruction sets. Make .Z80 the default, that is the name of the assmbler ;-)

Setting port values

I am trying to explicitly set port values on in and out. Consider the following code:

main:
	IN a, (02h)
	LD a, 2ah
	OUT (03h), a
	HALT

What I would expect, is that when I do p 02 => 01 in simulator before the first step, a should be 01 by next instruction. However trying to manipulate the port does not change anything:

>>> p 02
02 = ff : 01
>>> p 02
02 = ff :

Furthermore, I would expect that when I inspect the port value after the last instruction, it should be 2a. However it is unchanged:

PC   A  SZHPNC I  IFF BC   DE   HL   A'F' B'C' D'E' H'L' IX   IY   SP
0002 ff 000001 00 00  81a0 4754 87d9 8d66 5d80 d5f1 91b0 91ad 94d7 5a40
LD	(1000),A
>>> 

PC   A  SZHPNC I  IFF BC   DE   HL   A'F' B'C' D'E' H'L' IX   IY   SP
0005 ff 000001 00 00  81a0 4754 87d9 8d66 5d80 d5f1 91b0 91ad 94d7 5a40
LD	A,02
>>> 

PC   A  SZHPNC I  IFF BC   DE   HL   A'F' B'C' D'E' H'L' IX   IY   SP
0007 02 000001 00 00  81a0 4754 87d9 8d66 5d80 d5f1 91b0 91ad 94d7 5a40
OUT	(00),A
>>> 

PC   A  SZHPNC I  IFF BC   DE   HL   A'F' B'C' D'E' H'L' IX   IY   SP
0009 02 000001 00 00  81a0 4754 87d9 8d66 5d80 d5f1 91b0 91ad 94d7 5a40
HALT
>>> p 00
00 = ff :

The only way I get prompted for a value input is if I change the IN instruction to use address 01h:

main:
	IN a, (01h)
	LD a, 2ah
	OUT (03h), a
	HALT

That results in blocking till input from terminal:

>>> r inout.bin
Loader statistics for file inout.bin:
START : 0000
END   : 0009
LOADED: 000a

>>> 
a

PC   A  SZHPNC I  IFF BC   DE   HL   A'F' B'C' D'E' H'L' IX   IY   SP
0002 61 111110 00 00  cfee 20f6 32fb 307c cfea 87b9 bd1e 6e8b b0d0 5c03
LD	(1000),A
>>> 

No matter what I do, though, I cannot seem to find any output value that matches the OUTdirective regardless of port.

Thanks.

Add .PHASE to Z80 assembler

Priority: high
Difficulty: medium

The CP/M assemblers are not really good for developing firmware, standalon software etc. Often parts of the code need to be phased to another execution address, to be able to move code from ROM into RAM and such. Of course the necessary offset calculations can be done with expressions, but this is a workarround for the missing .PHASE pseudo-op, not very comfortable.

Implement complete ALU instructions for IX/L/H and IY/L/H

Priority: low, the ones used by existing software are implemented
Difficulty: easy or difficult

Implementing the complete instruction block allows to enable the test for the instructions in the Z80 exerciser programs, and verify that everything is working correct.

Theoretially easy because it is mostly copy&paste work, but if the necessary changes are not done very pedantic it will be time consuming to find the bugs in the instructions. The exerciser programs are no help for finding out what is wrong. I have spend many nights in front of the emulation and a real Z80 machine to figure, why the emulation doesn't produce the same result as Zilog's silicon. This is no fun at all.

Add embedded web server for monitoring, management, websocket based IO connections

Priority: medium
Difficulty: difficult

I already have a decent library of frontend components that run in the browser (all native HTML/CSS/JavaScript)

• simulated GUI desktop, including the following virtual/emulated devices (some that I just made up)
• TTY: - VT100/ansi compatible character mode serial terminal, can be windowed or zoomed to full-screen (over websockets)
• CRT: - complete implementation of the IMSAI VIO (over websockets: mirrors the 2KB display RAM and does all rendering in the browser)
• LPT: - complete implementation of an 80-column dot-matrix/line printer with selectable paper-types - ready to print on your real printer (dumb text printer, no Esc codes, over websockets)
• X:DSK: & LIB: - graphical disk manager for the 4 floppy drives A-D, including eject, insert (drag-and-drop) from a disk library (.../machine/disks/library/), download disk image, upload disk image, delete disk image (uses RESTful web service interface)
• CPA: - IMSAI CP-A front panel (only the 6 control switches & 4 status LEDs on the RHS, over websockets)
• SYS: - system status window, shows details of the simulation (host?), enables remote reboot
• CFG: - configuration file editor, enables config files (.../machine/conf) to be edited and saved

You can see what they look like in the attached screen-shots.

These all work against my port of the imsaisim to the esp32 micro-controller platform. When the browser is made full-screen you would't know you were in a browser, it just feels like a desktop GUI.

Unfortunately the embedded webserver I am using in that port is specific to the platform and not available for OSX/Linux/Win. But if a suitable embeddable webserver can be found and integrated with the z80pack then all the frontend code it ready to go.

Maybe implement baud rate for other SIO's than the ones used for terminal

Priority: none
Difficulty: easy

Easy to implement with copy&paste from the SIO's with baud rate.

I am not interested in this. From 1974 - 1984 I was using plenty of machines with paper and cassette tapes, mostly for work that is. It was no fun at all to wait 20 minutes for loading an assembler, compiler, interpreter ... into the machines. I have done this stuff enough for this life already. If you wish to use a tape SIO at 1200 baud for whatever reason feel free to implement, but make sure the configuration allows 0 baud (unlimited), if not it won't be accepted, sorry.

Same for the communication SIO's. My first own modem did 300 baud, at work we already had 2400 baud phase modulated modems with a size larger than a shoe box and a mighty price tag. I still have fun to connect systems via serial for data transfer, but at nowadays speed.

tu-uart emulation does not match documentation

The manual states of 03 (interrupt register)

'After the register is read the corresponding bit in the interrupt request register is reset'

However the code as implemented only seems to update this on a 1 ms timer.

In addition the uart0_int value when computed considers the int_mask value at the point of computation, but does not appear to recompute the mask when the int mask changes only at the next ms timer.

It looks to me like the register state computation (as opposed to the timer expiries) is happening in entirely the wrong time domain, so that code which polls the register until it hits FF handling events spins for a millisecond incorrectly.

Add a revision number to the CP/M 2.2 BIOS (imsaisim)

I know that space is getting tight in the CP/M 2.2 BIOS for the imsaisim, but...

I have been spending time lately supporting people who couldn't get the harddisk working or couldn't reach the SIO2 ports etc...
It took me a while to ask the question "are you using the latest CP/M disk with the new BIOS
?" and some of them would ask "How would I know?"

Could you add a space a 'b' and 2 hex digits into the SIGNON banner after the CP/M 2.2 to indicate the BIOS version, and bump this each time you release a new BIOS?

This would make it quicker and easier to know what BIOS people have on their system disk.
eg.

60K CP/M VER 2.2 b01

You can get 1 byte back by removing the 'S' from 'VERS' (as per the example above). The CP/M2.2 OS Manual only shows 'VER' (page 1-3). There is also some redundant code and data in the BIOS that "initialises" the SIOs, but in the emulation this is ignored.

Add support for 8" DS/DD disks that are not in weird Cromemco track 0 SD format

2.txt

8080 16bit incrementer/decrementer drives address bus during execution

Mike Douglas discovered that the address latch in the 8080 CPU is active during instructions using the 16bit incrementer/decrementer logic:

https://groups.google.com/forum/#!topic/s100computers/zVoLe4vvUFw

Add output to the address bus in the 8080 CPU for such instructions.

Implement a Hayes (AT) style, virtual modem (over telnet).

I have created a working prototype of an AT command driven, telnet based virtual modem.
AT commands implemented include:

• AT, test AT
• AT?, display basic help
• A/, (immediate, not required) repeat last command
• ATH, hangup current connection
• ATDname:port, make a telnet connection to 'name' on the specified port (23, default if none given) then enter data mode
• +++ (with a 1 sec guard interval before and after), return to command mode from data mode
• ATO, (re)enter online/data mode

this appears to be a workable minimum set of commands to make and hangup a connection.

I currently have it implemented on the imsaisim, 2nd SIO on port A, but could just as easily move it to port B.

A couple of issues have surfaced:

1. something on the CP/M side is stripping bit 8 after receiving extended ASCII chars (>127) but before they are displayed. This is using KERMIT.COM on the TTY: console

• I don't think its the simulation device code
• It doesn't look like the CP/M BIOS would strip anyhting
• KERMIT is set parity none so it shouldn't be KERMIT
• Could the BDOS be doing this?

2. Some UI is required (probably on the web/desktop UI) to reset the modem in the event you cannot get control back with a '+++'
3. If the modem is moved to the 2nd SIO port B, it would be useful to have BIOS support to access it on the CP/M physical device UR1:/UP1: so KERMIT.COM can see it.

I will soon post a PR to make this available in upstream Z80PACK. For now I can also provide a custom firmware for the IMSAI8080esp that replaces UART1/RS232-2 support with this virtual modem on UC1: (2nd SIO on port A).

Implement the Cromemco D+7A I/O interface card as a virtual device

I have coded a working implementation of virtual Cromemco D+7A I/O interface card as I want to use this interface on the new S-132 add-on board I am developing for the IMSAI8080esp.

The current use case is fairly trivial - it is to support a pair of JS-1 style joysticks so that the original Cromemco software written for the Dazzler that also expects one or more JS-1 joysticks can be used (or played!).

Of course if you just compile and link the code for the virtual Cromemco D+7A I/O interface card it does nothing. The implementation depends upon the "client".

When the client is the S-132 then the data from the first 4 Analog input channels (connected to the XY pairs of the 2 analog joysticks) and the 8 bits of the Digital input channel ( 2 sets of 4 joystick buttons) are transmitted over a high speed serial UART (3Mbps) and 2 of the Analog output channels are transmitted back to the S-132 over the same link to support sound (still working on that).

I realise that I can also provide a client from the Desktop Web UI. My plan is to support 1 or 2 connected analog joysticks via the web API for game controllers and hopefully sound on the client (never tried that). This client will use web sockets for data transmission like most of the Web UI does.

The "bad" news is that the exisiting Cromemco software expects to see the D+7A I/O interface in the 8080/Z80 I/O port address space from 24-31 (decimal) 18h - 1Fh.

This is a direct clash with where I asked to put the real-time-clock (RTC) #71

Before this module is merged into the code, the RTC will need to be moved, and the CP/M 3 Plus BIOS modified to see the RTC in its new location.

Add MPU-B style banked ROM (and RAM) to IMSAI memory

Discussed first in #18

Initialisation messages from the frontpanel library do not format correctly if PR #12 is applied.

This can be fixed in a further update that moves all the frontpanel init/exit code out of simctl.c and into the correct place in the initialisation sequence i.e. init_io() and exit_io()

Timing for interrupts

Assuming I read the code right you don't account for interrupt delivery T states

I think something like this is needed for Z80 (and I don't know the 8080 timings)

add_timing.txt

Move MOSTEK ICE to own module

There are now two machines with MOSTEK ICE attached. It would be better to move it into it's own module, so that the code doesn't need to be duplicated. Also the ICE then can be plugged into any machine.

Move RTC from cpmsim into I/O module

The RTC also is wanted in the IMSA 8080, so move it out of cpmsim into an I/O module usable by any machine.

Create high quality pictures of the Intel 8 MOD 80 machine

Need front panel pictures for that with ownership definitive clear and the owner grants the permission for using this pictures in machine emulation software.

Be aware that z80pack pictures have been used to create posters, t-shirts, mouse pads and who kowns what, so you should be able to life with that. Personaly I don't mind about such usage, but then I'm not the owner of any graphics artwork included, I use the artwork for my emulations in conformance with the license granted.

Implement an MMU for the imsaisim

I would like to implement an MMU for the imsaisim machine to enable a banked implementation of CP/M 3 (plus).
It seems straight forward to use the same "design" as for the cpmsim machine, but I have a few considerations and a few questions.

On the ESP32 port, the extra RAM (4MB PSRAM) is not as fast as the internal RAM (it is SPI connected through a 32K cache). I have done some testing using 64K reserved in the internal RAM, and copying (memcpy) the current segment out to SPRAM and the new segment in from SPRAM. The one advantage of this strategy is that the existing memory implementation doesn't need to be modified, but it has a time cost.

Timing is a follows:

Segment size	Time to "switch"
16K	1.4ms
32K	3.2ms
48K	5.4ms

Its not linear because of the 32K cache.

Question 1:

Do you think the above timings for bank switching are acceptable, or do you think they will have a big impact on performance?

Question 2:

Is it OK to still use I/O ports 20-23, it looks like some are reserved because of a missing parallel port peripheral. If new ports need to be allocated what would you recommend?

Create emulation of the Intel MDS 800 system

Priority: low
Difficulty: difficult

Emulation needs to be acurate enough for running original and unmodified Intel ISIS
as well as original unmodified Digital Resarch CP/M distributions.

Review and fix uses of mem_base() in all machines that implement banked memory

Priority: low
Difficulty: easy or difficult, depends on each machine memory architecture

Machines that implement banked memory and also use mem_base() are only looking at the first/base bank when accessing values via mem_base().
This is happening now in report_error() (or similar) in all such machines when attempting to show the opcodes of instructions that fault with OPTRAP*, however, they are retrieving the bytes from the first/base bank via mem_base() and not the bank where the error occurred.
Possibly, uses of mem_base() should be replaced with macros that default to the mem_base() implementation for simple machines without banked memory, but that machines can selectively override to implement correct memory access for their individual memory architecture.

imsaisim webfrontend LIB: not working on xfs filesystem

After installing imsaisim, I was unable to get the disk library functionality in the web frontend working. The LIB: window in the web interface is always blank. I can upload disk images and they appear on the file system, but they never show up in the window.

I'm running CentOS 7 and have xfs file systems. It seems that xfs behaves differently from ext4 when it comes to dirent. The d_type returned for regular files is DT_UNKNOWN, not DT_REG, so on line 276 of netsrv.c all of the files in my library are filtered out:

if (pDirent->d_type==DT_REG) {

After switching to this, it works properly on my system:

if (pDirent->d_type==DT_REG || pDirent->d_type==DT_UNKNOWN) {

Implement a light-weight logging library

Priority: High
Difficulty: Easy

The objective with this is to:

• Differentiate log output to the console from the TTY: (CP/M) device I/O
• Allos for (later) redirecting the log output somewhere else like a file, syslogd, or a websocket
• Use something that is all(mostly) macro pre-processing and doesn't add weight to the executable
• Use something that is simply a header file eg. log.h
• Support a range of logging levels eg. ERROR, WARN, INFO, DEBUG, VERBOSE, and plain LOG
• Let the log level be set globally (and in each file individually if required) and is baked in at compile time
• Let features like colour-coding different log levels, customising the format and timestamp, be easily selected and changed by the developer

I've become use to having a library like this available from the platform on my ESP32 build, and since its under the Apache 2.0 license, I've made a simplified version that resolves everything down to vprintf() and is portable. I'll put it in a PR for dev, and there will be examples of it in use in the code I start to put up for #38 (or related).

DMA memory access should light the HOLD led on IMSAI CP-A

I noticed this while I was figuring out how the imsai-fif.c code worked.
I see in the code a number of lines like

bus_request = 1
...
bus_request = 0

but this never lights the HOLD led, as the dma_write() function makes no updates to the front panel.
Also there is no code to try and light the HOLD led at the time of any dma_read() in imsai-fif.c.

My first thought was to alter dma_read() and dma_write() to take care of lighting the HOLD led, but then I noticed other modules using dma_read() and dma_write() that aren't meant to be performing DMA memory access, e.g.

• simctl.c
• imsai-vio.c
• sim1.c
• sim1a.c

(the cromemco-dazzler.c does need to do DMA memory access from what I can tell as the real board doesn't have its own memory)
This makes me think there is another kind of "internal" memory access that these modules require that memory.c currently doesn't provide.
I have a working solution for this where I have created two new "internal" memory access functions I have named peek() and poke() for sentimental reasons.

Before I post a Pull-Request I am interested to get your feedback whether you agree with my thinking and my outlined solution.

List new/added functionality, todo's, feature requests, work underway, etc... as new Issues

In your first response to Issue #18, you mention:

 I'm willing to change my priority list and start working on this with you now, it has to be done anyway, but then other things have to wait...

Can I suggest we all add any ideas for new/added functionality, todo's, feature requests, work underway, etc... as new Issues and label them accordingly. With visibility of what's on peoples' lists/minds then others might decide to contribute to solving some or making additional suggestions.

Implement the Cromemco 88-CCC Cyclops Camera Controller

Reproductions of the worlds first digital camera, the Cromemco Cyclops 88-ACC have been shown at recent VCF events in the US.
The Wikipedia page for the Cyclops has links to the manuals for both the camera and the controller at the bottom of the page https://en.m.wikipedia.org/wiki/Cromemco_Cyclops

I have already done a proof-of-concept to use a standard web-camera and process the video to produce the same bit-stream as the Cyclops. This happens in the browser and so will be usable with the webfrontend (see #38).

The interface controller needs to be implemented as a new iodevice so the bit-stream can be read by a simulator machine. Then the example code in the 88-CCC manual can be used to display the image on the Dazzler.

It would even be possible to implement the interface controller to work with a physical Cyclops camera using a cheap micro controller board to convert the Cyclops data to serial (probably via USB).

No mutex initialisation for data_sample_lock in lp_main.cpp

In the frontpanel module lp_main.cpp there are 2 mutexes defined:

//static pthread_mutex_t data_lock;
pthread_mutex_t data_lock;
pthread_mutex_t data_sample_lock;

however, only the first one is ever initialised in start_threads()

pthread_mutex_init(&data_lock,NULL);

So every call to lock and unlock this mutex fails, although this does not appear to effect the operation of the frontpanel library. So there are 2 alternatives:

1. initialise the second mutex in start_threads()

pthread_mutex_init(&data_lock,NULL);
pthread_mutex_init(&data_sample_lock,NULL);

or

2. remove the references in lp_main.cpp and lpanel.cpp to:

pthread_mutex_lock(&data_sample_lock);
...
pthread_mutex_unlock(&data_sample_lock);

There is a proposed fix in Pull-Request #6

Implement the uPF-1

Priority: low
Difficulty: pretty difficult

I still have mine, I doesn't take much place in the bookshelf, so unlike the 'boot anchors' I did not get rid of it. I also have the manual in PDF, firmware source etc. etc. I also could take pictures from my machine for creating the frontpanel with, so that there are no license/ownership issues.
In fact the uPF-1 monitor source was the reason for Didier's expression parser in z80asm ;-)

So if anyone wants to take the challenge just say what you need, and I'll see what I can do to help.

Implement a disk manager for use by floppy disk controller modules

Available now in PR #47.
Ready to work with

• imsai-fif.h (integarted in the PR)
• tarbell_fdc.h (should be very easy to integrate)

Some work is required to support more complex disk arrays that contatin structures e.g.

• cpmsim::iosim.c
• cromemco-fdc.c

Implement a DMA controller to support MOVE and XMOVE operations in CP/M 3 BIOS

I've looked at the Zilog 8410, popular in the period but unable to address banked memory or more then 64K of linear memory. The design and use of the I/O registers is also more complex than required for this task.

I propose using using memcpy() on the host side to perform the data transfer, and setup the DMA request via a series of I/O ports from the guest side, or possibly sequential writes to the same port to save I/O address space on the guest.

This would enable CP/M 3 to use more banks for buffers, give up a little more memory to the TPA space, and run a little faster.

RETI

The Z80 manual says RETI doesn't affect IFF but as far as I can see it does and this matches 'The Undocumented Z80 Section 5.3'

Fix frontpanels to jam instructions instead of doing a DMA read

Priority: high
Difficulty: medium

Make this working like the original circuits, after that #18 can be fixed.

Redundant frontpanel updates being made in `sim1.c` and `sim1a.c`

There are some redundant frontpanel updates being made in sim1.c and sim1a.c
that have a performance impact on systems with low-powered CPUs or microcontrollers. In both files, a call to memrdr(PC++) follows that will perform the required frontpanel update with the desired values.

There is a proposed fix in Pull-Request #6

Fuzix MMU traps

I find these useful for debugging Fuzix stuff.

This changes the wp_common I/O port behaviour a little so that bit 7 is set on a trap (cleared by writing the register again), and if bit 6 is set we also NMI.

Recovering from the NMI or dropping into a Z80 monitor is a shade interesting because we may have faulted trying to push stuff so have no valid return frame - but it's still useful 99% of the time.
mem.txt

Enable headless imsaisim mode ie. runs with no CP-A attached

Priority: low
Difficulty: easy

Might need some way to power-cycle and reset

Add macros to z80asm

Priority: low because one always can run some UNIX macro processor as front end
Difficulty: medium - difficult

Carfully study the modularity of this assembler. Have a look how the expression parser was replaced with a totally different one without any changes to other parts of the thing.
Implement a macro processor the same way, so that it can be substituted by another one
without modifying other parts. There have been quite some different macro implementations and eveyone prefers another one. To name a few:

Macro implementation by Digital Research in MAC/RMAC
Macro implementation by Microsoft in M80
Mostek had a very powerfull Macro processor in their UNIX cross assembler
Of course feel free to implement your own macro language.

Contributions will only be accepted if the macro processor can be substituted without
to much changes in the other components.

+++ for implementing two versions that can be selected with a command line option.

Make the VIO plug-any-play in the imsaisim

Priority: low
Difficulty: moderate, order of events doesn't favour this, ie. memory is initialised before ROM file is loaded so how does the VIO ROM get identified?

The CP/M BIOS already looks for the 'VIO' string in ROM to enable the VIO as the con: device.
The imsaisim could reserve and initialise RAM/ROM for the VIO only if the VIO ROM has been loaded.
This would release those extra few KBs for CP/M.

Altair system: Tarbell on-board boot ROM not working

Due to the latest changes, need to use the external boot ROM for now.

Remove imsai_vio_ctrl() from imsaisim memwrt() and let the VIO refresh loop handle this

Priority: medium
Difficulty: easy

For efficiency and better separation-of-concerns, the code in the imsaisim memory.c/h module memwrt() shouldn't have to perform

	if (addr == 0xf7ff)
		imsai_vio_ctrl(data);

This is getting done on every memory write just to check 1 byte, effecting performance.
This check could be moved to the imsai-vio.c module where a double-buffer could be used with any change noticed and acted on in the refresh loop.

Port to ESP32 micro-controller with TTY: over USB or RS232 serial, all other IO over WiFi

Priority: high
Difficulty: difficult, been working on it for almost a year now, but its about 95% ready to go.

I have ported z80pack V1.36, specifically the imsaisim machine, to the ESP32 micro-controller.
https://www.espressif.com/en/products/hardware/development-boards
A device that retails for around USD$20 - I have specifically used the ESP32-PICO-KIT

These devices have a dual-core CPU @ 240MHz, 520KB SRAM, 4MB Flash RAM (storage) and builtin WiFi, USB connector for serial UART and programming.

To this I have added

• microSD Card for a FAT filesystem (using a 2GB card)
• 4 green + 4 red LEDs for POST and Disk activity lights
• MAX232 style RS-232 driver and DB-9M socket for serial UART
• Full size, fully functional replica of the IMSAI CP-A front panel with all LEDs and switches (see attached image, for scale: the green mat behind is A3)
  

Sometimes I use the USB based serial UART for TTY: but most of the time I connect over WiFi using a browser to launch the desktop GUI that this port of the imsaisim can serve using an embedded web server (see #38 for more details and screen shots).

Running with '-f0' for unlimited speed I can get a simulated 4.905 MHz. This has been steadily climbing as I optimise the code. Under conditions I can't currently reproduce I have recorded a benchmark of 5.481 MHz, but there is certainly no problem with reliably running the simulation at a realistic 2MHz or 4MHz making WordStar, SuperCalc2, M80/L80 a pleasure to use.

Bug found in memory.h::memrdr(), bank switch is too early.

This problem was only apparent when using a ram_size of < 56K.
Fixed in PR #41.

Improve IMSAI FIF FDC

Priority: low
Difficulty: medium

The manual for the FDC is available now:

https://wiki.theretrowagon.com/wiki/Imsai_8080#Purchased_from_Herb_August_2018

Interesting read and helps to improve the FDC emulation and make it more accurate than what I was able to figure out with reverse engineering. From a first glance over the manuals I didn't see the need for urgent changes, so low priority and can be done sometime as time permits.

CPU utilisation is high because CP/M busy-waits on serial I/O (IMSAI)

I've noticed that CPU utilisation is high even when the simulator is doing nothing but waiting on keyboard input (in running state) so I thought I'd investigate.
On OSX running on an i7 its almost 50% , and on Debian on an Intel Atom its 100%, and that is when running the IMSAI machine simulation at only 2MHz.
The cause appears to be triggered by the fact that CP/M busy-waits on serial I/O, and the single biggest user of this time is the poll() function call in imsai-sio2.c
The poll() seems to be an "expensive" function with respect to CPU utilisation. And it gets called twice for each character.
This high CPU utilisation isn't good for battery consumption on any of my laptops (i7 MacBook Pro, or Intel Atom Asus Netbook).
I have a proposed solution that I have been using successfully that I will post as a Pull-Request.

CB 37 should not be counted as Z80_UNDOC

Zilog's Z280 manual explicitly says to use

ld a,#0x40
.byte CB,37
jp p, z280_cpu

to tell Z80 and Z280 apart. So it's documented undocumented, and it breaks those (rare) bits of software that try and detect a Z280 processor

See Zilog Z280tm MPU MIcroprocessors Unit Preliminary Technical Manual: Appendix A

tu-art hangs on a polled transmit when a timer is pending

In the case that a timer is pending but the system is sitting in a polling interrupt disabled loop doing output the system wrongly deadlocks because the emulation keeps the transmit buffer clear bit clear until the timer has cleared.

Add MITS 88-SIO Rev. 1 to IMSAI machine

Priority: medium
Difficulty: easy

IMSAI didn't use I/O ports 0/1 so a MITS SIO can be plugged into the system. This allows to run the MITS BASIC interpreters also on the IMSAI machine, was done by original owners way back then too.

Don't know if it creates problems with the ESP port or a Web frontend, because 2 different SIO's are connected to one terminal. Might need conditional compiling for excluding it.

Implement write-protect for IMSAI memory boards

Priority: low
Difficulty: easy

The standalone BASIC interpreter write protects it's memory, so it can't be poked to death.
Just set the 1KB pages in the page table to MEM_WPROT from the output to the port.
See BASIC source and manual for refernce.

Implement a unified (single) GNUmakefile for each simulation (machine)

Motivation

• I have felt sorry about all the Makefile.* modifications my new code has caused
• I want to learn more about make as I have only used it very simply in the past

Goals:

• have a single Makefile that works for all platforms for a given simulation eg. imsaisim
• localise the OS specific variations into a single place
• not have to symlink from ../../z80sim/simsrc
• not have to use #include "../../something/more.h" to reference header files in the source
• allow make install to well defined paths
• have best-practice file dependancy (there are some errors here and there at the moment)
• make it very simple to list the source files that are required to build a given machine

feel free to make other suggestions...

Implement the MITS 88-DCDD floppy disk controller

Working on it.