hoglet67 / pitubedirect

Bare-metal Raspberry Pi project that attaches to the Acorn TUBE interface and emulates many BBC Micro Co Processors

PiTubeDirect

PiTubeDirect is a low cost Second Processor project for Acorn's 8-bit machines (Beeb, Master, Electron, Atom) which uses two cheap chips to interface a Raspberry Pi to the Tube connector.

The Pi emulates one of a number of CPUs, and also the Tube interface chip.

A Pi Zero can emulate a 6502 Second Processor running at 274MHz.

For more information, see the project Wiki.

Here's the minimal configuration, using a Pi Zero and a DIY two-chip level shifter:

Benchmark results for the 65C02 Second Processor:

pitubedirect's Issues

Recalibrate "slow" cores to 3MHz before release of GPU code

(NS32k) read_n will corrupt the stack when 5-8 bytes requested

I was just looking at the code that was crashing on Bas32f and I noticed a bug (Probably mine).

If you request more than 4 bytes it will try and copy it to a 4 byte variable on the stack corrupting the stack.

80286 BBC BASIC won't list programs

Writing a short Basic program, LIST gives no output. LIST ,99 will work.

10 END
LIST

(Again, supposing a core bug is most likely.)

GPU code needs updating to cope with Pi 1 GPIO differences

I think Dominic has a plan for this....

Native Arm Co Pro: Prefetch abort when running BAS135 on multi-core Pis

This happens on the Pi 3 (and probably the Pi 2) when running BAS135.

It's a regression from d485c78

At a guess, it's caused when we added the small pages. Probably they are not marked as executable.

Prefetch Abort at 0000F104 on core 0
Registers:
r[00]=00000000
r[01]=00000000
r[02]=00000000
r[03]=00000000
r[04]=0000F104
r[05]=00000000
r[06]=01AFFFE0
r[07]=01F75778
r[08]=01F46CA8
r[09]=01F46C78
r[10]=01F46C84
r[11]=01F46BDC
r[12]=00000002
r[14]=0000F108
Memory:
0000F0F4=228CCCEE
0000F0F8=215C0002
0000F0FC=2A000035
0000F100=E1A0F00E
0000F104=E10F1000 <<<<<<
0000F108=E3C110CF
0000F10C=E121F001
0000F110=EF000010
0000F114=E2411C87
Flags:
NZCV--------------------IFTMMMMM
01100000000000000000000100010000 (User Mode)
Halted waiting for reset

Re-Test multicore build on GPU branch

Most recent works has been on the Pi Zero, need to do a recent amount of testing on the Pi 2 and 3.

Native ARM Co Pro: Improve Boot Message

Currently it says:
ARM1176 1000MHz

Two issues here:

• ARM1176 is hard coded, and is wrong for the multi-core Pis
• 1000MHz is hard coded, and might be incorrect

Update message to:

• use the phrase "Native ARM" instead of ARM1176
• lookup the clock speed dynamically

Debug application on ARM2 crashes

DEBUG TESTC
or
DEBUG HELLOC
fails with
Entering Supervisor because of branch through 0 R15 = 1F0016F8

As reported on stardot:
(But note that I'm using versions of these programs from a different disk image than the one attached. It's possible the error is mine.)

The debugger of ARM Evaluation system doesn't work with B-em or BeebEm emulators. I mentioned it in the other topics...

I am attaching a disk image. It is a copy of disc 3 of AES with several other files:
TEST - a program in assembler (6 lines of the plain text) to print a character 3 on the screen;
TESTC - the previous program compiled;
HELLO - a program in assembler (6 lines of the plain text) to print a "hello world" message;
HELLOC - the previous program compiled ;
PI-ARM1 - a compiled program which gives the digits of number pi.
Just mount this disc. Try
TYPE TEST
TESTC
TYPE HELLO
HELLOC
PI-ARM1
All should work. According to ARM Utilities Reference Manual the debugger invocation has syntax DEBUG A-PROGRAM-FILE.
Try
DEBUG TESTC
DEBUG HELLOC
DEBUG PI-ARM1
All cannot work. :(

Fast 6502 model broken on gpu branch on Pi Zero

The 6502tubeasm model, the faster 6502 model, does not work on the gpu branch because it relies on a register update to service an interrupt. We have a slower approach which we use on multi-core Pi.

Setup time violations every few seconds

Running the Sphere benchmark, with the lib6502 model on a Pi Zero, we notice screen corruptions once per minute or so. (With a logic analyser triggering on the nTube signal we didn't see setup violations, which was puzzling.)

Using a logic analyser with a more precise trigger and running a Basic loop

REPEAT A=PI/2.5: UNTIL 0

we see a setup time violation (for host reads) every few seconds.

We see that there are far fewer setup violations running Elite on the 65tubeasm model, but they still occur.

There are fewer or less serious violations running the gpu branch, compared to the ARM ISR in the main branch.

6809 Co Pro: SYNC instruction broken in Cobradev

It looks like something might be broken with NMIs.

Flex doesn't seem to start, and loading large files hangs, e.g.
6809>*SAVE TEST 8000 +4000
6809>*LOAD TEST

Looking with the debugger, it's stuck in the client ROM in the data transfer loop:

FE11 13          SYNC 
FE12 A6 80       LDA   ,X+
FE14 B7 FE E5    STA   $FEE5
FE17 B6 FF 94    LDA   $FF94
FE1A 26 F5       BNE   $FE11
FE11 13          SYNC 
FE12 A6 80       LDA   ,X+
FE14 B7 FE E5    STA   $FEE5
FE17 B6 FF 94    LDA   $FF94
FE1A 26 F5       BNE   $FE11

I think the change to (tube_irq & 7) has possibly changed the behavior of the sync instruction. This should pause execution until the next interrupt, and I don't think it does any more.

32016 Co Pro: Overruns / Lates seen in (GPU branch only)

During "cc cworld" which then hangs.

tube reset - copro 13
OVERRUN: A=5; D=61; RNW=1; NTUBE=1; nRST=1
LATE: A=5; D=61; RNW=1; NTUBE=1; nRST=1
OVERRUN: A=7; D=C4; RNW=0; NTUBE=0; nRST=1
cycle counter = 40471883776
I_CACHE_MISS = 928427899
D_CACHE_MISS = 1999809
tube reset - copro 13

Does not occur on current master branch.

Suggests maybe the emulation is significantly slower on the GPU branch?
Not the case... (Bas32/CLOCKSP: Master: 19.80MHz, GPU: 24.95MHz)

suggest next release is just for fixes

Our next release will be called Boa - I suggest we make that within a few weeks, supposing people report some experience with Anaconda which motivates small fixes. We already have a couple of small fixes lined up.

On the grounds that pre-releases or release candidates will never get as much attention as actual releases, perhaps in general we should expect to alternate fix-releases and feature-releases?

Native ARM: Implement OS_CallASWIR12 (needed for PFORTH)

PFORTH runs on the ARM7TDMI
http://www.stardot.org.uk/forums/viewtopic.php?f=29&t=6785

On PiTubeDirect we get:
SWI 00020071 not implemented ************
00020004 80000000 002ffd88 00000004

Switch to hardware mailboxes for the delivery of tube mailbox message

Some thoughts on this....

Goal:

• increase performance
• allowing emulators to stay in a continuous loop (without the need to poll)
• make the multi-core and GPU interactions with the emulator look the same

Still need to find the address of the mailbox hardware on the GPU side

Make this one directional - detect overruns with a 4-bit sequence counter

New ISR on emulator side would:

• listen on hardware mailbox interrupt
• call tube_io_hander() C code to update tube state as quickly as possible
• test for an exception condition (reset, tube NMI, tube IRQ)
• call emulator provided exception callback to deal with reset, NMI, IRQ

I'm not so sure about the last point. It sounds good, but the emulator would have to be written to allow the callback to be called asynchronously. Which might end up anyway with the emulator still needing to poll for interrupts.

The fast 6502 "r12/ip" trick would still be possible.

Native ARM Co Pro Cache consistency issues on all Pi Models

Looks like we also need to purge the instruction cache....

On my test image I have two versions of BAS135 - that differ slightly (one has a module header, the other doesn't):
bas135.zip

To reproduce this issue, do the following:

*FX 151,230,15
<Ctrl Break>
*DIN 14
BAS135
quit
*DIN 15
BAS135

At this point it will generally crash.

What's happing is that the first version of BAS135 is not being purged from the instruction cache when the second version is loaded things go wrong.

80286: BBC Basic trig is wrong

I'm guessing this is a 286 core emulation bug, although it could possibly be a bug in BBC Basic.

PRINT SIN(2)
1.00140532
PRINT COS(0.7)
1.00984219

(We know these values are wrong because they are greater than one.)

Found by running

CD BBCBASIC
BBCBASIC
CHAIN"SINE"

Native ARM Co Pro command processing issues on multi-core Pi's

Several weird things on the multi core Pis:

*HELP ARM doesn't show detailed errors

*MEM

shows the wrong address

*GO

doesn't go to the right address

32016: Escape is not reliably detected in BAS32

A simple loop like:
FOR A=1 TO 1000000:NEXT
cannot be interrupted.

Native ARM Co Pro: SAVE from withing BAS135 hangs

On a model B it hangs

On a master you get a "Bad Name" error

Looking a debug trace, it seems the filename ptr (R1) is getting corrupted:
SWI 0000000e complete cpsr=60000113
SWI 00000007 called from 0001cfe8 cpsr=60000193
SWI 00000007 complete cpsr=60000113
SWI 00000008 called from 0001cffc cpsr=60000193
00000000 31206265 fffffbff 00000003 00008f00 00008f10

R1 is incorrect (it has value "1 be") which is part of the TIME string:

Looking at the code:
https://github.com/hoglet67/PiTubeClient/blob/master/bbc_basic_1_35/s.Command#L1112

SAVEFIL
        LDR     R4,[ARGP,#PAGE]
        LDR     R5,[ARGP,#TOP]
        MVN     R2,#0
        SUB     R2,R2,#&F00-&B00
;save date stamped file [R1] of type R2 from R4 to R5
SAVEFILECLRSTK
        STR     R1,[SP,#-4]!
        MOV     R0,#14                 ;fetch date stamp
        SUB     R1,SP,#8
        MOV     R3,#3
        STR     R3,[R1]
        STR     R2,[R1,#4]
        SWI     WORD
        MOV     R0,#0
        LDR     R2,[R1,#4]
        LDR     R3,[R1]
        LDR     R1,[SP],#4
        SWI     FILE

I wonder if the stacked R1 is being corrupted by OS_WORD?

(NS32k) Check unaligned write_x64

The 64 bit read has been modified as the ARM does not support reading 64 bits non-aligned in one go.

The 64 bit write has not been modified however.

Can the Raspberry Pis support writing 64 bits non-aligned?

If not the write_x64 can cause a crash.

Lib6502 Co Pro: Basic crashes when events enabled

This problem is present in the Boa release.

It is still there in the latest Cobra-dev code.

10 FOR A=1 TO 100000
20 NEXT
30 GOTO 10

This runs fine.

Now enable VSync events (*FX 14,4)

> RUN
Syntax error at line 20
>

(I stumbled across this when trying to find a reproducible test case for #50)

Boot time degradation

There is anecdotal evidence that the PiTubeDirect boot time has degraded recently, such that the Master no longer recognises the Co Pro on power up. This was reported by Mark Haysman in #58.

To try to quantify this, I'm running this program on the Beeb:

10 P%=&2000
20[
30 LDA &FEE0
40 JMP &2000
50]
60 CALL &2000

I've got a scope hooked up to the Pi's reset switch, and also to GPIO Pin 24 (D0). This provides a clear indication of how long after reset is released it takes for the Pi to start responding to read requests from the Beeb.

My Master probe's the tube 918ms after power on (measured from VCC reaching 4V). This will probably vary between Masters.

All the SD Cards are freshly formatted with the SD Card Association formatter.

I'll start using my Sandisk Ultra 8GB Class 10 Card and a Pi Zero v1.3:

• 1156/1024ms - Anaconda
• 1160/1023ms - Boa
• 924/798ms - Cobra
• 930/800ms - Diamondback
• 1084/952ms - Egg Eater (rc0)

The first number is the boot time when the SD Card has just been inserted. The second number is the boot time on subsequent reboot cycles.

Note, none of these are recognised on first power up of the Master.

To understand if the SD Card makes a difference, here is the boot time of Diamondback with three different cards:

• 930/800ms - Sandisk Ultra 8GB Class 10 (as above)
• 732/576ms - OV 8GB Class 6
• 812/744ms - Sandisk 4GB Class 4

Out of these cards, the Sandisk Class 10 is not recognised on Boot in my Master, where as the other two are.

Staying with the OV Card, and using the Diamondback release, try different firmware blobs

• 732/576ms - firmware blob released with Diamondback
• 880/726ms - firmware blob released with EggEater
• 882/728ms - current firmware blob, as of 24/7/2018

Staying with the OV Card, and using the EggEater release, try different firmware blobs

• 734/584ms - firmware blob released with Diamondback
• 884/732ms - firmware blob released with EggEater
• 886/732ms - current firmware blob, as of 24/7/2018

So this demonstrates a Firmware Blob change between Diamondback and EggEater has slowed boot down by ~150ms.

Finally, comparing with a Pi Zero and a Pi Zero W:

Pi Zero:

• 732/576ms - original firmware blob released with Diamondback
• 882/728ms - current firmware blob, as of 24/7/2018

Pi Zero W:

• 782/584ms - original firmware blob released with Diamondback
• 1030/787ms - current firmware blob, as of 24/7/2018

Conclusions:

1. The firmware blob changes post Diamondback have slowed boot by ~150ms
2. The Pi Zero W is slower to boot that the Pi Zero, by 50-150ms (depending on the firmware)
3. The sum of (1) and (2) causes my Master to not see the Co Pro on boot
   4.The PiTubeDirect kernel has little effect on Boot time between Diamondback and EggEater

Next step is to bisect the firmware blob to see which commit added 150ms.

Native ARM Co Pro: SYS OS_GetEnv to A$ does not return invocation string

SYS "OS_GetEnv" TO A$:PRINT A$ should return the command line used to invoke Basic.

It doesn't.

Here's the current implementation:
https://github.com/hoglet67/PiTubeDirect/blob/boa-dev/src/tube-swi.c#L673

Dave

80286 - propose consistent renaming as 80186

We emulate a 186, which is accurate for emulating the Master 512, but because of a quirk in the ROM and the handling of tube transfers, it is detected and reported as a 286. We've been referring to 286 in talking about it.

It might be better to tweak the ROM we use, accurately report as a 186, and consistently refer to it as a 186. We just need to arrange to use NMI for data transfers - assuming this is something which only the ROM needs to know about.

The client ROM was coded to support both a 186 and a 286, the difference being:

• the 186 uses DMA for data transfers
• the 286 uses NMI for data transfers

Now, NMIs were much easier to work with than having to implement (or emulate) the 186's DMA hardware. So we need the CPU to be detected as a 286 (which depends on a some subtlety of how a certain thing that escapes me is pushed onto the stack).

But no 286 instructions are ever used, and all master 512 software is 186 compatible.

lib6502 can ignore reset

The lib6502 model, in the gpu branch, deals with reset in the interrupt handling. If interrupts are disabled with SEI the model will not respond to the reset signal from the host.

Native ARM Co Pro: Implement additional APIs

Not all the APIs that BBC Basic uses are currently implemented.

(Updated 7/9/2021)

There are implemented:

(Operating System)
00      WRITEC
01      WRITES
02      WRITE0
03      NEWLINE
04      READC
05      CLI
06      BYTE
07      WORD
08      FILE
09      ARGS
0A      BGET
0B      BPUT
0C      MULTIPLE (aka GBPB)
0D      OPEN (aka FIND)
0E      READLINE
10      GETENV
11      EXIT
16      ENTERSWI (aka EnterOS but check usage)
1C      MOUSE
2B      GENERATEERROR
31      READVDUVARIABLES                                used in A=VDU(x)
32      READPOINT                                       used in A=POINT(x,y)
39      SWINUMBERFROMSTRING                             used in SYS and assembler
20040   XOSCHANGEENV
20045   XOSPLOT
46      WRITEN
65      SCREENMODE
2006E   XOSSYNCHRONISECODEAREAS
100     WRITEI

(Operating System Modules)
40743   COLOURTRANSSETGCOL
40761   COLOURTRANSSETTEXTCOLOUR
62C81   BASICTrans_Error
62C80   BASICTrans_HELP
62C82   BASICTrans_Message

These are not implemented:

(Operating System)
2001E   XOS_Module                                      used in modHead.s
23      READVARVAL                                      used to read BASIC$crunch)
61      SETCOLOUR                                       used in COLOUR OF <colour num> ON <colour num>
DC      OS_ConvertInteger4                              used in module MOVEMEMORY

(Operating System Modules)
40140   SOUNDCONFIGURE
40141   SOUNDENABLE
401C6   SOUNDEVENTQBEAT
401C1   SOUNDEVENTQSCHEDULE
401C5   SOUNDEVENTTEMPO
40142   SOUNDSTEREO
4018A   SOUNDVOICE
4305F   Territory_ReadCalendarInformation
400EC   WIMPSLOT

A stretch goal might be to reach parity with Sprow's ARM7TDMI Co Pro:
http://www.sprow.co.uk/bbc/hardware/armcopro/armtubeoscalls.pdf

For GCOL syntax, see here

Add a minimal cmdline.txt to the release package

This was omitted by accident from the anaconda release.

Dave

Type 6 transfers are not working

See this post, which includes a test case:
http://stardot.org.uk/forums/viewtopic.php?p=159143#p159143

32016 Co Pro sometimes not recognised on reset

Tested with current master code using a Pi Zero on a Master 128

Approx 50% of the time the Co Pro is not recognised.

Investigate issue with Null Co Pro

http://www.stardot.org.uk/forums/posting.php?mode=quote&f=3&p=153107#pr153107

Possibly two issues:

• jms2 reported copro=14 was ignored in cmdline.txt
• for me it work, but once in Co Pro 14, you can't switch back again, and reset isn't being seen

32016 Co Pro: BAS32F/CLOCKSP gives a data abort exception

Mount Pan141a.ssd as drive 0 and Pan141b.ssd as drive 2.

There are two versions of BBC Basic:

:0.$.BAS32 - this is BBC Basic IV for the 32000, version 1.00/13 for the

:2.$.BAS32F - this is a different version that makes use of the FPU

Pi Zero @ 1000MHz: BAS32 - CLOCKSP gives 21.11MHz

Pi Zero @ 1000MHz: BAS32F - CLOCKSP gives 81.95MHz

Pi 3 @ 1200MHz: BAS32 - CLOCKSP gives 34.55MHz

Pi 3 @ 1200MHz: BAS32F - CLOCKSP gives a hard crash:

Data Abort at 01F32AA0 on core 0
Registers:
r[00]=00007DB1
r[01]=023A4130
r[02]=00000000
r[03]=023A4298
r[04]=00000000
r[05]=00000000
r[06]=023AC049
r[07]=0003C4BE
r[08]=023A428C
r[09]=03986698
r[10]=023A4290
r[11]=023A40C8
r[12]=023A4294
r[14]=01F32AA8
Memory:
01F32A90=8A000004
01F32A94=E3043298
01F32A98=E340323A
01F32A9C=E0866003
01F32AA0=E1C640F0 <<<<<<
01F32AA4=E8BD83F8
01F32AA8=E3560601
01F32AAC=E2868001
01F32AB0=E6EF7072
Flags:
NZCV--------------------IFTMMMMM
10000000000000000000000100010011 (Supervisor Mode)
Halted waiting for reset

This is:

01f32a74 <write_x64>:
1f32a74: e92d43f8 push {r3, r4, r5, r6, r7, r8, r9, lr}
1f32a78: e1a05003 mov r5, r3
1f32a7c: e30f3ff8 movw r3, #65528 ; 0xfff8
1f32a80: e3c064ff bic r6, r0, #-16777216 ; 0xff000000
1f32a84: e340300f movt r3, #15
1f32a88: e1a04002 mov r4, r2
1f32a8c: e1560003 cmp r6, r3
1f32a90: 8a000004 bhi 1f32aa8 <write_x64+0x34>
1f32a94: e3043298 movw r3, #17048 ; 0x4298
1f32a98: e340323a movt r3, #570 ; 0x23a
1f32a9c: e0866003 add r6, r6, r3
1f32aa0: e1c640f0 strd r4, [r6]

So it looks like there may be some alignment constraints on the Pi 3 that are not present on the Pi Zero.

Native ARM Co Pro: Implement OSWORD A=&0E/&0F sub-reason codes

These are extensions to allow the real time clock to be read in different formats.

Specifically, Basic uses sub-reason code 3 to read time as a 5 byte integer (centi-seconds since start of 1900).

See also #36 for context.

Different speeds between Zero and Zero-W

Hi.

I've been trying the standard Zero v1.3 and the Zero-W v1.1, and the W, according to the Native ARM core, and the ClockSP tests seems to be coming from the suppliers clocked at 700Mhz, rather than the 1GHz that the regular Zero does. Is this a known thing for the firmware? Is it picking up the different Zeros, or are the CPUs on the W genuinely running at 700MHz, even though the suppliers say they're meant to be clocked to 1Ghz?

Thanks, Mark.

First Pic - Zero-W, second pic, standard v1.3 Zero

Native ARM Co Pro: *BAS135 CLOCKSP throws an exception

Data Abort at 0001C1B8
Registers:
r[00]=00008F00
r[01]=001FF19E
r[02]=00000010
r[03]=00000010
r[04]=00000A3A
r[05]=001FFBD8
r[06]=000000FF
r[07]=001FFBD6
r[08]=00008700
r[09]=00000002
r[10]=00200000
r[11]=01F44098
r[12]=00008100
r[14]=0001C1C0
Memory:
0001C1A8=E2112003
0001C1AC=0A000009
0001C1B0=E1A02182
0001C1B4=E2623020
0001C1B8=E89100C0 <<<<<<
0001C1BC=E1A06236
0001C1C0=E1866317
0001C1C4=E4806004
0001C1C8=E2811004
Flags:
NZCV--------------------IFTMMMMM
00100000000000000000000100010000 (User Mode)
Halted waiting for reset

Native ARM Co Pro: ARM client should handle ROM-like header

See http://stardot.org.uk/forums/viewtopic.php?p=160379#p160379

80286 Co Pro fails to boot with Ctrl-Break

The following is logged to the serial console:

Illegal opcode: 67 @ 0000:0DE2

Pressing break and typing DOS at the * prompt works OK.

80286 - oddities in DAA, DAS, PUSHF, and opcode 0B

dp111 has been looking through the code and noted some suspicious findings. In the absence of tests, and in preference to lots of new tickets, I though we could perhaps list them here. Or, we can delete this and raise new tickets.

1. DAA probably wrong "as we aren't using the old value of AL or CF"
2. pushf "appears to set the overflow flag"
3. We don't need to support the 286 instruction set, so is this code we need or want?

      case 0xB: /* 0B OR Gv Ev */
        modregrm()
        ;
        oper1 = getreg16(reg);
        oper2 = readrm16(rm);
        op_or16();
        if ((oper1 == 0xF802) && (oper2 == 0xF802))
        {
          sf = 0; /* cheap hack to make Wolf 3D think we're a 286 so it plays */
        }
   
        putreg16(reg, res16);
      break;
   

NS32K: Reset behaviour differs from real Co Pro

On a real Co Pro, if you have loaded BAS32 and then hit soft break, you end up back at Basic's > prompt.

On PiTubeDirect you end up back at Pandora's * prompt.

i.e. we have lost the concept of a current language that persists across soft breaks.

I suspect this is down to:

void n32016_reset()
{
   n32016_reset_addr(0xF00000);
}

In the real hardware, the reset address is 0x0, and the ROM is temporarily paged in over the top of this.

Debugger: Deadlock if a key is pressed while serial tx buffer is full

For example:

On the Beeb, select the Z80 Co Pro:

*FX 151,230,4
<Ctrl break>

On the debugger, set an IO Read watchpoint on all IO activity:

>> WATCHI 0 0

At this point there a large volume of watch messages. The 64K serial output buffer fills, and the Co Pro context starts to block here:
https://github.com/hoglet67/PiTubeDirect/blob/cobra-dev/src/rpi-aux.c#L146

On the Beeb, if you enter *HELP it will run slowly.

As soon as you hit a key in the debugger, the system deadlocks.

Native ARM Co Pro: won't run FPA code e.g. BASIC64 AKA FBAS135

Running FBAS135 results in the Pi hitting a native exception, because the Pi supports VFP for floating point but code for earlier ARMs uses FPA. See here.

SWI 0002006e not implemented ************
Undefined Instruction at 0000F3BC

The offending instruction is "WFS r0" which is a write to the floating point status register.

This has been mentioned on stardot, see here.

[Thanks to Dave for explaining this]

The only option here would be to look for some code to emulate FPA, and add it in to the Undefined Instruction exception.

32016 Core Bug "invalid shift" running CLOCKSP

Also during BAS32/CLOCKSP we get overruns and repeated characters on the screen.

Cause seems to be the logging of a 32016 Core Bug:

tube reset - copro 13
pc=00005EC5: Invalid shift of 000000DF for size 32
pc=00005EC5: Invalid shift of 000000DF for size 32
OVERRUN: A=1; D=20; RNW=1; NTUBE=0; nRST=1
OVERRUN: A=1; D=20; RNW=1; NTUBE=0; nRST=1
OVERRUN: A=1; D=20; RNW=1; NTUBE=0; nRST=1
OVERRUN: A=1; D=36; RNW=1; NTUBE=0; nRST=1
OVERRUN: A=1; D=39; RNW=1; NTUBE=0; nRST=1
OVERRUN: A=1; D=2E; RNW=1; NTUBE=0; nRST=1

Occurs in master and gpu.

A shift of &DF is -32 is outside the range specified here:
http://cpu-ns32k.net/files/ismanual.pdf

Probably we should relax this warning.

Native ARM only offers 2MByte of RAM

If I'm not mistaken, the Native ARM model offers just 2M, whereas the emulated ARM2 offers a historically credible 4M and Sprow's ARM7TDMI board was sold with up to 32M and supported up to 64M. Is there room for a bump in RAM for Native ARM?

6809 Basic hangs on Escape

confirmed in latest boa-dev

• git version: cd01f82

(Even though this change landed in Anaconda:
Synced 6809 Tube ROM with the lastest from JGH
)

32016: Tune down invalid shift warning

During CLOCKSP on the Pi 3 (trig test) we see:

pc=00005EC5: Invalid shift of 000000DE for size 32

followed by OVERRUNs.

Just get rid of this warning.

Dave

No circuit diagram for breadboard DIY two-chip level shifter

I can't seem to find the wiring diagram for this anywhere in the wiki or code.

Type 2/3 transfers are not working

See this post, which includes a test case:
http://stardot.org.uk/forums/viewtopic.php?p=159143#p159143

32016: Rounding error when printing certain integers

For example:
@%=0
PRINT 64

should print 64 but currently prints 63.99999998

This seems to be a regression introduced in 7571274

Reset debounce code not working well in gpu branch

On the Master 128 (clean reset pulse) there are no issues.

On the Model B (lots of reset bounce) the Co Pro boot message is frequently garbled, especially on the larger Co Pros (though for some reason 65tube seems fine).

Quick test of the current master branch code suggests this is specific to the gpu branch.

Native ARM - Moving towards better structured kernel workspace

I'm not sure if this should be written up as an issue in the absense of anywhere looking like a "discussion" area. Feel free to close this and move the discussion to a more appropriate place.

A lot of the ARM kernel code has hardwired bits in at the moment. Some things will need to move to being vectors/buffers/etc. For instance, for GetEnv/SetEnv/WriteEnv and friends to work the environment string needs to be a copy of the string used, not a pointer to the string used. Several issues, including: the passed string will in user space and may be stomped on by another program loading over it, it has to be considered read-only (eg is could be a line in the middle of a BASIC program) and parts of Execute need to modify the string, etc.

Today I've been digging through notes from the Matchbox development and digging through our real-world reference hardware: the Acorn ARM Eval System, the Sprow CoPro and RISC OS itself.

At a general level, an ARM system is laid out like this (ignoring relocation for the moment):
...ARM memory layout
0000 +------------+
.....|..Hardware..| Should
0100 +------------+ be
.....|...Kernel...| read-only
1000 +------------+ in
.....|.Operating..| USER
.....|..System....| mode
8000 +------------+
.....|...User.....|
.....|............|
.....//////////////
(sorry, I still can't get these code blocks to work properly)

'AB' (ARM BASIC 1.00) is an example of a program that runs in a kernel-only environment loading to &1000, like running Bas32 on PanOS without booting Pandora, or BasicZ80 on Z80Tube without booting CP/M. RISC OS-y type code such as the ARM BASIC module (BASIC 1.05 and later) run in high memory with 8000 as the bottom of user memory.

I'm still digging through code and documentation to more fully draft up kernel workspace layout recommendations, but based on the reference hardware I recommend starting by moving towards this:
Initial layout:
&0000-FF Hardware entries and vectors
&0300-FF Debugger workspace
&0E00-FF Environment buffer and Error buffer
&0F00-EF Supervisor input buffer
&0FFB-FF Environment time (move this later on)

This gives us a start to getting GetEnv and friends working, SetEnv and OSCLI copy the command line (stripped of leading stars/spaces/'RUN') to &0E00 and the start time to &0FFB-&0FFF, Execute is able to modify it to swap in a module name, GetEnv returns R0=&E00, R1=ramtop, R2=&FFB.

I'm also looking through my module handling code to work out where things need to go to a module handler to hook in.