Re: [N8VEM: 3833] Re: Message to Yoda re the Propeller project

[James Moxham <mox...@internode.on.net>]

Re "For example for the keyboard and vga itwill look much like a UART to 
the Z80."

That is a very good way to understand a propeller. Speaking from a N8VEM 
perspective anyway! And down the track it will do more too - replace the 
eprom, the z80 (as Cluso already has done). Are the A.DSK images you use 
the same as Cluso's format?

A question - if you are decoding A0 and A1 only, do you also need to 
decode A2 to A7 - eg to get the address using /CS_PPI and /CS_UART.

Anyway, if you can trap z80 instructions with the propeller looking for 
certain pin combinations, that is extremely powerful. PASM sounds fast 
too. I'm used to microseconds, not nanoseconds.

I have a triblade too but it is only half completed. I got stuck with 
soldering the micro sd. I notice on your board you have a little 
adaptor. That looks very attractive. I'm looking at how the micro sd 
socket works on my uDrive modules, and it looks totally impossible to 
solder without using an oven and surface mount paste. The connections 
are inside the module. So an adaptor module like that could be very 
nice. I've got my standard sized adaptor board from futurlec too and 
that comes out to a simple 6 wire connection and I believe it is exactly 
the same wires as for the micro sd.

I might end up hacking the triblade to connect to a 6 wire SIL header 
rather than the micro sd card and get it working that way.

I've got micro, mini and standard sd card sockets from a number of 
suppliers. There seem to be lots of different layouts and the sockets 
are not easy to source. I tried soldering a mini sd card socket the 
other day and it was not all that easy either. It wasn't hard mind, but 
it required a lot of concentration and I'm comparing it with soldering 
the DIP parts on a standard N8VEM where you can do 3 pins per second and 
not even have to think about it very much. Where did you get your little 
adaptor board?

Also - level translation propeller 3V to N8VEM 5V. How does that work? 
Is 3V3 a valid high in TTL/LS/HC/HCT?

BTW I'm really excited by where this is going.

Cheers

James


yoda wrote:
> James,
>
> Think of the propeller as a super programmable I/O chip.  I can decide
> on what the protocol I want.  For example for the keyboard and vga it
> will look much like a UART to the Z80.  I will define a status
> register that can be checked to see if there is a character from the
> keyboard and I can have a busy status while the propeller is doing the
> output to vga, etc.
>
> There is a very nice instruction in the propeller that is called
> WAITPEQ or WAITPNE  which stands for Wait for Pin(s) equal or Wait for
> Pin(s) not equal.  So if you look at the schematic I have a CS, RD and
> A0 and A1 going into the propeller (maybe it was WR, I don't remember
> but you only need one of them).  So by keying on CS going low and
> looking at A0,A1 and the RD or WR I can tell which I/O port the Z80 is
> trying to read or write.  Then from that I either output the correct
> data or read the data and take action.  The tricky part is that I have
> ~450 nsec to do this.  That is approximately 35 clocks on the
> propeller so I have to be very efficient.  This part of the code will
> probably be in PASM.  I can use the status register to throttle the
> rate of I/Os if necessary so the rest of the code probably can be in
> SPIN.  My only concern is I think I am going to have to use a hub
> address for the status to communicate between Cogs and this could take
> up to 17 clocks to read based on where the hub access pointer is when
> a request a read from the hub memory.  I am looking at ways to split
> the status up and keep it private to the Cog to eliminate this non
> deterministic behavior.
>
> Dave
>
> On Jun 17, 11:47 pm, "James Moxham" <mox...@internode.on.net> wrote:
>   
>> That sounds intriguing. OUT and IN would be the simplest interface system.  
>> Do you OUT a data byte and a command byte or something like that? To one  
>> OUT address with a sequence, or to several addresses?
>>
>> The prop runs fast. I don't understand the prop very well, but can you set  
>> a cog going so it can wait for certain pin combinations that correspond to  
>> an OUT or an IN and then change the status of the data pins accordingly?  
>> Does this need to exploit the timing differences between IORQ and RD (or  
>> WR)?
>>
>> If you almost have all the pieces together, maybe this could be turned  
>> into a board??
>>
>> Cheers
>>
>> James
>>
>>
>>
>> On Thu, 18 Jun 2009 13:42:09 +0930, yoda <y....@r2d2.org> wrote:
>>
>>     
>>> James,
>>>       
>>> Take a look at the photos and schematics - there is an SD interface on
>>> my propIO board.  I have the propeller side of all the I/O (vga,
>>> keyboard and SD) working - just working on the data bus side.  I use
>>> the PockeTerm code for the keyboard and vga.  I have been able to talk
>>> to the propeller using basic OUT and INP functions so it is really
>>> putting all the pieces together.  I think the disk interface will be
>>> pretty straightforward.  I am using the same technique that Cluso and
>>> Heater have used for the files on the SD (actually had done
>>> independently before I saw their code - great minds think alike :)  If
>>> work would slow down a little and I get highly motivated for about 2
>>> days I can knock this out.  See what I can do late this week or the
>>> weekend - the code is all coded in my mind - just need to do a mind
>>> dump and some debugging.
>>>       
>>> Dave
>>>       
>>> On Jun 17, 10:07 pm, "James Moxham (Dr_Acula)"
>>> <mox...@internode.on.net> wrote:
>>>       
>>>> There are some great photos and a schematic on the wiki in the folder
>>>> DWM-PropIO. I was wondering how this project is going? The prop is
>>>> interfacing via the data bus and a few address lines, which should
>>>> make for much faster IO than using serial (to the PockeTerm). I'm
>>>> wondering whether this could be used to interface the sd card on the
>>>> prop? I can think of three different protocols - access FAT16 files
>>>> (compatible with a PC), access raw records and sectors (compatable
>>>> with CP/M), or Cluso's system where you create a single file disk
>>>> image using the simh, and then read it as CP/M files.
>>>>         
>>>> Anyway, if the prop expansion board project is growing and it is
>>>> working maybe down the track maybe we could turn this into a PCB? I'd
>>>> be most interested to hear how it is progressing.
>>>>         
>> --
>> Dr James Moxham
>> Belair Family Health Centre
>> 459 Belair Rd, Belair, South Australia
>> 5052
>> Phone: 61+8+8278 8900
>> Fax: 61+8+8370 3499
>> mox...@internode.on.net
>>
>> Using Opera's revolutionary e-mail client:http://www.opera.com/mail/
>>     
> >
>
>