Matchbox sized 6502 / Z80 / 6809 Co Pro

emulators, hardware and classic software for atom + system machines
User avatar
flynnjs
Posts: 831
Joined: Tue Jul 06, 2010 10:33 pm
Contact:

Re: Matchbox sized 6502 Co Processor

Post by flynnjs » Sun Nov 02, 2014 9:20 pm

The vast majority of my code changes seems to re-implement what Ed has now released in the way of "PARASITE_RNWCLK_INTERFACE_D" in a far less elegant way (i.e. I didn't bother with all the 'ifdefs :oops: ) I wish I'd known he'd got a more up to date version lurking (mine was all hacked from tube.20100606T1943.tgz)

The following made the Altera tools (esp. the simulator) break (I assume they work OK on Xilinx ISE) due to no initialised state so I changed:
A few intances of 8'bx which I changed to 8'bxxxxxxxx
Some of the casex I changed (4'bxxx1) to (4b0001) ... and the other case paths.
Some 6'b1 changed to 6'b111111

Lines of tube.v I changed (looks like to correct inverted logic on my board):
161: assign p_nmi_b = (p_nmi_b_r) ? 1'b0: `P_INTERRUPT_OFF_D ;
247: p_nmi_b_r = 1'b0;
and
163: assign p_irq_b = ( (h_reg0_q_r[`I_IDX] & p_data_available_w[0]) | (h_reg0_q_r[`J_IDX] & p_data_available_w[3]) ) ? 1'b0 : `P_INTERRUPT_OFF_D;

I also found this in ph_byte.v

Code: Select all

     begin
        if ( ! h_rst_b)
          fif_q_r <= 8'h41;             
        else
		    if (!p_rnw)             <------
          fifo_q_r <= fifo_d_r ;             
     end
Which isn't right as not all paths are declared, creating a latch. But the idea was that Q should not be updated on every clock, only writes. I think I spotted this a couple of places.

I also hacked out all the DMA code as I was sure it was breaking something at the time and 6502s don't use it.

Whatever is not working now for me I'm fairly sure is down to a R3 problem but it's a long time since I've actually debugged any of this.

User avatar
hoglet
Posts: 9110
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Matchbox sized 6502 Co Processor

Post by hoglet » Sun Nov 02, 2014 9:49 pm

Thanks got this Jason, it gives me a few things to try out tomorrow.

If I understand, the NMI polarity change was to correct something that's specific to you board? Because the original polarity looked correct to me.

How far have you managed to get with your board? i.e. what's working and what's not working?

I'm also suspicious of R3, because the few times I've actually caught the problem on the logic analyzer, it looks like NMI was not going high after R3 had been read.

Does anyone know whether the 6502 and Z80 second processors use 1 byte mode or 2 byte mode for register 3?

Dave

User avatar
flynnjs
Posts: 831
Joined: Tue Jul 06, 2010 10:33 pm
Contact:

Re: Matchbox sized 6502 Co Processor

Post by flynnjs » Sun Nov 02, 2014 10:09 pm

I think I got as far a a BASIC prompt but then most commands broke and it looked like the activity was due to R3 problems.

I might just drop Ed's latest release in and see what that does.

Do you have any changes you've done loaded into a github
or anything? Might be worth us all working from the same
sheet. I'll fire up my dev system tonight so I'm ready to do
a bit more debugging throughout the week.
I'd really like to be have a stable system so I post a few of
these miniature boards out to people.

I feel re-energised to spend effort on getting this finished now!

User avatar
BigEd
Posts: 2996
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Matchbox sized 6502 Co Processor

Post by BigEd » Sun Nov 02, 2014 10:12 pm

(A previous thread tells us that only NFS (Econet) uses 2-byte mode)

Thanks for the update Jason, and sorry you didn't have our more recent work to go with. When the dust settles I'll be sure to make a new release with everything as good as we can get it. If you take the present latest one, note that it already has one known bug as noted by Dave - I must have made a merge error.

User avatar
hoglet
Posts: 9110
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Matchbox sized 6502 Co Processor

Post by hoglet » Sun Nov 02, 2014 10:20 pm

flynnjs wrote: I think I got as far a a BASIC prompt but then most commands broke and it looked like the activity was due to R3 problems.
Can you give me an example of something that doesn't work for you?
flynnjs wrote: I might just drop Ed's latest release in and see what that does.

Do you have any changes you've done loaded into a github
or anything? Might be worth us all working from the same
sheet. I'll fire up my dev system tonight so I'm ready to do
a bit more debugging throughout the week.
Everything I have done is here:
https://github.com/hoglet67/CoPro6502
flynnjs wrote: I'd really like to be have a stable system so I post a few of
these miniature boards out to people.

I feel re-energised to spend effort on getting this finished now!
Excellent.

I think if a few of us put our heads together, we'll be able to get this sorted.

Dave

User avatar
flynnjs
Posts: 831
Joined: Tue Jul 06, 2010 10:33 pm
Contact:

Re: Matchbox sized 6502 Co Processor

Post by flynnjs » Sun Nov 02, 2014 11:11 pm

I've plugged the latest github code into my overall source for my DE0nano.

I note in ph_reg3.v, flag_0 and flag_1 use p_westb_b which is undefined if you're using PARASITE_RNWCLK_INTERFACE_D

That that probably means those flags don't get clocked as it will default to GND.

User avatar
hoglet
Posts: 9110
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Matchbox sized 6502 Co Processor

Post by hoglet » Mon Nov 03, 2014 5:32 pm

Jason,

The ph_reg3.v/p_westb_b bug is a good catch - looks like a real issue to me.

My 6502 co processor is using PARASITE_RNWCLK_INTERFACE_D, so I would expect it to be affected.

I'll think about this a bit more....

Here's a small progress update from the last couple of hours...

I've been focussing on the Z80 co processor, which uses the other style of parasite interface. I put the logic analyzer on the host side of the tube, and could see that it was hanging either right at the start of the language transfer, or after the first 256 byte block had been sent. It was waiting for space to become available in R4.

I looked at the Z80 code handing R3, and spotted the following:

Code: Select all

.LFBB4
; Read 256 bytes from Tube via R3
; -------------------------------
IN   A,(&04)    ; Get R3 status
OR   A
JP   P,LFBB4    ; Loop until data present <<<<<<<<<<
INI             ; Get a byte and increment HL
JP   NZ,LFBB4   ; Loop for 256 bytes
JR   LFBAA      ; Jump to restore and exit
The line I've marked with <<<<<< tests the parity of the whole byte. This means it's affected by unused bits (which are impacted by the 6'b1 vs 6'b111111 bug which flips the parity).

Unfortunately, fixing the unused bits didn't seem to make any difference :?

I switched the Logic analyzer over to the parasite CPU address bus, and tried to figure out where it was getting stuck. It seemed to be getting stuck in the OSWRCH code:

Code: Select all

.osWRCH
PUSH AF                  ; Save character
.LF672
IN A,(&00)               ; Read Tube R1 status
BIT 6,A:JR Z,LF672       ; Loop until b6 set
POP AF:OUT (&01),A       ; Send character to Tube R1
RET
It's in the loop at LF672, which again makes no sense to me....Unless it's trying to report a fault, and the host is busy trying to transfer the language, and the two ends get deadlocked. A larger R1 FIFO here might change the behaviour.

This is all very perplexing....

Dave

User avatar
hoglet
Posts: 9110
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Matchbox sized 6502 Co Processor

Post by hoglet » Mon Nov 03, 2014 9:11 pm

I've been trying to focus on why the language transfer is failing with the z80 co processor.

It seems like the host and parasite are somehow getting out of step during the transfer of the first 256 bytes of the language ROM.

I'm testing with Basic 2 (6502 version) as my language:
- 0x8000 is 0xc9
- ...
- 0x80ff is 0x44

On the logic analyzer I can see the parasite reading the first byte (0xc9), then reading lots more bytes, then reading the last byte (0x44). But then it continues to try wait for another byte, which is never sent:

Code: Select all

.LFBB4
; Read 256 bytes from Tube via R3
; -------------------------------
IN   A,(&04)    ; Get R3 status
OR   A
JP   P,LFBB4    ; Loop until data present
INI             ; Get a byte and increment HL
JP   NZ,LFBB4   ; Loop for 256 bytes
JR   LFBAA      ; Jump to restore and exit
It starting to look to me like somehow a byte has got lost.

So, either there is a problem with the FIFO handshaking, or the Z80 is not quite keeping up.

I suspect the former, as the 6502 is sending bytes every 10us (by dead reckoning), and the Z80 loop is taking 8.3us, which is less than this, so it should be able to keep up (although it will have to check status twice every now and again).

The only part of Z80 second processor has that I haven't yet implemented is the "Desynchronizing Logic", described in the section 5.9 of service manual:
http://chrisacorns.computinghistory.org ... procSM.pdf
To prevent ambiguous events, i.e. a register status change during a
status read, this circuit produces a "WA1T" signal to the Z80
processor when the PCS and HCS signals occur simultaneously.
It's possible this is why I'm having problems. :oops:

Dave

User avatar
jgharston
Posts: 3949
Joined: Thu Sep 24, 2009 12:22 pm
Location: Whitby/Sheffield
Contact:

Re: Matchbox sized 6502 Co Processor

Post by jgharston » Mon Nov 03, 2014 11:34 pm

hoglet wrote:

Code: Select all

.LFBB4
; Read 256 bytes from Tube via R3
; -------------------------------
IN   A,(&04)    ; Get R3 status
OR   A
JP   P,LFBB4    ; Loop until data present <<<<<<<<<<
INI             ; Get a byte and increment HL
JP   NZ,LFBB4   ; Loop for 256 bytes
JR   LFBAA      ; Jump to restore and exit
The line I've marked with <<<<<< tests the parity of the whole byte. This means it's affected by unused bits (which are impacted by the 6'b1 vs 6'b111111 bug which flips the parity).
Err, no. JP P is JumP if Plus, the opposite of JP M - JumP if Minus, it jumps after a test of bit 7 of some data. Parity jumps are JP PO (Parity Odd) and JP PE (Parity Even).

Code: Select all

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

User avatar
hoglet
Posts: 9110
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Matchbox sized 6502 Co Processor

Post by hoglet » Tue Nov 04, 2014 7:00 am

jgharston wrote:Err, no. JP P is JumP if Plus, the opposite of JP M - JumP if Minus, it jumps after a test of bit 7 of some data. Parity jumps are JP PO (Parity Odd) and JP PE (Parity Even).
Thanks Jonathan - at least that explains why fixing 6'b1 bug made no difference. It also makes complete sense! I've never done any Z80 before, so I'm very likely to have more misunderstandings like this.

Language Transfer is 100% reliable on the 6502 Co Pro, and 100% unreliable on the Z80 Co Pro. I want to try to focus on the differences:
- Different parasite clock speeds
- Different code pulling data from R3
- Different bus interface model used on the tube (separate RD/RW ns RNW)

Here's my plan of action for today:
- double check that my Z80 clocking is correct and that it's running at 6MHz
- try to actually observe the byte being skipped on the logic analyzer
- try switching the tube to the RNW style bus interface

I've also been thinking about the last of "desynchronizing logic". I really don't think this should be needed. Also, it's omitted from both my designs, yet only one is failing. Also, it's not present on the later Acorn designs (i.e. none of the internal co-processors have it).

Dave

User avatar
hoglet
Posts: 9110
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Matchbox sized 6502 Co Processor

Post by hoglet » Tue Nov 04, 2014 10:58 am

Hi all,

I've finally captured an example of a byte being lost during the language transfer using R3:
IMG_0720.JPG
Some explanation of the traces:
- D14 is HCS (host accessing the tube, writing to R3Data every 10us)
- D12 is PCS (parasite accessing the tube)
- D10 is high when parasite reads R3Status
- D9 is high when parasite reads R3Data
- D0..D7 is the parasite data bus

There are two cursors are lined up with successive reads from R3Data:
- The first is reading data 0x72 which is BBC Basic address 0x801A
- The second is reading data 0x0A which is BBC Basic address 0x801C

Between the two cursors you can see the status register is being polled 3 times. One of these should have picked up the write of 0x801B that happened just after the first cursor. But this write never seems to set the data available flag.

This does look to be like a problem with the Tube implementation with certain clock ratios.

Dave

User avatar
BigEd
Posts: 2996
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Matchbox sized 6502 Co Processor

Post by BigEd » Tue Nov 04, 2014 11:41 am

This might be unpalatable, but could you make use of the host's phi2 signal and a PLL to produce the parasite clock?

It might at least show that there is a clock domain crossing problem.

(This tactic wouldn't be available for a 40-pin tube chip replacement, of course.)

Ed

User avatar
hoglet
Posts: 9110
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Matchbox sized 6502 Co Processor

Post by hoglet » Tue Nov 04, 2014 12:05 pm

Ed,

I've just switched over to the other style of Parasite bus interface (Clock and Rdnw), and I've managed to get a bit further.

The language transfer sometimes completes, and I sometimes actually see the:
Insert CP/M System disc in drive A.

Needless to say, if I do that I get no further.....

I'll try the PLL suggestion.

Dave

User avatar
hoglet
Posts: 9110
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Matchbox sized 6502 Co Processor

Post by hoglet » Tue Nov 04, 2014 1:11 pm

Hi Ed,
BigEd wrote:This might be unpalatable, but could you make use of the host's phi2 signal and a PLL to produce the parasite clock?
This is turning out to be harder than expected.

I can't get the Xilinx DCM to lock to the 2MHz signal. The min input frequency in delay locked mode is 18MHz. In non-delay locked mode it should lock to 1MHz, but it's not playing ball.

Dave

User avatar
BigEd
Posts: 2996
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Matchbox sized 6502 Co Processor

Post by BigEd » Tue Nov 04, 2014 1:18 pm

Ah. Would it be any use to clock the parasite directly from the host clock? It would of course be slow...

User avatar
hoglet
Posts: 9110
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Matchbox sized 6502 Co Processor

Post by hoglet » Tue Nov 04, 2014 1:22 pm

The reason the DCM is not locking is because on the Beeb the 2MHzE clock occasionally misses a beat (I think it is cycle stretched when the 1MHz bus is accessed).
BigEd wrote:Ah. Would it be any use to clock the parasite directly from the host clock? It would of course be slow...
This would be too slow to keep up with the host writing to R3DATA every 10us.

Dave

User avatar
BigEd
Posts: 2996
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Matchbox sized 6502 Co Processor

Post by BigEd » Tue Nov 04, 2014 1:26 pm

Curses, foiled again.

PhilYoung
Posts: 204
Joined: Sun Jun 12, 2011 5:55 pm
Contact:

Re: Matchbox sized 6502 Co Processor

Post by PhilYoung » Tue Nov 04, 2014 4:56 pm

Hi,
hoglet wrote:
The only part of Z80 second processor has that I haven't yet implemented is the "Desynchronizing Logic", described in the section 5.9 of service manual:
http://chrisacorns.computinghistory.org ... procSM.pdf
Thanks for that link, I hadn't seen that for some reason.

Although probably nothing to do with your problems, I noticed that comparing the 6502 external second processor to the Z80 there is a difference in the power supplies to the ULA.

Vcc3 is the same in each case (+5v from the host BBC)
Vcc1 is the same in each case (+5v from the wedge PSU).

Vcc2 (parasite secondary supply) in both cases is fed from the wedge PSU via a 12ohm 1W resistor (and a series inductor in the Z80, only a small resistance at DC) and is specified as 5v in the 6502 version but 'between 2v and 3v' in the Z80. So in the Z80 version it is drawing about 200mA that it isn't for the 6502.

Any idea why the difference ?

I've noticed that internal 65C102 co-pros seem to come in all permutations of Ferranti or AMI ULA and 12W resistor fitted or not fitted, which would imply that whatever that pin powers doesn't matter in the 6502 case. Which seems odd.

Cheers,

Phil Young

User avatar
hoglet
Posts: 9110
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Matchbox sized 6502 Co Processor

Post by hoglet » Tue Nov 04, 2014 5:20 pm

hoglet wrote:I've just switched over to the other style of Parasite bus interface (Clock and Rdnw), and I've managed to get a bit further.

The language transfer sometimes completes, and I sometimes actually see the:
Insert CP/M System disc in drive A.
I've gone back to this configuration, and I'm now getting "Insert CP/M System disc in drive A" all the time now. This seems highly repeatable.

So, this does seem to imply that the lost bytes during language transfer are down to the bugs in Rd/Wr interface that don't happen in the Clk/Rdnw interface, rather that the asynchronous nature of the clocks.

Now, it seems to try to access the disk, but doesn't get very far, and then hangs. It's possibly my CPM system disk is duff.

I'm using a 1770 Disk Controller, and Acorn DFS 2.26. Can anyone confirm this combination should work?

Dave

User avatar
BigEd
Posts: 2996
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Matchbox sized 6502 Co Processor

Post by BigEd » Tue Nov 04, 2014 5:32 pm

Oops, crossed in the post, maybe not needed, but for the record:
hoglet wrote:This does look to be like a problem with the Tube implementation with certain clock ratios.
Two ideas, maybe, using the on-board 49.125MHz crystal:
- make an NCO, counting off against the host-clock input, to produce a 6MHz or whatever you need.
- clock the tube and parasite system from a high-speed crystal-derived clock, and put a domain-crossing resynchronising shim on the host side. Will need some tweakery probably to detect transitions on the control inputs, to avoid multiple accesses for a single host clock's worth of inputs.

(First idea from here)

User avatar
jgharston
Posts: 3949
Joined: Thu Sep 24, 2009 12:22 pm
Location: Whitby/Sheffield
Contact:

Re: Matchbox sized 6502 Co Processor

Post by jgharston » Tue Nov 04, 2014 6:34 pm

hoglet wrote:I've gone back to this configuration, and I'm now getting "Insert CP/M System disc in drive A" all the time now. This seems highly repeatable.
That at least shows that the language transfer completes sufficiently for the Z80 Client to notice it's not Z80 code, and drop to prompting for CP/M. Next you could try putting some Z80 code in a sideways ROM and see if that starts up correctly, such as BBCTube Z80 BASIC (info).

Code: Select all

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

User avatar
hoglet
Posts: 9110
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Matchbox sized 6502 Co Processor

Post by hoglet » Tue Nov 04, 2014 6:52 pm

jgharston wrote:Next you could try putting some Z80 code in a sideways ROM and see if that starts up correctly, such as BBCTube Z80 BASIC (info).
I've already tried this and it just hangs.

I've also tried *LOAD it from the OSCLI * prompt, and this also hangs.

So, still lots of problems unfortunately.

I'm really struggling because I haven't yet got a good understanding of Rich/Ed's tube implementation.

The other *really* frustrating thing is that the RS232 on my Logic Analyzer refuses to work, so I can't extract any data. If I could, I would write a tube protocol analyzer in Java. Shame, because it has 4M sample deep memory, which has been invaluable. I might have to order something like the Papilio Logic Sniffer, or some other cheap USB logic analyzer.

Dave

User avatar
flynnjs
Posts: 831
Joined: Tue Jul 06, 2010 10:33 pm
Contact:

Re: Matchbox sized 6502 Co Processor

Post by flynnjs » Tue Nov 04, 2014 7:05 pm

I dropped the most recent tube code into my overall design last night
and it was far from happy. Reverting back to my highly modified version
and I got back to where I was before. The main differences should have
been clocking.

I'm going to throw them into the simulator tonight and see what I can
find about the differences.

Dave, the ULA netlist you derrived, could that be turned into a huge
combinatorial HDL design?

User avatar
hoglet
Posts: 9110
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Matchbox sized 6502 Co Processor

Post by hoglet » Tue Nov 04, 2014 7:12 pm

flynnjs wrote:Dave, the ULA netlist you derrived, could that be turned into a huge combinatorial HDL design?
Unfortunately not.

It uses lots of asynchronous / self times logic (a research interest of Steve Furber), which is very unlikely to work in an FPGA.

Dave

User avatar
flynnjs
Posts: 831
Joined: Tue Jul 06, 2010 10:33 pm
Contact:

Re: Matchbox sized 6502 Co Processor

Post by flynnjs » Tue Nov 04, 2014 9:26 pm

Ah, I found another bug (I think) that I fixed in my code base:
in gen_flag_m.v

Code: Select all

   always @ ( posedge p2_clk or negedge rst_b )   
     begin
        if ( ! rst_b )
          p2_data_avail_q_r <= reset_state;
        else
          p2_data_avail_q_r <= p2_data_avail_d_w ;
     end
   
   always @ ( negedge p1_clk or negedge rst_b )
     begin
        if ( ! rst_b)
          p1_full_q_r <= reset_state;               <--- Copy and paste from above, should be <=1'b1; (i.e. not full)  
        else
          p1_full_q_r <= p1_full_d_w ;
     end

User avatar
hoglet
Posts: 9110
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Matchbox sized 6502 Co Processor

Post by hoglet » Tue Nov 04, 2014 9:45 pm

Jason,

Have you taken account of the full signals being inverted in tube.v?

Code: Select all

   always @ ( p_data_w or 
              p_addr or  
              p_reg0_q_r or            
              p_data_available_w or
              p_full_w )
     begin
        case ( p_addr )
          3'h0: p_data_r = { p_data_available_w[0], !p_full_w[0], p_reg0_q_r[5:0]};
          3'h1: p_data_r = p_data_w;          
          3'h2: p_data_r = { p_data_available_w[1], !p_full_w[1], 6'b111111};
          3'h3: p_data_r = p_data_w;
          3'h4: p_data_r = { p_data_available_w[2], !p_full_w[2], 6'b111111};
          3'h5: p_data_r = p_data_w;          
          3'h6: p_data_r = { p_data_available_w[3], !p_full_w[3], 6'b111111};
          3'h7: p_data_r = p_data_w;          
          // default: p_data_r = p_data_w;
        endcase // case ( p_addr )        
     end
Should't the reset value be zero, which is what the original code passed in.

Dave

User avatar
flynnjs
Posts: 831
Joined: Tue Jul 06, 2010 10:33 pm
Contact:

Re: Matchbox sized 6502 Co Processor

Post by flynnjs » Tue Nov 04, 2014 10:11 pm

Hmm, whoops. I wonder why I "fixed" that in my code?
I wouldn't have gone prodding unless it was giving problems...
(I should have kept notes!)

User avatar
hoglet
Posts: 9110
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Matchbox sized 6502 Co Processor

Post by hoglet » Wed Nov 05, 2014 5:38 pm

Afternoon all,

Another small update.

I spent a good chunk of the day walking with Liz and Jack (the dog), so was only able to put a couple of hours in this afternoon.

My goal was to try to debug why *LOAD was hanging the Z80 Co Processor.

So, out with big guns: :D
IMG_0724.JPG
The box at the top is a HP 54622D, which has 4M deep memory, but only very simple logic analyzer features. This is attached to the parasite side of the tube, but is limited to 13 connections because that's all that's spare on the FPGA.

The box at the bottom is my recent £9.95 eBay addition - an old HP 1650A - which only has 1K deep memory, but has excellent triggering and state filtering capabilities. This is attached to the host side of the tube.

So, what's going wrong with *LOAD?

On the host side, everything looked OK, and I could see the OSCLI command being passed across the tube, then I could see a type 1 transfer being initiated, and the bytes of the file being written to R3DATA. This it hung waiting for an acknowledgement from the parasite.

On the parasite side, I could see NMI going low, and the NMI executes the instruction at 0066, which should jump to FC61. Then things start to go wrong. NMI stays low, and pretty soon it looks like the Z80 is executing code from 0000, which isn't good.

So, there is something wrong with my NMI address mangling logic. This is meant to ensure the 0066 is fetched from ROM, but then allow the rest of the NMI to exectute from RAM.

Turns out the problem was this line:

Code: Select all

    rom_cs_b <= '0' when cpu_mreq_n = '0' and cpu_rd_n = '0' and (bootmode = '1' or cpu_NMI_n = '0') else '1';
The mistake was to include cpu_NMI_n here - basically I had mis-read the Z80 schematic, and this extra term here means the whole of the NMI executes from ROM. This is clearly wrong, because the appropriate NMI routine for the transfer type is written to RAM (at FC61) prior to the transfer.

So, I fixed this, and *LOAD no longer crashes. But unfortunately, instead of loading the file into memory, it load's zeros.

A bit more head scratching and poking around with the logic analyzer, and I spotted a possible problem. I actually could see the right data being put on the Z80 data bus, but it looked like it was taken away slightly too soon.

Looking at the hp_reg3.v, I noticed the following line:

Code: Select all

assign p_data = ( p_data_available_w[0] ) ? byte0_q_r: byte1_q_r;
Now, I know for a fact the 1 byte mode is being used, so I though I wonder what would happen if I changed it to:

Code: Select all

assign p_data = byte0_q_r;
Answer? *LOAD now actually loads data. Woooo!!

I don't know if this is a real bug, or is something to do with how I'm interfacing to the Z80 (yesterday I switched to CLK/RDNW style interface which is not natural for the Z80). Need to think about this some more...Or ask Ed :lol:

The next problem to look at is that *CPM is still not working. It also hangs.

More later....

Dave

User avatar
hoglet
Posts: 9110
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Matchbox sized 6502 Co Processor

Post by hoglet » Wed Nov 05, 2014 7:10 pm

Another small step forward:
IMG_0726.JPG
I've had to increase the Z80 clock slightly - it's now running at about 8MHz. The reason I did this was that loading larger files seemed unreliable. I looked from the logic analyzer that the NMI service routine was not quite keeping up with the bytes being pushed at it at 6MHz. I have no idea why this should be the case. Maybe the T80 core is not cycle accurate.

Anyone got any ideas as to why RUN is hanging? I'm suspicious of the HIMEM being F000, as this overlaps with where Basic is running. I've lowered it, but still RUN doesn't work.

Dave

User avatar
jgharston
Posts: 3949
Joined: Thu Sep 24, 2009 12:22 pm
Location: Whitby/Sheffield
Contact:

Re: Matchbox sized 6502 Co Processor

Post by jgharston » Wed Nov 05, 2014 8:46 pm

hoglet wrote:Anyone got any ideas as to why RUN is hanging? I'm suspicious of the HIMEM being F000, as this overlaps with where Basic is running. I've lowered it, but still RUN doesn't work.
Does your Z80 implementation implement the R register? RUN waits for R to be non-zero before proceeding to seed the random number generator.

Code: Select all

; RUN - Execute program
; =====================
L0D7A:
LD   SP,(HIMEM)
LD   IX,RAND
L0D82:
LD   A,R
JR   Z,L0D82			; Wait until R is nonzero
In my Z80 emulator I just increment R every time R is accessed rather than slow down the whole engine by incrementing R for every instruction fetch.
hoglet wrote:I'm suspicious of the HIMEM being F000, as this overlaps with where Basic is running. I've lowered it, but still RUN doesn't work.
BASIC's not running at &B000, it's running at &100-&3B00. The ROM is copied across the Tube to &B000, and when entered it does some initialisation before copying the BASIC code down to the start of memory at &100. It can't transfer directly to &0100 as it would actually have to transfer to &0000 to get the initialisation code across as well, and if entered on a non-Z80 CPU it would trash system memory - for example, on a 6502 it would tramp straight over the stack and system vectors - so the usual Tube transfer address is in the &8000-&B000 region.
Last edited by jgharston on Wed Nov 05, 2014 8:51 pm, edited 1 time in total.

Code: Select all

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

Post Reply

Return to “acorn atom and acorn system series”