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 string
i 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 0xff
I 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...

btst #2,SRA ; Check if transmitter ready bit is set
beq OUTCHAR ;
move.b D1,TBA ; Transmit Character
rts ; and return from whence we came.
;--------------------------------------

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.

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....

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?

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

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 byte
with 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 simplest
way 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 afterthoughts
For 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 68k
then 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 system
and 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


(Use Code tags to keep source format. Highlight source and press Code button. Admin)

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.