@Heater
Regarding your comment about wanting to use all DR tools for development work. Have you tried MAC? The complete package and docs are available.
@RickB
I have to look into this. I do have some original DR manuals on CP/M which includes instructions on customizing it and rebuilding it for new platforms, different disk hardware, memory sizes etc. Last time I glanced through it it all seemed overly complicated. Then I hit the thing that my CP/M sources are in Z80 (Microsoft) mnemonics and not original DR (Intel). But now it seems that's easy to translate.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I have just been reading through Dennis Ferron's laptop. This really is quite an amazing project. I wonder if it can indeed be ported to an 8080 or Z80?
The reason for that is that those chips can run all the CP/M software. I've just spent a day interfacing MBASIC and VB.NET with each other using the N8VEM. Having a board with a ram disk drive and access to a proper operating system with many different languages is a huge help. Spare I/O lines are handy too - so the board can actually *do* something.
The great thing about the N8VEM is it can run CP/M and all the standard CP/M programs. So you can go to the Altair SIMH site and collect what you need to do a job.
I note the comments about MBASIC not working with 24k of ram. That would be expected given how much the program needs. 64k is a must.
Dennis' project uses a single 64k ram - that is great to see as I thought they only came in 32k or 128k.
It proves you can interface a prop and another CPU. But this thread is about emulating a CPU.
Studying Dennis' project he uses 244s as buffers and I think if you don't use a CPU then the address lines need to be latched rather than just buffered. SRAM and glue chips are kind of old fashioned but they are also very cheap. Speed vs chip count? I guess no driver chips and 26 lines to a SRAM. Or a hybrid with latches and maybe 12 lines. Or 4 lines and a serial ram.
BTW the N8VEM site has CP/M source in both 8080 and Z80 code. One of the first projects was to do the translation, and that was done using a CP/M program on the board itself. So the board was able to rewrite its own operating system. I agree it is confusing. Especially the disk drive routines. That is the brilliant work done by Andrew Lynch and is the difference between a microcontroller board that can run machine code vs a board with an operating system that can load and run programs.
Post Edited (Dr_Acula (James Moxham)) : 1/4/2009 1:53:04 AM GMT
As I said before I like the Dennis Ferron's and Ariba's approach of hooking a real z80, 8080, 6502, whatever up to a Prop and RAM ,with the Prop intercepting the hosts control lines and clocking the host cpu.
Personally I'd like to tackle a z80 or 8085 but that is not going to happen any time soon. If anyone starts on this let's have a new thread for it.
As for the assembler, as far as I can tell there were/are two sets of mnemonics in use for the 8080/8085/Z80 chips. The original from Intel (includes MVI, LXI, STAX etc etc) and I think originally used by Digital Research for CP/M. Then there is the the mnemonics used for the Z80. These had most move instructions reduced to "ld". Introduced by ZILOG I believe as Intel had copyright on the originals.
Now I'd like to use all Digital Research tools to build CP/M and I believe that their assembler only understands Intel mnemonics (Could be wrong). BUT the CP/M sources I have are z80 style mnemonics even if they use only 8080 instructions.
I'm pretty sure that most assemblers compilers and such were using 8080 opcodes only even if they generated z80 codes.
Next, more serious, problem is that the SIMH build system (syscpm2) uses some programs that require z80 op codes to run. This really neeeds fixing for PropAltair to rebuild itself. Either we implement the few missing z80 instructions required or we change the build stystem.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
;
; ROUTINE TO PRINT (A) ON THE CONSOLE. ALL REGISTERS USED.
;
PRINT MOV E,A ;SETUP BDOS CALL.
MVI C,2
JMP ENTRY
and
;
; ROUTINE TO PRINT (A) ON THE CONSOLE. ALL REGISTERS USED.
;
PRINT: LD E,A ; SETUP BDOS CALL.
LD C,2
JP ENTRY
Like you say, same binary numbers in a compiled version, but subtle differences such as LD vs MVI and JP vs JMP, and the very subtle difference of the : after PRINT
So CP/M will run using just 8080 codes and if you want it in DR mnemonics that is fine. Where there might be problems is programs written after the early 80s that could use Z80 codes in, say, a compiler. I don't know how much of that went on, but I suspect most people stuck with just 8080 opcodes to keep applications more universal. Looking through the source code, 90% of the instructions are never used. Even though you spent some time on DAA, I couldn't find it anywhere. Even though the 8080 and Z80s were not RISCs, I think a lot of programmers treated them as such by only using a small subset of instructions.
Is the problem with adding the Z80 codes the time needed to code them, or the space in the Propeller? If the former, I wonder if reverse engineering the lookup tables in TASM would help. Or just mindlessly coding in instructions. I did that once when I wrote a Z80 interpreter/compiler.
Hmm - 8 pages on this thread and LOL you started by wondering if anyone would be interested!
Most code I have seen uses the second style. Microsofts M80 assembler will accept both. Just put the directive ".Z80" for Zilog style or ".8080" for the Intel style. I notice CBIOSX.MAC uses both.
I must say the .z80 style is easier to read and write.
CP/M and many other programs only uses actual 8080 opcodes even if they are writen with .z80 mnemonics. The BDS C compiler for example which will also only generate 8080 opcodes.
The DAA instruction was a pain because it is used by the "SURVEY" utility which prints details of RAM, ROM and I/O port use. Haven't found any other program that uses it yet though.
Now the problem: The altairz80 simulator of SIMH uses a program called CPMBOOT.COM in it's system generation script syscpm2.sub. That program, CPMBOOT.COM, is actually written in a simple high level language called SPL. The SPL compiler generates z80 opcodes in CPMBOOT.COM. So we need to support at least a few z80 opcodes in order use the existing syscpm2.
Thinking about this over night I have decided that PropAltair should strive to use the SIMH/Altairz80 CP/M sources and build system unchanged, rather than have to maintain yet another CP/M derivitive. So as I say some z80 opcodes will need implementing.
(I may work on a pure 8080 build as fresh from DR anyway but that will be called something else if it ever happens)
Anyone know what opcodes they may be? Or is some reverse engineering required here ?
I don't really want to spend the time on working on a full up z80 emulation. At least for a single COG implementation code space is a problem. When I go to multiple COGS it may become easier. At which point I may change my mind. Or someone else may want to continue with z80.
Yes, I'm amazed at the interest here. Very encouraging.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
"Thinking about this over night I have decided that PropAltair should strive to use the SIMH/Altairz80 CP/M sources and build system unchanged, rather than have to maintain yet another CP/M derivitive. So as I say some z80 opcodes will need implementing."
Agree.
Do you have the .COM or the source as well?
I've never had much luck with disassemblers. They fall over at the first .db data bytes, and then never seem to be able to recover. So how would you know what is what unless you have the source?
There are some truly obscure Z80 opcodes, eg set 6,(ix+d). Yes, ok maybe it might be able to set up a value in Ix with an offset and then set one bit high, but I'd probably load it into A, set the bit in A and then send it back out to ram. I doubt hardly anyone used those codes. So it is very tedious to put them all in and have them using up space.
I tend to code not even using the alternate registers. The only unique Z80 instruction I do use a bit is LDIR for block moves.
Memory 64k vs Z80 instruction set? Hmm. Both are going to take a bit of time.
Yep. Point is it's nice to be able to exchange boot disk images between SIMH on a PC and whatever "real" system you have. Prop emulation or actual z80 hardware.
As I say, the source to the troublesome CPMBOOT.COM is in a high level language, SPL. This looks like a simple Pascal and so gives no clue as to the opcodes used in the compiled code.
I hear about LDIR a lot and suspect that this is the culprit. CPMBOOT probably uses it for shifting those disk sectors around when building the boot disk. Only running the code and trapping for unknown ops will get us the true answer.
I always thought use of the alternate registers was pretty much reserved for fast context switching in interrupt handlers. So never occurs in "normal" code. PropAltair does not support interrupts anyway.
OOPS, ERROR: All the time I'm refering to CPMBOOT.COM as the problem program, it is in fact BOOTGEN.COM. This is what creates the boot sectors from CPMBOOT.
I have attached both source and executable of BOOTGEN in case someone can enlighten as to the z80 dependence.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
You know that with a working 8080 emulator running on the prop you have 99% of the worlds best tool for finding software that uses non-8080 op codes. When the emulator gets an unrecognized op code it could output the memory address and the next few bytes of data to some I/O device (Hub ram, sd, terminal, etc). Knowing only how many bytes the instruction used would allow the emulator to step to the next instruction. It would also provide some idea of what Z80 instructions might be worth adding to the emulator.
@kwinn, When I said "Only running the code and trapping for unknown ops will get us the true answer." I meant exactly as you say but perhaps not put so clearly.
Just now I can't think to hard about it as I don't have a working Prop system at all. Something has bust in my home made Prop board and I'm separated from all my electronics kit over the festive season.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Anyone out there got a real 8080 or 8085 CP/M system? As opposed to a Z80.
So far PropAltair runs CP/M and various BASICs without a hitch. It passes all the regression tests I created from Intel's 8080 documentation. It passes a CPU diagnostic from Microcosm Associates from 1980.
But there is one fly in the ointment. There is 8080/Z80 instruction set exerciser by Frank D Cringle that PropAltair fails on.
I'm fairly sure that it fails because it is expecting the flags to be set as per a MOSTEK Z80. Even when configured to test only 8080 instructions.
So here is the problem:
1. Z80 uses the parity flag to indicate overflow of signed numbers during arithmetic ops. 8080 just uses it for parity.
2. Z80 uses bit 1 of the flags as an indication that the last arithmetic op was an addition or subtraction.
3. I really want a test that works for a real 8080/8085.
Now the test program is not easy to modify without comparison to a real 8080/85 because it basically computes 32bit CRCs of batches of 10s or 100s of thousands of test cases and the compares with the CRCs that Frank has obtained from a MOSTEK Z80.
So really its still a Z80 tester even when testing 8080 instructions.
So is there anyone with a real 8080/85 CP/M system who could run this test and send me the CRC's that it reports ?
Attached is the test and it's source code of the test.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
1. Combined the simulator "main" object with the I/O subsystem. Thus saving a COG.
2. Fixed up flag setting, to get the MICROCOSM ASSOCIATES CPU diagnostic to pass. Works like am 8085 now.
If anyone wants to try this on a Prop Demo Board it will boot to a CP/M prompt from its self contained "files" without any SD card attached. For any more it is necessary to download the cpm2.dsk image to an SD card with cpm2sd.spin and PropTerminal.
altair_sim.spin is still the top level object, where you will want to change the clock settings.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater said "As for the assembler, as far as I can tell there were/are two sets of mnemonics in use for the 8080/8085/Z80 chips. The original from Intel (includes MVI, LXI, STAX etc etc) and I think originally used by Digital Research for CP/M. Then there is the the mnemonics used for the Z80. These had most move instructions reduced to "ld". Introduced by ZILOG I believe as Intel had copyright on the originals."
A little history: When Intel brought out the 8080, they used an architecture similar to the DEC PDP-n, and used the same mnemonics. When the z80 was still being developed, Zilog intended to use the same mnemonics also, only adding their new ones. They didn't because Intel threatened to sue for copyright infringement. The same thing happened with Motorola's 6800. If the companies hadn't got so litigious, life would have been a lot easier for us assembly programmers.
Dr. Acula says "I've never had much luck with disassemblers. They fall over at the first .db data bytes, and then never seem to be able to recover. So how would you know what is what unless you have the source?"
If you're thinking of disassemblers that run from a command line, as in "disasm <infile> <outfile>, it's true. 8080 assembly programmers were [noparse][[/noparse]are?] very, very clever, and no program could figure out their code, unaided.
The secret with disassemblers is to use them interactively. Ward Christensen's excellent RESOURCE, and later REZ, is a great example. The first thing you do is to scan the entire file for text messages like "Copyright Digital Research Corporation". When you find them, mark them as text. Next, look for buffers like arrays of 0x00's, etc. Mark them as data.
From here, there are two approaches. I like to just scan the program looking for small subroutines. Look for a label, followed shortly by a RET. See if you can identify any utility subs. Change the label to something meaningful. Now scan the file again to see where that function is called.
In CP/M, finding such functions is pretty easy. Define BDOS = 0x0005, and see where it's called.
Alternatively, if you can't find well-delineated functions (if, for example, the software were written by Bill Gates), you can just start marching through the code, trying to separate code from data. Again, CP/M makes it easy, because all code starts at 0x100.
I wrote a minicomputer disassembler. At least all instructions were the same length. I just made labels for each decoded instruction in the first pass, and added the text to the line end. Second pass removed all labels unreferenced. The labels had a character prefix plus address. A third pass could have been done to identify which were jumps to change the prefix, so that variables would be known. However, like the propeller, self modifying code was used. Only 3 registers (index registers) were available. Everything was memory to memory - and decimal !!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I did once a sort of smart disassembler. It would grab a compiled file and sort of interpret the code. Being aware of transfer control instructions it could dissasemble in two passes. It used a buffer to hold a set of flags per address. Later a simple dissasembler would use the flags to disassemble the original.
Heater - I just had a look at the Z80 code for the SIMH simulator. All in C, but not entirely dissimilar to Spin. Download at http://www.schorn.ch/cpm/intro.php scroll down to the second table at the bottom of that table. File is altairz80_cpu_nommu.c
Some of the instructions end up incredibly simple eg
case 0x13: /* INC DE */
++DE;
break;
Some are a little more complex
case 0x19: /* ADD HL,DE */
HL &= ADDRMASK;
DE &= ADDRMASK;
sum = HL + DE;
AF = (AF & ~0x3b) | ((sum >> 8) & 0x28) | cbitsTable[noparse][[/noparse](HL ^ DE ^ sum) >> 8];
HL = sum;
break;
And here is the code for your DAA:
case 0x27: /* DAA */
acu = HIGH_REGISTER(AF);
temp = LOW_DIGIT(acu);
cbits = TSTFLAG(C);
if (TSTFLAG(N)) { /* last operation was a subtract */
int hd = cbits || acu > 0x99;
if (TSTFLAG(H) || (temp > 9)) { /* adjust low digit */
if (temp > 5) SETFLAG(H, 0);
acu -= 6;
acu &= 0xff;
}
if (hd) acu -= 0x160; /* adjust high digit */
}
else { /* last operation was an add */
if (TSTFLAG(H) || (temp > 9)) { /* adjust low digit */
SETFLAG(H, (temp > 9));
acu += 6;
}
if (cbits || ((acu & 0x1f0) > 0x90)) acu += 0x60; /* adjust high digit */
}
AF = (AF & 0x12) | rrdrldTable[noparse][[/noparse]acu & 0xff] | ((acu >> 8) & 1) | cbits;
break;
Dr_A, I have from time to time looked long and hard at that code from SIMH. The SIMH Altairz80 simulator is what spurred me on with emulation on the Propeller as I realized I could run it as a reference machine, not having any real hardware of my own. Not to mention borrowing all the CP/M that it runs ready made.
I've also recently looked at the GNU 8085 emulator code which mostly looks a lot simpler.
I'm sure that the C code could be translated to SPIN easily enough if one wanted to invest the time in it. But then you'd end up with a dog slow emulator. My first attempt was in SPIN just to see if I could get the logic anywhere near right.
In the end I just sat down with the Intel 8080 manual and went through it op by op in PASM.
That SIMH code for DAA makes my PASM implementation, which works to all intents and purposes, look quite straight forward [noparse]:)[/noparse]
Anyway the issue is that SIMH implements flags (and therefore DAA) as per a MOSTEK Z80. What I was heading for is 8080/85 (which are not the same) or ultimately a means of switching between the three.
Seems setting flags the Z80 way is not going to happen in the current single COG PropAltair, I'm just out of LONGS and patience.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater, I have really enjoyed tinkering with your CP/M emulator...
Two Questions:
1. How do I adjust the memory to allow for the TV_text driver v. the serial port driver.
2. How do I write new files to the CP/M disk image.
Sincerely,
Willem
Welcome to the forum Willem and glad you had some fun with PropAltair.
As to your fist question, as you see it would be very easy to use the TV or VGA driver EXCEPT for the lack of memory.
To get a TV/VGA driver in it is necessary either shrink the size of the CP/M system from 24K to 16K or less making room in the HUB RAM for the drivers. Or one has to add external RAM to the Prop in which to put the CP/M system.
Adding extra RAM to the Prop is a hot topic around here, as you may have noticed, and a number of people are working on it in different ways. All of them will require adding RAM driver code to the emulator which may be tricky as it is very tightly packed into its COG already. For this reason, and others, I am working on a multiple COG emulator that will have room to work in.
Shrinking the size of the CP/M system and adding a TV/text driver is something I have planned to do. There are two parts to that problem:
1) Build a CP/M system of 16K or less. This is done from the Altairz80 emulator which is part of the SIMH project. www.schorn.ch/cpm/intro.php This quite easy after, editing one configuration file, just use the syscpm2 command.
2) Make some changes to the memory layout specified in altair_mem to get the CP/M components loaded to the right positions.
Of course you need to download a new SD card image. After that there should be room in the Prop to add TV/VGA drivers.
If you are interested in doing 2) I can provide extra help, or even do it my self if I have some time.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Just now that is tricky as well. Up until now if I wanted a new file on the system I have used the SIMH Altairz80 simulator to move the files on to a disk image then build the CP/M down to 24K then put that disk image on SD card.
Now ideally, authentically, we should build a disk image with XMODEM on it and use that to get stuff onto the Prop. CP/M.
This is something that will come to pass eventually.
PropAltair will let you format a further 7 "floppy" disks on SD card from B: on up, so there is loads of space to put things.
I'm also looking at simulating 4 CP/M hard drives.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
The altair also has a hard drive emulation with 8Mb. The following creates an emulation with 7 disks A> to G> and also disk I> which is the hard drive.
But CP/M *really* needs 64k. I'm following the thread on the 64 pin prop with great interest. Though I'm wondering what one could do with a standard prop connected to a 128k sram.
d tracks[noparse][[/noparse]0-7] 254
attach dsk cpm2.dsk
attach dsk1 basic.dsk
attach dsk2 games.dsk
attach dsk3 sbasic.dsk
attach dsk4 supercalc.dsk
attach dsk5 tools.dsk
attach dsk6 wordstar.dsk
attach hdsk i.dsk
set cpu 64k
set cpu noitrap
set cpu z80
set cpu altairrom
set cpu nonbanked
reset cpu
set sio ansi
set sio nosleep
boot dsk
bye
Dr_A, The plan is to add hard drive simulation to PropAltair that looks, to CP/M, like SIMH hard drives. Four drives of 8M. Then we can use the SIMH CP/M customized BIOS unchanged. Also the hard disk boot ROM image.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Heater, do you happen to have any documentation on modifying the BDOS? This project is amazing, but I have an actual Kaypro 2'84 with an Spartan3 FPGA wired into the system bus, and I was interested in trying to add a large non-volatile storage system to it (I actually got a prop board because I wanted to use it as an ethernet adapter for my kaypro!).
@brietech: Kaypro + Spatan3, what a wonderful combination of old and new technology.
What do you mean by "large"? If you are staying within the realms of original CP/M 2, 1M floppies and 8Meg hard drives then you will only need to modify the BIOS to get access to your new hardware. There are only a few simple routines to modify to select current drive, read/write sectors etc. Do you have the source code to your Kaypro's BIOS? You will need it as you will need to continue to support the Kaypo's existing hardware. The tricky part is getting your new BIOS onto the boot tracks of a floppy disk. Searching on the net you will find the Digital Research CP/M 2 manual which has instructions on creating boot disks. Perhaps on some CP/M forum you may find (or ask) about easy ways to do this for a Kaypro.
I have never created boot disks outside of the SIMH emulator which has scripts to do it for you.
In PropAltair I cheat by having the Propeller load the BIOS, BDOS and CCP into memory first and the starting the 8080 emulation. It does not actually boot from any disk (Although it can if you make a jump to the boot prom code at FF00) Perhaps if your Spartan can get control of the Kaypros bus you could do this trick with it as well. Fill the memory up and reset the CPU.
If you want bigger hard drives I guess it is necessary to modify the BDOS. I've never seen any docs on that, after all it was DR's "secret". All I can suggest is sitting down with the source code and studying it for a long while, it's not so big. You can find the sources on the altairz80 site and elsewhere. But I have a feeling that some of those limits on disk sizes are kind of fundamental the way CP/M stores file control blocks in memory and directory entries on disk etc. May not be possible to expand them in a CP/M compatible way.
By the way, did you connect your Prop to the Kaypro bus as a peripheral chip? I want to connect a Prop to a Z80 bus soon so would be interested how that worked out.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
By large I mean at least a couple of megabytes It currently has dual 360kb floppies (upgraded from the original dual 193 kb!), along with an Advent TurboROM. I've seen a couple of copies of code labeled "Kaypro BIOS" I think, but I haven't had a chance to look at them. I'm not sure how specific they are for each model of the kaypro (and most of them are in "squeezed" format, so I have to actually put them on the kaypro to look at them).
In regards to the Spartan3, my Kaypro 2 had an empty socket where a PIO chip could go, and it was assigned a 4-byte address space in the z-80's I/O space. I used series 330-ohm resistors, and just wired the FPGA directly into the system bus. The farthest I ever got with it was to instantiate a 4-byte SRAM and verify that I could read/write to it in MBASIC, but I haven't played with it in a while.
Oops, didn't see your question about interfacing the prop to the kaypro. I haven't gotten a chance to try it yet, but I was actually thinking just doing it over serial (the kaypro supports 19200!), and trying to implement some sort of WGET functionality or something. The FPGA could be used as well to provide a faster interface. I just moved to a new apartment and started taking a class, so I haven't had a whole lot of free time to play around with it. Any thoughts?
You could always run up an emulator like SIMH Alatairz80 on Windows, Linux or Mac, and import your squeezed files into it where you can un-squeeze them. Altairz80 has R.COM and W.COM to import and export from he host file system.
What you are doing with your Spartan on the Kaypro is just what I want to do with the Propeller on Z80 card replacing the PIO or other peripheral. Then we can have access to SD cards and VT100 terminal emulation etc via the Prop.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Comments
I ran into last night.. Mostly configuration stuff. [noparse]:)[/noparse]
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Check out: Protoboard Introduction , Propeller Cookbook 1.4 & Software Index
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card connected? - PropDOS
Regarding your comment about wanting to use all DR tools for development work. Have you tried MAC? The complete package and docs are available.
Rick
I have to look into this. I do have some original DR manuals on CP/M which includes instructions on customizing it and rebuilding it for new platforms, different disk hardware, memory sizes etc. Last time I glanced through it it all seemed overly complicated. Then I hit the thing that my CP/M sources are in Z80 (Microsoft) mnemonics and not original DR (Intel). But now it seems that's easy to translate.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
The reason for that is that those chips can run all the CP/M software. I've just spent a day interfacing MBASIC and VB.NET with each other using the N8VEM. Having a board with a ram disk drive and access to a proper operating system with many different languages is a huge help. Spare I/O lines are handy too - so the board can actually *do* something.
The great thing about the N8VEM is it can run CP/M and all the standard CP/M programs. So you can go to the Altair SIMH site and collect what you need to do a job.
I note the comments about MBASIC not working with 24k of ram. That would be expected given how much the program needs. 64k is a must.
Dennis' project uses a single 64k ram - that is great to see as I thought they only came in 32k or 128k.
It proves you can interface a prop and another CPU. But this thread is about emulating a CPU.
Studying Dennis' project he uses 244s as buffers and I think if you don't use a CPU then the address lines need to be latched rather than just buffered. SRAM and glue chips are kind of old fashioned but they are also very cheap. Speed vs chip count? I guess no driver chips and 26 lines to a SRAM. Or a hybrid with latches and maybe 12 lines. Or 4 lines and a serial ram.
BTW the N8VEM site has CP/M source in both 8080 and Z80 code. One of the first projects was to do the translation, and that was done using a CP/M program on the board itself. So the board was able to rewrite its own operating system. I agree it is confusing. Especially the disk drive routines. That is the brilliant work done by Andrew Lynch and is the difference between a microcontroller board that can run machine code vs a board with an operating system that can load and run programs.
Post Edited (Dr_Acula (James Moxham)) : 1/4/2009 1:53:04 AM GMT
Rick
Personally I'd like to tackle a z80 or 8085 but that is not going to happen any time soon. If anyone starts on this let's have a new thread for it.
As for the assembler, as far as I can tell there were/are two sets of mnemonics in use for the 8080/8085/Z80 chips. The original from Intel (includes MVI, LXI, STAX etc etc) and I think originally used by Digital Research for CP/M. Then there is the the mnemonics used for the Z80. These had most move instructions reduced to "ld". Introduced by ZILOG I believe as Intel had copyright on the originals.
Now I'd like to use all Digital Research tools to build CP/M and I believe that their assembler only understands Intel mnemonics (Could be wrong). BUT the CP/M sources I have are z80 style mnemonics even if they use only 8080 instructions.
I'm pretty sure that most assemblers compilers and such were using 8080 opcodes only even if they generated z80 codes.
Next, more serious, problem is that the SIMH build system (syscpm2) uses some programs that require z80 op codes to run. This really neeeds fixing for PropAltair to rebuild itself. Either we implement the few missing z80 instructions required or we change the build stystem.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 1/4/2009 11:06:52 AM GMT
;
; ROUTINE TO PRINT (A) ON THE CONSOLE. ALL REGISTERS USED.
;
PRINT MOV E,A ;SETUP BDOS CALL.
MVI C,2
JMP ENTRY
and
;
; ROUTINE TO PRINT (A) ON THE CONSOLE. ALL REGISTERS USED.
;
PRINT: LD E,A ; SETUP BDOS CALL.
LD C,2
JP ENTRY
Like you say, same binary numbers in a compiled version, but subtle differences such as LD vs MVI and JP vs JMP, and the very subtle difference of the : after PRINT
So CP/M will run using just 8080 codes and if you want it in DR mnemonics that is fine. Where there might be problems is programs written after the early 80s that could use Z80 codes in, say, a compiler. I don't know how much of that went on, but I suspect most people stuck with just 8080 opcodes to keep applications more universal. Looking through the source code, 90% of the instructions are never used. Even though you spent some time on DAA, I couldn't find it anywhere. Even though the 8080 and Z80s were not RISCs, I think a lot of programmers treated them as such by only using a small subset of instructions.
Is the problem with adding the Z80 codes the time needed to code them, or the space in the Propeller? If the former, I wonder if reverse engineering the lookup tables in TASM would help. Or just mindlessly coding in instructions. I did that once when I wrote a Z80 interpreter/compiler.
Hmm - 8 pages on this thread and LOL you started by wondering if anyone would be interested!
Most code I have seen uses the second style. Microsofts M80 assembler will accept both. Just put the directive ".Z80" for Zilog style or ".8080" for the Intel style. I notice CBIOSX.MAC uses both.
I must say the .z80 style is easier to read and write.
CP/M and many other programs only uses actual 8080 opcodes even if they are writen with .z80 mnemonics. The BDS C compiler for example which will also only generate 8080 opcodes.
The DAA instruction was a pain because it is used by the "SURVEY" utility which prints details of RAM, ROM and I/O port use. Haven't found any other program that uses it yet though.
Now the problem: The altairz80 simulator of SIMH uses a program called CPMBOOT.COM in it's system generation script syscpm2.sub. That program, CPMBOOT.COM, is actually written in a simple high level language called SPL. The SPL compiler generates z80 opcodes in CPMBOOT.COM. So we need to support at least a few z80 opcodes in order use the existing syscpm2.
Thinking about this over night I have decided that PropAltair should strive to use the SIMH/Altairz80 CP/M sources and build system unchanged, rather than have to maintain yet another CP/M derivitive. So as I say some z80 opcodes will need implementing.
(I may work on a pure 8080 build as fresh from DR anyway but that will be called something else if it ever happens)
Anyone know what opcodes they may be? Or is some reverse engineering required here ?
I don't really want to spend the time on working on a full up z80 emulation. At least for a single COG implementation code space is a problem. When I go to multiple COGS it may become easier. At which point I may change my mind. Or someone else may want to continue with z80.
Yes, I'm amazed at the interest here. Very encouraging.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Agree.
Do you have the .COM or the source as well?
I've never had much luck with disassemblers. They fall over at the first .db data bytes, and then never seem to be able to recover. So how would you know what is what unless you have the source?
There are some truly obscure Z80 opcodes, eg set 6,(ix+d). Yes, ok maybe it might be able to set up a value in Ix with an offset and then set one bit high, but I'd probably load it into A, set the bit in A and then send it back out to ram. I doubt hardly anyone used those codes. So it is very tedious to put them all in and have them using up space.
I tend to code not even using the alternate registers. The only unique Z80 instruction I do use a bit is LDIR for block moves.
Memory 64k vs Z80 instruction set? Hmm. Both are going to take a bit of time.
As I say, the source to the troublesome CPMBOOT.COM is in a high level language, SPL. This looks like a simple Pascal and so gives no clue as to the opcodes used in the compiled code.
I hear about LDIR a lot and suspect that this is the culprit. CPMBOOT probably uses it for shifting those disk sectors around when building the boot disk. Only running the code and trapping for unknown ops will get us the true answer.
I always thought use of the alternate registers was pretty much reserved for fast context switching in interrupt handlers. So never occurs in "normal" code. PropAltair does not support interrupts anyway.
OOPS, ERROR: All the time I'm refering to CPMBOOT.COM as the problem program, it is in fact BOOTGEN.COM. This is what creates the boot sectors from CPMBOOT.
I have attached both source and executable of BOOTGEN in case someone can enlighten as to the z80 dependence.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Just now I can't think to hard about it as I don't have a working Prop system at all. Something has bust in my home made Prop board and I'm separated from all my electronics kit over the festive season.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Anyone out there got a real 8080 or 8085 CP/M system? As opposed to a Z80.
So far PropAltair runs CP/M and various BASICs without a hitch. It passes all the regression tests I created from Intel's 8080 documentation. It passes a CPU diagnostic from Microcosm Associates from 1980.
But there is one fly in the ointment. There is 8080/Z80 instruction set exerciser by Frank D Cringle that PropAltair fails on.
I'm fairly sure that it fails because it is expecting the flags to be set as per a MOSTEK Z80. Even when configured to test only 8080 instructions.
So here is the problem:
1. Z80 uses the parity flag to indicate overflow of signed numbers during arithmetic ops. 8080 just uses it for parity.
2. Z80 uses bit 1 of the flags as an indication that the last arithmetic op was an addition or subtraction.
3. I really want a test that works for a real 8080/8085.
Now the test program is not easy to modify without comparison to a real 8080/85 because it basically computes 32bit CRCs of batches of 10s or 100s of thousands of test cases and the compares with the CRCs that Frank has obtained from a MOSTEK Z80.
So really its still a Z80 tester even when testing 8080 instructions.
So is there anyone with a real 8080/85 CP/M system who could run this test and send me the CRC's that it reports ?
Attached is the test and it's source code of the test.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Changes:
1. Combined the simulator "main" object with the I/O subsystem. Thus saving a COG.
2. Fixed up flag setting, to get the MICROCOSM ASSOCIATES CPU diagnostic to pass. Works like am 8085 now.
If anyone wants to try this on a Prop Demo Board it will boot to a CP/M prompt from its self contained "files" without any SD card attached. For any more it is necessary to download the cpm2.dsk image to an SD card with cpm2sd.spin and PropTerminal.
altair_sim.spin is still the top level object, where you will want to change the clock settings.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
A little history: When Intel brought out the 8080, they used an architecture similar to the DEC PDP-n, and used the same mnemonics. When the z80 was still being developed, Zilog intended to use the same mnemonics also, only adding their new ones. They didn't because Intel threatened to sue for copyright infringement. The same thing happened with Motorola's 6800. If the companies hadn't got so litigious, life would have been a lot easier for us assembly programmers.
Dr. Acula says "I've never had much luck with disassemblers. They fall over at the first .db data bytes, and then never seem to be able to recover. So how would you know what is what unless you have the source?"
If you're thinking of disassemblers that run from a command line, as in "disasm <infile> <outfile>, it's true. 8080 assembly programmers were [noparse][[/noparse]are?] very, very clever, and no program could figure out their code, unaided.
The secret with disassemblers is to use them interactively. Ward Christensen's excellent RESOURCE, and later REZ, is a great example. The first thing you do is to scan the entire file for text messages like "Copyright Digital Research Corporation". When you find them, mark them as text. Next, look for buffers like arrays of 0x00's, etc. Mark them as data.
From here, there are two approaches. I like to just scan the program looking for small subroutines. Look for a label, followed shortly by a RET. See if you can identify any utility subs. Change the label to something meaningful. Now scan the file again to see where that function is called.
In CP/M, finding such functions is pretty easy. Define BDOS = 0x0005, and see where it's called.
Alternatively, if you can't find well-delineated functions (if, for example, the software were written by Bill Gates), you can just start marching through the code, trying to separate code from data. Again, CP/M makes it easy, because all code starts at 0x100.
In time, all becomes clear <smile>.
Jack
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Prop Tools under Development or Completed (Index)
· Emulators (Micros eg Altair, and Terminals eg VT100) - index
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz
Some of the instructions end up incredibly simple eg
case 0x13: /* INC DE */
++DE;
break;
Some are a little more complex
case 0x19: /* ADD HL,DE */
HL &= ADDRMASK;
DE &= ADDRMASK;
sum = HL + DE;
AF = (AF & ~0x3b) | ((sum >> 8) & 0x28) | cbitsTable[noparse][[/noparse](HL ^ DE ^ sum) >> 8];
HL = sum;
break;
And here is the code for your DAA:
case 0x27: /* DAA */
acu = HIGH_REGISTER(AF);
temp = LOW_DIGIT(acu);
cbits = TSTFLAG(C);
if (TSTFLAG(N)) { /* last operation was a subtract */
int hd = cbits || acu > 0x99;
if (TSTFLAG(H) || (temp > 9)) { /* adjust low digit */
if (temp > 5) SETFLAG(H, 0);
acu -= 6;
acu &= 0xff;
}
if (hd) acu -= 0x160; /* adjust high digit */
}
else { /* last operation was an add */
if (TSTFLAG(H) || (temp > 9)) { /* adjust low digit */
SETFLAG(H, (temp > 9));
acu += 6;
}
if (cbits || ((acu & 0x1f0) > 0x90)) acu += 0x60; /* adjust high digit */
}
AF = (AF & 0x12) | rrdrldTable[noparse][[/noparse]acu & 0xff] | ((acu >> 8) & 1) | cbits;
break;
I wonder - how well does C translate to Spin?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Prop Tools under Development or Completed (Index)
· Emulators (Micros eg Altair, and Terminals eg VT100) - index
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz
I've also recently looked at the GNU 8085 emulator code which mostly looks a lot simpler.
I'm sure that the C code could be translated to SPIN easily enough if one wanted to invest the time in it. But then you'd end up with a dog slow emulator. My first attempt was in SPIN just to see if I could get the logic anywhere near right.
In the end I just sat down with the Intel 8080 manual and went through it op by op in PASM.
That SIMH code for DAA makes my PASM implementation, which works to all intents and purposes, look quite straight forward [noparse]:)[/noparse]
Anyway the issue is that SIMH implements flags (and therefore DAA) as per a MOSTEK Z80. What I was heading for is 8080/85 (which are not the same) or ultimately a means of switching between the three.
Seems setting flags the Z80 way is not going to happen in the current single COG PropAltair, I'm just out of LONGS and patience.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Two Questions:
1. How do I adjust the memory to allow for the TV_text driver v. the serial port driver.
2. How do I write new files to the CP/M disk image.
Sincerely,
Willem
As to your fist question, as you see it would be very easy to use the TV or VGA driver EXCEPT for the lack of memory.
To get a TV/VGA driver in it is necessary either shrink the size of the CP/M system from 24K to 16K or less making room in the HUB RAM for the drivers. Or one has to add external RAM to the Prop in which to put the CP/M system.
Adding extra RAM to the Prop is a hot topic around here, as you may have noticed, and a number of people are working on it in different ways. All of them will require adding RAM driver code to the emulator which may be tricky as it is very tightly packed into its COG already. For this reason, and others, I am working on a multiple COG emulator that will have room to work in.
Shrinking the size of the CP/M system and adding a TV/text driver is something I have planned to do. There are two parts to that problem:
1) Build a CP/M system of 16K or less. This is done from the Altairz80 emulator which is part of the SIMH project.
www.schorn.ch/cpm/intro.php This quite easy after, editing one configuration file, just use the syscpm2 command.
2) Make some changes to the memory layout specified in altair_mem to get the CP/M components loaded to the right positions.
Of course you need to download a new SD card image. After that there should be room in the Prop to add TV/VGA drivers.
If you are interested in doing 2) I can provide extra help, or even do it my self if I have some time.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Just now that is tricky as well. Up until now if I wanted a new file on the system I have used the SIMH Altairz80 simulator to move the files on to a disk image then build the CP/M down to 24K then put that disk image on SD card.
Now ideally, authentically, we should build a disk image with XMODEM on it and use that to get stuff onto the Prop. CP/M.
This is something that will come to pass eventually.
PropAltair will let you format a further 7 "floppy" disks on SD card from B: on up, so there is loads of space to put things.
I'm also looking at simulating 4 CP/M hard drives.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
But CP/M *really* needs 64k. I'm following the thread on the 64 pin prop with great interest. Though I'm wondering what one could do with a standard prop connected to a 128k sram.
d tracks[noparse][[/noparse]0-7] 254
attach dsk cpm2.dsk
attach dsk1 basic.dsk
attach dsk2 games.dsk
attach dsk3 sbasic.dsk
attach dsk4 supercalc.dsk
attach dsk5 tools.dsk
attach dsk6 wordstar.dsk
attach hdsk i.dsk
set cpu 64k
set cpu noitrap
set cpu z80
set cpu altairrom
set cpu nonbanked
reset cpu
set sio ansi
set sio nosleep
boot dsk
bye
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
What do you mean by "large"? If you are staying within the realms of original CP/M 2, 1M floppies and 8Meg hard drives then you will only need to modify the BIOS to get access to your new hardware. There are only a few simple routines to modify to select current drive, read/write sectors etc. Do you have the source code to your Kaypro's BIOS? You will need it as you will need to continue to support the Kaypo's existing hardware. The tricky part is getting your new BIOS onto the boot tracks of a floppy disk. Searching on the net you will find the Digital Research CP/M 2 manual which has instructions on creating boot disks. Perhaps on some CP/M forum you may find (or ask) about easy ways to do this for a Kaypro.
I have never created boot disks outside of the SIMH emulator which has scripts to do it for you.
In PropAltair I cheat by having the Propeller load the BIOS, BDOS and CCP into memory first and the starting the 8080 emulation. It does not actually boot from any disk (Although it can if you make a jump to the boot prom code at FF00) Perhaps if your Spartan can get control of the Kaypros bus you could do this trick with it as well. Fill the memory up and reset the CPU.
If you want bigger hard drives I guess it is necessary to modify the BDOS. I've never seen any docs on that, after all it was DR's "secret". All I can suggest is sitting down with the source code and studying it for a long while, it's not so big. You can find the sources on the altairz80 site and elsewhere. But I have a feeling that some of those limits on disk sizes are kind of fundamental the way CP/M stores file control blocks in memory and directory entries on disk etc. May not be possible to expand them in a CP/M compatible way.
By the way, did you connect your Prop to the Kaypro bus as a peripheral chip? I want to connect a Prop to a Z80 bus soon so would be interested how that worked out.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
In regards to the Spartan3, my Kaypro 2 had an empty socket where a PIO chip could go, and it was assigned a 4-byte address space in the z-80's I/O space. I used series 330-ohm resistors, and just wired the FPGA directly into the system bus. The farthest I ever got with it was to instantiate a 4-byte SRAM and verify that I could read/write to it in MBASIC, but I haven't played with it in a while.
Here is a pic:
What you are doing with your Spartan on the Kaypro is just what I want to do with the Propeller on Z80 card replacing the PIO or other peripheral. Then we can have access to SD cards and VT100 terminal emulation etc via the Prop.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.