@heater, I have BBC Basic running on the N8VEM but it won't run on the Zicog. I think it does use some unimplemented Z80 instructions (unlike Mbasic and wordstar which are really 8080 only).
I fired up my assembler and have been single stepping through the code. Unfortunately the debugger I wrote that prints out the registers is not working itself. I very much suspect some IX and IY code. I have narrowed it down by getting it to print dots to the screen as it does each instruction.
Somewhere in here it is failing:
LD IY,POWER10TABLE
LD IX,BINASCII ; ALWAYS PUT ANSWER HERE
DECASC1:
XOR A
LD E,(IY)
LD D,(IY+1)
DECASC2:
OR A
SBC HL,DE
So there are still some teething issues with very simple things before moving on to BBC Basic.
DDTZ is not working either which makes it harder to debug Z80 opcodes. I need some way of getting a debug working to be able to trace the instructions!
@heater, ok I got some code working to print out the registers and wrote it all in 8080 opcodes so it doesn't upset things.
I've narrowed it down to one instruction:
LD IX,5000
This doesn't fail straight away but it does cause a crash in a DIR after this has been run. ? the overlay code isn't being put back properly afterwards or something.
Drac: Use your second serial port to output (debug) each instruction before it executes and log it. Of course now you will likely find (murphy is lurking) it may have been an earlier instruction which failed to execute correctly.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Mr Russel was a bit of a genious on Z80 coding, so do not get surprized if you find an undocumented op-code.
He produces a SBC (1980 ish), before the BBC computer was out, he was sad that the Acorn built (Proton) BBC computer used 6502 types, hence the Z80 expansion board. It was used mostly/only by BBC engineers. On good shifts when nothing was going wrong the snooker games were narated by coding talk, happy days.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Out of this I've got some nifty assembly routines to print out registers and hence debug any instruction we want to throw at it. I'll keep experimenting as I want to find the problem with DDTZ and BBC basic.
Toby might be interested to know that Mr Russell is actively contributing to a thread on BBC basic at the moment over at comp.os.cpm
The problem is with the zicog, not with BBC basic, as BBC Basic runs fine on the N8VEM.
Maybe I'm being a bit cruel to the Zicog, but right now I'm trying to break it by throwing every CP/M program I can find at it!
Ok now we have a tough nut to crack. I'd like to see BBC BASIC running. What with being a true Brit and all that.
If Mr Russel is doing clever things with Z80 ops we need to find them. I just realized that not all ZiCog unimplemented ops result in a BREAK and a register dump.
Some of them just have zeros in the dispatch table and fly off into the blue yonder !
I'll try and get them all trapped then we can more easily see what we are up against.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Toby: There is only 2 pins available. An alternative to serial is 1-pin video and 1-pin keyboard. You cannot use the video pin for the keyboard during sync (if that is what you mean) as it will upset the sync.
I have been looking at the keyboard driver. I am not liking the chances of a 1-pin solution. Both the data and clock lines are bi-directional. I had thought the clock was only provided by the host.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Sorry, just being silly, again. I would be interested in that vid driver to see what the quality is, but if it can hack 80 columns it cant be too bad
Just etched a double sided PCB for a Dracblade. I had forgoten that as the copper is on both sides then the ironing on of the toner is actually better as there is no curve. No thru holes though so I might have to solder in the chips. I hate commitment. I'm using your trick of chips on the back of the board.
The KBD clocking is bi-dir but I think ther is a "simple mode" where the kbd gives data but the status ( leds etc ) on the kbd cannot be set. I am sure that is how Bascom AVR does it, using 2 pins still.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Post Edited (Toby Seckshund) : 12/6/2009 5:55:59 PM GMT
It seems that you have to issue a reset to the keyboard before it works. I wonder if any knows for sure. A reset is also sent to the keyboard in case of error. Guess I will have to try this, but this will have to wait till I go back to Sydney as this is where my keyboards are.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Re keyboards, on one version of the N8VEM I tried to be clever and only do data reads but it didn't work. I can't recall the exact reason why - I could live without the caps lock but it was something else - it might have been the reset. In any case it will be a matter of experimenting.
@Toby, if you are getting those thin tracks on a homebrew board, that is very impressive! (or I could send you a bought one for $10, but that wouldn't be nearly so fun)
Re BBC Basic, heater et al, can you get this onto your board? I'm at work for a while, but from memory I think it is giving a register dump so that ought to make debugging a bit easier. Just need to find what the opcode is. It was fairly close to 0100 also from memory. Normally you would fire up DDTZ and load in the program and trace it through but DDTZ isn't working either. So maybe need to rename the .COM to a .HEX and find the bytes in a hex editor?
www.bbcbasic.co.uk/bbcbasic.html generic CP/M version. @heater in particular, if you download that package there is a file BBdist.mac. It isn't the full source, but it is a small custom program that is part of the big program and it has a lot of Z80 instructions that I don't think have been given much of a workout on other programs.
@heater, ok this is getting very technical, but the bottom line is that zicog doesn't run Z80 yet and needs some more exhaustive testing.
DDTZ doesn't work to debug Z80 instructions because I think it itself uses Z80 instructions.
I tried running BBCBasic under 8080 DDT and it has a few jumps then ends up at 118H with the instruction DDE5
A quick scan through the op codes shows DD are IX related but I couldn't find E5. E3 was the closest. So first thing needed is a list of opcodes and instructions sorted by opcodes.
Next is some source code. There are some .lbr and .ark files related to DDTZ on the walnut creek archive but I'm not sure if they actually contain the source code. A tantalising search on google reveals a .mac is out there. Debugging DDTZ first might be a step as that is needed to debug other programs.
Or do we do this another way and look at that exerciser program? Can we isolate just the IX instructions in some way - maybe put them at the beginning so it at least passes or fails without spending all night running the program? Do you have the source for the exerciser by any chance?
Here is something cool though - there is so much room on the sd card you can put .arc files on there and not run out of space like on the N8VEM. Intriguingly, .ARC (and .ARK renamed as .ARC) files will unzip using Winzip. I can see a .mac file in there. And cool that winzip on an XP machine is still supporting legacy CP/M archive formats. Ok, time to get these onto the dracblade and see if I can get the ddtz source code...
Ok, got the source code for DDTZ. It is in 8080 assembler. I've not managed to find an instruction manual though and it is printing out 8080 opcodes so maybe it is DDT in disguise?
Meanwhile, BBCBasic is falling over at hex location 122H with this dump
A>bbcbasic
PC=0122 AF=0300 BC=E00C DE=014F HL=E3EF IX=0000 IY=0000 SP=E39D
Spacebar for next instruction
which is instruction F5 which is Push AF and the hex bytes are F5 08 CD 05 00 etc
Attached is a document containing Z80 op codes I found somewhere and .txt listing that I derived from something.
Here we see that DD E5 is PUSH IX. We do actually have a DD E5. It's in the dispatch_table_dd and looks like it tries to do a get_ixy and a push. Where "get_ixy" should get IX as it knows which reg to use form the dispatch table it is in.
What documentation are you using that does not have a PUSH IX. Is this another of those commonly used Z80 features that was not documented originally?
Strangely EXZ80DOC does not have tests for any kind of PUSHs and POPs. Nor does it have tests for CALLs and JUMPs.
The source for the exerciser is in the ZIPM2 disk images. It is EX.MAC. It can be built for 8080/z80 by including different .LIB files. There is a submit file that compiles all the versions.
The last one I posted had a modified version with all the quick tests done first and the failing ones at the end. I commented the failing tests in that source.
Thing is the EX program is not so helpful at finding out why an op fails. You see for each test that you see a pass/fail result for, it is actually running hundreds/thousands of test cases including variations of the op-code and lots of different register/memory values. It then adds the result of each little test into a CRC. Having done a batch like that it compares the CRC with what was obtained on a real Z80. So if a test fails you still don't know which of the hundreds/thousands of little test steps it was.
Still it points us in the general direction.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I just couldn't get the faith to solder the prop directly into the PCB. As my ironing doesn't acheive through hole plating I have snuck a wire from topside to bottom in the 6 or so "feed throughs). Also as with all good pics this is the preaty side.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
When I started to do the ironing, I jested, to HER, that perhaps I should power up two irons ( his + HER's ) one for each side. SHE asked if I would like another iron for Xmas, which was a reference to the time when I put an iron, wrapped up under the tree. How SHE laughted ... After A+E got it back it still worked good enough for the PCBs.
Side alighnment was about 10 mils just by using a couple of pins. Next time I will try to put one hole in the PCB as well. The twin iron may be better as the two layers may stick down with less movements.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Hi heater, yes we do need some sort of program that exercises each instruction even if it is only just once per instruction.
Failing that, I guess it is just a matter of tediously going through each one and testing an example of each. I started doing that and managed to find one almost straight away - EX AF, AF'. This crashes the zicog. Opcode 08
Propfest on the Gold Coast last night! Met up with Tubular - great evening. Shame Peter was o/s.
Off to check the mailbox - RamBlade pcb??? Although express posted yesterday (1 day service) I know from experience it often takes more - fingers crossed [noparse]:)[/noparse]
OT: Well my iron (used wife's iron when she got a newbie) has wax all over it and has been taken by the kids - use it to wax the skiis.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
@cluso - did heater miss out on yet another propfest? Is he leaving the invitations on a bus or something?
@heater, I found a program to test out some opcodes. See attached. Might need a few tweaks depending on what compiler you are using. I'm going to add the code to print out a few registers so can then put 'call registers' after each instruction.
Addit: I now have the IDE working so an edit/compile is only 5 seconds and is a single keypress. Debugging is much faster now. The compiler compiles with no errors. Can print out registers with the attached code.
Found another error.
LD (IX+7),24
compiles to
DD 36 07 18 ; hex values
Errors sometimes don't show up instantly, but they do show up if you call a dodgy instruction twice in a row.
So - EX AF, AF' and LD (IX+n),n have problems so far.
The missing EX and EXX instructions has been noted here a few time, I guess these details get lost in all the tooing and frowing that goes on in these threads.
Strangely enough EX and EXX are another couple of ops that EXZ80DOC does not test.
EX and EXX should not crash ZiCog exactly. They should cause it to perform a break and a register dump. Did it do that ?
When originally starting out on the old PropAltair emulator I did exactly create a program that exercised each instruction with a couple of different operands and checked resulting flags. That program grew and grew as I added more ops to the emulation. A gave up on it when starting out on Z80 ops, it was becoming a nightmare. It checked 8080 flags settings anyway which are different so it was broken for Z80. So I moved on to EXZ80DOC as a regression test.
The first step in finding out which ops don't work is to look in the zicog.spin code.
Many ops that are not implemented have "not_implemented" as there entry in the dispatch tables. Just search for "not_implemented", the opcode value is shown in comments on the left side of the table entries.
Next are the ops that as far as I know were not documented in the original Z80. Again these are easy to find as they have "undocumented" as their entry in the dispatch tables. There are quite many of these, a few of them do turn up in some later op-code lists I have seen.
"undocumented" is actually a label on the same point in the code as "not_implemented" so all these should also stop with a break and a register dump.
Thirdly there are a bunch of block operation instructions that are handled by overlays. The ones that are not functional, like CPD, have the overlay in place but it contains no code. For example look at for the overlay with label cpd_ovl. These ops will at least run through without doing anything. But of course any program using them will probably crash afterwards.
Fourthly there are some Z80 bit operations that, erroneously, don't have "unimplemented" in the dispatch tables. Instead they have zeros so they WILL crash ZiCog without a register dump. This includes all the ops you see under "dispatch_table_ddcb".
Lastly at the end of the list of tests in EXZ80DOC.MAC I have commented all the failing tests.
First simple thing to do is get all those ops described in "Thirdly" and "Fourthly" above to jump to "not_implemented" so that they stop politely with a register dump. Then run BBC BASIC or whatever and see where it stops.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Thanks heater. I rewrote the error message so it means a bit more "Unimplemented instruction at location PC, spacebar to continue" and on the dracblade dumped it to both the terminal and also the local VGA. Much easier to debug.
EXX does do the jump from the table but no code is there
EX AF, AF' is not implemented
{08} long not_implemented
How does one go about adding these? via overlays (given no longs left)
Oops yep, sorry I was wrong about EXX, but you get the idea anyway.
How does one go about adding these?
Hmmm....There are reasons most of these are not in place.
1) No room in the COG.
2) No room for more overlays in HUB.
3) I ran out of time and energy...
Problem 1) remains, especially for DracBlade and Hydra I guess which need more LONGS for EXT RAM access.
Problem 2) is to do with wanting max HUB space for CP/M on the DemoBoard. This problem does not exist for future versions of ZiCog as we will cease maintaining the DemoBoard CP/M variant. So we should have HUB space for more overlays.
Problem 3) is still around...
If you want to have a go at implementing an op in an overlay best cut and paste an existing overlay and its set up and table entries. For example search for "daa_ovl" to see what's involved.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Comments
I fired up my assembler and have been single stepping through the code. Unfortunately the debugger I wrote that prints out the registers is not working itself. I very much suspect some IX and IY code. I have narrowed it down by getting it to print dots to the screen as it does each instruction.
Somewhere in here it is failing:
LD IY,POWER10TABLE LD IX,BINASCII ; ALWAYS PUT ANSWER HERE DECASC1: XOR A LD E,(IY) LD D,(IY+1) DECASC2: OR A SBC HL,DESo there are still some teething issues with very simple things before moving on to BBC Basic.
DDTZ is not working either which makes it harder to debug Z80 opcodes. I need some way of getting a debug working to be able to trace the instructions!
Back to coding...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
I've narrowed it down to one instruction:
LD IX,5000This doesn't fail straight away but it does cause a crash in a DIR after this has been run. ? the overlay code isn't being put back properly afterwards or something.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
LD D,(IY+1)
looks suspiciously like the culprit here.
I would have thought regular indexed addressing is tested by EXZ80DOC so:
LD E,(IY)
Should be OK, and
LD IX,5000
Should be covered.
I could be totally wrong and will have to check this. Can you give us the exact op codes?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
He produces a SBC (1980 ish), before the BBC computer was out, he was sad that the Acorn built (Proton) BBC computer used 6502 types, hence the Z80 expansion board. It was used mostly/only by BBC engineers. On good shifts when nothing was going wrong the snooker games were narated by coding talk, happy days.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
This little bit of code passes the test
LD IX,5000 LD E,64 LD (IX+0),E CALL REGISTERS LD E,0 CALL REGISTERS LD E,(IX+0) CALL REGISTERSOut of this I've got some nifty assembly routines to print out registers and hence debug any instruction we want to throw at it. I'll keep experimenting as I want to find the problem with DDTZ and BBC basic.
Toby might be interested to know that Mr Russell is actively contributing to a thread on BBC basic at the moment over at comp.os.cpm
The problem is with the zicog, not with BBC basic, as BBC Basic runs fine on the N8VEM.
Maybe I'm being a bit cruel to the Zicog, but right now I'm trying to break it by throwing every CP/M program I can find at it!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
If Mr Russel is doing clever things with Z80 ops we need to find them. I just realized that not all ZiCog unimplemented ops result in a BREAK and a register dump.
Some of them just have zeros in the dispatch table and fly off into the blue yonder !
I'll try and get them all trapped then we can more easily see what we are up against.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I have 80x24 1-pin monochrome TV running
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
I have been looking at the keyboard driver. I am not liking the chances of a 1-pin solution. Both the data and clock lines are bi-directional. I had thought the clock was only provided by the host.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Just etched a double sided PCB for a Dracblade. I had forgoten that as the copper is on both sides then the ironing on of the toner is actually better as there is no curve. No thru holes though so I might have to solder in the chips. I hate commitment. I'm using your trick of chips on the back of the board.
The KBD clocking is bi-dir but I think ther is a "simple mode" where the kbd gives data but the status ( leds etc ) on the kbd cannot be set. I am sure that is how Bascom AVR does it, using 2 pins still.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Post Edited (Toby Seckshund) : 12/6/2009 5:55:59 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
@Toby, if you are getting those thin tracks on a homebrew board, that is very impressive! (or I could send you a bought one for $10, but that wouldn't be nearly so fun)
Re BBC Basic, heater et al, can you get this onto your board? I'm at work for a while, but from memory I think it is giving a register dump so that ought to make debugging a bit easier. Just need to find what the opcode is. It was fairly close to 0100 also from memory. Normally you would fire up DDTZ and load in the program and trace it through but DDTZ isn't working either. So maybe need to rename the .COM to a .HEX and find the bytes in a hex editor?
www.bbcbasic.co.uk/bbcbasic.html generic CP/M version. @heater in particular, if you download that package there is a file BBdist.mac. It isn't the full source, but it is a small custom program that is part of the big program and it has a lot of Z80 instructions that I don't think have been given much of a workout on other programs.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
DDTZ doesn't work to debug Z80 instructions because I think it itself uses Z80 instructions.
I tried running BBCBasic under 8080 DDT and it has a few jumps then ends up at 118H with the instruction DDE5
A quick scan through the op codes shows DD are IX related but I couldn't find E5. E3 was the closest. So first thing needed is a list of opcodes and instructions sorted by opcodes.
Next is some source code. There are some .lbr and .ark files related to DDTZ on the walnut creek archive but I'm not sure if they actually contain the source code. A tantalising search on google reveals a .mac is out there. Debugging DDTZ first might be a step as that is needed to debug other programs.
Or do we do this another way and look at that exerciser program? Can we isolate just the IX instructions in some way - maybe put them at the beginning so it at least passes or fails without spending all night running the program? Do you have the source for the exerciser by any chance?
Here is something cool though - there is so much room on the sd card you can put .arc files on there and not run out of space like on the N8VEM. Intriguingly, .ARC (and .ARK renamed as .ARC) files will unzip using Winzip. I can see a .mac file in there. And cool that winzip on an XP machine is still supporting legacy CP/M archive formats. Ok, time to get these onto the dracblade and see if I can get the ddtz source code...
Ok, got the source code for DDTZ. It is in 8080 assembler. I've not managed to find an instruction manual though and it is printing out 8080 opcodes so maybe it is DDT in disguise?
Meanwhile, BBCBasic is falling over at hex location 122H with this dump
which is instruction F5 which is Push AF and the hex bytes are F5 08 CD 05 00 etc
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 12/7/2009 1:18:18 PM GMT
The are many Z80 op code pages on the net I have been using this one [noparse][[/noparse]url]http://nemesis.lonestar.org/computers/tandy/software/apps/m4/qd/opcodes.html[noparse][[/noparse]url]
Attached is a document containing Z80 op codes I found somewhere and .txt listing that I derived from something.
Here we see that DD E5 is PUSH IX. We do actually have a DD E5. It's in the dispatch_table_dd and looks like it tries to do a get_ixy and a push. Where "get_ixy" should get IX as it knows which reg to use form the dispatch table it is in.
What documentation are you using that does not have a PUSH IX. Is this another of those commonly used Z80 features that was not documented originally?
Strangely EXZ80DOC does not have tests for any kind of PUSHs and POPs. Nor does it have tests for CALLs and JUMPs.
The source for the exerciser is in the ZIPM2 disk images. It is EX.MAC. It can be built for 8080/z80 by including different .LIB files. There is a submit file that compiles all the versions.
The last one I posted had a modified version with all the quick tests done first and the failing ones at the end. I commented the failing tests in that source.
Thing is the EX program is not so helpful at finding out why an op fails. You see for each test that you see a pass/fail result for, it is actually running hundreds/thousands of test cases including variations of the op-code and lots of different register/memory values. It then adds the result of each little test into a CRC. Having done a batch like that it compares the CRC with what was obtained on a real Z80. So if a test fails you still don't know which of the hundreds/thousands of little test steps it was.
Still it points us in the general direction.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
The SD, regs and poss 232 stuff to go on a half lenth top board ( still doing that bit )
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Anyway, be brave, weld those Props in place. So far I've been lucky[noparse]:)[/noparse] If not its a bit of a session with the solder sucker.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Side alighnment was about 10 mils just by using a couple of pins. Next time I will try to put one hole in the PCB as well. The twin iron may be better as the two layers may stick down with less movements.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
You're in the shed with HER iron firmly clamped upside down in a huge vice. Meanwhile YOUR iron is doing the delicate precision maneuvers from above.
A&E, here we come again.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I still get the flashbacks.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Failing that, I guess it is just a matter of tediously going through each one and testing an example of each. I started doing that and managed to find one almost straight away - EX AF, AF'. This crashes the zicog. Opcode 08
.Z80 org 100H main: EX AF,AF' RET END▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Off to check the mailbox - RamBlade pcb??? Although express posted yesterday (1 day service) I know from experience it often takes more - fingers crossed [noparse]:)[/noparse]
OT: Well my iron (used wife's iron when she got a newbie) has wax all over it and has been taken by the kids - use it to wax the skiis.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
@heater, I found a program to test out some opcodes. See attached. Might need a few tweaks depending on what compiler you are using. I'm going to add the code to print out a few registers so can then put 'call registers' after each instruction.
Addit: I now have the IDE working so an edit/compile is only 5 seconds and is a single keypress. Debugging is much faster now. The compiler compiles with no errors. Can print out registers with the attached code.
Found another error.
LD (IX+7),24
compiles to
DD 36 07 18 ; hex values
Errors sometimes don't show up instantly, but they do show up if you call a dodgy instruction twice in a row.
So - EX AF, AF' and LD (IX+n),n have problems so far.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 12/8/2009 1:53:39 AM GMT
The missing EX and EXX instructions has been noted here a few time, I guess these details get lost in all the tooing and frowing that goes on in these threads.
Strangely enough EX and EXX are another couple of ops that EXZ80DOC does not test.
EX and EXX should not crash ZiCog exactly. They should cause it to perform a break and a register dump. Did it do that ?
When originally starting out on the old PropAltair emulator I did exactly create a program that exercised each instruction with a couple of different operands and checked resulting flags. That program grew and grew as I added more ops to the emulation. A gave up on it when starting out on Z80 ops, it was becoming a nightmare. It checked 8080 flags settings anyway which are different so it was broken for Z80. So I moved on to EXZ80DOC as a regression test.
The first step in finding out which ops don't work is to look in the zicog.spin code.
Many ops that are not implemented have "not_implemented" as there entry in the dispatch tables. Just search for "not_implemented", the opcode value is shown in comments on the left side of the table entries.
Next are the ops that as far as I know were not documented in the original Z80. Again these are easy to find as they have "undocumented" as their entry in the dispatch tables. There are quite many of these, a few of them do turn up in some later op-code lists I have seen.
"undocumented" is actually a label on the same point in the code as "not_implemented" so all these should also stop with a break and a register dump.
Thirdly there are a bunch of block operation instructions that are handled by overlays. The ones that are not functional, like CPD, have the overlay in place but it contains no code. For example look at for the overlay with label cpd_ovl. These ops will at least run through without doing anything. But of course any program using them will probably crash afterwards.
Fourthly there are some Z80 bit operations that, erroneously, don't have "unimplemented" in the dispatch tables. Instead they have zeros so they WILL crash ZiCog without a register dump. This includes all the ops you see under "dispatch_table_ddcb".
Lastly at the end of the list of tests in EXZ80DOC.MAC I have commented all the failing tests.
First simple thing to do is get all those ops described in "Thirdly" and "Fourthly" above to jump to "not_implemented" so that they stop politely with a register dump. Then run BBC BASIC or whatever and see where it stops.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Did I miss another Prop fest? Would you forgive me if I left my TriBlade on the plane over to Oz?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
EXX does do the jump from the table but no code is there
EX AF, AF' is not implemented
{08} long not_implemented
How does one go about adding these? via overlays (given no longs left)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Oops yep, sorry I was wrong about EXX, but you get the idea anyway.
How does one go about adding these?
Hmmm....There are reasons most of these are not in place.
1) No room in the COG.
2) No room for more overlays in HUB.
3) I ran out of time and energy...
Problem 1) remains, especially for DracBlade and Hydra I guess which need more LONGS for EXT RAM access.
Problem 2) is to do with wanting max HUB space for CP/M on the DemoBoard. This problem does not exist for future versions of ZiCog as we will cease maintaining the DemoBoard CP/M variant. So we should have HUB space for more overlays.
Problem 3) is still around...
If you want to have a go at implementing an op in an overlay best cut and paste an existing overlay and its set up and table entries. For example search for "daa_ovl" to see what's involved.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.