Sorry if we are keeping you from "work" (shudder) and stearing you towards impending destitution. I have just printed off the last few posts to read, I find that I can cotton on to things far better when it is on paper (sorry trees). To print off the entire set or treads and extract all the relevant bits may be costly (sorry forests).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Sorry to break in... but I have an idea. I know, dangerous, especially since I have not looked at ZiCog's guts.
One simple technique I've used for holding two hub pointers in one cog register may be very useful here...
ROL hubptr,#16 ' <-- swap two hub pointers
Can also be used for other pointers..
So the implementation of EXX AH,AH' would be:
ROL axptr,#16
While this would not be good for all hub pointers (as pointed out in the quote below), it seems perfect for the alternate register set hub pointers...
Or am I missing something?
This should save some longs in ZiCog, MotoCog etc
heater said...
Dr_A: "Why are these variables longs when at most they store word variables?"
In the zicog.spin those variable like "b_reg" are NOT variables holding WORDS.
They are LONGS that contain the HUB addresses of the byte registers in HUB as defined in zicog_cpm.spin.
This way you can access the registers in HUB with "rdbyte data_8, b_reg" and "wrbyte data_8, c_reg".
You can aslo use rd/wrword for the register pairs.
Now one could say that HUB addresses can only be 15 bits (for 32K) so why use 32 bit longs to hold them?
Well, rdbyte, wrbyte etc need to use a LONG as the target HUB address.
BUT if we were very sneaky we could put other WORD variables into the high halves of those LONGS. When the LONG is used as a HUB address by rd/wrbyte the top half (where our variable is hiding) would be ignored.
This would make the code even more unreadable but would potentially save 18 words, 9 LONGS.
Edit: Forget the above. Putting vars in the high halves of HUB pointers would require shifting etc to access them eating more LONGS that we save.
Anyway as I said before you don't need any of those _alt register pointers. Just add and subtract from the existing pointers to switch the whole emulation from using one set of regs to another. It can all be done in an overlay with no "resident" code.
I'll have a look at the rest of your post later.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ 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
Bill, although it's great for PropI, and would do the job perfectly, it would have to be remembered for when we get Prop][noparse][[/noparse] because it won't work on that.
other than that, it's perfect, fast, and no messing swapping Words over!
Hi Bill, Brilliant! That's a very interesting idea. Looks like it would help the job along nicely. In fact it looks like the whole EX thing gets done in one instruction!! The two pointers can be set into the LONG from Spin prior to starting the PASM COG. Not only that it means we don't have keep track of if we are in the "front" or "back" register as it just rolls around each time.
Mind you I have resisted this kind of thing till now because when we get to the Prop II with more HUB RAM it's not going to work. For now it get's us out of a bind quickly.
Not only is it very dark, and snowing here. It's also minus fricken 10 Centigrade.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I would not worry about PropII for ZiCog yet - the changes and additions to the instruction set will spawn a ZiCog2 that will be much faster, better etc. as the new instructions will simplify a LOT of the code!
And Prop1 will be around for a long time... I plan to keep developing for BOTH Prop1 and Prop2!
[noparse][[/noparse]and there is a Morpheus 2 in early planning stages... It will be even more revolutionary than Morpheus was.]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ 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
OK Bill, we'll forget about Prop II until we know what it really looks like.
Last time I though about this kind of thing I just assumed that Prop II would be like Prop I only more so.
Of course following the Prop II threads I should already be thinking it's quite a different beast as far as ZiCog goes.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Thing was that until this morning it was a balmy almost zero Centigrade. Temp dropped like a stone in a couple of hours this afternoon.
I did go to the very top of Finland into Norway one mid-summer, very warm and sun shining all day long. After a few days of that life starts feeling very surreal, should I be awake or asleep now or what?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
SHE always says "Why cant we hibernate?". I resisted the initial thought - Is that your excuse for putting on weight ? I have mastered the art of not thinking out loud. Eventually.
Just been pratting about with FreePCB and have found that it will "copper pour", having spent ages drawing the bits in. Note to self - RTFM, RTFM, RTFM .....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Actually I can't wait for the "definitive" list, including op-code encoding. I think I can build a much better LMM2 engine than just running plain-old LMM on the prop.
Not to mention having to support it in LAS, PropellerBasic and Largos!
I also think a Prop2 re-write of ZiCog, MoCog etc will scream, don't forget, you can grab 64KB of HUB memory for the whole Z80/6809 address range.
I expect at least 10x (maybe 15x) faster ZiCog emulation. The overlays will also be MUCH faster with the quad-word loads.
heater said...
OK Bill, we'll forget about Prop II until we know what it really looks like.
Last time I though about this kind of thing I just assumed that Prop II would be like Prop I only more so.
Of course following the Prop II threads I should already be thinking it's quite a different beast as far as ZiCog goes.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ 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
The things you are talking about are so far above my head, there isn't a single wafted silver hair, as it rushes by. I have to get a grip on the Prop1 soon, not that I see myself doing any ironing for a PropII.
Mind you at least I shall be at the start of that party
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Actually, I think he is partially designing it for easier emulation and easier LMM - I certainly pestered him enough right after I came up with LMM with ideas for improvements, and I understand Sapieha did the same... and it would not surprise me if you and many others did the same!
I am pretty sure that I can get LMM to average 20 LMM mips out of hub memory... it blows my mind that it will theoretically be possible to write LMM video drivers!
heater said...
Bill, I've been dreaming about ZiCog RAM space sitting in Prop II HUB RAM for an awful long time now. The quad word loads are a serious bonus.
Some times, late at night, when I follow a Prop II thread, I get the feeling Chip is designing the thing just for ZiCog[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ 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
Bill & heater: Yes, the PropII will be fantastic for ZiCog, LMM, etc. But is is sooo much more. The counters will be incredible. And don't forget the ADC/DAC on each pin, with pullups/pulldowns, etc. And we will have about 96+8=104 I/O pins. AUtoincrement instructions, etc.
It is mindblowing just to think what the PropII will be capable of doing, and all <$10. I know the next complaint will be only 8 cogs (because I cannot see anything else not in there).
BUT, the Prop I is here now, and look at what has been achieved in the last year !!! We are still finding ways to exploit this chip. I guess, it has taken this long to build up the library of what it can do. A huge advantage is that there is only one Prop I, not like other chips where there are heaps of variants.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
The complaint about "only 8 COGs" has already been made and discussed. There was that great (as in long and as in very interesting) thread where Chip asked "more COGs or more RAM?"
My conclusion was that more COGs sounds very desirable, we always want more of a good thing. BUT more COGs, even if you can have the RAM as well, means slower execution as they all contend for the HUB. In this shared RAM architecture there must be an optimum number of processors. If there were an infinite number of COGs they would be stalled forever if they used HUB RAM[noparse]:)[/noparse]
Chip has apparently settled on 8 and I'm inclined to be happy with that. Especially if there is some form of high speed Prop to Prop comms possibility to enable throwing more COGs at a problem by buy another Prop.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater: While I would like more than 8 cogs, that was not my point. It will now be the shortcoming because it has everything else! Otherwise, it will be because it does not have >1MB memory. There will always be some shortcoming in someone's eyes. LOL
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Hey, at least it won't be I/O pins this time!! 96 Pins! I thought it pretty funny that RAM was the initial pinch on Prop I, and people sort of came to terms with that, either by coding well, or adding RAM, which moved the problem to pins. Turns out that many pins would play out well on ordinary Prop I. Who woulda thought?
Not on Prop II right away, hopefully. It will be something else entirely. Maybe will be COGs, and everybody gets better at threading...
Ok, got my first instruction working! I'll write this up as I think it might be easier than heater's method of running the instruction exerciser.
Printout first:
Zicog with Dracblade. D9F=19200 baud. D9M=1200 baud. F12=network.
Mount SD and find hard drive file locations
A=A.DSK
B=B.DSK
C=C.DSK
D=D.DSK
E=E.DSK
F=F.DSK
G=G.DSK
H=H.DSK
R=BOOT.DSK
Read boot code from SD card
Start Z80
Passed, loading Zicog
64K CP/M Version 2.2 (ZiCog, BIOS V1.27_Zi04, 8 HD, 10-Sep-2009)
SuperSUB V1.1
A>; AUTOEXEC.SUB; PLACE INITIAL BOOT COMMANDS HERE
A>type af.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
; 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
MAIN: LD A,1
LD B,2
LD C,3
HALT
EX AF,AF'
HALT
LD D,4
LD E,5
EX AF,AF' ; swap it back
HALT ; dumps registers
RET ; back to CP/M
END
A>submit zasm af
A>M80 =AF /Z/C/L/M
No Fatal error(s)
A>L80 AF,AF/N/E
Link-80 3.44 09-Dec-81 Copyright (c) 1981 Microsoft
Data 0103 0113 < 16>
47146 Bytes Free
[noparse][[/noparse]0000 0113 1]
A>AF
AF =0144 BC =0203 DE =F1FF HL =E3EF SP =E3A9 PC =010A
AF'=0000 BC'=0000 DE'=0000 HL'=0000 IX =0000 IY =0000
Unimplemented instruction at location PC, any key to continue
AF =0000 BC =0203 DE =F1FF HL =E3EF SP =E3A9 PC =010C
AF'=0144 BC'=0000 DE'=0000 HL'=0000 IX =0000 IY =0000
Unimplemented instruction at location PC, any key to continue
AF =0144 BC =0203 DE =0405 HL =E3EF SP =E3A9 PC =0112
AF'=0000 BC'=0000 DE'=0000 HL'=0000 IX =0000 IY =0000
Unimplemented instruction at location PC, any key to continue
A>
The unimplemented instruction is the HALT. Very handy for debugging.
Get wordstar working and write a little program and save it with a .MAC extension. .MAC is the Z80 equivalent of .ASM. Or you can write it in notepad and xmodem it over. I used both methods.
You will need M80 and L80 and a small submit program and submit itself. I've attached these, as well as the (warts and all) dracblade current version.
The precursor things were described a few threads back - create a blank overlay file etc.
I then filled it up with code. One complication is that there are not many working variables spare in the zicog, so there is no room to store pointers to the Alt registers. So I pointed to the A and F registers then added 8. Also I had to use data_16 for that variable which is not very tidy. And I removed the pointer to im_reg (not needed) and added a variable temp1 instead.
I'm sure there is a way to simplify this code. The other complication is the flags register being stored locally and not in hub, so you have to send the right value to hub. I think it is working right because it makes af 0000 and then restores it.
The registers now are two lines. At one stage I had some code that dumped out the hex values of the next 10 instructions but I don't think that is needed as the code has just been written so you know what they should be.
I'm now very happy as I have all the tools in place to write the code for any other instruction. And what is even better is the prop is doing this on itself, ie you write the .MAC assembly program in wordstar, you compile it on the prop, you run it and test it etc. The prop is now becoming self compiling (at least as far as CP/M).
The ex af,af' code is below. Any improvements anyone can see would be appreciated. I'm off to do the exx instruction now...
'---------------------------------------------------------------------------------------------------------
'ex af,af' overlay. rdbyte and wrbyte are value,address for both
org OVERLAY_START
ex_af_af_ovl wrbyte flags, f_reg ' local flags to hub register
rdbyte data_8,f_reg ' get it back into data_8
mov data_16,f_reg ' temp store
add data_16,#8 ' alt flags location in data_16 (temp variable)
rdbyte temp1,data_16 ' get the alt flag data into temp1
wrbyte data_8,data_16 ' F to F'
wrbyte temp1,f_reg ' F' to F
mov flags,temp1 ' put the F' to local flags
wrbyte flags,f_reg ' and put into hub too for break display
' now do the A register
add data_16,#1 ' data_16 to A' register
rdbyte data_8,a_reg ' A to data_8
rdbyte temp1,data_16 ' alt A to temp1
wrbyte data_8,data_16 ' A to A'
wrbyte temp1,a_reg ' A' to A
jmp #fetch
long $0[noparse][[/noparse]($ - OVERLAY_START) // 2] 'fill to even number of longs (REQUIRED)
ex_af_af_ovl_end
fit $1F0
I knew this would be faster now the tools are there. Just coded EXX as well:
'exx overlay.
org OVERLAY_START
exx_ovl mov data_16,c_reg ' happens to be 0 ie regbase
add data_16,#8 ' data_16 now points to the alt BC reg
rdword data_8,c_reg ' get BC into data_8 (messy as storing 2 bytes in data_8)
rdword temp1,data_16 ' BC' to temp1
wrword data_8,data_16 ' BC to BC'
wrword temp1,c_reg ' BC' to BC
add data_16,#2 ' point to DE'
rdword data_8,e_reg ' get DE into data_8
rdword temp1,data_16 ' DE' to temp1
wrword data_8,data_16 ' DE to DE'
wrword temp1,e_reg ' DE' to DE
add data_16,#2 ' point to HL'
rdword data_8,l_reg ' get HL into data_8
rdword temp1,data_16 ' HL' to temp1
wrword data_8,data_16 ' HL to HL'
wrword temp1,l_reg ' HL' to HL
jmp #fetch
long $0[noparse][[/noparse]($ - OVERLAY_START) // 2] 'fill to even number of longs (REQUIRED)
exx_ovl_end
fit $1F0
A message for heater. I'm now printing out a screen dump of the hex bytes 5 before and 5 after a break. I've just noticed that PC doesn't seem to point to the HALT instruction - it seems to point to the one after. Is that correct?
Dr_A, That's great. You have your code/test/debug cycles set up and a working EX. I used to do all this by poking the ops into HUB RAM on the demo board version.
Now it's time to optimize EX. Did you look at Bill's post the other day? You can swap from A to A' with just this:
ROL a_reg,#16 ' <-- swap A and A' reg hub pointers
The idea is that a_reg is initialized by spin such that the low 16 bits are the HUB address of the A register and the high 16 bits are the A' register.
Now, in normal use things like "rdbyte data_8, a_reg" will pick up the A register OK because there is only 32K RAM so the upper 17 bits of a_reg are not used.
Then an EX using ROL puts the A register address in the high bits of a_reg and the A' into the low bits. So now "rdbyte data_8, a_reg" picks up the A' reg.
On the next EX a_reg is rolled back to it's initial state and points again at A.
The same for
ROL f_reg,#16 ' <-- swap F and F' reg hub pointers
Be sure to write flags out to HUB first.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I'm lost again. Ok, ROL makes sense in a way in that you rotate it around the long. But how much setup is required beforehand? Where is the spin bit that sets up AF' in the other half? Is there a change to the variable list for the registers? Will I need to change the code that prints out the registers?
I might have to leave optimisation to others. The code I've posted prints out all the registers and there is the attachment with the compiler to compile tiny test programs written in Wordstar. Maybe I'll be leaving a trail of destruction and badly written code [noparse]:)[/noparse] but a slow bit of code is still better than no code. Hopefully someone will get fired up and deeply passionate about the above comments and feel a strong desire to post a working bit of code that saves some longs!
I'm looking at the IX and IY instructions now. I want DDTZ to run so I at least can debug Z80 programs...
Ok, a pile of IX and IY instructions all check out. PUS, POP, writing and reading to random locations
; 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
; push and pop IX all ok
MAIN: LD A,5
LD IY,5000
LD (IY+100),A
INC A
LD A,(IY+100)
HALT ;A should be 5, not 6
RET ; back to CP/M
END
I thought I would try running DDTZ and it is crashing at 2289H and the opcode before that is ED57. This is LD A,I and in the zicog it is
{57} long undocumented ' LD A,I
Above is its complementary instruction
{47} long not_implemented LD I,A
Neither of these are really needed, and there are some R register ones that are not needed too. Unless maybe for random number generation.
I tried changing 'undocumented' to 'not_implemented' but it does a break either way. Is it possible to have an instruction that is just ignored?
f_reg := (reg_base + 6) + ((reg_base + 14) << 16) ' Address of F reg in low word + address of F' reg in high word.
a_reg := (reg_base + 7) + ((reg_base + 15) << 16) ' Address of A reg in low word + address of A' reg in high word.
Now the guts of EX becomes:
rol a_reg, #16 ' Swap A address for A' address
rol f_reg, #16 ' Swap F address for F' address
Be sure to write flags to HUB first.
Similar for the EXX regs.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
An instruction that is just ignored, i.e. NOP, just requires that the dispatch table entry for it is "fetch".
Bit more tricky if the op you want ignore has an immediate operand or some other byte(s) following it. Then you do have to at least be sure to increment the PC appropriately.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Hmm maybe for the moment I will just put A=0 for LD A,I and LD A,R etc. Thansk for the heads-up on incrementing the PC. These four instructions are all 2 byte ones. DDTZ is crashing because the PC is only incremented by 1. BBCBasic is now at the point of running but giving an internal checksum error (but not crashing out to the Break register dump). That might be getting close to asking the author for some help on the source code.
Just from memory heater, did you finish doing all the IX and IY instructions? Were there others that you didn't get round to doing?
Dr_Acula said...
Hmm maybe for the moment I will just put A=0 for LD A,I and LD A,R etc. Thansk for the heads-up on incrementing the PC. These four instructions are all 2 byte ones. DDTZ is crashing because the PC is only incremented by 1. BBCBasic is now at the point of running but giving an internal checksum error (but not crashing out to the Break register dump). That might be getting close to asking the author for some help on the source code.
Just from memory heater, did you finish doing all the IX and IY instructions? Were there others that you didn't get round to doing?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ 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
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?
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Sorry to break in... but I have an idea. I know, dangerous, especially since I have not looked at ZiCog's guts.
One simple technique I've used for holding two hub pointers in one cog register may be very useful here...
ROL hubptr,#16 ' <-- swap two hub pointers
Can also be used for other pointers..
So the implementation of EXX AH,AH' would be:
ROL axptr,#16
While this would not be good for all hub pointers (as pointed out in the quote below), it seems perfect for the alternate register set hub pointers...
Or am I missing something?
This should save some longs in ZiCog, MotoCog etc
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
other than that, it's perfect, fast, and no messing swapping Words over!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
Mind you I have resisted this kind of thing till now because when we get to the Prop II with more HUB RAM it's not going to work. For now it get's us out of a bind quickly.
Not only is it very dark, and snowing here. It's also minus fricken 10 Centigrade.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I would not worry about PropII for ZiCog yet - the changes and additions to the instruction set will spawn a ZiCog2 that will be much faster, better etc. as the new instructions will simplify a LOT of the code!
And Prop1 will be around for a long time... I plan to keep developing for BOTH Prop1 and Prop2!
[noparse][[/noparse]and there is a Morpheus 2 in early planning stages... It will be even more revolutionary than Morpheus was.]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Last time I though about this kind of thing I just assumed that Prop II would be like Prop I only more so.
Of course following the Prop II threads I should already be thinking it's quite a different beast as far as ZiCog goes.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
You live in Finland. It is winter. It was dark, there, at 10:00 AM !
The furthest north I have been was The Shetland Isles, in January.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
I did go to the very top of Finland into Norway one mid-summer, very warm and sun shining all day long. After a few days of that life starts feeling very surreal, should I be awake or asleep now or what?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Just been pratting about with FreePCB and have found that it will "copper pour", having spent ages drawing the bits in. Note to self - RTFM, RTFM, RTFM .....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Not to mention having to support it in LAS, PropellerBasic and Largos!
I also think a Prop2 re-write of ZiCog, MoCog etc will scream, don't forget, you can grab 64KB of HUB memory for the whole Z80/6809 address range.
I expect at least 10x (maybe 15x) faster ZiCog emulation. The overlays will also be MUCH faster with the quad-word loads.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
The pioneering efforts going on right now are so excellent. This makes me wonder what will be pioneering for Prop II?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Some times, late at night, when I follow a Prop II thread, I get the feeling Chip is designing the thing just for ZiCog[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Mind you at least I shall be at the start of that party
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
I am pretty sure that I can get LMM to average 20 LMM mips out of hub memory... it blows my mind that it will theoretically be possible to write LMM video drivers!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
It is mindblowing just to think what the PropII will be capable of doing, and all <$10. I know the next complaint will be only 8 cogs (because I cannot see anything else not in there).
BUT, the Prop I is here now, and look at what has been achieved in the last year !!! We are still finding ways to exploit this chip. I guess, it has taken this long to build up the library of what it can do. A huge advantage is that there is only one Prop I, not like other chips where there are heaps of variants.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
My conclusion was that more COGs sounds very desirable, we always want more of a good thing. BUT more COGs, even if you can have the RAM as well, means slower execution as they all contend for the HUB. In this shared RAM architecture there must be an optimum number of processors. If there were an infinite number of COGs they would be stalled forever if they used HUB RAM[noparse]:)[/noparse]
Chip has apparently settled on 8 and I'm inclined to be happy with that. Especially if there is some form of high speed Prop to Prop comms possibility to enable throwing more COGs at a problem by buy another Prop.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Not on Prop II right away, hopefully. It will be something else entirely. Maybe will be COGs, and everybody gets better at threading...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Printout first:
Zicog with Dracblade. D9F=19200 baud. D9M=1200 baud. F12=network. Mount SD and find hard drive file locations A=A.DSK B=B.DSK C=C.DSK D=D.DSK E=E.DSK F=F.DSK G=G.DSK H=H.DSK R=BOOT.DSK Read boot code from SD card Start Z80 Passed, loading Zicog 64K CP/M Version 2.2 (ZiCog, BIOS V1.27_Zi04, 8 HD, 10-Sep-2009) SuperSUB V1.1 A>; AUTOEXEC.SUB; PLACE INITIAL BOOT COMMANDS HERE A>type af.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 ; 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 MAIN: LD A,1 LD B,2 LD C,3 HALT EX AF,AF' HALT LD D,4 LD E,5 EX AF,AF' ; swap it back HALT ; dumps registers RET ; back to CP/M END A>submit zasm af A>M80 =AF /Z/C/L/M No Fatal error(s) A>L80 AF,AF/N/E Link-80 3.44 09-Dec-81 Copyright (c) 1981 Microsoft Data 0103 0113 < 16> 47146 Bytes Free [noparse][[/noparse]0000 0113 1] A>AF AF =0144 BC =0203 DE =F1FF HL =E3EF SP =E3A9 PC =010A AF'=0000 BC'=0000 DE'=0000 HL'=0000 IX =0000 IY =0000 Unimplemented instruction at location PC, any key to continue AF =0000 BC =0203 DE =F1FF HL =E3EF SP =E3A9 PC =010C AF'=0144 BC'=0000 DE'=0000 HL'=0000 IX =0000 IY =0000 Unimplemented instruction at location PC, any key to continue AF =0144 BC =0203 DE =0405 HL =E3EF SP =E3A9 PC =0112 AF'=0000 BC'=0000 DE'=0000 HL'=0000 IX =0000 IY =0000 Unimplemented instruction at location PC, any key to continue A>The unimplemented instruction is the HALT. Very handy for debugging.
Get wordstar working and write a little program and save it with a .MAC extension. .MAC is the Z80 equivalent of .ASM. Or you can write it in notepad and xmodem it over. I used both methods.
You will need M80 and L80 and a small submit program and submit itself. I've attached these, as well as the (warts and all) dracblade current version.
The precursor things were described a few threads back - create a blank overlay file etc.
I then filled it up with code. One complication is that there are not many working variables spare in the zicog, so there is no room to store pointers to the Alt registers. So I pointed to the A and F registers then added 8. Also I had to use data_16 for that variable which is not very tidy. And I removed the pointer to im_reg (not needed) and added a variable temp1 instead.
I'm sure there is a way to simplify this code. The other complication is the flags register being stored locally and not in hub, so you have to send the right value to hub. I think it is working right because it makes af 0000 and then restores it.
The registers now are two lines. At one stage I had some code that dumped out the hex values of the next 10 instructions but I don't think that is needed as the code has just been written so you know what they should be.
I'm now very happy as I have all the tools in place to write the code for any other instruction. And what is even better is the prop is doing this on itself, ie you write the .MAC assembly program in wordstar, you compile it on the prop, you run it and test it etc. The prop is now becoming self compiling (at least as far as CP/M).
The ex af,af' code is below. Any improvements anyone can see would be appreciated. I'm off to do the exx instruction now...
'--------------------------------------------------------------------------------------------------------- 'ex af,af' overlay. rdbyte and wrbyte are value,address for both org OVERLAY_START ex_af_af_ovl wrbyte flags, f_reg ' local flags to hub register rdbyte data_8,f_reg ' get it back into data_8 mov data_16,f_reg ' temp store add data_16,#8 ' alt flags location in data_16 (temp variable) rdbyte temp1,data_16 ' get the alt flag data into temp1 wrbyte data_8,data_16 ' F to F' wrbyte temp1,f_reg ' F' to F mov flags,temp1 ' put the F' to local flags wrbyte flags,f_reg ' and put into hub too for break display ' now do the A register add data_16,#1 ' data_16 to A' register rdbyte data_8,a_reg ' A to data_8 rdbyte temp1,data_16 ' alt A to temp1 wrbyte data_8,data_16 ' A to A' wrbyte temp1,a_reg ' A' to A jmp #fetch long $0[noparse][[/noparse]($ - OVERLAY_START) // 2] 'fill to even number of longs (REQUIRED) ex_af_af_ovl_end fit $1F0▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 12/15/2009 4:40:17 AM GMT
Self-compilation is a point I have been waiting for. Great news. I think you should start a thread just to point this out.
I will leave heater to look at your code.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
'exx overlay. org OVERLAY_START exx_ovl mov data_16,c_reg ' happens to be 0 ie regbase add data_16,#8 ' data_16 now points to the alt BC reg rdword data_8,c_reg ' get BC into data_8 (messy as storing 2 bytes in data_8) rdword temp1,data_16 ' BC' to temp1 wrword data_8,data_16 ' BC to BC' wrword temp1,c_reg ' BC' to BC add data_16,#2 ' point to DE' rdword data_8,e_reg ' get DE into data_8 rdword temp1,data_16 ' DE' to temp1 wrword data_8,data_16 ' DE to DE' wrword temp1,e_reg ' DE' to DE add data_16,#2 ' point to HL' rdword data_8,l_reg ' get HL into data_8 rdword temp1,data_16 ' HL' to temp1 wrword data_8,data_16 ' HL to HL' wrword temp1,l_reg ' HL' to HL jmp #fetch long $0[noparse][[/noparse]($ - OVERLAY_START) // 2] 'fill to even number of longs (REQUIRED) exx_ovl_end fit $1F0A message for heater. I'm now printing out a screen dump of the hex bytes 5 before and 5 after a break. I've just noticed that PC doesn't seem to point to the HALT instruction - it seems to point to the one after. Is that correct?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 12/15/2009 5:55:55 AM GMT
Now it's time to optimize EX. Did you look at Bill's post the other day? You can swap from A to A' with just this:
ROL a_reg,#16 ' <-- swap A and A' reg hub pointers
The idea is that a_reg is initialized by spin such that the low 16 bits are the HUB address of the A register and the high 16 bits are the A' register.
Now, in normal use things like "rdbyte data_8, a_reg" will pick up the A register OK because there is only 32K RAM so the upper 17 bits of a_reg are not used.
Then an EX using ROL puts the A register address in the high bits of a_reg and the A' into the low bits. So now "rdbyte data_8, a_reg" picks up the A' reg.
On the next EX a_reg is rolled back to it's initial state and points again at A.
The same for
ROL f_reg,#16 ' <-- swap F and F' reg hub pointers
Be sure to write flags out to HUB first.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I might have to leave optimisation to others. The code I've posted prints out all the registers and there is the attachment with the compiler to compile tiny test programs written in Wordstar. Maybe I'll be leaving a trail of destruction and badly written code [noparse]:)[/noparse] but a slow bit of code is still better than no code. Hopefully someone will get fired up and deeply passionate about the above comments and feel a strong desire to post a working bit of code that saves some longs!
I'm looking at the IX and IY instructions now. I want DDTZ to run so I at least can debug Z80 programs...
Ok, a pile of IX and IY instructions all check out. PUS, POP, writing and reading to random locations
; 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 ; push and pop IX all ok MAIN: LD A,5 LD IY,5000 LD (IY+100),A INC A LD A,(IY+100) HALT ;A should be 5, not 6 RET ; back to CP/M ENDI thought I would try running DDTZ and it is crashing at 2289H and the opcode before that is ED57. This is LD A,I and in the zicog it is
{57} long undocumented ' LD A,IAbove is its complementary instruction
{47} long not_implemented LD I,ANeither of these are really needed, and there are some R register ones that are not needed too. Unless maybe for random number generation.
I tried changing 'undocumented' to 'not_implemented' but it does a break either way. Is it possible to have an instruction that is just ignored?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 12/15/2009 1:18:42 PM GMT
heater or I will pick up the pieces if you can get the additional instruction op codes working. We are both busy at the moment.
As soon as I have the RamBlades ready to ship I will look at ZiCog to grab and fix the latest code to load to the uSD cards.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
in zicog.spin we change to
f_reg := (reg_base + 6) + ((reg_base + 14) << 16) ' Address of F reg in low word + address of F' reg in high word. a_reg := (reg_base + 7) + ((reg_base + 15) << 16) ' Address of A reg in low word + address of A' reg in high word.Now the guts of EX becomes:
rol a_reg, #16 ' Swap A address for A' address rol f_reg, #16 ' Swap F address for F' addressBe sure to write flags to HUB first.
Similar for the EXX regs.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Bit more tricky if the op you want ignore has an immediate operand or some other byte(s) following it. Then you do have to at least be sure to increment the PC appropriately.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Just from memory heater, did you finish doing all the IX and IY instructions? Were there others that you didn't get round to doing?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
WRBYTE cnt,a_reg
as a good implementation of LD A,R
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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