Shop Learn
Dracblade SBC with Catalina C, PropBasic, CP/M, MP/M, TRS80, wireless network, - Page 5 — Parallax Forums

Dracblade SBC with Catalina C, PropBasic, CP/M, MP/M, TRS80, wireless network,



  • YodaYoda Posts: 132
    edited 2009-12-19 22:39
    @heater - I thought you were still only writing the 128 bytes into a 512 byte sector? You are packing now?
  • heaterheater Posts: 3,370
    edited 2009-12-19 22:58
    cpmtools for ZiCog, read, write, format etc ZiCog hard disk images on your Windows or Linux.

    Get cpmtools from here: or as a package in Debian etc.

    Add an entry to the configuration file "diskdefs" to specify zicog HD image layout;

    diskdef zicog
      seclen 128
      tracks 2048
      sectrk 32
      blocksize 4096
      maxdir 1024
      skew 0
      boottrk 6
      os 2.2

    Then you can play with files inside a ZiCog HD image like so:

    List the contents
    cpmls -l -f zicog   ../altairz80/zipm2.dsk
    -rwxrwxrwx    8192 Jan 01 1970                           
    -rw-rw-rw-     128 Jan 01 1970  autoexec.sub                      
    -rwxrwxrwx    3584 Jan 01 1970                          
    -rw-rw-rw-   67584 Jan 01 1970  bdos.mac                          
    -rw-rw-rw-  172032 Jan 01 1970  bdos.prn                          
    -rwxrwxrwx     128 Jan 01 1970                          
    -rw-rw-rw-     128 Jan 01 1970  boot.mac                          
    Copy file out of  image:
    cpmcp -f zicog zipm2.dsk 0:ZIBOOT.COM  .
    Copy file into disk image:
    cpmcp -f zicog zipm2.dsk data.txt   0:
    Remove a file:
    cpmrm -f zicog zipm2.dsk 0:data.txt
    Format a disk:
    mkfs.cpm -f zicog new.img

    Not sure how to set zicog as the default format yet.

    Yoda: We have been using packed sectors for many months now[noparse]:)[/noparse]
    It's a useful speed up what with caching four CP/M sectors in our SD buffer space.

    For me, the past is not over yet.
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2009-12-20 01:22
    This will be *very* useful. Now we have another way of moving files in and out of disk images. And I don't need to worry about coding anything!

    @Yoda, the hard drive images ended up so much more convenient than the floppy ones that we have abandoned the floppy ones. The hard drive images are directly compatible with the SIMH. I've got a little batch file for the simh that has Drives A-H as floppy images and drives I, J as hard images. If I want (say) the drive with the C compiler, I grab it from the simh site, copy my BLANK.DSK to I.DSK, fire up my simh, do a PIP *.* to drive I, then put that drive I on the SD card (renamed as - say - C.DSK) and it is good to go.

    It would be really handy to be able to transfer these hard drive images to and from the N8VEM. I see that Andrew Lynch is starting on a board for the N8VEM using the prop. It ought to be possible for the N8VEM to get access to these 8mb drive images via the SD card.

  • YodaYoda Posts: 132
    edited 2009-12-20 02:02

    I am planning on using the same format on the propIO so that there is interchangeability. Also within reason I am trying to make them compatible at the CBIOS level as well so that they will be bootable on either platform in the future.
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2009-12-20 02:47
    Sounds good Yoda. I see you have a post on the N8VEM forum looking for an Eagle or Kicad part for the uSD socket. I never managed to find this. Maybe Cluso can help there, or anyone else?

  • Toby SeckshundToby Seckshund Posts: 2,027
    edited 2009-12-20 23:06
    With the "Make it work, and then tell people about it" theory firmly chucked, stage left, >>>>

    Ladies and gentlemen, what are you forcasts of this one working ?

    I have to go to far flung provinces of this land, and so will be denigned the switching on until Wednesday.

    Bets ( to finance the new PC PSU and garage freezer ) gratefully received

    Style and grace : Nil point
    640 x 480 - 51K
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2009-12-21 00:04
    I suspect many of us are guilty of the "announcing my new xyz board, it was really easy" which really means "here is my new board and best not mention the pile of broken boards and chips sitting in the dustbin!"

    I'm very impressed with how small you have made this. And I do like the philosophy of treating this board like a fine red wine or a tasty cheese - let it mature for a while before testing!


    Post Edited (Dr_Acula) : 12/21/2009 12:12:41 AM GMT
  • Cluso99Cluso99 Posts: 18,014
    edited 2009-12-21 03:39
    I have responded to an email from Andrew (sorry missed the post). The microSD socket is Digikey WM17115-ND CONN MINI-USB-B RECEPTACLE 5POS RT ANG (it is posted in the TriBlade BOM). It is easy to solder as the pins are open and at the card end.

    Toby, that is a great photo of a small module. I have not been following closely - what is the hardware???

    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: ··· MultiBladeProp is:
  • Toby SeckshundToby Seckshund Posts: 2,027
    edited 2009-12-21 07:19
    It's a even more cut back Drac_Blade. It only has two latches for 64K mem, but there are spare pins that Dr_A uses for his second '232 so the 64K could be 256 paged ( but withiout the common area).

    I thought CP/M stood for Cigarette Packet / Micro, doesn't it ??

    I'll be back on Weds, so perhaps then, another YIPPEE.

    Style and grace : Nil point
  • Cluso99Cluso99 Posts: 18,014
    edited 2009-12-21 09:05
    I thought CPM now stood·for a "Computer Per Matchbox" tongue.gif· (couldn't think of a better use of "P")


    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: ··· MultiBladeProp is:
  • heaterheater Posts: 3,370
    edited 2009-12-21 10:08
    Incredible !

    They will never find that on the bus.

    For me, the past is not over yet.
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2009-12-21 10:24
    He's done it! A tiny CP/M computer in a matchbox. And even room to put some of the matches back.

    Is this the first official view of a soldered up ramblade?

  • Cluso99Cluso99 Posts: 18,014
    edited 2009-12-21 11:03
    Drac: I posted photos on the RamBlade thread on the 11th.

    heater: No, but if they sit on it they will feel the pain smile.gif I am sure the pin stakes will hurt lots LOL.

    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: ··· MultiBladeProp is:
  • SamMishalSamMishal Posts: 468
    edited 2009-12-21 15:08

    A belated one, but I have not been on the forum much recently.... too much life..cry.gif

    I am SOOOOOOO impressed shocked.gif ......what wonderfully meticulous work and such professionalism.yeah.gif

    VERY IMPRESSIVE...... congratulations.jumpin.gif· It also makes me feel nostalgic.....gooood old days....

    I must also say that I like the new avatar a LOT more than the previous one.tongue.gif

    I hope you have a wonderful success with this, you deserve it.

  • Dr_AculaDr_Acula Posts: 5,484
    edited 2009-12-22 00:44
    Thanks Sam. I've been a bit quiet as I'm busy writing the code to build a wireless communications protocol for these boards. It isn't as simple as it sounds but I'm ending up with a system that takes data packets and wraps them up with headers and footers to say where they came from and where they are meant to go. Spin code sitting underneath CP/M is perfect for this. I'm heading towards using some of the 4dSystems video to RS232 devices to capture pictures and chop them up into pieces and send them wirelessly via a very simplified bittorrent type of protocol. The ultimate application is for multiple robots etc sharing pictures of their local environment.

    Plus there might be some non Z80, non CP/M applications on the way...

  • Toby SeckshundToby Seckshund Posts: 2,027
    edited 2009-12-22 20:57
    Got back early, so testing time is nigh.

    And it's another YIPPEEEE. First time, which shows that the design is near to bomb proof. This is a second time I chose to lop lumps off it and it still lives !!

    Thanks guys yeah.gif

    Now Clusso has started a size war, I'll cling to the notion that MY attempt has connectors ! Two pics- one in it's spead eagle mode and a boot screen.

    PS I don't know if this is Cigarette packet sized or not. I do not know one person that smokes. Whwn I asked, at the local shop, if I could just jet the dimensions of one they looked at me as if I were the most blatent shoplifter they had in this week ( beleive me, I,m no runner)

    Style and grace : Nil point
    640 x 480 - 51K
    640 x 480 - 54K
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2009-12-22 22:41
    So the theory of letting a board "mature" works?!!

    Good to see homebrew versions working. Which bits are you lopping off - can you post a schematic?

    Cluso has won the size war comprehensively, so I'm also going to go with the "my board includes plugs" argument. Mind you, Cluso will probably put the thing in a plug next...

    Note to self - I must get motivated to do the 'hard' problem of getting the Z80 opcoces working. I keep putting it off, partly because it is quite hard to actually isolate the instructions as the EX program has them in groups and just tells you the group failed.

  • heaterheater Posts: 3,370
    edited 2009-12-23 00:24
    Brilliant looking board Toby. Seems you know the adage about "a design is not done until you can't take any more away" !

    I see on the N8VEM group someone is proudly showing off their CP/M box. It's very nice and all but it is the size of a house by comparison!

    Dr_A: I have been looking at the missing/incorrect op codes, problem is Christmas is now going to get in the way.

    For me, the past is not over yet.
  • mikedivmikediv Posts: 825
    edited 2009-12-23 00:39
    Hey guys in anticipation of getting my Dr_Acula board I went kind of crazy and bought some lots of Sram on Ebay here is what I have,, 40Pin MK380IN-6 I think they might be Z80 chips I also have PMC Flash PM29Foo2T-12PC 32 pin 1Meg Sram I believe.
    MCM60256AP10 256K Sram, the old style 27256 Eprom and the giant 27C010A-10 32 Pin Eprom I bought 100 of each and will be happy to share if we can use them I just ask that you guys would share any code with me.. I have this awesome programmer this thing will burn any Eprom, Ram, Pic, Arm, Atmel, EEprom you name it it will burn it it also tests the chips it will do over 10K devices I even got all the adapters for it, I tested the parts and it identified them so I know they are good I can even stick code on them if you guys want to pre-program them
    Let me know if we can use them
    Oh and happy holidays to everyone,, one more thing I drew up a board design well the schematic in Eagle Pro it was a real Bich for me can anyone help me figure out how I can get my boards made now I do not know how to do anything but draw the schematic is that good enough for having boards made?? thanks
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2009-12-23 03:35
    mikediv, two boards are on their way so surely one will be able to slip through customs and border security and any postal strikes and soon a board will lob in your letterbox.

    Meanwhile, what are you doing buying all those bits?! Actually, if you want, they could come in handy for a N8VEM board if you wanted to build a real Z80 board. Certainly it has been very handy for a few of us when debugging to have a real board as well for comparison. I used my eprom programmer a lot until heater and Cluso came along and rendered it obsolete!

    One of the problems with ram chips is most run on 5V. However... there is a way to use any generic sram chip. Run the latches at 5V instead of 3V (one of the latches doing the LCD display already is at 5V). Data going into the latch from the prop will be 3V to 5V so needs no interfacing. And data coming out of the ram chip into the prop just needs 8x1k resistors in series (to prop pins P0-P7. So for the cost of 8 resistors you can use any chip you like (even 2x32k 62256s if you decode the A15 line).

    30 boards arrived today. There is no one supplier that sells everything so I'm pulling together some bits so I could send out a board plus the hard-to-get parts (eg the ram chip, the sd card holder, the coils and switchers, and the vga socket plus maybe a few more things) and then the extra parts like generic sockets and logic chips and leds and resistors could be sourced locally.

    Re Eagle, there is a huge learning curve, very steep, but well worth persevering with. Do the schematic first. Check for unconnected tracks by grabbing each component and moving it a bit. Ask for questions about the hard bits. Then move to the board. Then do the autorouter. Then do many ripups/moves/redraws on the autorouter, moving parts around slightly each time. Then optimise a few things like making power traces thicker and moving vias away from pads. Then turn it into a gerber (takes about 30 seconds but it has some obscure menus to negotiate). Then send to a PCB maker. And then they send you back the boards with a nice Christmas card as well (Thanks, OurPCB!).

    I went through all the above learning process about two years ago and I wrote some of it up in an Instructable.

    OR - make your own PCB like Toby. The design is simple enough for home PCBs.

    OR - hopefully those boards will arrive soon but if not by next week, heck, I'll send a third...

  • Toby SeckshundToby Seckshund Posts: 2,027
    edited 2009-12-23 08:04
    This latest rendition of Dr_A's is the same cct but now with the fourth and third latches missing, along with all of the '232 stuff. This meens the memory is just 64KB and my '232 to TTL interface is the only way in/out ( if that bit becomes importnt there is some space on the second layer )

    I could use P24 + P25 for memory paging up to 256KB, but then I thought I would have enough spare pins to get rid of the decoder as well.

    The op codes, I looked at your words and think I may have got the gist of the way it's done, but work has gone manic ( before Xmas ) and so all thinking would be muddled. I have 2 weeks off soon and if SHE (and HER spawn) allow me a moment's peace....

    The EX and EXX are important for the Nascom EMU_DB64.

    As for "Does size matter?" I have some SM bits and I could have another ironing fest

    PS just thought, I havent put the pullup onto the latch, again, Will try that tonight and see if this one suffers the PSU startup probs too. 5V and 3.3V separate on this one.

    Style and grace : Nil point

    Post Edited (Toby Seckshund) : 12/23/2009 8:09:30 AM GMT
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2009-12-23 12:39
    Nifty. Faster, smaller, cheaper.

    EX and EXX are coded now, but only on the dracblade, not on the official zicog. I am not sure who is the holder of the official zicog code - heater or cluso99? It was in the last drac code though I can post it again see below (though you need to add a few pointers too). Heater may well be able to see a way to code these faster. I think heater was going to have some time soon to look at these.

    I'm working on ways of getting spin and CP/M to talk to each other. Eg, let's say a board needs a unique identifier, for use in a network for instance. We can save a tiny text file on the sd card either by copying it from a PC (created in notepad) or with a few lines of spin:
    PUB WriteName ' test writing a name to the sd card from CP/M - call after the sd card initialised eg just before zicog
      sd.popen(string("MYNAME.TXT",0),"w")         ' open file Myname.txt - terminate with 0
      sd.pwrite(string("Alpha   "),8)  ' write 8 bytes to file, pad alpha beta gamma to 8 chars
      sd.pclose ' close the file   

    CP/M can send something to an out port and put up to 128 bytes at memory location 80H and can write files onto the sd card this way. But for this example, we are interested in reading files off the sd card. So, MYNAME.TXT may or may not exist. At bootup, we run this tiny code which gives a prompt if it does not exist and if it does, then prints out the name of the board.

    PUB ReadMyName | r
      ' MYNAME.TXT is a tiny text file max 8 bytes created with notepad and copied to the SD card
      ' names are ALPHA BETA GAMMA EPSILON etc through the Greek alphabet
      ' pad unneeded bytes with spaces
      r:=sd.pread(@myname,8)                                  'get 8 bytes Alpha... Beta.... etc
      if r<0
        printstringcr(string("MYNAME.TXT not found"))
        vgatext.str(String("Board name = "))
        vgatext.str(@myname)         ' terminates with 0 and the array is 9 bytes and only copied 8 to the array so the last byte is 0 which is the terminator

    Next, we need a little routine to return the filename (and, just as importantly, not crash if the board has not been named yet).

    First, define an arbitrary port number in the VAR section:
    myname_port     = $70                   ' hopefully not used by anything else

    and then capture any outputs to this port in the PRI on_output
    PRI on_output
      case io_port
          GetMyname                                         ' returns board name in DMA 80H 

    and then process this request:
    PUB GetMyname | r
        ' reads 8 bytes from MYNAME.TXT and puts them in the DMA starting at address 80
        ' could pass io_data here if wanted to pass a value (0-255)
        ' small program is myname.mac OUT (70H),A  where A doesn't really matter but is passed in io_data
      r:=sd.pread(@myname,8)                                  'get 8 bytes Alpha... Beta.... etc
      if r>=0
        RamLatches.DoCmd("W", @myname, 128, 8) ' move 8 bytes from myname array to address 80H

    and finally, some code to test this. While machine code and C are the pukka way to do this, nothing is quicker for debugging than the MBASIC interpreter:
    10 REM an out to port &H70, with any value to get back the name of the board
    20 OUT &H70,0 
    30 FOR I=&H80 TO &H87 ' read 8 bytes
    40 J=PEEK(I) ' store in J
    50 IF J>=65 AND J<127 THEN A$=A$+CHR$(J) ' ignore spaces at the end
    60 NEXT I
    70 PRINT A$ ' print out the name
    80 PRINT LEN(A$) ' and just a quick test print out the length, which is 5 for ALPHA

    While it is more complicated to create big text files on the FAT part of the SD card, this shows how it is quite easy to read and write tiny files as long as they are 128 bytes or less. This could be useful for changing bootup parameters from within CP/M by writing to various setup files. (Somthing that Cluso is working on as well).

    Next step is using these named boards to create links between boards via wireless, with a timeout and with the ability to tell other boards not to talk for a while when two boards are communicating.

    For reference, EXX and EX pasm code

    'ex af,af' overlay.  rdbyte and wrbyte are value,address for both
                            org     OVERLAY_START
    ex_af_af_ovl            wrbyte  flags, f_reg      ' local flags to hub register
                            rdbyte  data_8,f_reg      ' get it back into data_8
                            mov     data_16,f_reg     ' temp store
                            add     data_16,#8        ' alt flags location in data_16 (temp variable)
                            rdbyte  temp1,data_16     ' get the alt flag data into temp1
                            wrbyte  data_8,data_16    ' F to F'
                            wrbyte  temp1,f_reg       ' F' to F
                            mov     flags,temp1       ' put the F' to local flags
                            wrbyte  flags,f_reg       ' and put into hub too for break display
                                                      ' now do the A register
                            add     data_16,#1        ' data_16 to A' register
                            rdbyte  data_8,a_reg      ' A to data_8
                            rdbyte  temp1,data_16     ' alt A to temp1
                            wrbyte  data_8,data_16    ' A to A'
                            wrbyte  temp1,a_reg       ' A' to A
                            jmp     #fetch
                            long    $0[noparse][[/noparse]($ - OVERLAY_START) // 2]    'fill to even number of longs (REQUIRED)
                            fit     $1F0
    'exx overlay.
                            org     OVERLAY_START
    exx_ovl                 mov data_16,c_reg         ' happens to be 0 ie regbase
                            add data_16,#8            ' data_16 now points to the alt BC reg
                            rdword data_8,c_reg       ' get BC into data_8 (messy as storing 2 bytes in data_8)
                            rdword temp1,data_16      ' BC' to temp1
                            wrword data_8,data_16     ' BC to BC'
                            wrword temp1,c_reg        ' BC' to BC
                            add data_16,#2            ' point to DE'
                            rdword data_8,e_reg       ' get DE into data_8
                            rdword temp1,data_16      ' DE' to temp1
                            wrword data_8,data_16     ' DE to DE'
                            wrword temp1,e_reg        ' DE' to DE
                            add data_16,#2            ' point to HL'
                            rdword data_8,l_reg       ' get HL into data_8
                            rdword temp1,data_16      ' HL' to temp1
                            wrword data_8,data_16     ' HL to HL'
                            wrword temp1,l_reg        ' HL' to HL
                            jmp     #fetch
                            long    $0[noparse][[/noparse]($ - OVERLAY_START) // 2]    'fill to even number of longs (REQUIRED)
                            fit     $1F0  

  • mikedivmikediv Posts: 825
    edited 2009-12-23 18:59
    Thank you very much Dr_A I can't wait to build your board.. I know about the chips I just got carried away and thought 1Meg Ram Wow not really thinking it through ,, But the offer does stand if anyone wants or needs any of these chips just email and I will mail some out to you
    Dr_A if you would like a bunch for your Z80 or anything at all let me know I have 50 pieces of most and 100 of some I can not possibly use all these so guys please don't be shy even if your a neewbie and would like some chips please just ask
    I was thinking just for the heck of it we could use the 2764 eproms and make some kind of boot image or firmware I know it would eat a lot of prop pins but thinking out load could we load the BIOS from the eprom(2764) then have it disconnect through software
    the 2764 and then free the I/O lines????

    P.S Heater I am not positive it was you but I thought someone was looking for the older style eproms if you want any of the chips or even the Z80 please just ask I know same deal the 1Meg ram will eat pins but I have 256K Sram as well.

    Dr-Acula I have been designing schematics for ever I can do that I want to have real boards made from my designs if you don't mind me asking in Eagle Pro I have been trying to learn but I am confused do I have to when building a board set each and ever individual PAD??
    I can take parts and place them on the boards and I figured out how to run wires but it does not look right I am not sure what to do about the PADS????
    Can I show you a quick example of what I did ?
    Thank you
  • Toby SeckshundToby Seckshund Posts: 2,027
    edited 2009-12-23 20:15

    I have put the 10K pullup onto the '138 gate and the waveform goes from the sagging signal (expected) to a crisp held up one. This time the systen boots ok with, or without the pullup but with the added capacitance of the 'scope probe, without the 10K, booting was a random affair. This time I have ran the 5 Volt and 3.3 Volt regs off of the incoming 9 Volts, rather than cascading them, the beasty runs barely warm anyway.

    Speaking of stacks of old chips, I still have a load of 27c1001s but I need to run WIN98 to to get the KISS programmer to go.

    Style and grace : Nil point
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2009-12-23 23:19
    Hi mikediv. Parallelling up eproms and ram chips would be quite possible as all the address and data lines could be shared, and you could do the chip select off a spare 138 output. The biggest problem is the 5V issue so would need those 8x1k resistors.

    Re Eagle, can you describe the problem a bit more? Just for a very simple example, start a new schematic and drop a couple of TTL chips on it, and join with one wire. Then go to the board view and you will see the two chips off the board. Move them into the middle of the board and you should see the airwires joining the pads. Then run the autorouter and it will put in the traces. So you never really need to worry about joining to the pads (yes, you can do manual tracing but I've never needed to).

    Can you a quick screen capture of what you have done and post it here as an attachment?

  • Dr_AculaDr_Acula Posts: 5,484
    edited 2009-12-24 11:39
    My new boards arrived (version 3) and I soldered up three of them.

    Silly me though, I was short one 10k pullup so I decided to leave one out, and now it doesn't work. The line I left it out of is DO of the SD card (to P12 on the prop) and I figured this could be left out because it was data from the sd card to the prop. The current schematic has 10k pullups on CS, DI, CLK and IRQ.

    Bad move! Putting in an extra resistor fixes it so this is the problem. I think this might be related to some of the problems Toby is having and I'm starting to think all the pullups are needed. But I don't understand why...

    Ok, deep inside the code, in the sdspiFemto.spin is some code to stop the DO pin. I'm not 100% sure how much of this 'stop' code is there because it is needed to drive an SD card, or because of Cluso99s specific requirements.

    (Intriguingly, Cluso comes up in the very latest fsrw code safe_spi
    {=== these PASM functions get me in and out of multiblock mode ===}
            ' we're already out of multiblock mode, so
            ' deselect the card and send out some clocks
            or outa,maskCS
            call #in8
            call #in8
            ' if you are using pull-up resistors, and need all
            ' lines tristated, then uncomment the following line.
            ' for Cluso99
            'mov dira,#0

    But that isn't code I'm using. This is the code I'm using:

    '' Stop SPI communications.  Any previously used I/O pins are set to input
    '' mode and the masks for the I/O pins are zeroed.
                            andn    dira,spiMaskCS          ' This is used for the situation
                            mov     spiMaskCS,#0            '  where the pins used for the SD
                            andn    dira,spiMaskDI          '   card may be used for some other
                            mov     spiMaskDI,#0            '    purpose when the card is removed
                            andn    dira,spiMaskClk
                            mov     spiMaskClk,#0
                            andn    dira,spiMaskDO
                            mov     spiMaskDO,#0
                            jmp     #i2cGoUpdate
    ' Cluso code commented out at present
    ' Modification by Cluso99 to force the SD card to tristate the D0 pin (allows other chips on the bus)
    spiDoStop               or      outa,spiMaskCS          ' CS=1
                            andn    dira,spiMaskDO          ' disable D0 as output (s/be input anyway)
                            call    #spiRecvByte            ' Output a stream of clocks 
                            andn    dira,spiMaskCS          ' CS input
                            mov     spiMaskCS,#0            ' 
                            mov     spiMaskDO,#0            ' D0 already input (above)
                            andn    dira,spiMaskDI          ' DI input
                            mov     spiMaskDI,#0            '  
                            andn    dira,spiMaskClk         ' CLK input
                            mov     spiMaskClk,#0
                            jmp     #i2cGoUpdate

    The thing is that I don't understand what is supposed to be going on here. My understanding is that DO only ever is an input to the propeller, so I can't see why you would want to disable it. Indeed, in Cluso's code there is the comment "s/be input anyway". Except that Cluso also then goes and explicitly makes it tristate just after that line.

    I'm trying to work out what the code does when it boots up the SD card. I'm presuming it sends out some bytes and then expects something to come back. I'm not sure why the pullup on DO should make any difference to what comes back - it should be high or low regardless of the pullup. The only explanation here that I can think of is that somewhere in the code it reads back a high which registers as success in some way, but the high is there because of the pullup, not because of the SD card status. And that has never really been obvious that is happening because everyone specifies the pullup.

    The *simple* answer is to put the pullup on DO. But then I have to get more boards made OR send out boards with an errata.

    There seems to be a lot of different opinions out there on the 'net about pullups. Eg "In the Appendix on page A-1, the PDF briefly mentions that MMC cards power up in open-drain mode and can not handle a clock faster than 400KHz. After initializing the card, it switches over to push-pull mode where the pull up resistor would no longer be needed."

    Implying you do need pullups. fsrw mentions 6 resistors for 4 lines. Are the other two DAT1 and DAT2? (pins 8 and 9 on the sd card)

    Oh, and just to muddy the waters even further, this is a standard sized sd card, but it actually is a micro sd card sitting in an adapter that goes to a standard sized one. So it really is a micro sd card (I have not had much luck with certain brands of standard size sd cards, so I'm sticking with sandisk 1gig uSD in a standard holder, because it works (and because they are only $7 on ebay))

    The circuit that works is which has *five* pullups. I'm not sure I'm game to leave any of them out now without really understanding more about how this works.

    Anyone who can shed some light on this (fsrw experts) would be most appreciated!


    Post Edited (Dr_Acula) : 12/24/2009 12:17:51 PM GMT
  • LeonLeon Posts: 7,620
    edited 2009-12-24 12:41
    On my SD card I/F I only put a pullup on CSn, and don't have any problems. Rayman doesn't have any problems with no pullups!

    I use a MiniSD card which is actually an adapter with a microSD card in it. It's supplied by Kingston Micro. I'd be a bit wary buying stuff like SD cards off Ebay, especially if they are very cheap. Their are lots of counterfeiters around.


    Amateur radio callsign: G1HSM
  • Toby SeckshundToby Seckshund Posts: 2,027
    edited 2009-12-24 14:30
    I found that I didn't need any of the pullups on Propcomm ccts and so I didn't put any on the Blade2 Bd, on the VDU bit, Clusso has some already on his bit but as that is using each pin for half a dozen different things I left them in. I have used 10Ks on all 4 lines on both of the DB bds as you had said that you had early problems without them. The pullup I keep forgetting is the 74HC138 pin4 one, this leads to ram access problems and the sysyen drops out with a "Spacebar" error, which I do not see fully because I do not build the two '232 bits.

    The small 64K version seems to be better on bootups, with or without the gate pullup, which is on now. Perhaps it is better layout, different feeding of the two regs or the on/off switch I remembered this time, which should give a better defined power rising edge.

    The addition of pullups didn't seem to help, or hinder, with the operation of more SD cards, only the two (of 5) fired up.

    Style and grace : Nil point
  • Toby SeckshundToby Seckshund Posts: 2,027
    edited 2009-12-24 15:00

    I have just lifted the DO pullup and baby still fires up, and loads MBASIC, etc, ok.

    Style and grace : Nil point
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2009-12-26 01:05
    I'll get to the fsrw code soon, but in the meantime I've written the code to latch the A16-A19 of the high latch. So now the raw code for banking is ready to go, plus this gives easy access to all 512k of the ram chip.

    There is a new command H to set the high byte latch. So the command set is now:
    ''Dracblade driver for talking to a ram chip via three latches
    '' Modified code from Cluso's triblade
    ' DoCmd(command_, hub_address, ram_address, block_length)
    ' R - read bytes at address n up (n to n+block_length) where n =0 to 65535 (ie lower 64k of the sram chip)
    ' W - write bytes at address n up
    ' I - initialise
    ' N - Led on (pass "N" and other values are zero)
    ' F - Led off
    ' H - set high latch to value in ramaddress A16 to A23 (will include the led) 

    Given the address is already passing a long, this is passed with the address
      HighLatchByte :=%00000000_00000000_00000000_00000000 ' xxxxxxxx_nnnnnnnn_xxxxxxxx_xxxxxxxx where n is A16 to A23
      RamLatches.DoCmd("H", 0, HighLatchByte, 0)           ' set high latch byte A16-A19, plus led plus the 4 spare outputs                  

    So for bank 0 pass zero, for bank 1 pass
    HighLatchByte :=%00000000_00000001_00000000_00000000


    HighLatchByte is added to the VAR list in the main program

    If you set it up to run in bank 111, ie in the top 64k of the sram, instead of the bottom 64k ram, it will happily load zicog and run CP/M fine. This leads to the concept of running a number of virtual CP/M machines all at once, which I think is what MP/M does.

    In the dracblade.spin program there are some extensive changes to add the new H command. There also ended up some common code with turning the led on and off, so it ended up simpler to combine these all together. As a result, the syntax for turning on and off the led has changed in the spin code in the Main program

    Instead of

    the command is now


    Which is more in keeping with passing a command as a single letter, and then 0 to 3 variables.

    I've attached the entire code as a zip.

    And I should add there is a bit of code at the beginning that reads the name of the board as a tiny text file off the sd card. If you don't want this then comment it out - the command to do this is just before the zicog is started
      ReadMyName ' comment this out if not needed

    I'm naming boards so that they can find each other in a network. Also it demonstrates a way of CP/M talking to FAT16 files on the sd card.

    Also I've been working on a new board layout - making chips closer and have managed to create enough space to add an octal buffer for another 8 inputs. This won't affect any of the existing code, but it does give the board 8 inputs (and the existing 4+2+1=7 outputs)


    Post Edited (Dr_Acula) : 12/26/2009 2:00:20 AM GMT
Sign In or Register to comment.