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

[hoglet]

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.

Does your Pi 1B have two mounting holes? (i.e. it's a Pi 1 B version 2.0) as per here:
https://www.raspberrypi-spy.co.uk/2012/ ... revisions/

Can you try the following:
- Edit config.txt to switch over to the debug kernel
- Remove the level shifter
- Capture a complete log of the Pi booting

Then post that log here, it might show something unexpected.

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.

That's very strange, as this is one of the exact combinations we tested at ABUG.

It does suggest a conflict is occurring.

Have you double checked the header adapter you made for a short?

The only other thing I can imagine is that the Pi is damaged (a shorted GPIO) and the extra current draw when the level shifter is attached is preventing it from booting. When a GPIO is damaged, often there is a low resistance path to either 0V or 3V3, typically < 100R. Can you go around each of the GPIO pins and check the resistance.

Dave

[KenLowe]

My RPi 1B has the two mounting holes:

RPi 1B with 2 mounting holes

There's not much to go wrong with the header. Definitely no shorts. ***FFS. Note to self: Don't use a jumper to keep header pins apart***

RPi 1B with extended header

With the level shifter disconnected, here's the power up log:

Code: Select all

▒▒▒▒▒▒▒▒`▒▒▒▒▒enable_MMU_and_IDCaches


**********     Raspberry Pi BBC Micro Coprocessor     **********


    FIRMWARE_VERSION : 5e208855
         BOARD_MODEL : 00000000
      BOARD_REVISION : 0000000e
   BOARD_MAC_ADDRESS : 08eb27b8 5f385ab1
        BOARD_SERIAL : eb08b15a 00000000
           EMMC_FREQ :    200.000 MHz    200.000 MHz    200.000 MHz
           UART_FREQ :     48.000 MHz   1000.000 MHz   1000.000 MHz
            ARM_FREQ :    700.000 MHz    700.000 MHz    700.000 MHz
           CORE_FREQ :    350.000 MHz    350.000 MHz    350.000 MHz
            V3D_FREQ :    250.000 MHz    250.000 MHz    250.000 MHz
           H264_FREQ :    250.000 MHz    250.000 MHz    250.000 MHz
            ISP_FREQ :    250.000 MHz    250.000 MHz    250.000 MHz
          SDRAM_FREQ :    400.000 MHz    400.000 MHz    400.000 MHz
          PIXEL_FREQ :      0.000 MHz  -1894.967 MHz  -1894.967 MHz
            PWM_FREQ :      0.000 MHz    500.000 MHz    500.000 MHz
           CORE TEMP :  16.41 °C
        CORE VOLTAGE :   1.20 V
     SDRAM_C VOLTAGE :   1.20 V
     SDRAM_P VOLTAGE :   1.20 V
     SDRAM_I VOLTAGE :   1.20 V
            CMD_LINE : bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2708_fb.fbdepth=16 bcm2708_fb.fbswap=1 dma.dmachans=0x7f35 bcm2708.boardrev=0xe bcm2708.serial=0xeb08b15a bcm2708.uart_clock=48000000 smsc95xx.macaddr=B8:27:EB:08:B1:5A vc_mem.mem_base=0x1fa00000 vc_mem.mem_size=0x20000000  copro=0 copro1_speed=3 copro3_speed=4 tube_delay=0 elk_mode=0
               COPRO : 0
Tube ULA sample delay  0
Raspberry Pi Direct 0 65C02 (fast) Client
>> emulator speed 0
Copro Memory size 0
>>
enable_MMU_and_IDCaches


**********     Raspberry Pi BBC Micro Coprocessor     **********


    FIRMWARE_VERSION : 5e208855
         BOARD_MODEL : 00000000
      BOARD_REVISION : 0000000e
   BOARD_MAC_ADDRESS : 08eb27b8 5f385ab1
        BOARD_SERIAL : eb08b15a 00000000
           EMMC_FREQ :    200.000 MHz    200.000 MHz    200.000 MHz
           UART_FREQ :     48.000 MHz   1000.000 MHz   1000.000 MHz
            ARM_FREQ :    700.000 MHz    700.000 MHz    700.000 MHz
           CORE_FREQ :    350.000 MHz    350.000 MHz    350.000 MHz
            V3D_FREQ :    250.000 MHz    250.000 MHz    250.000 MHz
           H264_FREQ :    250.000 MHz    250.000 MHz    250.000 MHz
            ISP_FREQ :    250.000 MHz    250.000 MHz    250.000 MHz
          SDRAM_FREQ :    400.000 MHz    400.000 MHz    400.000 MHz
          PIXEL_FREQ :      0.000 MHz  -1894.967 MHz  -1894.967 MHz
            PWM_FREQ :      0.000 MHz    500.000 MHz    500.000 MHz
           CORE TEMP :  18.56 °C
        CORE VOLTAGE :   1.20 V
     SDRAM_C VOLTAGE :   1.20 V
     SDRAM_P VOLTAGE :   1.20 V
     SDRAM_I VOLTAGE :   1.20 V
            CMD_LINE : bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2708_fb.fbdepth=16 bcm2708_fb.fbswap=1 dma.dmachans=0x7f35 bcm2708.boardrev=0xe bcm2708.serial=0xeb08b15a bcm2708.uart_clock=48000000 smsc95xx.macaddr=B8:27:EB:08:B1:5A vc_mem.mem_base=0x1fa00000 vc_mem.mem_size=0x20000000  copro=0 copro1_speed=3 copro3_speed=4 tube_delay=0 elk_mode=0
               COPRO : 0
Tube ULA sample delay  0
Raspberry Pi Direct 0 65C02 (fast) Client
>> emulator speed 0
Copro Memory size 0
>>

I'll check the GPIO pin resistance and report back shortly.

Edit: So once I removed ALL 13 shorts from the header, it's sprung into life. I'm amazed I didn't damage the PI!

[BigEd]

That might be a new record for number of shorts!

[KenLowe]

Switching back to EggEater, it's also working fine. Thanks for pointing me in the right direction again.

[hoglet]

***FFS. Note to self: Don't use a jumper to keep header pins apart***
...
So once I removed ALL 13 shorts from the header, it's sprung into life. I'm amazed I didn't damage the PI!

That made me laugh.

The board revision is 000E, not one of the problematic ones.

Do keep on using the Fer-de-lance RC0 release, the more testing it gets over the next week the better.

I'm slightly surprised the Pi survuived the 3.3V and 5V rails being shorted together. Maybe the power supply protection triped.

Dave

[hoglet]

Hello all,

Just to say, the Fer-De-Lance version of PiTubeDirect is now officially released:
https://github.com/hoglet67/PiTubeDirec ... r-de-lance

There were no changes since the RC0 a couple of weeks ago.

I've also opened a new development branch for the next release, called Gecko.

Dave

[jregel]

Just upgraded to the latest release. All looking good! Thanks for continuing with this amazing development.

[BeebMaster]

I've just upgraded to this release as well, great work! Nice to see the internal 65C102 seeing the light of day!

I thought I'd try the 256K Turbo second processor with the Level 3 file server, just in case, since they'd used it to build it, they added support for the extra RAM as a data cache. And...


...sadly not!

The CPU timing says it's running at 89MHz ish, although the file server start up speed seems identical to the fast 6502. I presume though that the real 256K wedge was running at 3 or 4 MHz?

[hoglet]

The CPU timing says it's running at 89MHz ish, although the file server start up speed seems identical to the fast 6502. I presume though that the real 256K wedge was running at 3 or 4 MHz?

The photos of the original showed a 3MHz GTE G65SC02P.

Dave

[BeebMaster]

I've noticed when using the 286 co-pro, after DOS Plus is loaded, the light on the Pi is constantly frittering away as if there is non-stop data transference between the host and the co-pro. Is that normal for DOS Plus? It doesn't seem to happen with other co-processors.

[BigEd]

If I had to guess, I'd say yes: the screen on the DOS side needs to be copied to the host side. If DOS has a flashing cursor, it's likely that it would cause constant updates.

[BeebMaster]

I think I broke it...

Following on from this, I thought I'd try Inter-Word with the Turbo 256K co-pro, just in case Computer Concepts had seen into the future and built in extended memory support.

But they hadn't:

Trying to force it did this:

which is quite normal, and happens on a real one. But pressing BREAK gave this:

None of that is output from a real 6502 second processor, I don't know what causes it.

[hoglet]

None of that is output from a real 6502 second processor, I don't know what causes it.

The Pi Co Pros are pre-loaded with a couple of test programs.

This is the code that installs them on when the Co Pro is started:

Code: Select all

void copy_test_programs(uint8_t *memory) {

   memcpy(memory + 0x800, sphere, sizeof(sphere));

   strcpy((char *)memory + 0x805,        " PiTubeDirect "RELEASENAME);
   strcpy((char *)memory + 0x805 + 0x25, " Commit ID: "GITVERSION);
   strcpy((char *)memory + 0x805 + 0x4A, " Pi: ");
   strcpy((char *)memory + 0x805 + 0x4F, get_info_string());

   memcpy(memory + 0x1000, clocksp, sizeof(clocksp));
#if defined(DORMANN_6502)
   memcpy(memory + 0x3400, dormann_d6502, sizeof(dormann_d6502));
#elif defined(DORMANN_65C02)
   memcpy(memory + 0x3400, dormann_d65c02, sizeof(dormann_d65c02));
#endif
}

The obvious ones here are the SPHERE basic program and CLOCKSP.

But there is a third one, the DORMANN 6502 test suite.

What''s happening when INTERWORD crashes as the current language is that it some how manages to jump into the middle of the DORMANN test suite, which promptly fails.

Dave

[BeebMaster]

Oh yes! I never knew that. So I didn't break it after all. I'll keep trying though.

[BeebMaster]

Could the pre-loader be used to load ARM BASIC if an ARM co-pro is selected?

[jregel]

Could the pre-loader be used to load ARM BASIC if an ARM co-pro is selected?

If I understand the intent here, I think this would be a very useful feature. Although I guess it's not too difficult to load up ARM BASIC from the CLI, having it automatically start would make it more accessible and easier to get started with this co-pro.

[BeebMaster]

Yes indeed, although it loses BASIC on BREAK and has to be reloaded again, sometimes causing a Bad program. On the Native ARM co-pro I use ARM BASIC v 1.35 which I load at &1800000 exec at &180012C, so it's higher than HIMEM at &100000. Also I can do

Code: Select all

*KEY10 *GO 180012C|M

to bring it back without reloading.

I'm not sure if it's safe to load up there with the Pi (Zero) memory allocation but, as the supermodel said to the dietician, it works for me.

[*STEVE]

Having some problems with my external PiTubeDirect on my Iss 2 Master 128. To start I should say that this has been working fine on my B+128.
As I say this is an external unit with the machine configured
*CONFIGURE EXTUBE
*CONFIGURE TUBE

On booting with the co-pro connected/powered I don't get the > prompt, as though BASIC is corrupted/not fully loading...

no > or cursor

Hitting BREAK again I get to a * prompt as though BASIC is not running.
If I *CONFIGURE NOTUBE, remove power from the PI or *FX 151,230,14 to disable the co-pro, the machine works fine.

I did read somewhere in the thread that BASIC gets relocated when running the co-pro, so tried removing the ROM I had in Socket 6/7 and setting LK19 West, in case this was necessary... no good tho.

Any thoughts from any Master 128 users?... probably something stupid overlooked on my part.

FWIW I also have a DataCentre-E connected (and working fine). Same problem with and without the DataCentre connected, same problem with our without my ANFS ROM (physically) plugged in.

Steve.

[BigEd]

What do you see with *STATUS and *ROMS? I'd guess that maybe *CONF. LANG nn is mis-set.

[*STEVE]

What do you see with *STATUS and *ROMS? I'd guess that maybe *CONF. LANG nn is mis-set.

I did wonder that myself but I think this is correct. Of course, let me know if I've missed something...

* prompt

*STATUS

*ROMS

Steve

[dp11]

Try unplugging and replugging at the master end of the tube interface. I wonder if you have a slightly dirty connection

[BigEd]

Good point - if it's that, may need some determined plugging and un-plugging to clean the contacts. If you have a way to clean them mechanically, that could help.

[*STEVE]

Try unplugging and replugging at the master end of the tube interface. I wonder if you have a slightly dirty connection

Have tried a couple of times already. All the same a good suggestion... might try some contact cleaner at the beeb end and check the PCB for dry joints around the connector.

Steve

[BeebMaster]

After you get the * prompt will *BASIC load BASIC successfully?

[*STEVE]

After you get the * prompt will *BASIC load BASIC successfully?

On typing *BASIC I get
BASIC

_ (flashing cursor)

... but no >_

Steve.

[BeebMaster]

That sounds like BASIC copying itself from ROM (in the Master) to co-pro RAM (in the Pi) isn't completing. Sometimes you get that effect after a soft reset, even with a real 6502 cheese wedge, but a Ctrl-BREAK normally solves it. It could be a bad Tube connection or faulty or very long cable.

I don't think ADFS is playing up but maybe try CTRL-D-BREAK to put the machine in DFS (or *CONFIGURE FILE 9) to see if that helps.

It may be worth unplugging all ROMs except BASIC for the time being to rule out a spurious sideways ROM fault.

Are you able to get to BASIC using any of the 6502 co-pros in the Pi Tube (*FX151,230,0/1/2/3 ?)

[*STEVE]

Okay so have tried a few things:
- cleaned the tube connector with some IPA and a brush to remove any contamination
- re-flowed the tube header connector just in case
- reset the NVM (I did wonder if garbage in the NVM could be causing)

... all of these didn't help. I then suspected perhaps IC7 74LS373 could be at issue, but given this is buffering both the TUBE and 1MHz BUS and my DataCentre-E is on the 1MHz BUS and working perfectly ruled this out.

As per suggestions above from Ian...
- Forcing DFS with CTRL+D+BREAK: No better
- Selecting different co-pros with *FX 151,230,x: No better (although is clearly changing co-pros correctly)
- Unplugging all ROMS: No better

However I do think your comment about BASIC failing to copy itself across to the PI could be where the issue lies. The cable on my co-pro is a bit long TBH (about 50cm where they are usually about 20-30cm max). I do wonder if this could be the issue and that timing is marginal - okay for the B+ but no good for the Master.

Does anyone know if there's any useful debug info that comes out of the serial connection on the PI that might shed some light?

Steve.

[BeebMaster]

It does sound like the cable length is the problem. Do you have a different cable you can try, or shorten it by moving the header? Or can you fit the Pi Tube under the Master (even if temporarily for testing)?

[Mince]

I had a similar-ish problem where the machine would crash transferring certain language ROMs across the Tube to the Pi. It was a bit weird and only happened when I had two cartridges plugged into the slots on the top of my Master, but affected Dave more seriously, in the same configuration. Dave helped me get to the bottom of it and I worked around it with tube_delay=15 in cmdline.txt on the Pi, before I replaced the board.

The full bug report is here: https://github.com/hoglet67/PiTubeDirect/issues/70

... might be worth trying that.

[*STEVE]

I had a similar-ish problem where the machine would crash transferring certain language ROMs across the Tube to the Pi. It was a bit weird and only happened when I had two cartridges plugged into the slots on the top of my Master, but affected Dave more seriously, in the same configuration. Dave helped me get to the bottom of it and I worked around it with tube_delay=15 in cmdline.txt on the Pi, before I replaced the board.

Thanks for the suggestions ..tried this though and unfortunately it didn't work. I also tried shortening my ribbon cable (now at 25cm) by cutting it down and putting the header back. Unfortunately still the same behaviour. Thinking about connecting to the serial debug to see if there are any clues in the output there...

Steve.