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

[hoglet]

Am I doing it wrong?

What file system are you trying to load it from?

Also PAGE (at &8F00) is lower than the load address of BASIC, so amn't I going to overwrite BASIC with BASIC at some point?!

Indeed....

It needs a loader writing that will relocate it to very high in memory.

[BeebMaster]

Well well! ANFS strikes again! If I *BAS135 from ADFS it executes fine (although I still get a disc search and not found sometimes).

According to the REM lines I am on Fer-de-lance-dev, commit ID 2ce115d, which I think is the fix applied earlier in the year for the ANFS 2-byte bug thing.

I still lose BASIC on BREAK, is that normal?

[hoglet]

Well well! ANFS strikes again! If I *BAS135 from ADFS it executes fine (although I still get a disc search and not found sometimes).

Is this a Beeb or a Master?

What version of ANFS?

I wonder if large file support is needed?

Well well!
I still lose BASIC on BREAK, is that normal?

I think so. It's the same for me.

[BeebMaster]

Master 128, MOS 3.20, ANFS 4.25.

It also has real internal 65C102 co-processor, I am using external PiTube Pi-Zero.

Funny that it happens with the native ARM but not the ARM Second Processor.

[BeebMaster]

Native ARM doesn't seem to load anything of any size from Econet. The smallest file I tried *LOADing was just 156 bytes. When I've loaded BASIC from ADFS, I then can't load any BASIC in from the net. It appears to do the load but the listing is blank and TOP stays at &8F02.

[hoglet]

OK, that definitely sounds like a bug in the Native ARM Co Pro.

I'm not sure I have the hardware to reproduce thus, unless I can use an A5000 as the file server.

I only have 1 1/2 Masters (the second one is missing a power supply).

[BeebMaster]

I'm wondering if I haven't got the right firmware now for some reason...I seem to be back to those problems we were having in January. If I save some BASIC to the Econet file server from the Native ARM it just saves as a load of zeros, but the save (and loading back) work from the 6502 and ARM 2nd processors.

[hoglet]

I'm wondering if I haven't got the right firmware now for some reason...I seem to be back to those problems we were having in January. If I save some BASIC to the Econet file server from the Native ARM it just saves as a load of zeros, but the save (and loading back) work from the 6502 and ARM 2nd processors.

I think you need to be running Fer-de-lance-dev commit ID 2ce115d (or later) on any Pi Tube Direct that's using ANFS (i.e. both the file server and the client).

Dave

[BeebMaster]

Right. That's all right then, I am only running the one Pi Tube. The file server is a 65C102.

[zolbatar]

Just a quick question, I had a Pi 3B+ on my PiTubeDirect but reused it for regular RISC OS stuff. Is the Pi Zero still good for use? I presume not wildly slower than the 3B+?

I don't mind buying either as they are both cheap enough, but just feels "neater" having a smaller daughterboard inside the case, and of course, probably less heat as well.

Cheers,
Daryl.

[hoglet]

Just a quick question, I had a Pi 3B+ on my PiTubeDirect but reused it for regular RISC OS stuff. Is the Pi Zero still good for use? I presume not wildly slower than the 3B+?

A Pi Zero will be fine - PiTubeDirect only uses a single core anyway.

I use the Pi Zero exclusively, because it's smaller, neater and draws significantly less power.

The main benefits of the Pi 3B+ or the Pi 4 are the larger cache and higher clock speed.

Dave

[dp11]

Pizero will be fine. I don't have all the figure to hand , but

PiZero(w) ( ARM1176JZF-S ARMv6 1GHz $5.00 to $10.00 +TAXes )
armcode 6502 : 290MHz

RPi3B+ ( Cortex A53 ARMv8 1.4GHz $35.00 + TAXes )
RPi3A+ ( Cortex A53 ARMv8 1.4GHz $25.00 + TAXes ) should work but untested
armcode 6502 : 339MHz
lib6502 : 131.56MHz
Z80 86.78MHz
ARM 151.46MHz
nativeARM : 20,735MHz

RPi4 ( Cortex A72 ARMv8 1.5GHz $35.00 + TAXes)
armcode 6502 : 370MHz
lib6502 : 237MHz
Z80 126MHz
ARM 246MHz
nativeARM : so fast it breaks clocksp

As you can see from the armcode 6502 cost per MHz the PiZero wins. Other cores will have a greater performance increase with newer ARM architectures as they are written in C

[zolbatar]

Thanks for the advice. Ordered a Zero WH.

I'm going to try and port some of my RISC OS 3D code over and see how much I can eek out of my 128 for graphics. I know right now that video write speed will be the bottleneck obviously.

Daryl.

[BeebMaster]

OK, that definitely sounds like a bug in the Native ARM Co Pro.

I'm not sure I have the hardware to reproduce thus, unless I can use an A5000 as the file server.

I only have 1 1/2 Masters (the second one is missing a power supply).

The A5000 can be used as a Level 4 fileserver although I'm not sure how much of a fileserver is needed for testing. I can't just recall whether the problem with ANFS we had previously was restricted to Econet data transmissions or whether actually saving the data to some filing system was part of the problem. You might get away without a fileserver by using a transmit or remote poke operation from the A5000 to the Pi-ed up Master.

[map856]

Does the EasterEgg release support the copro=N option in config.txt?

I've attempted inserting copro=14 (to start up with no coprocessor) in a couple of places but it seems to be getting ignored, i.e. it still starts up in the default 6502 second processor configuration.

Is there perhaps a specific location in config.txt where it has to be inserted?

Martin

[hoglet]

Does the EasterEgg release support the copro=N option in config.txt?

I've attempted inserting copro=14 (to start up with no coprocessor) in a couple of places but it seems to be getting ignored, i.e. it still starts up in the default 6502 second processor configuration.

copro=N should be added into cmdline.txt, not config.txt

(also, everything in cmdline.txt needs to be on the same line)

[map856]

Ah, ok! Easy enough. I'll try that. Thanks Dave.

Update:

That worked just fine of course.

But now I'm curious as to what the other parameters in cmdline.txt do and whether they should be left there:

copro=0 copro1speed=3 tube_delay=0 elk_mode=0

[BBCMaster2019]

Sorry if this is a daft question but I'm having issues getting Pi Zero W to work with the newest PiTubeDirect EggEater 23rd December 2018 Release.

After a quick look I reliased that there was a config file and I possibly need to remove the references to the other Pi versions. as the Pi 1 is the same cpu as the zero. I decided to use this with no change.If I press the Break key the Pi is turning on as I see the activity light come on but it goes straight off if I press break a second time. I had a quick look at the earlier versions and noticed there was an image file in them for the Pi Zero. So is the zero only supported on earlier versions?or am i missing something.I have also noticed that the model of pi Zero supported in the 1.3 (with no Wi-fi and blu tooth) mine is the Pi Zero 1.3 W with Wifi and Bluetooth I have tried this with a 1GB and 2GB Micro SD card. This is all installed in a BBC Master with internal Raspberry Pi Co Processor BBC master Adapter Issue 2B. I also have a Smart SPI installed. I dont have the Smart SPI Rom installed as I found loading MAMMFS into shadow ram better. So suspect this should be ok to leave attached.

Thanks in advance for any advice.

[hoglet]

Sorry if this is a daft question but I'm having issues getting Pi Zero W to work with the newest PiTubeDirect EggEater 23rd December 2018 Release.

It should without needing to make any config changes at all.

The Pi One, Pi Zero and Pi Zero W all use the same Broadcom SoC and so are able to share the same Kernel.

The activity light behaviour is as expected - it toggles state when there is activity.

This is all installed in a BBC Master with internal Raspberry Pi Co Processor BBC master Adapter Issue 2B.

Which vendor did you get this from?

Thanks in advance for any advice.

What Tube related *CONFIGURE setting do you have?

Can you try:
- *CONFIGURE TUBE
- *CONFIGURE EXTUBE
- <Ctrl Break>

I appeciate that you have it connected to the internal tube, but for various reasons on most systems setting EXTUBE is more reliable.

Dave

[BBCMaster2019]

Thank you for the reply

Which vendor did you get this from?

Retro Clinic

What Tube related *CONFIGURE setting do you have?

Can you try:
- *CONFIGURE TUBE
- *CONFIGURE EXTUBE
- <Ctrl Break>

I appeciate that you have it connected to the internal tube, but for various reasons on most systems setting EXTUBE is more reliable.

Dave

Sorry I hadnt seen any reference about *Configure When I looked around for info. The *Configure Commands above have got it to work.

Thank you again

I've even tested it now by loading 6502 Second Processor version of Elite

[BeebMaster]

Also PAGE (at &8F00) is lower than the load address of BASIC, so amn't I going to overwrite BASIC with BASIC at some point?!

Indeed....

It needs a loader writing that will relocate it to very high in memory.

This became a problem recently as I am using the Native ARM so I can have a very large (eg. 8MB) data buffer in BASIC.

My first solution was to set PAGE to &20000 and add this to my *KEY10 definition (which already includes *GO F12C to re-start BASIC without having to load the file again).

Now I have discovered that BASIC 1.35 appears to be relocatable, so it can be loaded anywhere. I've set its load/exec addresses to &1800000 so it's well above HIMEM. (I have to *GO it from 180012C however).

The first time I did it, I used an extra nought and loaded it at &180000000, which still worked, so the co-pro must be able to access at least 400MB of RAM if anyone wanted to increase the available RAM to the Native ARM co-pro, for instance...

A couple more quirks with the Native ARM if I may:

If there's a BASIC program loaded and you generate an error in immediate mode, the error message is appended with "at line <last line of BASIC>".

*. (but no other * command I've tried, including *CAT) always reports the ARM Tube help line.

[KenLowe]

I'm trying to get PiTubeDirect running on an old 26pin Raspberry Pi Model B (I think), but it's not working. Set up is level shifter is connected to beeb via 40 way ribbon. The other end of the level shifter is close coupled to the 26 pins of the RPi pins 27 thru 40 on the level shifter are not connected to anything. The RPi is powered up via a remote PSU, and the RPi is then powering up the level shifter.

If I swap the RPi Model B for a RPi 3 Model B (using the same SDCard) then it all works as expected.

I'm about to solder a debug header onto the level shifter and hook it up to a PC, but in the interim, any thoughts?

Edit: When I say it's not working, what happens is I get a flashing cursor top left of the screen. No text.

[BigEd]

Which version of PiTubeDirect are you using? The as-yet-unreleased Fer-de-Lance is probably a good one - Dave revamped the detection of various Pi models. I think you need to build from source though. See the branch here: https://github.com/hoglet67/PiTubeDirec ... -lance-dev

[KenLowe]

Which version of PiTubeDirect are you using? The as-yet-unreleased Fer-de-Lance is probably a good one - Dave revamped the detection of various Pi models. I think you need to build from source though. See the branch here: https://github.com/hoglet67/PiTubeDirec ... -lance-dev

I'm using EggEater. Building from source will need to be for another day! Is there anything I can do to force the PI to use the correct EggEater firmware kernel?

I tried modifying config.txt as follows, but that didn't work:

Code: Select all

# config.txt for PiTubeDirect (https://github.com/hoglet67/PiTubeDirect)
#
# default options 
core_freq=350
kernel=kernelrpi.img

# Global settings
[all]
force_turbo=1

hdmi_blanking=2
hdmi_ignore_edid=0xa5000080
hdmi_ignore_hotplug=1
boot_delay=0

kernel_address=0x1f00000
gpu_mem=16

# See fully annotated config.txt at
# https://raw.githubusercontent.com/Evilpaul/RPi-config/master/config.txt
# (via http://elinux.org/RPiconfig)

[BigEd]

I might be a bit confused... I'm certain Dave can give better advice!

[KenLowe]

So, I managed to hook up a serial interface, and get good data from the RPi 3B, but absolutely nothing from the RPi Model B.

Could it be something to do with the fact that on the Model B, pins 3, 5 & 13 have a different assignment compared to the Model 3B? Although, I presume the PI version detection code should be taking care of that?

One other thing I've noticed is that one of the level shifter ICs seem to run much warmer when hooked up to the Model B

[KenLowe]

To aid discussion / fault finding, I've attached a couple of photographs showing the setup on my RPi 3B and the equivalent setup on my RPi Model B. The header extension on my RPi Model B is a bit of a bodge. I'm using 2 off 1x4 header strips and 2 off 1x10 header strips as that's all I had available. That's why you see the extension strip extend beyond the 2x13 header on the RPi.

Working RPi 3B

Non Working RPi Model B with extension header

[hoglet]

Ken,

Could you try the Fer-de-lance RC0 release I have just made available?
https://github.com/hoglet67/PiTubeDirec ... -lance-rc0

As Ed eluded to, there are a small number of Pi 1B models that have an unusual revision number (01000002 rather than 00000002), and these were being incorrectly recognised by Egg Eater and earlier releases. This was fixed in the Fer-de-lance releases, which we tested at ABUG.

You don't have to make any changes to the config.txt file file, unless you want to enable logging by switching to the debug Kernel.

Dave

[hoglet]

I've also added some release notes for Fer-De-Lance RC0:
https://github.com/hoglet67/PiTubeDirec ... -lance-rc0

Dave

[KenLowe]

I've just tried this latest release, but it isn't working either. No data on the serial link. I therefore decided to remove the level shifter altogether, and hook the serial comms directly onto the GPIO header. When I do this, I can see valid data being streamed from the RPi. Next step was to use one of my Sundby level shifters in case the issue was specifically with my level shifter. However, I'm seeing the same issue with that level shifter too. No data on the serial link.

As I mentioned earlier, one of the 245s on the level shifter board is definitely running hotter when hooked up to the RPi Model B. This is the level shifter for the control and address signals. I'm not sure why this is happening? The same level shifters work fine with the RPi 3B. Is it possible that the RPi Model B GPIO pins are not being set up correctly resulting in higher than normal current flow through the level shifter?