nanook@rwing.UUCP (Robert Dinse) (11/13/90)
A while back someone posted source for a Z80 emulator including
"upm", CP/M of sorts. I've been trying to get this running, but seem to
be missing some of the files. For instance, ubg.c and initdisk.c seem
not to have been in the shar files or else they didn't unshar properly
on my system.
At any rate, I am without those, so I've got an emulator compiled,
with some hacking (to get it running on a Tandy 6000), got makedisk, but
now all I can get is no directory or binaries exist if I try to run upm.
I >assume< (this often proves to be a mistake) that initdisk is also
necessary?nsayer@uop.edu (Nick Sayer) (11/14/90)
nanook@rwing.UUCP (Robert Dinse) writes: > A while back someone posted source for a Z80 emulator including >"upm", CP/M of sorts. I've been trying to get this running, but seem to >be missing some of the files. For instance, ubg.c and initdisk.c seem >not to have been in the shar files or else they didn't unshar properly >on my system. oops. :-) The ubg.c file is user supplied. If you don't want to do debugging, put in some dummy routines that do nothing. One of these days I'm going to clean things up a bit. The problem is that the code turned out to be so bloody slow that I got despondent. initdisk.c doesn't exist. Use makedisk. > At any rate, I am without those, so I've got an emulator compiled, >with some hacking (to get it running on a Tandy 6000), got makedisk, but >now all I can get is no directory or binaries exist if I try to run upm. >I >assume< (this often proves to be a mistake) that initdisk is also >necessary? No, you need to make a CPM file with the CPM bdos, CCP and bios. I can't distribute those. Digital Research's lawyer can beat up my lawyer. :-) -- Nick Sayer | Disclaimer: "Don't try this at home, | RIP: Mel Blanc mrapple@quack.sac.ca.us | kids. This should only be done by | 1908-1989 N6QQQ [44.2.1.17] | trained, professional idiots." | May he never 209-952-5347 (Telebit) | --Plucky Duck | be silenced.
wilker@descartes.math.purdue.edu (Clarence Wilkerson) (11/14/90)
If you have a working CP/M system, with some effort you can generate the image needed for the emulator. One problem is that it needs a hex file, origined at 0, followed by a bitmap. I've gotten to the stage of having CCP, BDOS, and FAKE BIOS all in a hex file origined at 0, and an appropriate bitmap. However, I have not converted bitmap to hex yet. If you have no CP/M system, get DOSPLUS25 from simtel20.army.mil in pd2:<cpm.bdos> . Unarc this, and look for movdosplus.cpm or similar file name. This is a version of "MOVCPM". From 0980H to end is the CCP and BDOS clones. The bit map is at 600H. Then you have to hexify it. It might be easier to rewrite the loading routine to handle a binary file, not necessarily origined at 0. Clarence Wilkerson .
nanook@rwing.UUCP (Robert Dinse) (11/15/90)
In article <274059c8.5f66@uop.uop.edu>, nsayer@uop.edu (Nick Sayer) writes: > nanook@rwing.UUCP (Robert Dinse) writes: > > > > A while back someone posted source for a Z80 emulator including > >"upm", CP/M of sorts. I've been trying to get this running, but seem to > >be missing some of the files. For instance, ubg.c and initdisk.c seem > >not to have been in the shar files or else they didn't unshar properly > >on my system. > > The ubg.c file is user supplied. If you don't want to do debugging, > put in some dummy routines that do nothing. One of these days I'm > going to clean things up a bit. The problem is that the code turned > out to be so bloody slow that I got despondent. > Ok, I did this. I also have some ideas for speeding up the code but haven't gotten round to applying them yet. In particular, changing the "case" statements with values of 0-7 that are so frequently used into jump tables that are indexed. > initdisk.c doesn't exist. Use makedisk. > Make disk creates the pseudo-drive. I fully understand that you can't distribute CP/M binaries. I've got CP/M for another box here (model 4), and would xmodem binaries over to the Unix box to try it. Problem is I don't have a way of getting the binaries from the Unix file system onto the psuedo-drive built by the makedisk program. > No, you need to make a CPM file with the CPM bdos, CCP and bios. I > can't distribute those. Digital Research's lawyer can beat up my lawyer. :-) > I have a CP/M box here, can you give me more specific details? Excuse my ignorance, CP/M is not really my forte, Eskimo originally ran on a Z-80 based machine but it ran Newdos rather than CP/M which is quite a different critter. My primary interest in getting this to work is to get some of my old Z-80 tools onto this box (Tandy 6000) so I can mess with the innards of the O/S (z80ctl) more effeciently. > -- > Nick Sayer | Disclaimer: "Don't try this at home, | RIP: Mel Blanc > mrapple@quack.sac.ca.us | kids. This should only be done by | 1908-1989 > N6QQQ [44.2.1.17] | trained, professional idiots." | May he never > 209-952-5347 (Telebit) | --Plucky Duck | be silenced Thanks for posting the emulator and your assistance thus far. It opens up some new avenues for me. Moving files between the model 4 and the 6000 was too much of a pain as I do not regularly have a modem connected to it and the drives aren't compatable. An emulator, even a slow one, is great. Thanks.
darcy@druid.uucp (D'Arcy J.M. Cain) (11/16/90)
In article <274059c8.5f66@uop.uop.edu> nsayer@uop.edu (Nick Sayer) writes: > [...] >No, you need to make a CPM file with the CPM bdos, CCP and bios. I >can't distribute those. Digital Research's lawyer can beat up my lawyer. :-) > While my CP/M emulator isn't completely finished I am going to post it for people to play with if they wish. If anyone wants to hack on it feel free to send back the fixes and I will include them. I have taken what I think is an interesting direction is this version to emulate the CP/M stuff. I do all the prompting and some specific commands such as SAVE, DIR etc myself which gives me a lot of speed for those commands. For the BIOS and BDOS I don't have any Z80 code. Instead I define the BDOS as starting at 0xfec0 and the BIOS at 0xff00. The decoder treats any instruction above 0xfec0 as if it was a RET. The code that calls the decoder checks for that address and emulates the BDOS or BIOS call at that point. The neat thing is that since the code is completely ignored you can have a TPA of 64K less the 256 bytes in page zero as long as the space above 0xfec0 is only used for data or stack. In fact the default stack at startup is 0xfff0. Of course it is slow even though I decode *every* instruction through a massive switch statement. I have a few speedup ideas which depend on using the capabilities of the host processor but this would change from CPU to CPU. There is a compile time option to make a debugging version which is even slower but is really useful for debugging the emulator as well as ordinary CP/M programs. This isn't complete but is working to some extent. Anyway watch alt.sources. I'll post it shortly. -- D'Arcy J.M. Cain (darcy@druid) | D'Arcy Cain Consulting | I support gun control. West Hill, Ontario, Canada | Let's start with the government! + 416 281 6094 |
gideony@microsoft.UUCP (Gideon YUVAL) (11/18/90)
Does a similar 6502/AppleII emulator exist? Thanks -- Gideon Yuval, gideony@microsof.UUCP, 206-882-8080 (fax:206-883-8101;TWX:160520)
richard@pegasus.com (Richard Foulk) (11/20/90)
>Does a similar 6502/AppleII emulator exist? > Yes.