f



Ported DRI CP/M 2.2 works, sort of ...

Hi all! I've recently ported CP/M 2.2 to a new 64K, 8080 emulator. (By port=
ed I mean I downloaded the ASM source from http://www.cpm.z80.de/download/c=
pm2-plm.zip, assembled it with zasm-4, and wrapped it up with my custom BIO=
S into a bootable image.)

I boot it up and happily get the "a>" prompt. The "USER" command seems to b=
e fine. CTRL-C successfully warm boots, i.e. reloads tracks 0 and 1. Howeve=
r, any command that would go to the disk fails. "DIR" always reports "no fi=
les." The emulator supports code tracing, breakpoints, and execution step-i=
n/-over; I've stepped through the code from 'DIR'<ENTER> to "No files" and =
at no point does the code even attempt to hit the disk. To eliminate disk i=
mage format as one of the causes, I've been using "22src1" (from http://www=
..cpm.z80.de/download/22srcimg.zip) on drive B:; this is an ideal 77-track, =
1-head, 26-sector disk with a skew of 6.

I've tripled-checked my Disk Parameter Headers and my Disk Parameter Block =
- they're fine as best as I can tell. The BIOS is quite simple and heavily =
derived from http://www.gaby.de/cpm/manuals/archive/cpm22htm/axb.htm; and i=
t, too, has been checked, rechecked, and thoroughly tested. (None of this m=
eans I got it right, of course.)

I'm sure I haven't provided enough info, yet I'm hoping someone might have =
an idea of what I might try next.

Thanks!
- Liam
0
Liam
10/20/2016 7:13:02 PM
comp.os.cpm 3422 articles. 0 followers. Post Follow

5 Replies
268 Views

Similar Articles

[PageSpeed] 41

No idea about the disk you are using, but from your description what works and what not
it seems, that either the CCP is not working correct, or the disk image is corrupt at tracks 2+,
or it has a different format than implemented in your BIOS.

0
Udo
10/20/2016 7:38:34 PM
If you know how a standard 8" disk with skew 6 should look like use
fsed.cpm from cpmtools to look at the directory entries of the disk image.

Or install z80pack cpmsim, mount as disk b: and do a dir b: with
CP/M 2 from z80pack or look with zap under CP/M at the disk.
0
Udo
10/20/2016 7:52:19 PM
Thanks for the info! I've pulled down "cpmtools" and I'll be sure to poke '=
round a bit. They'll certainly be handy going forward.

I did, however, discover the cause of my issue. It was my emulator's implem=
entation of the 8080's SUB/SBB instructions. All was fine except when the s=
ubtrahend was 0; the carry bit was  being set (in SUB) and this would break=
 SBB. (Who would have thought that 003F - 0000 =E2=89=A0  FF3F.)

Finding this bug was quite an "adventure" ... stepping through command pars=
ing, table lookups, and FCB searches just to discover that the SUBHL routin=
e in the BDOS was getting back some funky math results. I've certainly walk=
ed away from this with a greater appreciation for the OS.
0
Liam
10/22/2016 12:14:43 PM
With this wrong subtraction the code will run off of course. After writing emulations for
such CPU's you might even more appreciate the silicon doing it with ca. 8000 transistors. 
0
Udo
10/22/2016 4:19:13 PM
> I did, however, discover the cause of my issue. It was my emulator's
> implementation of the 8080's SUB/SBB instructions. All was fine
> except when the subtrahend was 0; the carry bit was  being set (in
> SUB) and this would break SBB. (Who would have thought that 003F -
> 0000 ≠  FF3F.)

I'd also check the carry flag result on the compare and decrement
instructions.

There's an instruction exerciser program zexall.com for the Z80 and
cut-down versions 8080ex1.com, 8080ex2.com, and 8085ex1 for the
8080 and 8085.  Generally you will find the corresponding .MAC
source file along with it.  You should run these tests against a
new emulator like yours or a new hardware implementation.  This
will save you a lot of grief.  About the only thing that needs to
work as far as CP/M goes is console output, and you need some way
to load the program into memory an run it.  There's also 8080PRE.COM
which you run first to check out some of the really basic stuff.

I got the programs at: http://www.idb.me.uk/sunhillow/8080.html but
that URL doesn't seem to lead anywhere useful now.  I think it's
also available at https://github.com/begoon/i8080-core  as part of
a test suite for an emulator.

The 8080EX1.COM (or .HEX) is the one you want if you are emulating
an Intel 8080.  It runs 25 tests, runs about 2.9 billion instructions,
and generate a 32-bit CRC of the CPU state for each test.  The
8080EX1 version contains the "correct" CRCs for each test for an
Intel 8080.  (Note;  the "correct" answers change for an AMD 8080,
an 8085, or a Z80).  Each test either says "OK" or it gives the
"expected" and "found" CRCs.  If you get all tests 'OK', congratulations.
The tests are not exhaustive but they catch a lot of problems with
emulators and new hardware.  Things not tested: I/O instructions,
Interrupts, Halt instruction, 8085-only interrupt controller
instructions (RIM and SIM).

8080 instruction exerciser (KR580VM80A CPU)
dad <b,d,h,sp>................  OK
aluop nn......................  OK
aluop <b,c,d,e,h,l,m,a>.......  OK
<daa,cma,stc,cmc>.............  OK
<inr,dcr> a...................  OK
<inr,dcr> b...................  OK
<inx,dcx> b...................  OK
<inr,dcr> c...................  OK
<inr,dcr> d...................  OK
<inx,dcx> d...................  OK
<inr,dcr> e...................  OK
<inr,dcr> h...................  OK
<inx,dcx> h...................  OK
<inr,dcr> l...................  OK
<inr,dcr> m...................  OK
<inx,dcx> sp..................  OK
lhld nnnn.....................  OK
shld nnnn.....................  OK
lxi <b,d,h,sp>,nnnn...........  OK
ldax <b,d>....................  OK
mvi <b,c,d,e,h,l,m,a>,nn......  OK
mov <bcdehla>,<bcdehla>.......  OK
sta nnnn / lda nnnn...........  OK
<rlc,rrc,ral,rar>.............  OK
stax <b,d>....................  OK
Tests complete

This is what the result looks like if you run the 8085EX1 test on an
8080 (not 8085) emulator (This is expected to fail one test due to
different flag usage):

8085 instruction exerciser (Intel D8085AH-1 CPU)
dad <b,d,h,sp>................  OK
aluop nn......................  ERROR **** crc expected:98faf22b found:2b1ed911
<daa,cma,stc,cmc>.............  OK
<inr,dcr> a...................  OK
<inr,dcr> b...................  OK
<inx,dcx> b...................  OK
<inr,dcr> c...................  OK
<inr,dcr> d...................  OK
<inx,dcx> d...................  OK
<inr,dcr> e...................  OK
<inr,dcr> h...................  OK
<inx,dcx> h...................  OK
<inr,dcr> l...................  OK
<inr,dcr> m...................  OK
<inx,dcx> sp..................  OK
lhld nnnn.....................  OK
shld nnnn.....................  OK
lxi <b,d,h,sp>,nnnn...........  OK
ldax <b,d>....................  OK
mvi <b,c,d,e,h,l,m,a>,nn......  OK
mov <bcdehla>,<bcdehla>.......  OK
sta nnnn / lda nnnn...........  OK
<rlc,rrc,ral,rar>.............  OK
stax <b,d>....................  OK
Tests complete



Now the bad part: if you get an error (like I did with the DAA
instruction at first), these tests give you no clue what's wrong.
The test name indicates what instructions were tested, and you can
look at the test tables to find more details.

One approach is to split the test up into several.  The test table
uses bit-masks for determining what bits in the instruction under
test and various registers to vary.  For example, I split up the
test for <daa, cma, stc, and cmc> (the opcodes for these instructions
vary in only 2 bits) into 4 tests for the individual instructions
(DAA failed, the other 3 passed).  BUT: you need a known-good
emulator or hardware to run your new tests on to get "correct
answers" for them.

Note:  you may not actually *CARE* about the DAA instruction or the
half-carry flag, but the test checks it.  You can tell it to ignore
that flag, but if you change a test, you need a known-good emulator
or hardware to get a new "correct answer" for the test.

Another way is to construct a test which exercises the instructions
in question and prints the flags and registers that result.  Compare
against a known-good implementation or documentation.  This can
get pretty tedious.


> Finding this bug was quite an "adventure" ... stepping through
> command parsing, table lookups, and FCB searches just to discover
> that the SUBHL routine in the BDOS was getting back some funky math
> results. I've certainly walked away from this with a greater
> appreciation for the OS.

0
gordonb
11/3/2016 6:47:12 AM
Reply: