Dr_A: I'd have to think very hard about combining code from driver COG's into a single COG. Things that happen concurrently now will have to happen concurrently in the combined code. For example the console input will still have to pick up and buffer incoming characters when it it is combined with something else. It should not miss characters just because it is busy performing, say, SD card access. We don't want Control-C to be lost. Not so easy.
I think I have a handle on why those tests that fail with incorrect CRC do so:
The bit set/reset/test instructions were never really finished and some versions of them (different addressing mode) are not implemented at all.
The block comparisons (cpd and cpi) are there as stub overlays that don't have any code in them yet! (same for block input and output).
The set of tests that include DAA probably fail because our current DAA behaves enough like the original 8080 version to get SURVEY.COM to work. The Z80 DAA is a bit more involved.
The rest of the failures, not shown in the results, are instructions that are not implemented yet and just go to BREAK or instructions that never will be implemented because as far as I am aware operations on high and low halves of index registers were not documented for the original Z80.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Yes heater, upon reflection (and upon looking at the actual code!), you are right. So ok, I'll just use the stardard 4 serial driver cog routine from the obex.
Re crc fails, really from a practical perspective the main thing is that 8080 opcodes all work. I haven't checked for a while but do they all pass?
As for Z80, when it comes to assembly my main favourites are DJNZ and LDIR. As for all the standard CP/M software, I've been testing more and more and they all seem to work fine and so I think they probably are all 8080 compatible. I never really used bit set/reset, as I prefer to do an AND or an OR with a mask. Which is the way the prop and other micros work too. I suspect there are a huge number of Z80 instructions that no-one really used much.
I think Cluso is getting close to an official 1.0 release and that would be very exciting.
I'd be interested in looking at CP/M3 at some stage, if only to find some use for the 448k on the memory chip that is currently unused!
I found a full Z80 flag description on one of the FPGA Z80 emulation sites - I cannot find the bookmark
I had been thinking (for TriBlade and RamBlade at least) that we could call the cog directly to do the string comparison/move instructions as this would be much faster. Otherwise a specific overlay crafted for fast execution (not calling the read/write functions).
Obviously I cannot say how much of this is important. Maybe we just need to put·error reporting for each of the failed instructions and see if they are being utilised.
Drac: The fsrw we are currently using is a full cogs worth. That is why I want to use the new fsrw - still been too busy to check the latest fix. When we can move to the new fsrw, I am sure the fsrw and ram drivers can be combined. IIRC the FDX uses hub for the buffers.
CPM3 has been running but it still uses floppies. The CPM3 version is non-banked so you can try it. I think you should have the SD files.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Last I checked all 8080 only op-codes were working. Except for the possibility of the flags not being right in DAA sometimes, I tested it with ddt as best I could.
HOWEVER we are working in a twilight zone here. The 8080 op-codes work BUT they set flags as per a Z80. So even if you set CPU_8080 it runs more like a Z80 with all the new ops disallowed. There is one exception to this, forget which op now, that is often used to determine if running on Z80 or 8080. This is used to determine if LDIR and friends can be used in a program.
Notice there is no test for jumps in that EXZ80DOC. However DJNZ does work. Have yet to find a problem with any jump or calls.
Clusso: I think I have all Z80 flag settings under control. Except for DAA. I defy anyone to show me an accurate description of how that works[noparse]:)[/noparse]. I'm sure it is different than 8080. Flag settings can be gleaned from the way SIMH does it. We simply don't have enough space to implement it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Cluso, Drac. Any chance you could put up a ZiCog release 1.0 candidate with new fsrw, DracBlade support, whatever optimizations to the actual emulation...?
I could give it a test on a Demo Board, run it through EXZ80 and hopefully put it up as ZiCog V1.0.
Mikediv is moving on with the Hydra port. A V1.0 would be a better base for his efforts.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
If it is ok I'd prefer to wait till 1.0 comes out then rewrite it. The *theory* is you put everything new in an #ifdef. The *practice* is that there are so many exceptions it is almost like rewriting the program. For instance, tonight I got the multiple serial port code working. But the catch is that every UART.str(string("mystring")) is now UART.str(0,string("mystring")) and ditto for .dec and .hex.
Also already having to tweak the driver to add a method .rxavail to see if a byte is available but not to read it.
Just getting xmodem working again (the LCD and local VGA display are invaluable for debugging something like this).
Hmm - re 8080 opcodes and Z80 flags, I suppose all the real boards I've been using are Z80 chips so I presume set Z80 flags. As for DAA, well my Z80 handbook gives completely different values to the simh. Who knows what DAA really is supposed to do?!
Dr_A: "Who knows what DAA really is supposed to do?!"
Exactly. I defy anyone to show me an official Zilog document that spells it out 100%.
I did read somewhere that Z80 DAA was fixed up from the old 8080 DAA in that it worked properly after subtract operations rather than just after additions. There is a undocumented flag in the Z80 status register that indicates if the last operation was an addition or subtraction, specifically to fix DAA.
Annoyingly the EXZ80 tests only compare the results of what an instructions do against what they actually do on a real Z80. Rather than explicitly test the outcome of the operation against what the documentation tells you. If you see what I mean. So it's not much help in diagnosing problems.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater: Here is the latest archived code for the TriBlade. I have lonesock's fsrw v25 running as he found a bug not releasing DI. Could you see if you could use that also - it would be nice for us to use the same fsrw code.
drac: Since you are the master with wordstar, etc, would you mind testing it on the TriBlade?
If this works then I can strip out the old fsrw and simplify a few things for a V1.0 release.
Postedit: Senior moment Forgot to attach the code.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Hi Cluso, is that latest code on this thread or on your website?
I must say the sd card access is pretty fast already. It boots to A> faster than the screen can warm up so for me there isn't much need to make it faster. Then again, nothing like pushing things as far as they can go!
I have found the dracblade not quite fast enough to process xmodem packets at 38k baud. The triblade can. So either need to drop the baud rate back a bit, or see if I can change the 4 port with 64byte buffer into a 2 port serial driver with 132 byte buffer...
The cool thing I'm working towards is the ability to 'log in' to another CP/M board remotely via wireless. One would run a CP/M terminal program that would display what is going on on a remote board. Behind the scenes, spin code would be routing packets and if the packet is for a particular board then it would pass it through to CP/M. Also the background code would need to chop the bytes coming through into 128 or 64 byte chunks (eg a long DIR listing) so as to not overload the receiving uart buffer. The aim would be to have boards all over the house that you can chat to, send files to and from etc. True networking for CP/M. I think this is getting close now.
heater: The new fsrw is a lot larger than the sdspiqasm you use, so do not convert to use it on the DemoBoard.
Maybe we should do 2 releases, one for the DemoBoard and one for TriBlade. The·DemoBoard·will look simpler. The TriBlade will then continue on·and will include other hardware·options with external sram. Your thoughts?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I have version 2 of the dracblade soldered up and running. Some tweaks to the code (actually it is almost unrecognisable as the triblade code) and I have a self contained single propeller computer running tonight. I even ran WSCHANGE and patched wordstar so it runs with 40 lines instead of 24. Sweet!
It is late and I'm celebrating with a glass of port, but this is now ready for prime time/website writeup/photos/freebie giveaway boards. And a new thread. The catch with the freebies is I might need a bit of help getting the baud rate higher than 19200, and finding an irritating bug in wordstar where sometimes you have to type a key twice on the local keyboard but it works fine on the remote keyboard via a terminal program. And a bug where pushing caps lock prints "^". These are minor things though.
@cluso, I ended up removing all the sd card code that starts and stops the sd card. As I don't share the 4 sd lines I can afford just to leave the card running. That has meant it runs much faster - time from pushing the reset button to the A> is 5 seconds. Then 2 seconds to get MBASIC running. I also threw in some code to light a led when the sd card is being read or written, like the hard drive led on a PC. Very handy. Nice to watch it buffer packets on an xmodem transfer and write them to the card every few seconds. I *think* it is ok to leave the sd card running - I guess the problem that might arise is turning off the power with the sd card still active but nothing seems to be getting corrupted.
No free cogs left. Zicog fits with no longs spare and it took a lot of very cunning code to get to that stage.
And re the tests you wanted done, I can't get that latest code to get to an A> on the triblade. Can you double check something else didn't change and/or post a complete package of files?
I'm going to post a little bit of code here as this is quite relevant to the triblade. One of the problems running wordstar is that at the beginning when it asks to load a document or non document file, it then bypasses CP/M's scanning routine for input and does its own rapid polling for input. This tends to miss characters, and it was a problem that has plauged the N8VEM in both Wordstar and in BBC Basic. The problem is due to a conflict in protocols - one protocol (used in the parallax keyboard object for instance) is to ask for input and return a character value if there is a character and to return 0 if there is no character. The problem with this is that 0 can also be a valid ascii character, especially during binary xmodem transfers.
I have now solved this!
So, the way this now works is to add a flag variable which is 0 for false and -1 for true. If, and only if, a flag is set will CP/M then go and get the actual byte.
The concept can be extended to scan multiple sources for input. First, poll to see if anything is present. Set the flag(s) for each input. This is done in the PUB in_constat. Then, if something is present, collect the bytes. Fortunately (thanx to the foresight of the obex coders), both the uart and the keyboard objects have methods to detect if a character is present (tail<>head) without actually reading the character. And also they have buffers. So - read the uart first, and empty it out by reading each character into CP/M. Then when the uart is cleared, read the local keyboard (which would be on blade 1 on the triblade). Then, if required, read any other devices (eg the second uart port on the dracblade).
I put the uart ahead of the local keyboard to speed up xmodem (xmodem maxes out at about 19200 baud anyway as the sd card can't write much faster than that).
So, code now looks like this for the dracblade. For the triblade, need to delete the local keyboard (though this is going to be added on blade 1 - is this working yet cluso?)
VAR
Byte Keyflag ' flag to say a keyboard character is available 0=no, 1=yes
Byte UART0flag ' flag to say a character is available on serial port 0
.
.
.
PRI in_constat
'Handle reads from the console status port
Keyflag :=kb.Gotkey ' 255=true (character), 0=false is there a key in the buffer
UART0Flag:= UART.rxavail(0) ' 255=true (character), 0=false
if KeyFlag or UART0Flag
io_data := %00000011 'Return flag to say a character is available
else
io_data := %00000010 'No: Return no char ready for input
PRI in_condata
'Handle reads from the console data port, expects flags to be set correctly
if UART0Flag ' check uart first
io_data := UART.rxcheck(0) ' Yes: Return a character
UART0Flag :=0 ' reset the flag
else ' if all cleared then local keyboard
if KeyFlag ' is there a keyboard char?
key :=kb.key ' get the character
ProcessKey ' check for some high characters and remap
io_data :=key ' send to CP/M
Keyflag :=0 ' reset the flag
' add uart1 here for the second serial port
At last I can truly say that wordstar now works on the zicog!
Drac: I have had a few thing that I had to do in Qld. Some now done.
Today I ordered all the parts for the RamBlade. The pcbs should be shipping to me any day now. Lachlan has kindly allowed me to ship the bits to his box in the US so hopefully they will all be there by end of this wk.
The other night I started readying a 'forked' V2.0 release for ZiCog and TriBlade. V1.0 will be for Prop Protoboard, Demoboard, etc (no external ram), just SD/uSD. I will have to look at including the above code - thanks Drac
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
All getting very exciting with the 'worlds smallest CP/M computer' on the way.
Once upon a time I think you had a triblade that was fully populated but did you loan that to someone? If so, I'm not sure where you got to with getting the links between blades 1 and 2 working. I think it was a 12 bit protocol but was there code in the end?
Perhaps the demo is going to be eclipsed by the ramblade? If so, I guess there still needs to be that code for a demo version. I'm presuming the keyboard/vga etc would all be standard objects? For the dracblade, the VGA ended up being a hybrid of the 1024 driver code and the VT100 driver code from OldBitCollector/Vince Briel's Pocketerm. My code is on the link below, near the bottom of that page wrapped up in a big zip file.
RossH has the fully populated TriBlade. I just used FDX to communicate to Blade #1 - no special protocol. RamBlade will use the same for the time being at least.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Cluso, can I ask a technical question. There are several places where a timer/counter would be useful, both in Spin and in CP/M. From spin, it could be a word that is incremented up to FFFF then back to 0. In CP/M you could read that with an In to two specific ports.
This could be useful to time things, especially for timeouts - eg if keyboard not pressed in x milliseconds then go on to something else. It doesn't have to be super accurate.
Normally you could just setup a cog - except that I've run out.
I have a vague idea you could use the block read/write object as this is just sitting there most of the time waiting for commands R or W etc. If it was incrementing a counter too, it would only add a tiny delay.
there are 4 variables going in but only one coming back. How could I add another variable? Just put it after err_ with a comma? Pass back the value as part of err_ (which is a long just returning 0 or not zero). Hmm - that would mess up all the calling routines, but then again there are not very many of these.
Your advice would be most appreciated. Cheers, James
Dr_A: I suggest you use the COGs timers or the Props global timer. They are one of the few resources of the Prop we can make available to CP/M what with all the PINS and COGs being used up.
1) Just define another IN port address.
2) Trap the IN instructions to that address, same as we do for UART, keyboard etc, in the zicog_cpm.spin
3) In that new trap handler read the value of the Prop counter or a timer.
4) Scale the result as you like and return it to zicog.
You could also think about resetting/presetting this timer from OUT instructions.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Certainly, the TBP cog could do it when idle, by using the props CNT and updating time/date fields. CPM3 asks for the date on bootup. I have thought about this in the past.
As heater also suggested, an IN instruction could also do this. Just reads CNT and calculates the difference since the last read. CNT increments every propeller clock cycle (so 80MHz or whatever). It is 32 bits and rolls over about every 90 seconds. A counter could also be used.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Ah, I knew you guys would come to the rescue! I didn't know about the internal clock counter. This sounds perfect. Re heaters list from 1-4, I think I can do the code for 1,2 and 4. Scaling can be done in CP/M. Re 3), Reading the clock might be just one instruction - is it a spin or pasm instruction and what is it?
The internal system clock counter is cog location CNT.· It's readable from assembly or Spin.
As long as some piece of code, either Spin or CP/M, executes more often than about once every 30 seconds, you can use CNT to keep a clock / calendar.· You initially save the CNT value, then when you get control back, you do
The best place would probably be the TriBlade/DracBlade driver as it is doing nothing a lot of the time. It could maintain a hub location(s) with time and date - great for all O/S. An IN instruction could read it in spin. There is plenty of space there.
However, last night I was looking at the cog sizes. The TriBlade driver is about $50 longs. The fsrw has 30 free, but has 128 used for read ahead, which we are not using. I have to check and see if the buffer is used at all. If not, both these drivers would be better combined in 1 cog and there would still be room for the RTC. It would also mean an improvement in HD speed as we could transfer the data directly between SRAM and SD without going via the hub. But this will have to wait.
Meantime, just use IN and spin can read the CNT register.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I have just posted a release candidate for V2.0 (TriBlade version) on the ZiCog thread. A release candidate for V1.0 (DemoBoard version) should be posted shortly.
Comments
I think I have a handle on why those tests that fail with incorrect CRC do so:
The bit set/reset/test instructions were never really finished and some versions of them (different addressing mode) are not implemented at all.
The block comparisons (cpd and cpi) are there as stub overlays that don't have any code in them yet! (same for block input and output).
The set of tests that include DAA probably fail because our current DAA behaves enough like the original 8080 version to get SURVEY.COM to work. The Z80 DAA is a bit more involved.
The rest of the failures, not shown in the results, are instructions that are not implemented yet and just go to BREAK or instructions that never will be implemented because as far as I am aware operations on high and low halves of index registers were not documented for the original Z80.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Re crc fails, really from a practical perspective the main thing is that 8080 opcodes all work. I haven't checked for a while but do they all pass?
As for Z80, when it comes to assembly my main favourites are DJNZ and LDIR. As for all the standard CP/M software, I've been testing more and more and they all seem to work fine and so I think they probably are all 8080 compatible. I never really used bit set/reset, as I prefer to do an AND or an OR with a mask. Which is the way the prop and other micros work too. I suspect there are a huge number of Z80 instructions that no-one really used much.
I think Cluso is getting close to an official 1.0 release and that would be very exciting.
I'd be interested in looking at CP/M3 at some stage, if only to find some use for the 448k on the memory chip that is currently unused!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
I found a full Z80 flag description on one of the FPGA Z80 emulation sites - I cannot find the bookmark
I had been thinking (for TriBlade and RamBlade at least) that we could call the cog directly to do the string comparison/move instructions as this would be much faster. Otherwise a specific overlay crafted for fast execution (not calling the read/write functions).
Obviously I cannot say how much of this is important. Maybe we just need to put·error reporting for each of the failed instructions and see if they are being utilised.
Drac: The fsrw we are currently using is a full cogs worth. That is why I want to use the new fsrw - still been too busy to check the latest fix. When we can move to the new fsrw, I am sure the fsrw and ram drivers can be combined. IIRC the FDX uses hub for the buffers.
CPM3 has been running but it still uses floppies. The CPM3 version is non-banked so you can try it. I think you should have the SD files.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
HOWEVER we are working in a twilight zone here. The 8080 op-codes work BUT they set flags as per a Z80. So even if you set CPU_8080 it runs more like a Z80 with all the new ops disallowed. There is one exception to this, forget which op now, that is often used to determine if running on Z80 or 8080. This is used to determine if LDIR and friends can be used in a program.
Notice there is no test for jumps in that EXZ80DOC. However DJNZ does work. Have yet to find a problem with any jump or calls.
Clusso: I think I have all Z80 flag settings under control. Except for DAA. I defy anyone to show me an accurate description of how that works[noparse]:)[/noparse]. I'm sure it is different than 8080. Flag settings can be gleaned from the way SIMH does it. We simply don't have enough space to implement it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I could give it a test on a Demo Board, run it through EXZ80 and hopefully put it up as ZiCog V1.0.
Mikediv is moving on with the Hydra port. A V1.0 would be a better base for his efforts.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Also already having to tweak the driver to add a method .rxavail to see if a byte is available but not to read it.
Just getting xmodem working again (the LCD and local VGA display are invaluable for debugging something like this).
Hmm - re 8080 opcodes and Z80 flags, I suppose all the real boards I've been using are Z80 chips so I presume set Z80 flags. As for DAA, well my Z80 handbook gives completely different values to the simh. Who knows what DAA really is supposed to do?!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
Note to self - 3.3V, 3.3V, ...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Exactly. I defy anyone to show me an official Zilog document that spells it out 100%.
I did read somewhere that Z80 DAA was fixed up from the old 8080 DAA in that it worked properly after subtract operations rather than just after additions. There is a undocumented flag in the Z80 status register that indicates if the last operation was an addition or subtraction, specifically to fix DAA.
Annoyingly the EXZ80 tests only compare the results of what an instructions do against what they actually do on a real Z80. Rather than explicitly test the outcome of the operation against what the documentation tells you. If you see what I mean. So it's not much help in diagnosing problems.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
drac: Since you are the master with wordstar, etc, would you mind testing it on the TriBlade?
If this works then I can strip out the old fsrw and simplify a few things for a V1.0 release.
Postedit: Senior moment
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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/24/2009 8:55:56 AM GMT
I must say the sd card access is pretty fast already. It boots to A> faster than the screen can warm up so for me there isn't much need to make it faster. Then again, nothing like pushing things as far as they can go!
I have found the dracblade not quite fast enough to process xmodem packets at 38k baud. The triblade can. So either need to drop the baud rate back a bit, or see if I can change the 4 port with 64byte buffer into a 2 port serial driver with 132 byte buffer...
The cool thing I'm working towards is the ability to 'log in' to another CP/M board remotely via wireless. One would run a CP/M terminal program that would display what is going on on a remote board. Behind the scenes, spin code would be routing packets and if the packet is for a particular board then it would pass it through to CP/M. Also the background code would need to chop the bytes coming through into 128 or 64 byte chunks (eg a long DIR listing) so as to not overload the receiving uart buffer. The aim would be to have boards all over the house that you can chat to, send files to and from etc. True networking for CP/M. I think this is getting close now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
Post Edited (Dr_Acula) : 11/24/2009 8:52:04 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Maybe we should do 2 releases, one for the DemoBoard and one for TriBlade. The·DemoBoard·will look simpler. The TriBlade will then continue on·and will include other hardware·options with external sram. Your thoughts?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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/24/2009 9:21:26 AM GMT
Hi Cluso - I'm having trouble getting past "starting Hdisks"
I've now got three sd cards all loaded up with all the files and all three are working fine on the dracblade. Not sure what to do next...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
It is late and I'm celebrating with a glass of port, but this is now ready for prime time/website writeup/photos/freebie giveaway boards. And a new thread. The catch with the freebies is I might need a bit of help getting the baud rate higher than 19200, and finding an irritating bug in wordstar where sometimes you have to type a key twice on the local keyboard but it works fine on the remote keyboard via a terminal program. And a bug where pushing caps lock prints "^". These are minor things though.
@cluso, I ended up removing all the sd card code that starts and stops the sd card. As I don't share the 4 sd lines I can afford just to leave the card running. That has meant it runs much faster - time from pushing the reset button to the A> is 5 seconds. Then 2 seconds to get MBASIC running. I also threw in some code to light a led when the sd card is being read or written, like the hard drive led on a PC. Very handy. Nice to watch it buffer packets on an xmodem transfer and write them to the card every few seconds. I *think* it is ok to leave the sd card running - I guess the problem that might arise is turning off the power with the sd card still active but nothing seems to be getting corrupted.
No free cogs left. Zicog fits with no longs spare and it took a lot of very cunning code to get to that stage.
And re the tests you wanted done, I can't get that latest code to get to an A> on the triblade. Can you double check something else didn't change and/or post a complete package of files?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
Congratulations
I like the bit " No COGS left". Just How many did you expect to be kicking their heals???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
I have now solved this!
So, the way this now works is to add a flag variable which is 0 for false and -1 for true. If, and only if, a flag is set will CP/M then go and get the actual byte.
The concept can be extended to scan multiple sources for input. First, poll to see if anything is present. Set the flag(s) for each input. This is done in the PUB in_constat. Then, if something is present, collect the bytes. Fortunately (thanx to the foresight of the obex coders), both the uart and the keyboard objects have methods to detect if a character is present (tail<>head) without actually reading the character. And also they have buffers. So - read the uart first, and empty it out by reading each character into CP/M. Then when the uart is cleared, read the local keyboard (which would be on blade 1 on the triblade). Then, if required, read any other devices (eg the second uart port on the dracblade).
I put the uart ahead of the local keyboard to speed up xmodem (xmodem maxes out at about 19200 baud anyway as the sd card can't write much faster than that).
So, code now looks like this for the dracblade. For the triblade, need to delete the local keyboard (though this is going to be added on blade 1 - is this working yet cluso?)
VAR Byte Keyflag ' flag to say a keyboard character is available 0=no, 1=yes Byte UART0flag ' flag to say a character is available on serial port 0 . . . PRI in_constat 'Handle reads from the console status port Keyflag :=kb.Gotkey ' 255=true (character), 0=false is there a key in the buffer UART0Flag:= UART.rxavail(0) ' 255=true (character), 0=false if KeyFlag or UART0Flag io_data := %00000011 'Return flag to say a character is available else io_data := %00000010 'No: Return no char ready for input PRI in_condata 'Handle reads from the console data port, expects flags to be set correctly if UART0Flag ' check uart first io_data := UART.rxcheck(0) ' Yes: Return a character UART0Flag :=0 ' reset the flag else ' if all cleared then local keyboard if KeyFlag ' is there a keyboard char? key :=kb.key ' get the character ProcessKey ' check for some high characters and remap io_data :=key ' send to CP/M Keyflag :=0 ' reset the flag ' add uart1 here for the second serial portAt last I can truly say that wordstar now works on the zicog!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
Today I ordered all the parts for the RamBlade. The pcbs should be shipping to me any day now. Lachlan has kindly allowed me to ship the bits to his box in the US so hopefully they will all be there by end of this wk.
The other night I started readying a 'forked' V2.0 release for ZiCog and TriBlade. V1.0 will be for Prop Protoboard, Demoboard, etc (no external ram), just SD/uSD. I will have to look at including the above code - thanks Drac
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Once upon a time I think you had a triblade that was fully populated but did you loan that to someone? If so, I'm not sure where you got to with getting the links between blades 1 and 2 working. I think it was a 12 bit protocol but was there code in the end?
Perhaps the demo is going to be eclipsed by the ramblade? If so, I guess there still needs to be that code for a demo version. I'm presuming the keyboard/vga etc would all be standard objects? For the dracblade, the VGA ended up being a hybrid of the 1024 driver code and the VT100 driver code from OldBitCollector/Vince Briel's Pocketerm. My code is on the link below, near the bottom of that page wrapped up in a big zip file.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/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
This could be useful to time things, especially for timeouts - eg if keyboard not pressed in x milliseconds then go on to something else. It doesn't have to be super accurate.
Normally you could just setup a cog - except that I've run out.
I have a vague idea you could use the block read/write object as this is just sitting there most of the time waiting for commands R or W etc. If it was incrementing a counter too, it would only add a tiny delay.
I'm just not 100% sure of the syntax. In
there are 4 variables going in but only one coming back. How could I add another variable? Just put it after err_ with a comma? Pass back the value as part of err_ (which is a long just returning 0 or not zero). Hmm - that would mess up all the calling routines, but then again there are not very many of these.
Your advice would be most appreciated. Cheers, James
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
1) Just define another IN port address.
2) Trap the IN instructions to that address, same as we do for UART, keyboard etc, in the zicog_cpm.spin
3) In that new trap handler read the value of the Prop counter or a timer.
4) Scale the result as you like and return it to zicog.
You could also think about resetting/presetting this timer from OUT instructions.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
As heater also suggested, an IN instruction could also do this. Just reads CNT and calculates the difference since the last read. CNT increments every propeller clock cycle (so 80MHz or whatever). It is 32 bits and rolls over about every 90 seconds. A counter could also be used.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
As long as some piece of code, either Spin or CP/M, executes more often than about once every 30 seconds, you can use CNT to keep a clock / calendar.· You initially save the CNT value, then when you get control back, you do
Post Edited (Mike Green) : 12/2/2009 1:13:03 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
However, last night I was looking at the cog sizes. The TriBlade driver is about $50 longs. The fsrw has 30 free, but has 128 used for read ahead, which we are not using. I have to check and see if the buffer is used at all. If not, both these drivers would be better combined in 1 cog and there would still be room for the RTC. It would also mean an improvement in HD speed as we could transfer the data directly between SRAM and SD without going via the hub. But this will have to wait.
Meantime, just use IN and spin can read the CNT register.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
http://forums.parallax.com/showthread.php?p=788511
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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