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

[dv8]

Possibly an issue with the language relocator introduced in MOS 3.50?

That's exactly what it is.
The relocation tables for BASIC and EDIT are at the end of the VIEW ROM.
Have you replaced VIEW using the overlay board?

[hoglet]

A separate point - should I be able to read the current co-pro number with OSBYTE 150, or is the information lost after a reset? It always returns &7F in Y.

*FX 151 230 n is write-only.

There is no way to read n back (because read is already defined for all 8 tube addresses).

Dave

[BeebMaster]

Possibly an issue with the language relocator introduced in MOS 3.50?

That's exactly what it is.
The relocation tables for BASIC and EDIT are at the end of the VIEW ROM.
Have you replaced VIEW using the overlay board?

Yes - although by the previous owner, not me. In fact I just found an old screenshot from 2003 which does show View in ROM E, but now it's CPFS, so I must have altered the overlay board link settings at some point.

[BeebMaster]

Been playing about with this a bit, it's quite interesting. I also read the MOS 3.50 manual.

BASIC 4r32 doesn't work on a second processor on MOS 3.20, presumably because its relocation address is &B800 but without the locator to translate all the absolute jump addresses when it gets copied into the second processor, the code doesn't make sense.

(That being said, the standard View in MOS 3.20 does relocate giving 48K of free space, so I don't understand how that works without the relocator, unless the whole thing is written with only relative jumps, which doesn't seem likely.)

Where I was finding that *BASIC correctly loaded BASIC 4r32 into the second processor on MOS 3.50, that's because it doesn't relocate when invoked with its usual star command. BASIC 4r32 also has *HIBASIC in it, which will relocate, and doesn't work because it can't find the relocation table pointed to by the descriptor table. If it's the configured language, it will relocate on a hard reset, or it can be forced at other times with *FX142 (or forced not to relocate by adding 64 to the ROM number).

Looking at the image of BASIC 4r32, the descriptor table has the ROM number where the relocation table is held stored as &82. According to the manual, this is a relative number if the top bit is set, so it would make &82 equal 2 ROMs higher than BASIC, so with BASIC in 12 and View in 14 in the normal MOS 3.50 would be how it is expected to work.

I thought I could try to replicate this by loading BASIC 4r32 into sideways RAM bank 4, and View B3.3 into 6, but I can't do it because BASIC always disappears from the ROM table after a hard reset (even though it's still there if examining the memory)! So that's either some other curiosity of Station 201 that I don't know about yet, or a copy protection thing in BASIC 4r32 that isn't documented.

[BeebMaster]

I solved it by disabling the overlay board and then BASIC 4r32 relocates as expected to B800 in the second processor.

I also solved why it didn't work in sideways RAM. It seems MOS 3.50 has a feature that disables all duplicate copies of a ROM, even if one of them is unplugged. So I loaded BASIC into SRAM, overtyped the copyright date from 1988 to 1989 and it reappears after a hard reset, and loading View two slots higher makes the relocator work.

The only thing I still don't understand (although it isn't for this topic really I suppose) is how View in MOS 3.20 and MOS 3.50 relocate giving 48K free when they don't have the relocation bit set in the ROM type.

[jgharston]

All of my binaries load at &F000, this seems to work fine, I'm not sure if addresses higher than &10000 will cause issues if you try to use DFS rather than ADFS as your file system, but &F000 is definitely safe to use.

DFS uses 18-bit addresses, &FFFF0000-&FFFFFFFF and &00000000-&0002FFFF. So you can use any language address up to &2FFFF. Checking the DFS code suggests you can load any file up to &2FFFF and it will wrap past and continue into memory at &3xxxx. Eg, loading a 32K file to &2FF00 will load it into memory at &2FF00-&37EFF, which makes sense as the filing system should be agnositic about the system it is loading into.

[jgharston]

BASIC 4r32 doesn't work on a second processor on MOS 3.20, presumably because its relocation address is &B800 but without the locator to translate all the absolute jump addresses when it gets copied into the second processor, the code doesn't make sense.

(That being said, the standard View in MOS 3.20 does relocate giving 48K of free space, so I don't understand how that works without the relocator, unless the whole thing is written with only relative jumps, which doesn't seem likely.)

View has its own relocator, and has had since version B2.somethingorother.

I thought I could try to replicate this by loading BASIC 4r32 into sideways RAM bank 4, and View B3.3 into 6, but I can't do it because BASIC always disappears from the ROM table after a hard reset (even though it's still there if examining the memory)! So that's either some other curiosity of Station 201 that I don't know about yet, or a copy protection thing in BASIC 4r32 that isn't documented.

Have you tried BASIC in bank 5 and View in bank 7? I was finding bank 4 disappearing when I was trying to test AMX Art with ADFS, and it's heartening to see somebody else having the same issue, I wasn't imaginging it!

Edit:

I also solved why it didn't work in sideways RAM. It seems MOS 3.50 has a feature that disables all duplicate copies of a ROM, even if one of them is unplugged. So I loaded BASIC into SRAM, overtyped the copyright date from 1988 to 1989 and it reappears after a hard reset, and loading View two slots higher makes the relocator work.

All BBC MOSes have that, it's not Master-specific. And you've explained my disappearing bank 4 issue!

[BeebMaster]

Ah yes, but MOS 3.20 doesn't delete a duplicate ROM from the ROM table listing, whereas MOS 3.50 does. And there's an extension in MOS 3.50 to *UNPLUG which apparently unplugs all identical copies of a ROM, so that's why I couldn't use a SRAM version of BASIC with the ROM version unplugged, as it had disabled both.

[Wheel_nut]

All BBC MOSes have that, it's not Master-specific. And you've explained my disappearing bank 4 issue!

Would that also explain why I couldn't get View v3.00 working in Sideways RAM on my Beeb? Your View J3.00 works perfectly for me in an EPROM.

[dominicbeesley]

DFS uses 18-bit addresses, &FFFF0000-&FFFFFFFF and &00000000-&0002FFFF. So you can use any language address up to &2FFFF.

I've been meaning to ask about this recently. On the 65816 processor DFS226 and VDFS (in b-em) fail to load anything >= &20000 with *LOAD and *RUN. There's no problem with an explicit load address i.e. *LOAD CLOCKSP 20600.

As far as I can see it is supposed to work as above but doesn't...it is fin with ADFS. I've not had a chance to investigate where it is failing but seems to be (V)DFS

[dominicbeesley]

I just had a look at vdfs in b-em and it looks like it only allows tube style transfers for addresses <&10000 (I may be misreading this?):

Code: Select all

                if (addr > 0xffff0000 || curtube == -1)
                    read_file_io(fp, addr);
                else
                    read_file_tube(fp, addr);

I couldn't find the sourcecode for DFS 226 but the source for 229 does seem to do a compare with the bank byte being 3 to decide whether to do a tube transfer so not sure why that isn't working here. HostFS works ok.

D

[jgharston]

The VDFS support code in BeebEm has different code for the different processors as it has to "see" the CoPro's memory which is in a different structure for each system, and the last time I looked I hadn't written any code to access the the ARM memory. If somebody has added it, and they've just cut'n'pasted the code from a 64K CoPro, then it will restrict the addresses to 64K. It should restrict the addresses to the size of the memory map for the CoPro.

Code: Select all

    if (TubeEnabled || TorchTubeActive || AcornZ80) {
      addr&=0xFFFF;
      if (count>0xFF00-addr) count=0xFF00-addr;		// Prevent wrapround
    }
    if (TubeEnabled)     fread((void *)(TubeRam+addr),   1, count, handle);
    if (TorchTubeActive) fread((void *)(z80_ram+addr),   1, count, handle);
    if (AcornZ80)        fread((void *)(z80_ram+addr),   1, count, handle);
//    if (ArmTube)         fread((void *)(ramMemory+addr), 1, count, handle);
//#ifdef M512COPRO_ENABLED
//    if (Tube186Enabled)  fread((void *)(Tube186+addr), 1, count, handle);
//#endif

If the lastest code is based on the above, then the address is only restricted for 64K CoPros, an ARM or 80x86 CoPro will use a 32-bit address. Which could bomb out if writing past the end of emulated memory, the ARM and 80x86 transfer code needs to include a wrap past the size of the emulated memory.

If the memory size is a power of two then it's a simple addr = addr & (memsize-1);. otherwise a decision has to be made what to do. If memsize is 6M and you load 2M from 5M onwards, where does the second half of the data go?

Code: Select all

                if (addr > 0xffff0000 || curtube == -1)
                    read_file_io(fp, addr);
                else
                    read_file_tube(fp, addr);

That's telling me that addresses &FFFFxxxx are in I/O memory and addresses <&FFFF0000 are in CoPro memory. You would have to look inside read_file_tube() to see if it modifies that passes 'addr'.

[dominicbeesley]

Thanks JGH,

I'll have a look at BeebEm - but that doesn't have the 65816 TUBEs which is where I stumbled on this.

Still at a loss as to why DFS is seemingly doing the wrong thing.

D

[BeebMaster]

I think I found a bug in the Native ARM co-pro. It appends the line number of last line of BASIC to an OS command error in immediate mode.

[hoglet]

I think I found a bug in the Native ARM co-pro. It appends the line number of last line of BASIC to an OS command error in immediate mode.
capture217.png

Wouldn't that be a bug in the error handler in ARM BASIC 1.35?

[BeebMaster]

Possibly, but it doesn't happen when running ARM BASIC 1.35 on RISC OS, for example, so I wonder if it is something to do with the interaction between the Native ARM OS and the BASIC error handler. I'm not sure what causes the line number to be added to an error message, but I'm guessing it's a flag of some sort, perhaps it's being interfered with when control returns to ARMBASIC from an OS command?

[hoglet]

Possibly, but it doesn't happen when running ARM BASIC 1.35 on RISC OS, for example, so I wonder if it is something to do with the interaction between the Native ARM OS and the BASIC error handler. I'm not sure what causes the line number to be added to an error message, but I'm guessing it's a flag of some sort, perhaps it's being interfered with when control returns to ARMBASIC from an OS command?

I've looked at how Basic 1.35 work, and the Error Handler is actually just written in BASIC. A line number is added if the ERL variable is non-zero. So it seems somehow this is getting set during the error processing of a bad command error.

Specifically, it seems to be set to the last line number of the current Basic program. But this only seems to happen if there is a basic program loaded. I'm at a loss to explain how the environment can triggering such a behaviour.

Please can you try these two tests for me using ARM BASIC 1.35 on RISC OS?

1. For the issue you have identified:

2. For the possible second issue, that seems to corrupt the current basic program:

(I did find a bug in the Native Arm Co Pro error handler code, but it's not responsible for this issue)

Dave

[dominicbeesley]

I'm not sure how it works in Arm BASIC but (IIRC) in 6502/65816 BASICs there is a text pointer zero-page variable which points at wherever the current basic or OSCLI line is stored. When an error occurs if this is below PAGE then ERL is set to 0, if greater or equal then the program is searched for a line containing that address - if it is past the end then the last line number is set in ERL.

Could it be that the input/* command buffer is "above" the BASIC program on the Arm Copro? What happens with OSCLI? that executes from the string buffer I think

D

[BeebMaster]

I get the same behaviour on the Native ARM, but it's any * command, not just a Bad command error. Also the program corruption occurs with or without a * command:

Next will try it on RISC OS 3.70.

[BeebMaster]

Oh dear!

[BeebMaster]

The Bad program bug looks to have been there since the beginning:

[hoglet]

Just a quick note to say we discovered a couple of critical issues with Gecko on the RPI4 which prevent the Pi from booting.

These have now been fixed, so if you want to use Gecko on the RPI4 you'll need to download the latest version:
https://github.com/hoglet67/PiTubeDirect/releases

These fixes only affect the RPI4; for other platforms there are no changes, so no need to update.

And as no one has complained, it seems there aren't many RPI4 users out there.

Dave

[BeebMaster]

I wonder if we should run a poll on what Pi people are using?

[IanS]

Please show the results as a pi(e) chart.

[BigEd]

It would also be interesting to see what version they are using, or to put another way, whether they've ever updated.

I think I'd suggest a new thread though.

[KenLowe]

I wonder if we should run a poll on what Pi people are using?

Will there be an option for 'all of the above'

It would also be interesting to see what version they are using.

Again, will there be an option for 'all of the above'

[BeebMaster]

I'm happy to start one, although I'll need to dig out a full Pi list. What's that new thing that comes in its own box, does that count?

I think a poll for Pi 1 MHz might be useful as well.

Maybe even RGB to HDMI?

[jgharston]

I think I found a bug in the Native ARM co-pro. It appends the line number of last line of BASIC to an OS command error in immediate mode.
capture217.png

You've pressed BREAK then done OLD. Is that actually any code in there? You've 'OLD'ed random data, so the error handler is going to get confused validating the program when an error occurs.
What happens if you do:
BREAK
10HELLO
*this is an error
?

[jgharston]

I get the same behaviour on the Native ARM, but it's any * command, not just a Bad command error. Also the program corruption occurs with or without a * command:

It's not corrupting the current program, because you've done NEW, so there *is* no BASIC program. Absolutely anything is allowed to happen to the heap between the end of the current BASIC program and the top of memory. Anything that gets put in the heap will, well, get put in the heap, and if you have no BASIC program, the heap starts at PAGE+2. If there *used* *to* *be* a BASIC program at PAGE, and you place the heap on top of it - BY NEWING THE PROGRAM - then, yes, anything that goes in the heap is going to overwrite that program that is no longer there because you've NEW'ed it.

[jgharston]

At some point the default error handler changed from
IF QUIT ERROR EXT ERR,REPORT$ ELSE RESTORE:IF ERL:!(HIMEM-4)=@%:@%=&90A:REPORT:PRINT" at line ";ERL:@%=!(HIMEM-4) ELSE REPORT:PRINT
to
IF QUIT ERROR EXT ERR,REPORT$ ELSE RESTORE:IF ERL CALL!ERRXLATE:PRINT$STRACC ELSE REPORT:PRINT

presumably, ERRXLATE is a call to use BASICTrans to create an internationalised error string, and that may well use heap space - as it is allowed to do - in creating that string.