TriBladeProp with Proto Boards
Humanoido
Posts: 5,770
What's the best way to make a stripped-down TriBladeProp version
with three Propeller Proto Boards or two and a HYDRA?
humanoido
with three Propeller Proto Boards or two and a HYDRA?
humanoido
Comments
Basically the three Props on a TriBlade are independent of each other apart from the power supply. That is unless you bridge the links for serial comms that can run between them. I am currently only ever running Blade #2 with the RAM and SD on it.
So nothing stopping you building up the Blades as per the TriBlade schematics. That is provided the Proto Board is not already using some pins that the Blades need.
Blade #3 is pretty much just a Prop with all pins available to expansion headers so no problems there I guess.
Blade #2 with the RAM and SD sharing some pins is the tricky one. You might find that without a tight PCB layout and good decoupling it will not run at the speed that Cluso gets out of it.
Blade #1 is probably easy, especially if you skip the RAM, just VGA and TV resistors as per a Prop Demo Board.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I did try to use a commoned XTAL (Blade2's) but found that when that bit reset it banjaxed the other. Obviously the Osc stops at RST and restarts after boot sequence. The VT100 got very upset, so back to two Xtals.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
Just use the schematics from page 2 of the TriBlade schematics to build Blade #2. You do not need the FLASH or the second SRAM at this time. Make sure you do the -OE modification described elsewhere on the thread. So you can use a ProtoBoard,·do not fit the PS2 or VGA. Add a latch, SRAM and SD/microSD and it's done. You may not get the speed I do, but that does not matter. This is basically what the RamBlade is (without power supply), except the RamBlade will be faster.
As others have said, Blade #1 is really only a prop with VGA, TV, Keyboard and mouse. Forget the FLASH, SRAM and latch - so you can use a ProtoBoard and add TV if you need that. Blade #3 is just a prop with unused I/O pins.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Can one Prop do it all? Since the HYDRA has the video/tv, mouse, and keyboard already wired, and it has the extra memory and plug-in SD card adapter, it seems possible to run the software (modified for pins) on the just the HYDRA without Prop 1 and 3. My goal is to run CPM and some languages which other TriBladeProp enthusiasts are running. I don't care about having free pins at this time. I am not sure about the OE modification/ latch or what its doing. Again, thanks sincerely.
humanoido
In theory the Hydra with its external RAM expansion and SD card could run ZiCog and CP/M on it's own.
In practice it needs a bit of working on, modify all of ZiCogs external RAM driving code, arrange to be able to use RAM and SD card at the same time on Hydra.
I don't have a Hydra so I have no idea how much is involved. Others here were/are still looking at it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
(or just buy Cluso's board!)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
You should seriously write this up, and offer a canned software download with the modified code.
I know there are HYDRA schematics in the printed book but they are in sections, i.e. not one complete schematic. I will also look around and see if there is a complete schematic posted somewhere, perhaps newly created. If anyone finds one, let us know! We may need to ask in the HYDRA forum?
humanoido
http://forums.parallax.com/showthread.php?p=639469
The store page is here:
www.parallax.com/Store/Microcontrollers/PropellerProgrammingKits/tabid/144/CategoryID/20/List/0/SortField/0/Level/a/ProductID/467/Default.aspx
The HYDRA SD-MAX Storage Card page is here:
www.parallax.com/Store/Microcontrollers/PropellerProgrammingKits/tabid/144/CategoryID/20/List/0/SortField/0/Level/a/ProductID/505/Default.aspx
humanoido
Mind you, it is hard to see the hydra having access to fast ram as you need lots of lines to do the address and data. Cluso's is the fastest with a 27 line solution. I'm getting pretty good speed with a 12 line solution. I doubt I2C and other serial ram solutions would be fast enough though.
My board is still very much experimental but it will be released soon. Also I'll start a new thread as I don't want to hijack Cluso's too much. I have two bits of VT100 code to clean up and then I think it will be ready.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
Post Edited (Dr_Acula) : 11/26/2009 11:08:50 AM GMT
MikeDiv is looking at a Hydra port of ZiCog. I thought someone else wanted to do that as well, can't remember the name now. I hope the space optimizations you and Cluso have made recently allow the Hydra RAM access code to fit.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Looking at the schematic, it has onboard program memory 32-128K EEPROM w/cart insertion logic and U4 is a 24LC256.
humanoido
Post Edited (humanoido) : 11/26/2009 12:30:40 PM GMT
HYDRA Xtreme 512K SRAM Card
www.parallax.com/Store/Microcontrollers/PropellerProgrammingKits/tabid/144/CategoryID/20/List/0/SortField/0/Level/a/ProductID/444/Default.aspx
Here's the quote from Parallax:
"The HYDRA XTREME 512K Card (HX512) completes the HYDRA system giving it a full 512K of Static RAM (SRAM) and 128K BYTE EEPROM for program storage. The interface between the HYDRA and the HX512 is made possible by a state-of-the-art Lattice ispMach 4064 Complex Programmable Logic Device (CPLD) which acts as the memory controller and "glue" logic interfacing the HYDRA and the HX512.
The CPLD is used to address the large 512K memory as well as act as a simple memory controller that is capable of auto increment and decrement functionality to help accelerate your code. With this exciting addition to your HYDRA, it literally transforms the HYDRA into a full featured 32-bit computer that can host large programs, operating systems, interpreters, compilers, and more advanced games and graphics applications.
Additionally, the Lattice CPLD can be re-programmed with a 3rd party programmer or one your build (instructions included on CD-ROM). By re-programming the CPLD, you can literally change the "personality" and behavior of the HX512 altering it to suit your needs as well as using the HX512 as low-cost CPLD development kit. The CPLD development tool is included on CD-ROM. In addition to the hardware is a complete software API suite consisting of both a SPIN based API and highly accelerated ASM API. Both APIs are well documented in the HYDRA XTREME 512K SRAM CARD Programming and User Manual that comes on the CD-ROM. Over 80 pages of illustrations, explanations, and source code will get you jump-started with the HX512!"
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
humanoido
You have to hack ZiCog such that it can read/write random bytes from the ext RAM. MikeDiv is looking into this.
You have to arrange to be able to use an SD and the ext RAM at the same time, which I'm told is not possible on an "out of the box" Hydra.
You have to hack the Ext RAM driver that the Spin parts of the emulation use as well.
It is possible the extra code for accessing the Hydra ext RAM will not fit in the ZiCog COG. Space is very tight and the Hydra requires more code for random access than TriBlade.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I am using a HX512K connected to a Demo board. I have tried to fit the Driver into Zicog and was unsuccessful. I mentioned that today in the jazzed thread relating to ZiCog
and has a result received a PM from (Kuroneko). The big problem is that there is so little room in Zicog to accomodate the driver.
On the plus side, we only need to use 64k for CPM1 (If I remember). I will contact Kuroneko shortly and hopefully he will have some ideas.
@heater or Clusso
What is the lastest version of CPM/1 and how many free longs are there for the Xmem drivver?
@Clusso, one week + PP is the true ?
Ron
Speed experiments are continuing - what I'm finding is that memory access is a bit slower on a drac blade compared to a triblade so programs run maybe 20% slower. However, the sd card is on all the time, so hard drive access is maybe 10% faster. Overall, a program like wordstar loads about the same on both boards, and is about the same as real Z80 running at 4Mhz. So it is all totally usable. And boots *way* faster than Windows!
But it is hard to answer the question about a hydra speed without more info about the memory. Is the hydra schematic a bit of a secret? Is it ok to post a scan of the memory add-on? I'm guessing here from just the photos but is the memory access serial and how many lines does it use? Speed is proportional to the number of pins devoted to memory access.
I see 10 connectors on that photo above. What do those 10 lines do? Maybe it is possible - I'm using 12 lines. The auto increment could make a big difference as most of the time in a CP/M program it will be auto incrementing. So somewhere in the driver code it would need to check if newaddress=oldaddress+1, and if yes then auto increment, and if no, send the new address (16 bits). The challenge may be to fit that in only a handful of longs. Then again, if you go for 8080 opcodes CP/M seems to run fine and 8080 leaves plenty of longs free in the zicog.
It took me a couple of weeks of evenings to write the dracblade driver code.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
Post Edited (Dr_Acula) : 11/29/2009 5:42:27 AM GMT
humanoido
@Kuroneko
In response to your PM.
The Zicog code below is an old version but if you care to take a look at the memory access section you will see that there is not much to play with. There are only 14 Longs left in the cog. I don’t know how many longs in the current Zicog mem driver but its bound very tightly.
I did make a start but soon realized that I was not going to get this code to fit. It was a diversion from my main project at the time and never went back to it. I wondered at the time whether I should try running the driver in another cog but it’s the bottle neck anyway so did not look any further.
I don’t know whether the post inc/dec can be used to any effect, maybe Heater, or Clusso might have something to say on that.
Note the pin configuration that I am using does not help the cause.
Ron
Step 1: Set the clock strobe line HIGH.
Step 2: Read the data on the data bus.
Step 3: Set the clock strobe line LOW.
Step 4: (Optional) Read another BYTE; GOTO Step 1.
This is about as fast as is possible. The setting of clock bit can be done by logically OR’ing the I/O, the reading of the data
bus can be done with a simple read, and finally the resetting of the clock strobe can be done with a logical AND’ing of a
mask with I/O. So 3 ASM instructions can in theory achieve all this with the right set up. However, the challenge is
extracting the data from the 32-bit I/O read which requires shifting and masking (2-3 instructions), and so forth. Thus, the
actual reading of data is very fast, but the data has to be extracted and positioned to work with.
This is the code which uses three latches to talk to a 512k memory chip. (actually only two really as the high 3 bits are not used)
' **************************** Dr_Acula single propeller driver **************** ' three latches to access the ram chip - see main program for spin version ' uses variables address and data_8. skip banked memory and checking for out of bounds address ' will need two nop instructions in /rd and /wr to be sure Outx long %00000000_00000000_00000000_00000000 ' temp variable ' for temp use, same as n in the spin code Direction138 long %00000000_00000000_00001111_00000000 ' for reads so data lines are tristate till the read LowAddress long %00000000_00000000_00000101_00000000 ' low address latch = xxxx010x and gate high xxxxxxx1 MiddleAddress long %00000000_00000000_00000111_00000000 ' middle address latch = xxxx011x and gate high xxxxxxx1 WriteEnable long %00000000_00000000_00000011_00000000 ' write enable xxxx001x and xxxxxxx0 read_memory_byte call #RamAddress ' sets up the latches with the correct ram address mov dira,Direction138 ' for reads so P0-P7 tristate till do read mov outa,#$0 ' set 000 low 138 read, low gate and P0-P7 are inputs nop ' none does not work, 1 does work mov data_8, ina ' read SRAM and data_8, #$FF ' extract 8 bits or outa,#$100 ' set the gate high again mov dira,#0 ' tristate all pins read_memory_byte_ret ret write_memory_byte call #RamAddress ' sets up the latches with the correct ram address ' experiments both replacing outx with outa, and also using data_8 as the working variable instead of outx have both failed mov outx,data_8 ' get the byte to output and outx, #$FF 'ensure upper bytes=0 or outx,WriteEnable ' or with correct 138 address which is the same as latchdirection2 mov outa,outx ' send it out andn outa,#$100 ' set gate low nop ' NOP needs at least one due to 138 propogation delay or outa,#$100 ' set it high again mov dira,#0 ' 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,Direction138 ' set up the pins for programming latch chips or dira,#$FF ' set P0-P7 high 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,#$100 ' set gate low or outa,#$100 ' set it high again and 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,#$100 ' set gate low or outa,#$100 ' set it high again RamAddress_ret retThis code fits with no longs free. But if you go to 8080 code there is lots of space.
I reckon this hydra idea is worth pursuing - it is not a crazy idea at all.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
Updated code
Here·is some·HX512K code which·I think I can shoe horn into Zicog but I want to use the standard I/O pins 30.31 to Terra Term. I think you have done this already so interested to know how you are running your Serial I/O.
BTW
My micro SD card is on 8..12 This code fits witn no longs left. will need to save a few more to use to use the whole 512 k
DAT org 000 {{ My HX512K connection to the to Prop is ....... ctrl_0 = Pin 24 ctrl_1 = Pin 25 clk = Pin 26 DBus 0..7 = Pin 0..7 The code assumes that the Card is in run the run state with no post INC/DEC. }}strobe or outa, ck xor outa, ck mov outa, $0 strobe_ret retlat_adr add outa, address and outa, #$FF or outa, ll call #strobe add outa, address shr outa, #8 or outa, lh call #strobe Lat_adr_ret retwrite mov dira, sdir call #lat_adr mov outa, $0 add outa, data_8 call #strobe write_ret retread call #lat_adr or outa, rd and dira, rdd or outa, ck mov data_16, ina xor outa, ck mov dira, sdir and data_16, #8 read_ret retread_memory_word call #read mov data_16, data_8 ror data_16, #8 add address, #1 call #read or data_16, data_8 rol data_16, #8 read_memory_word_ret retwrite_memory_word mov data_8, data_16 call #write shr data_8, #8 add address, #1 call #write write_memory_word_ret retPost Edited (Ron Sutcliffe) : 12/2/2009 12:01:31 PM GMT
There will no doubt be lots of testing at the very simplest level. I spent days just getting it to write one byte to the ram and read it back. Then suddenly over less than half a day it went from that to running CP/M. So don't despair if you are stuck on the simple 1 byte transfer for a while. Looks like you have some code almost there.
Re serial, I'm using Tim Moore's object unchanged. 4 ports but only using 2. Instead of UART.dec(n), you use UART.dec(3,n) where 3 is port 0 to 3.
Declare like this;
So you can set the pins (I/m using 31 30 25 and 24)
What else?
My micro SD is on
I'm using the fsrw object, and I think Cluso modified it to tristate, but I have modified it back so it doesn't, and it may well be back to how it was originally.
The other big bit of code is the block ram read and write. This has been greatly modified from cluso's code with some commands deleted, and a couple of new ones added for a diagnostic led. Once you get a single byte read and write working on the hydra from within zicog, you can copy that code into this driver. Maybe lose the led stuff.
This cog is needed as it handles the block transfer in pasm. I started off doing it in spin (as I think did cluso) and it was much slower.
''Dracblade driver for talking to a ram chip via three latches '' Modified code from Cluso's triblade VAR ' communication params(5) between cog driver code - only "command" and "errx" are modified by the driver long command, hubaddrs, ramaddrs, blocklen, errx, cog ' rendezvous between spin and assembly (can be used cog to cog) ' command = R, W, =0 when operation completed by cog ' hubaddrs = hub address for data buffer ' ramaddrs = ram address for data ($0000 to $FFFF) ' blocklen = ram buffer length for data transfer ' errx = returns =0 (false=good), else <>0 (true & error code) ' cog = cog no of driver (set by spin start routine) PUB start : err_ ' Initialise the Drac Ram driver. No actual changes to ram as the read/write routines handle this command := "I" cog := 1 + cognew(@tbp2_start, @command) if cog == 0 err_ := $FF ' error = no cog else repeat while command ' driver cog sets =0 when done err_ := errx ' driver cog sets =0 if no error, else xx = error code PUB stop if cog cogstop(cog~ - 1) PUB LedOn command :="N" repeat while command ' driver cog sets 0 when done PUB LedOff command :="F" repeat while command ' driver cog sets 0 when done PUB DoCmd(command_, hub_address, ram_address, block_length) : err_ ' Do the command: R, W, read/write hubaddrs := hub_address ' hub address start ramaddrs := ram_address ' ram address start blocklen := block_length ' block length command := command_ ' must be last !! ' Wait for command to complete and get status repeat while command ' driver cog sets =0 when done err_ := errx ' driver cog sets =0 if no error, else xx = error code DAT '' +--------------------------------------------------------------------------+ '' | Dracblade Ram Driver (with grateful acknowlegements to Cluso) | '' +--------------------------------------------------------------------------+ org 0 tbp2_start ' setup the pointers to the hub command interface (saves execution time later ' +-- These instructions are overwritten as variables after start comptr mov comptr, par ' -| hub pointer to command hubptr mov hubptr, par ' | hub pointer to hub address ramptr add hubptr, #4 ' | hub pointer to ram address lenptr mov ramptr, par ' | hub pointer to length errptr add ramptr, #8 ' | hub pointer to error status cmd mov lenptr, par ' | command I/R/W/G/P/Q hubaddr add lenptr, #12 ' | hub address ramaddr mov errptr, par ' | ram address len add errptr, #16 ' | length err nop ' -+ error status returned (=0=false=good) ' Initialise hardware (unlike the triblade, just tristates everything and read/write set the pins) init mov err, #0 ' reset err=false=good mov dira,zero ' tristate the pins done wrlong err, errptr ' status =0=false=good, else error x wrlong zero, comptr ' command =0 (done) ' wait for a command (pause short time to reduce power) pause mov ctr, delay wz ' if =0 no pause if_nz add ctr, cnt if_nz waitcnt ctr, #0 ' wait for a short time (reduces power) rdlong cmd, comptr wz ' command ? if_z jmp #pause ' not yet ' decode command cmp cmd, #"R" wz ' R = read block if_z jmp #rdblock cmp cmd, #"W" wz ' W = write block if_z jmp #wrblock cmp cmd, #"N" wz ' N= led on if_z jmp #led_turn_on cmp cmd, #"F" wz ' F = led off if_z jmp #led_turn_off mov err, cmd ' error = cmd (unknown command) jmp #done tristate mov dira,zero ' all inputs to zero jmp #done ' turn led on led_turn_on mov dira,latchdirection ' setup active pins 138 and bus mov outa,ledpin ' led is on or outa,HighAddress ' or with the high address andn outa,GateHigh ' set gate low or outa,GateHigh ' set the gate high again jmp #tristate ' set pins tristate led_turn_off mov dira,latchdirection ' setup active pins 138 and bus mov outa,Zero ' led is off or outa,HighAddress ' or with the high address andn outa,GateHigh ' set gate low or outa,GateHigh ' set the gate high again jmp #tristate ' set pins tristate '--------------------------------------------------------------------------------------------------------- 'Memory Access Functions rdblock call #ram_open ' get variables from hub variables rdloop call #read_memory_byte ' read byte from address into data_8 wrbyte data_8,hubaddr ' write data_8 to hubaddr ie copy byte to hub add hubaddr,#1 ' add 1 to hub address add address,#1 ' add 1 to ram address djnz len,#rdloop ' loop until done jmp #init ' reinitialise wrblock call #ram_open wrloop rdbyte data_8, hubaddr ' copy byte from hub call #write_memory_byte ' write byte from data_8 to address add hubaddr,#1 ' add 1 to hub address add address,#1 ' add 1 to ram address djnz len,#wrloop ' loop until done jmp #init ' reinitialise ram_open rdlong hubaddr, hubptr ' get hub address rdlong ramaddr, ramptr ' get ram address rdlong len, lenptr ' get length mov err, #5 ' err=5 mov address,ramaddr ' cluso's variable 'ramaddr' to dracblade variable 'address' ram_open_ret ret 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 mov data_8, ina ' read SRAM and data_8, #$FF ' extract 8 bits or outa,GateHigh ' set the gate high again 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 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 delay long 80 ' waitcnt delay to reduce power (#80 = 1uS approx) ctr long 0 ' used to pause execution (lower power use) & byte counter GateHigh long %00000000_00000000_00000001_00000000 ' HC138 gate high, all others must be low Outx long 0 ' for temp use, same as n in the spin code LatchDirection long %00000000_00000000_00001111_11111111 ' 138 active, gate active and 8 data lines active LatchDirection2 long %00000000_00000000_00001111_00000000 ' for reads so data lines are tristate till the read LowAddress long %00000000_00000000_00000101_00000000 ' low address latch = xxxx010x and gate high xxxxxxx1 MiddleAddress long %00000000_00000000_00000111_00000000 ' middle address latch = xxxx011x and gate high xxxxxxx1 HighAddress long %00000000_00000000_00001001_00000000 ' high address latch = xxxx100x and gate high xxxxxxx1 'ReadEnable long %00000000_00000000_00000001_00000000 ' /RD = xxxx000x and gate high xxxxxxx1 ' commented out as the same as GateHigh WriteEnable long %00000000_00000000_00000011_00000000 ' /WE = xxxx001x and gate high xxxxxxx1 Zero long %00000000_00000000_00000000_00000000 ' for tristating all pins data_8 long %00000000_00000000_00000000_00000000 ' so code compatability with zicog driver address long %00000000_00000000_00000000_00000000 ' address for ram chip ledpin long %00000000_00000000_00000000_00001000 ' to turn on led▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
I have copied it and will look at it when I have finished the Xmem testing.
Think I only need a getchar putchar going to feed tera term (FullDuplexSerial will do the job) just wanted to see how the I/O interface worked
Ron
Before you run TeraTerm get PST running first. "dir" and "ls" should work after ZiCog boots, so you will see that output 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)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Next step after that is single stepping the very first Z80 opcode. I think I was about 3 days on reading/writing one byte, then another 3 days on single stepping instructions before I let it run free with a proper bootup.
I have a gut feeling the hydra is going to run, for all intents and purposes, about the same speed as all the other zicog emulations.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller