EASy68K  
It is currently Fri Oct 19, 2018 6:31 pm

All times are UTC




Post new topic Reply to topic  [ 7 posts ] 
Author Message
PostPosted: Mon Apr 02, 2018 10:25 am 
Offline

Joined: Sat May 20, 2017 3:07 pm
Posts: 5
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.
;--------------------------------------

:(


Top
 Profile  
 
PostPosted: Mon Apr 02, 2018 8:56 pm 
Offline

Joined: Fri Dec 23, 2016 5:18 pm
Posts: 77
Location: New Mexico, USA
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.


Top
 Profile  
 
PostPosted: Mon Apr 02, 2018 9:41 pm 
Offline

Joined: Sat May 20, 2017 3:07 pm
Posts: 5
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....


Top
 Profile  
 
PostPosted: Tue Apr 03, 2018 1:33 pm 
Offline

Joined: Fri Dec 23, 2016 5:18 pm
Posts: 77
Location: New Mexico, USA
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. :shock:

What projects are you planing to do with the 68000?


Top
 Profile  
 
PostPosted: Tue Apr 03, 2018 10:12 pm 
Offline

Joined: Sat May 20, 2017 3:07 pm
Posts: 5
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


Top
 Profile  
 
PostPosted: Thu Apr 05, 2018 3:30 pm 
Offline

Joined: Sat May 20, 2017 3:07 pm
Posts: 5
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

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

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


Top
 Profile  
 
PostPosted: Fri Apr 06, 2018 3:06 am 
Offline

Joined: Fri Dec 23, 2016 5:18 pm
Posts: 77
Location: New Mexico, USA
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 7 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group