z80pack 1.38 release

[udo-munk]

There have been so many improvements and additions since the 1.37 release, I really would like to create the 1.38 final release from the development branch in the near future. If you still need to get anything into 1.38-dev please discuss here, so that I get an idea when I can start preparing the release, thanks.

[sneakywumpus]

I opened PR #199 to clean up load_file().

[udo-munk]

I also get an email for an opened PR.

[sneakywumpus]

I'm adding a macro table to the list file.

[sneakywumpus]

Just some questions:
Was it intentional that the following files use 16 bytes per line?
I use a little script to check that I didn't break the assembler that assembles all .asm files and compares the .hex and .lis output.
Do you use the same -e option for all .asm files?

altairsim/roms/turnmon.hex
imsaisim/life.hex
imsaisim/microchess.hex
imsaisim/scs1.hex

[udo-munk]

No it was not intentional, I used 16 bytes per line to compare with the old version and for some I forgot to assemble again with the default. I'll replace these files.

[sneakywumpus]

I have locally changed the macro code to not convert to upper case. This looks much nicer in the listing,
but causes a problem for the XYBASIC code. It has a macro "error" with creates character constants from
parameters that are not character constants. This causes a divergence from the code produced by MAC
(which convert everything to upper case). The programmers seem to have thought about this, since in the
70 uses of this macro only 4 calls have lower case parameters. What to do? Change the 4 lines in XYBASIC,
or keep the conversion the upper case in the macro code?

[sneakywumpus]

The macro code shouldn't convert to upper case, since this makes it impossible to use lower case with macros.
We could add a flag to the assembler to force conversion to upper case.

[sneakywumpus]

The only character case specific thing in the assembler before the introduction of macros was
that symbols are case insensitive and are listed as upper case in the symbol table.
Lets keep it that way. So, introduce a flag for upper conversion or change the affected assembler
source code?

[udo-munk]

I would leave the source code as is, because the way it is it can be build on CP/M and ISIS systems. Would be better to have assembler options for the wanted behaviour.

[sneakywumpus]

This wouldn't change the possibility to build on CP/M or ISIS systems.
These are the changes that would be needed:

diff ./bendix ../bendix
117c117
< 	error	f,d,k		;issue fatal DK error
---
> 	error	f,D,K		;issue fatal DK error
diff ./eval ../eval
620c620
< 	error	n, o, v		;else nonfatal OV error
---
> 	error	n, O, V		;else nonfatal OV error
diff ./fp9511 ../fp9511
228c228
< fover:	error	n, o, v		;issue nonfatal OV error
---
> fover:	error	n, O, V		;issue nonfatal OV error
diff ./packard ../packard
84c84
< 	error	f, f, i		;and issue fatal FI error
---
> 	error	f, F, I		;and issue fatal FI error

All other uses of error already use upper case for the 2nd and 3rd parameter.
The files bendix and packard aren't used for the CP/M, Altair and Imsai builds,
I included these just for completeness.

[udo-munk]

OK, these modules were customizations for special customer machines used as health monitor, no one would build theses versions anymore, so not really essential.

[ratboy666]

I always thought that the macro (and label, etc) lookup were not case sensitive... but, case was to be retained in 'quoted' strings. Anywhere else, a conversion to upper could be expected. The only problem is in the IRPC macro. So, let us run some code through M80: .8080 0000' aseg org 100h irpc c,abcABCxyz db '&c' endm 0100 61 + db 'a' 0101 62 + db 'b' 0102 63 + db 'c' 0103 41 + db 'A' 0104 42 + db 'B' 0105 43 + db 'C' 0106 78 + db 'x' 0107 79 + db 'y' 0108 7A + db 'z' end And here we see that the string is NOT upper-cased, but taken as is. Now, if db '&c' is replaced by db &c we see that db a is the SAME as db A -- which is to say 07 (the value of A as a register operand). That compare is done case insensitive -- so, delay the compare until the actual symbol table lookup, but store in mixed case (for IRPC expansion). Note... as far as I remember, this was also the Intel Assembler behaviour, but it has been a long time... For macros, we should strive to be as consistent as possible! One case-fold too many... and there may be a macro that cannot be expressed! But... in this case, not that A evals to 7, and to force that down one macro expansion, use %A, which is replaced with 7 -- her is the example: mymac macro p   db '&p' endm mymac %A which results in: db '7' because... %A replaces %A with 7, which is then passed to mymac... This can be a life-saver in macros, because x set x+1 then macrocall %x passes the value of X, not the symbol. Thus allowing us to implement stacks, and data structures in macro. But... this also implies that symbol and SYMBOL should be the same. Except... for IRPC (as seen above). Note also that '&param' in the macro needs to recover the case of each of the characters. The macro code itself should, in general, not convert to upper case -- can you give me that actual problematic macro for XYBASIC? Thanks, Fred Weigel

…

On Mon, 2022-10-31 at 08:36 -0700, sneakywumpus wrote: I have locally changed the macro code to not convert to upper case. This looks much nicer in the listing, but causes a problem for the XYBASIC code. It has a macro "error" with creates character constants from parameters that are not character constants. This causes a divergence from the code produced by MAC (which convert everything to upper case). The programmers seem to have thought about this, since in the 70 uses of this macro only 4 calls have lower case parameters. What to do? Change the 4 lines in XYBASIC, or keep the conversion the upper case in the macro code? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: <udo-munk/z80pack/repo- ***@***.***>

[sneakywumpus]

error   macro   typ, m1, m2
        call    erro&TYP
        db      '&M1', '&M2' or 80H
        endm

Normally this would be called with, for example, error n, O, V but in a few places they put error n, o, v,
so you get lower case character constants when the assembler is not converting to upper case like DRI MAC.

[sneakywumpus]

I think the assembler is in a release candidate state now.
If anyone else is listening: please test the assembler from the "dev" branch,
especially the new macro functions and expression parser.

[sneakywumpus]

Now I'm really running out of ideas of what can be done to the assembler.
Only testing remains.

[sneakywumpus]

I was thinking about moving the common stuff from sim.h into z80core as simcore.h and replace it with an #include "simcore.h" at the end of each sim.h.

[udo-munk]

As long as you don't move anything in the user definable section that is ok. There should be only one file where the user customizes a machine to their needs.

[sneakywumpus]

Should BUS_8080 be configurable or solely depend on FRONTPANEL?

[udo-munk]

Doesn't need to be configurable, the CPU bus signals are provided for FRONTPANEL only.

[sneakywumpus]

Is there a particular reason why the Makefile's specify gcc and g++ as the compiler?
Wouldn't be better to just leave CC and CXX at their system default values, as the civetweb Makefile does?
So that one doesn't need, for example, have to explicitly type "make CC=cc" in cpmsim/srctools on FreeBSD.

[sneakywumpus]

I mean nowadays on every *nix like system "cc" is either gcc or clang.
I think the gcc usage comes from the 80s/90s when vendor compilers didn't cut it or cost extra and
nearly everyone installed gcc on their systems.

[udo-munk]

Yes, might be better to leave CC and CCX at the system defaults, one can override it with make CC=whatever anyway.

[sneakywumpus]

While building z80pack on FreeBSD I discovered that there is a package for z80pack. This package is in
conflict with another package that includes hex2bin and bin2hex utilities, so I'm thinking about renaming
bin2hex to cpmb2h and ptp2bin to cpmp2b to avoid any possible conflicts.

[udo-munk]

Not really great names, hasn't to do with CP/M, these are generic format conversion programs.

[sneakywumpus]

Do you have any suggestions, or just leave it as it is?

[udo-munk]

Just leave as is.

[sneakywumpus]

I'm done with the assembler, and the simulators now compile cleanly and run on FreeBSD,
so I won't hinder your release process anymore :-)

[udo-munk]

You didn't hinder anything, that all were good improvements. I'll give the current dev sources another week to see if any problems come up, and if not I'll prepare the release version.

[sneakywumpus]

I made some changes to the z80pack homepage to fix internal link rot.
The attached file contains a patch and the new index.html produced by applying it to the current version.

index.tar.gz

[udo-munk]

Thank you, just checked and uploaded to web site.

[udo-munk]

Are we ready for release or is something in the queue that should go into it?

[sneakywumpus]

I'm currently working on making the entire project follow a common coding style.
Especially the code by David McNaughton and Fred Weigel uses a different style.
I don't know what they will be saying if I mess with their code...

And the frontpanel library code is really unreadable. Is this still being maintained upstream?
The only thing I can find is an old site at https://sourceforge.net/projects/frontpanel which
has code from 2008 and some Windows patches in the Bugs section from 2015.

I will not touch civetweb, since this is an active upstream project.

I've settled on using astyle (https://astyle.sourceforge.net) for the formatting, since I can't get
clang-format to not mess up the all the nicely aligned end of line comments.

None of these tools is perfect, but they are very useful for an initial clean-up.

This is the .astylerc file I'm using:

style=kr
lineend=linux
indent=force-tab=8

keep-one-line-blocks
attach-closing-while
indent-preproc-define
min-conditional-indent=3
pad-comma
pad-header
unpad-brackets
squeeze-lines=1
align-pointer=name
attach-return-type
attach-return-type-decl
max-code-length=80

# don't use these for automatic formatting
# since they remove the space in "(int) 4"
# and change "(BYTE) *s" to "(BYTE) * s"
pad-oper
unpad-paren

Or should I stop this relatively massive and possibly disruptive undertaking?

[udo-munk]

So far I have avoided to mess to much with the formatting of others for some reasons.

Others might like the formatting they are using better and they migth want to support or at last read their code. More problematic is, if it is some library like frontpanel or the AMD MPU, these are used in multiple emulation projects. If owners of A come with one formatting, and then B come with another, what should the owner of the code do?

Probably you should contact them first and ask about this.

However, I'm fine with waiting for your clean ups, then this is through in the next release and verything neater.

[udo-munk]

No, this are relicts from using plain old UNIX System V makefiles, can go.

[sneakywumpus]

I'd like to rename memory.[hc] to memsim.[hc] (like iosim) to get rid of the conflict with <memory.h> and -iquote .

[sneakywumpus]

Or perhaps simio.[hc] & simmem.[hc] like simctl.c

[udo-munk]

Fine with me, this are just names I used when it was implemented, more logical names will help others.

[sneakywumpus]

In my quest to make z80pack installable I'm intending to make FRONTPANEL runtime opt-out and HAS_NETSERVER runtime opt-in, i.e. an option '-F' to disable the front panel and '-p ' to disable the front panel and start a net server at port .

Leaving out FRONTPANEL and HAS_NETSERVER from sim.h would still completely exclude the corresponding code.

Opinions?

[udo-munk]

The web server won't see disk drives, if diskmannager is not included, this was necessary to change disks in the web frontend. Without usage is optional, machine can be used with or without. What works is if disk manger always is used, so I think this is OK, there is no good reason to not use it.

[sneakywumpus]

In imsai-fif.c the large drive I is only supported without HAS_DISKMANAGER

[udo-munk]

OK, then there was a reason :-(
The problem is, floppy disks can be changed anytime by the user, a hard disk of course not, this is a fixed device. Dave has provisions for this in his ESP32 machines, but I don't know what. We need to make the hard disk somehow available without going through diskmannager.

[udo-munk]

Same problem likely with the Z1, even has 3 hard disks.

[udo-munk]

No problems with the Z1, has separate FD and HD controllers, each handling their drives.

[udo-munk]

Looked through the code for IMSAI, can easily be fixed. Harddisk needs separate handling is not a floppy disk, so needs to go out of the disks[] array. Then all this #ifdef LARGEDISK can go, no one wants a system without a hard disk. Also all this #ifdef HAS_DISKMANAGER can go, we always use it.

[udo-munk]

Just testing, after the latest changes I cannot access disks/drivei.dsk on the IMSAI anymore at all:

A>dir i:
Bdos Err On I: Bad Sector

[udo-munk]

Forgot to make newest bits, still was running the old code with HD disabled because diskmanager, looks fine now.

[udo-munk]

Copyright and history entry in imsai-fif.[ch] need update.

[sneakywumpus]

The 8080/Z80-core source code is starting to look messy (yours truly ducks into a corner...), and I'm inclined to, as you suggested, implemented a second selectable set of cores more optimized for size/speed and clean-up the original ones with only the UNDOC_*/FAST_BLOCK options remaining.

[udo-munk]

No problem, you see what I meant. Completely separated cores would be better, then one can have a readable and easy to understand/debuggable one, while others can be more advanced or optimized for some special purpose.

[sneakywumpus]

Or should we even remove the UNDOC_FLAGS and UNDOC_IALL options from the original core to leave this as a by the book implementation?

[sneakywumpus]

As it was, before I came along...

[udo-munk]

Implementing the undocumented flags is completely useless. All one can do is PUSH AF and then look at the bits, of course there are no instructions that can branch on them, or anything. The only effect it has is a huge pile of useless code consuming memory and time, to make one instruction exerciser happy. Way back then I also had the discussion with Frank Cringle, who did understand my point and agreed to make the test of the undocumented flag bits an option and not a must. Not needed, not useful, can go if you ask me. Maybe wait a while to hear other opinions.

[sneakywumpus]

I was wondering a bit why you did accept my push request with this stuff, we already had this discussions before... But now that the code had passed all available tests and I had my "Erfolgserlebnis" it doesn't really have any practical use. I'll remove it. What about UNDOC_IALL instructions?

[udo-munk]

Because now you had your "Erfolgserlebnis" and know exactly why I implemented it as it was.

[udo-munk]

The undocumented instructions I had implemented were those really used by some old software, TDL mostly did this. I added one after another until there was no software anymore that would trap. So same here, instructions that never ever are used by anything waste memory and worse, time to keep them working correct.

[sneakywumpus]

Oops didn't read this before replying. Will also remove.

[udo-munk]

In cpmsim the measured runtime cannot be correct:

System halted
CPU ran 71 ms and executed 10862565 t-states
Clock frequency 151.73 MHz

I typed a few commands, and sure needed several seconds for that, I am not this fast ;-)

[udo-munk]

Ah, is corrected for the time the busy wait sleeped the CPU.

[udo-munk]

On the IMSAI:

System halted
CPU ran 4681 ms and executed 33731009 t-states
Clock frequency 7.20 MHz

This is not possible. Happens if one resets the CPU from front panel. Probably because reset_cpu() sets R to 0.