BBC BASIC on the 65816

[BigEd]

ah, good point, I didn't even think of a limit for each array.

[dominicbeesley]

The Sigma Experiment does look to work (after skipping the stuff that messes with PAGE)...not that I've managed to get anywhere with it...

[paulxtr]

PiTubeDirect doesn't (yet) have a 65816 Co Pro, but I might try and port the code over from B-Em if there is any interest. It might then be possible to add a debugger, which would help folk developing new software.

Hi Dave,

I already have one of John Kortink's ReCo65816 coprocessors but would also be very interested in a PiTubeDirect 65816 Co Pro.



Cheers,
Paul

[dominicbeesley]

Hoglet, if you do start on a 65816 tube for the PiTube do give me a shout. Attached is the code for my quickndirty client rom I did 5 or so years ago.

It looks like I made the native vectors appear in bank 1, probably not the best idea, I'd not do that now (I'd probably go for placing them at FEEx instead). The rest looks pretty standard but I think I'd be tempted to make the client rom appear in bank0 during boot then switch it and the hardware registers up to bank FF - that would free up precious bank 0 space - we'd still need MOS entry points and vectors in bank 0 but that could be ram with relevant stuff copied in?

Caveat: I stopped working on this around 5 years ago when we moved house - I may have left it in a broken state. I am willing and eager to help if it needs fixing up. I've no idea whether my old 65816 board will work...it was a bit Heath Robinson to say the least as I'm sure you remember:

https://github.com/dominicbeesley/65816_tube_altera
viewtopic.php?f=3&t=9975

Still the code is probably a starting point and I should be able to get it into a much more usable state with the experience gained recently

D

[hoglet]

Hoglet, if you do start on a 65816 tube for the PiTube do give me a shout.

I made a bit of a start on on this earlier today, by porting across the 65816 Co Pro implementation from B-em.

Here's it running in PiTubeDirect:

capture26.png

And with debug support:

Screenshot from 2020-12-08 13-06-26.png

Attached is the code for my quickndirty client rom I did 5 or so years ago.

It looks like I made the native vectors appear in bank 1, probably not the best idea, I'd not do that now (I'd probably go for placing them at FEEx instead). The rest looks pretty standard but I think I'd be tempted to make the client rom appear in bank0 during boot then switch it and the hardware registers up to bank FF - that would free up precious bank 0 space - we'd still need MOS entry points and vectors in bank 0 but that could be ram with relevant stuff copied in?

Caveat: I stopped working on this around 5 years ago when we moved house - I may have left it in a broken state. I am willing and eager to help if it needs fixing up. I've no idea whether my old 65816 board will work...it was a bit Heath Robinson to say the least as I'm sure you remember:

https://github.com/dominicbeesley/65816_tube_altera
viewtopic.php?f=3&t=9975

Still the code is probably a starting point and I should be able to get it into a much more usable state with the experience gained recently

Thanks for this, I had forgotton you had done some work on this.

I've committed it to the gecko-dev branch, which is where we are curretly working:
https://github.com/hoglet67/PiTubeDirec ... om_dominic

So now PiTubeDirect has two new Co Pros:
- CoPro 18 - a 65816 with the ReCo65816 client ROM
- CoPro 19 - a 65816 with the Dossytronics client ROM

The latter needs a bit of debugging, I expect because of hardware differences betwen ReCo65816 and your Altera DE0 implementation. It boots, but then crashes after the first command:

capture27.png

I'll have a play later.

Dave

[hoglet]

That's a bit better:

capture28.png

I'm pretty sure it was a bug in the 65816 CPU Emulation (of the XCE instruction):
https://github.com/hoglet67/PiTubeDirec ... t/c7dea32c

Next issue is interrupts hang, which I expect is down to the lack of high vectors.

Dave

[BigEd]

Splendid! I suppose it's managing an average of about 30MHz?

[dominicbeesley]

Cool! What does it do with native vectors ATM? I can always tweak the client ROM to work that way. I can't quite remember how I did the address mangling on the board but IIRC it was in some sort of programmable logic so it should be easy enough to make that work the same way. I've gone right off doing it in Bank1 now!

D

[hoglet]

Cool! What does it do with native vectors ATM? I can always tweak the client ROM to work that way. I can't quite remember how I did the address mangling on the board but IIRC it was in some sort of programmable logic so it should be easy enough to make that work the same way. I've gone right off doing it in Bank1 now!

I've just pushed a few fixes.

They include now fetching the native interrupt vector from bank 1.

The other issue is the emulator implements the banking model of ReCo65816, which is a bit different to yours.

Changes here:
https://github.com/hoglet67/PiTubeDirec ... 0a59f81537

A step in the right direction:

capture29.png

CLOCKSP is slower than before because the debugger is enabled.

It's still a bit crashy, which needs further investigation.

Dave

[dominicbeesley]

I'll try and make another build target of 816 basic for this too

D

[dominicbeesley]

Is there any documentation for how the reco65816 works in hardware api terms?

[hoglet]

Is there any documentation for how the reco65816 works in hardware api terms?

The below is from the documention John provides:
http://www.zeridajh.org/hardware/reco6502/updates.htm

Hardware registers

There are four hardware registers, named 'default', 'divider', 'banking' and 'banknum'. They are all shift registers, i.e. they are written to one bit at a time (although you will not notice that if you use the utility code to write to them, because you then simply pass a value, refer to 'Programming interface' for details).

All registers are write only, and appear at address &FEF0. A 3-bit value is written. The register is selected by bits 2-1 (0, 1, 2, 3 respectively for 'default', 'divider', 'banking' and 'banknum'), and the value of bit 0 is written into the most significant bit of the selected register, while shifting 'down' the old value (similar to a 6502 'ROR' instruction where C is set to the value of bit 0).

'Default' (a 1-bit register), when set to 1, will suppress the effects of all other registers' values, so they can be updated safely. Specifically, it will force the processor clock to 'slow' (which is fixed at 3.15 MHz, making the value of 'divider' irrelevant), and implicitly force 'banking' to '1000' (disabling all banking, and enabling the ROM). When 'default' is set to 0, the values of all other registers become effective again.

'Divider' (a 4-bit register), selects the 'fast' processor clock frequency :

Code: Select all

Value	Frequency
0	22.1184 MHz
1	14.7456 MHz
2	11.0592 MHz
3	8.84736 MHz
4	7.37280 MHz
5	6.31954 MHz
6	5.52960 MHz
7	4.91520 MHz
8	4.42368 MHz
9	4.02153 MHz
10	3.68640 MHz
11	3.40283 MHz
12	3.15977 MHz
13	2.94912 MHz
14	2.76480 MHz
15	2.60216 MHz

Note that, regardless of the 'fast' processor clock frequency, the Tube ULA is always accessed in 'slow' mode (3.15 MHz).

'Banking' (a 4-bit register), decodes as follows :

Code: Select all

bit 3 : ROM enable
bit 2 : 65C816 banking enable
bit 1 : banking enable for address window 2 (0x8000 through 0xBFFF)
bit 0 : banking enable for address window 1 (0x4000 through 0x7FFF)

To enable the ROM, set bit 3 to 1 (but note that you may have to switch to a lower processor clock frequency first, because the ROM allows only relatively slow accesses). The ROM will appear at addresses 0x8000 through 0xFFFF.

To enable 65C816 linear addressing (where bits 18 through 16 of the address are conveyed via the databus), set bit 2 to 1.

To enable bankswitching for address window 2 and/or 1, set bit 1 and/or 0 to 1 respectively. When bankswitching is enabled, you can use the 'banknum' register to choose which one of 8 different banks of 16 KB appears in the address window. When bankswitching is disabled, this is always 'bank 0'.

'Banknum' (a 6-bit register), decodes as follows :

Code: Select all

bit 5-3 : number of the bank appearing in address window 2
bit 2-0 : number of the bank appearing in address window 1

Refer to the description of the 'banking' register for more details.

[Pernod]

Is there any documentation for how the reco65816 works in hardware api terms?

If anything's not clear then I may be able to help, as John K answered a few questions I had when I emulated the ReCo65816.

[dominicbeesley]

Hi Hoglet,

Would it be possible to get a pre-built image (or whatever's needed to copy onto my sd card) for a PiZeroW so I can have a play with this? I've not got access to the required tools to build at the moment but I can do the BASIC port.

If not I'll try and get the build tools working at this end on WSL.
1st dumb question: The wiki says to run "./configure_rpizero.sh" but that is missing from Git, what to do?

[hoglet]

Would it be possible to get a pre-built image (or whatever's needed to copy onto my sd card) for a PiZeroW so I can have a play with this? I've not got access to the required tools to build at the moment but I can do the BASIC port.

Sure, here's a current build:

PiTubeDirect_20201209_1710_dmb.zip

I've fixed a couple of things today and the Dossytronics client now seems very stable.

Do take a look at the git history:
https://github.com/hoglet67/PiTubeDirec ... /src/65816

If not I'll try and get the build tools working at this end on WSL.
1st dumb question: The wiki says to run "./configure_rpizero.sh" but that is missing from Git, what to do?

Sorry, that was the wiki lagging behind reality. The Pi Zero now uses the same kernel as the Pi One.

I've corrected the wiki.

Dave

[dominicbeesley]

Cool! Thanks! Just quickly tried that and it works. Looks like I've got it building on WSL too!

I've been looking through the client code and it looks like I'll be making a few changes if you don't object:

"Long" MOS entry points
I'd got most of the MOS entry points to be Native/Emulation mode agnostic (at least it looks that way - memory is a bit vague). What I'd not done is make a set that can be entered with JSL - that precludes calling them from code not in bank 0! I propose a second set of entry points at FExx (or something) unless someone has a better idea?

"Long" OS Vectors
The normal BRKV..IND3V but allowing for 24bit pointers - maybe at $240 onwards. The default for the 24bit vectors is to call the 16bit vectors. BRKV may need some thought as I can't work out how to get the program bank of the BRK instruction if running in emulated mode. For now I'll just assume bank 0?

More to come tomorrow...

[hoglet]

I've been looking through the client code and it looks like I'll be making a few changes if you don't object:

No objection from me; it's your baby!

BRKV may need some thought as I can't work out how to get the program bank of the BRK instruction if running in emulated mode. For now I'll just assume bank 0?

As far as I understand, it's impossible (i.e. this information is lost when PB is set to bank zero).

The same applies for an interrupt in emulated mode.

So I think assuming bank zero is reasonable in these case.

More to come tomorrow...

I noticed another thing this morning.

If you do a Ctrl-BREAK, CmdOSLoop is executed in Native mode.

If you then do a normal-BREAK, CmdOSLoop is executed in Emulated mode.

Looking at the code, I can see why this is the case. Normally it wouldn't matter, but the native mode BRK vector was still being fetched from bank 0. So pressing ESCAPE caused a hang.

Dave

[BigEd]

(It feels to me that native mode OS facilities should always be JSL entrypoints, as native mode apps will always have lots of high memory available and are moderately likely to be running in high banks. No advantage in providing JSR entry.)

BTW, I think I'm right in saying that an OS convention - like the one used for sideways RAM - could make the program bank byte available for emulation-mode BRK and interrupts. But I don't think it's worth it, once we have a system which supports native mode.

[dominicbeesley]

I'm now coming round to the idea of using COP calls - I'm going to have a crack at it today. It should hopefully mean that I can rid most of the core BASIC code of differences for the blitter/beeb816/tube versions other than the shims. If it looks promising I'll publish a proposed API - I was thinking of the Communicator API but the more I look at it the more it just feels wrong and too unMOSsy?

One thing I'm not sure about is whether/how to change/augment OSBYTEs 83,84

JGH has an extended API to return bit7 of A clear and the 24 bit address for MEMTOP/MEMBOT in AYX. However, that doesn't give the full story, there's a wodge of MOS code and hardware registers at F000-FFFF so maybe have 83, 84 return free space in bank 0 and a new API to return memory above bank 0. So, the Blitter would return 010000-1EFFFF free, beeb816 C00000-C80000?, Tube 010000-0FFFFF? (Not sure of the exact memory specs of the Tubes and beeb816)

D

[BigEd]

This might be a terrible idea, but... for free memory we now need to know two things: free space in bank 0 and free high banks.

If we assume high banks are completely free, we only need the top byte for that. So returning
low=C01900
high=C37C00
would mean (by strict convention)
Bank 00 is free from 1900 to 7C00
Banks C0 through to and including C3 are completely free.

But I don't know if this fits within Jonathan's extended 24 bit idea.

[hoglet]

But I don't know if this fits within Jonathan's extended 24 bit idea.

This is not just an idea, it's what the original Acorn 256K Turbo Co Pro actually does....

Code: Select all

   On exit X and Y point to the first byte after the top of user memory,
   used to initialise BASIC's 'HIMEM'. If b7 of A is clear, then A:Y:X
   holds the 23-bit address of the top of user memory, as when running
   6502Turbo code on a CoProcessor, which returns A=&04, XY=&0000.

You can see the Turbo extensions in the original code here:
https://github.com/stardot/Acorn6502Tub ... /Tos02#L60

Dave

[dominicbeesley]

Thanks both,

That's an idea but doesn't quite fit in with how the blitter works. There's a heap at the top of ChipRAM that grows downwards so not entirely on bank boundaries, though I could finagle it down to the nearest bank boundary.

Does the 6502Turbo copro also have stuff "in the way" so and do you know what it reports?

D

[hoglet]

Does the 6502Turbo copro also have stuff "in the way" so and do you know what it reports?

It side-steps the issue by ignoring bank 0:
- OSBYTE &83 returns A=&01, X=&00, Y=&00 (== 0x010000 = 64KB)
- OSBYTE &84 returns A=&04, X=&00, Y=&00 (== 0x040000 = 256KB)

i.e. The region between the two is uninterrupted.

[dominicbeesley]

Ah, bugger! I'd like something that also gives us both a bank0 free map and a high memory free map, which Ed's suggestion does do but with a coarser grain for high memory. I'll cogitate a bit further.

Which BASIC should I be using with the Turbo copro on a model B?

D

[hoglet]

Which BASIC should I be using with the Turbo copro on a model B?

Allegedly there once was a "Turbo Basic" but this has yet to be re-discovered.

[BigEd]

Hmm, this is difficult. There are two ranges to consider and not enough space to specify them both! The Turbo idea seems to be that it you are a Turbo app, you only get to play in the higher banks.

We can't quite say the same: our native apps will need some bank 0 space, surely, if only for buffers to communicate with the OS.

Pessimistically we could perhaps say that native apps get everything from &2000 to &2FFF - that's the highest likely PAGE and lowest likely HIMEM.

But I think it'd be better if we did have a way for the OS to tell the application about both regions, somehow.

(Using my scheme, if an app accidentally interprets the two numbers as being actually the PAGE and HIMEM, it just gets less than it would have - it doesn't get anything it shouldn't get.)

That said, it might not work for Dominic's blitter. Is it possible for that heap to get a bank to itself?

[dominicbeesley]

Hi,

I've been having a look at the tube code and it really needs a bit of fixing up before it will be usable:
- Data transfers to be 24 bit, so we can load to banks other than 0
- Native BRK handler
- Fix up what is happening with BREAK/CTRL-BREAK. (I think I have a fix for this)
- Ideally, change the PiTubeDirect emulation to use my banking registers (I will have to dig out my VHDL code and see how it works but I think it was a lot simpler than JK's and doesn't pollute bank 1)
- Make the tube OS soft-loadable (I had it working at some point but can't remember now how...it might have been on the 6809).

Some probably dumb questions:
- what's the quickest way to (re)build for the Zero, should this work?
First time

Code: Select all

cd scripts
./configure_rpi.sh
make -B -j 4

Subsequent

Code: Select all

make -j 4

I'm guessing I should then just copy the build kernelrpi.img to my sd card?

Am I missing some make magic that is translating the binary of the tube client to a .c file. I can see

Code: Select all

%.inc: %.bin
	xxd -i -c 16 $< > $@
	cp $@ ../$*.c

In the tube client make file but that doesn't give a valid C file, did you just edit the C declaration bit on by hand or is there a part of the build that does that?

D

[hoglet]

I'm guessing I should then just copy the build kernelrpi.img to my sd card?

Yes, that's pretty much it.

Am I missing some make magic that is translating the binary of the tube client to a .c file. I can see

Code: Select all

%.inc: %.bin
	xxd -i -c 16 $< > $@
	cp $@ ../$*.c

In the tube client make file but that doesn't give a valid C file, did you just edit the C declaration bit on by hand or is there a part of the build that does that?

This step is manual at the moment.

You need to cd into the tuberom_dominic directory and type make.

That should run the following commands@

Code: Select all

rm -f *.o *.lst *.bin *.inc *~
ca65 -l tuberom_dominic65816.as.lst tuberom_dominic65816.as
ld65 tuberom_dominic65816.o -o tuberom_dominic65816.bin -C tuberom_dominic65816.lkr
xxd -i -c 16 tuberom_dominic65816.bin > tuberom_dominic65816.inc
cp tuberom_dominic65816.inc ../tuberom_dominic65816.c
rm tuberom_dominic65816.o tuberom_dominic65816.bin

The xxd/cp commands generate a C include file in the parent directory.

You then need to rebuild the PiTubeDirect kernel to pick this up. An incremental make (with no params) should be fine.

It would be nice to have PiTubeDirect load these ROMs from the SD Card at runtime, but that's not possible at the moment.

[dominicbeesley]

Thanks Dave,

I'm still not clear how the tuberom_dominic65816.c gets the C declaration stuff added i.e. xxd outputs a comma separated list of hex value suitable for initialising an array but the .c file that is compiled looks like:

Code: Select all

unsigned char tuberom_dominic65816_bin[] = {
...hex values here...
};
unsigned int tuberom_dominic65816_bin_len = 32768;

How are they getting added?

I'll try and get an updated client ROM in the next couple of days and I'll (try and) do a pull request with any changes in it.

I've just had a quick look at my VHDL for my implementation of the TUBE and it looks like I may also have been plonking the vectors in bank 1, not a good long-term solution. I'll look at putting them somewhere better! If I get a chance (it is my birthday today so I've got to do Zoom tonight) I'll try and fire up my TUBE board, it's lain dormant for 5 years so unlikely to work though as it was hand etched and the tracks were very fine, I suspect the flux may have eaten through some of them by now!

I'm not sure how much interest there would be in an updated 65816 copro on a real board. I'm tempted to get a board fabricated - it would be a good practice for getting PCBA done from a Chinese manufacturer.

D

[hoglet]

How are they getting added?

xxd does all that

Code: Select all

$ echo "hello" > hello.bin
$ xxd -i hello.bin
unsigned char hello_bin[] = {
  0x68, 0x65, 0x6c, 0x6c, 0x6f, 0x0a
};
unsigned int hello_bin_len = 6;
$ xxd -v
xxd V1.10 27oct98 by Juergen Weigert