Running RVBASIC from PiEconetFS crashes with exception

[mincebert]

I'm unclear if this is a RISC-V BASIC issue, or a PiTubeDirect Indigo issue, or a problem with PiTubeDirect, or I'm doing something monumentally stupid, but I get an uncaught exception if I try and execute RVBASIC from my PiEconetBridge.

I have the load and execute addresses set to &F80000 and I get the same error if I *LOAD and *GO, rather than just */, if I *MOVE the file from NET to ADFS, it then runs OK.

*NET
*INFO RVBASIC
RVBASIC    00F80000 00F80000   02328C    WR/       05/09/23 020716
*/RVBASIC
00F8578A:00000000:
Uncaught Exception
*LOAD RVBASIC F80000
*GO F80000
00F8578A:00000000:
Uncaught Exception
*MOVE RVBASIC -ADFS-$.TEMP.RVBASIC
*ADFS
*INFO $.TEMP.RVBASIC
RVBASIC    WR (54)  00F80000  00F80000  0002328C  003B25  
*/$.TEMP.RVBASIC
BBC BASIC for RISC-V Co Processor 1.36a
(C) Copyright R. T. Russell, 2023
>

Apologies if I've missed something not implemented yet, or misunderstood something!

[mincebert]

This is on a Master with MOS 3.50 and ANFS 4.25, BTW.

[hoglet67]

This is a good find - I don't think I've tested the two-byte transfer mode that ANFS uses.

Can you spot the cut-paste error?

Type3:
    lb      t0, R4STATUS(gp)            # Test for an pending interrupt signalling end of transfer
    bltz    t0, Release
    lb      t0, R3STATUS(gp)
    bgez    t0, Type3
    lb      t0, R3DATA(gp)
    sb      t0, (t2)                    # store lo byte to memory
    lb      t1, R3DATA(gp)
    sb      t0, 1(t2)                   # store hi byte to memory
    addi    t2, t2, 2
    j       Type3

I'll fix this today and post a dev-build to this thread for you to test.

[mincebert]

I only started looking at RISC-V yesterday , but is it the second store should be t1 instead of t0?

Or, more probably, the load should be t0 instead of t1, since I don’t think there’s a reason to use another register there.

If so, that does explain why, when I compared a copy loaded via ANFS and another via ADFS that there were a lot of differences. I hadn’t noticed they were every second byte, though!

[hoglet67]

Yes indeed, the second load should be t0.

[mincebert]

Oh yes, so it is - every odd-numbered byte is wrong and the same as the even-numbered byte before it!

[hoglet67]

I've fixed the LOAD issue, but there also now seems to be an issue with SAVE that I'm investigating....

[hoglet67]

I've created a seperate issue (#179) for the SAVE bug, as that looks like an error in the ULA code.

I'll close this one now.