z80pack release 1.36

[Udo Munk]

is available at http://www.autometer.de/unix4fun/z80pack/ftp/

The included z80 cross-assember has a few bugs fixed related to labels
and sometimes wrong evaluation of expressions with operators with
same precedence. If you assembled something with version 1.7 you
might want to re-assemble with version 1.8 because of these bugs.

Also this version now prints date/time into the listing file, so that
it not only depends on filesystem timestamps to see, when something
was build.

Then the assembler has a new option -e<number> to set the symbol
length. The default is 8 as before, but some of you want to use long
labels, so there.

The Z80 core now includes more of the undocumented instructions
that were used by TDL, so that all and any of the recovered TDL
software can be used. The Altair emulation comes with the TDL
ZAPPLE monitor, which can be used to read in the old TDL tapes,
same as with CUTER and the old ProcTec tapes.

I also left my builds of Martin Eberhard's 8080 monitor in the Altair
and IMSAI emulation directories, which is another good standalone
monitor for such systems. Source and manual are here:
https://drive.google.com/drive/folders/0B-XdfCubTNJJNW54UWJJVnpKMlE

The SIO code using UNIX domain sockets is improved a bit, so that
tape I/O sessions with minicom work better. If you use netcat you
might be left with half closed sockets resulting in problems, but
that is how the sockets were designed, certainly not for what I'm
doing here ;-)

The Cromemco FDC emulation now is very accurate in details,
not necessary for running OS's on an emulated FDC. I did that
more for my self to see how exact I can get it, see sources and
evaluate the FDC with Martin Eberhard's flexer CDOS program.

The Altair emulation comes with the UCSD p-System disks I have
build for the system, great fun.

In cpmsim I also left a Fuzix distribution for you, even more fun.
For using it see http://fuzix.org

---

So, 30 years and 35 releases later I'm still working on it, the wish
list of cool stuff to do with this grows with every release, so I never
can finish it in this live.

Merry Christmas everyone, have fun with the new bits over the holidays,
Udo

[Bill Lewis]

Merry Christmas to you and everyone also!

And thank you for sharing your work on z80pack.

Bill

[gr...@sydneysmith.com]

On Friday, December 22, 2017 at 7:26:20 AM UTC+11, Udo Munk wrote:
>
> The included z80 cross-assember has a few bugs fixed related to labels
> and sometimes wrong evaluation of expressions with operators with

> same precedence. ...
>
> The Z80 core now includes more of the undocumented instructions ...

>
> The Cromemco FDC emulation now is very accurate in details,
> not necessary for running OS's on an emulated FDC. I did that
> more for my self to see how exact I can get it, see sources and
> evaluate the FDC with Martin Eberhard's flexer CDOS program.
>

Hi Udo,

I really like z80sim. It has given me the ability to revisit my very early days of computing. I have been surprised at how stuff that I haven't thought of for 40 years just pops back into mind in the right environment. Who'd have thought I'd still remember how to write in Z80!

It looks like most of the work in the update was around better matching undocumented instructions. A lot of work by the look of it.

I'm pleased that you've updated the assembler. I'd noticed the associativity was off and it looks like the changes in the new version address that. I've added extra brackets in code so it'll be nice to simplify those bits again.

I guess my main interest in the new version is the FDC changes. I really like the ReadOnly code. Adding (or removing depending on disk size) a write protect tab is obvious, in hindsight. It hadn't even occurred to me to make a disk image read-only in the host OS. I've just been copying masters in whenever I needed a clean start. It's a great idea though and I'm pretty sure that CDOS checks and reports this. (Not sure that CP/M would.)

With the changes to the index pulse, does this resolve the timing issue you were seeing with later versions of CDOS Init?

All the very best,
Greg (from http://www.sydneysmith.com)

[Udo Munk]

On Friday, January 5, 2018 at 11:17:54 PM UTC+1, gr...@sydneysmith.com wrote:

> I really like z80sim. It has given me the ability to revisit my very early days of computing.
> I have been surprised at how stuff that I haven't thought of for 40 years just pops back into
> mind in the right environment. Who'd have thought I'd still remember how to write in Z80!

I know what you mean, I'm wondering my self that I'm still pretty good at 8080/Z80
assembler stuff.

> It looks like most of the work in the update was around better matching undocumented
> instructions. A lot of work by the look of it.

Yes, this is the largest part of the changes. I implement the undocumented instructions
only for existing software, and TDL used a lot in their 12K BASIC.

> I'm pleased that you've updated the assembler. I'd noticed the associativity was off and
> it looks like the changes in the new version address that. I've added extra brackets in
> code so it'll be nice to simplify those bits again.

The problem can be avoid with extra brackets, which I use anyway. That's why the bugs
were unnoticed for a long time, I got aware about that while trying to get Zapple assembled.
So far no new bug was reported, so hopefully it's OK now.

> I guess my main interest in the new version is the FDC changes. I really like the ReadOnly code.
> Adding (or removing depending on disk size) a write protect tab is obvious, in hindsight. It hadn't
> even occurred to me to make a disk image read-only in the host OS. I've just been copying masters
> in whenever I needed a clean start. It's a great idea though and I'm pretty sure that CDOS checks and
> reports this. (Not sure that CP/M would.)

CP/M itself won't, it just reports a write error. It needs to be checked and reported in the BIOS,
but most BIOS's won't even look at the FDC status and instead report a write error back to
the BDOS. Way back I was using BIOS's that checked the status and set the disk R/O, then CP/M can
handle it correct too.
CDOS checks and reports it, yes.

> With the changes to the index pulse, does this resolve the timing issue you were seeing
> with later versions of CDOS Init?

Unfortunately not, but at least the index pulse now is emulated technically very accurate.
Somewhere they are using tight loops < 10ms, which the CPU runs way to fast and the
result generates an overflow error.

> All the very best,
> Greg (from http://www.sydneysmith.com)

Best regards,
Udo

[rwd...@gmail.com]

I find that frontpanel of cromemcosim absorbs all cpu on Pi Zero and 93% on Pi3, and cromemcosim doesn't get enough cpu to run through the boot process

Is there any way to tune frontpanel so that the switches are operable, but so that it isn't burning cpu on bulb/lamp updates?

Regards
Richard

[Udo Munk]

You can reduce the FPS, it is set to 60 which is fine for desktop/notebook systems.
A setting of 30 FPS looks OK too, lower settings might not look nice anymore, but
will reduce the CPU load. The FPS is set in the config files ./conf/system.conf with
the variable fp_fps.

[Richard Deane]

Thanks
Dropping to 2 on pi3 works, but emulator is very slow; on pi zero it is still soaking up all cpu. Roll on pi4 :)
richard

[Udo Munk]

On Sunday, January 14, 2018 at 10:49:08 PM UTC+1, Richard Deane wrote:

> Thanks
> Dropping to 2 on pi3 works, but emulator is very slow; on pi zero it is still soaking up all cpu.
> Roll on pi4 :)

Welcome. The OpenGL code for the front panel might be a bit to much for the tiny computers,
I don't have one, so never tried. At least the sources are very portable to also build for these
systems, and future versions might provide more powerful CPU/GPU.

[dott.Piergiorgio]

seems that people don't understand more the persistence on the retina.
Normal people has no more than 1/30 sec. of persistence, so 30 FPS IS
enough for the 90%+ of people.

there's enough flames on gaming forums on the framerate... personally,
24 (NTSC) and 30 (PAL) FPS is more than enough for emulators, for
obvious reasons.

OTOH, the emulation of Dazzler never flickered, so its framerate is
perfect, albeit I don't have tried to do demo-grade fooling around.

Very side note, I noticed that your emulation isn't noticed in the demo
community. because you're German, I guess that you should do something,
being guest at a demoparty is basically deserved free beer ;)

Best regards from Italy,
dott. Piergiorgio.

[Udo Munk]

On Monday, January 15, 2018 at 12:30:44 PM UTC+1, dott.Piergiorgio wrote:

> seems that people don't understand more the persistence on the retina.
> Normal people has no more than 1/30 sec. of persistence, so 30 FPS IS
> enough for the 90%+ of people.

It actually is 25 FPS, else CRT-TV and Cinema wouldn't have worked.
For the younger ones I can assure that both worked for me in the 60th ;-)

> there's enough flames on gaming forums on the framerate... personally,
> 24 (NTSC) and 30 (PAL) FPS is more than enough for emulators, for
> obvious reasons.

That is for the display FPS. For the front panel the brightness of a LED
is computed when a new frame is rendered. The algorith seems to
work better at 60 FPS, if you compare the emulation against videos of the
real machines. That's why the 60 FPS is default, which halfway decent
hardware can render without much load.

Or with other words, it is not the display update rate in engines,
it is the other stuff computed together with the next frame for the
display, that might no happen often enough at 25-30.

> OTOH, the emulation of Dazzler never flickered, so its framerate is
> perfect, albeit I don't have tried to do demo-grade fooling around.

It uses xlib double buffereing, that's why it is not flickering at any
refresh rate, same as the VIO and VDM video logic. I choosed 30 FPS
because that is what the original hardware had to use for US CRT's and
with this refresh rate even the decades old games and animations look
very realistic and run at correct speed.

> Very side note, I noticed that your emulation isn't noticed in the demo
> community. because you're German, I guess that you should do something,
> being guest at a demoparty is basically deserved free beer ;)

Yeah, well I don't really care ;-) Also I'm way to busy for visiting
these demo parties, I might do when I'm retired and bored enough.

[Udo Munk]

I have not found bugs in 1.36, nor did I receive bug reports, seems to be good
this release. I've put it on GitHub:

https://github.com/udo-munk/z80pack

I have added a branch 'dev' with stuff under development good enough
for reviews/testing, that will definitely get into the next release.
So you can try out new upcoming stuff, add feature or your own machines,
whatever.

Enjoy,
Udo