Hi there,I have been trying to sort out a couple of home made 68000 boards i have built them both on protoboard ( the sort with just round holes not strips )There one is 68000 and the other is 68010 both at 10 mhz, Both have a pair of 28C256 eeproms for rom and a pair of 128K static ram chips they both have a pair of 74ls374 wired to 16 leds from vcc, and both have an MC68681 Duart for i/o with has a 74ls138 for address decode and the other a gal chip.both have dtack driven from a 74ls121 rom/ram/latches direct from the address decoder and the duart from the duarts dtack output which does have a pullup on it.

The Problem i can write to the duart without any problem i have 8 leds on the output port and can turn them on and off at will.i can write to the transmit buffer and have chars show up on a connected pc but any attempt to read from the duart always returns 0xff so for instance to send a stringi have to insert short delays between chars or either nothing comes out or its garbled. trying to read any readable register also only ever returns 0xffI have gone over the circuit several times and can find nothing wrong. R/W is wired directly to the cpu as are the address and data lines, obviously the address decoders work as i can write to the chip just not read from it. i can change the cpu clock from 5mhz to 16mhz and the only thing that changes is the amount of time i have to pause before sending a new char.I am utterly lost at this point. all the buss and handshake signals are very clean on the scope if that is of any help.

my init code is like this...

MOVE.B #$00,ACR ; for 9600 N81 MOVE.B #$BB,CSRA ; MOVE.B #$13,MR1A ; MOVE.B #$17,MR2A ; MOVE.B #$BB,CSRB ; MOVE.B #$82,MR1B ; This is done 'inline' so that if the memory MOVE.B #$1F,MR2B ; does not work we can g'tee that the uart can MOVE.B #$05,CRA ; send an error message. MOVE.B #$05,CRB ;

my byte out routine is like this.... ;-------------------------------------- ; Writes a character to Port A, blocking if not ready (Full buffer)OUTCHAR: ; Takes a character in D1 move.w #$ff,D5 ; short delay dbf D5,* ; as reading the status byte does NOT presently work...

You may have hooked up the 68681 data bus to the wrong byte lane or address the register incorrectly. When doing a byte write, 68000 places data on both high byte and low byte so it doesn't matter which byte lane the 68681 is hooked to. For read, data for even address comes from D8-D15 and dats for odd address comes from D0-D7. So if 68681's data bus is hooked up to D0-D7, the registers must be on odd addresses.

Author:

Span [ Mon Apr 02, 2018 9:41 pm ]

Post subject:

Re: MC68681 DUART reading problem.

Wow thank you......I have been going round the bend trying to sort this out. I just moved the duarts base address up by 1 and instant success!!!! The worse thing is i should have twigged myself as i knew about the buss behaviour as i added a 74LS32 to ensure the ram or flash is written only to the intended byte......

Days and days i have been going round the twist.....Like most things like this it usually something daft...

many thanks....

Author:

Plasmo [ Tue Apr 03, 2018 1:33 pm ]

Post subject:

Re: MC68681 DUART reading problem.

I'm glad it is an addressing issue, switching byte lane is more difficult.

Being there and done that...more times than I care to admit. Sometimes I'd drop a pen and watch it fall to ground to make sure gravity is still working.

What projects are you planing to do with the 68000?

Author:

Span [ Tue Apr 03, 2018 10:12 pm ]

Post subject:

Re: MC68681 DUART reading problem.

Oh it is wired to the wrong byte lane...But by adding 1 to the uarts base address all references to the uart are shifted up by one placing it on the other byte lane.

I am doing it to learn 68k assembly , Once the basic unit is solid i want to turn it into a generic cpu module and end up building a complete 68k pc

Author:

Span [ Thu Apr 05, 2018 3:30 pm ]

Post subject:

Re: MC68681 DUART reading problem.

A general question,

I wired the duart in my 1st two prototypes to D0-D7 and had problems, before it was pointed out i was talking to the upper bytewith the uart on the lower byte, For now i have just moved the base address up by one and of course its all working again.

I am slowly working towards a pcb layout ( started again twice so far ), I assume it would be good practice to put the duart on D8-15 ?I am also thinking of adding 6 74ls245 buffers 3 for address and two for data and one for control buss then hanging a couple of isa slots being the simplestway to get a vga port and a multy-io card to give me parralel/game/2serial/ide interfaces if add 3 16 bit isa slots i would even have a spare slot for afterthoughtsFor networking i figured the easiest way would be one of those little network modules off ebay that contain everything needed.

software wise now that i have the test hardware running i am teaching myself 68k assembly and starting by implementing the same traps as easy 68kthen i can confirm if i have implemented the code fairly well or just made a dogs dinner afterwards by comparing my code with the code from easy 68k.

I have done a bit of C programming years back for both windows and Linux, these days i only dabble in Linux at home and using asmx for the 68k assembler.At the bottom i will put a short piece of 68K asm i wrote to implement the 1st trap 15 task task 0

Question besides have i made an arse of it ? ( it does seem to work when called ) It is entered via a 'trap' but i then call other routines like outchar directly without going through any traps is this good practice ?If it is considered good practice should those direct routines be callable without a trap or be considered kernel code only usable by the operating systemand any user io must go through traps ( that's what i thought was the right way to do it )

Any advice criticism here will be welcome.

Trap 15 task 0 my 1st piece of code in 68 k other than the expected 1st light ( blinking an led and getting a uart up and talking )NB i have not cheated and looked at any other code so forgive me if it's naff

Code:

;---------------------------------------_trap15_0: ; Display string at (A1), D1.W bytes long with carriage return and line feed (CR, LF). (see task 13) cmp.b #$0, D1 ; Check D1 actually has a length of more than 0 bytes. beq.s Trap150BailOut ; Nothing to copy so just bail out cleanly.

cmpi.l #$FF, D1 ; Check that were not trying to copy more than 255 bytes. bcc.s Trap150BailOut ; Over 255 so just bail out. ; If we get here then the target string has a length greater ; than zero and less than 255 ( trying to copy the same limits as easy68k ) move.l #$0,D4 ; Zero D4 and use it as a count of chars copied. move.l D1, D5 ; Save D1 as its our length specifier but is also used as the char to print in outchar move.l #$0,D3 ;Trap150_Again: ; move.b (A1)+, D1 ; Get the 1st char to copy jsr outchar ; send that char to the coms out module addi.b #$01, D3 ; Add 1 to our count holder cmp D5,D3 ; Compare the count of chars copied with target amount... beq.s Trap150BailOut ; Counts match so bail out as job done. jmp Trap150_Again ; Not yet matching so do it again.Trap150BailOut: ;All exits come through here to clean up afterwards... jsr CRLF ; ( just sends carriage return and line feed ) MOVEM.L (A7)+,D0-D7/A0-A6 ; POP ALL REGISTERS ( pushed in the base trap 15 decoder ) RTE ; And of course return from exception.;---------------------------------------

You definitely want to stay in D0-D7 byte lane for the 68681. The reason is because 68000 expects interrupt vectors on D0-D7.

68000 has decent data & address drive capability, so assuming you have a pair of RAM, a pair of ROM, and 68681, you may be able to drive 2 ISA cards without buffers.

Nothing wrong with calling trap services while inside a trap service. But since you are already in the system environment once a trap service is called, you can access the I/O directly, and save the overhead of trap service calls. The user applications normally do not access the I/O directly.

Regarding the trap service, you are saving & restoring a lot of registers for every trap call. A0-A1, D0-D2 are probably all you needed. You can always save/restore more if a particular routine needs more registers.