This is definitely a challenge and *much* harder than soldering up/programming a N8VEM. But I'm taking notes as there are many ways to simplify things. Ultimately this probably needs to be written up as a website with step-by-step instructions rather than links to pages within two seperate postings.
Ok, I have a board soldered up. It has all the right chips on it. The sd card is installed.
2) Are there any other links that need installing - what is the "Note there is a mod to wire -OE from prop to sram"?
3) The homespun compiler compiled zicog009_rr090.spin and turned it into a .eeprom. This involved renaming both homespun and the .spin file to something shorter to simplify the compile process within a command shell. There probably is a simpler way of doing this eg a batch file as you mentioned, or a shell from a vb.net IDE. It didn't error on the #define and the standard propeller compiler does. So is homespun a different language to the standard .spin language? Or does it have additional commands that are not included in standard spin?
4) Do you have a link to a binary file to put on the sd card? I couldn't find one on the link. I only need one file for testing purposes.
5) I worked out that OBEX means this site http://obex.parallax.com/objects/ But I'm not sure where the terminal program is. I will try a few more search terms.
6) I have gone through the zicog009_rr090.spin program and I see a reference to 115k baud. Is this the baud rate it boots up at? Can I just use any old terminal program? If so, I tried that as a quick test but got no bootup message. But the sd card is blank, I'm not sure if a link is right, I think a link might be missing and I'm not 100% sure if the .spin program is the entire program.
Sorry for asking so many dumb questions! Help would be most appreciated.
I got lost with which compiler ... a long time back and went back to nailing a prop to a real Z80. Got interested in a comment from Ale about CPLDs and the went off on yet another tangent. Hey-Ho.
I had a homemade blade 2 assembled that appears to pass the 1Mb test, I just need to get what next clear, like you.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
I have not had time to build up my TriBlade yet so I cannot say much about that.
As for #define etc these are not supported in the Parallax Propeller Tool. They are supported in Homespun and BST.
I have been building ZiCog exclusively with BST for a long time now. Just add the defines in the Project options. You only need to enter the the name eg TRIBLADE_PROP rather than #define TRIBLADE_PROP in the defines window.
The thing about terminal programs is to have one that releases the com port when not in focus so that you can program the Prop. Plus there is some issue with DTR or whatever resetting the Prop.
Why not just use BST which has a terminal window built into the IDE which behaves very well?
Before worrying about files on the SD card you should at least get to the point of getting a sign on message from ZiCog (and a few other messages before it starts CP/M) out to your terminal screen.
Good luck all. Hope to have time to catch up with you in the TriBlade world soon. Then I'll be back here to ask how you did it [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
In most propeller programs I have looked at I see they consist of several different programs. I think these are called objects. The Pocketerm for instance has a number of these programs that do things like run the vga display etc.
So I guess a very basic question to ask is whether those two .spin programs are the entire code or only part of it.
To go right back to basics, is there a bit of code that just sends "hello" up the serial line at a defined baud rate?
I tried looking for such code in the zicog009_rr90 but couldn't find it.
But I did find something in the zicogdemo009_rr90 code, that referenced debug.xxx and I'm wondering if this references some missing code that runs this debug (given debug does not appear in the help file as a keyword. Or maybe it is...)
So one question - which is the program to use, the demo one or the non demo one?
And I'm getting more certain there is missing code.
I found a line in the demo spin program:
debug : "FullDuplexSerialPlus" 'reqd to load SRAM from microSD, then closed & kb + TV started
I think this might imply there is some code called "fullduplexserialplus". An 'object' or something. There is reference to
sd : "fsrwFemto" 'SD Software used in FemtoBASIC
as well and I am thinking these may be external programs. If so, then I'm starting to wonder if there is a 'package' of programs out there that is supposed to be used as a group?
If that is the case, then a link to this code package would be most appreciated. Not quite sure why the compiler didn't give an error message either if half the external code is missing.
Heater, what is BST and do you have a link for this?
BST is a clone of the Parallax Propeller Tool that runs on Mac and Linux as well, written by BradC.
It also has a few non parallax compatible enhancements like the #define stuff that we use to build for different Prop hardware from the same source files.
The thread is called "Mac/Windows/Linux IDE...." and is on the front page now.
I have been using this for a long while and it is great stuff. Includes a terminal screen for direct chatting with your Prop over the programming pins.
Now we just need Cluso to set you straight on the ZiCog version to use for the TriBlade I'm a bit out of touch with progress on that front I'm afraid.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
James: Apologies for the code being all over the place.
Have arrived in Gosford but family around today, so no prop. I will assemble a TriBlade asap and put all the code together that is required including the objects, and zip it into one file for you.
Sorry linking pins on the 74HC573 is NOT required if using the 74HC573. There are so many options on the TriBlade (multipurpose) which is why I try to understand what each person wants out of the board. Otherwise, you include a lot of parts that are not required. Other issues took my time from making a better explanation of the options.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Thanks ++ for the reply. Files etc would be very helpful as I can see this heading towards a very nifty board. When I get home I might take a couple of photos and post them - especially the underside as I don't think there are any photos around of the chips on the underside and mine might be in the wrong way round etc. I'll be home in about 6 hours. Still eagerly looking forward to the A>...
the demo spin program is the 'main' and the other zicog program is an object for the cog. And there are all the other objects in there as well like the keyboard.
But for driving just one blade, I think it won't need keyboard or vga. The input/output is just one serial object. And I've made up a nifty little RS232 splitter board so I can have the RS232 signal going back to the PC for display on a terminal, and another side of the splitter going off to a Pocketerm and do the keyboard/display for debugging. So maybe a terminal program on the PC isn't even needed. Anyway, that is the theory. Looking forward to getting home...
Post Edited (Dr_Acula (James Moxham)) : 8/3/2009 7:40:56 AM GMT
Addit: Well, this is quite a challenge. I'm probably weeks away from the A>, but learning a lot along the way. Ok, the main challenge with the code as it is is to rewrite it for just one blade on the triblade. That means all comms comes in and out via the download pins. So - out with the keyboard code and out with the TV.text messages (I haven't got a spare TV) Also, lots of the code is not needed when emulated on a triblade. Then all the debug messages need to be rerouted through the serial object rather than to the TV screen. There are lots of these and after a while the whole project got a bit unwieldy. So it probably will involve a top-down approach rather than trying to modify existing code. To that end, I've started with a blank slate and written a little program using just the serial object and this program simply echos characters back to a terminal program running on a PC. That works fine. I guess the steps in building this back up to a working zicog simulation would be to get the sd card routines working, debug those and prove it can read a file and a record off a file. Then put zicog back in and tell zicog to read data off the sd card files.
Not trivial by any means, and great credit is due to those who have this working.
Given that this is not going to be a project where you solder up a board and drop in some code, and given it is going to take a fair bit of work, I'm pondering some of the features needed on a board. I'm thinking about the tradeoff of speed vs pins (as discussed many times on this forum) and thinking whether this whole thing could ever fit in one propeller? eg, one cog to do vga, one to do keyboard, two to do serial ports, one to do zicog and one to do sd card access. Use an 8 bit bus, 3 bits to select which device on a bus, decode with a 138, address the ram with two latches for 64k or 3 latches for 64k+, add a /wr and a /rd line and an iorq line like on a z80. Drive vga and keyboard and sd card as per standard wiring. Ram access is 3x slower than the triblade. Use one latch to talk to a parallel LCD display. I'm happy to trade speed to get it on one chip because there are ways to speed up sbasic/mbasic/bbcbasic/c by adding in machine code. Or write in pure Z80 assembly. I guess I might need to look at the prices of importing propeller chips, because one locally purchased prop chip + peripherals works out cheaper than a N8VEM board, but two locally purchased prop chips plus peripherals is more than a N8VEM. I guess the aim is still to shrink this sort of thing down to the lowest cost www.vintage-computer.com/vcforum/showthread.php?t=16511 I'm still pondering lowest cost too, as glue chips like HC logic are very cheap (25c) compared with chips like Uarts ($6), Z80s ($3), eproms ($3) etc. Some chips are common to both (the same ram chip happens to work both in the triblade and the N8VEM). So I guess my preference is to drop in a number of HC373s rather than another propeller.
Then again, Cluso has posted some intriguing messages recently about some new boards...
Post Edited (Dr_Acula (James Moxham)) : 8/3/2009 12:27:21 PM GMT
James: Sorry you are missunderstanding - we desperately need to chat as you are complicating matters. The code already runs on 1 prop - Blade #2. You should have the prompt in 10 minutes max, provided you have a propplug equivalent and the software on the pc. You wanted to do other things and this is why I was asking what you wanted to do with your TriBlade. I will await your call on skype to get you running. I have also posted code to run on Blade #1 to do VGA/TV and Keyboard, etc. I think this is confusing the issue.
I apologise for posting multiple versions of the code and confusing all. I will need to update the forum and my website to make it easy for you and others.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
James: Actually I thought it was straight forward to get running. I think you are trying to run before walking Also you kind of missed the real time flow as the project was peaking. I think it would probably take me a day or so to reconstruct what I did to get everything running on the triblade - probably because I have too many projects up in the air at the moment plus the real job that puts food on the table. I agree with Cluso99 that it is best to get ZiCog running on blade #2 with a propPlug then branch out from there to get terminal running on Blade 1. By the time you get that running and understood - it will be trivial for you to use the 3rd Blade or other pins on Blade 1 for your parallel I/O
I agree the code is somewhat scattered with many versions in the threads and probably needs to be consolidated at the top of one of the threads.
I think I may still have the wrong code. The code I'm using makes lots of mention of the TV and keyboard objects. But these are not connected to blade #2, they are connected to blade #1. If it is running on blade #2, then input will come via the download pins, not via a keyboard. Is that correct?
Addit: I've worked it out!
kb : "PC_Keyboard" 'You can also use Keyboard object for PS2-Keyboard
TV : "PC_Text"
All through the program there is mention of TV.xyz and kb.xyz. I couldn't work out why you would have a TV when there is no TV. These lines explain it all, because the TV output is being redirected to the programming cable via an object called PC_Text.
Now all I think I need to do is go through and replace the references to 115k baud to 38k (as my rather long serial cable has too much crosstalk at higher baud rates). Ok - back to coding...
Post Edited (Dr_Acula (James Moxham)) : 8/4/2009 5:42:15 AM GMT
You should not have to mess with high level code. If you want messages rerouted to a different place just drop in a different object to do it. Just because the code says "TV.out" does not mean that TV is an actual TV, perhaps it's full duplex serial or what ever you have assigned it to. You should not have to chnage much to get this working.
I'm sure Cluso will set you straight it's all been done already.
I am also intrigued by the idea of a version of ZiCoG that uses only one Propeller, a minimal pin interface to say just 64K of RAM, has SD card and can drive a VGA screen.
May not be so fast but this is how I envisaged it a long time ago as a minimal chip CP/M system.
Lets think on that.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Reading again I see you have sussed the TV thing. Sorry my bad, I should have changed the name a long time ago.
Just read it as "Terminal VT100" [noparse]:)[/noparse] What ever that eventually is defined to be.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Ok, getting there. Next step is the compiler. I gather only BST works - is that right? If so, is there something that goes in the command line? I created a little batch file
bstc -e zicog_demo009_rr090.spin
pause
but it doesn't seem to create anything and it is giving three error messages:
C:\Propeller\bst>bstc -e zicog_demo009_rr090.spin
Brads Spin Tool Compiler v0.15.3 - Copyright 2008,2009 All rights reserved
Compiled for i386 Win32 at 08:17:48 on 2009/07/20
Loading Object zicog_demo009_rr090
zicog_demo009_rr090 - Error at (189,2) Expected Unique Name, Constant or "("
#else
_^
zicog_demo009_rr090(190,3) Error : Symbol _clkmode is already defined!
_clkmode = xtal1 + pll8x
__^
zicog_demo009_rr090 - Error at (196,1) Expected Object definition
#ifdef TriBladeProp
^
Compiled 913 Lines of Code in 0.031 Seconds
C:\Propeller\bst>pause
Press any key to continue . . .
Earlier I think Cluso said he was using Homespun and Heater is using BST on Linux. I ran it through homespun:
C:\Program Files\Parallax Inc\Propeller Tool v1.2.5>homespun024 zicog_demo009_rr
090 -b -d -i3 -w
Homespun Spin Compiler 0.24
parsing zicog_demo009_rr090.spin
parsing zicog009_rr090.spin
Warning: zicog009_rr090.spin (288, 33): JMP with non-immediate operand
vect_1 jmp vector 'Jump(indirect) to th
e instruction handler
^
Warning: zicog009_rr090.spin (292, 33): JMP with non-immediate operand
jmp vector 'Jump(indirect) to th
e instruction handler
^
Warning: zicog009_rr090.spin (1739, 33): JMP with non-immediate operand
jmp OVERLAY_LOAD_RET 'return(indirect) to
calling routine
^
parsing PC_Keyboard.spin
parsing PC_Text.spin
parsing TriBladeProp_Blade2_202.spin
parsing FullDuplexSerialPlus.spin
parsing fsrwFemto.spin
parsing sdspiFemto.spin
compiling zicog_demo009_rr090.spin
Error: zicog_demo009_rr090.spin (1068, 15): Unknown symbol idle
r := tbp2.idle 'give up the bus
^
C:\Program Files\Parallax Inc\Propeller Tool v1.2.5>pause
Press any key to continue . . .
And with BST and adding the Ox (and changing the triblade v to 202)
C:\Propeller\bst>bstc -e -Ox zicog_demo009_rr090.spin
Brads Spin Tool Compiler v0.15.3 - Copyright 2008,2009 All rights reserved
Compiled for i386 Win32 at 08:17:48 on 2009/07/20
Loading Object zicog_demo009_rr090
Loading Object zicog009_rr090
Loading Object PC_Keyboard
Loading Object PC_Text
Loading Object TriBladeProp_Blade2_202
Loading Object FullDuplexSerialPlus
Loading Object fsrwFemto
Loading Object sdspiFemto
zicog_demo009_rr090(1068,15) Error : Unable to locate method/constant in Object
r := tbp2.idle 'give up the bus
______________^
zicog_demo009_rr090(1082,15) Error : Unable to locate method/constant in Object
r := tbp2.active 'activate the bus
______________^
Compiled 3172 Lines of Code in 0.406 Seconds
C:\Propeller\bst>pause
Press any key to continue . . .
Post Edited (Dr_Acula (James Moxham)) : 8/4/2009 6:51:38 AM GMT
Dr A: To compile this code it is required to set some definitions so that the #ifdefs select the correct bits of code to compile. For example: For demo board use you must define PROP_DEMO_BOARD, for Triblade we need TRIBLADE_PROP.
If using Homespun you will have to find the "#define TRIBLADE_PROP" etc statements in all spin files and uncomment the ones you need. I believe this is true for BSTC as well, unless there is a way to set them on the command line.
If using BST you can enter the defines into a dialogue box in the project options. In that case you don't need to uncomment the "#defines" in the code and the given defines work across all files compiled in the project.
Again Cluso will have to set you straight on the required defines for Triblade.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
A few have asked about the VB6 code I used to create the CPM files (disks) for the microSD card to run ZiCog. Here is the VB6 source - it is pretty rough so please take it as it comes. This is what I use on the TriBlade.
The original CPM 2.2 and CPM 3 files (disks) were from the SIMH site.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
If using Homespun you will have to find the "#define TRIBLADE_PROP" etc statements in all spin files and uncomment the ones you need. I believe this is true for BSTC as well, unless there is a way to set them on the command line.
bstc -D TRIBLADE_PROP
will do it [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
This is a major milestone, thanks to the huge efforts of Cluso and Dr_Acula ZiCog is now happily up and running CP/M 2 and WordStar and xmodem and the BDS C compiler etc etc on the TriBlade Prop without any serial console port problems.
Reading and writing to hard drives on SD card from CP/M 2 has been shown to work, at least on the Prop Demoboard version.
Changes:
' - Incorporate all Cluso's and DrAcula's changes see zicog_demo.spin for details.
' - Removed keyboard object and all references to kb.something
' - Removed TV object and all references to TV.something
' - Replaced kb and TV with UART using FullDuplexSerial
' - Removed FrequencyCount object and all reference to fcounter (no one was using it)
' - Removed a "repeat" from in_hdskport after "HDSK ERROR 5", saves the survey program hanging.
' - Changed in_condata to use UART.rxcheck, saves the survey program from hanging.
' - Added disk I: to the disk start up message.
' - It is now necessary to use SPACE to single step instructions.
ZiCog can be run on a Prop Demo Board:
1) Compile with BST setting the defines as per the included zicog_demo.sprj project file.
2) Use BSTs terminal window to view the output. Baud rate = 38400.
3) Even with out a CP/M file system in SD card it will start and run it's included CP/M up until the A> prompt.
4) You may have to watch a lot of disk read error messages scroll by first.
5) Not many CP/M commands work after that point with no SD card CP/M file system [noparse]:)[/noparse]
See the first post in this thread to download this new version.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Heater - can you update the baudrate in you message to read 38400, not 3840 (typo). I think we should up this back to 115200? what do you think? (James uses 38400, but if we download from the pc it will be 115200 which is likely what most will do)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I think baud rates are just something people have to check and adjust, like the crystal frequency setting.
So we should make that more obvious somehow. In the docs (non-existent) and in the code.
The default can be changed in the next release.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
It's at the top anyway in CON - if it isn't I will move it there. Just about to download your v010 and see what you have been up to.
I will shift over to this thread again because we are back to ZiCog and CPM rather than TriBlade.
I asked about the 137 byte sectors - are the extra bytes used anywhere in CPM? If not, can you remove them from your sd file ?? The hard disk should be simple as I have blank 32MB disk files. So I will copy one to HDRIVE_I.DSK and then format and pip files to it - easy
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Not so much really, just cleaning out old junk and checking everything still works on the Demo Board. One issue was that the CP/M survey program reads from all the I/O ports. This was hanging because it was reading straight from UART.rx which waits for input. Changed to UART.rxcheck. Perhaps that's why the console emulation was written in such a way as to have that bug that Dr_A found recently. I forget now, that was such old code.
Also survey was hanging because everything was stopped on a read (write? I forget) of the hdsk port in the wrong way.
The CBIOSX we use expects those 137 bytes. At least the pre bytes are read, it may ignore the post bytes if I remember correctly. It does not check the content of the pre bytes. So that is what we have to deliver from the emulation.
Still we can keep just the 128 real data bytes of the sectors in our image files and synthesis the pre and post bytes as we pass them into CBIOSX in the Spin code.
Isn't this what you do in the TriBlade version anyway?
Like I said I should do the same so that we are compatible. I feel a version 0.11 coming on. It will be a few days away, give you guys time to throw something into the pot as well[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Comments
This is definitely a challenge and *much* harder than soldering up/programming a N8VEM. But I'm taking notes as there are many ways to simplify things. Ultimately this probably needs to be written up as a website with step-by-step instructions rather than links to pages within two seperate postings.
Ok, I have a board soldered up. It has all the right chips on it. The sd card is installed.
1) I have installed a link as per this page http://www.bluemagic.biz/clusodocs/tribladeprop_a1b.jpg However, I do not understand this link as it appears to link pin 17 and pin 11 of the HC573. Is that correct?
2) Are there any other links that need installing - what is the "Note there is a mod to wire -OE from prop to sram"?
3) The homespun compiler compiled zicog009_rr090.spin and turned it into a .eeprom. This involved renaming both homespun and the .spin file to something shorter to simplify the compile process within a command shell. There probably is a simpler way of doing this eg a batch file as you mentioned, or a shell from a vb.net IDE. It didn't error on the #define and the standard propeller compiler does. So is homespun a different language to the standard .spin language? Or does it have additional commands that are not included in standard spin?
4) Do you have a link to a binary file to put on the sd card? I couldn't find one on the link. I only need one file for testing purposes.
5) I worked out that OBEX means this site http://obex.parallax.com/objects/ But I'm not sure where the terminal program is. I will try a few more search terms.
6) I have gone through the zicog009_rr090.spin program and I see a reference to 115k baud. Is this the baud rate it boots up at? Can I just use any old terminal program? If so, I tried that as a quick test but got no bootup message. But the sd card is blank, I'm not sure if a link is right, I think a link might be missing and I'm not 100% sure if the .spin program is the entire program.
Sorry for asking so many dumb questions! Help would be most appreciated.
Cheers
James
I got lost with which compiler ... a long time back and went back to nailing a prop to a real Z80. Got interested in a comment from Ale about CPLDs and the went off on yet another tangent. Hey-Ho.
I had a homemade blade 2 assembled that appears to pass the 1Mb test, I just need to get what next clear, like you.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
It's great to see you making progress with ZiCog.
I have not had time to build up my TriBlade yet so I cannot say much about that.
As for #define etc these are not supported in the Parallax Propeller Tool. They are supported in Homespun and BST.
I have been building ZiCog exclusively with BST for a long time now. Just add the defines in the Project options. You only need to enter the the name eg TRIBLADE_PROP rather than #define TRIBLADE_PROP in the defines window.
The thing about terminal programs is to have one that releases the com port when not in focus so that you can program the Prop. Plus there is some issue with DTR or whatever resetting the Prop.
Why not just use BST which has a terminal window built into the IDE which behaves very well?
Before worrying about files on the SD card you should at least get to the point of getting a sign on message from ZiCog (and a few other messages before it starts CP/M) out to your terminal screen.
Good luck all. Hope to have time to catch up with you in the TriBlade world soon. Then I'll be back here to ask how you did it [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
In most propeller programs I have looked at I see they consist of several different programs. I think these are called objects. The Pocketerm for instance has a number of these programs that do things like run the vga display etc.
So I guess a very basic question to ask is whether those two .spin programs are the entire code or only part of it.
To go right back to basics, is there a bit of code that just sends "hello" up the serial line at a defined baud rate?
I tried looking for such code in the zicog009_rr90 but couldn't find it.
But I did find something in the zicogdemo009_rr90 code, that referenced debug.xxx and I'm wondering if this references some missing code that runs this debug (given debug does not appear in the help file as a keyword. Or maybe it is...)
So one question - which is the program to use, the demo one or the non demo one?
And I'm getting more certain there is missing code.
I found a line in the demo spin program:
debug : "FullDuplexSerialPlus" 'reqd to load SRAM from microSD, then closed & kb + TV started
I think this might imply there is some code called "fullduplexserialplus". An 'object' or something. There is reference to
sd : "fsrwFemto" 'SD Software used in FemtoBASIC
as well and I am thinking these may be external programs. If so, then I'm starting to wonder if there is a 'package' of programs out there that is supposed to be used as a group?
If that is the case, then a link to this code package would be most appreciated. Not quite sure why the compiler didn't give an error message either if half the external code is missing.
Heater, what is BST and do you have a link for this?
BST is a clone of the Parallax Propeller Tool that runs on Mac and Linux as well, written by BradC.
It also has a few non parallax compatible enhancements like the #define stuff that we use to build for different Prop hardware from the same source files.
The thread is called "Mac/Windows/Linux IDE...." and is on the front page now.
Follow the links from the first post here http://forums.parallax.com/showthread.php?p=755835 to get the latest version.
I have been using this for a long while and it is great stuff. Includes a terminal screen for direct chatting with your Prop over the programming pins.
Now we just need Cluso to set you straight on the ZiCog version to use for the TriBlade I'm a bit out of touch with progress on that front I'm afraid.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Have arrived in Gosford but family around today, so no prop. I will assemble a TriBlade asap and put all the code together that is required including the objects, and zip it into one file for you.
Sorry linking pins on the 74HC573 is NOT required if using the 74HC573. There are so many options on the TriBlade (multipurpose) which is why I try to understand what each person wants out of the board. Otherwise, you include a lot of parts that are not required. Other issues took my time from making a better explanation of the options.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Addit - I found the full software packages - can't wait to get home and install this!
The code makes sense now. Link here http://forums.parallax.com/showthread.php?p=786418
the demo spin program is the 'main' and the other zicog program is an object for the cog. And there are all the other objects in there as well like the keyboard.
But for driving just one blade, I think it won't need keyboard or vga. The input/output is just one serial object. And I've made up a nifty little RS232 splitter board so I can have the RS232 signal going back to the PC for display on a terminal, and another side of the splitter going off to a Pocketerm and do the keyboard/display for debugging. So maybe a terminal program on the PC isn't even needed. Anyway, that is the theory. Looking forward to getting home...
Post Edited (Dr_Acula (James Moxham)) : 8/3/2009 7:40:56 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Addit: Well, this is quite a challenge. I'm probably weeks away from the A>, but learning a lot along the way. Ok, the main challenge with the code as it is is to rewrite it for just one blade on the triblade. That means all comms comes in and out via the download pins. So - out with the keyboard code and out with the TV.text messages (I haven't got a spare TV) Also, lots of the code is not needed when emulated on a triblade. Then all the debug messages need to be rerouted through the serial object rather than to the TV screen. There are lots of these and after a while the whole project got a bit unwieldy. So it probably will involve a top-down approach rather than trying to modify existing code. To that end, I've started with a blank slate and written a little program using just the serial object and this program simply echos characters back to a terminal program running on a PC. That works fine. I guess the steps in building this back up to a working zicog simulation would be to get the sd card routines working, debug those and prove it can read a file and a record off a file. Then put zicog back in and tell zicog to read data off the sd card files.
Not trivial by any means, and great credit is due to those who have this working.
Given that this is not going to be a project where you solder up a board and drop in some code, and given it is going to take a fair bit of work, I'm pondering some of the features needed on a board. I'm thinking about the tradeoff of speed vs pins (as discussed many times on this forum) and thinking whether this whole thing could ever fit in one propeller? eg, one cog to do vga, one to do keyboard, two to do serial ports, one to do zicog and one to do sd card access. Use an 8 bit bus, 3 bits to select which device on a bus, decode with a 138, address the ram with two latches for 64k or 3 latches for 64k+, add a /wr and a /rd line and an iorq line like on a z80. Drive vga and keyboard and sd card as per standard wiring. Ram access is 3x slower than the triblade. Use one latch to talk to a parallel LCD display. I'm happy to trade speed to get it on one chip because there are ways to speed up sbasic/mbasic/bbcbasic/c by adding in machine code. Or write in pure Z80 assembly. I guess I might need to look at the prices of importing propeller chips, because one locally purchased prop chip + peripherals works out cheaper than a N8VEM board, but two locally purchased prop chips plus peripherals is more than a N8VEM. I guess the aim is still to shrink this sort of thing down to the lowest cost www.vintage-computer.com/vcforum/showthread.php?t=16511 I'm still pondering lowest cost too, as glue chips like HC logic are very cheap (25c) compared with chips like Uarts ($6), Z80s ($3), eproms ($3) etc. Some chips are common to both (the same ram chip happens to work both in the triblade and the N8VEM). So I guess my preference is to drop in a number of HC373s rather than another propeller.
Then again, Cluso has posted some intriguing messages recently about some new boards...
Post Edited (Dr_Acula (James Moxham)) : 8/3/2009 12:27:21 PM GMT
I apologise for posting multiple versions of the code and confusing all. I will need to update the forum and my website to make it easy for you and others.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
I agree the code is somewhat scattered with many versions in the threads and probably needs to be consolidated at the top of one of the threads.
Dave
I think I may still have the wrong code. The code I'm using makes lots of mention of the TV and keyboard objects. But these are not connected to blade #2, they are connected to blade #1. If it is running on blade #2, then input will come via the download pins, not via a keyboard. Is that correct?
Addit: I've worked it out!
kb : "PC_Keyboard" 'You can also use Keyboard object for PS2-Keyboard
TV : "PC_Text"
All through the program there is mention of TV.xyz and kb.xyz. I couldn't work out why you would have a TV when there is no TV. These lines explain it all, because the TV output is being redirected to the programming cable via an object called PC_Text.
Now all I think I need to do is go through and replace the references to 115k baud to 38k (as my rather long serial cable has too much crosstalk at higher baud rates). Ok - back to coding...
Post Edited (Dr_Acula (James Moxham)) : 8/4/2009 5:42:15 AM GMT
You should not be weeks away. A day or two maybe.
You should not have to mess with high level code. If you want messages rerouted to a different place just drop in a different object to do it. Just because the code says "TV.out" does not mean that TV is an actual TV, perhaps it's full duplex serial or what ever you have assigned it to. You should not have to chnage much to get this working.
I'm sure Cluso will set you straight it's all been done already.
I am also intrigued by the idea of a version of ZiCoG that uses only one Propeller, a minimal pin interface to say just 64K of RAM, has SD card and can drive a VGA screen.
May not be so fast but this is how I envisaged it a long time ago as a minimal chip CP/M system.
Lets think on that.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Just read it as "Terminal VT100" [noparse]:)[/noparse] What ever that eventually is defined to be.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
bstc -e zicog_demo009_rr090.spin
pause
but it doesn't seem to create anything and it is giving three error messages:
C:\Propeller\bst>bstc -e zicog_demo009_rr090.spin
Brads Spin Tool Compiler v0.15.3 - Copyright 2008,2009 All rights reserved
Compiled for i386 Win32 at 08:17:48 on 2009/07/20
Loading Object zicog_demo009_rr090
zicog_demo009_rr090 - Error at (189,2) Expected Unique Name, Constant or "("
#else
_^
zicog_demo009_rr090(190,3) Error : Symbol _clkmode is already defined!
_clkmode = xtal1 + pll8x
__^
zicog_demo009_rr090 - Error at (196,1) Expected Object definition
#ifdef TriBladeProp
^
Compiled 913 Lines of Code in 0.031 Seconds
C:\Propeller\bst>pause
Press any key to continue . . .
Earlier I think Cluso said he was using Homespun and Heater is using BST on Linux. I ran it through homespun:
C:\Program Files\Parallax Inc\Propeller Tool v1.2.5>homespun024 zicog_demo009_rr
090 -b -d -i3 -w
Homespun Spin Compiler 0.24
parsing zicog_demo009_rr090.spin
parsing zicog009_rr090.spin
Warning: zicog009_rr090.spin (288, 33): JMP with non-immediate operand
vect_1 jmp vector 'Jump(indirect) to th
e instruction handler
^
Warning: zicog009_rr090.spin (292, 33): JMP with non-immediate operand
jmp vector 'Jump(indirect) to th
e instruction handler
^
Warning: zicog009_rr090.spin (1739, 33): JMP with non-immediate operand
jmp OVERLAY_LOAD_RET 'return(indirect) to
calling routine
^
parsing PC_Keyboard.spin
parsing PC_Text.spin
parsing TriBladeProp_Blade2_202.spin
parsing FullDuplexSerialPlus.spin
parsing fsrwFemto.spin
parsing sdspiFemto.spin
compiling zicog_demo009_rr090.spin
Error: zicog_demo009_rr090.spin (1068, 15): Unknown symbol idle
r := tbp2.idle 'give up the bus
^
C:\Program Files\Parallax Inc\Propeller Tool v1.2.5>pause
Press any key to continue . . .
And with BST and adding the Ox (and changing the triblade v to 202)
C:\Propeller\bst>bstc -e -Ox zicog_demo009_rr090.spin
Brads Spin Tool Compiler v0.15.3 - Copyright 2008,2009 All rights reserved
Compiled for i386 Win32 at 08:17:48 on 2009/07/20
Loading Object zicog_demo009_rr090
Loading Object zicog009_rr090
Loading Object PC_Keyboard
Loading Object PC_Text
Loading Object TriBladeProp_Blade2_202
Loading Object FullDuplexSerialPlus
Loading Object fsrwFemto
Loading Object sdspiFemto
zicog_demo009_rr090(1068,15) Error : Unable to locate method/constant in Object
r := tbp2.idle 'give up the bus
______________^
zicog_demo009_rr090(1082,15) Error : Unable to locate method/constant in Object
r := tbp2.active 'activate the bus
______________^
Compiled 3172 Lines of Code in 0.406 Seconds
C:\Propeller\bst>pause
Press any key to continue . . .
Post Edited (Dr_Acula (James Moxham)) : 8/4/2009 6:51:38 AM GMT
If using Homespun you will have to find the "#define TRIBLADE_PROP" etc statements in all spin files and uncomment the ones you need. I believe this is true for BSTC as well, unless there is a way to set them on the command line.
If using BST you can enter the defines into a dialogue box in the project options. In that case you don't need to uncomment the "#defines" in the code and the given defines work across all files compiled in the project.
Again Cluso will have to set you straight on the required defines for Triblade.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
The original CPM 2.2 and CPM 3 files (disks) were from the SIMH site.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
bstc -D TRIBLADE_PROP
will do it [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
This is a major milestone, thanks to the huge efforts of Cluso and Dr_Acula ZiCog is now happily up and running CP/M 2 and WordStar and xmodem and the BDS C compiler etc etc on the TriBlade Prop without any serial console port problems.
Reading and writing to hard drives on SD card from CP/M 2 has been shown to work, at least on the Prop Demoboard version.
Changes:
' - Incorporate all Cluso's and DrAcula's changes see zicog_demo.spin for details.
' - Removed keyboard object and all references to kb.something
' - Removed TV object and all references to TV.something
' - Replaced kb and TV with UART using FullDuplexSerial
' - Removed FrequencyCount object and all reference to fcounter (no one was using it)
' - Removed a "repeat" from in_hdskport after "HDSK ERROR 5", saves the survey program hanging.
' - Changed in_condata to use UART.rxcheck, saves the survey program from hanging.
' - Added disk I: to the disk start up message.
' - It is now necessary to use SPACE to single step instructions.
ZiCog can be run on a Prop Demo Board:
1) Compile with BST setting the defines as per the included zicog_demo.sprj project file.
2) Use BSTs terminal window to view the output. Baud rate = 38400.
3) Even with out a CP/M file system in SD card it will start and run it's included CP/M up until the A> prompt.
4) You may have to watch a lot of disk read error messages scroll by first.
5) Not many CP/M commands work after that point with no SD card CP/M file system [noparse]:)[/noparse]
See the first post in this thread to download this new version.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 8/19/2009 5:37:16 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (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 we should make that more obvious somehow. In the docs (non-existent) and in the code.
The default can be changed in the next release.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I will shift over to this thread again because we are back to ZiCog and CPM rather than TriBlade.
I asked about the 137 byte sectors - are the extra bytes used anywhere in CPM? If not, can you remove them from your sd file ?? The hard disk should be simple as I have blank 32MB disk files. So I will copy one to HDRIVE_I.DSK and then format and pip files to it - easy
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (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
Also survey was hanging because everything was stopped on a read (write? I forget) of the hdsk port in the wrong way.
The CBIOSX we use expects those 137 bytes. At least the pre bytes are read, it may ignore the post bytes if I remember correctly. It does not check the content of the pre bytes. So that is what we have to deliver from the emulation.
Still we can keep just the 128 real data bytes of the sectors in our image files and synthesis the pre and post bytes as we pass them into CBIOSX in the Spin code.
Isn't this what you do in the TriBlade version anyway?
Like I said I should do the same so that we are compatible. I feel a version 0.11 coming on. It will be a few days away, give you guys time to throw something into the pot as well[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.