Matchbox sized 6502 / Z80 / 6809 Co Pro

[BigEd]

A scripted build would be great. Also, I suspect compressed bitstreams will be a lot smaller and therefore faster to load.

[hoglet]

One thing that's not obvious so far is how to combine the various .bit files into a .mcs file. In particular, presumably the order and address for the .bit files in the .mcs is important - is there a note for which one goes where?

If you are building everything from the sources in github, the order and addresses are:

Code: Select all

ICAP_reboot.bit   at address 0x000000
LX9CoPro6502.bit  at address 0x054000
LX9CoProZ80.bit   at address 0x0A8000
LX9CoPro6809.bit  at address 0x0FC000
LX9CoPro80186.bit at address 0x150000
LX9Co_BIST.bit    at address 0x1A4000

I've spaced the bitstreams out slightly, so the small variations in size don't mean you have to keep editing the multiboot loader (ICAP_reboot.v).

Dave

[flynnjs]

Today we found a few bugs on the copro firmware which are tube related.

Firstly, when R3 is being used in 2 byte mode from host to parasite the parasite receives two copies of the first byte and none of the second. This was found because NFS uses 2 byte mode and other file systems generally don't. We had a Econet running in Halifax.

Secondly, R3 transfers from parasite back to host start off ok but occasionally write $ee to remainder of a file during saving. This was observed with both RAMfs and ADFS. Until we track this down I would advise not to save to disk if you're worried about corruption.

Hardware wise we found that model Bs don't like ribbon cable but seem reliable directly connected under the beeb whereas Masters are generally ok with a longish ribbon.

[hoglet]

Sound's like you guys have been having fun

Firstly, when R3 is being used in 2 byte mode from host to parasite the parasite receives two copies of the first byte and none of the second. This was found because NFS uses 2 byte mode and other file systems generally don't. We had a Econet running in Halifax.

Bugger, I didn't think anything was using 2 byte mode.

This is a bug that I am aware of.

See this commit: Temporary fix to HP3 - WILL BREAK TWO BYTE MODE
https://github.com/hoglet67/CoPro6502/c ... bbed483026

I need to try to remember why this was necessary.

Secondly, R3 transfers from parasite back to host start off ok but occasionally write $ee to remainder of a file during saving. This was observed with both RAMfs and ADFS. Until we track this down I would advise not to save to disk if you're worried about corruption.

Can you say a bit more about this? How would I try to replicate?

Hardware wise we found that model Bs don't like ribbon cable but seem reliable directly connected under the beeb whereas Masters are generally ok with a longish ribbon.

This is consistent with my experience as well.

Today I've managed to confirm the weirdness I was seeing with the 80186 V482 BASIC is interrupt related. I wrote a small program that flashed a memory mapped LED when the bug happens, and as soon as I disable interrupts the bug stops happening.

I'm pretty sure this means due to some subtle Zet bug, the interrupt handler is corrupting some register state.

Dave

[flynnjs]

Easily replicated. Load or write a short bit of basic. Save to disk. Load back from disk and see if you get bad program error. Or just *dump it and see if there are any &ee bytes at the end.

[firthmj]

One thing that's not obvious so far is how to combine the various .bit files into a .mcs file. In particular, presumably the order and address for the .bit files in the .mcs is important - is there a note for which one goes where?

If you are building everything from the sources in github, the order and addresses are:

Code: Select all

ICAP_reboot.bit   at address 0x000000
LX9CoPro6502.bit  at address 0x054000
LX9CoProZ80.bit   at address 0x0A8000
LX9CoPro6809.bit  at address 0x0FC000
LX9CoPro80186.bit at address 0x150000
LX9Co_BIST.bit    at address 0x1A4000

I've spaced the bitstreams out slightly, so the small variations in size don't mean you have to keep editing the multiboot loader (ICAP_reboot.v).

Dave

Thanks for this, I'll try and write a script to build all the designs and one to create an MCS based on this addressing.

Out of curiosity, is there a reason not to space it even further to become multiples of 64k:

Code: Select all

ICAP_reboot.bit   at address 0x000000
LX9CoPro6502.bit  at address 0x060000
LX9CoProZ80.bit   at address 0x0C0000
LX9CoPro6809.bit  at address 0x120000
LX9CoPro80186.bit at address 0x180000
LX9Co_BIST.bit    at address 0x1E0000

From the datasheet, I think the flash chip has a 64k sector size, so in theory with this addressing arrangement it would be possible to replace one design in the flash without corrupting any other one.
Of course, persuading the Xilinx tools to do this might be more tricky!

[firthmj]

Here's some quick and dirty scripts which (for me) make the build process easier

build_scripts.zip

(1015 Bytes) Downloaded 24 times

They are:

• ise_build_all.tcl - Open each ISE project in turn, and run "Generate Programming File"
  ise_clean_all.tcl - Open each ISE project in turn, and run the clean process
  gen_mcs - Script to call "promgen" to build an MCS file from all of the generated BIT files

The two ".tcl" files are run by doing "xtclsh script"
The "gen_mcs" script is currently a Bash script (I'm working on Linux), but the only important bit is the last line, which is the promgen command to build the MCS. If you delete all but the last line and rename it to ".bat", you'll probably have a batch file that will run on Windows

Regards

Michael

[richardtoohey]

[OFF-TOPIC]Hey, someone else who uses Tcl! Well, I don't use it that much any more, but every now and then ...

[jgharston]

At Halifax we were having problems remembering the link settings to select different processors. Would it be possible for the link settings to tbe the same as the ROM cpu type numbers, as I know those off the to of my head!

So, that would be:
0 - test
2 - 6502
3 - 6809
7 - PDP11
8 - Z80
9 - 32016
11 - 80x86
13 - ARM

(see Wiki Page - damn, I really need to get the Wiki back online)

[berendvosmer]

I've had some fun designing a Papilio One CoPro Wing with 128k RAM (See my previous posts).

Checking the pcb prices and components on the Farnell website, they should cost around 6 EUR (30 EUR divided by 5) for the board and about 14 EUR excl. VAT for the components per board, provided I reach the minimum order quantity with Farnell.

At this price, and if you add the price for the Papilio itself, I'm not sure it's as good value for money as the excellent board by Flynnjs (for which many kudo's).

Anyway, do you think it would make sense to start a thread for it in the "for sale / freebies" section to see if we can reach 5?

(apologies if this post should have been made in that section already)

[jgharston]

And just when I thought we were close to done

Code: Select all

Invalid opcode from BBCBASIC
Flags ----------------
  CS:IP    DS   ES    SS:SP    AX   BX   CX   DX   BP   SI   DI
4E5C:1A40 1B7B 1225 1B7B:02F2 1A02 1A07 0000 0002 0000 0082 0101

If the CS value is the executing BASIC code, then that's this subroutine:

Code: Select all

1000:1a2b 9c                   pushf  
1000:1a2c 50                   push   ax
1000:1a2d 53                   push   bx
1000:1a2e 55                   push   bp
1000:1a2f 8bee                 mov    bp, si
1000:1a31 8bf2                 mov    si, dx
1000:1a33 e82400               call   loc_00001a5a
1000:1a36 e89a14               call   loc_00002ed3
1000:1a39 8bd6                 mov    dx, si
1000:1a3b 8bf5                 mov    si, bp
1000:1a3d 5d                   pop    bp
1000:1a3e 5b                   pop    bx
1000:1a3f 58                   pop    ax
1000:1a40 9d                   popf   
1000:1a41 c3                   ret    

But the code at 1A3F is POP AX which is a normal 8086 opcode. It looks like the CodeSector register has been trashed and it's jumping off into random memory. Try doing dumping the memory around the error with, in this example, *D 4E5C:1A20+40 to see what's in the memory it's trying to execute. (Replace the address in the *D command with the actual value in the error report minus 20.)

Edit: updated disassembly here.

[hoglet]

Anyway, do you think it would make sense to start a thread for it in the "for sale / freebies" section to see if we can reach 5?

(apologies if this post should have been made in that section already)

I would definitively start another thread, as requests will easily get lost here. You will also then be able to edit the first post to maintain the current status, etc.

I'm still interested in one.

Dave

[roland]

I've had some fun designing a Papilio One CoPro Wing with 128k RAM (See my previous posts).

Why not 512k RAM? Those cost just a few euro's more and in your diagram there are still two pins available for extra address lines?

Checking the pcb prices and components on the Farnell website, they should cost around 6 EUR (30 EUR divided by 5) for the board and about 14 EUR excl. VAT for the components per board, provided I reach the minimum order quantity with Farnell.

It you don't get to the minimum order of €50.00 ex VAT, I can help you. I have a business account and I have no minimum order limit I usually try to place orders with a minimum of €20,00 just to be reasonable with them.

[hoglet]

- Is there a schematic anyway of how to wire a quadrature mouse to the user port so it's compatible? I tried my old AMX Mouse compatible Atari trackball, and it's clearly not Master 512 compatible.

That surprises me, I though it used the same wiring as the BBC Mouse - it could be that it uses the Master Compact wiring (see).

Checking the 6502.SYS code shows that it's not even the Compact wiring. It's both the AMX mouse *and* the Master512 mouse:
b7,b6,b5 = buttons Right, Middle, Left
b4,b3 = 11 - AMX mouse
b4,b3 <> 11 - Acorn mouse/trackerball
b4 = Y direction, Acorn mouse/trackerball
b3 = X direction, Acorn mouse/trackerball
b2 = Y direction, AMX mouse
b0 = X direction, AMX mouse
CB1 = X movement
CB2 = Y movement

So, a standard AMX-style mouse should work as long as b3 and b4 float or are held high.

I've spent a couple of hours his afternoon trying to get the mouse working.

My "mouse" is actually an Atari Trackball (CX80) that has been wired into the user port in a way should that be AMX compatible (i.e. using the above connections).

Initially I was convinced there must be a problem with the hardware, so I had a go at tracing the circuit so I could do some debugging. It turned out the only problem was the "trackball/joystick" switch was set to joystick.

I connected it back up to the Master, and checked the user port VIA (addresses FE60 and FE6D) with the following program:

Code: Select all

10 REPEAT
20 PRINT ~?&FE6D,~?&FE60
30 UNTIL FALSE

And everything seemed to response as expected.

So I installed AMX Super Rom 3.61, and confirmed that the pointer seemed to be working. This was a bit of a faff, as you seem to have to repeatedly call *SHOWPOINTER. Is there a simpler way to test this?

Anyway, I'm pretty convinced the trackball is working as an AMX Compatible Mouse. However, with the 80x86 Co Pro and Gem it still doesn't work properly. As you move the mouse, there are tiny movements of the pointer, up then down, or right then left, but essentially staying in the same place, or moving very slowly towards the top right of the screen.

It's as if the X and Y movement signals are also being used as the X and Y direction.

If you do manage to get the mouse over something, then the left button works and I can cause a menu to come up.

I'm very confused as to what is going in. It's possible this is a subtle Zet bug, but it's very weird.

JHG, what's the nature of the mouse communication between the host and the 80x86? Is it the raw mouse movement signals, or does the host maintain the pointer X,Y and pass this over?

Dave

[danielj]

I've had the lx9 copro running gem with my hacked mouse and there was no issue at all. Worked perfectly.

D.

[hoglet]

I've had the lx9 copro running gem with my hacked mouse and there was no issue at all. Worked perfectly.

Very interesting. So I wonder what the difference is....

Are you using a Master or Model B?
What ROMs are present in the beeb?
What version of the Co Pro bitfile?
What version of the Client ROM?
Is this with the hard disk image you sent me the other day?

I'd love to get to the bottom of this

By the way, have you tried either of the BBC Basics? I'd like to see if the results I'm seeing are consistent.
- JHG's BBCBasic crashes on startup with an illegal instruction.
- Original BBCBasic(x86) V482 mostly works, but has some weirdness. For example:

Code: Select all

10 REM
20 GOTO 10
30 PRINT "WEIRD"
40 GOTO 10

ends up printing WEIRD occasionally.

Dave

[danielj]

That was with my Master, and the version of the bitfile that Jason popped onto everyone's copro yesterday.

I tried "BBCBASIC" which bombed straight away, the version on the HDD IMAGE I gave you. This is the version here:
http://www.cowsarenotpurple.co.uk/bbcco ... tware.html

I'll try and record the error on bombing if I get a moment to hook the master back up, but it may not be this evening unfortunately.

(also, I noted that it's reporting 768k on boot - I've got a 1meg expansion on my real 80186 copro and it reports 896k?)

d.

[hoglet]

That was with my Master, and the version of the bitfile that Jason popped onto everyone's copro yesterday.

Hmm, that sounds like the same version I am running then.

I tried "BBCBASIC" which bombed straight away, the version on the HDD IMAGE I gave you. This is the version here:
http://www.cowsarenotpurple.co.uk/bbcco ... tware.html

At least this is consistent.

I'll try and record the error on bombing if I get a moment to hook the master back up, but it may not be this evening unfortunately.

On mine, it has somehow ended up jumping into the middle of no where, and hitting an &FF which is the illegal opcode.

(also, I noted that it's reporting 768k on boot - I've got a 1meg expansion on my real 80186 copro and it reports 896k?)

This is because the RAM currently stops at 0xBFFFF. This is easily fixable, and I think if I made it stop at EFFFF then it would find 896KB.

Dave

[jgharston]

Mouse....

You can test a mouse wired up for AMX User Port or Master Compact Mouse Port with the *MOUSE command and mouse test code here. If a mouse is correctly wired up and working then the following test code will work:

Code: Select all

REPEAT
PRINT "X=";ADVAL(7)
PRINT "Y=";ADVAL(8)
PRINT "Buttons: Left=";INKEY-10;" Middle=";INKEY-11;" Right=";INKEY-12
VDU 11,11,11
UNTIL FALSE

Common problems are:
* the buttons the wrong way around
* X and Y the wrong way around - that is the X and Y signals swapped
* movement goes in the wrong diretion - that is ?axis and ?direction swapped

JHG, what's the nature of the mouse communication between the host and the 80x86? Is it the raw mouse movement signals, or does the host maintain the pointer X,Y and pass this over?

The host maintains the mouse state catching the mouse movement interupts (CB1 and CB2). The client asks the host for the current mouse state with one of the OSWORD &FA sub-calls. From the client there's an XIOS call to ask for the current mouse state.

[danielj]

So just double checked. GEM/Mouse work fine. BBCBASIC bomb is this:

d.

[hoglet]

Daniel: That's exactly the same crash that I get.

JHG: Thanks for info, it's finally helped me get to the bottom of this.

I managed to disable the 80x86 Co Pro and leave the 6502.SYS mouse handling code in memory. I patched the interrupt vector to point to this code, and was able to look at the host memory locations that are meant to store the mouse X and Y. These were behaving incorrectly, indicating the issue was on the host side.

So I started looking at the mouse handling code in 6502.SYS, and it suddenly dawned on me that it was expecting the direction signal to keep flipping as well as the movement signal. In fact, just as you might expect with a true quadrature mouse.

The way my Atari Trackball is wired, the direction bits literally indicated the direction i.e. 0 is moving down, 1 is moving up.

Anyway, schematic in hand, I've now been able to rewire this to behave as a proper quadrature mouse.

So finally I can use the mouse in Gem.

I did a bit more testing, and both Paint and Writer seem to work.

So the only known issues at the moment are with BBC Basic.

The other thing I have done is to tweak the memory decoding, so that it sees RAM right up to EFFFF. Now on startup it find 896KB. I've just pushed this change to github.

Dave

[firthmj]

That was with my Master, and the version of the bitfile that Jason popped onto everyone's copro yesterday.

I tried "BBCBASIC" which bombed straight away, the version on the HDD IMAGE I gave you. This is the version here:
http://www.cowsarenotpurple.co.uk/bbcco ... tware.html

I'll try and record the error on bombing if I get a moment to hook the master back up, but it may not be this evening unfortunately.

(also, I noted that it's reporting 768k on boot - I've got a 1meg expansion on my real 80186 copro and it reports 896k?)

d.

Hi,

Would there be any chance you could make the HDD image more generally available?
At the moment, if I wanted to play with the 80186 emulation on the Co-Pro, I'd need to dig out a floppy drive and some disks, which would take a while!

Thanks

Michael

[danielj]

Hi Michael,
It's a bit on the large side to post on the board, if you PM me your email address I'll fling it your way. It's also fine for testing, but it's not a vanilla install so it's possibly not ideal for everyone (I can't remember how I've messed around with it) and I don't want to get stuck supporting it at the moment.

You might be able to restore the image from the 4.03 version of Beebem to a CF card: http://www.mkw.me.uk/beebem/index.html using cfrestore? - AFAIK that's a "fresh out of the box" installation. I haven't tried it myself though.

In the meantime when I get a moment I'll try and put together a clean installation and pop it somewhere for people to hoover down.

d.

[leenew]

Hi there,

There's one thing that has me puzzled...
At the Halifax meet-up the new co-pro was tested on various beebs and masters.
In general, when connected to a beeb, it does not like being on the end of a cable, even if that cable is very short.
The Master does not seem to mind.
When connected directly to the socket on a beeb, the results are more successful.

Now, the explanation that is being given, is that the way the beeb is designed means that lots of things are hanging off the data bus, and the co-pro+cable combo just tips it over the edge.
The design of the master's bus is more sensible, and this won't happen.

I get the explanation.

What I don't get, is that a real 6502 co-pro cheese wedge obviously had a cable to connect to the tube, and this was longer than the one being used with the new co-pro. But to the best of my knowledge, it suffered no such problems.
I have had a few co-pro cheese wedges, and although I cannot claim to have tested them to within an inch of their lives, I definitely have tested them by playing Tube Elite on my beeb (with datacentre fitted) and never had a problem.
The only difference I can see (from my layman point of view) is the power supply.
Would it make a difference if the new co-pro was powered? or am I barking up the wrong tree?

**keep further explanations in baby-words please **

Lee.

[danielj]

Torch Z80 runs off Tube without external power. Although with disk pack it would generally have an uprated PSU (you could buy it without this however).

Matchbox CoPro uses so little juice I doubt the beeb even notices.

(I admit to going to 4 syllables there).

d.

[leenew]

Well, if you speak fast, I reckon "generally" is only 3 syllables

Lee.

[danielj]

You are right though, it is a bit odd. How long is the cable on the external copros in total do you think?

d.

[Mike3071]

Hi, on my Master 128 I had to shorten the cable to 2" to get reliable operation with my Matchbox Co Pro.

Mike

[hoglet]

Mike,

Hi, on my Master 128 I had to shorten the cable to 2" to get reliable operation with my Matchbox Co Pro.

Does your Co Pro have the extra decoupling capacitors added by Jason?

Do you have anything attached to the 1MHz bus? On the Master this shares the same databus as the Tube, where as on the Model B it doesn't.

Dave

[Mike3071]

Hi, yes it does have the extra decoupling capacitors added by Jason and there is nothing attached to the 1MHz bus.
I originally used a cable the same length as my Acorn 2nd processor but it was
unstable so I shortened it.

Mike