Current state of PiTubeDirect on Spectrum Next

[egrath]

Hi, can you please elaborate on the current state of using BeebFpga on the Spectrum Next in conjunction with a PiTubeDirect accelerator? I've managed to build a external coprocessor enabled bitstream by modifying the top-level component (bbc_micro_spec_next.vhd) to use the following configuration:

    generic (
        IncludeAMXMouse    : boolean := true;
        IncludeSPISD       : boolean := true;
        IncludeSID         : boolean := true;
        IncludeMusic5000   : boolean := true;
        IncludeICEDebugger : boolean := true;
        IncludeCoPro6502   : boolean := false;
        IncludeCoProExt    : boolean := true;
        IncludeVideoNuLA   : boolean := true;
        IncludeMaster      : boolean := true
    );

However, when flashing the core and running it, the display gets black after rom loading. PiTubeDirect seems to work, i've run the validation tests from https://github.com/hoglet67/PiTubeDirect/wiki/Validation and they look similar (at least they don't throw any obvious errors).

Is this supposed to work currently?

[hoglet67]

Is this supposed to work currently?

Although this feature is supported on other BeebFPGA builds, it has not been tested at all on the Spec Next, so no it's not supposed to work.

The main reason being that the Spec Next Pi Accelerator uses GPIOs differently from PiTubeDirect (in terms of the ones used, and the direction).

I was concerned about mis-configurations causing damage. For example, running the BeebFPGA core with external Tube support, but with the Spec Next Pi Accelerator present instead of PiTubeDirect.

Also, as I don;'t actually own a Spec Next, and have to borrow one for testing, I really didn't want to risk damaging someone else's Spec Next.

That said, in the BeebFPGA core the GPIOs that connect to the Pi are set to be current limited at 8mA, so I think the risk of damage is low, but it's possible.....

On the black screen you see, is there a cursor flashing in the top left corner?

[hoglet67]

That said, in the BeebFPGA core the GPIOs that connect to the Pi are set to be current limited at 8mA, so I think the risk of damage is low, but it's possible.....

Actually, looking at the .ucf file I left the drive strength at 2mA, which may not be enought to operate correctly. In the other BeebFPGA builds where this feature has been tested, the .ucf file includes

DRIVE = 8 | SLOW

for each of the accel_io<> nets

But honestly, I doubt this is the issue.

[hoglet67]

Sorry for the deluge of questions....

Can you detail the steps you used to build the core?

[egrath]

1. Cloned the repository, opened bbc_master_spec_next.xise in ISE 14.7
2. Did the mentioned modifications
3. Built it using "Process->Implement Top Module"
4. copied the existing machines/bbcmaster to machines/bbctube on the Next's SD
5. modified machines/bbctube/core.cfg for a new name
6. modified machines/bbctube/beeb.cfg to disable the internal copro Regarding the Spec Next, i'll PM you @stardot

[hoglet67]

OK, you missed a crutial step which patches the BeebFPGA boot loader firmware into the .bit file. This is a 6502 program that produces the BeebFPGA splash screen and validates the ROM CRCs, prior to allowing the core to boot normally. I guess you never see this screen?

When I package the core, I run a script called make_spec_next_release.sh: https://github.com/hoglet67/BeebFpga/blob/master/make_spec_next_release.sh

This has a couple of dependencies:

• crc16 here
• beebasm here

Let me see if I can build a version with this setting.

Testing would be at your own risk though!

[hoglet67]

Regarding the risks here, there are two "mismatched" scenarios to consider:

1. Spec Next core with PiTubeDirect firmware on Pi
2. BeebFPGA core with Spec Next on the Pi

The concern is, due to the different use of GPIOs, that both the FPGA and Pi end up configuring a particular GPIO as an output, and they end up fighting.

By setting the DRIVE value to 2 in the UCF file, very little current should flow in this scenario. So no damage should result. I believe both the SpecNext and BeebFPGA cores use this setting.

The main reason I haven't enabled this feature yet is I feel more investigation is needed. Particularly I would like to understand how the Spec Next firmware uses the accelerator GPIOs. So if you (or anyone else) is aware of any documentation on this that would be very helpful.

[egrath]

I'm currently not aware exactly on how this works on the Spectrum Next side, but what i've found out is that NextPi uses the I2S protocol to communicate with the Next and that this is done by adding a device tree overlay during system startup. Then on the NextPi, one can simply play audio files back and they are sent via I2S Soundcard to the Next.

NextPi also configures a UART terminal to let the Next control what the Pi should do (play).

Will dig a little bit deeper into NextPi's source code at https://github.com/StalePixels/NextPi/

[hoglet67]

If you are up for trying this, here's a version of the cores that has the external tube enabled: beeb_fpga_spec_next_20230428_1119_MMFS.zip beeb_fpga_spec_next_20230428_1119_MMFS2.zip

The first build uses MMFS as the file system, the second uses MMFS2.

I would suggest using the Master core, as this gives you more explicit control over tube selection.

You would then need to

*CONF. TUBE
*CONF. EXTUBE

Followed by a Ctrl-BREAK

[hoglet67]

One more thing....

I would recommend you add the following line to the config.txt file on the Pi:

# Configure a pullup on nTUBE
gpio=17=pu

This should greatly reduce the chance of problems when the Spec Next core is running.

Dave

[hoglet67]

We've just given this a try on my friends Spec Next, and it appears to be working nicely.

To summarise the steps involved:

Setup PiTubeDirect

• On a PC edit the PiTubeDirect SD Card config.txt file and add the following line near the top:

#
# config.txt for PiTubeDirect (https://github.com/hoglet67/PiTubeDirect)
#

# Configure a pullup on nTUBE
gpio=17=pu

• Put the SD Card into the Pi

Setup BeebFPGA Core on Spec Next

• Unzip the 20230428_1119 release (attached above) onto the Spec Next SD Card

If you want the Pi Co Pro to be enabled by default, do the following:

For the Model B Core:

• edit machines/bbcmodelb/beeb.cfg and change copro from 0 to 1

For the Master Core:

• edit machines/bbcmaster/beeb.cfg and change copro from 0 to 1 and also change cmos10 from 80 to 84

Note:

• If copro is left at 0, you need to press Config-9 to enable a Co Processor
• If cmos10 is left at 80, you need to do *CONFIG.EXTUBE to select the Pi Co Processor instead of the internal 6502 Co Processor

[egrath]

Thank you very much for the fast response, will try that out on immediatly on tuesday morning, been on vacation for the next few days!

[egrath]

This is absolutely brilliant - works! Thank you very much for the quick response and help in this case!

[hoglet67]

@egrath

There is now a official release of BeebFpga for the Spectrum Next that includes External PiTubeDirect Co Processor support: https://github.com/hoglet67/BeebFpga/releases/tag/specnext_beta8

This adds one additional level of protection against conflicts between the FPGA and the Pi due to the wrong firmware on the Pi. During the boot stage the BeebFPGA core now passivly detects PiTubeDirect, and only if this is successful will the External Tube interface be enabled.

The splash screen has been updated to indicate whether PiTubeDirect is detected:

The passive detection needs the latest hognose-fixes release of PiTubeDirect to work: https://github.com/hoglet67/PiTubeDirect/releases/tag/hognose-fixes

This works using weak pullups/pulldowns on the Pi.

regards

Dave