Minimal Tube 6502decode bus snoop with FTDI USB

for bbc micro/electron hardware, peripherals & programming issues (NOT emulators!)
cmorley
Posts: 1019
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford
Contact:

Minimal Tube 6502decode bus snoop with FTDI USB

Post by cmorley » Fri Jan 19, 2018 11:45 am

Thread Links:
Photos:
PCB Photos
Assembled Photo
Instructions:
Assembly
Purple FT232H board
Source
Operation
Linux notes


I bought some FTDI breakout boards and have been reading up on them. I've also been half following hoglet's threads on logic analyser and then Tube bus snooping with his 6502decode tool. I wondered if I could connect an FT232H or FT2232H directly to the Tube to stream the bus to to BBC...

FT232H or FT2232H boards are available on eBay for £6-7 delivered.

Turns out you can, with no extra components. The FTDI chips are 5v tolerant. They have a CPU FIFO mode which makes the interface like a Z80 bus with CS#, WR# and RD#.

I changed the FTDI chip to CPU FIFO mode & connected up an FT2232H with some jumper wires and it just works.

FT2232H :
D0-D7 : Tube D0-D7
CS# : 0v (stream everything) or TUBE# (stream all tube activity)
RD# : 3.3v
WR# : 2MHzE (works because FT232H captures data on falling edge)
A0 : 0v (FIFO send)
Photo0760.jpg
The interface is synchronous so you get 1 byte per bus cycle. The USB is HiSpeed so easily handles 2MB/s.

Hoglet's 6502decode currently uses R/W but I think it could be modified to delete that dependency. The interrupt detection for example would have to change to watch for PC & P being pushed for example.

Since 6502decode + Tube bus snooping looks like it could be very useful for diagnosing ill Beebs I thought I'd share this finding. One could solder a cut up IDE cable straight to the breakout board. FTDI drivers are well supported on multiple platforms.

Edit:
With "stream tube" you get a dummy byte you need to ignore before every actual byte. These should be discarded by the PC. This is because you get a byte when 2MHzE is low and TUBE# goes low (e.g. FE if instruction is STA &FEE1) then the actual value next cycle when 2MHzE goes low.
Last edited by cmorley on Sun Mar 25, 2018 1:06 pm, edited 2 times in total.

cmorley
Posts: 1019
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford
Contact:

Re: Minimal Tube 6502decode bus snoop with FTDI USB

Post by cmorley » Fri Jan 19, 2018 12:57 pm

Here is a few seconds of a BASIC hello world running: hw.bin

Browsing in a HEX editor it looks like the bus snooping is working as expected.

I simply used from a command prompt on a Windows machine:

Code: Select all

type com2: > log.bin
EDIT: this is only 7bit ASCII!!! So I redid it from cygwin with:

Code: Select all

cat /dev/ttyS1 > boot.bin
Here is the following assembly loop with interrupts enabled: loop.bin

Code: Select all

   10DIM mc% 256
   20P%=mc%
   30[
   40.go
   50LDA #65
   60STA &7C00
   70INC &7C01
   80JMP go
   90]
Also a cold boot capture: boot.bin
(Reset vector fetch is @ 0x00034c17)
Attachments
snoop.rar
(139.98 KiB) Downloaded 28 times

User avatar
myelin
Posts: 740
Joined: Tue Apr 26, 2016 9:17 pm
Location: Mountain View, CA, USA
Contact:

Re: Minimal Tube 6502decode bus snoop with FTDI USB

Post by myelin » Sat Jan 20, 2018 12:53 am

Nice work! It's exciting to see everything decode6502 is enabling :)
Last edited by myelin on Sat Jul 06, 2019 6:14 am, edited 1 time in total.
SW/EE from New Zealand, now in Mountain View, CA, making BBC/Electron hardware projects for fun.
Most interesting: Arcflash, FX2+PiTubeDirect Tube/Cartridge adapter, USB cart interface.

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

Re: Minimal Tube 6502decode bus snoop with FTDI USB

Post by hoglet » Sat Jan 20, 2018 1:16 pm

Just to say I'm following this thread with interest, but am otherwise a bit distracted at the moment with a broken central heating system. :-({|=

Next week I'll try to make R/W optional in 6502decode. I've just been looking at the code and it is a bit of rework, but I think it should be possible.

Currently R/W is used for two things:
(1) - allows bus cycles to be added to the "read accumulator" or the "write accumulator", which made the emulation simpler.
(2) - to detect an interrupt (three successive writes, PC then PSW)

For (1) we can substitute a single combined "accumulator" that is simply the data from the bus cycles that follow the instruction. It may be simpler to change this structure to a byte array. At the moment I'm also thinking we need to indicate in the opcode tables which cycles are expected to be reads vs writes. But this might be avoidable.

For (2) we need to look for PC (hi), PC (lo), PSW appearing on the bus in cycles 2, 3 and 4 respectively. This is quite unlikely to happen by chance.

Of course, if anyone else want's to hack the code to do this, feel free!

Dave

cmorley
Posts: 1019
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford
Contact:

Re: Minimal Tube 6502decode bus snoop with FTDI USB

Post by cmorley » Sat Jan 20, 2018 6:56 pm

Ok... so both "type com2: >" from DOS or cat from cygwin output 7bit unless something configures the COM port as 8 bit. So some init needed but both methods work.

Hoglet look away now... no peeking...

So I hacked the source in hoglet's github archive and modded it to support 8bit and 16bit dump files. I killed the separate read & write accumulators and combined that in one. This would be better as a history buffer.

I fixed up interrupts to look for the PC push. I couldn't immediately see how to get the flags & didn't want to change the co-sim so I left PC detection only. I also fixed up reset detection if there is no reset line in the log. It is hacky because I looked for the vector pull of DCC9 + the LDA# which is the first instruction a B with OS1.20 runs... as I said a hack but works.

I tried it on my test captures I posted and created another log too of a break press from running a loop with interrupts disabled for my easier debugging!

I murdered and trampled a few other things on my way through but this hack of main.c is working. Needs a real tidy up.
main.rar
(7.33 KiB) Downloaded 23 times
Output example:
reset.rar
(208 Bytes) Downloaded 24 times

Code: Select all

???? : BRK #00
pc: prediction failed at 0005 old pc was 0000
0005 : BRK #00
!!!RST
pc: prediction failed at D9CD old pc was 9B07
D9CD : RESET !!
D9CD : LDA #40
D9CF : STA 0D00
D9D2 : SEI
D9D3 : CLD
D9D4 : LDX #FF
D9D6 : TXS
D9D7 : LDA FE4E
D9DA : ASL A
D9DB : PHA
D9DC : BEQ D9E7
D9DE : LDA 0258
D9E1 : LSR A
D9E2 : CMP #01
D9E4 : BNE DA03
DA03 : LDX #0F
DA05 : STX FE42
DA08 : DEX
DA09 : STX FE40
DA0C : CPX #09
DA0E : BCS DA08
DA08 : DEX
DA09 : STX FE40
DA0C : CPX #09
DA0E : BCS DA08
DA08 : DEX
DA09 : STX FE40
DA0C : CPX #09
DA0E : BCS DA08
DA08 : DEX
DA09 : STX FE40
DA0C : CPX #09
DA0E : BCS DA08
DA08 : DEX
DA09 : STX FE40
DA0C : CPX #09
DA0E : BCS DA08
DA08 : DEX
DA09 : STX FE40
DA0C : CPX #09
DA0E : BCS DA08
DA08 : DEX
DA09 : STX FE40
DA0C : CPX #09
DA0E : BCS DA08
DA10 : INX
DA11 : TXA
DA12 : JSR F02A
F02A : LDY #03
F02C : STY FE40
F02F : LDY #7F
F031 : STY FE43


Hoglet: I see you crib info out of the byte stream to set emulation registers. This can be done for the flags too on an interrupt entry.

I've been using my FT2232H (dual) adapter so far but have some cheap FT232H (single channel) ones on order. I might do a PCB adapter to make it a simple plug in based on the headers on the cheaper Chinese ones... £6.50 from ebay $6.50 from aliexpress incl postage.

cmorley
Posts: 1019
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford
Contact:

Re: Minimal Tube 6502decode bus snoop with FTDI USB

Post by cmorley » Sat Jan 20, 2018 6:59 pm

P.S. I built it under cygwin because it seemed like the quickest way to get libargp.

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

Re: Minimal Tube 6502decode bus snoop with FTDI USB

Post by hoglet » Sat Jan 20, 2018 8:17 pm

Nice...

Does the register emulation still work correctly?

cmorley
Posts: 1019
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford
Contact:

Re: Minimal Tube 6502decode bus snoop with FTDI USB

Post by cmorley » Sat Jan 20, 2018 8:27 pm

hoglet wrote:Nice...

Does the register emulation still work correctly?
$ ./decode6502.exe -h -s loop.bin > out.txt

Code: Select all

DE66 : AE 4D 02 : LDX 024D       : A=D6 X=04 Y=03 SP=?? N=0 V=0 D=0 I=1 Z=0 C=1
DE69 : 20 8F DE : JSR DE8F       : A=D6 X=04 Y=03 SP=?? N=0 V=0 D=0 I=1 Z=0 C=1
DE8F : E0 05    : CPX #05        : A=D6 X=04 Y=03 SP=?? N=1 V=0 D=0 I=1 Z=0 C=0
DE91 : 90 02    : BCC DE95       : A=D6 X=04 Y=03 SP=?? N=1 V=0 D=0 I=1 Z=0 C=0
DE95 : 8E 4C 02 : STX 024C       : A=D6 X=04 Y=03 SP=?? N=1 V=0 D=0 I=1 Z=0 C=0
DE98 : AC 4E 02 : LDY 024E       : A=D6 X=04 Y=00 SP=?? N=0 V=0 D=0 I=1 Z=1 C=0
DE9B : 88       : DEY            : A=D6 X=04 Y=FF SP=?? N=1 V=0 D=0 I=1 Z=0 C=0
DE9C : 98       : TYA            : A=FF X=04 Y=FF SP=?? N=1 V=0 D=0 I=1 Z=0 C=0
DE9D : 29 08    : AND #08        : A=08 X=04 Y=FF SP=?? N=0 V=0 D=0 I=1 Z=0 C=0
DE9F : 18       : CLC            : A=08 X=04 Y=FF SP=?? N=0 V=0 D=0 I=1 Z=0 C=0
DEA0 : 6D 4C 02 : ADC 024C       : A=0C X=04 Y=FF SP=?? N=0 V=0 D=0 I=1 Z=0 C=0
DEA3 : E9 00    : SBC #00        : A=0B X=04 Y=FF SP=?? N=0 V=0 D=0 I=1 Z=0 C=1
DEA5 : 8D C0 FE : STA FEC0       : A=0B X=04 Y=FF SP=?? N=0 V=0 D=0 I=1 Z=0 C=1
DEA8 : 60       : RTS            : A=0B X=04 Y=FF SP=?? N=0 V=0 D=0 I=1 Z=0 C=1
It seems to be working... that was a snippet from the OS ISR

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

Re: Minimal Tube 6502decode bus snoop with FTDI USB

Post by hoglet » Sun Jan 28, 2018 6:34 pm

Chris,

I just wanted to let you know that I've not forgotten about this thread. This afternoon I started merging your changes in, starting with the merged accumulator. I've been testing this against the old version, using the full reset log as a test case.

It turns out there are quite a few corner cases that are breaking the emulation, because the wrong "operand" value is now being passed to the emulation (the operand being the effective input into the emulated instruction).

I'll give a couple of examples...

The first is any read-modify-write instruction:

Code: Select all

        #  address R/W description
       --- ------- --- ------------------------------------------
        1    PC     R  fetch opcode, increment PC
        2    PC     R  fetch low byte of address, increment PC
        3    PC     R  fetch high byte of address, increment PC
        4  address  R  read from effective address
        5  address  W  write the value back to effective address,
                       and do the operation on it
        6  address  W  write the new value to effective address
Previously the operand was the most recent value in the read accumulator, which is (4). With a merged accumulator this is now (6) which is incorrect.

This one is easy to fix - we just need a flag in the opcode table to identify RMW operations.

The second example is a bit more painful and is the interrupt (BRK likely also has this problem):

Code: Select all

        #  address R/W description
       --- ------- --- -----------------------------------------------
        1    PC     R  fetch opcode, increment PC
        2    PC     R  read next instruction byte (and throw it away),
                       increment PC
        3  $0100,S  W  push original PCH on stack, decrement S
        4  $0100,S  W  push original PCL on stack, decrement S
        5  $0100,S  W  push P on stack, decrement S
        6   $FFFE   R  fetch PCL
        7   $FFFF   R  fetch PCH
Previously the PC validation code was comparing the current emulated PC value with (3) and (4) from the write accumulator. With a merged accumulator this now seems to be using (6) and (7) which is wrong, because that is the next PC value.

What's particularly painful in this case is the merged accumulator is only a uint32_t, so it only stores four values - i.e. (3) has fallen off the end.

Either the accumulator needs to change to a uint64_t, or it needs to change to a byte array.

Before diving in to this further, I just wanted to check that you hadn't done any more work on this stuff.

Dave

Edit: I just made it a uint64_t and that's seems to have sorted things...

Current code is here:
https://github.com/hoglet67/6502Decoder ... ccumulator

cmorley
Posts: 1019
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford
Contact:

Re: Minimal Tube 6502decode bus snoop with FTDI USB

Post by cmorley » Sun Jan 28, 2018 8:57 pm

Hi Dave,

Good work. No I hadn't looked anything further since my 'seems to work' post. I was waiting for the cheap FT232H boards to arrive on the slow boat from China before doing anything more.

I fixed up a few things with the new accumulator which I saw were obvously wrong - I assume you saw them with a diff. I fixed up the address snoops for JMP etc. but I never figured out why the IRQ match with the rnw looked on cycle 2 as with the PC push you can scan ahead for on cycle 1 it seems... so I left alone what I hadn't determined the function of or reasoning behind.

Input lookahead and history as slices of the stream buffer is probably the best way to change it in the future but if uint64_T works with minimal changes then :D

I think I will look at building libargp under windows too so it can be compiled as a console app for *nix and Win. I will draw a PCB to adapt the cheap chinese boards (when i eventually get them and measure them!) to 40 pin IDC for a more robust connection. I'll make those boards available to any and all + the gerbers.

Chris

Edit: just looking comparing the latest github to my version... how does the byte read work on that? I'd changed the stream read to bytes.

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

Re: Minimal Tube 6502decode bus snoop with FTDI USB

Post by hoglet » Tue Jan 30, 2018 7:51 pm

I've quite done a bit more work on the 6502 decoder today. This is all in aid of improving operation where only the data bus is being captured (i.e. no sync, rnw, rdy or rst signals), which is the theme of Chris's thread.

The latest code is still in a branch but is reasonably stable:
https://github.com/hoglet67/6502Decoder ... ccumulator

I've updated both the decoder_without_sync and decoder_with_sync to use a common bus cycle "accumulator" (this is the work Chris started). So the rnw signal is now optional and the system will try to do the best it can without it.

When rnw is not present, I was seeing some false positives with the heuristic for interrupt cycle detection. So as well as looking for the current PCL and PCH being pushed onto the stack, I also now check against the current flags. This has eliminated all the false positives. If we get further problems, we can also add checking for the data being the same in bus cycle 0 and bus cycle 1, which is true in an interrupt cycle because after the opcode cycle the PC remains unchanged.

I've added a --vecrst= option to allow the reset vector (and optionally the initial opcode) to be supplied.

I've also add --byte option to allow byte mode to be selected. This allows the input file to just contain successive byte-wide samples of the data bus. By selecting this option, you are implicitly saying all of the control signals (rnw, sync, rst, rdy, rst, phi2) are unconnected.

Here are some example commands showing these options being used.

Code: Select all

# Beeb
./decode6502 --byte --vecrst=A9D9CD data_only.bin

# Electron
./decode6502 --byte --vecrst=A9D8D2 data_only.bin

# Master
./decode6502 --byte --vecrst=A9E364 -c data_only.bin
In all cases the verbosity of the output can be increased by adding one or more of:
- -h to include opcode hex values
- -s to include all register state
- -y to include instruction cycle counts

Let me know if you find any problems.

Dave

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

Re: Minimal Tube 6502decode bus snoop with FTDI USB

Post by BigEd » Fri Feb 02, 2018 8:29 am

Rather impressive! How does it do at cold start, when it doesn't know anything about the machine state?

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

Re: Minimal Tube 6502decode bus snoop with FTDI USB

Post by hoglet » Fri Feb 02, 2018 9:56 am

BigEd wrote:Rather impressive! How does it do at cold start, when it doesn't know anything about the machine state?
On balance, pretty well.

It seems to sync up with the instruction stream within a few instructions. You'll occasionally see it loose sync again slightly later when a branch is mispredicted (because the corresponding flag is still unknown). But if you arrange to start capturing well before the event you are interested in it works just fine.

I've also noticed that fx2pipe seems to corrupt the data at the start of a capture, so I've started just dropping the first 8KB, which again is fine if everything is started manually.

Yesterday I did some new synchronous captures on the Master of:
- The Dormann 6502 tests
- The Dormann 65C02 tests
- The Clark full BCD tests

There files are a bit too big to put in git, so I uploaded them as "release files" to github:
https://github.com/hoglet67/6502Decoder ... /test_data

The test script now downloads these locally first, then runs with all possible combinations of signal options:

Code: Select all

    sync
    sync_nornw
    sync_norst
    sync_nordy
    sync_nornw_norst
    sync_nornw_nordy
    sync_norst_nordy
    sync_nornw_norst_nordy
    nosync
    nosync_nornw
    nosync_norst
    nosync_nordy
    nosync_nornw_norst
    nosync_nornw_nordy
    nosync_norst_nordy
    nosync_nornw_norst_nordy
It takes a very long time to run through everything, but all combination give identical results (after a few small tweaks and bug fixes), which is very reassuring.

The only prediction failures in the run are with the electron reset tests, and this is due to bus contention when writing to &8xxx.

Everything is now merged back into master on github now:
https://github.com/hoglet67/6502Decoder/commits/master

Dave

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

Re: Minimal Tube 6502decode bus snoop with FTDI USB

Post by hoglet » Fri Feb 02, 2018 9:58 am

Chris,
cmorley wrote: FT232H or FT2232H boards are available on eBay for £6-7 delivered.
Could you post a link to the kind of board you are using?

cmorley
Posts: 1019
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford
Contact:

Re: Minimal Tube 6502decode bus snoop with FTDI USB

Post by cmorley » Fri Feb 02, 2018 10:00 am

Cold boot works fine. It synchronises on the reset vector pull and the OS sets everything from there. The boot.bin in the logs rar file I uploaded is a cold boot log. It should be very good for helping diagnose long beep problems.

cmorley
Posts: 1019
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford
Contact:

Re: Minimal Tube 6502decode bus snoop with FTDI USB

Post by cmorley » Fri Feb 02, 2018 10:02 am

hoglet wrote:Chris,
cmorley wrote: FT232H or FT2232H boards are available on eBay for £6-7 delivered.
Could you post a link to the kind of board you are using?
I've been using an official FTDI board so far which is £15+VAT IIRC from Mouser. The cheap boards from China haven't arrived yet. I'll post the links once I've checked they have real chips on and not fake FTDI parts.

cmorley
Posts: 1019
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford
Contact:

Re: Minimal Tube 6502decode bus snoop with FTDI USB

Post by cmorley » Fri Feb 02, 2018 10:39 am

One of the cheap boards arrived today. Quality looks fine. The FTDI drivers detected it and installed it so it seems OK. I haven't hooked it up yet.

https://www.ebay.co.uk/itm/FT232H-high- ... 2749.l2649

£6.15 from this seller. The same board is available from multiple sellers. I have two with the same picture on order from Aliexpress too where they were ~$6 each. Searches for FT232H will find them.

I will do a PCB over the weekend to adapt to the Acorn Tube 40 pin IDC connections/pinout. It will be 0.1" headers only so soldering suitable for total beginners.

Coeus
Posts: 1396
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: Minimal Tube 6502decode bus snoop with FTDI USB

Post by Coeus » Fri Feb 02, 2018 1:12 pm

cmorley wrote:One of the cheap boards arrived today. Quality looks fine. The FTDI drivers detected it and installed it so it seems OK. I haven't hooked it up yet.

https://www.ebay.co.uk/itm/FT232H-high- ... 2749.l2649

£6.15 from this seller. The same board is available from multiple sellers. I have two with the same picture on order from Aliexpress too where they were ~$6 each. Searches for FT232H will find them.

I will do a PCB over the weekend to adapt to the Acorn Tube 40 pin IDC connections/pinout. It will be 0.1" headers only so soldering suitable for total beginners.
Great news. I have ordered one of the FT232H boards in anticipation.

cmorley
Posts: 1019
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford
Contact:

Re: Minimal Tube 6502decode bus snoop with FTDI USB

Post by cmorley » Sat Feb 03, 2018 8:55 pm

I hooked up the "CJMCU-232H" purple board to the B this evening and it logs. I'm now using hoglet's latest code from github to decode.

I'm getting a few corrupt bytes but I think this is poor signal integrity because I just shoved some jumper wires into an IDE cable to give this purple board a whirl. A rats nest of jumpers on the tube doesn't work for my co-pro so I'm not surprised.

I've measured the purple board and made a footprint for it in my PCB software. So I'll progress the snoop adapter for the purple board.

I'm tempted to do a board with a PLD on (16V8) which will allow bidirectional coms over USB to a PC at memcpy speeds on the Acorn machine - as well as the bus snoop. I could make this a separate board or make the PLD an optional fit to the snoop adapter (no fit for bus snoop, fit for full bidir coms too). It would allow transfers to PC with USB at as fast as the 6502 can LDA STA... hostfs... humm...

Any cons for designing one PCB with optional fit PLD?

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

Re: Minimal Tube 6502decode bus snoop with FTDI USB

Post by hoglet » Sat Feb 03, 2018 9:23 pm

cmorley wrote: I'm getting a few corrupt bytes but I think this is poor signal integrity because I just shoved some jumper wires into an IDE cable to give this purple board a whirl. A rats nest of jumpers on the tube doesn't work for my co-pro so I'm not surprised.
Could you possibly upload a reasonably long capture, e.g. of the Beeb powering up.

I've been doing the following:
- Power off the Beeb
- Hold BREAK down
- Power on the Beeb
- Start the capture software for a capture of length ~1.25 seconds (2.5M samples)
- Release BREAK quickly

That seems to result in very clean capture files which compress to ~140KB.

Dave

cmorley
Posts: 1019
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford
Contact:

Re: Minimal Tube 6502decode bus snoop with FTDI USB

Post by cmorley » Sun Feb 04, 2018 2:46 pm

I knocked up an adapter on veroboard to get rid of the rats nest of jumpers. It isn't sending wrong bytes, the PC is missing blocks of bytes.

I've been using type comn: > log.bin from a windows command prompt and cat /dev/ttySn > log.bin from cygwin both with the same effect so I think I might have hit the limit of the VCP (virtual comm port) or streaming.

The FT232H is good for 40MBytes/s so I might have to move to the FTDI D2xx driver. I'll write a small program to read in from the USB & try that.

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

Re: Minimal Tube 6502decode bus snoop with FTDI USB

Post by hoglet » Sun Feb 04, 2018 3:45 pm

cmorley wrote:I knocked up an adapter on veroboard to get rid of the rats nest of jumpers. It isn't sending wrong bytes, the PC is missing blocks of bytes.
When capturing from the FX2 with fx2pipe, there seems to be a similar "discontinuity" about 4KB in. The only way to avoid this seems to be to power cycle the board. Rather than do this each time, I've taken to using dd to drop the first 8KB of any capture, and the remainder is always clean and error free:

Code: Select all

fx2pipe -d=1d50:608d -a  2> /dev/null | dd bs=8192 skip=1  > data.bin
Are you seeing multiple missing blocks?

Dave

cmorley
Posts: 1019
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford
Contact:

Re: Minimal Tube 6502decode bus snoop with FTDI USB

Post by cmorley » Sun Feb 04, 2018 4:58 pm

hoglet wrote: When capturing from the FX2 with fx2pipe, there seems to be a similar "discontinuity" about 4KB in. The only way to avoid this seems to be to power cycle the board. Rather than do this each time, I've taken to using dd to drop the first 8KB of any capture, and the remainder is always clean and error free:

Code: Select all

fx2pipe -d=1d50:608d -a  2> /dev/null | dd bs=8192 skip=1  > data.bin
Are you seeing multiple missing blocks?
Dave
What USB chip does the FX2 use? The FTDI has a 4K FIFO send & receive. If yours has a 4K FIFO too & it stops adding when full (rather than evict oldest) then you'll get a discontinuity at the FIFO depth.

Yes the frames are being dropped throughout using VCP & cat or I also tried:

Code: Select all

dd if=/dev/ttyS7 of=./new.bin bs=4K count=512 iflag=fullblock
Sometimes it looks like it drops just one 64 byte USB packet - I put a telltale in the 6502 code to give me a hint about how much is missing.

I dropped the buffer receive latency and that makes a difference. This laptop is quite old and slow by modern standards so either a dedicated read program through VCP or switching to D2xx will probably work.

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

Re: Minimal Tube 6502decode bus snoop with FTDI USB

Post by hoglet » Sun Feb 04, 2018 6:05 pm

cmorley wrote: What USB chip does the FX2 use? The FTDI has a 4K FIFO send & receive. If yours has a 4K FIFO too & it stops adding when full (rather than evict oldest) then you'll get a discontinuity at the FIFO depth.
It uses a Cypress FX2 chip (CY7C68013A), also known as EZ-USB:
http://www.cypress.com/file/138911/download

This has 16KB of on-chip code/data RAM.

I think the current fx2pipe software uses 8KB of this as buffering organised 16x 512B buffers in some kind of a circular queue.

I've never seen lost data beyond the first 8KB of the capture, but then my machine is fast (well, fast by 2008 standards, a Core2 Quad Q9550). It may be different on a slower machine.

The only other anomaly I've seen (just a couple of times) is an additional unexpected bus cycle, probably from noise on the clock.

Dave

cmorley
Posts: 1019
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford
Contact:

Re: Minimal Tube 6502decode bus snoop with FTDI USB

Post by cmorley » Sun Feb 04, 2018 6:42 pm

This laptop is quite old with a Core 2 Duo T9300... pedestrian by modern standards. Tweaking settings reduces the dropped frames so it is the laptop not the FT232H. Hence why I think the D2xx FTDI drivers will fix it even on this slow beast.

I used a counter (actually @ &7c00 so I can see it on the screen and bus cycles) then LDA that in the test loop. If the LDA jumps then it has lost bytes. I don't see any corruption other than the lost bytes.

Edit: I tried "type comn: > log.bin" again from a command prompt and it seems just as good as dd under cygwin. I need a native windows serial->file program on a slow machine...

cmorley
Posts: 1019
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford
Contact:

Re: Minimal Tube 6502decode bus snoop with FTDI USB

Post by cmorley » Mon Feb 05, 2018 2:02 pm

Yeah I hit the VCP (virtual com port) throughput limit on this laptop.

I tried a quick C# bulk read into buffer and it drops packets while flat out on one core.

So I tried a quick d2xx bulk reader in C# and it drops nothing using <5% CPU in debug mode.

cmorley
Posts: 1019
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford
Contact:

Re: Minimal Tube 6502decode bus snoop with FTDI USB

Post by cmorley » Tue Feb 06, 2018 12:50 pm

Photos of the prototype I made up. Not many wires needed as you can see!

I cut the track on the purple board to the LED TX/RX LED (for RS232 mode) which shares the pin with ~WE (FIFO CPU mode). I did this so the NOT gate which drives the clock in the beeb is not sinking the LED current - LED is connected to 3V3.

The inputs on the FT232H have internal (~70K IIRC) pull ups so leaving them NC works. I'll tie them to 5v on the actual PCB.

Top:
Photo1195.jpg
Bottom:
Photo1196.jpg
I'll send the PCB off to be made after Chinese NY.

I have no idea what quantity to order. PM me if interested with qty you'd like (PCB & optional PLD) and I'll keep a tally and update this thread.

Work on the assumption that:
PCB: <£2.50 each
PLD (programmed): £2 (for bidirectional option)

cmorley
Posts: 1019
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford
Contact:

Re: Minimal Tube 6502decode bus snoop with FTDI USB

Post by cmorley » Wed Feb 07, 2018 8:29 am

Quantity guestimate... board (B), pld (P) :
  • sweh (USA) full kit PAID
  • hoglet full kit + purple module PAID
  • RobC full kit + purple module PAID
  • Coeus full kit PAID
  • grannyg full kit PAID
  • marcusjambler full kit PAID


PM me and I'll add you to the list.

If there are several people in one country who want one then it might make more sense for one of them to order small batch of boards. Elecrow will be US$10-15 incl postage for 10 boards (promotional 10 for 5 price but they've had it going nearly a year!). Gerbers and JED will be free.

Or DIY as I have done in my proto... it took 15 mins there are so few connections required.
Last edited by cmorley on Sat Mar 24, 2018 10:39 pm, edited 10 times in total.

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

Re: Minimal Tube 6502decode bus snoop with FTDI USB

Post by hoglet » Wed Feb 07, 2018 9:03 am

I'll certainly take a board + CPLD, thanks.

Dave

RobC
Posts: 2714
Joined: Sat Sep 01, 2007 9:41 pm
Contact:

Re: Minimal Tube 6502decode bus snoop with FTDI USB

Post by RobC » Wed Feb 07, 2018 2:29 pm

I'd like a board and CPLD too please!

Post Reply