It is a 32 bit counter incremented at the clock frequency - so the lowest byte of the register would look pretty random to Z80 code, more so than the slower-incrementing Z80 refresh register [noparse]:)[/noparse]
And you are correct, it does not need to be declared.
Dr_Acula said...
That sounds intriguing. Just to check, cnt is an internal variable that is incremented somwhere, and it is a byte? This could be used for random numbers, right? I haven't got the pasm instruction set in front of me right now, but cnt doesn't need declaring anywhere, it is internal?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ www.mikronauts.com Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full Morpheusdual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory IO board kit $89.95, both kits $189.95 Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
Dr_A - "BBCBasic is now at the point of running but giving an internal checksum error (but not crashing out to the Break register dump)."
This sounds like excellent progress.
At this point its probably a good idea to run EXZ80DOC again and see if anything has gone broken. There were four tests with CRC errors anyway.
I think you have that zipm2.dsk I put out that has a modified EXZ80ALL on it. If you look in the EX.MAC on that disk you will see I put all the tests into order of execution time but with the tests that failed with a crash at the end. I also added some comments against the failed tests.
Well, at the end of that test list you will find this:
dw rotxy ;(416 cycles) ; Not implemented
dw rotxy1 ;(416 cycles) ; Not implemented
dw rld ;(7168 cycles) ; Not implemented
dw inout ;(65,536 cycles) ; Not implemented
dw rotz80 ;(6,784 cycles) ; Crash
dw ld8rrx ;(6,912 cycles) ; Not implemented
dw ld8ixy ;(32 cycles) ; Undocumented, not implemented
dw incxh ;(3,072 cycles) ; Undocumented, not implemented
dw incxl ;(3,072 cycles) ; Undocumented, not implemented
dw incyh ;(3,072 cycles) ; Undocumented, not implemented
dw incyl ;(3,072 cycles) ; Undocumented, not implemented
dw alu8rx ;(376,832 cycles) ; Undocumented, not implemented
You can find out what instructions these are testing by looking for the test name in the code and the comments there.
For example: test "ld8rrx" has the comment "ld <b,c,d,e,ixy,a>,<b,c,d,e,ixy,a> (6,912 cycles)"
Those tests I marked up as "Undocumented, not implemented" are all using the high or low bytes of IX and IY. Now I'm not 100% sure but I don't think these were documented in the original Z80 all though they do turn up in a lot of opcode lists I've seen.
Now I hate to mention it but the dreaded DAA still does not work. I coded it as per the original Intel 8085 documentation, tested it as best I could manually and it is good enough to get SURVEY to display it's results correctly.
However Z80 DAA is a lot more complicated. I think Zilog fixed it to also work for subtraction. It relies on knowing if the last operation was an add or subtract.
Now the code to implement this extra DAA stuff was never going to fit in COG. DAA is already the biggest overlay so it has no room to grow.
I wonder if BBCBasic is using DAA in that checksum calculation ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
That does not do what you think it does [noparse]:)[/noparse] Even if it did work, as this is a hub operation (and therefore locked to 16n) at least the lower 4 bits would be constant.
Post Edited (kuroneko) : 12/16/2009 7:24:52 AM GMT
The context that BBC Basic uses this is to seed the random number generator. Whilst the 0-255 R reg would allow for better seeding than 0-15, the randomness of the choice of seed was the human time taken to wait from switch on to starting the random sequence. Sticking a constant in there, until the R reg is implimented properly wouldn't threaten the fabric of time.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
What kuroneko means...
1. you cannot use wrbyte cnt, a_reg as "cnt" may not be used as the destination (even though it is in fact the source)
2. cnt will always have the lower 4 bit combinations identical (i.e. not random). This is because it is a hub operation and you only get a slot every 16 clock cycles. We know the source (if a register) is sampled in the "e" cycle which is where no doubt were the wrbyte instruction is "cycling" while waiting for a hub access.
What you will need to do is this ...
mov tmp, cnt
shr tmp, #4 '#2 or #4 (2 is because each instruction will be mainly synchronised - we don't have wait instructions in ZiCog)
wrbyte cnt, a_reg
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Getting there with unimplemented instructions but I'm still struggling with more fundamental things.
LD A,I
LD A,R
LD I,A
LD R,A
'---------------------------------------------------------------------------------------------------------
'ireg overlay LD A,I LD I,A LD A,R LD R,A =ED then 57,47,5F,4F
' for the moment do nothing for all 4 of these as not used by the zicog
' down the track, cnt could be used for LD A,R to create a random number
'
org OVERLAY_START
ireg_ovl
add pc,#1 ' do nothing, skip this byte (2 byte commands)
jmp #fetch
long $0[noparse][[/noparse]($ - OVERLAY_START) // 2] 'fill to even number of longs (REQUIRED)
ireg_ovl_end
fit $1F0
Added the jumps in the ED jump table at 57,47,5F,4F
These are two byte instructions and all this does is skip the second byte by incrementing the PC. No actual code as yet.
Tested with this little .MAC program compiled on the dracblade.
File IREG.MAC
; changing from tasm mnemonics - replace all $nn with nnH
; remove . in front of equ
; remove : in equ lines
; must have a CR/LF after END
; use zasm.sub with supersub
; eg supersub zasm myfile (where myfile is called myfile.mac but do not put the
; mac in the instruction - m80 knows it is implied)
; zasm.sub is the following two lines
;M80 =$1 /Z/C/L/M
;L80 $1,$1/N/E
; LD A,R
; LD R,A
; LD I,A
; LD A,I all these do nothing but at least dont crash the zicog
MAIN: LD A,1 ; setup a few registers to prove it works
LD B,2
LD C,3
HALT
LD A,R ; these should do nothing
LD R,A
LD I,A
LD A,I
HALT
LD D,4 ; do a few more instructions
LD E,5
HALT ; dumps registers
RET ; back to CP/M
END
I'm dumping out the hex values in memory 5 before and 5 after the current PC ie 10 bytes so it is possible to see the hex of what instruction just happened and what is about to happen.
The program runs to completion (with 3 breaks) and goes back to CP/M as expected.
I can now get DDTZ to run. But it is not working and while it returns to CP/M, nothing in CP/M works after running DDTZ. So somewhere in that program is a corrupted instruction.
So - I guess it is back to the exerciser for now...
I had an idea of going to the .MAC source of DDTZ but it appears the source I have is corrupted. It won't compile on the dracblade nor on the N8VEM. One thing - it is writting in 8080 pnemonics, but has special overlays for a handful of Z80 commands. But not all and I think this version might be incomplete in some way.
@heater, I've gone back to a post on the 15th March in this thread when we were running the exerciser. I think you had a way of creating a source file so it ran the quick tests at the beginning.
I've just run the Z80 exerciser on the SIMH and it passes everything. So I guess that means it is possible to build a perfect emulator.
I then ran it on a N8VEM with a real Z80 and got a few crc checks. Some we mentioned back in March were the same as the crc numbers on the zicog which was good news.
Do you still have the sources for those programs? Could you maybe post one with the quick bits listed first, and then I can do a comparison with a real Z80? Cheers, James
Dr_A, That version of EXZ80DOC.COM with quick tests done first and the source code for it are in the last zipm2.dsk I posted. I'd post it again but I'm away from my machine today.
In theory you don't have to compare running EX against a real Z80 as it already contains CRCs of test results when run on a MOSTEK Z80.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
<insert image of Homer slapping his forehead and saying "DUH!">
Ofcourse, it would read the shadow register.
I was bitten by this a couple of years ago when I was trying to do
WRLONG ina, hubptr
Thanks,
Bill
kuroneko said...
Bill Henning said...
I'd suggest
WRBYTE cnt,a_reg
as a good implementation of LD A,R
That does not do what you think it does [noparse]:)[/noparse] Even if it did work, as this is a hub operation (and therefore locked to 16n) at least the lower 4 bits would be constant.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ www.mikronauts.com Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full Morpheusdual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory IO board kit $89.95, both kits $189.95 Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
Time to get this to pass the tests. I'm not greatly concerned about crc errors yet, as I know these came up on a real Z80 too. Just need the crc to be the same (which I can test easily but it does take all night to run a test)
But first test is to get the exerciser to get to the end
A>exz80doc
Z80 instruction exerciser
Undefined status bits NOT taken into account
<adc,sbc> hl,<bc,de,hl,sp>....( 71,680) cycles ERROR **** crc expected:f39089a0 found:70201f28
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 OK
aluop a,<ixh,ixl,iyh,iyl>.....(376,832) cycles
AF =38C5 BC =C035 DE =22DD HL =2847 SP =234B PC =253D
AF'=0000 BC'=0000 DE'=0000 HL'=0000 IX =ACCF IY =C76E
Unimplemented instruction one before location PC, any key to continue
And copied off the screen as I can't copy and paste it yet the bytes near this error are (SP is 253D and I think it errors the one before)
2538 7B
2539 11
253A 01
253B DD
253C 84
253D 00
253E 00
253F ED
2540 73
Addit: Found a list of opcodes including undocumented ones. Posting it here as I was able to work out the above is DD84 which is an undocumented one. There are a huge number of opcodes in the DD set that are undocumented. Do we use them? (I never have). But at least we need to not fail the emulation on them - ie increment the PC properly.
Dr_A, I'm not sure where we are going with this now. Normally I would want any ops the we don't implement to cause a break and a reg. dump rather than just silently fail and continue. Having them break is more useful when trying to get something like BBCBasic to work as we can see immediately where it trips up.
All those ops that operate on high and low halves of IX and IY are not implemented. As far as I know they were not documented as for the original Z80. Can we check that some how?
If you look at the DD and FD ops you soon realize that what actually happens is that the DD and FD prefixes throw a big switch in the Z80 somewhere that cause it to operate on IX and IY instead of HL.
Most (not sure if all) ops have the same function as the opcode without the prefix byte except using index regs instead of HL. That is why there are actually ops to operate on IXH, IXL, IYH and IYL as bytes. Thesy are the same operations as on H and L bytes.
So this leads me to think:
If we were really smart we would not have that dispatch table for DD and FD ops separately rather the DD and FD prefix would arrange that whatever happens next hapens to IX an IY instead of HL. Bit like moving the register pointer for EX.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Yes I can see your argument for leaving it as it is, and also for changing it. How hard would it be to add these non implemented codes (simh has them)? Or how about we change the source code for the exerciser program and delete these opcodes?
What I'd really like is for someone to come up with an original Zilog Z80 manual/data sheet so that we can find out if those ops were originally advertised as working or not. If not they should be removed from EXZ80DOC and tested in EXZ80ALL instead.
Anyway, never mind the exerciser, we want BBCBasic to run. So we need to implement whatever it uses, documented or not. So we should break on unimplemented stuff.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I had the official Mostec Z80 book, as standard with the Nascon kit. I have a link, somewhere, to a pdf of it, and as far as I can remember the "undocumented" ops were only a "happen chance" and were never officially supported. As you say, Heater, they unleash a raft of obscure features. I will search for that link (it was a grey A4 paperback, about 300 pages, if I recall)
Using cnt as a source for the R register is ok I think.
Why: the 16 cycle window is not an issue because you are not synchronized to the HUB and inside the 16 cycle window from previous reads/z80 instructions, you have an arbitrary number of instructions between reads of cnt, i.e. R. btw, R is only a 7 bit counter!
I do not know how the BBC Basic uses R but I'd guess it is only 1 read to R... so no issue at all...
re heater "What I'd really like is for someone to come up with an original Zilog Z80 manual/data sheet so that we can find out if those ops were originally advertised as working or not."
Oh, ok (swivels chair, pulls the Zilog Data Book (1979) off the shelf and turns to page 6). I can't see any of those split IX/IY instructions anywhere. So I reckon they ought to come out of the exerciser. If we just remove those ones, then I can do a checksum and compare with a real Z80.
heater, where did you say the source was again for the exerciser? Somewhere in a zip posted a while back?
Down in the dark depths of Dr Acula's crypt, obscured by dust, cobwebs and the bones of young virgins there lurks....A Zilog Z80 manual !
Brilliant. I'm going to fix up the EXZ80DOC.COM to only does what it says it does. Still that does not mean that BBC Basic does not use some of those undocumented ops or undocumented flag bit settings.
I'll try and post you my EX source when I get home tonight.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Ale said...
Why: the 16 cycle window is not an issue because you are not synchronized to the HUB and inside the 16 cycle window from previous reads/z80 instructions, you have an arbitrary number of instructions between reads of cnt, i.e.
How do you know that you're not synchronised? The code path after returning from the hub access (to read the LD A, R instruction) up to querying cnt is constant (assumption on my part, but why wouldn't it be). Which means you are locked to the hub window (16n + const). What am I missing here? Or is it possible that instructions are fetched either from hub or cog (cache) memory?
Just managed to squeeze in a run of EX on my TriBlade again having lost the results from last time. Here is the result:
[noparse][[/noparse]code]
A>exz80doc
Z80 instruction exerciser
Undefined status bits NOT taken into account
ld hl,(nnnn)..................( 16) cycles OK
ld sp,(nnnn)..................( 16) cycles OK
ld (nnnn),hl..................( 16) cycles OK
ld (nnnn),sp..................( 16) cycles OK
ld (<ix,iy>+1),nn.............( 32) cycles OK
ld (<ix,iy>-1),nn.............( 32) cycles OK
ld <bc,de>,(nnnn).............( 32) cycles OK
ld <ix,iy>,(nnnn).............( 32) cycles OK
ld <ix,iy>,nnnn...............( 32) cycles OK
ld a,<(bc),(de)>..............( 44) 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
ld <b,c,d,e,h,l,(hl),a>,nn....( 64) cycles OK
ld (nnnn),<bc,de>.............( 64) cycles OK
ld (nnnn),<ix,iy>.............( 64) cycles OK
ld <bc,de,hl,sp>,nnnn.........( 64) 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
ld a,(<ix,iy>+1)..............( 128) cycles OK
ld a,(<ix,iy>-1)..............( 128) cycles OK
ld (<ix,iy>+1),<h,l>..........( 256) cycles OK
ld (<ix,iy>-1),<h,l>..........( 256) cycles OK
ld <h,l>,(<ix,iy>+1)..........( 256) cycles OK
ld <h,l>,(<ix,iy>-1)..........( 256) cycles OK
<set,res> n,(<ix,iy>+1).......( 448) cycles ERROR **** crc expected:cc63f98a found:3d695930
<set,res> n,(<ix,iy>-1).......( 448) cycles ERROR **** crc expected:b2cdd674 found:43c776ce
ld <b,c,d,e>,(<ix,iy>+1)......( 512) cycles OK
ld <b,c,d,e>,(<ix,iy>-1)......( 512) 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
<inc,dec> bc..................( 1,536) cycles OK
<inc,dec> de..................( 1,536) 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> sp..................( 1,536) cycles OK
bit n,(<ix,iy>+1).............( 2,048) cycles ERROR **** crc expected:a8ee0867 found:216e7b00
bit n,(<ix,iy>-1).............( 2,048) cycles ERROR **** crc expected:29c170d8 found:a04103bf
<inc,dec> a...................( 3,072) cycles OK
<inc,dec> b...................( 3,072) cycles OK
<inc,dec> c...................( 3,072) cycles OK
<inc,dec> d...................( 3,072) cycles OK
<inc,dec> e...................( 3,072) cycles OK
<inc,dec> h...................( 3,072) cycles OK
<inc,dec> l...................( 3,072) cycles OK
<inc,dec> (hl)................( 3,072) cycles OK
ld <bcdehla>,<bcdehla>........( 3,456) cycles OK
cpd<r>........................( 6,144) cycles ERROR **** crc expected:c8439345 found:e3bc468c
cpi<r>........................( 6,144) cycles ERROR **** crc expected:e66fa7d2 found:d6607fd7
<rlca,rrca,rla,rra>...........( 6,144) cycles OK
<inc,dec> (<ix,iy>+1).........( 6,144) cycles OK
<inc,dec> (<ix,iy>-1).........( 6,144) cycles OK
<set,res> n,<bcdehl(hl)a>.....( 6,912) cycles OK
neg...........................( 16,384) 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
bit n,<b,c,d,e,h,l,(hl),a>....( 49,152) cycles OK
<daa,cpl,scf,ccf>.............( 65,536) cycles ERROR **** crc expected:9b4ba675 found:c2e033f4
<adc,sbc> hl,<bc,de,hl,sp>....( 71,680) cycles ERROR **** crc expected:f39089a0 found:70201f28
aluop a,(<ix,iy>+1)...........(229,376) cycles OK
aluop a,(<ix,iy>-1)...........(229,376) cycles OK
aluop a,<b,c,d,e,h,l,(hl),a>..(753,664) cycles OK
shf/rot (<ix,iy>+1)...........( 416) cycles PC=253F AF=8082 BC=94F4 DE=DBF6 HL=FF3C IX=0102 IY=0102 SP=61D9
[noparse][[/noparse]url]
After that last test which "breaks" because the ops are not implemented there are more missing/failing ops.
No chance to play with changing the EX program itself but I have attached the source for it with comments in the "tests" list indicating what fails on ZiCog, what is not implemented yet, and what is not a documented instruction of the original Z80.
To build this copy EXZ80DOC.LIB to EXCONFIG.LIB and assemble with "do mc ex" on ZiCog or SIMH.
For some reason EX has no tests for EX and such that have been tripping us up recently.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Running it now on a real Z80. Not finished yet, but intriguing I got a crc error on an instruction set that yours passed. Yours is *better* than a real Z80 on that one!
A>ex
Z80 instruction exerciser
Undefined status bits NOT taken into account
ld hl,(nnnn)..................( 16) cycles OK
ld sp,(nnnn)..................( 16) cycles OK
ld (nnnn),hl..................( 16) cycles OK
ld (nnnn),sp..................( 16) cycles OK
ld (<ix,iy>+1),nn.............( 32) cycles OK
ld (<ix,iy>-1),nn.............( 32) cycles OK
ld <bc,de>,(nnnn).............( 32) cycles OK
ld <ix,iy>,(nnnn).............( 32) cycles OK
ld <ix,iy>,nnnn...............( 32) cycles OK
ld a,<(bc),(de)>..............( 44) 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
ld <b,c,d,e,h,l,(hl),a>,nn....( 64) cycles OK
ld (nnnn),<bc,de>.............( 64) cycles OK
ld (nnnn),<ix,iy>.............( 64) cycles OK
ld <bc,de,hl,sp>,nnnn.........( 64) 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
ld a,(<ix,iy>+1)..............( 128) cycles OK
ld a,(<ix,iy>-1)..............( 128) cycles OK
ld (<ix,iy>+1),<h,l>..........( 256) cycles OK
ld (<ix,iy>-1),<h,l>..........( 256) cycles OK
ld <h,l>,(<ix,iy>+1)..........( 256) cycles OK
ld <h,l>,(<ix,iy>-1)..........( 256) cycles OK
<set,res> n,(<ix,iy>+1).......( 448) cycles OK
<set,res> n,(<ix,iy>-1).......( 448) 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 (<ix,iy>+1),<b,c,d,e>......( 1,024) cycles OK
ld (<ix,iy>-1),<b,c,d,e>......( 1,024) cycles OK
<inc,dec> bc..................( 1,536) cycles OK
<inc,dec> de..................( 1,536) 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> sp..................( 1,536) cycles OK
bit n,(<ix,iy>+1).............( 2,048) cycles OK
bit n,(<ix,iy>-1).............( 2,048) cycles OK
<inc,dec> a...................( 3,072) cycles OK
<inc,dec> b...................( 3,072) cycles OK
<inc,dec> c...................( 3,072) cycles OK
<inc,dec> d...................( 3,072) cycles OK
<inc,dec> e...................( 3,072) cycles OK
<inc,dec> h...................( 3,072) cycles OK
<inc,dec> l...................( 3,072) cycles OK
<inc,dec> (hl)................( 3,072) cycles OK
ld <bcdehla>,<bcdehla>........( 3,456) cycles OK
cpd<r>........................( 6,144) cycles OK
cpi<r>........................( 6,144) cycles OK
<rlca,rrca,rla,rra>...........( 6,144) cycles OK
<inc,dec> (<ix,iy>+1).........( 6,144) cycles OK
<inc,dec> (<ix,iy>-1).........( 6,144) cycles OK
<set,res> n,<bcdehl(hl)a>.....( 6,912) cycles OK
neg...........................( 16,384) 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 ERROR **** crc expected:5fc828e9 found:f9c36ff1
aluop a,nn....................( 45,056) cycles OK
bit n,<b,c,d,e,h,l,(hl),a>....( 49,152) cycles OK
<daa,cpl,scf,ccf>.............( 65,536) cycles OK
<adc,sbc> hl,<bc,de,hl,sp>....( 71,680) cycles OK
aluop a,(<ix,iy>+1)...........(229,376) cycles OK
aluop a,(<ix,iy>-1)...........(229,376) cycles OK
aluop a,<b,c,d,e,h,l,(hl),a>..(753,664) cycles
Will repost when that big set finishes (any way of splitting it up??)
In the source of the EX test we find "At the end of the sequence the crc is compared to an expected value that was found empirically on a real Z80" and "Documented flags are as per Mostek Z80"
So we can conclude that a Mostek Z80 is not the same as a ZilogZ80.
So actually we should create a another version of EX that has the correct checksums in it for a real Z80. EZ80REAL.COM ?
What brand of Z80 are you running that test on?
I have to dig up that mini-n8vem you sent me I think that is a Zilog.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
My RamBlade is running ZiCog · (I have been busy with other things and RamBlade)
Drac: Could you post the latest ZiCog code (with the extra instruction fixes) so that I can integrate with TriBlade, RamBlade & Demo Board code? How much more to go before it is ready for a release?
I note all the testing with the exorciser? Could you post the compiled file? I presume I can then Xmodem it across?
I am thinking of modifying (#ifdef) the spin code (serial out function) to check if ">" is written and insert the CNT value before the ">". This would give us some timing info at each A> prompt.
Are there any files we want to include in the CPM2.2 A drive for a release version? I noticed that the version I am currently using does not have MBasic but I can copy that from the B drive.
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Re my latest code - see the dracblade thread which I think is on page 2 on the forum - latest post has attachment from the 26th Dec. Lots in there is not needed for ramblade, but the zicog code is there.
EX and EXX are working. LD A,I are not coded properly - I just skip them but ideally R could be the cnt register from pasm. There are other instructions that don't work but I don't know what they are. BBC Basic will no run but it gives a Basic error message (which at least is one step better than crashing out to a register dump).
I'm in two minds about a 1.0 release when instructions are known to not work. Thoughts from others would be appreciated.
Comments
And you are correct, it does not need to be declared.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full
Morpheusdual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory IO board kit $89.95, both kits $189.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
This sounds like excellent progress.
At this point its probably a good idea to run EXZ80DOC again and see if anything has gone broken. There were four tests with CRC errors anyway.
I think you have that zipm2.dsk I put out that has a modified EXZ80ALL on it. If you look in the EX.MAC on that disk you will see I put all the tests into order of execution time but with the tests that failed with a crash at the end. I also added some comments against the failed tests.
Well, at the end of that test list you will find this:
dw rotxy ;(416 cycles) ; Not implemented dw rotxy1 ;(416 cycles) ; Not implemented dw rld ;(7168 cycles) ; Not implemented dw inout ;(65,536 cycles) ; Not implemented dw rotz80 ;(6,784 cycles) ; Crash dw ld8rrx ;(6,912 cycles) ; Not implemented dw ld8ixy ;(32 cycles) ; Undocumented, not implemented dw incxh ;(3,072 cycles) ; Undocumented, not implemented dw incxl ;(3,072 cycles) ; Undocumented, not implemented dw incyh ;(3,072 cycles) ; Undocumented, not implemented dw incyl ;(3,072 cycles) ; Undocumented, not implemented dw alu8rx ;(376,832 cycles) ; Undocumented, not implementedYou can find out what instructions these are testing by looking for the test name in the code and the comments there.
For example: test "ld8rrx" has the comment "ld <b,c,d,e,ixy,a>,<b,c,d,e,ixy,a> (6,912 cycles)"
Those tests I marked up as "Undocumented, not implemented" are all using the high or low bytes of IX and IY. Now I'm not 100% sure but I don't think these were documented in the original Z80 all though they do turn up in a lot of opcode lists I've seen.
Now I hate to mention it but the dreaded DAA still does not work. I coded it as per the original Intel 8085 documentation, tested it as best I could manually and it is good enough to get SURVEY to display it's results correctly.
However Z80 DAA is a lot more complicated. I think Zilog fixed it to also work for subtraction. It relies on knowing if the last operation was an add or subtract.
Now the code to implement this extra DAA stuff was never going to fit in COG. DAA is already the biggest overlay so it has no room to grow.
I wonder if BBCBasic is using DAA in that checksum calculation ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (kuroneko) : 12/16/2009 7:24:52 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
1. you cannot use wrbyte cnt, a_reg as "cnt" may not be used as the destination (even though it is in fact the source)
2. cnt will always have the lower 4 bit combinations identical (i.e. not random). This is because it is a hub operation and you only get a slot every 16 clock cycles. We know the source (if a register) is sampled in the "e" cycle which is where no doubt were the wrbyte instruction is "cycling" while waiting for a hub access.
What you will need to do is this ...
mov tmp, cnt
shr tmp, #4 '#2 or #4 (2 is because each instruction will be mainly synchronised - we don't have wait instructions in ZiCog)
wrbyte cnt, a_reg
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 A,I
LD A,R
LD I,A
LD R,A
'--------------------------------------------------------------------------------------------------------- 'ireg overlay LD A,I LD I,A LD A,R LD R,A =ED then 57,47,5F,4F ' for the moment do nothing for all 4 of these as not used by the zicog ' down the track, cnt could be used for LD A,R to create a random number ' org OVERLAY_START ireg_ovl add pc,#1 ' do nothing, skip this byte (2 byte commands) jmp #fetch long $0[noparse][[/noparse]($ - OVERLAY_START) // 2] 'fill to even number of longs (REQUIRED) ireg_ovl_end fit $1F0Added the jumps in the ED jump table at 57,47,5F,4F
These are two byte instructions and all this does is skip the second byte by incrementing the PC. No actual code as yet.
Tested with this little .MAC program compiled on the dracblade.
File IREG.MAC ; changing from tasm mnemonics - replace all $nn with nnH ; remove . in front of equ ; remove : in equ lines ; must have a CR/LF after END ; use zasm.sub with supersub ; eg supersub zasm myfile (where myfile is called myfile.mac but do not put the ; mac in the instruction - m80 knows it is implied) ; zasm.sub is the following two lines ;M80 =$1 /Z/C/L/M ;L80 $1,$1/N/E ; LD A,R ; LD R,A ; LD I,A ; LD A,I all these do nothing but at least dont crash the zicog MAIN: LD A,1 ; setup a few registers to prove it works LD B,2 LD C,3 HALT LD A,R ; these should do nothing LD R,A LD I,A LD A,I HALT LD D,4 ; do a few more instructions LD E,5 HALT ; dumps registers RET ; back to CP/M ENDI'm dumping out the hex values in memory 5 before and 5 after the current PC ie 10 bytes so it is possible to see the hex of what instruction just happened and what is about to happen.
The program runs to completion (with 3 breaks) and goes back to CP/M as expected.
I can now get DDTZ to run. But it is not working and while it returns to CP/M, nothing in CP/M works after running DDTZ. So somewhere in that program is a corrupted instruction.
So - I guess it is back to the exerciser for now...
I had an idea of going to the .MAC source of DDTZ but it appears the source I have is corrupted. It won't compile on the dracblade nor on the N8VEM. One thing - it is writting in 8080 pnemonics, but has special overlays for a handful of Z80 commands. But not all and I think this version might be incomplete in some way.
@heater, I've gone back to a post on the 15th March in this thread when we were running the exerciser. I think you had a way of creating a source file so it ran the quick tests at the beginning.
I've just run the Z80 exerciser on the SIMH and it passes everything. So I guess that means it is possible to build a perfect emulator.
I then ran it on a N8VEM with a real Z80 and got a few crc checks. Some we mentioned back in March were the same as the crc numbers on the zicog which was good news.
Do you still have the sources for those programs? Could you maybe post one with the quick bits listed first, and then I can do a comparison with a real Z80? Cheers, James
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 12/16/2009 10:18:02 AM GMT
In theory you don't have to compare running EX against a real Z80 as it already contains CRCs of test results when run on a MOSTEK Z80.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Ofcourse, it would read the shadow register.
I was bitten by this a couple of years ago when I was trying to do
WRLONG ina, hubptr
Thanks,
Bill
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full
Morpheusdual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory IO board kit $89.95, both kits $189.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
Time to get this to pass the tests. I'm not greatly concerned about crc errors yet, as I know these came up on a real Z80 too. Just need the crc to be the same (which I can test easily but it does take all night to run a test)
But first test is to get the exerciser to get to the end
And copied off the screen as I can't copy and paste it yet the bytes near this error are (SP is 253D and I think it errors the one before)
2538 7B
2539 11
253A 01
253B DD
253C 84
253D 00
253E 00
253F ED
2540 73
Addit: Found a list of opcodes including undocumented ones. Posting it here as I was able to work out the above is DD84 which is an undocumented one. There are a huge number of opcodes in the DD set that are undocumented. Do we use them? (I never have). But at least we need to not fail the emulation on them - ie increment the PC properly.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 12/17/2009 12:33:19 AM GMT
All those ops that operate on high and low halves of IX and IY are not implemented. As far as I know they were not documented as for the original Z80. Can we check that some how?
If you look at the DD and FD ops you soon realize that what actually happens is that the DD and FD prefixes throw a big switch in the Z80 somewhere that cause it to operate on IX and IY instead of HL.
Most (not sure if all) ops have the same function as the opcode without the prefix byte except using index regs instead of HL. That is why there are actually ops to operate on IXH, IXL, IYH and IYL as bytes. Thesy are the same operations as on H and L bytes.
So this leads me to think:
If we were really smart we would not have that dispatch table for DD and FD ops separately rather the DD and FD prefix would arrange that whatever happens next hapens to IX an IY instead of HL. Bit like moving the register pointer for EX.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Anyway, never mind the exerciser, we want BBCBasic to run. So we need to implement whatever it uses, documented or not. So we should break on unimplemented stuff.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
http://numba-tu.com/nascomhomepage.com/pdf/z80-mostek.pdf·but isnt the full version _ I have a print off of it back at home (in the garage,somewhere)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Post Edited (Toby Seckshund) : 12/17/2009 9:24:29 AM GMT
Why: the 16 cycle window is not an issue because you are not synchronized to the HUB and inside the 16 cycle window from previous reads/z80 instructions, you have an arbitrary number of instructions between reads of cnt, i.e. R. btw, R is only a 7 bit counter!
I do not know how the BBC Basic uses R but I'd guess it is only 1 read to R... so no issue at all...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit some of my articles at Propeller Wiki:
MATH on the propeller propeller.wikispaces.com/MATH
pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL020
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
Oh, ok (swivels chair, pulls the Zilog Data Book (1979) off the shelf and turns to page 6). I can't see any of those split IX/IY instructions anywhere. So I reckon they ought to come out of the exerciser. If we just remove those ones, then I can do a checksum and compare with a real Z80.
heater, where did you say the source was again for the exerciser? Somewhere in a zip posted a while back?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Brilliant. I'm going to fix up the EXZ80DOC.COM to only does what it says it does. Still that does not mean that BBC Basic does not use some of those undocumented ops or undocumented flag bit settings.
I'll try and post you my EX source when I get home tonight.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Fixing the exz80 program would be *very* much appreciated!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
This is the book that I wrote all my MC by, I never got to run ZEAP assembler.
The previous link points to a book given with the Nascom kit, but is far less detailed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
[noparse][[/noparse]code]
A>exz80doc
Z80 instruction exerciser
Undefined status bits NOT taken into account
ld hl,(nnnn)..................( 16) cycles OK
ld sp,(nnnn)..................( 16) cycles OK
ld (nnnn),hl..................( 16) cycles OK
ld (nnnn),sp..................( 16) cycles OK
ld (<ix,iy>+1),nn.............( 32) cycles OK
ld (<ix,iy>-1),nn.............( 32) cycles OK
ld <bc,de>,(nnnn).............( 32) cycles OK
ld <ix,iy>,(nnnn).............( 32) cycles OK
ld <ix,iy>,nnnn...............( 32) cycles OK
ld a,<(bc),(de)>..............( 44) 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
ld <b,c,d,e,h,l,(hl),a>,nn....( 64) cycles OK
ld (nnnn),<bc,de>.............( 64) cycles OK
ld (nnnn),<ix,iy>.............( 64) cycles OK
ld <bc,de,hl,sp>,nnnn.........( 64) 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
ld a,(<ix,iy>+1)..............( 128) cycles OK
ld a,(<ix,iy>-1)..............( 128) cycles OK
ld (<ix,iy>+1),<h,l>..........( 256) cycles OK
ld (<ix,iy>-1),<h,l>..........( 256) cycles OK
ld <h,l>,(<ix,iy>+1)..........( 256) cycles OK
ld <h,l>,(<ix,iy>-1)..........( 256) cycles OK
<set,res> n,(<ix,iy>+1).......( 448) cycles ERROR **** crc expected:cc63f98a found:3d695930
<set,res> n,(<ix,iy>-1).......( 448) cycles ERROR **** crc expected:b2cdd674 found:43c776ce
ld <b,c,d,e>,(<ix,iy>+1)......( 512) cycles OK
ld <b,c,d,e>,(<ix,iy>-1)......( 512) 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
<inc,dec> bc..................( 1,536) cycles OK
<inc,dec> de..................( 1,536) 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> sp..................( 1,536) cycles OK
bit n,(<ix,iy>+1).............( 2,048) cycles ERROR **** crc expected:a8ee0867 found:216e7b00
bit n,(<ix,iy>-1).............( 2,048) cycles ERROR **** crc expected:29c170d8 found:a04103bf
<inc,dec> a...................( 3,072) cycles OK
<inc,dec> b...................( 3,072) cycles OK
<inc,dec> c...................( 3,072) cycles OK
<inc,dec> d...................( 3,072) cycles OK
<inc,dec> e...................( 3,072) cycles OK
<inc,dec> h...................( 3,072) cycles OK
<inc,dec> l...................( 3,072) cycles OK
<inc,dec> (hl)................( 3,072) cycles OK
ld <bcdehla>,<bcdehla>........( 3,456) cycles OK
cpd<r>........................( 6,144) cycles ERROR **** crc expected:c8439345 found:e3bc468c
cpi<r>........................( 6,144) cycles ERROR **** crc expected:e66fa7d2 found:d6607fd7
<rlca,rrca,rla,rra>...........( 6,144) cycles OK
<inc,dec> (<ix,iy>+1).........( 6,144) cycles OK
<inc,dec> (<ix,iy>-1).........( 6,144) cycles OK
<set,res> n,<bcdehl(hl)a>.....( 6,912) cycles OK
neg...........................( 16,384) 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
bit n,<b,c,d,e,h,l,(hl),a>....( 49,152) cycles OK
<daa,cpl,scf,ccf>.............( 65,536) cycles ERROR **** crc expected:9b4ba675 found:c2e033f4
<adc,sbc> hl,<bc,de,hl,sp>....( 71,680) cycles ERROR **** crc expected:f39089a0 found:70201f28
aluop a,(<ix,iy>+1)...........(229,376) cycles OK
aluop a,(<ix,iy>-1)...........(229,376) cycles OK
aluop a,<b,c,d,e,h,l,(hl),a>..(753,664) cycles OK
shf/rot (<ix,iy>+1)...........( 416) cycles PC=253F AF=8082 BC=94F4 DE=DBF6 HL=FF3C IX=0102 IY=0102 SP=61D9
[noparse][[/noparse]url]
After that last test which "breaks" because the ops are not implemented there are more missing/failing ops.
No chance to play with changing the EX program itself but I have attached the source for it with comments in the "tests" list indicating what fails on ZiCog, what is not implemented yet, and what is not a documented instruction of the original Z80.
To build this copy EXZ80DOC.LIB to EXCONFIG.LIB and assemble with "do mc ex" on ZiCog or SIMH.
For some reason EX has no tests for EX and such that have been tripping us up recently.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Running it now on a real Z80. Not finished yet, but intriguing I got a crc error on an instruction set that yours passed. Yours is *better* than a real Z80 on that one!
Will repost when that big set finishes (any way of splitting it up??)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
In the source of the EX test we find "At the end of the sequence the crc is compared to an expected value that was found empirically on a real Z80" and "Documented flags are as per Mostek Z80"
So we can conclude that a Mostek Z80 is not the same as a ZilogZ80.
So actually we should create a another version of EX that has the correct checksums in it for a real Z80. EZ80REAL.COM ?
What brand of Z80 are you running that test on?
I have to dig up that mini-n8vem you sent me I think that is a Zilog.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
aluop a,<b,c,d,e,h,l,(hl),a>..(753,664) cycles OK
shf/rot (<ix,iy>+1)...........( 416) cycles OK
shf/rot (<ix,iy>-1)...........( 416) cycles OK
<rrd,rld>.....................( 7,168) cycles OK
<ini,outi,ind,outd><,r>.......( 65,536) cycles ERROR **** crc expected:aafb6d5c found:498ee92f
shf/rot <b,c,d,e,h,l,(hl),a>..( 6,784) cycles OK
ld <bcdexya>,<bcdexya>........( 6,912) cycles OK
ld <ixh,ixl,iyh,iyl>,nn.......( 32) 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
aluop a,<ixh,ixl,iyh,iyl>.....(376,832) cycles OK
Some failure detected.
CP/M V2.2C
A>
Chip is a Zilog Z84C00
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
My RamBlade is running ZiCog
Drac: Could you post the latest ZiCog code (with the extra instruction fixes) so that I can integrate with TriBlade, RamBlade & Demo Board code? How much more to go before it is ready for a release?
I note all the testing with the exorciser? Could you post the compiled file? I presume I can then Xmodem it across?
I am thinking of modifying (#ifdef) the spin code (serial out function) to check if ">" is written and insert the CNT value before the ">". This would give us some timing info at each A> prompt.
Are there any files we want to include in the CPM2.2 A drive for a release version? I noticed that the version I am currently using does not have MBasic but I can copy that from the B drive.
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Post Edited (Cluso99) : 12/27/2009 2:55:19 AM 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
Re my latest code - see the dracblade thread which I think is on page 2 on the forum - latest post has attachment from the 26th Dec. Lots in there is not needed for ramblade, but the zicog code is there.
EX and EXX are working. LD A,I are not coded properly - I just skip them but ideally R could be the cnt register from pasm. There are other instructions that don't work but I don't know what they are. BBC Basic will no run but it gives a Basic error message (which at least is one step better than crashing out to a register dump).
I'm in two minds about a 1.0 release when instructions are known to not work. Thoughts from others would be appreciated.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 12/27/2009 4:26:15 AM GMT