I am going to have a bit of catchup to do shortly. My hardware is packed at the moment as I have been interstate back & forth a bit. At least I have my trusty laptops.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Dr_Acula said...
It has pointers to what it thinks are the registers in HUB. a_reg, b_reg, etc.
Ah I see. Very cunning.
I'm going to zip up the working code and put it in the dracblade thread. Juergen should be getting the board sometime this week.
I do see lots of @@@ through the code. Hmm - another instruction to learn. I thought I knew it all when I learnt @ and @@ and ||.
To look at something different for a while I could implement some of the missing opcodes in ZiCog. I think it's sufficient to post them here (as attachment) and someone could paste them into the source?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
heater said...
Pullmoll: That would be great. I can always cut and paste[noparse]:)[/noparse]
But I think there is something up with ZiCog infrastructure else LDD world work. That same something might mess up testing of any new ops as well.
Ok, but you could just move the now failing and new instructions to the top of the exerciser to not have to wait. Who knows, perhaps implementing more functions shows a hidden scheme in the bug.
Here's cpi_lmm and cpir_lmm for a start.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
heater said...
Where did the uninitialized "tmp" come from in cpi_lmm ?
Oops! I guess that should be data_8. In the others also. I didn't compile it, just wrote it from my head.
My oh my, ini(r) will produce a nice hub access stall. Almost every opcode reads or writes from/to hub RAM.
DUH! The sub lmm_pc is also wrong: 9*4 not 9*8.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
What's the purpose of the three labels z80_exx, in_c and out_c? They will write the b register from data_8, which is certainly wrong. Shall they become cog functions?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
heater said...
Pullmoll: My oh my, ini(r) will produce a nice hub access stall."
Not to worry, all IN/OUT action has to pass through the glacial world of Spin anyway.
Unless someone would write a PASM version of the i/o handler, which shouldn't be all too difficult.
Perhaps I can get mine compatible with what now is in Main_Dr_Acula.spin.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Those labels are long forgotten but intended for implementation of EXX, IN reg,(C) and OUT reg,(C). They are referenced from the dispatch tables. in_c and out_c are little "micro-ops".
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater said...
Those labels are long forgotten but intended for implementation of EXX, IN reg,(C) and OUT reg,(C). They are referenced from the dispatch tables. in_c and out_c are little "micro-ops".
Ok, so they should be in the cog and not LMM. I may leave that to you or try and implement your reg_ptr swap. And the in and out code sequences are already in ini and outi.
Say, how long does <adc,sbc> hl,<bc,de,hl,sp>....( 71,680) cycles take on ZiCog? It runs for ages here...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/14/2010 10:09:34 PM GMT
Funnily enough I've just been snoozing while waiting for EXZ80DOC to finish. The results are attached.
I pasted your codes in first. Sadly cpi, cpir, cpd, cpdr all failed. New DAA is OK.
On the bright side I discovered why LDD failed. That test case also tests LDDR which had not yet been adapted for LMM.
Talk about a bug not being where you are looking!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater said...
Funnily enough I've just been snoozing while waiting for EXZ80DOC to finish. The results are attached.
I pasted your codes in first. Sadly cpi, cpir, cpd, cpdr all failed. New DAA is OK.
On the bright side I discovered why LDD failed. That test case also tests LDDR which had not yet been adapted for LMM.
Talk about a bug not being where you are looking!
Hmm.. I'll compare them to the MAME implementation and see what I did wrong.
Did you read that I found my bug, too?
Here's the CPI code
UINT8 val = RM((Z), (Z)->HL);
UINT8 res = (Z)->A - val;
(Z)->WZ++;
(Z)->HL++; (Z)->BC--;
(Z)->F = ((Z)->F & CF) | (SZ[noparse][[/noparse]res]&~(YF|XF)) | (((Z)->A^val^res)&HF) | NF;
if ((Z)->F & HF) res -= 1;
if (res & 0x02) (Z)->F |= YF; /* bit 1 -> flag 5 */
if (res & 0x08) (Z)->F |= XF; /* bit 3 -> flag 3 */
if ((Z)->BC) (Z)->F |= VF;
Leaving the perfect emulation aside, it should set sign and zero flags, and the auxiliary carry from aux^alu^data_8 as it does. Aha! It should _not_ alter the carry flag. Then the N flags is always set, which I forgot to do in PASM. That's all I see and it applies to cpir, cpd and cpdr also, because all do compares = subtractions. DUH!
The attached versions of cpi, cpd, cpir and cpdr should now match the MAME code.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/15/2010 12:06:53 AM GMT
I'm thinking of hacking up a quick test rig to try doing some "enhancements" to the low-level SD card driver to sort out HCSD support etc. (Not that the extra space is really needed but last time I looked it was easier and cheaper to buy 4GB cards than anything else, certainly in full size SD anyway). I have all the components in my spares bin I think, some RAM an SD card socket a prop and eeprom etc. Two quick questions:
1. What's the current version of ZiCog? v0.10 is at the top of this thread but looks quite old compared to the current discussions
2. What hardware layouts are currently supported? The #ifdefs in v0.10 indicate either TriBlade, or PropDemoBoard however PropDemoBoard is being deprecated (at least for CPM applications I believe?)
As a follow up to those, anyone know what the most popular hardware platform is? Also, is the SD driver being used included in the current release .zip or is it in OBEX?
(I'm aware I don't have a particularly good working knowledge of the code layout yet and have only been glancing at headers but right now I'm meant to be doing some entirely different coding...)
hairymnstr said...
I'm thinking of hacking up a quick test rig to try doing some "enhancements" to the low-level SD card driver to sort out HCSD support etc. (Not that the extra space is really needed but last time I looked it was easier and cheaper to buy 4GB cards than anything else, certainly in full size SD anyway). I have all the components in my spares bin I think, some RAM an SD card socket a prop and eeprom etc. Two quick questions:
1. What's the current version of ZiCog? v0.10 is at the top of this thread but looks quite old compared to the current discussions
2. What hardware layouts are currently supported? The #ifdefs in v0.10 indicate either TriBlade, or PropDemoBoard however PropDemoBoard is being deprecated (at least for CPM applications I believe?)
As a follow up to those, anyone know what the most popular hardware platform is? Also, is the SD driver being used included in the current release .zip or is it in OBEX?
(I'm aware I don't have a particularly good working knowledge of the code layout yet and have only been glancing at headers but right now I'm meant to be doing some entirely different coding...)
Thanks.
Nathan
There is a - said to be - rather old SD driver included in the latest source that Dr_Acula attached some posts further up. AFAIK the support for the PropDemoBoard is history for CP/M use.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Pullmoll: I'm far away from home just now, I'll get EXZ80DOC for you this evening.
hairymnstr: My latest ZiCog development efforts only work on TriBlade for now. I can post the whole thing if you like.
You can get a nice working ZiCog CP/M from Dr_Acula on his DracBlade thread.
Cluso has ZiCog CP/M versions on his TriBlade and RamBlade threads.
I will integrate these variants to the dev version sometime but who knows when.
I don't really want to support CP/M on the DemoBoard as it is all but useless in that small space. However that old version you see in the top of this thread is quite OK to try out. I don't think you will miss much from it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
hairymnstr: Latest TriBlade and RamBlade code is on those threads and is v150 IIRC and is quite stable and will run wordstar. You should still be able to compile that version for the DemoBoard, but that will no doubt be the last to support it. There are links for the SD files there also. These version use the latest fsrw driver from lonesock/rokicki. I unsure what Drac uses now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Pullmoll: cpd<r> and cpi<r> still not working [noparse]:)[/noparse]
According to my Mosteck Z80 manual and a very new ZiLog Z80 book all these ops should set the sign flag.
I tried to add that like so:
test alu, #sign_bit wz
muxnz flags, #sign_bit
but still no joy.
Then you have:
andn flags, #parity_bit 'Always clear parity flag, as BC is 0
in CPIR and CPDR which cannot be right as the comparison loop stops when A=[noparse][[/noparse]HL] so BC may not be zero.
From the book:
S is set if result is negative; reset otherwise
Z is set if A = (HL); reset otherwise
H is set if borrow form bit 4; reset otherwise
P/V is set if BC -1 ≠ 0; reset otherwise
N is set
C is not affected
Edit: Hmm.. thinks "has Pullmoll labled CPD and CPDR backwards?"
Makes my head spin. Must sleep....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater said...
Pullmoll: cpd<r> and cpi<r> still not working [noparse]:)[/noparse]
According to my Mosteck Z80 manual and a very new ZiLog Z80 book all these ops should set the sign flag.
I tried to add that like so:
test alu, #sign_bit wz
muxnz flags, #sign_bit
but still no joy.
Then you have:
andn flags, #parity_bit 'Always clear parity flag, as BC is 0
in CPIR and CPDR which cannot be right as the comparison loop stops when A=[noparse][[/noparse]HL] so BC may not be zero.
From the book:
S is set if result is negative; reset otherwise
Z is set if A = (HL); reset otherwise
H is set if borrow form bit 4; reset otherwise
P/V is set if BC -1 ≠ 0; reset otherwise
N is set
C is not affected
Edit: Hmm.. thinks "has Pullmoll labled CPD and CPDR backwards?"
Makes my head spin. Must sleep....
I think I had the Z80 sign flag right. The sub alu, data8 wz, wc should set the carry when alu becomes negative.
Well, these opcodes turn out to be nastier than I thought they would be. Suggestion: I make them work in my code and once I've found out to do them, I'll translate the code to the LMM version. Those minor changes should be possible without making an error..... I hope [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
FWIW I found Dr_Acula's post with the EXZ80DOC tests that failed on a real Z80. Attached.
AND I got cpd<r> and cpi<r> working now. I'll translate them for ZiCog.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
heater said...
That's more serious than I remember. There are two failing tests that one would expect to pass inluding some fundamental ALU OP stuff.
As for DAA, what can I say?
I don't see how the tests INI and IND are supposed to pass without knowing the state of the I/O hardware on the particular computer it is run on.
I have to fire up my miniN8VEM, I'm was sure there was only one failure apart from the INI/IND thing.
What we don't know is what brand of Z80 that was run on.
They could have the INI and IND results discarded, i.e. read to a memory range that does not go into the CRC, and there could be a flags mask to ignore S and Z, which are both set from the value read from the port... Yes, from EX.MAC:
; make sure that <hl> points to memory area where +/- 256 bytes may be arbitrarliy changed
So the test is writing outside of the region that goes into the CRC.
Yes, there are known differences between Zilog's Z80 and some of NEC's derivatives. The EXZ80 is a good help, nevertheless. We don't want to emulate a specific brand?
BTW: I have a list with entries into the tests to avoid running the first dozen or so which already worked. You just have to patch offset $80 in the COM file to the entry to start with. The names of the last tests are missing, as I didn't wait yet until they are finished.
My latest and greatest cpi<r>,cpd<r> is also attached again.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
I have no time to look at this, we are busy preparing some software for an exhibition/trade show in Amsterdam next week. Does not help that the show is one month earlier than my boss thought it was when he said we should attend!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
To look at something different for a while I could implement some of the missing opcodes in ZiCog. I think it's sufficient to post them here (as attachment) and someone could paste them into the source?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
But I think there is something up with ZiCog infrastructure else LDD world work. That same something might mess up testing of any new ops as well.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Ok, but you could just move the now failing and new instructions to the top of the exerciser to not have to wait. Who knows, perhaps implementing more functions shows a hidden scheme in the bug.
Here's cpi_lmm and cpir_lmm for a start.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/14/2010 2:34:06 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
My oh my, ini(r) will produce a nice hub access stall. Almost every opcode reads or writes from/to hub RAM.
DUH! The sub lmm_pc is also wrong: 9*4 not 9*8.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/14/2010 2:37:42 PM GMT
Not to worry, all IN/OUT action has to pass through the glacial world of Spin anyway.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/14/2010 3:07:24 PM GMT
Unless someone would write a PASM version of the i/o handler, which shouldn't be all too difficult.
Perhaps I can get mine compatible with what now is in Main_Dr_Acula.spin.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Say, how long does <adc,sbc> hl,<bc,de,hl,sp>....( 71,680) cycles take on ZiCog? It runs for ages here...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/14/2010 10:09:34 PM GMT
I pasted your codes in first. Sadly cpi, cpir, cpd, cpdr all failed. New DAA is OK.
On the bright side I discovered why LDD failed. That test case also tests LDDR which had not yet been adapted for LMM.
Talk about a bug not being where you are looking!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Hmm.. I'll compare them to the MAME implementation and see what I did wrong.
Did you read that I found my bug, too?
Here's the CPI code
UINT8 val = RM((Z), (Z)->HL); UINT8 res = (Z)->A - val; (Z)->WZ++; (Z)->HL++; (Z)->BC--; (Z)->F = ((Z)->F & CF) | (SZ[noparse][[/noparse]res]&~(YF|XF)) | (((Z)->A^val^res)&HF) | NF; if ((Z)->F & HF) res -= 1; if (res & 0x02) (Z)->F |= YF; /* bit 1 -> flag 5 */ if (res & 0x08) (Z)->F |= XF; /* bit 3 -> flag 3 */ if ((Z)->BC) (Z)->F |= VF;Leaving the perfect emulation aside, it should set sign and zero flags, and the auxiliary carry from aux^alu^data_8 as it does. Aha! It should _not_ alter the carry flag. Then the N flags is always set, which I forgot to do in PASM. That's all I see and it applies to cpir, cpd and cpdr also, because all do compares = subtractions. DUH!
The attached versions of cpi, cpd, cpir and cpdr should now match the MAME code.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/15/2010 12:06:53 AM GMT
I changed it but the cpd<r> test still fails[noparse]:)[/noparse]
Err. Skip that gibberish I wrote here and have now deleted [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 3/15/2010 7:08:45 AM GMT
Jaja.. I think I know why. The condition A == (HL) or BC == 0 was not really there. Another try with the attached code?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
1. What's the current version of ZiCog? v0.10 is at the top of this thread but looks quite old compared to the current discussions
2. What hardware layouts are currently supported? The #ifdefs in v0.10 indicate either TriBlade, or PropDemoBoard however PropDemoBoard is being deprecated (at least for CPM applications I believe?)
As a follow up to those, anyone know what the most popular hardware platform is? Also, is the SD driver being used included in the current release .zip or is it in OBEX?
(I'm aware I don't have a particularly good working knowledge of the code layout yet and have only been glancing at headers but right now I'm meant to be doing some entirely different coding...)
Thanks.
Nathan
There is a - said to be - rather old SD driver included in the latest source that Dr_Acula attached some posts further up. AFAIK the support for the PropDemoBoard is history for CP/M use.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
hairymnstr: My latest ZiCog development efforts only work on TriBlade for now. I can post the whole thing if you like.
You can get a nice working ZiCog CP/M from Dr_Acula on his DracBlade thread.
Cluso has ZiCog CP/M versions on his TriBlade and RamBlade threads.
I will integrate these variants to the dev version sometime but who knows when.
I don't really want to support CP/M on the DemoBoard as it is all but useless in that small space. However that old version you see in the top of this thread is quite OK to try out. I don't think you will miss much from it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
According to my Mosteck Z80 manual and a very new ZiLog Z80 book all these ops should set the sign flag.
I tried to add that like so:
test alu, #sign_bit wz muxnz flags, #sign_bitbut still no joy.
Then you have:
andn flags, #parity_bit 'Always clear parity flag, as BC is 0
in CPIR and CPDR which cannot be right as the comparison loop stops when A=[noparse][[/noparse]HL] so BC may not be zero.
From the book:
S is set if result is negative; reset otherwise
Z is set if A = (HL); reset otherwise
H is set if borrow form bit 4; reset otherwise
P/V is set if BC -1 ≠ 0; reset otherwise
N is set
C is not affected
Edit: Hmm.. thinks "has Pullmoll labled CPD and CPDR backwards?"
Makes my head spin. Must sleep....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 3/15/2010 9:00:14 PM GMT
Thank you! Interestingly my code hangs on the very first test.
Okay, found that one quickly. Now the first tests pass rather quickly.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/15/2010 10:45:31 PM GMT
I posted the TriBlade version on the TriBlade thread. It also compiles for the RamBlade so see the RamBlade thread for the RamBlade driver.
I will wait until the dust settles (and I have time) to see what has to be done to merge all the code again.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
I think I had the Z80 sign flag right. The sub alu, data8 wz, wc should set the carry when alu becomes negative.
Well, these opcodes turn out to be nastier than I thought they would be. Suggestion: I make them work in my code and once I've found out to do them, I'll translate the code to the LMM version. Those minor changes should be possible without making an error..... I hope [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/16/2010 1:51:48 PM GMT
AND I got cpd<r> and cpi<r> working now. I'll translate them for ZiCog.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/16/2010 3:06:59 PM GMT
As for DAA, what can I say?
I don't see how the tests INI and IND are supposed to pass without knowing the state of the I/O hardware on the particular computer it is run on.
I have to fire up my miniN8VEM, I'm was sure there was only one failure apart from the INI/IND thing.
What we don't know is what brand of Z80 that was run on.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
They could have the INI and IND results discarded, i.e. read to a memory range that does not go into the CRC, and there could be a flags mask to ignore S and Z, which are both set from the value read from the port... Yes, from EX.MAC:
; make sure that <hl> points to memory area where +/- 256 bytes may be arbitrarliy changed
So the test is writing outside of the region that goes into the CRC.
Yes, there are known differences between Zilog's Z80 and some of NEC's derivatives. The EXZ80 is a good help, nevertheless. We don't want to emulate a specific brand?
BTW: I have a list with entries into the tests to avoid running the first dozen or so which already worked. You just have to patch offset $80 in the COM file to the entry to start with. The names of the last tests are missing, as I didn't wait yet until they are finished.
My latest and greatest cpi<r>,cpd<r> is also attached again.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/16/2010 6:43:29 PM GMT
I have no time to look at this, we are busy preparing some software for an exhibition/trade show in Amsterdam next week. Does not help that the show is one month earlier than my boss thought it was when he said we should attend!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
The solution is always required yesterday ( or the day before )
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point