Shop OBEX P1 Docs P2 Docs Learn Events
TriBlade Prop PCB: Uses 3 Propeller ICs for a Single Board Computer (SBC) - Page 7 — Parallax Forums

TriBlade Prop PCB: Uses 3 Propeller ICs for a Single Board Computer (SBC)

145791032

Comments

  • Cluso99Cluso99 Posts: 18,069
    edited 2009-08-13 13:01
    I will take a look at the pasm code (Kye's and fdx) asap - probably will not be till the w/e. I coded soft uarts on the 68705 in the early 80's, so I should be able to find the problem smile.gif

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    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
  • Toby SeckshundToby Seckshund Posts: 2,027
    edited 2009-08-14 14:49
    Slightly off topic, has anybody ran a CMOS Z80 at 3.3V, at a reduced clockrate. If so how much derating was required.

    Life would be simpler if the prop and the Z80 could connect dirrectly and as it is a 10MHz (@5v) would 4MHz ish work ?

    Resistors and other "logics" could be ditched.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Style and grace : Nil point
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2009-08-14 15:07
    No never tried decreasing the voltage. Though I almost always derate the clock on a Z80 - usually to about 3.6Mhz, as it saves power and games run better (cheating? , moi?). You know, a week ago I'd have been very interested in interfacing a Z80 and Propeller. But now, with the entire thing working in an emulation, it somehow doesn't seem so important.

    As an aside, today I also soldered up an old-school Z80 board with a real Z80, eprom etc. The Zicog still isn't quite there yet - next little issue to sort out is the speed of the sd card access, which is about 1/10th of the speed of talking to a ram disk on the N8VEM. I've got used to MBASIC booting instantly. But this will come. Meanwhile,

    Working things are:
    The triblade running a Z80/CPM emulation using just 5 chips.
    SD card with multiple disk drive emulations
    Xmodem file transfers from any terminal program
    Wordstar working
    MBASIC working
    SBASIC working
    BDS C working
    Assembly compiler working

    Things I'd really like:
    More serial ports
    VGA and keyboard and the zicog on one propeller (even if it sacrifices a little speed)
    Battery backed ram disk like on the N8VEM for faster file access on drive A
    An expansion bus with 8 digital lines, 3 address lines and /WR and /RD for talking to external latches/input chips (373 and 240)
    A 20x4 LCD display like on the N8VEM for a portable solution (running as well as the vga terminal, like on the N8VEM)

    The N8VEM forum has brainstormed hybrid Propeller and real Z80 systems. I think soon we are entering a very exciting time when it can all be done inside an emulation. Or at worst, two propeller chip emulations.

    See humanoido's thread for a photo and text printout of some programming on the triblade/zicog.

    Running a Z80 at 3.3V? Thinking about that more, I wonder if that would work?
  • Toby SeckshundToby Seckshund Posts: 2,027
    edited 2009-08-14 15:57
    Ihave a "Blade 2" sat in front of me which sits above a larger board with the "Buffered Z80 MK1" and an "arduino esque" demoboard board. so I could do a sort of Blade1 / Blade2. I got as far as the 1MB test and lost track of all the compiler changes, played with other thing and now have come back to revisit it all.

    If I could do plated thru holes I am sure the Nascom would be alive by now, I will have to stop chasing perfect ideals, and achieve something. Hey-Ho.

    The slowed up real Z80 might happen. The two Prop CP/M is still a cute solution, if you can get the Props.

    I noticed a QP/M by Microcode, I think, on a search a while ago, which said it did timestamps on files, if it would help.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Style and grace : Nil point
  • heaterheater Posts: 3,370
    edited 2009-08-14 18:51
    Dr_A said "...a week ago I'd have been very interested in interfacing a Z80 and Propeller. But now, with the entire thing working in an emulation, it somehow doesn't seem so important."

    You'll never know how happy that makes me. It makes all the effort worthwhile[noparse]:)[/noparse]

    Still sorry not to have time to play along. It's a working weekend for me.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • Cluso99Cluso99 Posts: 18,069
    edited 2009-08-15 05:55
    James:

    Can you try the attached modified FullDuplexSerial in place of Kye's SerialEngine ?

    I have added rxavail which returns true (-1) if there is a character available. If this still loses characters with 1 stop bit then I will fix it (make it 2 cogs) for now.

    So...

    UART.TransmitCharacter --> UART.tx

    UART.TransmitCharacters --> UART.str

    UART.ReceiveCharacter --> UART.rx

    UART.ReceiveNumber --> UART.rxavail (BUT IT RETURNS TRUE=-1 IF CHARACTER AVAILABLE)

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    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
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2009-08-15 13:09
    Hi Cluso, studying the code now.

    I spent several hours changing the code over to Kye's object, and I know it will take just as long to change it to this new code.

    So before I embark on that, can I ask -

    Is this already working with the usb/serial chip?
    Returning -1 if no byte - yes need to go through each line and check that.

    I need to get my head around the PASM code. I find this code so hard to understand as there are some basic concepts I need to grasp. eg, in the Rx bit it has an instruction jmpret rxcode txcode
    I don't understand this instruction. Where does it jump to? A label rxcode, but this does not exist. To 'res 1', but what does that do? To another jmpret instruction that also references rxcode? To the 'chunk of transmit code', but that code starts with 'transmit' and the first instruction is to jmpret back to receive. So I can't follow any of the program flow, and thus it is hard to work out exactly what it is doing.

    The fundamental problem is to sample the start bit finely enough that you can capture the negative transition fairly soon after it happens, and then put the sample point in the middle of the bit, and then ensure it samples in the middle for the rest of the bits. But also, that puts the last sample point in the middle of the stop bit. Then you need to start sampling finely again to pick the next transition. But how do you then synchronise with sending the bits in the tx? Kye synchronised both together, but it only works because the Rx has one extra stop bit so the Tx ended slightly sooner. What I am trying to work out is the maths of fitting in proper stop bit lengths for the final stop bit on a Tx when the Rx already has shortened that slightly by the slight delay introduced by the time slice delay on the initial start bit.

    It is very complicated to work out a formula to do that if you only have one stop bit and there is a continuous stream of Rx bytes and you want to fit in Tx at the same time. The Tx code gradually gets out of synch - and the bigger the time slice on the Rx at the beginning the faster it is out of synch - eg 1/8th of a bit gets out of synch in as little as 8 bytes.

    Unless the code can cope with Tx and Rx having their start/stop bits out of synch. That, I think, is the key, but it involves some extra counters to keep track of where it is up to and I can't see those counters in this object.

    Unless you accept slightly short stop bits on the Tx. But that is a fudge and assumes the device at the other end can handle that, which assumes the device at the other end is doing things properly like sampling in the middle of the bit. Or you accept slower baud rates. But what if the device at the other end is another propeller?

    Someone mentioned on another thread an object that can handle 4 uarts on one cog? I wonder how that would work, and whether the above complexities have been considered?

    Also, this is such a complicated thing to explain that it almost needs a drawing at the beginning of the code to explain the waveforms and where the sampling happens and how it shifts back and forth between Tx and Rx.

    It is sooo much simpler just to add two stop bits. Which is what Kye said. But I would like to get to understand the pasm code a bit better in order to work out the timing works. And, sorry for the long post!

    Addit: Cluso, some time back there was mention of the drives being 32mb ie 8mb drives but only 1mb is available. I think the simh has drives I onwards as 8Mb. I tried putting a blank drive I image on the sd card and then adding the drive in the code
    FindDriveBase(8, string("DRIVE__I.DSK")) 'set the SD card drive base(s) 8MB HARD DRIVE

    But it gives a whole lot of errors when trying to access the drive. Did you ever get this working by any chance?

    Post Edited (Dr_Acula) : 8/15/2009 2:22:27 PM GMT
  • heaterheater Posts: 3,370
    edited 2009-08-15 14:26
    Dr_A: I think those JMPRETs are very sneaky.

    JMPRET RetInstAddr, DestAddress

    Stores the return address into RetInstAddr and then jumps to DestAddress, clear enough.

    But consider, if somewhere else in a different routine there is another JMPRET with reversed source and dest.

    JMPRET DestAddress, RetInstAddr

    That gets you back to where your first JMPRET left off and you first routine continues.

    And likewise if the first routine does his JMPRET again execution returns to where ever the second routine left off.

    So what we have here is two "threads" of execution that can swap back and forth between each other any time they don't have much to do.

    "Cooroutines" I think they are called in the literature. Normally one thinks of "callers" and "subroutines" but here they are both on the same level as it were.

    So I guess in this case (I have not looked at the code) the tx loop "calls" the rx loop which "calls" the tx loop and on and on. With each call the one who is called just continues from where he left off.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.

    Post Edited (heater) : 8/15/2009 2:35:22 PM GMT
  • heaterheater Posts: 3,370
    edited 2009-08-15 14:32
    I guess you will find that somewhere the rxcode and txcode destination address are initialized with the start addresses of their respective loops.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • Cluso99Cluso99 Posts: 18,069
    edited 2009-08-15 18:35
    Heater: Yes, that is precisely what the FDX code is doing.

    I am trying to determine if there is a problem requiring 2 stop bits in FDX. I don't have anything to send it a string of characters fast enough to test.

    James: You can globally replace the UART.xxx as I showed above (Ctrl-F) in the demo spin module. There are 4 types of calls. There is only 1 call that requires a fix for the -1 response. This should be a simple test. Like I said, if there is a real problem with FDX it is worth fixing.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    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
  • heaterheater Posts: 3,370
    edited 2009-08-15 18:41
    Clusso: "I don't have anything to send it a string of characters fast enough to test."

    What, not even another COG ?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • Cluso99Cluso99 Posts: 18,069
    edited 2009-08-15 18:51
    I actually meant that comment for James.

    But no. The cog will most likely disguise the problem James is seeing. I have not seen this problem. James has already fixed another problem.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    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
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2009-08-16 00:36
    Sorry for the long delays - working all this weekend. They do give me internet access at work though.

    Lots of things could give you a continuous stream of RS232 data but maybe this hasn't come up because most people are using the USB to serial chips and those chips are putting in longer stop bits? A dedicated cog ought to be able to produce the right waveform though - just make it a Tx only so as not to confuse things. This is a very complex problem to solve though - and it isn't quite a cut and paste job going back and forth in the code between different serial objects, eg Kye's code doesn't have a hex output print, so you have to put that in the main code instead. Maybe all input output could go through just a few subroutines in the main program first - I might look at that (also would solve the 13,10 vs 10 issue). Otherwise it might be heading towards ifdef hell. At least the 2 stop bits is a practical solution.

    Cluso, did you say at one stage you had dropped characters in CP/M3? If so, then maybe you have seen this problem too?

    Oh, and testing it, you can replicate it on xmodem but can't see the problem in action. Better to do it by running wordstar, open a document and then send some text into that document as a continuous serial stream. Then you can see it dropping characters with one stop bit but not with two.

    I was pondering a cog to do 4 asynchronous inputs, and another cog to do 4 outputs. At least it might be easier to understand. jmpret makes sense now, but it is still very hard to trace out the exact timing.

    I think this problem is going to be harder to solve than some of the other problems that still need looking at. Is it possible to look at getting the 8mb hard drives working, and also dropping in the faster sd card routines?

    Post Edited (Dr_Acula) : 8/16/2009 1:05:17 AM GMT
  • KyeKye Posts: 2,200
    edited 2009-08-16 01:49
    You guys ponder things to much.

    I think I've fixed the problem with my code. I've spent all day rewriting it and making it much faster and much more precise.

    Most of the changes are under the hood but I've tested it out on a few 256 byte hex dumps at different baud rates and I've had no problems. Once I finish the timing calculations for full duplex mode at 250_000 BPS I'll test the driverb out on a much larger data set looking for errors.

    ... The code is even more complicated now. Unless you really know what your doing please don't ask me to try to tell you how it works. I've used alot of implict tricks from knowledge on how the processor works to lower the maximum transmiter execution time to 61 clock cycles - its minimum is 20 clock cyels.

    ...

    The reason I don't have hex output in my code is because all hex output should be in a central library of code. It is wasteful to give each interface piece of code hex/bin/dec rountines. It is better to have one rountine in a central library. That rountine then can return a string for the string transmit rountine to use.

    ... I'll post the code later when I finish. I've spent all day working to make the code as fast as possible to eanble 250_000 BPS mode. (I had to make the driver execute stuff in less than 80 cycles at worst case).

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Nyamekye,
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2009-08-16 01:57
    Brilliant - can't wait to give it a try. And I agree re the hex thing - otherwise the objects end up with too much 'bloatware'. Will the new code be available in the next 24h?
  • Cluso99Cluso99 Posts: 18,069
    edited 2009-08-16 03:20
    Great work Kye smile.gif Look forward to seeing the code, and I agree the hex code, etc should be in a module of it's own.

    A suggestion... you are using TransmitCharacter/s and ReceiveCharacter, ReceiveNumber. This is yet another naming. TV has out, FDX has tx and str. It would be nice if all these had the same named calls so interchanging them would be easy. I run a modified version of FDX that has also has an out call but of course it wastes code/speed. Also, the call names are too long.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    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
  • KyeKye Posts: 2,200
    edited 2009-08-16 04:32
    I'll shorten the names for you guys. But in general the names will be long. I'll just change the names in the version I give you.

    I should be done within the next 24 hours. I'm kinda done now, but I'm still trying to ensure 250_000 BPS mode. Its really hard to get some parts of the code to execute in less than 80 clock cycles.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Nyamekye,
  • Cluso99Cluso99 Posts: 18,069
    edited 2009-08-16 04:34
    James: Can you give this a try? It is your last posted code with a modified FDX with Kye's calls added for simplicity, so you should only have to compile.

    Unfortunately, in my haste, I left my box of props and parts in Qld. I have blank TriBlade pcbs here with no parts - wo is me!·cry.gif

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    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
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2009-08-16 05:23
    Ok, will do when I get home. (I'm busy suturing lacerations at the moment). I'd also looking forward to testing that half duplex code. And then Kye's new code as well.
  • Cluso99Cluso99 Posts: 18,069
    edited 2009-08-16 07:16
    Maybe you could suture my lacerations ? - self inflicted when I realised I forgot my TriBlade, etc - LOL

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    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
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2009-08-16 07:47
    Packing instructions when travelling: Toothbrush, toothpaste, shaver, triblade...
  • heaterheater Posts: 3,370
    edited 2009-08-16 09:36
    Dr_A:

    I did add a lot of Spin code for emulating SIMH compatible 8MB Hard drives to zicog_demo a long time ago.

    That code emulates the SIMH Direct Memory Access interface with the hard drives.

    I have only ever been able to test that code on my PropDemo board so it does not go through any FAT file system. Straight from CP/M to sectors (blocks) on the SD card.

    I got as far as confirming that I could DIR the hard drive and "type" text files from it. I could also PIP files in and out of it from a floppy drive. However the PIP would crash when complete. So the sequence was something like:
    1) PIP a file from drive A to hard drive.
    2) It crashes/hangs
    3) Reboot CP/M
    4) Type the new file copy from the hard drive. It's there OK.

    Possibly PIP hangs because hard drive support really needs more CP/M memory than I have. Or it could be a big in the emulation. But at least it was seen to read and write.

    There were some posts about this on the ZiCog thread.

    Not sure how far Cluso got with adapting/testing that code to TriBlade with FAT system.

    By the way: I just noticed that over on the N8VEM group someone has lashed a Z80 to a Prop and is having trouble with double characters coming out of CP/M to the VGA. That has also been reported for the ZiCog, CP/M, WordStar, VGA combination. I had expected you might be one to see it again.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • heaterheater Posts: 3,370
    edited 2009-08-16 09:39
    Oh forgot to mention, you may need a recent CP/M BIOS for getting hard disks to work if you are running the emulation in 8080 mode. There was a bug in the SIMH BIOS CPU detection code that I reported to Peter Schorn which he promptly fixed.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2009-08-16 10:33
    Much rejoicing!!!

    Cluso, re that post about 6 back, those files work perfectly with 1 stop bit. I don't know how you did it but, YIPPEE!

    hop.gif

    Tested with Wordstar - all perfect.
    Tested with xmodem - all perfect.

    Right, now I guess we need to package that up into a working zip and tidy up all those mods I made along the way. Any chance you could pls re-release this with a few simple mods?

    * No need to include my name in the file now this works.
    * My baud rate was 38400 but I think most people would prefer 115k so change that.
    * Do we go 13,10? Or (here is an idea), add a simple subroutine PUB/PRI CRLF and just call it after each line, and you just modify that one PUB if you only want a 13?
    * Change that signon message re the serial settings to 1 stop bit. (it is kind of useful in case someone accidentally turned hardware flow control on or something, at least by searching the source code they would get a clue)
    * I got sick of typing 'yes' every time it booted to enable the sd card. I always wanted the sd card. So I disabled that message. Is that ok?
    * do a quick search for the term N8VEM for all the instances I added traps for N8VEM I/O calls. Maybe add these to comments in the revision list.
    * When I moved over to Kye's code I had to comment out lots of the TV.hex calls. Now there is the PUB PrintHex(value) at the end of the program, maybe uncomment them all so it calls that pub instead. Find with a search for tv.hex.
    * in 'out_constat ' I print out the port number rather than the byte. Useful to see what is going on. There seem to be some ^C (&H03) characters going out from time to time, eg just before the A> prompt. Not sure what is creating those. Eventually maybe find what is sending those, or comment out the line printing it (though maybe not yet as it still could be useful)

    Hopefully the next series of mods will be done in a bit more structured way (ie, memo to self - make more comments along the way!)
  • Cluso99Cluso99 Posts: 18,069
    edited 2009-08-16 13:19
    James: Great news - congratulations jumpin.gif

    However, that code is what I was using - there was no fix ! It is the FullDuplexSerial with the added calls to make it simulate Kye's calls. But I needed to know that the standard FDX object·did not have a bug with stop bits, so thanks for confirming. I think that you switched to Kye's code before you actually fixed the problem in the emulation thereby introducing another bug.

    re your comments...
    • would you please resend me your latest code (in case the code I sent you was not your latest)·so that I can combine your fixes.
    • v093 had a fix for baudrate so it was set only once.
    • v093 had a fix for the crlf issue in the driver, so only 1 change was required. I will think about a cleaner way to do this.
    • can now change the signon messages and Y reply (#define option)
    • agreed with the other comments also.

    I think I need a top level wrapper for the FDX/UART or whatever, so that it will be easy to substitute Serial,·Keyboard,·TV, etc.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    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
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2009-08-16 13:58
    Yes, I have about 8 folders now with different versions. Very confusing. Some of the things you sent were added and some were not. The key with Kye's code was to greatly simplify the way bytes were captured and this in turn uncovered the bug talking to CP/M.

    Anyway, the good news is that it now seems impossible to break. Stuff just seems to work. So, let's just go with that last code you posted.

    What next? The faster sd access (is the current one 100khz?). Or the 8mb drives (maybe heater can help with that 8mb code). All very exciting!
  • KyeKye Posts: 2,200
    edited 2009-08-16 18:13
    Ah, you guys didn't wait. Here's my next version. I've only tested it with a few 255 byte hex dumps and it seems to work great.

    If you can also give it a try that would be great. I think I have fixed the problems. It would be a help to me to know that it works somewhere else.

    I spent alot of time getting the receiving and transmiting code perfect and down to the few nano seconds of accuracy. The driver now samples within 4 clocks of the correct time and sends bits out within 8 clocks of the correct time.

    I only increased the size by 4 longs. So its 148 longs with 130 longs of var space. Everything I think is operational with the 256 byte in and out buffers.



    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Nyamekye,
  • KyeKye Posts: 2,200
    edited 2009-08-16 18:18
    Wait, heres one with the names changed.

    Also not that the receive check function allows you to check the last received byte that enters the serial buffers. This is usefull for using the buffers to hold an entered string of characters until some key like enter is hit. Then you can dump the buffer and do what you want with it.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Nyamekye,
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2009-08-16 23:15
    Yes, Cluso rushed off and got a whole lot of things working yesterday. Not sure how he does it! I'll plug in the serial engine code tonight and give it a test run.
  • Cluso99Cluso99 Posts: 18,069
    edited 2009-08-17 04:20
    James: It was a 5 second mod to add the call names like Kye's. You are reading way too much complexity into all this tongue.gif
    Granted that Kye's code let you look for the actual problem.

    Kye: Thanks for your code - it helped solve the real bug of dropping characters.
    I think there is a bug in the·rxavail call.

    PUB rxavail '' 3 Stack Longs
    '' ┌──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
    '' │ Returns the number of characters in the receiver buffer.                                                                 │
    '' └──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
      return ((inputHead - inputTail) & $FF)
    
    
    

    ·Should be...
    PUB rxavail '' 3??? Stack Longs
    '' ┌──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
    '' │ Returns the number of characters in the receiver buffer.                                                                 │
    '' └──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
      if inputHead >= inputTail
        return ((inputHead - inputTail) & $FF)
      else
        return ((inputHead + $FF - inputTail)) & $FF)
    
    

    Is it necessary to know the number of received characters in the buffer? If not, then this may be simpler..
    PUB rxavail : truefalse
    '' Check if byte(s) available
    '' returns true (-1) if bytes available
      truefalse := rx_tail <> rx_head
    
    

    BTW can you use a constant to define the length of the buffers like I did with the recent posting of the modified FDX for James·(also pasm needs to use the constant also)

    CON
      bufsiz = 256 '16              'buffer size (16, 32, 64, 128, 256, 512) must be factor of 2, max is 512
      bufmsk = bufsiz - 1           'buffer mask used for wrap-around ($00F, $01F, $03F, $07F, $0FF, $1FF)
    

    VAR
      byte  rx_buffer[noparse][[/noparse]bufsiz]           'transmit and receive buffers
      byte  tx_buffer[noparse][[/noparse]bufsiz]
    

      rx_tail := (rx_tail + 1) & bufmsk  'example of use
    

    Kye, we should probably continue this under your SerialEngine post as there may be input from others. I also have some other ideas for you.


    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    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
Sign In or Register to comment.