Matchbox sized 6502 / Z80 / 6809 Co Pro

[Fwapp]

Hi Gents - I took delivery of my LX9 co-pro board this morning and have installed to test it out.

I have an issue in that if I shift-break to call up my MMC card (using MMFS 1.27) it comes back with..

>*TV255
>*MENU

Tube on!

Entering *menu gives the same response.

When the bbc starts, I only get the first sound you normally here (boop of the boop-beep, yes I know, really technical!) but it shows

Acorn TUBE 65C102 Co-Processor

Acorn MMFS (my change)

Basic

Is there a command I need to enter to get things underway? I managed to sort my MMC card, but am wondering (as a learner Beeb driver) if I'm missing something that would be obvious to you old hands?

[Lardo Boffin]

Hi Gents - I took delivery of my LX9 co-pro board this morning and have installed to test it out.

I have an issue in that if I shift-break to call up my MMC card (using MMFS 1.27) it comes back with..

>*TV255
>*MENU

Tube on!

Entering *menu gives the same response.

When the bbc starts, I only get the first sound you normally here (boop of the boop-beep, yes I know, really technical!) but it shows

Acorn TUBE 65C102 Co-Processor

Acorn MMFS (my change)

Basic

Is there a command I need to enter to get things underway? I managed to sort my MMC card, but am wondering (as a learner Beeb driver) if I'm missing something that would be obvious to you old hands?

I had a TurboMMC sd card reader installed and that had similar problems with the coproc switched on. I suspect the menu program knows it does non-tube safe stuff and therefore does not run.

If you do *FX151,230,14 (I think - the latest version may have a different null co proc) and then press break (this switches off the coproc) this should allow your MMC card reader to work from the menu.

If you have any tube based games (Elite) then you will need to leave the coproc on and navigate directly to it without using the menu.

Most games won't run with the coproc switched on.

Lardo

[Fwapp]

Thanks for the reply

Just gave that quick go and it seem to engage Z80 co-pro mode, so I might need a different *FX call.

[Lardo Boffin]

Thanks for the reply

Just gave that quick go and it seem to engage Z80 co-pro mode, so I might need a different *FX call.

You're welcome. And welcome to the world of Beeb!

I suspect you may have to go from 0 to 14 to see which one doesn't show a co-proc after pressing break...

Enjoy!

[hoglet]

Thanks for the reply

Just gave that quick go and it seem to engage Z80 co-pro mode, so I might need a different *FX call.

You I think must have the LX9CoProCombined_20151215_1004_dmb firmware.

DIP switch / *FX settings as described here:
https://github.com/hoglet67/CoPro6502/w ... h-settings

To disable the Co Pro, try *FX 151,230,6

Dave

[DutchAcorn]

As software compatibility with the 6502 copro is limited, it is probably more practical to change the dip switch settings on the copro board to 0110: i.e. change the middle two switches (setting no 6). This will ensure that the copro is off by default and you can leave it plugged into the Tube port.

If you need your 6502 copro simply type *FX 151,230,0 and press ctrl-break.

[Fwapp]

Gents, thank you for your help - I now know a lot more!

Following a read of the co-pro settings and the DUTILS guide, Elite co-processor edition is up and running!

[Lardo Boffin]

Gents, thank you for your help - I now know a lot more!

Following a read of the co-pro settings and the DUTILS guide, Elite co-processor edition is up and running!

Excellent news! See you in the 'Quest to become Elite!' thread!

[hoglet]

Where's the best place to ask / look for questions regarding the sources. For example I'm looking for the source code for the bootrom.dat (PIC?) code, trying to work out how the initial boot works

By initial boot, do you mean the Xilinx multi-boot loader? (there in no PIC, it's all done in hardware)

The source code for this is here:
https://github.com/hoglet67/CoPro6502/b ... P_reboot.v
https://github.com/hoglet67/CoPro6502/b ... CAP_core.v
https://github.com/hoglet67/CoPro6502/b ... P_config.v

There is a general description of how Xilinx supports multi boot here:
http://www.xilinx.com/support/documenta ... f#page=133

It's pretty hairy though!

The ability to dynamically reconfigure needs to be embedded in every one of the Co Processor designs, so the *FX 151,230,N will work.

Dave

[dominicbeesley]

Thanks Dave,

'll have a read through that. It was the bootrom for the PIC in the zet core that I was looking at...I guess that must have come with the core.

I am now trying to work out how the *FX 151,230,X works...need to brush up on my Verilog! Should give me something to do on my holidays next week...

Thanks

D

[hoglet]

I am now trying to work out how the *FX 151,230,X works...need to brush up on my Verilog! Should give me something to do on my holidays next week...

This component is attached to the tube interface in each Co Pro design, and is responsible to initiating the dynamic reconfiguration:
https://github.com/hoglet67/CoPro6502/b ... P_config.v

[flynnjs]

I am now trying to work out how the *FX 151,230,X works...need to brush up on my Verilog!

The Verilog Dave pointed to won't make alot of sense unless you read the Xilinx docs about
the ICAP module. I cut the very first version of that and it was a bit of an experiment for
me so isn't the most elegant but it worked.

[dominicbeesley]

Thanks lads, it was the bit the reads the switches that I was interested in, I've had a quick look but now got side tracked as my beeb has decided to die on me so I can't test the matchbox at the moment.

Logic analyser is hooked up and hopefully be back in business soon...

D

[hoglet]

Hi Guys,

It's been a while since we made any changes to the Matchbox firmware (about 9 months). So to remedy that, here's a update that includes a radically overhauled version of the 6502 Co Pro:

LX9CoProCombined_20161110_1455_dmb.zip

(1.89 MiB) Downloaded 112 times

The main changes are:

6502 Co Pro now uses the 65C02 version of Arlet's 6502 core.

Arlet's 6502 core is very well regarded over on 6502.org, and is specifically designed to get the most out of registered FPGA block RAM without needing to insert a wait state. The update to the 65C02 instruction set was done a few months ago by myself and BigEd.

6502 Co Pro speeds are now 4MHz/8MHz/16MHz and 64MHz.

i.e. Co Pro 3 is now twice as fast, due to the use of Arlet's core.

6502 Co Pro has access to 1MB of external RAM using bank switching.

This is the cool new feature that we've been thinking about for a while.

The 6502 memory map is spilt into 8K pages via a set of paging eight registers at &FEE0-&FEE7:
- the register at &FEE0 controls the mapping of 0x0000-0x1FFF
- the register at &FEE1 controls the mapping of 0x2000-0x3FFF, etc
- page values of 0x00-0x07 are directed to fast internal block RAM (and this is the default).
- page values of 0x80-0xFF are directed to slower external static RAM.

To test this, there is now a variant of the Co Pro Conway Life implementation that uses this bank switched memory support much larger patterns. More on this later in the Conway Life Thread

It's now possible for someone to port Alan Cox's Fuzix to run on the 6502 Co Pro in the Beeb.

32016 Co Pro is slightly faster.

ROM accesses now have one less wait state.

Other Co Processors.

None of the other Co Processors have changed.

Compatibility.

Please let me know if you have any issue with this release. I'm aware that the last release didn't seem to work on the latest batch of boards from Jason, for reasons we have yet to fathom. There is nothing in this release that I would expect to have fixed that.

regards

Dave

[tricky]

That's great, just one little suggestion
Is it worth having a 3MHz 6502 for Elite/ModelB mode?

[fordp]

Dave with the Matchbox board no longer going to be made any more how about this as an alternative:

http://www.cnx-software.com/2017/03/13/ ... h-sh2-soc/

I am happy to buy one for you if it is suitable.

[hoglet]

Dave with the Matchbox board no longer going to be made any more how about this as an alternative:
http://www.cnx-software.com/2017/03/13/ ... h-sh2-soc/

The problem with this board, and in fact most current FPGA boards, is they use SDRAM rather than SRAM, which is much slower for random accesses, and infinitely harder to work with.

Also, I don't think I have the motivation to target another FPGA board, unless it is architecturally very similar to the old one (i.e. uses SRAM).

Jason has (I think) offered to make the current PCB design public, so if the demand is there I'm sure someone will pick this up. I'm just not sure the demand is there.

Dave

[fordp]

Worth a try Dave. It just seemed an option to allow new people to get on board.

I was thinking if there is at least 64K of block RAM then the 8 pit parts would be OK.

It looked like a pretty similar chip too, so the porting would not be too bad.

I liked the elegance of using the same level shifter board for both this project and Pi Direct.

Thanks for looking.

[flynnjs]

To be fair, I've got something else in the pipeline which may allow people "to get on board".
It could also free some boards up as people might upgrade.
However, I've got LVROM drives to sort and a new computer to go into space before then
so I expect it won't be ready until xmas time.

[trixster]

That's great, just one little suggestion
Is it worth having a 3MHz 6502 for Elite/ModelB mode?

I'd like this too!

[hoglet]

Continued from:
viewtopic.php?p=169437#p169437
and
viewtopic.php?p=169449#p169449

Dave what ram speed it the copro expecting?

The x86 Co Processor is being clocked at 16MHz.

Which is somewhat overclocked I think for the RAM speed we have, but up until now there have been no reported issues.

It's very painful with Xilinx ISE to properly constrain a design that uses external asynchronous RAM, so I never attempted to do this with the Matchbox designs. So it is possible the path involving the asynchronous RAM includes considerable logic delays on the FPGA as well.

I did subsequently work out how to do this for BeebFPGA:
https://github.com/hoglet67/BeebFpga/bl ... uo.ucf#L57
but never went back and applied this to all the Matchbox designs.

With 70ns rev E chips tge x86 doesn't appear to work correctly some times you get ram faulty type 0/xxxx where xxxx appears to be random.

RevD ram at 70ns appear to work. Jason has tried all the usual tricks of adding extra decoupling etc.

I would suggest halving the clock rate to 8MHz, and see if that resolves this issue.

Here's a test build that does just that:

LX9CoProCombined_20170514_0720_dmb.zip

(1.89 MiB) Downloaded 91 times

The source for this is here:
https://github.com/hoglet67/CoPro6502/t ... _2017_test

(Only the x86 design has been changed here)

Note, it seems this 8MHz clock rate is slightly too slow as the language transfer on Ctrl-Break hangs. But it should still be useful for testing. Just do a normal break, then type DOS as the * prompt. If this resolves the issue, we can try 12MHz. The original Master 512 Co Processor is 10MHz I think.

Dave

[hoglet]

Here's a few more speeds to try:

10MHz:

LX9CoProCombined_20170514_0916_dmb.zip

(1.89 MiB) Downloaded 96 times

12MHz:

LX9CoProCombined_20170514_0941_dmb.zip

(1.89 MiB) Downloaded 91 times

14MHz:

LX9CoProCombined_20170514_0954_dmb.zip

(1.89 MiB) Downloaded 103 times

(10MHz is fast enough for the language transfer to work)

Dave

[flynnjs]

Dave,
thanks for that. I went straight for 12MHz build and x86 DOS is now 100% stable

The ARM is still very iffy. Does that push the RAM limits too?

[hoglet]

Dave,
thanks for that. I went straight for 12MHz build and x86 DOS is now 100% stable

The ARM is still very iffy. Does that push the RAM limits too?

It runs at 32MHz with one wait state.

Adding a second wait state would be possible, but is more that a 5-minute job...

I could slow the whole thing down to 24MHz if you like.

Has the SRAM type changed on the most recent boards, or is it just a different batch that happens to be closer to spec (i.e. slower)?

I'm pretty sure I settled on 16MHz for all the external RAM based designs:
- Bank-switched RAM on the 6502
- 80x86
- 32016
- ARM2
- 68000

It does sound like all of these should be reduced to 12MHz.

Dave

[hoglet]

Edited above post.

[flynnjs]

The latest are IS66WV51216EBLL-70
Previous had been IS66WV51216DBLL-70.

There could also be some with IS62 series too.

I have two identical PCBs one with the D revision RAM and another with the E revision.
The D is OK at 16 MHz and the is E isn't.

As an interim just running the whole ARM slower might be useful.

[hoglet]

Actually, could you try the 6502, as it clocked at 64MHz but with 4 wait states added for external RAM accesses?

The only program I know that uses this is LIFE:
http://www.stardot.org.uk/forums/viewto ... 39#p154739

The program to run in MLIFE (Matchbox Life)

Test with the Turing Machine (it takes about a minute to load!)

I'll update the ARM now...

Dave

[hoglet]

Actually, I can easily add an additional RAM wait state to the ARM, as I parametrized this:
https://github.com/hoglet67/CoPro6502/b ... ram32.v#L6

It will take about 30 mins to build this (and the x86 again at 12MHz).

[hoglet]

Here's a build with:
- 80x86 running at 12MHz
- ARM2 running at 32MHz with two external RAM wait states

LX9CoProCombined_20170514_1320_dmb.zip

(1.89 MiB) Downloaded 106 times

Dave

[flynnjs]

Thanks, that build seems 100% reliable on the rev E RAM.
The datasheet for the RAM gives the same timing figures but they've obviously changed something internally to make it less overclockable.