info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
z80pack features discussion
240 views
Skip to first unread message
Udo Munk
Jan 5, 2015, 4:27:00 PM1/5/15
to
Apologies guys, as you probably too I hate it when I have to dig through tons
of stuff totally off topic while doing research. So I'll answer your questions in
this thread with appropriate topic.
On 1/3/15 1:55 PM, dottor Piergiorgio M. d' Errico wrote:
> or better, enlarged virtual frontpanel (I don't have teutonic precision
> on mouse handling ;)
And after I enlarged it the next one says: oh no this is too large, make it smaller.
Won't work, size stays, is working for me on my equipment. But fortunately you
can adjust all and everything your self. John created a simple language that
describes the front panel graphics objects, so that they can be adjusted. Not
only that, he also gave as a well written user guide, you'll find in the z80pack
doc directory.
The relevant section is this:
The following object could be used to create the background for a dark gray 19-inch by 5.25-inch panel.
object front_panel color 0.3 0.3 0.3 polygon
v 0. 0.
v 19 0
v 19 5.25 v 0 5.25
Realism
- begins an object called "front_panel" - defines a color
- begins the definition of a polygon
- vertex at x=0 y=0
- vertex at x=19.0 y=5.25
- vertex at x=19.0 y=5.25
- vertex at x=0 y=5.25
You'll find this for each fp machine in file conf/panel.conf. The coordinates define
the square that builds the front panel window and you can change the sizes here
to whatever you want. I would suggest to read the whole manual chapter, because
there are some other statements, that help you to scale the graphics, so that the
ratio won't get all wrong and such.
Also you could create copies of the conf directory and make configurations for
small, medium and large size, and use conf as link to the directory with the
configuration you want, same as I did that with the link to either 2D or 3D model.
Then write some shell scripts like emu_small and emu_large, which set the link
before starting the emulation.
of stuff totally off topic while doing research. So I'll answer your questions in
this thread with appropriate topic.
On 1/3/15 1:55 PM, dottor Piergiorgio M. d' Errico wrote:
> or better, enlarged virtual frontpanel (I don't have teutonic precision
> on mouse handling ;)
And after I enlarged it the next one says: oh no this is too large, make it smaller.
Won't work, size stays, is working for me on my equipment. But fortunately you
can adjust all and everything your self. John created a simple language that
describes the front panel graphics objects, so that they can be adjusted. Not
only that, he also gave as a well written user guide, you'll find in the z80pack
doc directory.
The relevant section is this:
The following object could be used to create the background for a dark gray 19-inch by 5.25-inch panel.
object front_panel color 0.3 0.3 0.3 polygon
v 0. 0.
v 19 0
v 19 5.25 v 0 5.25
Realism
- begins an object called "front_panel" - defines a color
- begins the definition of a polygon
- vertex at x=0 y=0
- vertex at x=19.0 y=5.25
- vertex at x=19.0 y=5.25
- vertex at x=0 y=5.25
You'll find this for each fp machine in file conf/panel.conf. The coordinates define
the square that builds the front panel window and you can change the sizes here
to whatever you want. I would suggest to read the whole manual chapter, because
there are some other statements, that help you to scale the graphics, so that the
ratio won't get all wrong and such.
Also you could create copies of the conf directory and make configurations for
small, medium and large size, and use conf as link to the directory with the
configuration you want, same as I did that with the link to either 2D or 3D model.
Then write some shell scripts like emu_small and emu_large, which set the link
before starting the emulation.
Udo Munk
Jan 5, 2015, 4:45:31 PM1/5/15
to
On Monday, January 5, 2015 2:10:36 PM UTC+1, dottor Piergiorgio M. d' Errico wrote:
> on-the-fly tiny/small programs); cpmsim ought to have his version of
> Schorn's READ.COM/WRITE.COM, and this is perhaps more useful than having
> throttle control...
This will never be included in z80pack, if you want this you have to do it your self.
The reason are the immense security risks, that cannot be managed. One nice
feature of the virtual machine is, that a malicious program in worst cases can
crash the machine or destroy a disk image. Otherwise it is running in a sandbox
without access to the host.
With access to the hosts filesystem a simple CP/M program can create great damage.
Here one of the usual example hacks. Everyone often misspells a command like
emasc instead of emacs. Now I write a file named emasc into the hosts filesystem
and make it executable. Guess what will happen the next time you'll misspell it.
That is why . by default is not in your PATH, and I don't ask who all has added it
nevertheless, because it is so convenient. And even if I could try to create the
thing under $HOME/bin from CP/M, maybe there are leaks that can be exploited.
So instead of asking for this simply do this:
Run to terminals, in one the emulation, the second cd'd to your file directory.
You can use cpmtools on disk active running in the emulation, it won't set file
locks. Reading files from the disk is no thing, after writing to the disk you need
to do a CNTL-C in the emulation, because you just changed the disk. You are
familiar with the procedure anyway.
Again, write shell script w and r that do something like "w d myfile.dat", which
would write myfile.dat to disks/drived.cpm with cpmcp.
> on-the-fly tiny/small programs); cpmsim ought to have his version of
> Schorn's READ.COM/WRITE.COM, and this is perhaps more useful than having
> throttle control...
This will never be included in z80pack, if you want this you have to do it your self.
The reason are the immense security risks, that cannot be managed. One nice
feature of the virtual machine is, that a malicious program in worst cases can
crash the machine or destroy a disk image. Otherwise it is running in a sandbox
without access to the host.
With access to the hosts filesystem a simple CP/M program can create great damage.
Here one of the usual example hacks. Everyone often misspells a command like
emasc instead of emacs. Now I write a file named emasc into the hosts filesystem
and make it executable. Guess what will happen the next time you'll misspell it.
That is why . by default is not in your PATH, and I don't ask who all has added it
nevertheless, because it is so convenient. And even if I could try to create the
thing under $HOME/bin from CP/M, maybe there are leaks that can be exploited.
So instead of asking for this simply do this:
Run to terminals, in one the emulation, the second cd'd to your file directory.
You can use cpmtools on disk active running in the emulation, it won't set file
locks. Reading files from the disk is no thing, after writing to the disk you need
to do a CNTL-C in the emulation, because you just changed the disk. You are
familiar with the procedure anyway.
Again, write shell script w and r that do something like "w d myfile.dat", which
would write myfile.dat to disks/drived.cpm with cpmcp.
Udo Munk
Jan 5, 2015, 4:53:44 PM1/5/15
to
On Monday, January 5, 2015 2:25:39 PM UTC+1, dottor Piergiorgio M. d' Errico wrote:
>
> A thing whose reduces portability... CP/M software heavily use control,
> so ^-* isn't an option, and where *nix, *bsd and macos disagree is their
> view of keypressing of control/alt/altgr/option...
>
> and, what mapping ? mnemonic or positional ? please... I have enough
> issues with VICE's keymap files..
Agreed, this keymap files often create even more problems than it helps.
If you find it difficult to operate the switches with the mouse then enlarge
the window by resizing it, or by configuration change. That will make it
easier to hit them switches.
> Il 05/01/2015 05:25, Egan Ford ha scritto:
> > On 1/3/15 1:55 PM, dottor Piergiorgio M. d' Errico wrote:
> >> or better, enlarged virtual frontpanel (I don't have teutonic precision
> >> on mouse handling ;)
> >
> > Keyboard support for the switches would be a nice-to-have as well.
> > On 1/3/15 1:55 PM, dottor Piergiorgio M. d' Errico wrote:
> >> or better, enlarged virtual frontpanel (I don't have teutonic precision
> >> on mouse handling ;)
> >
>
> A thing whose reduces portability... CP/M software heavily use control,
> so ^-* isn't an option, and where *nix, *bsd and macos disagree is their
> view of keypressing of control/alt/altgr/option...
>
> and, what mapping ? mnemonic or positional ? please... I have enough
> issues with VICE's keymap files..
Agreed, this keymap files often create even more problems than it helps.
If you find it difficult to operate the switches with the mouse then enlarge
the window by resizing it, or by configuration change. That will make it
easier to hit them switches.
dottor Piergiorgio M. d' Errico
Jan 6, 2015, 4:36:29 AM1/6/15
to
Il 05/01/2015 22:45, Udo Munk ha scritto:
> On Monday, January 5, 2015 2:10:36 PM UTC+1, dottor Piergiorgio M. d' Errico wrote:
>
>> on-the-fly tiny/small programs); cpmsim ought to have his version of
>> Schorn's READ.COM/WRITE.COM, and this is perhaps more useful than having
>> throttle control...
>
> This will never be included in z80pack, if you want this you have to do it your self.
> The reason are the immense security risks, that cannot be managed. One nice
> feature of the virtual machine is, that a malicious program in worst cases can
> crash the machine or destroy a disk image. Otherwise it is running in a sandbox
> without access to the host.
if one can explain how to camouflage x86/x86-64 binaries as 8080/z80
> On Monday, January 5, 2015 2:10:36 PM UTC+1, dottor Piergiorgio M. d' Errico wrote:
>
>> on-the-fly tiny/small programs); cpmsim ought to have his version of
>> Schorn's READ.COM/WRITE.COM, and this is perhaps more useful than having
>> throttle control...
>
> This will never be included in z80pack, if you want this you have to do it your self.
> The reason are the immense security risks, that cannot be managed. One nice
> feature of the virtual machine is, that a malicious program in worst cases can
> crash the machine or destroy a disk image. Otherwise it is running in a sandbox
> without access to the host.
binaries...
I surely will be very careful in handling dosbox & dosemu, but generally
the entire reason dì etre of emulators (re. virtual machines) is that
the binaries are mutually incompatible...
> With access to the hosts filesystem a simple CP/M program can create great damage.
> Here one of the usual example hacks. Everyone often misspells a command like
> emasc instead of emacs. Now I write a file named emasc into the hosts filesystem
> and make it executable. Guess what will happen the next time you'll misspell it.
> That is why . by default is not in your PATH, and I don't ask who all has added it
> nevertheless, because it is so convenient. And even if I could try to create the
> thing under $HOME/bin from CP/M, maybe there are leaks that can be exploited.
>
> So instead of asking for this simply do this:
>
> Run to terminals, in one the emulation, the second cd'd to your file directory.
> You can use cpmtools on disk active running in the emulation, it won't set file
> locks. Reading files from the disk is no thing, after writing to the disk you need
> to do a CNTL-C in the emulation, because you just changed the disk. You are
> familiar with the procedure anyway.
list of cpmtools's disk definitions:
> diskdef ibm-3740
> diskdef 4mb-hd
> diskdef pcw
> diskdef pc1.2m
> diskdef cpm86-144feat
> diskdef cpm86-720
> diskdef cf2dd
> diskdef alpha
> diskdef apple-do
> diskdef apple-po
> diskdef myz80
> diskdef cpcsys
> diskdef cpcdata
> diskdef nigdos
> diskdef epsqx10
> diskdef ibm-8ss
> diskdef ibm-8ds
> diskdef electroglas
> diskdef ibmpc-514ss
> diskdef ibmpc-514ds
> diskdef p112
> diskdef p112-old
> diskdef gide-cfa
> diskdef gide-cfb
> diskdef attwp
> diskdef kpii
> diskdef kpiv
> diskdef interak
> diskdef fdd3000
> diskdef fdd3000_2
> diskdef 1715
> diskdef 17153
> diskdef scp624
> diskdef scp640
> diskdef scp780
> diskdef scp800
> diskdef z9001
> diskdef v1050
> diskdef microbee40
> diskdef dreamdisk40
> diskdef dreamdisk80
> diskdef rc759
> diskdef icl-comet-525ss
> diskdef z80pack-hd
> diskdef z80pack-hdb
> diskdef bw12
> diskdef bw14
> diskdef nsfd
> diskdef nshd4
> diskdef nshd8
> diskdef mdsad175
> diskdef mdsad350
> diskdef osborne1
> diskdef osborne4
> diskdef lobo2
> diskdef lobo3
> diskdef dec_pro
> diskdef tdos-ds
> diskdef pmc101
> diskdef td143ssdd8
> diskdef heassdd8
> diskdef mordsdd
> diskdef morsddd
> diskdef osb1sssd
> diskdef ampdsdd
> diskdef ampdsdd80
> diskdef altdsdd
> diskdef trsomsssd
> diskdef memotech-type03
> diskdef memotech-type07
> diskdef memotech-type43
> diskdef memotech-type47
> diskdef memotech-type4B
> diskdef memotech-type4F
> diskdef memotech-type18
> diskdef memotech-type19
> diskdef memotech-type1A
> diskdef memotech-type1B
> diskdef memotech-type1C
> diskdef memotech-type1D
> diskdef memotech-type1E
> diskdef memotech-type1F
> diskdef memotech-type50
> diskdef memotech-type51
> diskdef memotech-type51-italy
> diskdef memotech-type51-s2r64
> diskdef memotech-type51-s2r
> diskdef memotech-type52
> diskdef rm-sd
> diskdef rm-dd
> diskdef rm-qd
> diskdef amp1
> diskdef amp2
> diskdef amp3
> diskdef amp4
> diskdef amp5
> diskdef amp6
> diskdef ampro800
guess how many mispelling after -f is possible... all potentially
screwing a diskimage.
but it's your source code, and I don't push my disagreement into the
extreme consequences (a forking), so let's close this point with an
"agreement to disagree" :)
Best regards from Italy,
dott. Piergiorgio.
Udo Munk
Jan 6, 2015, 5:42:59 AM1/6/15
to
On Tuesday, January 6, 2015 10:36:29 AM UTC+1, dottor Piergiorgio M. d' Errico wrote:
> if one can explain how to camouflage x86/x86-64 binaries as 8080/z80
> binaries...
This is easy, for the 8080 the instructions c3 xx yy is a jump instruction,
> if one can explain how to camouflage x86/x86-64 binaries as 8080/z80
> binaries...
the usual start of a CP/M program. For the x86 this is not a jump
instruction, c3 is a return from call instruction, so a CP/M program
executed on DOS does nothing. By using the instructions sets in some
more creative way you can write a program that branches to label_a on a
8080, but branches to label_b on a x86. If I remember right even Intel
published an example how to do this.
But this is not necessary if I know that a CP/M emulation has an
interface to the hosts filesystem, that allows to write bytes into
a file there. So I can write a CP/M program that does what it promises
to do, but has an additional payload, that also writes another valid
x86 program via the interface to the host. One has to hope of course
that it will get executed sometimes by someone, but there are ways
for that ;-)
> I surely will be very careful in handling dosbox & dosemu, but generally
> the entire reason dì etre of emulators (re. virtual machines) is that
> the binaries are mutually incompatible...
> if your rationale is mispelling the filenames, let's give a look to the
> list of cpmtools's disk definitions:
>
> > diskdef ibm-3740
> guess how many mispelling after -f is possible... all potentially
> screwing a diskimage.
is fine with me, guess how often I have destroyed an images my self
with buggy code ;-) That is why we have backups of the images.
But with the possibility to destroy the hosts UNIX or Windows filesystem
from running a CP/M program in an emulation with leaks, a whole other
class of treats is created.
> but it's your source code, and I don't push my disagreement into the
> extreme consequences (a forking), so let's close this point with an
> "agreement to disagree" :)
implement it because of the implications with this. I am aware that
some of you want it, I have explained the implications. So please use
cpmtools to manage your disk images, because it won't have unwanted
side effects that are difficult to detect.
dottor Piergiorgio M. d' Errico
Jan 6, 2015, 7:03:41 AM1/6/15
to
Il 06/01/2015 11:42, Udo Munk ha scritto:
>> if your rationale is mispelling the filenames, let's give a look to the
>> list of cpmtools's disk definitions:
>>
>>> diskdef ibm-3740
> ...
>
>> guess how many mispelling after -f is possible... all potentially
>> screwing a diskimage.
>
> It was an example only, a well known one anyway. Destroying the images
> is fine with me, guess how often I have destroyed an images my self
> with buggy code ;-) That is why we have backups of the images.
>
> But with the possibility to destroy the hosts UNIX or Windows filesystem
> from running a CP/M program in an emulation with leaks, a whole other
> class of treats is created.
>
>> but it's your source code, and I don't push my disagreement into the
>> extreme consequences (a forking), so let's close this point with an
>> "agreement to disagree" :)
>
> No problem, this is a valid request for a feature, I don't want to
> implement it because of the implications with this. I am aware that
> some of you want it, I have explained the implications. So please use
> cpmtools to manage your disk images, because it won't have unwanted
> side effects that are difficult to detect.
Personally there's a good compromise, if you think on it: the main issue
>> if your rationale is mispelling the filenames, let's give a look to the
>> list of cpmtools's disk definitions:
>>
>>> diskdef ibm-3740
> ...
>
>> guess how many mispelling after -f is possible... all potentially
>> screwing a diskimage.
>
> It was an example only, a well known one anyway. Destroying the images
> is fine with me, guess how often I have destroyed an images my self
> with buggy code ;-) That is why we have backups of the images.
>
> But with the possibility to destroy the hosts UNIX or Windows filesystem
> from running a CP/M program in an emulation with leaks, a whole other
> class of treats is created.
>
>> but it's your source code, and I don't push my disagreement into the
>> extreme consequences (a forking), so let's close this point with an
>> "agreement to disagree" :)
>
> No problem, this is a valid request for a feature, I don't want to
> implement it because of the implications with this. I am aware that
> some of you want it, I have explained the implications. So please use
> cpmtools to manage your disk images, because it won't have unwanted
> side effects that are difficult to detect.
of your scheme lies in the care needed in giving the correct parameter
to -f to cpmcp/cpmrm, a thing easily solved with a 30-minute work with
shell script (personally, I use an even more easier system, a set of
bash aliases... but isn't a thing one can put in a makefile w/o security
concerns :P )
best regards from Italy,
dott. Piergiorgio
Steven Hirsch
Jan 6, 2015, 7:40:56 AM1/6/15
to
On 01/05/2015 04:45 PM, Udo Munk wrote:
> Run to terminals, in one the emulation, the second cd'd to your file directory.
> You can use cpmtools on disk active running in the emulation, it won't set file
> locks. Reading files from the disk is no thing, after writing to the disk you need
> to do a CNTL-C in the emulation, because you just changed the disk. You are
> familiar with the procedure anyway.
Hi, Udo. I've had problems copying files into an active z80pack session. In
> Run to terminals, in one the emulation, the second cd'd to your file directory.
> You can use cpmtools on disk active running in the emulation, it won't set file
> locks. Reading files from the disk is no thing, after writing to the disk you need
> to do a CNTL-C in the emulation, because you just changed the disk. You are
> familiar with the procedure anyway.
particular, the ALV for hard disk images does not get rebuilt with Ctl-C (this
is expected behavior for a CP/M hard disk). Even using the 'relog' command
with ZR/ZSDOS has been problematic and I've often ended up with corrupted
directories. My suggestion would be to only use floppy images in such a manner.
FYI: I have contributed updates to cpmtools that enable propagation of file
timestamps back and forth between a Linux host and the virtual disk. There
was always limited support for CP/M-3 timestamps, but I fleshed that out and
added Datestamper support (ZR/ZSDOS). I am not sure if Michael ever
officially released a version with these changes, but I've been using it here
for several years and found it helpful.
Steve
Udo Munk
Jan 6, 2015, 8:33:13 AM1/6/15
to
On Tuesday, January 6, 2015 1:03:41 PM UTC+1, dottor Piergiorgio M. d' Errico wrote:
> Personally there's a good compromise, if you think on it: the main issue
> of your scheme lies in the care needed in giving the correct parameter
> to -f to cpmcp/cpmrm, a thing easily solved with a 30-minute work with
> shell script (personally, I use an even more easier system, a set of
> bash aliases... but isn't a thing one can put in a makefile w/o security
> concerns :P )
Of course I can add shell scripts to the distribution that use cpmtools
> Personally there's a good compromise, if you think on it: the main issue
> of your scheme lies in the care needed in giving the correct parameter
> to -f to cpmcp/cpmrm, a thing easily solved with a 30-minute work with
> shell script (personally, I use an even more easier system, a set of
> bash aliases... but isn't a thing one can put in a makefile w/o security
> concerns :P )
but take care about the details for the user. Something like this:
cpmw [-t] d file - write file to CP/M disk drive d
cpmr [-t] d file - read file from CP/M disk drive d
-t would do the conversion for text file.
If you guys find this helpfull I'll be glad to add such scripts.
Udo Munk
Jan 6, 2015, 8:43:10 AM1/6/15
to
On Tuesday, January 6, 2015 1:40:56 PM UTC+1, Steven Hirsch wrote:
> Hi, Udo. I've had problems copying files into an active z80pack
> session. In particular, the ALV for hard disk images does not
> get rebuilt with Ctl-C (this is expected behavior for a CP/M
> hard disk). Even using the 'relog' command with ZR/ZSDOS has
> been problematic and I've often ended up with corrupted
> directories. My suggestion would be to only use floppy images
> in such a manner.
Thanks for correcting my Steve. This is because the allocation vectors
> Hi, Udo. I've had problems copying files into an active z80pack
> session. In particular, the ALV for hard disk images does not
> get rebuilt with Ctl-C (this is expected behavior for a CP/M
> hard disk). Even using the 'relog' command with ZR/ZSDOS has
> been problematic and I've often ended up with corrupted
> directories. My suggestion would be to only use floppy images
> in such a manner.
for harddisks are not used, well harddisk are not supposed to change
disks on the fly. Of course one can set them appropriate, for the
banked OS's that won't be a problem. For CP/M 2 one might lose one
page from the TPA for space needed for the ALV's, but that's not
too bad. Have to check this out...
> FYI: I have contributed updates to cpmtools that enable propagation
> of file timestamps back and forth between a Linux host and the virtual
> disk. There was always limited support for CP/M-3 timestamps, but I
> fleshed that out and added Datestamper support (ZR/ZSDOS). I am not
> sure if Michael ever officially released a version with these changes,
> but I've been using it here for several years and found it helpful.
preserve the timestamps between UNIX and UCSD filesystem and I found
it helpful. Probably you should contact Michael and ask about this.
Udo Munk
Jan 6, 2015, 9:24:13 AM1/6/15
to
On Tuesday, January 6, 2015 2:43:10 PM UTC+1, Udo Munk wrote:
...
...
...
ff2a 380 402 CHK00: DEFS 16 ;check vector 0
ff3a 381 403 CHK01: DEFS 16 ;check vector 1
ff4a 382 404 CHK02: DEFS 16 ;check vector 2
ff5a 383 405 CHK03: DEFS 16 ;check vector 3
ff6a 384 406 CHKHD1: DEFS 64 ;check vector harddisk 1
ffaa 385 407 CHKHD2: DEFS 64 ;check vector harddisk 2
386 408 ;
ffea 387 409 ENDDAT EQU $ ;end of data area
...
> banked OS's that won't be a problem. For CP/M 2 one might lose one
> page from the TPA for space needed for the ALV's, but that's not
> too bad. Have to check this out...
Even for CP/M 2 the HD ALV's would fit as is:
> page from the TPA for space needed for the ALV's, but that's not
> too bad. Have to check this out...
...
...
ff2a 380 402 CHK00: DEFS 16 ;check vector 0
ff3a 381 403 CHK01: DEFS 16 ;check vector 1
ff4a 382 404 CHK02: DEFS 16 ;check vector 2
ff5a 383 405 CHK03: DEFS 16 ;check vector 3
ff6a 384 406 CHKHD1: DEFS 64 ;check vector harddisk 1
ffaa 385 407 CHKHD2: DEFS 64 ;check vector harddisk 2
386 408 ;
ffea 387 409 ENDDAT EQU $ ;end of data area
Udo Munk
Jan 6, 2015, 9:41:01 AM1/6/15
to
HD check vector, that's why I didn't implemented them.
Egan Ford
Jan 6, 2015, 11:33:10 AM1/6/15
to
On 1/5/15 2:53 PM, Udo Munk wrote:
> Agreed, this keymap files often create even more problems than it helps.
> If you find it difficult to operate the switches with the mouse then enlarge
> the window by resizing it, or by configuration change. That will make it
> easier to hit them switches.
It's not difficult, but tedious. I wrote a game for the IMSAI that
> Agreed, this keymap files often create even more problems than it helps.
> If you find it difficult to operate the switches with the mouse then enlarge
> the window by resizing it, or by configuration change. That will make it
> easier to hit them switches.
assumes you have a printer, but all input must be done via switches.
Testing this with a mouse is just tedious. I looked into adding
keyboard support myself but ran out of time. I may just create a
standalone utility that will use XWarpPointer to move the mouse to the
switch and toggle it. This way I do not have to maintain a fork.
Udo Munk
Jan 6, 2015, 11:45:25 AM1/6/15
to
On Tuesday, January 6, 2015 5:26:11 PM UTC+1, Egan Ford wrote:
> Any that want to experience using switches may find that a bit easier if
> there was a 1:1 mapping of the switches to the keyboard when the Graphic
> UI is in focus. E.g. 1-8 for the first 8 switches, Q-I for the 2nd,
> etc... Pressing a key would just toggle the switch.
And here a problems begin already, in the 3D models U is used to
move the model Up in the windwo. Next row D is used for Down.
And some more, see manual.
> It's not difficult, but tedious. I wrote a game for the IMSAI that
> assumes you have a printer, but all input must be done via switches.
> Testing this with a mouse is just tedious. I looked into adding
> keyboard support myself but ran out of time. I may just create a
> standalone utility that will use XWarpPointer to move the mouse to the
> switch and toggle it. This way I do not have to maintain a fork.
I see. Well one needs to find some solution for that, like your
standalone, without breaking several fp features. Some of them are
needed if you want to create your own fp for some machine, like
switching the cursor on/off to read out the coordinates for exact
positionig of elements.
> Any that want to experience using switches may find that a bit easier if
> there was a 1:1 mapping of the switches to the keyboard when the Graphic
> UI is in focus. E.g. 1-8 for the first 8 switches, Q-I for the 2nd,
> etc... Pressing a key would just toggle the switch.
And here a problems begin already, in the 3D models U is used to
move the model Up in the windwo. Next row D is used for Down.
And some more, see manual.
> It's not difficult, but tedious. I wrote a game for the IMSAI that
> assumes you have a printer, but all input must be done via switches.
> Testing this with a mouse is just tedious. I looked into adding
> keyboard support myself but ran out of time. I may just create a
> standalone utility that will use XWarpPointer to move the mouse to the
> switch and toggle it. This way I do not have to maintain a fork.
standalone, without breaking several fp features. Some of them are
needed if you want to create your own fp for some machine, like
switching the cursor on/off to read out the coordinates for exact
positionig of elements.
dottor Piergiorgio M. d' Errico
Jan 6, 2015, 1:45:57 PM1/6/15
to
Steven Hirsch
Jan 7, 2015, 7:50:39 AM1/7/15
to
for one or both hard disks. I know it would help me :-). I always have to
remember to quit and restart z80pack when I copy in a new file.
The ZSDOS documentation appears to indicate that 'relog' rebuilds the ALV even
on hard disks, but that hasn't been my experience. At a minimum, you end up
picking up a stale timestamp for files that come in from outside. Since I use
a CP/M port of 'make' for a lot of my work, that's problematic.
Steve
Udo Munk
Jan 7, 2015, 9:08:43 AM1/7/15
to
vectors for both HD's active. I don't know yet if that works, I never
used such large changeable disk drives with a CP/M system. This needs
some testing.
For CP/M 3 and MP/M 2 I'll make the included BIOS's then using the check
verctors for all HD's, also the 512MB device. One won't loose size
from the TPA because I put the vectors into banked memory.
Stay tuned...
Udo Munk
Jan 7, 2015, 3:02:17 PM1/7/15
to
http://www.autometer.de/unix4fun/z80pack/ftp/tools/
You need to modify the path where you have installed z80pack-1.24, if it isn't in
your home directory. Then copy the scripts to ~/bin or /usr/local/bin and make
them executable with chmod 755 cpm[rw].
This are wrapper scripts for cpmstools, so cpmtools need to be installed of course.
Syntax is:
cpmr [-t] drive [user:]file
cpmw [-t] drive [user:]file
-t is optional, with this option text files will be converted, without it is a binary copy.
User number [user:] is optional, if not given user # 0 is the default.
The scripts check everything I can imagine going wrong and they should prevent
that you can corrupt your disk images. They will be included in the srctools directory
for z80pack version 1.25.
Hope this helps some of you.
Udo Munk
Jan 7, 2015, 4:48:13 PM1/7/15
to
On Wednesday, January 7, 2015 3:08:43 PM UTC+1, Udo Munk wrote:
> Stay tuned...
I have put a disk image here:
http://www.autometer.de/unix4fun/z80pack/ftp/
Filename is cpm63k.tgz. This disk image is bootable with a 63K CP/M 2.2, that has
check vectors active for both HD's. The disk includes boot/BIOS source and submit
script to build.
If you write a file now to drives i: or j: CP/M sees that the disk was changed and
you'll get the usual R/O BDOS error, if you try to write from CP/M without CMTL-C.
Seems to work OK also for large disks and prevents corruption, if the disk changes
with running emulation.
> Stay tuned...
I have put a disk image here:
http://www.autometer.de/unix4fun/z80pack/ftp/
Filename is cpm63k.tgz. This disk image is bootable with a 63K CP/M 2.2, that has
check vectors active for both HD's. The disk includes boot/BIOS source and submit
script to build.
If you write a file now to drives i: or j: CP/M sees that the disk was changed and
you'll get the usual R/O BDOS error, if you try to write from CP/M without CMTL-C.
Seems to work OK also for large disks and prevents corruption, if the disk changes
with running emulation.
Udo Munk
Jan 8, 2015, 4:59:18 AM1/8/15
to
> > On Sunday, January 4, 2015 2:29:43 PM UTC+1, dottor Piergiorgio M. d' Errico wrote:
> >
> >> well, this is a little feedback for both of you and Schorn:
> >>
> >> I personally think that parameters handling can be streamlined using I
> >> for (Intel) 8080, and taking <number> for the speed. (I actually found
> >> 8Mhz a good balance between host CPU resource and emulation speed,
> >> (esp. during Southern Italy's summer...) )
I thought a bit about this request, here what I think.
The options for the z80pack machines are:
usage: cpmsim -z -8 -s -l -i -u -mn -fn -xfilename
-z = emulate Zilog Z80
-8 = emulate Intel 8080
-s = save core and CPU
-l = load core and CPU
-i = trap on I/O to unused ports
-u = trap on undocumented Z80 instructions
-m = init memory with n
-f = CPU clock frequency n in MHz
-x = load and execute filename
That is reasonable and I keept it easy. Of course one could change these
options as requested, but it won't improve anything. What it will do
for sure is breaking hundreds of scripts, IMHO that isn't worth it yet.
Then it is not my thing to work on consolidated options for emulations
and virtual machines. If you want that write a paper about how options
should look like, and file that in as request for change to all authors
of the machines. Probably a waste of time because such changes won't
do much more than breaking the scripts in existing repositories. That
all needs to be overworked then too and user have to download all the
modified content again.
So for now I'll leave the options alone for good.
> >
> >> well, this is a little feedback for both of you and Schorn:
> >>
> >> I personally think that parameters handling can be streamlined using I
> >> for (Intel) 8080, and taking <number> for the speed. (I actually found
> >> 8Mhz a good balance between host CPU resource and emulation speed,
> >> (esp. during Southern Italy's summer...) )
I thought a bit about this request, here what I think.
The options for the z80pack machines are:
usage: cpmsim -z -8 -s -l -i -u -mn -fn -xfilename
-z = emulate Zilog Z80
-8 = emulate Intel 8080
-s = save core and CPU
-l = load core and CPU
-i = trap on I/O to unused ports
-u = trap on undocumented Z80 instructions
-m = init memory with n
-f = CPU clock frequency n in MHz
-x = load and execute filename
That is reasonable and I keept it easy. Of course one could change these
options as requested, but it won't improve anything. What it will do
for sure is breaking hundreds of scripts, IMHO that isn't worth it yet.
Then it is not my thing to work on consolidated options for emulations
and virtual machines. If you want that write a paper about how options
should look like, and file that in as request for change to all authors
of the machines. Probably a waste of time because such changes won't
do much more than breaking the scripts in existing repositories. That
all needs to be overworked then too and user have to download all the
modified content again.
So for now I'll leave the options alone for good.
Steven Hirsch
Jan 8, 2015, 5:36:35 PM1/8/15
to
ALV has changed. Your update should make it "just work".
I'll let you know.
Steve
Udo Munk
Jan 9, 2015, 12:04:22 AM1/9/15
to
On Thursday, January 8, 2015 at 11:36:35 PM UTC+1, Steven Hirsch wrote:
> Thanks, Udo! Actually, ZSDOS handles relog automagically if it knows that the
> ALV has changed. Your update should make it "just work".
>
> I'll let you know.
You're welcome Steve. Right should automagically work.
> Thanks, Udo! Actually, ZSDOS handles relog automagically if it knows that the
> ALV has changed. Your update should make it "just work".
>
> I'll let you know.
I'll try this with CP/M 3 too, there is a boot option for this anyway with a
8080 clean CP/M 3, that uses no Z80 instructions and so run on both. So
I'll modify this disk for first tests before making it permanent on the
disk images included in the emulations.
Udo Munk
Jan 9, 2015, 3:26:32 PM1/9/15
to
Uploaded CP/M 3 8080 version to z80pack repository. It now has check vectors active for
all HD's, the 512MB j: drive too. Works OK and the TPA still is 62KB, because the vectors
are in banked memory and there is plenty.
A performance loss is not sensible with this fast machine, even not for the 512MB drive
with 8192 directory entries. Way back then we had no such disk drives, at least not for
micros running CP/M. Interesting to try these things nowadays with much better
equipment.
all HD's, the 512MB j: drive too. Works OK and the TPA still is 62KB, because the vectors
are in banked memory and there is plenty.
A performance loss is not sensible with this fast machine, even not for the 512MB drive
with 8192 directory entries. Way back then we had no such disk drives, at least not for
micros running CP/M. Interesting to try these things nowadays with much better
equipment.
Udo Munk
Jan 21, 2015, 6:03:44 AM1/21/15
to
On Friday, January 9, 2015 at 9:26:32 PM UTC+1, Udo Munk wrote:
> Uploaded CP/M 3 8080 version to z80pack repository. It now has
> check vectors active for all HD's, the 512MB j: drive too. Works
> OK and the TPA still is 62KB, because the vectors are in banked
> memory and there is plenty.
Update:
> Uploaded CP/M 3 8080 version to z80pack repository. It now has
> check vectors active for all HD's, the 512MB j: drive too. Works
> OK and the TPA still is 62KB, because the vectors are in banked
> memory and there is plenty.
After testing this for a while I updated the CP/M 3 disk included
in the z80pack distribution with this BIOS too.
Then I modified the MP/M BIOS too, so that check vectors are active
for all HD's. Will also be included in the next release.
0 new messages