Pi-based Co-Pro on the cheap - 100MHz 6502 for £10? (now 274MHz)

for bbc micro/electron hardware, peripherals & programming issues (NOT emulators!)
User avatar
simoni
Posts: 448
Joined: Wed May 25, 2016 6:18 pm
Contact:

Re: Pi-based Co-Pro on the cheap - 100MHz 6502 for £10? (now 274MHz)

Post by simoni » Sun Jan 22, 2017 3:22 pm

I tested with a floppy and it functioned ok (on the master 128)

However... I think I've narrowed down the problem. It's to do with the DMA sector transfers (which I don't believe the patched IDE ADFS uses) - but the original SCSI ADFS does.

ADFS is fine when reading, but when writing it's either running way too fast (most likely) - or too slow. The SCSI DMA shouldn't exceed the maximum allowed DMA rate of the Adaptec ACB-4000. I need to attach a bunch more test equipment to see what's really going on - but it's clear that the Pi CoPro (even when switched to 3MHz mode) is not the same as the real thing during ADFS access to SCSI and the issue only shows on SCSI since DMA isn't used in the IDE patched ADFS.

What confused me was the host reset... I'd forgotten that there were two ways BeebSCSI would trigger the condition - a real host reset - and if something goes amiss during DMA; it was the latter case that occurred.

It would be interesting if someone could test this against a real SCSI adapter (be aware that failures during write DMA can corrupt your hard drive though). I'm not sure how to test the effect on ADFS timing that's being caused by the PiCoPro though?

(just saw your additional post - I'll try one of the previous versions to see if the issue is there)

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

Re: Pi-based Co-Pro on the cheap - 100MHz 6502 for £10? (now 274MHz)

Post by BigEd » Sun Jan 22, 2017 3:28 pm

If you switch to copro 1, that's a 3MHz 6502 near enough.
*FX 151,230,1
and control-break. Or put "copro=1" into a file cmdline.txt on the SD card. (See the wiki for more.)
Last edited by BigEd on Sun Jan 22, 2017 4:37 pm, edited 1 time in total.

User avatar
simoni
Posts: 448
Joined: Wed May 25, 2016 6:18 pm
Contact:

Re: Pi-based Co-Pro on the cheap - 100MHz 6502 for £10? (now 274MHz)

Post by simoni » Sun Jan 22, 2017 4:31 pm

Ok, well I've tried all 3 versions of the copro (with and without the *fx 151,230,1) and they all cause ADFS to fail in the same way.

It's hard to be sure, but my best guess is that the copro is adversely effecting the DMA speed (although why this only seems to break writing and not reading I'm not sure).

I was hoping to use the Pi based co-pro as part of my Domesday emulation efforts - hence the initial testing; but this system has to be SCSI... Domesday VFS doesn't 'do' IDE.

I'll try and think of an easy way to test the variance in the DMA speed - I can also (hopefully) find someone with a real Domesday system to see if the VP415 works with VFS and a Pi copro. Something is amiss though; since it all works with both of the original 65x02 copros.

I'll check back if I find out anything more - I guess the best test/comparison would be to try the pi copro with a physical SCSI drive - but I don't have one :)

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

Re: Pi-based Co-Pro on the cheap - 100MHz 6502 for £10? (now 274MHz)

Post by hoglet » Sun Jan 22, 2017 4:34 pm

Simon,

Can you explain a bit more about how the DMA sector transfer is working? Is the host CPU still involved in reading each byte from the tube FIFO?

Can you point me to the bit of ADFS source where this is happening (for the SAVE direction)? I want to understand what tube transfer type is occurring.

The tube data transfer should be flow controlled. i.e. the Co Processor polls for the FIFO full flag, and so the rate is ultimately driven by how fast the host is able to read the FIFO. A much faster host should not therefore have much effect on the rate. I wonder if this is an edge case, where the first byte of the transfer appears too quickly, or too late?

Dave

User avatar
simoni
Posts: 448
Joined: Wed May 25, 2016 6:18 pm
Contact:

Re: Pi-based Co-Pro on the cheap - 100MHz 6502 for £10? (now 274MHz)

Post by simoni » Sun Jan 22, 2017 4:57 pm

Can you explain a bit more about how the DMA sector transfer is working?
I'm not much of an expert in the inner workings of ADFS, but I did write up about the discovery of this ADFS 'feature' in another post:

http://www.stardot.org.uk/forums/viewto ... 36#p148436

Basically ADFS and the SCSI adaptor use two signals (REQuest and ACKnowledge) when exchanging bytes over the 1 MHz bus. For everything except sector transfer this is asynchronous (the host will always wait for the device to respond). When transferring sectors, the ACB-4000 will buffer 256 bytes from the drive into its on board RAM; ADFS then sends a clocked (synchronous) stream of REQs and expects the device to transfer 256 bytes one after another - although the device sends ACK, ADFS ignores it. This is to speed up the actual transfer of data. It's the same mechanism for reading and writing (hence my confusion over why reading works, but writing doesn't).

The DMA is limited to one quarter of the clock speed of the ACB-4000. The actual transfer rate (when I measured it a while ago) was about 1 byte per 8us. With VFS this is slower to allow for the fact that the VP415 SCSI hardware isn't as fast as the ACB-4000.

How this all works over the tube, I'm not sure... but you would expect it to be on the host side since it's I/O; so I'm also confused as to why the Pi CoPro causes it to fail. It could be that my SCSI implementation is 'on the edge' of the timing - and the increase from the Pi CoPro is just too much for it - but then you would expect it to work in the 4MHz mode, which it doesn't. Best test would be to get someone with a real ACB-4000 to try it (I've made a request on the FB group to see if anyone has both real physical SCSI drives and the Pi CoPro... you never know).

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

Re: Pi-based Co-Pro on the cheap - 100MHz 6502 for £10? (now 274MHz)

Post by hoglet » Sun Jan 22, 2017 5:20 pm

simoni wrote: The DMA is limited to one quarter of the clock speed of the ACB-4000. The actual transfer rate (when I measured it a while ago) was about 1 byte per 8us. With VFS this is slower to allow for the fact that the VP415 SCSI hardware isn't as fast as the ACB-4000.
Was 1 byte per 8us measured with the Tube in use?

Do you have any idea where the DMA transfer code is in the ADFS ROM?

If you search for "LDA &FEE5" there are 4 instances of this, the last two I think are part of the floppy driver.

That leaves:
https://github.com/hoglet67/ADFS/blob/6 ... 0.asm#L313
and
https://github.com/hoglet67/ADFS/blob/6 ... 0.asm#L409

I'm trying to understand which of these is used for the DMA sector transfer, and what tube transfer type is used.

I suspect it's the second one, and that is using a type 6 transfer.

One important thing to note here. There is no use of flow control on the host side, so if the Co Pro doesn't write bytes to the FIFO fast enough, then data will be lost. But because there is no use of flow control, the Co Pro will have very little influence on the timing of the transfer seen by the SCSI adapter. Basically the worst that should happen is the wrong data gets written to the sector. That was the reason I suggested that test a few posts back, because it should demonstrate this underflow if its happening. What I don't understand is how this is causing the host side to hang.

Dave

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

Re: Pi-based Co-Pro on the cheap - 100MHz 6502 for £10? (now 274MHz)

Post by hoglet » Sun Jan 22, 2017 5:35 pm

Another thing to try....

Does *SAVE work with any of the other Co Processors in Pi Tube Direct.

Here's the list:
274MHz 65C102 (*FX 151,230,0)
3MHz 65C102 (*FX 151,230,1)
20MHz 65C102 (*FX 151,230,2)
60MHz Z80 (*FX 151,230,4)
??MHz 80286 (*FX 151,230,8)
??MHz 6809 (*FX 151,230,9)
~9MHz ARM2 (*FX 151,230,12)
??MHz 32016 (*FX 151,230,13)
??MHz ARMnative (*FX 151,230,15)

Dave

User avatar
simoni
Posts: 448
Joined: Wed May 25, 2016 6:18 pm
Contact:

Re: Pi-based Co-Pro on the cheap - 100MHz 6502 for £10? (now 274MHz)

Post by simoni » Sun Jan 22, 2017 6:01 pm

Interesting results...

274MHz 65C102 (*FX 151,230,0) - No
3MHz 65C102 (*FX 151,230,1) - No
20MHz 65C102 (*FX 151,230,2) - No
60MHz Z80 (*FX 151,230,4) - No
??MHz 80286 (*FX 151,230,8) - Couldn't boot
??MHz 6809 (*FX 151,230,9) - YES
~9MHz ARM2 (*FX 151,230,12) - No
??MHz 32016 (*FX 151,230,13) - No
??MHz ARMnative (*FX 151,230,15) - YES

Without BASIC I was a little limited, so I used *SAVE TEST1 2000 +100 in each setting.
What I don't understand is how this is causing the host side to hang.
The hang is due to the DMA failing; there is no error checking and both sides just expect 256 bytes. If something goes wrong then one side or the other will just wait forever (actually that's not quite true - I designed BeebSCSI to recover from this gracefully; it just assumes the host has reset and restarts its state machine). I guess the real question is 'why does the DMA fail?' :)

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

Re: Pi-based Co-Pro on the cheap - 100MHz 6502 for £10? (now 274MHz)

Post by hoglet » Sun Jan 22, 2017 6:11 pm

Interesting results - I'll have a ponder.
simoni wrote: The hang is due to the DMA failing; there is no error checking and both sides just expect 256 bytes. If something goes wrong then one side or the other will just wait forever (actually that's not quite true - I designed BeebSCSI to recover from this gracefully; it just assumes the host has reset and restarts its state machine). I guess the real question is 'why does the DMA fail?' :)
Did you understand the point I was trying to make about the lack of host side tube flow control in ADFS? This means the timing of the data transfer should not depend in any way on the behaviour of the Co Pro.

In what way is the DMA transfer failing? Does this imply underrun?

Can you tell how many bytes have been transferred when it fails?

Dave

User avatar
simoni
Posts: 448
Joined: Wed May 25, 2016 6:18 pm
Contact:

Re: Pi-based Co-Pro on the cheap - 100MHz 6502 for £10? (now 274MHz)

Post by simoni » Sun Jan 22, 2017 6:38 pm

Did you understand the point I was trying to make about the lack of host side tube flow control in ADFS? This means the timing of the data transfer should not depend in any way on the behaviour of the Co Pro.
I got the gist :) But, even given this fact, the original copro works with ADFS and the Pi copro doesn't; which implies logically that the copro does/can have an effect. I don't mean to sound harsh here (I think the pi copro is awesome :) ) but it seems to imply an issue.
In what way is the DMA transfer failing? Does this imply underrun?
The host stops responding before completing the transfer of 256 bytes causing the SCSI state-machine to time out.
Can you tell how many bytes have been transferred when it fails?
Because of the timing sensitive nature of the DMA, there isn't any reporting in detail... but, since I have the source I will modify it (i.e. hack-attack!) and see if I can get the result out. Give me a little while and I will report back.

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

Re: Pi-based Co-Pro on the cheap - 100MHz 6502 for £10? (now 274MHz)

Post by hoglet » Sun Jan 22, 2017 6:57 pm

simoni wrote: I got the gist :) But, even given this fact, the original copro works with ADFS and the Pi copro doesn't; which implies logically that the copro does/can have an effect. I don't mean to sound harsh here (I think the pi copro is awesome :) ) but it seems to imply an issue.
I agree there clearly is an issue, and it's very likely the Co Pro at fault.

What I was trying to say was that if the effect is timing based, then it's probably quite subtle.

Are you planning to keep digging into this? Let me know if there's anything I can do to help....

Am I right in assuming the data read from the tube FIFO shouldn't matter (even if it's incorrect?) - i.e. bad data alone shouldn't cause the DMA to hang?

Dave

User avatar
simoni
Posts: 448
Joined: Wed May 25, 2016 6:18 pm
Contact:

Re: Pi-based Co-Pro on the cheap - 100MHz 6502 for £10? (now 274MHz)

Post by simoni » Sun Jan 22, 2017 7:15 pm

It doesn't seem to be bad data... more missing data...

I did two tests, one with a small file and one with a large file (and I altered BeebSCSI's debug to show the number of transferred bytes in the case of DMA failure)

Code: Select all

Test 1: (*SAVE TEST1 2000 +100)

SCSI State: Selected by host ID 1
SCSI State: Command phase
SCSI State: Information transfer phase: Command
SCSI Commands: CDB byte 0 decode: Command group 0 (6 bytes) opcode 8
SCSI Commands: Received command operand bytes: 8 0 0 0 2 0
SCSI Commands: READ command (0x08) received
SCSI Commands: Target LUN = 0, LBA = 0, Blocks = 2
SCSI State: Information transfer phase: Data in
File system: filesystemOpenLunForRead(): Successful
SCSI Commands: Transferring requested blocks to the host...
0 1
File system: filesystemCloseLunForRead(): Completed
SCSI Commands: Read6 command successful
SCSI State: Status.  Status byte = 0
SCSI State: Information transfer phase: Status
SCSI State: Message In.  Message byte = 0
SCSI State: Information transfer phase: Message in
SCSI State: Bus Free
SCSI State: Information transfer phase: Data out
SCSI State: Selected by host ID 1

SCSI State: Command phase
SCSI State: Information transfer phase: Command
SCSI Commands: CDB byte 0 decode: Command group 0 (6 bytes) opcode 10
SCSI Commands: Received command operand bytes: 10 0 69 8 1 0
SCSI Commands: WRITE command (0x0A) received
SCSI Commands: Target LUN = 0, LBA = 17672, Blocks = 1
SCSI State: Information transfer phase: Data out
File system: filesystemOpenLunForWrite(): Successful
SCSI Commands: Transferring requested blocks from the host...
0
File system: filesystemCloseLunForWrite(): Completed
SCSI Commands: Write6 command successful
SCSI State: Status.  Status byte = 0
SCSI State: Information transfer phase: Status
In test 1 the SCSI device thinks it got 256 bytes from the host, but when it gets to the status transfer phase the host is gone and never responds. There's no way for the SCSI device to know what happened to the host.

Code: Select all

Test 2: (*SAVE TEST2 2000 +4000)

SCSI State: Selected by host ID 1
SCSI State: Command phase
SCSI State: Information transfer phase: Command
SCSI Commands: CDB byte 0 decode: Command group 0 (6 bytes) opcode 8
SCSI Commands: Received command operand bytes: 8 0 0 0 2 0
SCSI Commands: READ command (0x08) received
SCSI Commands: Target LUN = 0, LBA = 0, Blocks = 2
SCSI State: Information transfer phase: Data in
File system: filesystemOpenLunForRead(): Successful
SCSI Commands: Transferring requested blocks to the host...
0 1
File system: filesystemCloseLunForRead(): Completed
SCSI Commands: Read6 command successful
SCSI State: Status.  Status byte = 0
SCSI State: Information transfer phase: Status
SCSI State: Message In.  Message byte = 0
SCSI State: Information transfer phase: Message in
SCSI State: Bus Free
SCSI State: Information transfer phase: Data out

SCSI State: Selected by host ID 1
SCSI State: Command phase
SCSI State: Information transfer phase: Command
SCSI Commands: CDB byte 0 decode: Command group 0 (6 bytes) opcode 10
SCSI Commands: Received command operand bytes: 10 1 12 48 64 0
SCSI Commands: WRITE command (0x0A) received
SCSI Commands: Target LUN = 0, LBA = 68656, Blocks = 64
SCSI State: Information transfer phase: Data out
File system: filesystemOpenLunForWrite(): Successful
SCSI Commands: Transferring requested blocks from the host...
0 SCSI Commands: Write DMA interrupted by host reset at byte #0
File system: filesystemCloseLunForWrite(): Completed
In test 2 the host begins the DMA sector transfer, but fails to send even a single byte. As in the first case, the command transfer is fine, but the data isn't sent.

Does this provide any clues? :)
i.e. bad data alone shouldn't cause the DMA to hang?
No, it will just result in an unreadable file... but (as per the above tests), the problem seems to be a lack of data.
Are you planning to keep digging into this?
Oh yes :) I want to use the Pi CoPro for Domesday emulation... so I'd like to get to the bottom of the issue; I'm happy to test anything you think might give us a clue (but I have to admit mostly ignorance when it comes to the Tube's inner workings!)

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

Re: Pi-based Co-Pro on the cheap - 100MHz 6502 for £10? (now 274MHz)

Post by hoglet » Sun Jan 22, 2017 7:17 pm

I just had another thought.

I'm wondering if for some reason type-6 tube transfers (256-byte, parasite to host) are completely broken.

I think the ADFS Sector DMA to SCSI are the first example we have come across that actually uses them.

I've just checked the ADFS IDE Patch, and I don't think that uses type-6 transfers.

It should be possible to write a test program to initiate such a transfer (actually, I think JGH posted one a while back).

I can try this tomorrow.

Dave

User avatar
simoni
Posts: 448
Joined: Wed May 25, 2016 6:18 pm
Contact:

Re: Pi-based Co-Pro on the cheap - 100MHz 6502 for £10? (now 274MHz)

Post by simoni » Sun Jan 22, 2017 7:42 pm

I'm wondering if for some reason type-6 tube transfers (256-byte, parasite to host) are completely broken
Well, the fact that reading from SCSI discs works perfectly (when the transfer is in the opposite direction) and writing doesn't is the biggest point of 'confusion' for me. The DMA mechanism is the same in both cases (it's always the host that clocks in/out the data and the SCSI has to keep up). So your guess certainly seems to match the observed results.

Just let me know if you want me to test something.

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

Re: Pi-based Co-Pro on the cheap - 100MHz 6502 for £10? (now 274MHz)

Post by hoglet » Sun Jan 22, 2017 8:13 pm

Right, I think I have managed to reproduce the hang.

I'm using a test suite I wrote last year:
tubetests.zip
(1.83 KiB) Downloaded 17 times
This runs through and tests type 0/1/2/3/6/7 tube transfers.

First, I confirmed that it passes with the Matchbox Co Pro.

Next, with PiTubeDirect I get:
- Type 0: Pass
- Type 1: Pass
- Type 2: Fail
- Type 3: Fail
- Type 6: Hangs
- Type 7: ? never gets this far

What seems to be happening is that for some reason the host is hanging in the tube release code (with interrupts disabled as Caps lock doesn't work).

I think this confirms what you are seeing, and gives me something concrete to work with.

All the tube release code does is:

Code: Select all

0415 78          x    SEI               Disable IRQs
0416 A9 05       ©.   LDA #&05          Send &05 to R4 to interupt CoPro
0418 20 6C 06     l.  JSR &066C
041B 20 6A 06     j.  JSR &066A      || Send Tube ID to notify a Tube release
041E 28          (    PLP               Get IRQ state back
041F A9 80       ©.   LDA #&80
0421 85 15       ..   STA &15           Set Tube ID to 'unclaimed'
0423 85 14       ..   STA &14           Set Tube status to 'free'
0425 60          `    RTS

Send Tube ID via R4
-------------------
066A A5 15       ¥.   LDA &15        || Get Tube ID

Send byte in A via R4
---------------------
066C 2C E6 FE    ,æþ  BIT &FEE6         Check R4 status
066F 50 FB       Pû   BVC &066C         Loop until port free
0671 8D E7 FE    .çþ  STA &FEE7         Send byte
0674 60          `    RTS
The only place this can possibly hang is the loop in &66C.

I'll have a think as to what might be going on here...

Dave

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

Re: Pi-based Co-Pro on the cheap - 100MHz 6502 for £10? (now 274MHz)

Post by hoglet » Sun Jan 22, 2017 9:43 pm

hoglet wrote: I'll have a think as to what might be going on here...
I think I've found the bug - the way we were implementing bit 7 of R3_STATUS was incorrect. For anyone who is interested, the gory details are in App Note 004. Specifically, bit of R3_STATUS is defined differently to the other status registers, and should indicate when action required by the parasite for data in either direction.

I've had a go at fixing this, and type 6 transfers now pass my test suite.

Would you like to give this build a try?
PiTubeDirect_20170122_2133_dmb.zip
(2.09 MiB) Downloaded 20 times
The test suite shows there are also problems with the two byte transfers (type 2 and 3), which I need to dig into further. But I think that just affects Econet.

Dave

User avatar
simoni
Posts: 448
Joined: Wed May 25, 2016 6:18 pm
Contact:

Re: Pi-based Co-Pro on the cheap - 100MHz 6502 for £10? (now 274MHz)

Post by simoni » Sun Jan 22, 2017 9:51 pm

Would you like to give this build a try?
You are a superhero :) Loading and saving now function (I tried a few BASIC programs and some *SAVEs up to 16K) - all worked flawlessly.

If you'd like me to capture some logs or do anything more detailed, just let me know. Now I can start testing what a 270MHz Domesday system with super-high speed SCSI is like... Something tells me that it's going to be fun ;)

Thanks for such a quick response and (although I've said it in the past) thanks for the Pi CoPro!

/Simon

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

Re: Pi-based Co-Pro on the cheap - 100MHz 6502 for £10? (now 274MHz)

Post by hoglet » Sun Jan 22, 2017 9:56 pm

Excellent, I'm glad that fixed it.

I don't need any traces, but thanks for the offer.

Type 2 and 3 transfers still need a bit more work. Luckily they are rarely used.

Dave

User avatar
simoni
Posts: 448
Joined: Wed May 25, 2016 6:18 pm
Contact:

Re: Pi-based Co-Pro on the cheap - 100MHz 6502 for £10? (now 274MHz)

Post by simoni » Sun Jan 22, 2017 10:05 pm

Luckily they are rarely used.
I'm sure I'll find a use for them at some point... I'm one of *those* users :roll:

Seriously though, I'm hoping to get BeebSCSI out in the wild very soon (my only two precious production boards are on their way to ABug for next weekend for their first public demo) and there are a lot of Pi CoPro users, so it's really good to track down the issue and see them working together.

User avatar
simoni
Posts: 448
Joined: Wed May 25, 2016 6:18 pm
Contact:

Re: Pi-based Co-Pro on the cheap - 100MHz 6502 for £10? (now 274MHz)

Post by simoni » Mon Jan 23, 2017 3:52 pm

Just to 'finish up' on this. I just connected the patched Pi CoPro to my Master (which is fitted with 2 BeebSCSI devices, one external and one internal (emulating VFS support))... and booted Domesday. I can confirm that the Pi CoPro now supports Domesday. All of the SCSI layer worked including the video control.

I've only done some light testing, but there are noticeable improvements in the text output speed (Domesday uses a custom font with kerning) and the searches are pretty zippy too :)

The only odd thing (and I guess it's not super-important right now) was the RB2 mouse support. The mouse movement was very slow compared to a real copro. Interestingly, when I rebooted and turned on the mouse (without booting Domesday) using *MOUSE 1 *POINTER 1 - it was fine.

Still a happy result... Again, thanks for all the work on this!

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

Re: Pi-based Co-Pro on the cheap - 100MHz 6502 for £10? (now 274MHz)

Post by hoglet » Mon Jan 23, 2017 4:05 pm

simoni wrote: Just to 'finish up' on this. I just connected the patched Pi CoPro to my Master (which is fitted with 2 BeebSCSI devices, one external and one internal (emulating VFS support))... and booted Domesday. I can confirm that the Pi CoPro now supports Domesday. All of the SCSI layer worked including the video control.
That's excellent news. Well done!
simoni wrote: The only odd thing (and I guess it's not super-important right now) was the RB2 mouse support. The mouse movement was very slow compared to a real copro. Interestingly, when I rebooted and turned on the mouse (without booting Domesday) using *MOUSE 1 *POINTER 1 - it was fine.
If you switch to the 3MHz Co Pro (*FX 151,230,1 followed by Ctrl-Break) is it still slow?

Dave

User avatar
simoni
Posts: 448
Joined: Wed May 25, 2016 6:18 pm
Contact:

Re: Pi-based Co-Pro on the cheap - 100MHz 6502 for £10? (now 274MHz)

Post by simoni » Mon Jan 23, 2017 4:10 pm

If you switch to the 3MHz Co Pro (*FX 151,230,1 followed by Ctrl-Break) is it still slow?
No, running it in the 3MHz mode made it move normally again (Just tested it with the National disc).

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

Re: Pi-based Co-Pro on the cheap - 100MHz 6502 for £10? (now 274MHz)

Post by hoglet » Mon Jan 23, 2017 4:20 pm

simoni wrote:
If you switch to the 3MHz Co Pro (*FX 151,230,1 followed by Ctrl-Break) is it still slow?
No, running it in the 3MHz mode made it move normally again (Just tested it with the National disc).
Maybe measuring the mouse movement somehow involves a fixed loop on the Co Pro side, and with the faster Co Pro that loop is executing much more quickly, which might look like a very slow moving mouse.

But I would have expected all the mouse stuff to have been handler on the host. That's the way the mouse on the Master 512 works.

Dave

User avatar
simoni
Posts: 448
Joined: Wed May 25, 2016 6:18 pm
Contact:

Re: Pi-based Co-Pro on the cheap - 100MHz 6502 for £10? (now 274MHz)

Post by simoni » Mon Jan 23, 2017 4:32 pm

It is a little odd. The mouse support is built into the VFS ROM so you'd expect it to be the same with or without Domesday running - which it wasn't. It's possible that Domesday provides it's own mouse support, but that seems unlikely (otherwise why bother putting it in VFS).

Just tested it with an AMX mouse (since Domesday supports both types) and, unsurprisingly, it's the same (since both mice work in the same manner, but with different pin outs). I guess it could be the 6522 timing is effected somehow; but that wouldn't explain why it works before Domesday is booted.

Slow pointer movement is usually caused by the host missing quadrature pulses. The Master 512 is an AMX mouse (if I remember right), so the result should be the same. It's an odd thing, but I can't think of anyway to give you some meaningful test output - still, since it works in 3MHz mode, it's not as critical as SCSI support :)

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

Re: Pi-based Co-Pro on the cheap - 100MHz 6502 for £10? (now 274MHz)

Post by jgharston » Mon Jan 23, 2017 4:53 pm

The mouse is purely I/O driven, the two User port interupt lines trigger an IRQ, two data lines for the direction, all done in the background on the I/O processor, it's not polled in any way. Foreground applications request the mouse position by calling ADVAL7/8 which mearly read the coordinate variables that the background process updates.

Code: Select all

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

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

Re: Pi-based Co-Pro on the cheap - 100MHz 6502 for £10? (now 274MHz)

Post by hoglet » Mon Jan 23, 2017 5:00 pm

jgharston wrote:The mouse is purely I/O driven, the two User port interupt lines trigger an IRQ, two data lines for the direction, all done in the background on the I/O processor, it's not polled in any way. Foreground applications request the mouse position by calling ADVAL7/8 which mearly read the coordinate variables that the background process updates.
Jonathan, Can you think of an explanation for the behaviour that Simon is observing, i.e. that the mouse moves slower with the faster 6502 Co Pro?

Simon, there is a ~20MHz 6502 Co Pro (*FX 151,230,2), it would be interesting to whether that exhibits a mouse slow down.

Dave

User avatar
simoni
Posts: 448
Joined: Wed May 25, 2016 6:18 pm
Contact:

Re: Pi-based Co-Pro on the cheap - 100MHz 6502 for £10? (now 274MHz)

Post by simoni » Mon Jan 23, 2017 5:03 pm

Page 39-40 of the AIV manual has some interesting text about *POINTER 3 mode allowing users to "write their own device drivers" - not sure if it's a clue, but here's a link to the manual:

http://www.domesday86.com/wp-content/up ... -Guide.pdf

User avatar
simoni
Posts: 448
Joined: Wed May 25, 2016 6:18 pm
Contact:

Re: Pi-based Co-Pro on the cheap - 100MHz 6502 for £10? (now 274MHz)

Post by simoni » Mon Jan 23, 2017 5:07 pm

Simon, there is a ~20MHz 6502 Co Pro (*FX 151,230,2), it would be interesting to whether that exhibits a mouse slow down.
It's 'better' in this mode (in that the mouse movement up and down works, which it barely does in 274MHz mode) - but it still slower than in 3MHz mode.

User avatar
fordp
Posts: 1000
Joined: Sun Feb 12, 2012 9:08 pm
Location: Kent, England
Contact:

Re: Pi-based Co-Pro on the cheap - 100MHz 6502 for £10? (now 274MHz)

Post by fordp » Mon Jan 23, 2017 6:42 pm

Pure guess, but maybe the Beeb is much busier with the faster CoPro so missing mouse movements.
FordP (Simon Ellwood)
Time is an illusion. Lunchtime, doubly so!

User avatar
BeebMaster
Posts: 2679
Joined: Sun Aug 02, 2009 4:59 pm
Location: Lost in the BeebVault!
Contact:

Re: Pi-based Co-Pro on the cheap - 100MHz 6502 for £10? (now 274MHz)

Post by BeebMaster » Mon Jan 23, 2017 10:50 pm

I can't offer an explanation, but I can confirm that I noticed this behaviour when using real Domesday hardware with a modern, fast co-processor attached to it. I think it was at Bolton but I can't remember which occasion as I can't find any photos of a Master AIV with a bit of modern board hanging out of the tube bus. I do remember the search being very fast (as has been said) and the trackerball pointer going very slowly, as has also been said.

So it isn't a one-off freak activity, if that helps.

I'm not sure the setting of *POINTER would do much to affect the movement speed:

*POINTER 0 switches the display of the pointer off but still updates the X,Y co-ordinates of the current trackerball position
*POINTER 1 switches the display on and allows tracking of the co-ordinates
*POINTER 2 switches the display off and stops the co-ordinates being updated
*POINTER 3 switches the display on but doesn't update the co-ordinates (so that the pointer can be moved "manually" with *TSET x,y if some other input device is being used)

Demonstration of sorts here:

http://www.beebmaster.co.uk/Domesday/UseTBall.html
Image

Post Reply