Dr_Acula said...
You are very good. How many coffees have you had today?
One was left over from last night and I heated it up in the microwave ... yes, really. Now I got me some biscuits and am in the process of making a fresh coffee... wondering what I do until your board arrives.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
I'm multitasking. My 12 year old son is doing negative number maths and I needed a quick way of testing the rules for negative addition and negative multiplication. Windows calculator won't let you type "-22" though it will let you type "22" then "-". But it is not entirely clear what happens to the next number. I don't need confusion - I'm trying to demonstrate a complete mastery of maths to a 12 year old.
So - fire up mbasic on a dracblade, and type "print -22*-10" and there is the answer to demonstrate the minus minus rule. I could have done that in vb.net but it would have taken over a minute to boot.
Addit - now he is doing long division in negative numbers. MBasic is getting a workout tonight!
Dr_Acula said...
Great news with your board arriving. And when you have two, it will be even better.
Yep! Mine is just a simple prototyping board with serial, TV out and some 10 LED bar, no keyboard or mouse. Cluso "the Cluso" 99 offered me a DIP RAM chip which I think I could use to extend this board to a TriBlade compatible...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
@Omikron: version 150 (_rr150) near the end of the TriBlade thread. There have been way too many revisions since then for me to keep up. I will wait until the actual ZiCog code is stable before back adding the improvements.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I used to think that the Z80 I grew up with was a simple little soul, having started to read the PDF I realize that what I was playing with was a lot more tricky. Thank heavens I was young and relativly fresh in thought !
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
I'll be interested to study this new LMM code. I'm particularly keen to look at MP/M at some stage, and that involves just a few lines of code to do the bank switching (currently commented out on the dracblade). LMM looks just the ticket. Even better down the track with Bill's SPI serial ram chips and caching.
Dr_A: Here is my current zicog.spin.
It has all overlay code removed and replaced with LMM. This one has the working DAA in LMM but many other Z80 ops that were overlays are now broken until the emulation code is adapted for LMM properly. 41 LONGs free in COG.
I removed the bank switched memory code from read/write routines for now because it was never tested and looks like it clobbers "address" which would break some ops that use read/write memory word. Also part of the quest to save longs.
I had it in the back of my mind to skip over CP/M 3 and try MP/M first. Reason being that MP/M is started by a command from running CP/M 2. I had a feeling it would make it easier to modify MP/Ms loader and BIOS for our hard disk only set up.
Not much point in trying MP/M without banked switched memory though.
Also MP/M should probably have a timer interrupt which would slow us down somewhat although I believe it is possible get it working without by putting the process switching in the I/O routines as you have suggested sometime ago. Should be OK as long as all running programs do actually poll some I/O frequently.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I was working with CP/M 2.2 often in 80's. But I never worked with CP/M 3.x. Is there a programmer manual for 3.x? I mean BDOS services and BIOS structures description.
I have another long you can save. Instead of this:
...
mov adj_60, #$60 'Set up adjustment values
mov adj_06, #$06
test flags, #neg_bit wz 'Negate adjustments if neg flag set
if_nz neg adj_60, adj_60
if_nz neg adj_06, adj_06
'If half carry or low nibble > 9 adjust by +/- 0x06
test flags, #aux_bit wz
cmp nibble, #$0A wc
if_nc_or_nz add data_8, adj_06
'If carry or A reg greater than 0x99 adjust by +/- 0x60
test flags, #carry_bit wz
cmp A, #$9A wc
if_nc_or_nz add data_8, adj_60
...
Do this:
...
mov adjust, #$06 'Set up adjustment value
test flags, #neg_bit wz 'Negate adjustments if neg flag set
if_nz neg adjust, adjust
'If half carry or low nibble > 9 adjust by +/- 0x06
test flags, #aux_bit wz
cmp nibble, #$0A wc
if_nc_or_nz add data_8, adjust
shl adjust, #4
'If carry or A reg greater than 0x99 adjust by +/- 0x60
test flags, #carry_bit wz
cmp A, #$9A wc
if_nc_or_nz add data_8, adjust
...
Yes, I know that long doesn't hurt.. it's just for the beauty of it
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Ok, your new LMM code works fine in the Dracblade. I'm not sure how to see how much memory it takes in the zicog cog, but overall in the hub memory the whole thing seems to have saved about 200 more longs. But that could be because you have some opcodes missing. Anyway 616 longs free now.
I made some changes - the memory driver code, a few variables, a couple of extra PUBs. I should try and Ifdef these in so there is one piece of 'standard' code rather than having to modify it each time.
Tested with mbasic, wordstar and the wireless network.
I found a variable in my original zicog code called ram_size that doesn't seem to do anything (and was using up a precious cog long) so I commented it out and no problems. So I commented it out on the LMM code and also, no problems. What is this variable for?
' additions James Moxham 14th March 2010 - these probably need to be wrapped up with an ifdef
' more variables to the CON section
' PUB DMA_Read and DMA_Write, changed ram driver code for latched ram
' added ram_z80 to beginning of the cog code in a DAT as a pointer for dma access
' removed this line ' ram_size := $FB00 '(1024 * msize) - $100 as ram_size variable not used anywhere else??
File is attached.
Do you now have enough room for banked memory? If so, what was the bit that was dodgy in the original code?
Addit - maybe don't incoroporate any of my changes into your code as yet - I'll wait till it is all tested and then do a copy across with changes and try to get the ifdef thing sorted. This post is to a)say that the LMM works fine and b) as a note to myself when I need to change future zicog versions for the dracblade.
Drac: IIRC Banked memory was never tested and it was required to be different in RamBlade to TriBlade because it embedded the sram access. Unfortunately still other things on my plate :-(
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Pullmoll: That only saves a long in HUB as it is LMM code and the adj_06 was going to become a general temp variable in COG anyway. Still I like it, I'll put it in.
Still can't see why LDD does not work. It's the pretty much the same code as LDI and they both work as overlay. Which makes me think the problem is not actually in LDD but in the LMM mechanism or execute loop or dispatch or somewhere else. So I won't look at any other ops until LDD works. Sadly not time to play for some days now.
Dr_A: Not sure how you got to 200 LONGs saved, I only made 116. There is some LMM code that is commented out for now so it will get a bit bigger again.
Do put any DracBlade code in between #ifdef..#endif and do use #else when there are options. Makes it easier to see what going on.
There is plenty of room for banked memory code now. The only reason the old code would not have worked is because it added offsets to "address" to get to banked memory in ext RAM. This turns out to be a no-no because a few users of read/write_memory_byte expect "address" not to be altered. I guess we can fix that quite easily.
It would be great if you can post a zicog.spin that works with DracBlade and has "ifdef etc. Then we will have a combined TriBlade/DracBlade and possibly other (VMCog) version for the first time.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater said...
Pullmoll: That only saves a long in HUB as it is LMM code and the adj_06 was going to become a general temp variable in COG anyway. Still I like it, I'll put it in.
Yes, I knew that. Still, it is 2 longs in the hub and 1 long if you join adjust with another cog long.
heater said...
Still can't see why LDD does not work. It's the pretty much the same code as LDI and they both work as overlay. Which makes me think the problem is not actually in LDD but in the LMM mechanism or execute loop or dispatch or somewhere else. So I won't look at any other ops until LDD works. Sadly not time to play for some days now.
I looked at the most recent zicog.spin and didn't see a reason why it could fail either. HL and DE are post decrementing and you have that. BC <> 0 set the parity flag. Everything should be all right.
If I look at EX.MAC then HL=msbt+3, DE=msbt+2 and BC=1 for the LDD test.
For LDI it is HL=msbt+2 DE=msbt and BC=1.
This means that both tests use the RAM at msbt ff. differently. msbt is the "machine state before test" memory range, which means that LDD is mangling the value of the msbt.IX range while LDI acts on msbt.IY. Anyway, all this should be reflected in the CRC.
It isn't fun to see that you're struggling from a similar problem as I do: invisible bugs [noparse]:([/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
I'm going to write those ops to a test prog and stick it where the ziboot gets loaded and set SINGLE_STEP on. This can't be so hard. I'm sure the problem is lurking somewhere out side of LDD. That is, lurking somewhere we are not looking[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Dr_A: If you want to see how much COG space is left in ZiCog use the "View -> Compiler Listing" option in BST. Then go to the ZiCog TAB and hit F8. After compilation the listing window shows all the code generated. Scroll down and find something like this:
There are 41 ($029) Longs left in the cog
Yep, my build has 41 spare longs, soon to be 42.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater said...
I'm going to write those ops to a test prog and stick it where the ziboot gets loaded and set SINGLE_STEP on. This can't be so hard. I'm sure the problem is lurking somewhere out side of LDD. That is, lurking somewhere we are not looking[noparse]:)[/noparse]
Of course. The problem is always sitting about 30 centimeters away from the monitor [noparse]:)[/noparse]
I found a stupid one in my code again. I had swapped the DD/FD CB disp8 XX table entries for RES and SET bit. DUH!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Re "Dr_A: If you want to see how much COG space is left in ZiCog use the "View -> Compiler Listing" option in BST. Then go to the ZiCog TAB and hit F8. After compilation the listing window shows all the code generated. Scroll down and find something like this:"
Can you walk me through that one again? I consistently get a long pause then "Compiler crashed". All the other objects give the correct information about size. Just not the zicog or the zicogLMM. Maybe you can't trick it with respect to running over the 2k size for a cog?
You will need a new/latest version of BST. There was a crashy problem in BST to do with upper case/lower case used in #defines. Like for example "#define TriBladeProp."
Be sure you have those defines in zicog.spin as normally they get picked up from the top level object and are not defined if you just compile zicog by itself.
Better still put them in the Project dialog box.
Alternatively, just compile everything from the top level as normal. After switching on the list view. Then the listing will contain all of the code in the project. You just have to scroll down further to find the cog usage message.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Attached is a zicog file with #ifdef for Dracblade. Some code ended up being the same as the Triblade and I was very pleased to take a guess and try
#ifdef TriBladeProp or Dracblade
and it works.
This version was yours from a few days ago. I hope you haven't added too much more of your code. If your code is 'complicated' then please send me your latest code.
Alternatively you can take your latest code, then go through this file looking for "Dracblade" and that should find all the changes.
This is a great moment - we have now managed to converge to one common file again. Now all the dracblade people can potentially join in with adding instructions.
A little while back I posted how to add a new instruction with overlays. Of course, now that information is out of date. I did a quick search for one of the new instructions and I have a bit of an idea how code is added but it would be helpful to read the "definitive" instructions.
Also = the view menu is very handy. Can you point me to the bit that says how much of a cog is used? I've got this bit - is that the information?
Object ZicogLMM
Object Base is 0D40
|===========================================================================|
Object Constants
|===========================================================================|
|===========================================================================|
VBASE Global Variables
|===========================================================================|
VBASE : 0000 LONG Size 0004 Variable cog
VBASE : 0004 LONG Size 0004 Variable cur_op
Dumb question. How are you doing EXX if you don't have access to the alternate register set?
Below is code I used to add the alternate registers in the zicog. Now commented out but easy to uncomment
reg_base := LONG[noparse][[/noparse]cpu_params] ' memory locations in hub that contain these variables
c_reg := reg_base + 0
b_reg := reg_base + 1
e_reg := reg_base + 2
d_reg := reg_base + 3
l_reg := reg_base + 4
h_reg := reg_base + 5
f_reg := reg_base + 6
a_reg := reg_base + 7
' bc_reg_alt := reg_base + 8 ' no room for these but values here for reference
' de_reg_alt := reg_base + 10
' hl_reg_alt := reg_base + 12
' af_reg_alt := reg_base + 14
' im_reg := reg_base + 16 ' this is not used at all,? delete
ix_reg := reg_base + 18
iy_reg := reg_base + 20
sp_reg := reg_base + 22
pc_reg := reg_base + 24
They were just copied from the Main routine
DAT
'The Z80 Registers.
'Do not change the order of these.
'Registers are defined in pairs as words so as to enable them to be
'accessed individually as BYTE or in pairs as WORD.
'The ordering makes it easier to find a register specified by a 3-bit
'register field within an op code or to swap between main and
'alternate register sets.
register_file word
bc_reg word 0
de_reg word 0
hl_reg word 0
af_reg word 0
bc_reg_alt word 0
de_reg_alt word 0
hl_reg_alt word 0
af_reg_alt word 0
im_reg word 0
ix_reg word 0
iy_reg word 0
sp_reg word 0
pc_reg word 0
Great stuff. No I have not had any time to change anything much in ZiCog so I'll probably be able to drop DracBlade code in easily.
It's not totally clear that overlays are dropped yet. This is an experiment after all. But it starts to look that way.
You just have to scroll down through all of the listing in that window. Eventually you will start to recognize a big lot of ZiCog PASM and you just have to find the cog usage statement in there.
Alternatively you can save the content of the listing view to a file, open that in an editor and search for the thing.
I've said it before and I'll say it again. ZiCog itself does not need definitions of the alternate registers.
How is that?
It has pointers to what it thinks are the registers in HUB. a_reg, b_reg, etc.
If we want to use an alternative register set we only have to point those pointers at different register definitions in HUB.
This is what EX, EXX should do. Should be smaller/faster than moving the register content around.
We could make a mutant Z80 with many register sets that way[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
So - fire up mbasic on a dracblade, and type "print -22*-10" and there is the answer to demonstrate the minus minus rule. I could have done that in vb.net but it would have taken over a minute to boot.
Addit - now he is doing long division in negative numbers. MBasic is getting a workout tonight!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Yep! Mine is just a simple prototyping board with serial, TV out and some 10 LED bar, no keyboard or mouse. Cluso "the Cluso" 99 offered me a DIP RAM chip which I think I could use to extend this board to a TriBlade compatible...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Did you read this?
http://sam.speccy.cz/asm/undoc_z80_documented.pdf
I used to think that the Z80 I grew up with was a simple little soul, having started to read the PDF I realize that what I was playing with was a lot more tricky. Thank heavens I was young and relativly fresh in thought !
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
http://busy.speccy.cz/tvorba/kodex.htm
Jim
Congratulations Heater, it shows the genuine interest in this work.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
By the way my latest LMM version of ZiCog has 41 LONGs free in the COG.
Sadly I've broken all the BIT/SET/RES instructions for now but they will be OK with new LMM code.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
It has all overlay code removed and replaced with LMM. This one has the working DAA in LMM but many other Z80 ops that were overlays are now broken until the emulation code is adapted for LMM properly. 41 LONGs free in COG.
I removed the bank switched memory code from read/write routines for now because it was never tested and looks like it clobbers "address" which would break some ops that use read/write memory word. Also part of the quest to save longs.
I had it in the back of my mind to skip over CP/M 3 and try MP/M first. Reason being that MP/M is started by a command from running CP/M 2. I had a feeling it would make it easier to modify MP/Ms loader and BIOS for our hard disk only set up.
Not much point in trying MP/M without banked switched memory though.
Also MP/M should probably have a timer interrupt which would slow us down somewhat although I believe it is possible get it working without by putting the process switching in the I/O routines as you have suggested sometime ago. Should be OK as long as all running programs do actually poll some I/O frequently.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I have another long you can save. Instead of this:
... mov adj_60, #$60 'Set up adjustment values mov adj_06, #$06 test flags, #neg_bit wz 'Negate adjustments if neg flag set if_nz neg adj_60, adj_60 if_nz neg adj_06, adj_06 'If half carry or low nibble > 9 adjust by +/- 0x06 test flags, #aux_bit wz cmp nibble, #$0A wc if_nc_or_nz add data_8, adj_06 'If carry or A reg greater than 0x99 adjust by +/- 0x60 test flags, #carry_bit wz cmp A, #$9A wc if_nc_or_nz add data_8, adj_60 ...Do this:
... mov adjust, #$06 'Set up adjustment value test flags, #neg_bit wz 'Negate adjustments if neg flag set if_nz neg adjust, adjust 'If half carry or low nibble > 9 adjust by +/- 0x06 test flags, #aux_bit wz cmp nibble, #$0A wc if_nc_or_nz add data_8, adjust shl adjust, #4 'If carry or A reg greater than 0x99 adjust by +/- 0x60 test flags, #carry_bit wz cmp A, #$9A wc if_nc_or_nz add data_8, adjust ...Yes, I know that long doesn't hurt.. it's just for the beauty of it
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Ok, your new LMM code works fine in the Dracblade. I'm not sure how to see how much memory it takes in the zicog cog, but overall in the hub memory the whole thing seems to have saved about 200 more longs. But that could be because you have some opcodes missing. Anyway 616 longs free now.
I made some changes - the memory driver code, a few variables, a couple of extra PUBs. I should try and Ifdef these in so there is one piece of 'standard' code rather than having to modify it each time.
Tested with mbasic, wordstar and the wireless network.
I found a variable in my original zicog code called ram_size that doesn't seem to do anything (and was using up a precious cog long) so I commented it out and no problems. So I commented it out on the LMM code and also, no problems. What is this variable for?
' additions James Moxham 14th March 2010 - these probably need to be wrapped up with an ifdef
' more variables to the CON section
' PUB DMA_Read and DMA_Write, changed ram driver code for latched ram
' added ram_z80 to beginning of the cog code in a DAT as a pointer for dma access
' removed this line ' ram_size := $FB00 '(1024 * msize) - $100 as ram_size variable not used anywhere else??
File is attached.
Do you now have enough room for banked memory? If so, what was the bit that was dodgy in the original code?
Addit - maybe don't incoroporate any of my changes into your code as yet - I'll wait till it is all tested and then do a copy across with changes and try to get the ifdef thing sorted. This post is to a)say that the LMM works fine and b) as a note to myself when I need to change future zicog versions for the dracblade.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 3/14/2010 1:32:57 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)·
· 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
Still can't see why LDD does not work. It's the pretty much the same code as LDI and they both work as overlay. Which makes me think the problem is not actually in LDD but in the LMM mechanism or execute loop or dispatch or somewhere else. So I won't look at any other ops until LDD works. Sadly not time to play for some days now.
Dr_A: Not sure how you got to 200 LONGs saved, I only made 116. There is some LMM code that is commented out for now so it will get a bit bigger again.
Do put any DracBlade code in between #ifdef..#endif and do use #else when there are options. Makes it easier to see what going on.
There is plenty of room for banked memory code now. The only reason the old code would not have worked is because it added offsets to "address" to get to banked memory in ext RAM. This turns out to be a no-no because a few users of read/write_memory_byte expect "address" not to be altered. I guess we can fix that quite easily.
It would be great if you can post a zicog.spin that works with DracBlade and has "ifdef etc. Then we will have a combined TriBlade/DracBlade and possibly other (VMCog) version for the first time.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Yes, I knew that. Still, it is 2 longs in the hub and 1 long if you join adjust with another cog long.
I looked at the most recent zicog.spin and didn't see a reason why it could fail either. HL and DE are post decrementing and you have that. BC <> 0 set the parity flag. Everything should be all right.
If I look at EX.MAC then HL=msbt+3, DE=msbt+2 and BC=1 for the LDD test.
For LDI it is HL=msbt+2 DE=msbt and BC=1.
This means that both tests use the RAM at msbt ff. differently. msbt is the "machine state before test" memory range, which means that LDD is mangling the value of the msbt.IX range while LDI acts on msbt.IY. Anyway, all this should be reflected in the CRC.
It isn't fun to see that you're struggling from a similar problem as I do: invisible bugs [noparse]:([/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
There are 41 ($029) Longs left in the cog
Yep, my build has 41 spare longs, soon to be 42.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Of course. The problem is always sitting about 30 centimeters away from the monitor [noparse]:)[/noparse]
I found a stupid one in my code again. I had swapped the DD/FD CB disp8 XX table entries for RES and SET bit. DUH!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Can you walk me through that one again? I consistently get a long pause then "Compiler crashed". All the other objects give the correct information about size. Just not the zicog or the zicogLMM. Maybe you can't trick it with respect to running over the 2k size for a cog?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Be sure you have those defines in zicog.spin as normally they get picked up from the top level object and are not defined if you just compile zicog by itself.
Better still put them in the Project dialog box.
Alternatively, just compile everything from the top level as normal. After switching on the list view. Then the listing will contain all of the code in the project. You just have to scroll down further to find the cog usage message.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Attached is a zicog file with #ifdef for Dracblade. Some code ended up being the same as the Triblade and I was very pleased to take a guess and try
#ifdef TriBladeProp or Dracblade
and it works.
This version was yours from a few days ago. I hope you haven't added too much more of your code. If your code is 'complicated' then please send me your latest code.
Alternatively you can take your latest code, then go through this file looking for "Dracblade" and that should find all the changes.
This is a great moment - we have now managed to converge to one common file again. Now all the dracblade people can potentially join in with adding instructions.
A little while back I posted how to add a new instruction with overlays. Of course, now that information is out of date. I did a quick search for one of the new instructions and I have a bit of an idea how code is added but it would be helpful to read the "definitive" instructions.
Also = the view menu is very handy. Can you point me to the bit that says how much of a cog is used? I've got this bit - is that the information?
Object ZicogLMM
Object Base is 0D40
|===========================================================================|
Object Constants
|===========================================================================|
|===========================================================================|
VBASE Global Variables
|===========================================================================|
VBASE : 0000 LONG Size 0004 Variable cog
VBASE : 0004 LONG Size 0004 Variable cur_op
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 3/14/2010 10:02:24 AM GMT
Below is code I used to add the alternate registers in the zicog. Now commented out but easy to uncomment
They were just copied from the Main routine
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Great stuff. No I have not had any time to change anything much in ZiCog so I'll probably be able to drop DracBlade code in easily.
It's not totally clear that overlays are dropped yet. This is an experiment after all. But it starts to look that way.
You just have to scroll down through all of the listing in that window. Eventually you will start to recognize a big lot of ZiCog PASM and you just have to find the cog usage statement in there.
Alternatively you can save the content of the listing view to a file, open that in an editor and search for the thing.
I've said it before and I'll say it again. ZiCog itself does not need definitions of the alternate registers.
How is that?
It has pointers to what it thinks are the registers in HUB. a_reg, b_reg, etc.
If we want to use an alternative register set we only have to point those pointers at different register definitions in HUB.
This is what EX, EXX should do. Should be smaller/faster than moving the register content around.
We could make a mutant Z80 with many register sets that way[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
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 ||.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller