6809 Co Pro Client ROM

discussion of beeb/electron applications, languages, utils and educational s/w
User avatar
hoglet
Posts: 6352
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

6809 Co Pro Client ROM

Postby hoglet » Tue Jun 20, 2017 1:38 pm

I just thought I would start a new thread for issues with Jonathan's 6809 Client ROM.

This is used in the Matchbox Co Pro, and also in Pi Tube Direct, and it's mostly working quite well.

Dominic (Beesley) just PMed me to me know the version in the Matchbox is not the most recent "1.00" version (there are several). It suffers from bugs in OSBYTE A=&82, &83 and &84.

I've also just discovered event handling is broken. For example, *FX 14,4 will hang the Co Pro.

I did a bit of debugging in the PiTubeDirect 6809 debugger, and it turns out the bug is here:

Code: Select all

fd25 :                  Get_R1:
fd25 : b6fee6              LDA  >TUBE4S   ; Read Tube R4 status
fd28 : 2b02                BMI  NotFIRQ_R4   ; Pending R4 transfer higher priority than R1 transfer

should be:

Code: Select all

fd25 :                  Get_R1:
fd25 : b6fee6              LDA  >TUBE4S   ; Read Tube R4 status
fd28 : 2b02                BPL  NotFIRQ_R4   ; Pending R4 transfer higher priority than R1 transfer

I did a small patch to test, and this seems to fix the issue.

Jonathan, would you like to fix this in your sources, and maybe release a version 1.01?

Also, as this is being used in several projects, it would be really helpful if the version number could be incremented for any time new fixes are made.

Many thanks,

Dave

User avatar
jgharston
Posts: 2658
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield

Re: 6809 Co Pro Client ROM

Postby jgharston » Wed Jun 21, 2017 12:42 am

I've been scribbling up a list of tweeks, so if there are any other bugs dug out, post them and I'll do them all in one go.

I'll have a look at the PDP11 client as well, it might have the same bug. The 6812 client is most likely to have the same bug as it's the 6809 client translated into 6812 code.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
jgharston
Posts: 2658
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield

Re: 6809 Co Pro Client ROM

Postby jgharston » Thu Jun 22, 2017 2:24 pm

Here's an update. There's a couple of other tweeks I'm looking into then I'll propagate it into the 6812 client code.
http://mdfs.net/Software/Tube/6809/Clie ... 170622.bin
http://mdfs.net/Software/Tube/6809/Clie ... 170622.src

I've checked the PDP11 code, and it doesn't have this bug, but rather a different bug.The event code is supposed to read from TubeR1 while allowing TubeR4 interupts, but the PDP11 event code just reads from TubeR1. (I think) it just means that in the rare case of the host starting a data transfer in the middle of an event, the data transfer will be delayed.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
hoglet
Posts: 6352
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: 6809 Co Pro Client ROM

Postby hoglet » Thu Jun 22, 2017 5:57 pm

Thanks Jonathan,

I'll give that a try tomorrow.

Have you managed to do any testing of this, e.g. in PiTubeDirect?

Dave

User avatar
hoglet
Posts: 6352
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: 6809 Co Pro Client ROM

Postby hoglet » Fri Jun 23, 2017 10:06 am

Hi Jonathan,

I've just noticed that the contents of the above link have changes since I downloaded it yesterday.

Code: Select all

3d1dd16e4a06aace11541750c0e0efb4  101a/Client09v101-20170622.bin
fe2e12d3f23c738d3a504138da2667fa  101b/Client09v101-20170622.bin

The PiTubeDirect Diamondback RC1 now includes the current version of the 6809 Client ROM 1.01a:
https://github.com/hoglet67/PiTubeDirect/releases

It would be great if you could try this out.

Are there further things you have to finalize? I want to make sure what we include in PiTubeDirect is as stable as possible.

Dave

User avatar
jgharston
Posts: 2658
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield

Re: 6809 Co Pro Client ROM

Postby jgharston » Fri Jun 23, 2017 10:51 pm

Updates at:
http://mdfs.net/Software/Tube/6809/updates.htm
hoglet wrote:I've just noticed that the contents of the above link have changes since I downloaded it yesterday.

Code: Select all

3d1dd16e4a06aace11541750c0e0efb4  101a/Client09v101-20170622.bin
fe2e12d3f23c738d3a504138da2667fa  101b/Client09v101-20170622.bin

About an hour and a cup of tea later, I realised that I'd uploaded v1.01 a couple of hours after midnight, and v1.01a later the same calendar day before midnight, which resulted in the upload filename being the same. :(

I've been testing this with the PiTube. There's a bit of code on the update page that lets you load a replacement client on top of a live client, it works until Break and then the hardware code comes back. It's been working all evening, running various test programs and the development 6809 BBC BASIC.

I haven't been able to get my Matchbox to start up the 6809 CoPro even with the fixes applied at Cambridge, and trying four different Tube extension cables. I'm planning on unplugging the PiTube and plugging the Matchbox back in to methodically check which CoPros work.

Edit: the last thing on my list of tweeks to the client code is possibly distinguishing between 6800, 6809 and 68000 code which all have ended up with ROM Type &03.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
jgharston
Posts: 2658
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield

Re: 6809 Co Pro Client ROM

Postby jgharston » Fri Jul 14, 2017 6:34 pm

6809 Tube Client updates at http://mdfs.net/Software/Tube/6809/updates.htm

Version 1.01 build A is a bugfix update.
Version 1.02 build B adds some improvements that have been on a to-do list for ages

I've received no mention of any problems, so I rolled over the version to 1.02 and made it the main code at http://mdfs.net/Software/Tube/6809

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
jgharston
Posts: 2658
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield

Re: 6809 Co Pro Client ROM

Postby jgharston » Sun Jul 16, 2017 8:58 pm

I've been looking at the data transfer code in the 6809 client. Taking this example:

Code: Select all

FIRQ1:
FIRQ1lp:
   SYNC          ; Wait for IRQ
   LDA  >TUBE3   ; Get byte from Tube host
   STA  ,X+       ; Store in parasite memory
   LDA  DMA_DONE   ; Has flag changed?
   BNE  FIRQ1lp   ; Loop until FIRQ5 clears flag
   BRA  FIRQ_DONE

The DMA_DONE flag is updated via an interupt. The data transfer is synchronised with the SYNC instruction, which waits for an interupt. However, looking at the code it looks like the action is going to be:
SYNC - wait for IRQ
IRQ happens - DMA_DONE gets cleared
but then another LDA >TUBE/STA ,X+ happens before DMA_DONE is checked. So all byte/word data transfers will send one/two bytes too many.

It looks like the code should be:

Code: Select all

FIRQ1:
FIRQ1lp:
   SYNC            ; Wait for IRQ
   LDA  DMA_DONE   ; Has flag changed?
   BEQ  FIRQ_DONE
   LDA  >TUBE3     ; Get byte from Tube host
   STA  ,X+        ; Store in parasite memory
   BRA  FIRQ1lp   ; Loop until FIRQ5 clears flag

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
jgharston
Posts: 2658
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield

Re: 6809 Co Pro Client ROM

Postby jgharston » Mon Jul 17, 2017 12:59 am

I've done some tests and yes, the 6809 Client was erroneously transfering an extra byte or word in the transfer type 0/1/2/3 loops. v0.26 build B fixes this.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
hoglet
Posts: 6352
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: 6809 Co Pro Client ROM

Postby hoglet » Mon Jul 17, 2017 8:21 am

Thanks for this Jonathan.

That change makes sense to me.

Is there any more work on the 6809 Client ROM expected in the near future?

If not, I'll include this version in the final PiTubeDirect Diamondback release, which is due shortly.

Dave

User avatar
jgharston
Posts: 2658
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield

Re: 6809 Co Pro Client ROM

Postby jgharston » Mon Jul 17, 2017 10:15 am

I so want to say "that it, yes, done", but in debugging the PDP11 Client last night I found another bug, though one hidden by it apparently having no effect. Give it a week's testing and if nothing else has cropped up I'll roll it over to a whole number.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
hoglet
Posts: 6352
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: 6809 Co Pro Client ROM

Postby hoglet » Wed Jul 19, 2017 10:01 am

Hi Jonatham,

Some results from testing 1.02c on a Master with an updated Matchbox.

*RUN TEST09, and pressing "A" at each step

IMG_0980.JPG

jgharston wrote:TestXX: MEMTOP and MEMBOT should look sensible. 0100-F800 on 6809.

MEMBOT looks wrong.
jgharston wrote:The various calls TestXX makes should give results that make sense on context of what it says its testing

At this point it just goes on printing hex numbers forever.

(I just checked, an this doesn't happen with 1.01a so it's a regression)

Edit: See post below for an explanation.
jgharston wrote:When TestXX is paused, pressing Break should re-enter the caller (the supervisor if you haven't run anything else)

It does.

*RUN R.BASIC09

IMG_0983.JPG

jgharston wrote:When BasicXX is paused, pressing Break should re-enter BasicXX. Pressing Break again should re-enter again. And again.

It does.

Basic09 loaded into a sideways ROM

jgharston wrote:*FX142,romnumber should select it

It seems there is an issue here. One of two things happens:

1. It prints "6809 EXTENDED BASIC" and immediately returns to the * supervisor prompt.
IMG_0986.JPG

2. It prints "6809 EXTENDED BASIC" and then hangs.
IMG_0984.JPG

I just checked, and the same happens with 1.01a.

Edit: See post below for an explanation.
jgharston wrote:Ctrl-Break should select it

Same result as *FX 142,4.
jgharston wrote:Break should re-enter it

Same result as *FX 142,4.
jgharston wrote:Attempting to enter a 6502 language should give Not XXX code or Not a language

Yes, you get "Not 6809 code"
jgharston wrote:If all the BasicXX ROMs are loaded, the one relevant to the selected CoPro should be the one selected with *BASIC/Ctrl-Break, and all others should give an error if you try to enter then with *Fx142,romnumber

Is this behaviour specific to the Model B?

On the Master the only ROM that seems to be tried as a language is the one set by *CONF. LANG

I'll create a build of PiTubeDirect with this ROM, so that you can use that, and the PiTubeDirect debugger to figure this out. Back in a mo...

Dave
Last edited by hoglet on Wed Jul 19, 2017 4:01 pm, edited 1 time in total.

User avatar
hoglet
Posts: 6352
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: 6809 Co Pro Client ROM

Postby hoglet » Wed Jul 19, 2017 10:16 am

Jonathan,

Here's a dev build of PiTubeDirect that uses 6809 Client ROM 1.02c:
PiTubeDirect_20170719_1112_dmb.zip
(1.27 MiB) Downloaded 7 times

If you have a serial cable for your Pi, you can try out the debugger.

Dave

User avatar
hoglet
Posts: 6352
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: 6809 Co Pro Client ROM

Postby hoglet » Wed Jul 19, 2017 11:17 am

Jonathan,

The bug with the PR_HEX test seems to be due to an intentional API change allowing A to be corrupted.

1.01a:

Code: Select all

; Print A as 2-digit hex
; ======================
; Preserves all registers
;
PR_HEX:


1.02c:

Code: Select all

; Print A as 2-digit hex
; ======================
; API allows A to be corrupted
; All other registers preserved

Dave

User avatar
hoglet
Posts: 6352
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: 6809 Co Pro Client ROM

Postby hoglet » Wed Jul 19, 2017 2:16 pm

Jonathan,

The crash after language transfer on Ctrl-Break is caused by a bug in the 7 transfer code:

Code: Select all

; Transfer 7 - Multiple byte host -> parasite
; -------------------------------------------
FIRQ7:
FIRQ7lp:
   LDA  >TUBE3S    ; Wait for Tube R3 ready
   BPL  FIRQ7lp     
   LDA  >TUBE3    ; Get byte from Tube host via R3
   STA  B,X    ; Store in parasite memory at (X+B)         <<<<<<<<<<<<<<<<<
   INCB       ; Increment offset from X
   BNE  FIRQ7lp    ; Loop 256 times

The accumulator in the accumulator offset indexed addressing mode is treated as a signed value. So bytes 128...255 of the transfer are placed in the wrong address (i.e 8080-80FF are actually written to 7F80-7FFF, etc).

As far as I can see, this bug has always been present :shock:

I'm pretty sure I'm correct in my reading of the 6809 datasheet:
aoi.PNG

http://www.gbgmv.se/dl/doc/md09/MC6809_DataSheet.pdf

Changing

Code: Select all

   STA  B,X

to

Code: Select all

   STA ,X+

seems to fix the problem

The type 6 transfer code has the same bug.

Dave

User avatar
jgharston
Posts: 2658
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield

Re: 6809 Co Pro Client ROM

Postby jgharston » Sat Jul 22, 2017 9:08 pm

Thanks. I've been carting a printout around with me as I tromp through south-east Ireland. :) Every now and then I've scribbled bits on it.

Weird the B,X thing, I had originally implemented in my emulator as a signed offset, but I'm sure I read somewhere that it was always a positive offset, so changed it. Simple enough to fix, use B as a counter and do STA X+ in the loop.

I'll have to check the OSWORD code as well, as I think it uses B,X to transfer the control block. If the control block is 128 bytes long, then the 128th byte will be fetched from block-128 instead of block+128.

I was sketching out in my head some data transfer test code that runs on the host and pokes and peeks various stuff over to the CoPro with each of the transfer methods to test them. That's something I'll have to do when I get home.

Edit: Also, I've uploaded some notes on the TubeTest programs. It shouldn;t be in this directory, but with the limited internet access I';ve got here I just stuck it there: http://mdfs.net/Mirror/Image/JGH/CoProTests.txt

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
jgharston
Posts: 2658
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield

Re: 6809 Co Pro Client ROM

Postby jgharston » Mon Jul 24, 2017 8:29 am

hoglet wrote:
jgharston wrote:If all the BasicXX ROMs are loaded, the one relevant to the selected CoPro should be the one selected with *BASIC/Ctrl-Break, and all others should give an error if you try to enter then with *Fx142,romnumber
Is this behaviour specific to the Model B?
On the Master the only ROM that seems to be tried as a language is the one set by *CONF. LANG
It's dependent on if the ROM code has a service routine, which at the moment is just Z80 BASIC and PDP BASIC. 6809 BASIC doesn't have a service routine, so is only selectable with *FX142.

Also, the Master dos a little bit of checking with *FX142 which the BBC doesn't. The BBC selects a ROM regardless of its ROM type, the CoPro Client then checks if the Language bit is set or not. The Master checks the Language bit first, so on a BBC you will always get 'Not XXX code' from the client, on the Master you will either get 'This is not a language' from the MOS if the Language bit is not set (eg *FX142,DFSROM) or 'Not XXX code' from the Client.

The service routine that Z80BASIC and PDPBASIC have checks what CPU the CoPro is, and if it matches then they claim *BASIC, and if the current default language is not their CPU they make themselves the default language. So, for example, *BASIC with a PDP CoPro present selects PDP BASIC not 6502 BASIC, and Ctrl-Break will select whatever is the highest PDP code language ROM instead of whatever is *CONFIGUREd or the default highest language ROM.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
jgharston
Posts: 2658
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield

Re: 6809 Co Pro Client ROM

Postby jgharston » Tue Jul 25, 2017 10:11 pm

6809 Tube Client version 1.02 build Dock Beach
DMB: Bugfix: FIRQ6/7 were using signed counter offset.
JGH: FIRQ execute/transfer addresses now a seperate variable so able to rationalise and tidy ADDRHI/ADDR/TRANS/PROG variables.
Bug discovered: */(space)filename params sets LPTR to filename instead of params as with the old *RUN bug.
See http://mdfs.net/Software/Tube/6809/updates.htm

There's some updated tests on the TubeUtils disk.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

dominicbeesley
Posts: 383
Joined: Tue Apr 30, 2013 11:16 am

Re: 6809 Co Pro Client ROM

Postby dominicbeesley » Wed Jul 26, 2017 3:55 pm

Is there anything you need me to do to change BBCBASIC for the recent changes, I've been concentrating on other stuff...

User avatar
hoglet
Posts: 6352
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: 6809 Co Pro Client ROM

Postby hoglet » Thu Jul 27, 2017 10:59 am

Hi Jonathan,

I've done a bit of testing with 1.02d.

There seems to be a new bug that's messing up the language transfer and other data transfers

Here's a session in the PiTubeDirect debugger that shows the problem.

I'm setting memory read/write watch points on tube data registers (the second fff9 parameter is a mask that's applied to the watch address, so this covers fee1, fee3, fee5 and fee7). I'm also setting an instruction watch point on the start of the interrupt handler (fd03). The nice thing about watchpoints is they are completely non-intrusive (i.e. they don't significantly slow down the co pro). I'm then just hitting ctrl-break.

Code: Select all

>> watch fd03
Exec watchpoint set at fd03
>> watchr fee1 fff9
Mem Rd watchpoint set at fee1
>> watchw fee1 fff9
Mem Wr watchpoint set at fee1
>> c
Running
>>              cycle counter = 34635740544
              I_CACHE_MISS = 737377600
              D_CACHE_MISS = 4813
tube reset - copro 9
Mem Wr watchpoint hit at fcf0 : fee1 = a
Mem Wr watchpoint hit at fcf0 : fee1 = d
Mem Wr watchpoint hit at fcf0 : fee1 = 36
Mem Wr watchpoint hit at fcf0 : fee1 = 38
Mem Wr watchpoint hit at fcf0 : fee1 = 30
Mem Wr watchpoint hit at fcf0 : fee1 = 39
Mem Wr watchpoint hit at fcf0 : fee1 = 20
Mem Wr watchpoint hit at fcf0 : fee1 = 54
Mem Wr watchpoint hit at fcf0 : fee1 = 55
Mem Wr watchpoint hit at fcf0 : fee1 = 42
Mem Wr watchpoint hit at fcf0 : fee1 = 45
Mem Wr watchpoint hit at fcf0 : fee1 = 20
Mem Wr watchpoint hit at fcf0 : fee1 = 36
Mem Wr watchpoint hit at fcf0 : fee1 = 34
Mem Wr watchpoint hit at fcf0 : fee1 = 4b
Mem Wr watchpoint hit at fcf0 : fee1 = 20
Mem Wr watchpoint hit at fcf0 : fee1 = 31
Mem Wr watchpoint hit at fcf0 : fee1 = 2e
Mem Wr watchpoint hit at fcf0 : fee1 = 30
Mem Wr watchpoint hit at fcf0 : fee1 = 32
Mem Wr watchpoint hit at fcf0 : fee1 = 64
Mem Wr watchpoint hit at fcf0 : fee1 = a
Mem Wr watchpoint hit at fcf0 : fee1 = d
Mem Wr watchpoint hit at fcf0 : fee1 = a
Mem Wr watchpoint hit at fcf0 : fee1 = d
Mem Wr watchpoint hit at fcf0 : fee1 = 0
Exec watchpoint hit at fd03
Mem Rd watchpoint hit at fd62 : fee7 = 7
Mem Rd watchpoint hit at fd54 : fee7 = ff
Mem Rd watchpoint hit at fd54 : fee7 = 0
Mem Rd watchpoint hit at fd54 : fee7 = 0
Mem Rd watchpoint hit at fd54 : fee7 = 80
Mem Rd watchpoint hit at fd54 : fee7 = 0
Exec watchpoint hit at fd03
Mem Rd watchpoint hit at fd62 : fee7 = 6
Mem Rd watchpoint hit at fd54 : fee7 = 7
Mem Rd watchpoint hit at fd54 : fee7 = ff
Mem Rd watchpoint hit at fd54 : fee7 = 0
Mem Rd watchpoint hit at fd54 : fee7 = 0
Mem Rd watchpoint hit at fd54 : fee7 = 81
Exec watchpoint hit at fd03
Mem Rd watchpoint hit at fd62 : fee7 = 0
Mem Rd watchpoint hit at fd54 : fee7 = 6
Mem Rd watchpoint hit at fd54 : fee7 = 7
Mem Rd watchpoint hit at fd54 : fee7 = ff
Mem Rd watchpoint hit at fd54 : fee7 = 0
Mem Rd watchpoint hit at fd54 : fee7 = 0
Exec watchpoint hit at fd03
Mem Rd watchpoint hit at fd62 : fee7 = 82
>> r
      PC = face
      CC = E:0 H:1 H:0 I:1 N:0 Z:0 V:0 C:1 NZVC
       A = 40
       B = 00
       D = 4000
       X = ff00
       Y = ff80
       U = 0000
       S = ff7e
      DP = 00
>> s10
Stepping 10 instructions
FACB B6 FE E2    LDA   $FEE2
FACE 2A FB       BPL   $FACB
FACB B6 FE E2    LDA   $FEE2
FACE 2A FB       BPL   $FACB
FACB B6 FE E2    LDA   $FEE2
FACE 2A FB       BPL   $FACB
FACB B6 FE E2    LDA   $FEE2
FACE 2A FB       BPL   $FACB
FACB B6 FE E2    LDA   $FEE2
FACE 2A FB       BPL   $FACB
>>

If you look, the transfers via R4 seem to be getting out of sync.

Which I'm guessing is due to this change:

Code: Select all

   BSR  Get_R4   ; Get sync byte
   LDA  #$FF
   STA  DMA_DONE   ; Signal 'transfer in progress'
   ANDCC #$BF   ; DMB: re-enable FIRQ interrupts to allow Release FIRQ

to

Code: Select all

   LDA  #$FF
   STA  DMA_DONE   ; Signal 'transfer in progress'
   ANDCC #$BF   ; DMB: re-enable FIRQ interrupts to allow Release FIRQ
   BSR  Get_R4   ; Get sync byte

By enabling interrupts before reading the sync byte you are allowing the FIRQ handler to be re-entered before it's fully consumed the first data transfer request.

Dave

User avatar
jgharston
Posts: 2658
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield

Re: 6809 Co Pro Client ROM

Postby jgharston » Sun Jul 30, 2017 6:28 pm

hoglet wrote:I've done a bit of testing with 1.02d.
There seems to be a new bug that's messing up the language transfer and other data transfers
...
If you look, the transfers via R4 seem to be getting out of sync.
...
By enabling interrupts before reading the sync byte you are allowing the FIRQ handler to be re-entered before it's fully consumed the first data transfer request.

I looked at this code similar to when I was looking at the data transfer loops that tested DMADONE after transfering a byte - resulting in one more byte than needed always being transfered. I was looking at the code and it worried me that it was waiting for the sync byte and only then setting things up ready for the transfer routines. The host waits for the Sync byte to be collected before setting off and pushing data across. It looked like with a fast host/slow client the host could start pushing as soon as the Sync had been collected but before the client has set itself up.

I've been rechecking everything using the 6502 Client as the master reference, which is how I found the FIRQ4 bug. The 6502 Client makes sure it sets everything up before waiting for the sync byte, so holds the host back until the client is ready. As the 6809 uses SYNC'd polling rather than interupts it's a different issue. It probably needs ANDCC #$BF and BSR Get_R4 swapping around, even though that looks wrong:

Code: Select all

   LDA  #$FF
   STA  DMA_DONE   ; Signal 'transfer in progress'
   BSR  Get_R4   ; Get sync byte
   ANDCC #$BF   ; DMB: re-enable FIRQ interrupts to allow Release FIRQ

I'll upload version 1.02 build E in a few minutes. (Can't think of an Irish town beginning with 'E', but then I'm back homem now anyway :)

I left some redundant code in the client deliberately so a binary diff would show just a few byte changes without code being moved to different address.

dominicbeesley wrote:Is there anything you need me to do to change BBCBASIC for the recent changes, I've been concentrating on other stuff...

There shouldn't need to be, it's low level data transfer that's had the bugs in it, and 'Data Transfer' was overwriting the 'Set Execution Address'.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
hoglet
Posts: 6352
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: 6809 Co Pro Client ROM

Postby hoglet » Tue Aug 01, 2017 11:46 am

jgharston wrote:[
I'll upload version 1.02 build E in a few minutes. (Can't think of an Irish town beginning with 'E', but then I'm back homem now anyway :)

Just tested 1.02 build E and it resolves the language transfer issue.

Here's a screen photo of TEST09:
IMG_0994.JPG

Let me know if there's any further testing you want me to do.

I can also generate a PiTubeDirect build with this included if that's any use to you.

Dave

dominicbeesley
Posts: 383
Joined: Tue Apr 30, 2013 11:16 am

Re: 6809 Co Pro Client ROM

Postby dominicbeesley » Tue Aug 01, 2017 12:34 pm

Eniskillen?

User avatar
jgharston
Posts: 2658
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield

Re: 6809 Co Pro Client ROM

Postby jgharston » Sat Aug 05, 2017 6:45 pm

dominicbeesley wrote:Eniskillen?
That's in Northern Ireland, and I was travelling between Dublin and Cork, via Knockree, Powerscourt, Tramore, Waterford, Cork, Kinsale, Cobh and back to Dublin.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
jgharston
Posts: 2658
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield

Re: 6809 Co Pro Client ROM

Postby jgharston » Sat Aug 05, 2017 6:46 pm

hoglet wrote:
jgharston wrote:I'll upload version 1.02 build E in a few minutes. (Can't think of an Irish town beginning with 'E', but then I'm back homem now anyway :)
Just tested 1.02 build E and it resolves the language transfer issue.

So just the */(space)filename issue to fix. :)

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

dominicbeesley
Posts: 383
Joined: Tue Apr 30, 2013 11:16 am

Re: 6809 Co Pro Client ROM

Postby dominicbeesley » Sat Aug 05, 2017 8:53 pm

Ah, if it has to be in The Republic then how about Elphin?

User avatar
jgharston
Posts: 2658
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield

Re: 6809 Co Pro Client ROM

Postby jgharston » Thu Aug 10, 2017 11:52 pm

jgharston wrote:So just the */(space)filename issue to fix. :)

Which I appear to have done, version 1.03 build A.

*/test09 command line gives:
Image

*/(space)test09 command line gives:
Image

It also confirms that all the data transfer calls work. 1-byte and 2-byte tested by loading from network, 256-byte tested by loading EXBAS09 from ROM.

Tested on my PiTube, the 6809 on my Matchbox hangs.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
hoglet
Posts: 6352
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: 6809 Co Pro Client ROM

Postby hoglet » Fri Aug 11, 2017 6:45 am

jgharston wrote:
jgharston wrote:So just the */(space)filename issue to fix. :)

Which I appear to have done, version 1.03 build A.

Excellent. I'll test this today on the Matchbox and PiTubeDirect.

Are there other things you are working on in the 6809 Client ROM?

I'm holding off releasing a new version of the Matchbox and PiTubeDirect until you give me the nod that you are ready.

Dave

User avatar
jgharston
Posts: 2658
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield

Re: 6809 Co Pro Client ROM

Postby jgharston » Fri Aug 11, 2017 8:25 pm

hoglet wrote:
jgharston wrote:
jgharston wrote:So just the */(space)filename issue to fix. :)

Which I appear to have done, version 1.03 build A.
Excellent. I'll test this today on the Matchbox and PiTubeDirect.
Are there other things you are working on in the 6809 Client ROM?
I'm holding off releasing a new version of the Matchbox and PiTubeDirect until you give me the nod that you are ready.

I can't think of any other issues - but I said that a couple of weeks ago didn't I? :)

Give it some testing before I roll the version up to a round number.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
jgharston
Posts: 2658
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield

Re: 6809 Co Pro Client ROM

Postby jgharston » Wed Aug 16, 2017 11:25 pm

Before finalising things I'm considering making the 32-bit fields in the OSGBPB, OSFILE and OSARGS calls native 6809 big-endian words instead of 6502/Z80/PDP/32K/ARM little-endian words.

This would only affect machine code programs. Any implementation of BASIC translates API calls to and from the correct format for the API call. So far no code has been written that uses these calls, other than the Client softload tool.

What this would mean is that from 6809 machine code program instead of doing:
control:
.word filename
.byte load && $ff, (load>>8) && $ff, (load>>16) && $ff, (load>>24) && $ff ; low-endian address
...etc

you would do:
.word filename
.long load ; big-endian address
...etc

From BASIC you would still do X%!2=load%:X%!6=exec%, etc.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_


Return to “software: other”

Who is online

Users browsing this forum: No registered users and 3 guests