[Coco] 6x09 read and write strobes.

[John Kent]

Phill sorry,

Helps if I read the email and not go off on tangents.
Sorry about that.

John.

On 16/12/2011 7:27 PM, Phill Harvey-Smith wrote:
> On 16/12/2011 03:38, John Kent wrote:
>> Falling edge of Q is it ?
>> I posted a timing diagram, on 2011/12/05 but I must have had Q inverted.
>>
>> You can use a 7400 to generate read and write strobes, or half a 74139
>> decoder.
>
> Yep Dragondos uses both :), though it does use both Q and E :)
>
>> Phil was using a CPLD and verilog to program it.
>
> Phill :) :)
>
>> The equations he used were:
>>
>> assign RD = E & RW & Reset;
>> assign WR = Q & ~RW & Reset;
>> assign nRD = ~RD;
>> assign nWR = ~WR | RamWP;
>>
>> what it should have been I think was:
>>
>> assign RD = E & RW & nReset;
>> assign WR = E & ~RW & nReset;
>
> True I think that I need to change the name of my reset input to nReset,
> I did try it with just E but it was even more flakey like that, 
> however that was before I resolved the issue, which was caused 
> elsewhere.. see below. So I may try with just E.
>
> Cirtainly the just E makes sense, as things like the 6821 do it that 
> way, and it matches the 6502 PHI NAND R/W combination, and since the 
> 6502 bus was based on the Motorola one, that also figures.
>
>> I'm not sure if his reset was active high or active low.
>> I have not used verilog much, so I'm not 100% sure of the syntax.
>> Some peripherals such as the Z8530 assert both RD & WR to reset the
>> peripheral, if my memory serves me correctly. I'm not sure if Phil was
>> trying to do that or if he was trying to prevent random read/writes
>> during reset.
>
> Prevent random access during reset, not sure if it's needed but 
> doesn't do any harm :)
>
>> I didn't get a reply from Phil Harvey-Smith, so I'm not sure if he has
>> sorted out his problem.
>
> Yep got it sorted, and it took me several days of head scratching and 
> waving a scope probe around.
>
> Basically my board has several main components, A CPLD to do address 
> decoding and buffering, an AVR to interface with the SD/MMC and some 
> RAM and ROM for the firmware. Anyway to allow for field upgrades the 
> AVR is also connected to the programming lines on the CPLD, what was 
> happening was that the programming output pins on the AVR where not 
> correctly initialised, and where chattering and causing the CPLD to 
> randomly go into programming mode, which of course meant it stopped 
> buffering and decoding....not good.
>
> Anyway correctly initialising the programming lines has fixed this and 
> all is now hopefully working.
>
> There's some pictures on facebook :-
>
> https://www.facebook.com/media/set/?set=a.2007692184197.2112104.1000448675&type=1&l=823e24b844 
>
>
> And a couple of videos on Youtube...
>
> http://www.youtube.com/watch?v=Cr3C802q8Qo&context=C353e71aADOEgsToPDskJ6a_pXYcwK0M9M_GDEktA- 
>
>
> and
>
> http://www.youtube.com/watch?v=qoLwJKakSDg&feature=context&context=C353e71aADOEgsToPDskJ6a_pXYcwK0M9M_GDEktA- 
>
>
> Cheers.
>
> Phill.
>
>
>
> -- 
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>

-- 
http://www.johnkent.com.au
http://members.optusnet.com.au/jekent