Yes, the ex af,af may well have been data being misinterpreted by the disassembly as code. All the more amazing that the simulation threads its way through without getting confused about data vs code, because it would only take one instruction that should be 2 bytes to be misinterpreted as 3 bytes for the whole thing to stop working.
One minor thing - that program run looks like it is running over and over. It is supposed to end and go back to cp/m A> after one print of "Hello World".
I'll see if I can find some more code to exercise it a bit more - eg floating point numbers and strings. Documentation is hard to come by, but there is a fairly good chance that sbasic is written entirely in 8080.
Well, I cheated a bit. I don't have a quick way to transfer files into the CP/M files system yet so I just dropped the program into the Z80 RAM space in HUB at $0100 from where it runs immediately. When it ends it does a warm boot or such and so ends up running again. All the IO goes through BDOS as normal though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Ah. So do you have all of CP/M sitting at the top of the 20k code space? If so, that will be capturing input from the keyboard which I guess is from the spin terminal code. In CP/M you type the name of a file and it goes through and just tests the word is not a keyword like TYPE or DIR, then if it isn't it loads the program into 0100 and does a jump to the beginning. So you have the ability to list files with a DIR, but not quite yet the ability to load those files into 0100? I won't say that is a trivial task because the N8VEM code to do that is actually quite a slab of the whole CP/M code, plus there is different code for different drives, eg the eprom drive and the ram drive. Looking at the triblade, I guess there would be a ram drive (may as well add it) and various SD drives up to the max 8mb that CP/M uses. A generic question, my understanding is that SD cards 'wear out', a bit like eeproms wear out with lots of writes? Maybe that isn't true but I'm figuring that for files where you store the file infrequently then the SD card would be the place to put it, and for files that are used often (eg text files that a program is reading in and out) then a ramdrive would be better. Do you have access to the source code for the CP/M the SIMH uses as well as the source code for the N8VEM CP/M?
SD memory cards have a processor inside that is supposed to do "wear levelling". There's extra space on the card that's used for keeping track of how often a section of the flash memory has been used. When a sector has been written a number of times, it's moved elsewhere in the flash memory to an area that hasn't been used and the processor keeps track of where it's been moved.
OK, my set up is a bit weird just now.
1. There is a CP/M file system on the SD card. Actually eight of them one for each floppy disk drive.
2. Drive A: contains all the files from the SIMH cpm2 boot disk plus a few extras I have put there. The other drives are empty but usable.
3. However currently I do not boot up from the SD card.
4. Instead, CPP, BDOS and BIOS are loaded into memory from files included into zicog_demo.spin. In effect the boot loader is in Spin.
5. When CP/M is running commands are ARE indeed read from SD card e.g. DIR, loaded to 100 and executed. See previous screen shots.
Funny you should mention TYPE and DIR. In my CP/M build (from SIMH) these commands are not built in to the CPP, DIR is read from disk, so you have to have a working disk before you can even try to see what is on it.
Now my problem is if I want to add a new program to drive A: I have to add it to a disk image, using SIMH, and load the new disk image into the SD card. This takes ten minutes to download so I don't do it often. I have no card reader/writer so I do this via serial download to the Prop which then writes the image to the SD card. Having a card reader would not help as I use only CP/M format on the card, no FAT. This will probably change in the future.
So to run your test I cheated and included it with the files loaded at boot time. Had I taken the time to build a new disk image with that program on it would be run as a normal CP/M command.
All the CP/M source code (CPP, BDOS, BIOS) is included in the SIMH cpm2 disk image. Just run up the AltairZ80 simulator on your PC using the cpm2 disk. At the cp/m prompt you can write files out from the disk to your host (Windows or Linux) using the "w" command. e.g. "w cpp.mac" gets you the source of cpp. There is a "r" command to read files back into CP/M.
I don't know what the life time of an SD card is but I'm sure that for normal "manual" usage it is longer than mine. I would only worry about it if I had a continuously running program that rapidly updates some file in which case a RAM drive would be better. To do this under ZiCog would only require a small change to he disk emulation. To do it on a normal CP/M machine would require changes to the BIOS.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I just managed to get enough Z80 ops working that he Z80 CPU exerciser program (from the SIMH project) at least starts up and runs without crashing the emulator.
As you can see all the tests FAIL.
There is only the first few tests on the screen each of which cycles through a few tens of test cases, there are actually 80 tests many of which have tens and hundreds of thousands of test cases. Could take many hours(days) to run.
There is a long road ahead.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
@heater, I've just put those exerciser programs on a real board. They are *very* slow - I think they were designed for testing the simh which emulates a 180Mhz machine. Have you seen the source code anywhere - it could be handy to both decrease the number of tests and also narrow down exactly which instruction is failing.
Down the track certainly a faster system is needed for running a program. I needed another N8VEM board for the wireless mesh project tonight, and it was 30 mins to solder the board, 3 mins to program an eprom (which has CP/M and xmodem on it), and then 5 mins to run a batch program to fill up a drive with about 20 files. I've got it all automated and down the track no doubt we can do the same for the triblade. 38400 baud means most CP/M files are under 30 seconds per file and some are only a few seconds.
You might be interested to see this printout - it seems crc errors are coming up on a real board too:
Attached is an sbasic program to do some maths and strings. Change the extension to a .COM as before. Code below:
rem Converts string to upper case
function ucase(mystring=string) = string
var i=integer
var outstring=string
var ch=byte
outstring=""
for i=1 to len(mystring)
ch=mid(mystring,i,1)
if ch>='a' and ch<='z' then ch=ch-32
outstring=outstring+chr(ch)
next i
end=outstring
rem ************ MAIN **************
var integertest=integer
var realtest=real
var stringtest=string
integertest=5
integertest=integertest+10
print "5+10=";integertest
realtest=2
realtest=realtest^.5
print "Square root of 2:";realtest
stringtest="Hello World"
print left$(stringtest,5)
print right$(stringtest,5)
print ucase(stringtest)
end
Post Edited (Dr_Acula (James Moxham)) : 3/12/2009 1:01:11 PM GMT
Dr_A, You have the wrong exerciser their use EXZ80DOC.COM
There are three versions of the exerciser, they are all built from the same source EX.MAC but with some changes made to an included file (I think the file included by EX.MAC is EC.LIB.
So to build it copy one of ECZ80ALL.LIB, ECZ80DOC.LIB or EC8080.LIB to EC.LIB and the assemble EX.MAC
ECZ80ALL is for testing all Z80 ops and all the flags documented or not.
ECZ80DOC is for Z80 ignoring undocumented flags
EC8080 is for 8080/8085.
You have the source already I guess.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Z80 instruction exerciser
Undefined status bits taken into account
<adc,sbc> hl,<bc,de,hl,sp>....( 71,680) cycles OK
add hl,<bc,de,hl,sp>..........( 35,840) cycles OK
add ix,<bc,de,ix,sp>..........( 35,840) cycles OK
add iy,<bc,de,iy,sp>..........( 35,840) cycles OK
aluop a,nn....................( 45,056) cycles OK
aluop a,<b,c,d,e,h,l,(hl),a>..(753,664) cycles ERROR **** crc expected:06c7aa8e found:1b9e9b5e
aluop a,<ixh,ixl,iyh,iyl>.....(376,832) cycles OK
aluop a,(<ix,iy>+1)...........(229,376) cycles OK
aluop a,(<ix,iy>-1)...........(229,376) cycles OK
bit n,(<ix,iy>+1).............( 2,048) cycles OK
bit n,(<ix,iy>-1).............( 2,048) cycles OK
bit n,<b,c,d,e,h,l,(hl),a>....( 49,152) cycles OK
cpd<r>........................( 6,144) cycles OK
cpi<r>........................( 6,144) cycles OK
<daa,cpl,scf,ccf>.............( 65,536) cycles ERROR **** crc expected:6d2dd213 found:2af51f3e
<inc,dec> a...................( 3,072) cycles OK
<inc,dec> b...................( 3,072) cycles OK
<inc,dec> bc..................( 1,536) cycles OK
<inc,dec> c...................( 3,072) cycles OK
<inc,dec> d...................( 3,072) cycles OK
<inc,dec> de..................( 1,536) cycles OK
<inc,dec> e...................( 3,072) cycles OK
<inc,dec> h...................( 3,072) cycles OK
<inc,dec> hl..................( 1,536) cycles OK
<inc,dec> ix..................( 1,536) cycles OK
<inc,dec> iy..................( 1,536) cycles OK
<inc,dec> l...................( 3,072) cycles OK
<inc,dec> (hl)................( 3,072) cycles OK
<inc,dec> sp..................( 1,536) cycles OK
<inc,dec> (<ix,iy>+1).........( 6,144) cycles OK
<inc,dec> (<ix,iy>-1).........( 6,144) cycles OK
<inc,dec> ixh.................( 3,072) cycles OK
<inc,dec> ixl.................( 3,072) cycles OK
<inc,dec> iyh.................( 3,072) cycles OK
<inc,dec> iyl.................( 3,072) cycles OK
<ini,outi,ind,outd><,r>.......( 65,536) cycles ERROR **** crc expected:47fff448 found:a48a703b
ld <bc,de>,(nnnn).............( 32) cycles OK
ld hl,(nnnn)..................( 16) cycles OK
ld sp,(nnnn)..................( 16) cycles OK
ld <ix,iy>,(nnnn).............( 32) cycles OK
ld (nnnn),<bc,de>.............( 64) cycles OK
ld (nnnn),hl..................( 16) cycles OK
ld (nnnn),sp..................( 16) cycles OK
ld (nnnn),<ix,iy>.............( 64) cycles OK
ld <bc,de,hl,sp>,nnnn.........( 64) cycles OK
ld <ix,iy>,nnnn...............( 32) cycles OK
ld a,<(bc),(de)>..............( 44) cycles OK
ld <b,c,d,e,h,l,(hl),a>,nn....( 64) cycles OK
ld (<ix,iy>+1),nn.............( 32) cycles OK
ld (<ix,iy>-1),nn.............( 32) cycles OK
ld <b,c,d,e>,(<ix,iy>+1)......( 512) cycles OK
ld <b,c,d,e>,(<ix,iy>-1)......( 512) cycles OK
ld <h,l>,(<ix,iy>+1)..........( 256) cycles OK
ld <h,l>,(<ix,iy>-1)..........( 256) cycles OK
ld a,(<ix,iy>+1)..............( 128) cycles OK
ld a,(<ix,iy>-1)..............( 128) cycles OK
ld <ixh,ixl,iyh,iyl>,nn.......( 32) cycles OK
ld <bcdehla>,<bcdehla>........( 3,456) cycles OK
ld <bcdexya>,<bcdexya>........( 6,912) cycles OK
ld a,(nnnn) / ld (nnnn),a.....( 44) cycles OK
ldd<r> (1)....................( 44) cycles OK
ldd<r> (2)....................( 44) cycles OK
ldi<r> (1)....................( 44) cycles OK
ldi<r> (2)....................( 44) cycles OK
neg...........................( 16,384) cycles OK
<rrd,rld>.....................( 7,168) cycles OK
<rlca,rrca,rla,rra>...........( 6,144) cycles OK
shf/rot (<ix,iy>+1)...........( 416) cycles OK
shf/rot (<ix,iy>-1)...........( 416) cycles OK
shf/rot <b,c,d,e,h,l,(hl),a>..( 6,784) cycles OK
<set,res> n,<bcdehl(hl)a>.....( 6,912) cycles OK
<set,res> n,(<ix,iy>+1).......( 448) cycles OK
<set,res> n,(<ix,iy>-1).......( 448) cycles OK
ld (<ix,iy>+1),<b,c,d,e>......( 1,024) cycles OK
ld (<ix,iy>-1),<b,c,d,e>......( 1,024) cycles OK
ld (<ix,iy>+1),<h,l>..........( 256) cycles OK
ld (<ix,iy>-1),<h,l>..........( 256) cycles OK
ld (<ix,iy>+1),a..............( 64) cycles OK
ld (<ix,iy>-1),a..............( 64) cycles OK
ld (<bc,de>),a................( 96) cycles OK
Some failure detected.
CP/M V2.2C
A>
You know, I had already been wondering.... In the source code of the EX test Frank Cringle states that the CRCs resulting from the tests are compared to CRC's he got running the same test on a real MOSTEK Z80. So I was wondering if a real original Zilog Z80 would be in any way different.
Looks like with the daa and alu op tests above that you may have found some differences. Are you running a Zilog chip?
Of course the third failure you have there concerns IN operations, well how can that be expected to pass except of the machine Frank used to create the CRC's
Anyway, if you are using a real Zilog Z80 I would like to use your CRC results in my tests. For authenticities sake, after all this is ZiCog not MoCog. Trouble is we now need to find out why they are different.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I'll double check when I get home from work. The only spanner in the works is that about 10 years ago I spent a king's ransom buying a number of Z80 chips from Radio Spares. They were very expensive, they were rated at 8Mhz and they were CMOS. These chips run cold.
Now, in the last year, I have a parts drawer full of about 20 new Z80 chips that I have bought from all over the world. Most are labelled Zilog. Some are 4Mhz, some are 6 and some are 8. All are supposed to be cmos. Some have identical part numbers to the chips from Radio Spares. But every single one runs warm.
I cannot seem to find a single new Z80 chip that will run cold, and what I am wondering is whether there are fake chips out there, and people just print "Zilog" on the chip and no-one cares.
What I can say though is that they all seem to run the software ok. That could be because none of the code I'm using actually uses DAA or depends on unusual flag configurations (the Zero flag is the one used most of the time).
I guess what we need is to get inside the exerciser program and see how it works.
Good news that you have got so many instructions working!
Addit: scratch that bit about the source code, I just found your post on the .mac files. The doc one is for undocumented instructions? I was guessing it was the documentation for the program. Ok, with the .mac file we can go to work and narrow down just the exercises that are failing. It will speed things up a bit too - that program run took more than half an hour.
Post Edited (Dr_Acula (James Moxham)) : 3/13/2009 12:07:48 AM GMT
I don't know about fake chips. There were/are many companies making Z80 clones. I read somewhere that half the Z80's in the world were not made by Zilog. Perhaps all these clones had their subtle differences. And perhaps someone has been relabelling clones as Zilogs.
Of course Zilog still exists and according to their web site we could get hold of new Z80 samples to try out !
No. The "DOC" version of EX is for testing the documented flag settings, the "ALL" also checks the undocumented flags. I made the same mistake as you thinking that DOC meant the program documentation.
However, some strange things, it is possible to access IX and IY as two pairs of 8 bit registers IXH, IXL, IYH and IYL. Much like H and L. Well this is an undocumented feature of the Z80 but there are tests for it in the "DOC" version. Of course ZiCog does not support this yet.
Did you know that the Z80 uses 16 bit addresses (from BC) for it's I/O instructions? Turns out the Sinclair ZX81 used this. Might have know Clive Sinclair was always using "odd" features of devices.
The EX program is very clever at what it does. Checking that millions of instruction/data combinations have the same result as a real chip. But it does make it hard to pin down exactly which instruction, flag whatever maybe causing a problem. Still it can be done by narrowing down the number of test cases generated, running the code on two different machines, Zilog and emulation say, and comparing the CRCs. You do have to have a reference machine to do this.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
OK here is what you could do with EX to find the difference between your "real" Zilog chip and the SIMH. Or I might do to track down hard problems in ZiCog:
1. Rebuild the EX test with the trace option set, see EX.MAC. This will print out the machine state, registers and a few bytes of memory, together with the current CRC value after EVERY test combination.
2. Comment out all tests in the tests list except one that you are interested in.
3.Run this modified EX on the real Z80 and SIMH. This will take a long while as output is through serial console port.
4.Capture the output to files.
5. Use diff (linx) or WinDiff to find where the results differ. There we will see exactly the instruction and test data that produces a different result.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Re 1) I'm not having much luck rebuilding ex.mac. I've changed the settings at startup but I'm getting fatal errors with M80. I think it might be this line MACLIB EXCONFIG.LIB because I can't find that file. Do you have a copy by any chance?
This version is set up to run a version of the SIMH AltairZ80 CPU diagnostic with output to PropTerminal. No SD card required here.
With a one line change (move a comment tick) in zicog_demo.spin (look for "OPTIONS" it will run a 20K CP/M up to the command prompt. With a CP/M file system on SD card CP/M commands, DIR etc, will work as well.
I have modified the SIMH diagnostic (and called it zicogtst.com) so as to exclude tests of undocumented instructions. It also performs tests in order of their execution time as the alu ops take forever.
The old T8080.COM cpu diagnostic is gone as it no longer passes now that we are implementing Z80 flag settings not 8080.
The zicogtst has a lot of failures still but results show that all Z80 addressing modes are handled correctly and all the increment/decrement instructions work. See attached screen shots.
Work continues on getting all the tests to pass but I'm getting a bit stuck with only 4 longs left in the COG. Moving the A reg back to HUB will free up some space as will getting rid of the "ROM" memory access function when Cluso has the external RAM working. There is not a lot left I can put into overlays.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I am just about to start·have started testing ZiCog v0.4 and I have a few questions.
I have changed the xtal to 5MHz and pll16.
I have uncommented the first instruction in options and it now works (Note there are 3 instructions not 2 and need to enable only 1) - currently run on Blade#3·so no SRAM conflicts.
What I/O pins do you use and where? The heartbeat/frequency counter uses one - I have to remove all so they do not conflict with the SRAM - will have to think about how we can get an indication back and use the LED (maybe we can connect the LED to one of the address pins to see it toggling)
I will have to copy the hub ram (the Z80 RAM) to the SRAM. I will just do this in spin - slow but easy - and I can do this before the Z80 cog is started.
Anything else you can think of ???
I notice you use PropTerminal. I haven't used this - I usually use PST, but expect PropTerminal will be required. Do you know if this releases the com port when it loses focus (like PST)? I will look this up. Found and answered. My test code sees mouse movements.
I note the Ram size in hub is only $4F00. Shouldn't this be $5000 ??
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
OK, you want to be brave and go straight to running CP/M from external RAM [noparse]:)[/noparse]
I assume you have written the external RAM access PASM routines, tested them somehow, and fitted them into zicog.spin.
I assume you have had a CP/M sign on message and prompt coming out on PropTerminal. That's as far as we get with out an SD card but good for now.
1. Uncomment the first option line only (yes the first one of three) in zicog_demo. As you have done.
2. Add something to zicog_demo to zero all your RAM first. The reason for this will be seen in a later experiment.
3. Add something to zicog_demo to copy the HUB RAM from ram_z80 length 20K into the external RAM at $0000
There should not be any need to worry about the addresses of CCP, BDOS etc at this stage as this RAM image should work the same from HUB or external.
4. Add something to zicog_demo to copy the HUB RAM from rom_z80 length $0100 (256) into external RAM at $FF00.
This is the bootstrap EEPROM image. It is not used for boot strapping here but at least one byte of it is accessed by the BIOS to determine which floppy disk to boot from. Things dont go well with out it.
It should just work now[noparse]:)[/noparse]
If not try this test:
1. Uncomment the two lines in zicog.spin that cause a break in execution after every instruction.
2. Run again.
3. Hitting a key should cause zicog to step on instruction as the attached image shows. First instruction at PC=0000 is jump (C3) to $4200. Second instruction at $4200 is jump (C3) to $4233 etc etc.
As for IO pins:
The heartbeat, can be removed for now.
The SD card pins. Can be removed. You should still get a CP/M prompt even if SD access fails.
The Prop loader pins as used by Propterminal.
Never noticed before but the RAM size is 256 bytes short. That's because in a 64K system the top 256 bytes are the bootstrap EPROM.
If you have any problems contact me by email. Save cluttering up the thread.
Good luck.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Clutter the thread! Clutter the thread!
I first learned ASM on a TRS-80 Model I... Forgot it all loooong ago, but love reading everything about the progress of this project!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"They may have computers, and other weapons of mass destruction." - Janet Reno
Update:
I have heaters code working on Blade #3 (no SRAM, so the heartbeat doesn't interfere with the SRAM)
Modified the code to remove the heartbeat and SD card interface (so no I/O pins are used) and running on Blade #2 (with SRAM)
Added copying and verifying the z80 ram/rom to the SRAM
Next: I am in the middle of modifying the code to run from SRAM. It will be a full 64KB version. Expect to complete this tonight my time.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Cluso needs some free LONGs in which to implement external RAM access on the TriBlade so:
1. The z80 A register has been moved back into HUB space. This slows everything by 1% or so but saves many LONGs.
2. The NEG instruction emulation is moved into an overlay.
Getting z80 accurate flag settings has been eating up the COG but I think we are nearly there.
In this version all alu ops (add, sub, or, xor etc) are passing the EXZ80DOC test. As are NEG and double adds (DAD B etc)
Cluso, In this version there are 13 free LONGs. Things are getting tight but pretty much everything I need to fix now will happen in the overlays where all the z80 stuff lives. I'm sure we can find another handful of longs if we really have to.
Do not try to use the CP/M files included in Zicog (or PropAltair) to create a 64K CP/M system they will not work. When the 20K version is running we will work on that.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Thanks heater. Today before I had to go out, I had the code loading into SRAM and single-stepping (SRAM write disabled) but it is failing because it is reading from 0000=C3, then 0001=00 (shoud be 4200=C3. Haven't had time to look, but could be where option may change what is in the ram after I have already loaded the sram - will check shortly. Hadn't disabled output on the cog after loading sram. Still error though 0000=C3, 0003=00, 0005=c3.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
This is a bit sad to admit but I confess to being able to read these numbers as instructions. C3 is jump. Then the next two bytes are the LSB and then MSB. So it will be C3 00 42 which is a jump to 4200 which is lower than the usual sorts of numbers which are up near the top of 64k of ram. Cluso99 - good to hear payment went thru and I'm looking forward to a board.
Comments
Yes, the ex af,af may well have been data being misinterpreted by the disassembly as code. All the more amazing that the simulation threads its way through without getting confused about data vs code, because it would only take one instruction that should be 2 bytes to be misinterpreted as 3 bytes for the whole thing to stop working.
One minor thing - that program run looks like it is running over and over. It is supposed to end and go back to cp/m A> after one print of "Hello World".
I'll see if I can find some more code to exercise it a bit more - eg floating point numbers and strings. Documentation is hard to come by, but there is a fairly good chance that sbasic is written entirely in 8080.
Looking forward to the boards...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
OK, my set up is a bit weird just now.
1. There is a CP/M file system on the SD card. Actually eight of them one for each floppy disk drive.
2. Drive A: contains all the files from the SIMH cpm2 boot disk plus a few extras I have put there. The other drives are empty but usable.
3. However currently I do not boot up from the SD card.
4. Instead, CPP, BDOS and BIOS are loaded into memory from files included into zicog_demo.spin. In effect the boot loader is in Spin.
5. When CP/M is running commands are ARE indeed read from SD card e.g. DIR, loaded to 100 and executed. See previous screen shots.
Funny you should mention TYPE and DIR. In my CP/M build (from SIMH) these commands are not built in to the CPP, DIR is read from disk, so you have to have a working disk before you can even try to see what is on it.
Now my problem is if I want to add a new program to drive A: I have to add it to a disk image, using SIMH, and load the new disk image into the SD card. This takes ten minutes to download so I don't do it often. I have no card reader/writer so I do this via serial download to the Prop which then writes the image to the SD card. Having a card reader would not help as I use only CP/M format on the card, no FAT. This will probably change in the future.
So to run your test I cheated and included it with the files loaded at boot time. Had I taken the time to build a new disk image with that program on it would be run as a normal CP/M command.
All the CP/M source code (CPP, BDOS, BIOS) is included in the SIMH cpm2 disk image. Just run up the AltairZ80 simulator on your PC using the cpm2 disk. At the cp/m prompt you can write files out from the disk to your host (Windows or Linux) using the "w" command. e.g. "w cpp.mac" gets you the source of cpp. There is a "r" command to read files back into CP/M.
I don't know what the life time of an SD card is but I'm sure that for normal "manual" usage it is longer than mine. I would only worry about it if I had a continuously running program that rapidly updates some file in which case a RAM drive would be better. To do this under ZiCog would only require a small change to he disk emulation. To do it on a normal CP/M machine would require changes to the BIOS.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I just managed to get enough Z80 ops working that he Z80 CPU exerciser program (from the SIMH project) at least starts up and runs without crashing the emulator.
As you can see all the tests FAIL.
There is only the first few tests on the screen each of which cycles through a few tens of test cases, there are actually 80 tests many of which have tens and hundreds of thousands of test cases. Could take many hours(days) to run.
There is a long road ahead.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Oh and heater - my laptops drop chars but I like it... iCog.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· 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·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
@heater, I've just put those exerciser programs on a real board. They are *very* slow - I think they were designed for testing the simh which emulates a 180Mhz machine. Have you seen the source code anywhere - it could be handy to both decrease the number of tests and also narrow down exactly which instruction is failing.
Down the track certainly a faster system is needed for running a program. I needed another N8VEM board for the wireless mesh project tonight, and it was 30 mins to solder the board, 3 mins to program an eprom (which has CP/M and xmodem on it), and then 5 mins to run a batch program to fill up a drive with about 20 files. I've got it all automated and down the track no doubt we can do the same for the triblade. 38400 baud means most CP/M files are under 30 seconds per file and some are only a few seconds.
You might be interested to see this printout - it seems crc errors are coming up on a real board too:
A>ex8080
Switched to 8080 processor.
8080 instruction exerciser
add hl,<bc,de,hl,sp>..........( 35,840) cycles OK
aluop a,nn....................( 45,056) cycles ERROR **** crc expected:3f92a27
3 found:d13cf741
aluop a,<b,c,d,e,h,l,(hl),a>..(753,664) cycles ...
So maybe your simulation is ok after all??
Attached is an sbasic program to do some maths and strings. Change the extension to a .COM as before. Code below:
rem Converts string to upper case function ucase(mystring=string) = string var i=integer var outstring=string var ch=byte outstring="" for i=1 to len(mystring) ch=mid(mystring,i,1) if ch>='a' and ch<='z' then ch=ch-32 outstring=outstring+chr(ch) next i end=outstring rem ************ MAIN ************** var integertest=integer var realtest=real var stringtest=string integertest=5 integertest=integertest+10 print "5+10=";integertest realtest=2 realtest=realtest^.5 print "Square root of 2:";realtest stringtest="Hello World" print left$(stringtest,5) print right$(stringtest,5) print ucase(stringtest) endPost Edited (Dr_Acula (James Moxham)) : 3/12/2009 1:01:11 PM GMT
There are three versions of the exerciser, they are all built from the same source EX.MAC but with some changes made to an included file (I think the file included by EX.MAC is EC.LIB.
So to build it copy one of ECZ80ALL.LIB, ECZ80DOC.LIB or EC8080.LIB to EC.LIB and the assemble EX.MAC
ECZ80ALL is for testing all Z80 ops and all the flags documented or not.
ECZ80DOC is for Z80 ignoring undocumented flags
EC8080 is for 8080/8085.
You have the source already I guess.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
When I rebuilt the EXZ80DOC I reordered all the tests to put the quickest ones first.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Undefined status bits taken into account
<adc,sbc> hl,<bc,de,hl,sp>....( 71,680) cycles OK
add hl,<bc,de,hl,sp>..........( 35,840) cycles OK
add ix,<bc,de,ix,sp>..........( 35,840) cycles OK
add iy,<bc,de,iy,sp>..........( 35,840) cycles OK
aluop a,nn....................( 45,056) cycles OK
aluop a,<b,c,d,e,h,l,(hl),a>..(753,664) cycles ERROR **** crc expected:06c7aa8e found:1b9e9b5e
aluop a,<ixh,ixl,iyh,iyl>.....(376,832) cycles OK
aluop a,(<ix,iy>+1)...........(229,376) cycles OK
aluop a,(<ix,iy>-1)...........(229,376) cycles OK
bit n,(<ix,iy>+1).............( 2,048) cycles OK
bit n,(<ix,iy>-1).............( 2,048) cycles OK
bit n,<b,c,d,e,h,l,(hl),a>....( 49,152) cycles OK
cpd<r>........................( 6,144) cycles OK
cpi<r>........................( 6,144) cycles OK
<daa,cpl,scf,ccf>.............( 65,536) cycles ERROR **** crc expected:6d2dd213 found:2af51f3e
<inc,dec> a...................( 3,072) cycles OK
<inc,dec> b...................( 3,072) cycles OK
<inc,dec> bc..................( 1,536) cycles OK
<inc,dec> c...................( 3,072) cycles OK
<inc,dec> d...................( 3,072) cycles OK
<inc,dec> de..................( 1,536) cycles OK
<inc,dec> e...................( 3,072) cycles OK
<inc,dec> h...................( 3,072) cycles OK
<inc,dec> hl..................( 1,536) cycles OK
<inc,dec> ix..................( 1,536) cycles OK
<inc,dec> iy..................( 1,536) cycles OK
<inc,dec> l...................( 3,072) cycles OK
<inc,dec> (hl)................( 3,072) cycles OK
<inc,dec> sp..................( 1,536) cycles OK
<inc,dec> (<ix,iy>+1).........( 6,144) cycles OK
<inc,dec> (<ix,iy>-1).........( 6,144) cycles OK
<inc,dec> ixh.................( 3,072) cycles OK
<inc,dec> ixl.................( 3,072) cycles OK
<inc,dec> iyh.................( 3,072) cycles OK
<inc,dec> iyl.................( 3,072) cycles OK
<ini,outi,ind,outd><,r>.......( 65,536) cycles ERROR **** crc expected:47fff448 found:a48a703b
ld <bc,de>,(nnnn).............( 32) cycles OK
ld hl,(nnnn)..................( 16) cycles OK
ld sp,(nnnn)..................( 16) cycles OK
ld <ix,iy>,(nnnn).............( 32) cycles OK
ld (nnnn),<bc,de>.............( 64) cycles OK
ld (nnnn),hl..................( 16) cycles OK
ld (nnnn),sp..................( 16) cycles OK
ld (nnnn),<ix,iy>.............( 64) cycles OK
ld <bc,de,hl,sp>,nnnn.........( 64) cycles OK
ld <ix,iy>,nnnn...............( 32) cycles OK
ld a,<(bc),(de)>..............( 44) cycles OK
ld <b,c,d,e,h,l,(hl),a>,nn....( 64) cycles OK
ld (<ix,iy>+1),nn.............( 32) cycles OK
ld (<ix,iy>-1),nn.............( 32) cycles OK
ld <b,c,d,e>,(<ix,iy>+1)......( 512) cycles OK
ld <b,c,d,e>,(<ix,iy>-1)......( 512) cycles OK
ld <h,l>,(<ix,iy>+1)..........( 256) cycles OK
ld <h,l>,(<ix,iy>-1)..........( 256) cycles OK
ld a,(<ix,iy>+1)..............( 128) cycles OK
ld a,(<ix,iy>-1)..............( 128) cycles OK
ld <ixh,ixl,iyh,iyl>,nn.......( 32) cycles OK
ld <bcdehla>,<bcdehla>........( 3,456) cycles OK
ld <bcdexya>,<bcdexya>........( 6,912) cycles OK
ld a,(nnnn) / ld (nnnn),a.....( 44) cycles OK
ldd<r> (1)....................( 44) cycles OK
ldd<r> (2)....................( 44) cycles OK
ldi<r> (1)....................( 44) cycles OK
ldi<r> (2)....................( 44) cycles OK
neg...........................( 16,384) cycles OK
<rrd,rld>.....................( 7,168) cycles OK
<rlca,rrca,rla,rra>...........( 6,144) cycles OK
shf/rot (<ix,iy>+1)...........( 416) cycles OK
shf/rot (<ix,iy>-1)...........( 416) cycles OK
shf/rot <b,c,d,e,h,l,(hl),a>..( 6,784) cycles OK
<set,res> n,<bcdehl(hl)a>.....( 6,912) cycles OK
<set,res> n,(<ix,iy>+1).......( 448) cycles OK
<set,res> n,(<ix,iy>-1).......( 448) cycles OK
ld (<ix,iy>+1),<b,c,d,e>......( 1,024) cycles OK
ld (<ix,iy>-1),<b,c,d,e>......( 1,024) cycles OK
ld (<ix,iy>+1),<h,l>..........( 256) cycles OK
ld (<ix,iy>-1),<h,l>..........( 256) cycles OK
ld (<ix,iy>+1),a..............( 64) cycles OK
ld (<ix,iy>-1),a..............( 64) cycles OK
ld (<bc,de>),a................( 96) cycles OK
Some failure detected.
CP/M V2.2C
A>
You know, I had already been wondering.... In the source code of the EX test Frank Cringle states that the CRCs resulting from the tests are compared to CRC's he got running the same test on a real MOSTEK Z80. So I was wondering if a real original Zilog Z80 would be in any way different.
Looks like with the daa and alu op tests above that you may have found some differences. Are you running a Zilog chip?
Of course the third failure you have there concerns IN operations, well how can that be expected to pass except of the machine Frank used to create the CRC's
Anyway, if you are using a real Zilog Z80 I would like to use your CRC results in my tests. For authenticities sake, after all this is ZiCog not MoCog. Trouble is we now need to find out why they are different.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I'll double check when I get home from work. The only spanner in the works is that about 10 years ago I spent a king's ransom buying a number of Z80 chips from Radio Spares. They were very expensive, they were rated at 8Mhz and they were CMOS. These chips run cold.
Now, in the last year, I have a parts drawer full of about 20 new Z80 chips that I have bought from all over the world. Most are labelled Zilog. Some are 4Mhz, some are 6 and some are 8. All are supposed to be cmos. Some have identical part numbers to the chips from Radio Spares. But every single one runs warm.
I cannot seem to find a single new Z80 chip that will run cold, and what I am wondering is whether there are fake chips out there, and people just print "Zilog" on the chip and no-one cares.
What I can say though is that they all seem to run the software ok. That could be because none of the code I'm using actually uses DAA or depends on unusual flag configurations (the Zero flag is the one used most of the time).
I guess what we need is to get inside the exerciser program and see how it works.
Good news that you have got so many instructions working!
Addit: scratch that bit about the source code, I just found your post on the .mac files. The doc one is for undocumented instructions? I was guessing it was the documentation for the program. Ok, with the .mac file we can go to work and narrow down just the exercises that are failing. It will speed things up a bit too - that program run took more than half an hour.
Post Edited (Dr_Acula (James Moxham)) : 3/13/2009 12:07:48 AM GMT
Of course Zilog still exists and according to their web site we could get hold of new Z80 samples to try out !
No. The "DOC" version of EX is for testing the documented flag settings, the "ALL" also checks the undocumented flags. I made the same mistake as you thinking that DOC meant the program documentation.
However, some strange things, it is possible to access IX and IY as two pairs of 8 bit registers IXH, IXL, IYH and IYL. Much like H and L. Well this is an undocumented feature of the Z80 but there are tests for it in the "DOC" version. Of course ZiCog does not support this yet.
Did you know that the Z80 uses 16 bit addresses (from BC) for it's I/O instructions? Turns out the Sinclair ZX81 used this. Might have know Clive Sinclair was always using "odd" features of devices.
The EX program is very clever at what it does. Checking that millions of instruction/data combinations have the same result as a real chip. But it does make it hard to pin down exactly which instruction, flag whatever maybe causing a problem. Still it can be done by narrowing down the number of test cases generated, running the code on two different machines, Zilog and emulation say, and comparing the CRCs. You do have to have a reference machine to do this.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
OK here is what you could do with EX to find the difference between your "real" Zilog chip and the SIMH. Or I might do to track down hard problems in ZiCog:
1. Rebuild the EX test with the trace option set, see EX.MAC. This will print out the machine state, registers and a few bytes of memory, together with the current CRC value after EVERY test combination.
2. Comment out all tests in the tests list except one that you are interested in.
3.Run this modified EX on the real Z80 and SIMH. This will take a long while as output is through serial console port.
4.Capture the output to files.
5. Use diff (linx) or WinDiff to find where the results differ. There we will see exactly the instruction and test data that produces a different result.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
PIP EXCONFIG.LIB=ECZ80DOC.LIB
Actually what I did was to remove the use of that file all together and put the equates in EX.MAC and renamed it ZICOGTST.MAC
When assembling this on a SIMH cpm2 disk it fails with DISK FULL so I had to make more room.
Attached shows ZiCog is making some progress on passing those tests. All loads and stores, but at least the addressing modes are working nicely.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· 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·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
This version is set up to run a version of the SIMH AltairZ80 CPU diagnostic with output to PropTerminal. No SD card required here.
With a one line change (move a comment tick) in zicog_demo.spin (look for "OPTIONS" it will run a 20K CP/M up to the command prompt. With a CP/M file system on SD card CP/M commands, DIR etc, will work as well.
I have modified the SIMH diagnostic (and called it zicogtst.com) so as to exclude tests of undocumented instructions. It also performs tests in order of their execution time as the alu ops take forever.
The old T8080.COM cpu diagnostic is gone as it no longer passes now that we are implementing Z80 flag settings not 8080.
The zicogtst has a lot of failures still but results show that all Z80 addressing modes are handled correctly and all the increment/decrement instructions work. See attached screen shots.
Work continues on getting all the tests to pass but I'm getting a bit stuck with only 4 longs left in the COG. Moving the A reg back to HUB will free up some space as will getting rid of the "ROM" memory access function when Cluso has the external RAM working. There is not a lot left I can put into overlays.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I am just about to start·have started testing ZiCog v0.4 and I have a few questions.
I have changed the xtal to 5MHz and pll16.
I have uncommented the first instruction in options and it now works (Note there are 3 instructions not 2 and need to enable only 1) - currently run on Blade#3·so no SRAM conflicts.
What I/O pins do you use and where? The heartbeat/frequency counter uses one - I have to remove all so they do not conflict with the SRAM - will have to think about how we can get an indication back and use the LED (maybe we can connect the LED to one of the address pins to see it toggling)
I will have to copy the hub ram (the Z80 RAM) to the SRAM. I will just do this in spin - slow but easy - and I can do this before the Z80 cog is started.
Anything else you can think of ???
I notice you use PropTerminal. I haven't used this - I usually use PST, but expect PropTerminal will be required. Do you know if this releases the com port when it loses focus (like PST)? I will look this up. Found and answered. My test code sees mouse movements.
I note the Ram size in hub is only $4F00. Shouldn't this be $5000 ??
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· 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·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Post Edited (Cluso99) : 3/17/2009 1:26:40 PM GMT
OK, you want to be brave and go straight to running CP/M from external RAM [noparse]:)[/noparse]
I assume you have written the external RAM access PASM routines, tested them somehow, and fitted them into zicog.spin.
I assume you have had a CP/M sign on message and prompt coming out on PropTerminal. That's as far as we get with out an SD card but good for now.
1. Uncomment the first option line only (yes the first one of three) in zicog_demo. As you have done.
2. Add something to zicog_demo to zero all your RAM first. The reason for this will be seen in a later experiment.
3. Add something to zicog_demo to copy the HUB RAM from ram_z80 length 20K into the external RAM at $0000
There should not be any need to worry about the addresses of CCP, BDOS etc at this stage as this RAM image should work the same from HUB or external.
4. Add something to zicog_demo to copy the HUB RAM from rom_z80 length $0100 (256) into external RAM at $FF00.
This is the bootstrap EEPROM image. It is not used for boot strapping here but at least one byte of it is accessed by the BIOS to determine which floppy disk to boot from. Things dont go well with out it.
It should just work now[noparse]:)[/noparse]
If not try this test:
1. Uncomment the two lines in zicog.spin that cause a break in execution after every instruction.
mov OVERLAY_PAR, break_ovl_ '\\ copy break_ovl's parameters call #OVERLAY_LOAD '// load & execute break_ovl2. Run again.
3. Hitting a key should cause zicog to step on instruction as the attached image shows. First instruction at PC=0000 is jump (C3) to $4200. Second instruction at $4200 is jump (C3) to $4233 etc etc.
As for IO pins:
The heartbeat, can be removed for now.
The SD card pins. Can be removed. You should still get a CP/M prompt even if SD access fails.
The Prop loader pins as used by Propterminal.
Never noticed before but the RAM size is 256 bytes short. That's because in a 64K system the top 256 bytes are the bootstrap EPROM.
If you have any problems contact me by email. Save cluttering up the thread.
Good luck.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I first learned ASM on a TRS-80 Model I... Forgot it all loooong ago, but love reading everything about the progress of this project!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"They may have computers, and other weapons of mass destruction." - Janet Reno
I have heaters code working on Blade #3 (no SRAM, so the heartbeat doesn't interfere with the SRAM)
Modified the code to remove the heartbeat and SD card interface (so no I/O pins are used) and running on Blade #2 (with SRAM)
Added copying and verifying the z80 ram/rom to the SRAM
Next: I am in the middle of modifying the code to run from SRAM. It will be a full 64KB version. Expect to complete this tonight my time.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· 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·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Attached is zicog v0.5.
Cluso needs some free LONGs in which to implement external RAM access on the TriBlade so:
1. The z80 A register has been moved back into HUB space. This slows everything by 1% or so but saves many LONGs.
2. The NEG instruction emulation is moved into an overlay.
Getting z80 accurate flag settings has been eating up the COG but I think we are nearly there.
In this version all alu ops (add, sub, or, xor etc) are passing the EXZ80DOC test. As are NEG and double adds (DAD B etc)
Cluso, In this version there are 13 free LONGs. Things are getting tight but pretty much everything I need to fix now will happen in the overlays where all the z80 stuff lives. I'm sure we can find another handful of longs if we really have to.
Do not try to use the CP/M files included in Zicog (or PropAltair) to create a 64K CP/M system they will not work. When the 20K version is running we will work on that.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· 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·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Post Edited (Cluso99) : 3/18/2009 10:01:04 AM GMT
Suggest putting something in zicog_demo.spin to read and print out the first few bytes of ext RAM after it is loaded but before starting the CPU.
You should see from address zero up:
C3, 00, 42, 00, 00, C3, 00, 34, 00, 00, 00.......
It's all zeros up until address 0100 where we get the zicogtst code:
C3, 65, 01......
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Now implementing wih v0.5 - standy...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· 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·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Yep, gets to you after a while.
We are starting off with a known working CP/M build in 20K, so the address is a bit low, when that flies we'll go the Full Monty.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.