Toby: Mike NZ should be sending you a PM about the Nascom.
heater: I am still looking for my old fashioned clunky morse key. I threw a lot of stuff out in 2000 when we moved. Hoping that didn't go too. Not that I ever got my morse ticket. But the real thing is all my Motorola kits and Z80 kits, plus tubes of new Z80's and SCC's etc that got thrown out (sold for scrap along with my mini computers).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
This is a special present for Heater. Wordstar running on a single propeller as a standalone computer with keyboard and display driver and sd card.
Ok, it is slow to load (because the ram DMA is in spin and needs to be ported over to pasm. A couple of hours work)
It also needs tweaking as the wordstar version is using 24 lines and the prop terminal program is set up for 40 lines. Need to edit a wordstar overlay file (which isn't too hard). So - lots more lines of text. Sweet!
I made it green screen as it is getting close to the capacity of the internal memory of the propeller and some of the vga driver code for multiple colors was not needed. But with optimisation I think it can go back in.
8080 codes work fine. VT100 codes also work fine. The spin code scans both the serial port input for keypresses (from the PC) and also the local keyboard and sends both through to CP/M. The output goes to both the PC terminal program and to the vga display. (and given there is a nifty 20x4LCD display object in the obex, I'll also send it to a small LCD display).
8x 8mb hard drives. Two serial ports.
The code is a mess as it includes lots of commented out lines and lots of triblade ifdefs that actually should be dracblade ifdefs. I need to take the latest version of Cluso's code ((I'm on 127) and rebuild it properly so it has the triblade or the dracblade. An other hour or two of coding, but all straightforward to do.
Eventually I'll need to take a close look at trying to go back to Z80 codes. Then again, I never really use many as I tend to use only 8080 codes but write assembly in Z80 mnemonics. Indeed (and intriguingly), the only unique Z80 code I really like is DJNZ, which I see has found its way into PASM.
I have a new board on the way. It has onboard switchers for both 3V3 and 5V and has the wirelinks fixed. Also some pins were changed so the SD card pins are now grouped together. Once that arrives next week and I can prove it works, I might see my way clear to sending a few freebies to anyone that is keen to give this a go.
The catch. There is always a catch. It is about 2/3 of the speed of the triblade. I think it would be up to the user to decide on speed vs cost.
The upside - pacman runs at a *normal* speed, so it is possible to win!!
How much space have you got left in HUB ? Going to full Z80 also eats HUB space with extra dispatch tables.
Yep, you now have unenviable job of getting it to compile and run for both TriBlade and DracBlade. I imagine we are running into some messy "#ifdef" soup by now.
Hmm..freebies [noparse]:)[/noparse]
Perhaps you should put up a DracBlade thread so the future DracBlade followers can find what they need.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Yes, you need a DracBlade thread describing the hardware. Then we will have 3+ places to look for code. OUCH!
Had my TriBlade running today for the first time since the 3rd Adelaide propfest. It has done some travelling - Surfers, Gosford, Adelaide, Gosford, Surfers, Gosford. At least I didn't leave it on a bus LOL.
I will have to download TeraTerm. James, are there any tricks to get running with wordstar ???
heater: did you look at the ZiCog code where I found 8 longs. Found another 2. Slightly faster too. But of course I want to use them to speedup the emulation - fetching words would be a nice improvement in speed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
No time to fire up any prop code. I'm running about a lot, on that damn bus, just have odd moments to ramble on here.
Anyway, all changes to the zicog emulation itself need checking by running the instruction set test program EXZ80DOC.COM. If that passes at least as well normal I'd be more than happy with any optimizations anyone can come up with. Problem is it takes a good long time to run.
Note: Must use CPU_Z80 and EXZ80DOC.COM. There is also an EX8080.COM that tests 8080 only op-codes only but as we are setting the flags like a Z80 it fails pretty much every test. Perhaps one day the will be a shed load more #ifdefs to get the 8080 flag setting right.
EXZ80ALL.COM tests against undocumented flag register bit settings which I've never bothered to look into.
WORD read/writes would be great if you can find enough space to put the extra code in.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Yes, ok three threads it may have to be. This board isn't quite ready yet though for prime time so I hope it is ok to keep posting here for the moment...
Re how much space free, BST tells me that the program is 4800 longs, the variable list is 1518 longs and there are 1870 longs free. I don't think the ifdefs will be too bad - it should be possible for instance to put most of it in a single big group at the bottom of the existing code as a single ifdef.
And as a shameless plug for BST, the quick F10 compile/test/run has greatly sped up development.
Next little job is to replicate the triblade driver as a dracblade driver, and that should simplify the ifdef situation even further.
James: No problems - keep it here until you have fully spec'd hw.
The space problems are in the ZiCog cog for your extra code, and hub only in heater's DemoBoard platform (no SRAM) where every bit of space is required for CPM.
To see how much ZiCog space is available place some nop's at the beginning of the ZiCog code after outx and before the jmp #fetch. After this instruction it will be removed by bst as unused code!
I have a little time over the next few days so I will try and get the new fsrw running on ZiCog/TriBlade. Whether it works or not, I think it is time for a V1.0 release, arts and all, so I will liase with heater on this.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
This picture is a bit blurry but it demonstrates writing an SBasic program in the N8VEM IDE and then hitting a 'compile' button and downloading and running it on the Propeller. For a small program compiled by shelling the SIMH and downloading the .COM it takes about 10 seconds. Alternatively, the program can be downloaded compiled on the Propeller and this takes about 20 seconds. Both are 'one click' options, much like the F10 option for compiling the entire Zicog (which in itself is about 10 seconds).
So the development cycle for writing code is fast.
The N8VEM IDE has a number of 'one click' options, including downloading batches of files using xmodem. A batch of files might be the Wordstar group, or the BDS C group. This all is working brilliantly on the propeller.
What is new today is the Dracblade driver in PASM. This is the same as the Triblade driver, so the concept here is that you drop in a single object depending on the hardware. The code is now greatly simplified. The main differences now with the Triblade code is the startup code for the keyboard and vga, duplicating UART.tx("A") with VGATEXT.OUT("A") for diagnostic messages, and some extra code at the bottom included as a single #ifdef that handles the VT100 terminal.
Bootup is *fast*. Indeed, with a cathode ray monitor switched off at the powerpoint, and switching both the monitor and the propeller on at the same time, the A> is ready for use about the same time as the monitor is warmed up. Since when has Windows been able to do that?!
@Cluso, if it is ok with you, I'd like to try to combine these two projects into one source code, with suitable #ifdefs? I've looked through the code and I don't think it will decrease the readability of the triblade code as the dracblade will largely replicate the triblade as an alternate group of ifdef code. Do you have a copy of your latest version by any chance? OR - would you prefer I wait till 1.0 comes out?
Re the zicog in Z80, I'm over by 14 longs.
I might be able to save a few as I have
Zero long %00000000_00000000_00000000_00000000
mov dira,zero ' tristate all pins
Is this the same as mov dira,0 ?, ie specifically, given that constants seem to be limited to 9 bits, does mov dira,0 tristate bits 10 up?
That might save a little.
Then I've also noticed that the entire ram driver only uses pins 0-15. So, instead of
LatchDirection long %00000000_00000000_00011101_11111111
Is it possible to substitute a word instead of a long? (assuming that pins 16-31 are definitely all tristated).
If you want to put the DracBlade driver within the TriBlade driver and select by #ifdef, that is fine by me. I guess, as we add other platforms, it will only be necessary to issue one set of software files which will be simpler.
Would you like to email me your ZiCog code and I will see if I can find some longs for you. I am not confident though. Heater maybe able to put one of the Z80 resident opcodes into an overlay to save the space for you.
I think mov dira,#0 is legitimate.
The latch direction is in the cog, so it has to be long.
I don't think I have done anything to the code (except the ZiCog.spin yesterday) since I gave you the latest - it is only comments and I can add them easily. email me on when you are available and I can hook up skype.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Ok, doing mov dira,0 doesn't work
Changing longs to words doesn't work either (it did work but only with one variable, and then I needed to pad it anyway so the dispatch tables lined up.
I shaved two nops on the ram and now it is only over by 12 longs.
I haven't put in the changes you suggested on the zicog thread but I think you shaved another ?2 longs
Re the code, I commented out these lines:
'#ifdef TriBladeProp
'the following are also used as variables later...
'The TriBladeProp Blade #2 driver presets the latch to enable SRAM -CE(U23)=0 and hold LE=0
'datax mov outa, ram_latched '-WE=1 -OE=1, all other bits=0
'outx mov dira, ram_dir_read ' setup direction to read
'#endif
and then the ramd driver code is below. Otherwise the zicog is unchanged.
GateHigh long %00000000_00000000_00000001_00000000 ' HC138 gate high, all others must be low
Outx long %00000000_00000000_00000000_00000000 ' temp variable ' for temp use, same as n in the spin code
LatchDirection long %00000000_00000000_00011101_11111111 ' 138 active, gate active and 8 data lines active
LatchDirection2 long %00000000_00000000_00011101_00000000 ' for reads so data lines are tristate till the read
LowAddress long %00000000_00000000_00001001_00000000 ' low address latch = xxx010xx and gate high xxxxxxx1
MiddleAddress long %00000000_00000000_00001101_00000000 ' middle address latch = xxx011xx and gate high xxxxxxx1
'ReadEnable long %00000000_00000000_00000001_00000000 ' /RD = xxx111xx and gate high xxxxxxx1
' commented out as the same as GateHigh
WriteEnable long %00000000_00000000_00011101_00000000 ' /WE = xxx111xx and gate high xxxxxxx1
Zero long %00000000_00000000_00000000_00000000 ' for tristating all pins
read_memory_byte
call #RamAddress ' sets up the latches with the correct ram address
mov dira,LatchDirection2 ' for reads so P0-P7 tristate till do read
mov outa,GateHigh ' actually ReadEnable but they are the same
andn outa,GateHigh ' set gate low
' nop ' short delay to stabilise
nop ' none does not work, 1 does work
mov data_8, ina ' read SRAM
and data_8, #$FF ' extract 8 bits
or outa,GateHigh ' set the gate high again
mov dira,zero ' tristate all pins
read_memory_byte_ret ret
write_memory_byte
call #RamAddress ' sets up the latches with the correct ram address
mov outx,data_8 ' get the byte to output
and outx, #$FF 'ensure upper bytes=0
or outx,WriteEnable ' or with correct 138 address
mov outa,outx ' send it out
andn outa,GateHigh ' set gate low
' nop ' no nop doesn't work, one does, so put in two to be sure
nop ' another NOP
or outa,GateHigh ' set it high again
mov dira,zero ' tristate all pins
write_memory_byte_ret ret
RamAddress ' sets up the ram latches. Assumes high latch A16-A18 low so only accesses 64k of ram
mov dira,LatchDirection ' set up the pins for programming latch chips
mov outx,address ' get the address into a temp variable
and outx,#$FF ' mask the low byte
or outx,LowAddress ' or with 138 low address
mov outa,outx ' send it out
andn outa,GateHigh ' set gate low
' ?? a NOP
or outa,GateHigh ' set it high again
' now repeat for the middle byte
mov outx,address ' get the address into a temp variable
shr outx,#8 ' shift right by 8 places
and outx,#$FF ' mask the low byte
or outx,MiddleAddress ' or with 138 middle address
mov outa,outx ' send it out
andn outa,GateHigh ' set gate low
or outa,GateHigh ' set it high again
RamAddress_ret ret
If you can see an optimisation that would be great!
Has to be "mov dira,#0" - which I use all the time [noparse]:)[/noparse]
Dr_Acula said...
Ok, doing mov dira,0 doesn't work
Changing longs to words doesn't work either (it did work but only with one variable, and then I needed to pad it anyway so the dispatch tables lined up.
I shaved two nops on the ram and now it is only over by 12 longs.
I haven't put in the changes you suggested on the zicog thread but I think you shaved another ?2 longs
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ 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
Here is the first optimisation - saves 3 longs but is slower
GateHigh long %00000000_00000000_00000001_00000000 ' HC138 gate high, all others must be low
LatchDirection long %00000000_00000000_00011101_11111111 ' 138 active, gate active and 8 data lines active
LatchDirection2 long %00000000_00000000_00011101_00000000 ' for reads so data lines are tristate till the read
LowAddress long %00000000_00000000_00001001_00000000 ' low address latch = xxx010xx and gate high xxxxxxx1
MiddleAddress long %00000000_00000000_00001101_00000000 ' middle address latch = xxx011xx and gate high xxxxxxx1
'ReadEnable long %00000000_00000000_00000001_00000000 ' /RD = xxx111xx and gate high xxxxxxx1
' commented out as the same as GateHigh
WriteEnable long %00000000_00000000_00011101_00000000 ' /WE = xxx111xx and gate high xxxxxxx1
Zero long %00000000_00000000_00000000_00000000 ' for tristating all pins
outx long $0 ' temp variable ' for temp use, same as n in the spin code
addrx long $0
read_memory_byte
call #RamAddress ' sets up the latches with the correct ram address
mov dira,LatchDirection2 ' for reads so P0-P7 tristate till do read
mov outa,GateHigh ' actually ReadEnable but they are the same
call LatchItRead
mov data_8,outx ' get the data read
and data_8, #$FF ' extract 8 bits
mov dira,zero ' tristate all pins
read_memory_byte_ret ret
write_memory_byte
call #RamAddress 'sets up the latches with the correct ram address
mov outx,data_8 'get the byte to output
mov addrx,WriteEnable 'or with correct 138 address
call LatchIt
mov dira,zero 'tristate all pins
write_memory_byte_ret ret
RamAddress ' sets up the ram latches. Assumes high latch A16-A18 low so only accesses 64k of ram
mov dira,LatchDirection
mov outx,address 'set address 0-7 (& 8-15)
mov addrx,LowAddress 'set the Low Address
call LatchIt
mov outx,address
ror outx,#8 'set address 8-15
mov addrx,MiddleAddress 'set the Middle Address
call LatchIt
RamAddress_ret ret
LatchIt and outx,#$FF ' mask the low byte (data/address byte)
or outx,addrx ' or with 138 mask
mov outa,outx ' send it out
LatchItRead andn outa,GateHigh ' set gate low
nop ' ?? a NOP
mov outx,ina ' read SRAM (in case it is a read)
or outa,GateHigh ' set it high again
LatchIt_ret ret
Here is a second - another saving of 3 longs. Note the immediate values - they should work
GateHigh equ %1_00000000 ' HC138 gate high, all others must be low
LatchDirection2 equ %0_11111111 ' for reads so data lines are tristate till the read
Zero equ $0 ' for tristating all pins
DAT
'GateHigh long %00000000_00000000_00000001_00000000 ' HC138 gate high, all others must be low
LatchDirection long %00000000_00000000_00011101_11111111 ' 138 active, gate active and 8 data lines active
'LatchDirection2 long %00000000_00000000_00011101_00000000 ' for reads so data lines are tristate till the read
LowAddress long %00000000_00000000_00001001_00000000 ' low address latch = xxx010xx and gate high xxxxxxx1
MiddleAddress long %00000000_00000000_00001101_00000000 ' middle address latch = xxx011xx and gate high xxxxxxx1
'ReadEnable long %00000000_00000000_00000001_00000000 ' /RD = xxx111xx and gate high xxxxxxx1
' commented out as the same as GateHigh
WriteEnable long %00000000_00000000_00011101_00000000 ' /WE = xxx111xx and gate high xxxxxxx1
'Zero long %00000000_00000000_00000000_00000000 ' for tristating all pins
outx long $0 ' temp variable ' for temp use, same as n in the spin code
addrx long $0
read_memory_byte
call #RamAddress ' sets up the latches with the correct ram address
' mov dira,LatchDirection2 ' for reads so P0-P7 tristate till do read
andn dira,#LatchDirection2 ' for reads so P0-P7 tristate till do read
mov outa,#GateHigh ' actually ReadEnable but they are the same
call LatchItRead
mov data_8,outx ' get the data read
and data_8, #$FF ' extract 8 bits
mov dira,#zero ' tristate all pins
read_memory_byte_ret ret
write_memory_byte
call #RamAddress 'sets up the latches with the correct ram address
mov outx,data_8 'get the byte to output
mov addrx,WriteEnable 'or with correct 138 address
call LatchIt
mov dira,#zero 'tristate all pins
write_memory_byte_ret ret
RamAddress ' sets up the ram latches. Assumes high latch A16-A18 low so only accesses 64k of ram
mov dira,LatchDirection
mov outx,address 'set address 0-7 (& 8-15)
mov addrx,LowAddress 'set the Low Address
call LatchIt
mov outx,address
ror outx,#8 'set address 8-15
mov addrx,MiddleAddress 'set the Middle Address
call LatchIt
RamAddress_ret ret
LatchIt and outx,#$FF ' mask the low byte (data/address byte)
or outx,addrx ' or with 138 mask
mov outa,outx ' send it out
LatchItRead andn outa,#GateHigh ' set gate low
nop ' ?? a NOP
mov outx,ina ' read SRAM (in case it is a read)
or outa,#GateHigh ' set it high again
LatchIt_ret ret
Now that saves 6 longs plus the 8 I saved yesterday.. So it should now fit provided I have correctly redone your code :-)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
- you don't need "GateHigh" as you can use the constant "#$100"
Saves you one long!
Dr_Acula said...
Ok, doing mov dira,0 doesn't work
Changing longs to words doesn't work either (it did work but only with one variable, and then I needed to pad it anyway so the dispatch tables lined up.
I shaved two nops on the ram and now it is only over by 12 longs.
I haven't put in the changes you suggested on the zicog thread but I think you shaved another ?2 longs
If you can see an optimisation that would be great!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ 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
Thanks ++ for those suggestions. I can't wait to get home from work tonight and try this out.
I'm still trying to get the hang of mixing up a 32 bit processor with 8 bits, 16 bits and 9 bit constants. If code space wasn't an issue (as it isn't generally in Spin) then I guess it is just easier to do everything in longs.
So to clarify, mov myvalue, #nn will work with #nn from 0 to $1FF? But mov outa,#0 will tristate all 32 pins?
And if I have a long and I OR it with a constant, and the constant only goes up to $1FF, then do the bits above bit 9 remain unchanged?
What would happen if you did an AND with a constant? would the bits above bit 9 remain unchanged, or are they ANDed with a hidden value of either 0 or 1?
Another thought - can outa be used as a register? I'm thinking of the code where it starts with a value in outx, does some bit manipulation on that then about half way through puts that into outa and then does some more bit manipulation. So long as the 138 latch bit always stays high or tristate through this process, it won't really matter if the other lines are going on and off as the pins are set up. Could this then mean outx isn't needed as a variable??
I'll ponder that a bit more as it might be that the changes already made have resulted in enough savings. Cluso, are you up to 8 longs already in other parts of the code?
Ultimately all Prop ops are 32 bits wide. If you use a literal value (with the #) you get to specify only the low 9 bits, the other 23 being zeros. So you can work out what AND, OR, etc do from that.
No reason you can't use outa as a register. Well, it IS a register. Execute an instruction from it if you want to "JMP #OUTA"
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
James: As heater said, the #$00-#$1FF are zero extended by the hardware, so any instruction will just make the remaining bits zero. It is a neat trick we use.
There are 4 to 6? usable shaddow memory locations in the cog ram register range $1F0-$1FF that can be used. I use them for my zero footprint debugger which wholy resides in the shaddow ram and executes from there. It is tricky to use but as a last resort it's there. There is DIRB, INB, OUTB.
I already found 8 longs in the ZiCog.spin I posted 2 days ago. I re-used 2 instructions which were only executed on startup for temporary locations (datax & outx ??). I found address_stash and ???_stash could also find an instruction only used on startup.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Got there - the zicog now fits on the dracblade with Z80 opcodes and precisely zero longs spare!
Optimisations:
1) - Cluso's 8 longs saved in rr128
2) Realising that WriteEnable and LatchDirection2 in my variables were the same thing
3) Using andn outa,#$100 ' set gate low using a constant rather than a long. This saved code in many places.
4) I didn't end up needing the LatchIt optimisations so speed is still the same
5) removing multiple instances of
'#ifdef TriBladeProp
' mov dira, ram_dir_input 'RR20090321 (pass I/O to another cog)
'#endif
as I'm pretty sure my dira gets set explicitly with each memory call. Unless I misunderstand this bit of code.
and 6) - the one that might be controversial: At the beginning of the zicog is this:
DAT
org 0
entry
OVERLAY_LOAD_RET
' jmp #RESIDENT_CODE 'Go execute resident code first (loaded automatically at CogNew)
'Can use as a RET instruction AFTER execution of the loaded overlay
'---------------------------------------------------------------------------------------------------------
'RESIDENT ROUTINES follow...
'
RESIDENT_CODE
and as shown above, I commented out the jmp #resident_code
It still seems to work but am I missing something with this jump to the very next label in the code?
**postedit - attached is my collection of useful Z80 assembly routines with low level CP/M calls like print to the screen, file I/O, math and strings. Compilation off board and download using the N8VEM editor takes about 5 seconds. All works perfectly though it doesn't use all the instructions, so I'm going to leave it running overnight with the EXZ80DOC program.
Drac, the jmp #resident_code is modified if heater uses the overlay as a call. I cannot answer if this is used or not, because the overlay mechanism I wrote allows a few options. Try comenting out the label OVERLAY_LOAD_RET. If it still compiles then it is ok, if not then you may get wierd results because the next instruction will be modified with a call return address.
So if I understand correctly you have 1 long to find if you need the above instruction. Is there any code you execute once on startup? address_stash can be placed on this instruction and save a long. Use DIRB as a register to save & restore for address_stash. This will give you 1 long.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Yes I thought the jmp resident_code looked a bit easy. It might also explain a few fails in the instruction exercisier.
So--- need to look at those other options. I looked at address_stash (and the other stash one)and outx but they seem to both be used as part of the same routine (ie stash/read/restore from stash)so no luck there. Ditto using data_8 as a working variable inside the read/write routines.
You have to be careful using the registers as memory storage as not all are read/write and there is also shaddow ram underneath them.
But you can (should be able) to use the DIRB as a temp storage location without problems. So just change address_stash or data_stash to DIRB - IIRC data-stash is only used once so it is an easier mod.
The simpler the mod the better
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I tried something else. There is a variable 'nibble' in the main zicog code. I searched through and could only find this variable in the DAA overlay. So I fingured maybe it could be moved to the overlay? eg comment it out here
'---------------------------------------------------------------------------------------------------------
'Z80 String operation parts
'---------------------------------------------------------------------------------------------------------
'Misc variables
alu long 0
aux long 0
'nibble long 0
mask_bit_16 long $0001_0000
mask_low_word long $0000_FFFF
cmd_pending long 0
and put it at the end of the overlay.
daa_ovl
rdbyte data_8, a_reg
mov nibble, data_8 'Isolate low nibble of accumulator
and nibble, #$0F
cmp nibble, #10 wc 'Test for greater than 9
test flags, #aux_bit wz 'Test auxillary carry
if_nz_or_nc add data_8, #$06 'Add 6 to accumulator if greater than 9 or AUX carry
add nibble, #6 'Check for AUX carry from low nibble
test nibble, #%00010000 wz
muxnz flags, #aux_bit 'and set AUX flag if so.
mov nibble, data_8 'Isolate high nibble of accumulator
shr nibble, #4
cmp nibble, #10 wc 'Test for greater than 9
test flags, #carry_bit wz 'Test carry flag
if_nz_or_nc add data_8, #$60 'Add (6 << 4) to accumulator if greater than 9 or carry
test data_8, #$100 wz 'Check for 8 bit carry out
if_nz or flags, #carry_bit 'Set carry flag if so (N.B. Do NOT clear carry if not so)
and data_8, #$FF wz, wc
muxz flags, #zero_bit 'Set Z80 zero flag from props zero
muxnc flags, #parity_bit
test data_8, #128 wz
muxnz flags, #sign_bit
wrbyte data_8, a_reg
jmp #fetch
nibble long 0
long $0[noparse][[/noparse]($ - OVERLAY_START) // 2] 'fill to even number of longs (REQUIRED)
daa_ovl_end
fit $1F0
This gives me the long I need. Compiles fine. Also tested it with a quick program in assembly and traced it through with DDT. Put 0B2H into
the A register and it returns 12 which is correct as B+6=decimal 17 which is 16+1, and the 2 stays the same. Gives the same result as it gave before.
Wasn't Turbulence using the "output pins" as fast storage. The first time I ran it, it was on my early Z80 bd which was laden with debug LEDs. They were almost as entertaining as the VGA output.
Dr_A
I have mused on the decoder and latch bits of Dracblade, they will fit int a XC9536XL (·LCD not implimented )·One spare pin and only 66% used innards, although I havent floorplanned it yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Post Edited (Toby Seckshund) : 11/20/2009 2:09:04 PM GMT
Moving nibble I'm sure is just fine. It will slow down DAA as it's another long to load. We don't much care about the speed of DAA.
Actually thinking about it, generally moving data from "resident" to overlay in what is the biggest overlay would not gain you any space. After all that just makes the resident area smaller and the required overlay area bigger. But there is the fact that overlays have to be an even number of LONGS in size. So perhaps we are lucky and the nibble just moves into a place that would be padded out with zero anyway. In which case there is no loss in speed either.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
bst optimises so if it's not used it's probably not in the compiled code. I fell into that trap trying to add dummy longs to find out how many longs were left in the cog.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
"bst optimises so if it's not used it's probably not in the compiled code"
As far as I can tell this is NOT true for LONGs in PASM. I've just tried it again with simple test prog with all optimizations turned on.
For sure it would be very bad to just remove along from the middle of PASM which could well beak some code that depends on the offsets of things. Unlike Spin it is very dangerous to remove away code from assembly languages.
I have used the trick of adding "unused long 0[noparse][[/noparse]43]" as dummy longs before a "fit" statement to determine the amount of free space. But you don't need to, BST tells us in the listing file output.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater: I am still looking for my old fashioned clunky morse key. I threw a lot of stuff out in 2000 when we moved. Hoping that didn't go too. Not that I ever got my morse ticket. But the real thing is all my Motorola kits and Z80 kits, plus tubes of new Z80's and SCC's etc that got thrown out (sold for scrap along with my mini computers).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Ok, it is slow to load (because the ram DMA is in spin and needs to be ported over to pasm. A couple of hours work)
It also needs tweaking as the wordstar version is using 24 lines and the prop terminal program is set up for 40 lines. Need to edit a wordstar overlay file (which isn't too hard). So - lots more lines of text. Sweet!
I made it green screen as it is getting close to the capacity of the internal memory of the propeller and some of the vga driver code for multiple colors was not needed. But with optimisation I think it can go back in.
8080 codes work fine. VT100 codes also work fine. The spin code scans both the serial port input for keypresses (from the PC) and also the local keyboard and sends both through to CP/M. The output goes to both the PC terminal program and to the vga display. (and given there is a nifty 20x4LCD display object in the obex, I'll also send it to a small LCD display).
8x 8mb hard drives. Two serial ports.
The code is a mess as it includes lots of commented out lines and lots of triblade ifdefs that actually should be dracblade ifdefs. I need to take the latest version of Cluso's code ((I'm on 127) and rebuild it properly so it has the triblade or the dracblade. An other hour or two of coding, but all straightforward to do.
Eventually I'll need to take a close look at trying to go back to Z80 codes. Then again, I never really use many as I tend to use only 8080 codes but write assembly in Z80 mnemonics. Indeed (and intriguingly), the only unique Z80 code I really like is DJNZ, which I see has found its way into PASM.
I have a new board on the way. It has onboard switchers for both 3V3 and 5V and has the wirelinks fixed. Also some pins were changed so the SD card pins are now grouped together. Once that arrives next week and I can prove it works, I might see my way clear to sending a few freebies to anyone that is keen to give this a go.
The catch. There is always a catch. It is about 2/3 of the speed of the triblade. I think it would be up to the user to decide on speed vs cost.
The upside - pacman runs at a *normal* speed, so it is possible to win!!
Back to coding...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
Post Edited (Dr_Acula) : 11/17/2009 3:45:59 AM GMT
I just posted a version of ZiCog that saves another 8 longs. There are probably other savings but I didn't look closely.
Probably need to profile the instruction set usage to find out what are most used.
Are you home today???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
How much space have you got left in HUB ? Going to full Z80 also eats HUB space with extra dispatch tables.
Yep, you now have unenviable job of getting it to compile and run for both TriBlade and DracBlade. I imagine we are running into some messy "#ifdef" soup by now.
Hmm..freebies [noparse]:)[/noparse]
Perhaps you should put up a DracBlade thread so the future DracBlade followers can find what they need.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Had my TriBlade running today for the first time since the 3rd Adelaide propfest. It has done some travelling - Surfers, Gosford, Adelaide, Gosford, Surfers, Gosford. At least I didn't leave it on a bus LOL.
I will have to download TeraTerm. James, are there any tricks to get running with wordstar ???
heater: did you look at the ZiCog code where I found 8 longs. Found another 2. Slightly faster too. But of course I want to use them to speedup the emulation - fetching words would be a nice improvement in speed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
No time to fire up any prop code. I'm running about a lot, on that damn bus, just have odd moments to ramble on here.
Anyway, all changes to the zicog emulation itself need checking by running the instruction set test program EXZ80DOC.COM. If that passes at least as well normal I'd be more than happy with any optimizations anyone can come up with. Problem is it takes a good long time to run.
Note: Must use CPU_Z80 and EXZ80DOC.COM. There is also an EX8080.COM that tests 8080 only op-codes only but as we are setting the flags like a Z80 it fails pretty much every test. Perhaps one day the will be a shed load more #ifdefs to get the 8080 flag setting right.
EXZ80ALL.COM tests against undocumented flag register bit settings which I've never bothered to look into.
WORD read/writes would be great if you can find enough space to put the extra code in.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Re how much space free, BST tells me that the program is 4800 longs, the variable list is 1518 longs and there are 1870 longs free. I don't think the ifdefs will be too bad - it should be possible for instance to put most of it in a single big group at the bottom of the existing code as a single ifdef.
And as a shameless plug for BST, the quick F10 compile/test/run has greatly sped up development.
Next little job is to replicate the triblade driver as a dracblade driver, and that should simplify the ifdef situation even further.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
The space problems are in the ZiCog cog for your extra code, and hub only in heater's DemoBoard platform (no SRAM) where every bit of space is required for CPM.
To see how much ZiCog space is available place some nop's at the beginning of the ZiCog code after outx and before the jmp #fetch. After this instruction it will be removed by bst as unused code!
I have a little time over the next few days so I will try and get the new fsrw running on ZiCog/TriBlade. Whether it works or not, I think it is time for a V1.0 release, arts and all, so I will liase with heater on this.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
So the development cycle for writing code is fast.
The N8VEM IDE has a number of 'one click' options, including downloading batches of files using xmodem. A batch of files might be the Wordstar group, or the BDS C group. This all is working brilliantly on the propeller.
What is new today is the Dracblade driver in PASM. This is the same as the Triblade driver, so the concept here is that you drop in a single object depending on the hardware. The code is now greatly simplified. The main differences now with the Triblade code is the startup code for the keyboard and vga, duplicating UART.tx("A") with VGATEXT.OUT("A") for diagnostic messages, and some extra code at the bottom included as a single #ifdef that handles the VT100 terminal.
Bootup is *fast*. Indeed, with a cathode ray monitor switched off at the powerpoint, and switching both the monitor and the propeller on at the same time, the A> is ready for use about the same time as the monitor is warmed up. Since when has Windows been able to do that?!
@Cluso, if it is ok with you, I'd like to try to combine these two projects into one source code, with suitable #ifdefs? I've looked through the code and I don't think it will decrease the readability of the triblade code as the dracblade will largely replicate the triblade as an alternate group of ifdef code. Do you have a copy of your latest version by any chance? OR - would you prefer I wait till 1.0 comes out?
Re the zicog in Z80, I'm over by 14 longs.
I might be able to save a few as I have
Zero long %00000000_00000000_00000000_00000000 mov dira,zero ' tristate all pinsIs this the same as mov dira,0 ?, ie specifically, given that constants seem to be limited to 9 bits, does mov dira,0 tristate bits 10 up?
That might save a little.
Then I've also noticed that the entire ram driver only uses pins 0-15. So, instead of
Is it possible to substitute a word instead of a long? (assuming that pins 16-31 are definitely all tristated).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
If you want to put the DracBlade driver within the TriBlade driver and select by #ifdef, that is fine by me. I guess, as we add other platforms, it will only be necessary to issue one set of software files which will be simpler.
Would you like to email me your ZiCog code and I will see if I can find some longs for you. I am not confident though. Heater maybe able to put one of the Z80 resident opcodes into an overlay to save the space for you.
I think mov dira,#0 is legitimate.
The latch direction is in the cog, so it has to be long.
I don't think I have done anything to the code (except the ZiCog.spin yesterday) since I gave you the latest - it is only comments and I can add them easily. email me on when you are available and I can hook up skype.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Changing longs to words doesn't work either (it did work but only with one variable, and then I needed to pad it anyway so the dispatch tables lined up.
I shaved two nops on the ram and now it is only over by 12 longs.
I haven't put in the changes you suggested on the zicog thread but I think you shaved another ?2 longs
Re the code, I commented out these lines:
and then the ramd driver code is below. Otherwise the zicog is unchanged.
GateHigh long %00000000_00000000_00000001_00000000 ' HC138 gate high, all others must be low Outx long %00000000_00000000_00000000_00000000 ' temp variable ' for temp use, same as n in the spin code LatchDirection long %00000000_00000000_00011101_11111111 ' 138 active, gate active and 8 data lines active LatchDirection2 long %00000000_00000000_00011101_00000000 ' for reads so data lines are tristate till the read LowAddress long %00000000_00000000_00001001_00000000 ' low address latch = xxx010xx and gate high xxxxxxx1 MiddleAddress long %00000000_00000000_00001101_00000000 ' middle address latch = xxx011xx and gate high xxxxxxx1 'ReadEnable long %00000000_00000000_00000001_00000000 ' /RD = xxx111xx and gate high xxxxxxx1 ' commented out as the same as GateHigh WriteEnable long %00000000_00000000_00011101_00000000 ' /WE = xxx111xx and gate high xxxxxxx1 Zero long %00000000_00000000_00000000_00000000 ' for tristating all pins read_memory_byte call #RamAddress ' sets up the latches with the correct ram address mov dira,LatchDirection2 ' for reads so P0-P7 tristate till do read mov outa,GateHigh ' actually ReadEnable but they are the same andn outa,GateHigh ' set gate low ' nop ' short delay to stabilise nop ' none does not work, 1 does work mov data_8, ina ' read SRAM and data_8, #$FF ' extract 8 bits or outa,GateHigh ' set the gate high again mov dira,zero ' tristate all pins read_memory_byte_ret ret write_memory_byte call #RamAddress ' sets up the latches with the correct ram address mov outx,data_8 ' get the byte to output and outx, #$FF 'ensure upper bytes=0 or outx,WriteEnable ' or with correct 138 address mov outa,outx ' send it out andn outa,GateHigh ' set gate low ' nop ' no nop doesn't work, one does, so put in two to be sure nop ' another NOP or outa,GateHigh ' set it high again mov dira,zero ' tristate all pins write_memory_byte_ret ret RamAddress ' sets up the ram latches. Assumes high latch A16-A18 low so only accesses 64k of ram mov dira,LatchDirection ' set up the pins for programming latch chips mov outx,address ' get the address into a temp variable and outx,#$FF ' mask the low byte or outx,LowAddress ' or with 138 low address mov outa,outx ' send it out andn outa,GateHigh ' set gate low ' ?? a NOP or outa,GateHigh ' set it high again ' now repeat for the middle byte mov outx,address ' get the address into a temp variable shr outx,#8 ' shift right by 8 places and outx,#$FF ' mask the low byte or outx,MiddleAddress ' or with 138 middle address mov outa,outx ' send it out andn outa,GateHigh ' set gate low or outa,GateHigh ' set it high again RamAddress_ret retIf you can see an optimisation that would be great!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
GateHigh long %00000000_00000000_00000001_00000000 ' HC138 gate high, all others must be low LatchDirection long %00000000_00000000_00011101_11111111 ' 138 active, gate active and 8 data lines active LatchDirection2 long %00000000_00000000_00011101_00000000 ' for reads so data lines are tristate till the read LowAddress long %00000000_00000000_00001001_00000000 ' low address latch = xxx010xx and gate high xxxxxxx1 MiddleAddress long %00000000_00000000_00001101_00000000 ' middle address latch = xxx011xx and gate high xxxxxxx1 'ReadEnable long %00000000_00000000_00000001_00000000 ' /RD = xxx111xx and gate high xxxxxxx1 ' commented out as the same as GateHigh WriteEnable long %00000000_00000000_00011101_00000000 ' /WE = xxx111xx and gate high xxxxxxx1 Zero long %00000000_00000000_00000000_00000000 ' for tristating all pins outx long $0 ' temp variable ' for temp use, same as n in the spin code addrx long $0 read_memory_byte call #RamAddress ' sets up the latches with the correct ram address mov dira,LatchDirection2 ' for reads so P0-P7 tristate till do read mov outa,GateHigh ' actually ReadEnable but they are the same call LatchItRead mov data_8,outx ' get the data read and data_8, #$FF ' extract 8 bits mov dira,zero ' tristate all pins read_memory_byte_ret ret write_memory_byte call #RamAddress 'sets up the latches with the correct ram address mov outx,data_8 'get the byte to output mov addrx,WriteEnable 'or with correct 138 address call LatchIt mov dira,zero 'tristate all pins write_memory_byte_ret ret RamAddress ' sets up the ram latches. Assumes high latch A16-A18 low so only accesses 64k of ram mov dira,LatchDirection mov outx,address 'set address 0-7 (& 8-15) mov addrx,LowAddress 'set the Low Address call LatchIt mov outx,address ror outx,#8 'set address 8-15 mov addrx,MiddleAddress 'set the Middle Address call LatchIt RamAddress_ret ret LatchIt and outx,#$FF ' mask the low byte (data/address byte) or outx,addrx ' or with 138 mask mov outa,outx ' send it out LatchItRead andn outa,GateHigh ' set gate low nop ' ?? a NOP mov outx,ina ' read SRAM (in case it is a read) or outa,GateHigh ' set it high again LatchIt_ret retHere is a second - another saving of 3 longs. Note the immediate values - they should work
GateHigh equ %1_00000000 ' HC138 gate high, all others must be low LatchDirection2 equ %0_11111111 ' for reads so data lines are tristate till the read Zero equ $0 ' for tristating all pins DAT 'GateHigh long %00000000_00000000_00000001_00000000 ' HC138 gate high, all others must be low LatchDirection long %00000000_00000000_00011101_11111111 ' 138 active, gate active and 8 data lines active 'LatchDirection2 long %00000000_00000000_00011101_00000000 ' for reads so data lines are tristate till the read LowAddress long %00000000_00000000_00001001_00000000 ' low address latch = xxx010xx and gate high xxxxxxx1 MiddleAddress long %00000000_00000000_00001101_00000000 ' middle address latch = xxx011xx and gate high xxxxxxx1 'ReadEnable long %00000000_00000000_00000001_00000000 ' /RD = xxx111xx and gate high xxxxxxx1 ' commented out as the same as GateHigh WriteEnable long %00000000_00000000_00011101_00000000 ' /WE = xxx111xx and gate high xxxxxxx1 'Zero long %00000000_00000000_00000000_00000000 ' for tristating all pins outx long $0 ' temp variable ' for temp use, same as n in the spin code addrx long $0 read_memory_byte call #RamAddress ' sets up the latches with the correct ram address ' mov dira,LatchDirection2 ' for reads so P0-P7 tristate till do read andn dira,#LatchDirection2 ' for reads so P0-P7 tristate till do read mov outa,#GateHigh ' actually ReadEnable but they are the same call LatchItRead mov data_8,outx ' get the data read and data_8, #$FF ' extract 8 bits mov dira,#zero ' tristate all pins read_memory_byte_ret ret write_memory_byte call #RamAddress 'sets up the latches with the correct ram address mov outx,data_8 'get the byte to output mov addrx,WriteEnable 'or with correct 138 address call LatchIt mov dira,#zero 'tristate all pins write_memory_byte_ret ret RamAddress ' sets up the ram latches. Assumes high latch A16-A18 low so only accesses 64k of ram mov dira,LatchDirection mov outx,address 'set address 0-7 (& 8-15) mov addrx,LowAddress 'set the Low Address call LatchIt mov outx,address ror outx,#8 'set address 8-15 mov addrx,MiddleAddress 'set the Middle Address call LatchIt RamAddress_ret ret LatchIt and outx,#$FF ' mask the low byte (data/address byte) or outx,addrx ' or with 138 mask mov outa,outx ' send it out LatchItRead andn outa,#GateHigh ' set gate low nop ' ?? a NOP mov outx,ina ' read SRAM (in case it is a read) or outa,#GateHigh ' set it high again LatchIt_ret retNow that saves 6 longs plus the 8 I saved yesterday.. So it should now fit provided I have correctly redone 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
Post Edited (Cluso99) : 11/18/2009 2:44:07 PM GMT
Saves you one long!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
I'm still trying to get the hang of mixing up a 32 bit processor with 8 bits, 16 bits and 9 bit constants. If code space wasn't an issue (as it isn't generally in Spin) then I guess it is just easier to do everything in longs.
So to clarify, mov myvalue, #nn will work with #nn from 0 to $1FF? But mov outa,#0 will tristate all 32 pins?
And if I have a long and I OR it with a constant, and the constant only goes up to $1FF, then do the bits above bit 9 remain unchanged?
What would happen if you did an AND with a constant? would the bits above bit 9 remain unchanged, or are they ANDed with a hidden value of either 0 or 1?
Another thought - can outa be used as a register? I'm thinking of the code where it starts with a value in outx, does some bit manipulation on that then about half way through puts that into outa and then does some more bit manipulation. So long as the 138 latch bit always stays high or tristate through this process, it won't really matter if the other lines are going on and off as the pins are set up. Could this then mean outx isn't needed as a variable??
I'll ponder that a bit more as it might be that the changes already made have resulted in enough savings. Cluso, are you up to 8 longs already in other parts of the code?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
No reason you can't use outa as a register. Well, it IS a register. Execute an instruction from it if you want to "JMP #OUTA"
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
There are 4 to 6? usable shaddow memory locations in the cog ram register range $1F0-$1FF that can be used. I use them for my zero footprint debugger which wholy resides in the shaddow ram and executes from there. It is tricky to use but as a last resort it's there. There is DIRB, INB, OUTB.
I already found 8 longs in the ZiCog.spin I posted 2 days ago. I re-used 2 instructions which were only executed on startup for temporary locations (datax & outx ??). I found address_stash and ???_stash could also find an instruction only used on startup.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Optimisations:
1) - Cluso's 8 longs saved in rr128
2) Realising that WriteEnable and LatchDirection2 in my variables were the same thing
3) Using andn outa,#$100 ' set gate low using a constant rather than a long. This saved code in many places.
4) I didn't end up needing the LatchIt optimisations so speed is still the same
5) removing multiple instances of
'#ifdef TriBladeProp
' mov dira, ram_dir_input 'RR20090321 (pass I/O to another cog)
'#endif
as I'm pretty sure my dira gets set explicitly with each memory call. Unless I misunderstand this bit of code.
and 6) - the one that might be controversial: At the beginning of the zicog is this:
DAT org 0 entry OVERLAY_LOAD_RET ' jmp #RESIDENT_CODE 'Go execute resident code first (loaded automatically at CogNew) 'Can use as a RET instruction AFTER execution of the loaded overlay '--------------------------------------------------------------------------------------------------------- 'RESIDENT ROUTINES follow... ' RESIDENT_CODEand as shown above, I commented out the jmp #resident_code
It still seems to work but am I missing something with this jump to the very next label in the code?
**postedit - attached is my collection of useful Z80 assembly routines with low level CP/M calls like print to the screen, file I/O, math and strings. Compilation off board and download using the N8VEM editor takes about 5 seconds. All works perfectly though it doesn't use all the instructions, so I'm going to leave it running overnight with the EXZ80DOC program.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
Post Edited (Dr_Acula) : 11/20/2009 2:22:31 AM GMT
So if I understand correctly you have 1 long to find if you need the above instruction. Is there any code you execute once on startup? address_stash can be placed on this instruction and save a long. Use DIRB as a register to save & restore for address_stash. This will give you 1 long.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
So--- need to look at those other options. I looked at address_stash (and the other stash one)and outx but they seem to both be used as part of the same routine (ie stash/read/restore from stash)so no luck there. Ditto using data_8 as a working variable inside the read/write routines.
DIRB it might be then - I'll check it out.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
Post Edited (Dr_Acula) : 11/20/2009 3:34:41 AM GMT
But you can (should be able) to use the DIRB as a temp storage location without problems. So just change address_stash or data_stash to DIRB - IIRC data-stash is only used once so it is an easier mod.
The simpler the mod the better
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
and put it at the end of the overlay.
daa_ovl rdbyte data_8, a_reg mov nibble, data_8 'Isolate low nibble of accumulator and nibble, #$0F cmp nibble, #10 wc 'Test for greater than 9 test flags, #aux_bit wz 'Test auxillary carry if_nz_or_nc add data_8, #$06 'Add 6 to accumulator if greater than 9 or AUX carry add nibble, #6 'Check for AUX carry from low nibble test nibble, #%00010000 wz muxnz flags, #aux_bit 'and set AUX flag if so. mov nibble, data_8 'Isolate high nibble of accumulator shr nibble, #4 cmp nibble, #10 wc 'Test for greater than 9 test flags, #carry_bit wz 'Test carry flag if_nz_or_nc add data_8, #$60 'Add (6 << 4) to accumulator if greater than 9 or carry test data_8, #$100 wz 'Check for 8 bit carry out if_nz or flags, #carry_bit 'Set carry flag if so (N.B. Do NOT clear carry if not so) and data_8, #$FF wz, wc muxz flags, #zero_bit 'Set Z80 zero flag from props zero muxnc flags, #parity_bit test data_8, #128 wz muxnz flags, #sign_bit wrbyte data_8, a_reg jmp #fetch nibble long 0 long $0[noparse][[/noparse]($ - OVERLAY_START) // 2] 'fill to even number of longs (REQUIRED) daa_ovl_end fit $1F0This gives me the long I need. Compiles fine. Also tested it with a quick program in assembly and traced it through with DDT. Put 0B2H into
the A register and it returns 12 which is correct as B+6=decimal 17 which is 16+1, and the 2 stays the same. Gives the same result as it gave before.
I hope this isn't missing something?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Dr_A
I have mused on the decoder and latch bits of Dracblade, they will fit int a XC9536XL (·LCD not implimented )·One spare pin and only 66% used innards, although I havent floorplanned it yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Post Edited (Toby Seckshund) : 11/20/2009 2:09:04 PM GMT
Actually thinking about it, generally moving data from "resident" to overlay in what is the biggest overlay would not gain you any space. After all that just makes the resident area smaller and the required overlay area bigger. But there is the fact that overlays have to be an even number of LONGS in size. So perhaps we are lucky and the nibble just moves into a place that would be padded out with zero anyway. In which case there is no loss in speed either.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
As far as I can tell this is NOT true for LONGs in PASM. I've just tried it again with simple test prog with all optimizations turned on.
For sure it would be very bad to just remove along from the middle of PASM which could well beak some code that depends on the offsets of things. Unlike Spin it is very dangerous to remove away code from assembly languages.
I have used the trick of adding "unused long 0[noparse][[/noparse]43]" as dummy longs before a "fit" statement to determine the amount of free space. But you don't need to, BST tells us in the listing file output.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.