Beeb816 Revival

[Revaldinho]

Beeb816 might not be quite ready for prime time, but at least the theatrical trailer is out ...

https://drive.google.com/file/d/1pTYV-N ... p=sharing

EDIT: Fix movie link.

[danielj]

Beeb816 might not be quite ready for prime time, but at least the theatrical trailer is out ...

https://revaldinho.smugmug.com/Vintage- ... HfXhnxZ/A

Loved it - great work!

d.

[BigEd]

I LOLed! Ten years in the making but well worth the wait.

[Diminished]

Beautiful.

[Ramtop]

Oooh, very interesting!

[flaxcottage]

Awesome! And great music.

[RobC]

Brilliant

[BigEd]

Let me try to say what Beeb816 is and what it offers...
- it's a board to plug in to the 6502 socket of a Beeb
- compatible at power up with most existing software and hardware
- offers a 6x to 7x speedup
- complements PiTubeDirect, by speeding up screen output
- four banks of sideways RAM
- genuine 14MHz 65816 can also run 16 bit code in a 24 bit address space

We think it should be handy for Basic, for development, for adventure games, for a faster graphics performance.

More detail:
- it's got a fast CPU, fast 512k RAM, and two glue chips
- there's an optional support ROM which gives you *TURBO and *SHADOW commands
- at power on, it runs at 2MHz as normal and should be compatible with most 65C02-legal software
- with *SHADOW you can set HIMEM=&8000 in any MODE
- with *TURBO you get a 14MHz CPU, with acceleration of the OS, four ROMs, the sideways banks, and the base 32k of RAM
- extra instructions in the 65816 allow direct access to a 24 bit address space

Lots of testing is still needed, and there's room for more exploration of what Beeb816 can do.

It's a project, not a product - but it's open source so anyone can build one.

It looks like this:

[Diminished]

In Turbo mode, does it just drive the legacy buses at higher speeds? So, is the 32K of RAM the 32K of RAM from the 1980s, or is it all on the SRAM now?

Also, what went wrong with the Mark 1?

(Everyone seems to love those AS6C4008s)

[dominicbeesley]

That was what started me on my projects years ago did you see the blitter board I've been (almost as slowly working on). Would you be interested in sharing on the support room, api, etc?

I've still not quite managed 14mhz yet though!

[Revaldinho]

In Turbo mode, does it just drive the legacy buses at higher speeds? So, is the 32K of RAM the 32K of RAM from the 1980s, or is it all on the SRAM now?

The CPLD fully decouples the 14MHz 65816 and SRAM from the motherboard most of the time. When the CPU has to access some resource on the motherboard the CPLD synchronizes the clocks, switches the CPU down to the mother board clock (whether that's for a 2MHz or stretched 1Mhz cycle access) and then completes the access.

In TURBO mode Beeb816 takes copies of ROMs 4-7 (could be sideways RAM too) and ROMs 12-15 in fast memory, and all memory below &3000 is dealt with locally too. All access to these resources run at full speed. 'Video RAM' is dealt with like a cache: Beeb816 has its own high speed copy which is used for reads, but has to slow the clock down for writes to the original motherboard RAM.

In this acceleration mode the CPU is running at full speed for the vast majority of the time. The ClockSP and Sphere stats flashed up in the trailer show a good 7x speed up over the standard Beeb.

Also, what went wrong with the Mark 1?

To be fair, the Mark 1 did kind of work too but only at 8MHz using a synchronous clock taken from the video ULA via a flying lead. We never got it running with a fully asynchronous clock. We have a lot more test and debug kit now that we didn't have first time round, like my vintage HP scope, bus pirates and most importantly a Hoglet Mk1. So finally we traced the problem down to the Beeb816 interfering in the BBC's memory refresh cycles. Using the synchronous clock on the original fortuitously avoided changing memory addresses at the critical time, but any asynchronous clock was bound to hit the problem. The Mk2 board fixes this.

[dudleysoft71]

It would be interesting to see how it performs with tube transfers, obviously reading from the tube and writing to video memory would have to work at 2MHz, but presumably the rest of the clock cycles for those instructions would still run at 14MHz as would the rest of the code, it would be nice to see how much memory could be transferred to screen memory in a frame since the biggest limitation on porting to the Native Pi Co-processor currently is the transfer of video data to the host screen memory which is reliant on the host CPU (although even with the slow host video transfer Frontier is still faster on the Beeb than the original ST version it's based on )

[Revaldinho]

It would be interesting to see how it performs with tube transfers, obviously reading from the tube and writing to video memory would have to work at 2MHz, but presumably the rest of the clock cycles for those instructions would still run at 14MHz as would the rest of the code, it would be nice to see how much memory could be transferred to screen memory in a frame since the biggest limitation on porting to the Native Pi Co-processor currently is the transfer of video data to the host screen memory which is reliant on the host CPU (although even with the slow host video transfer Frontier is still faster on the Beeb than the original ST version it's based on )

Is there a simple potted benchmark I can just load up and run to test this ?

(I have run the PiTubeDirect Sphere benchmark with Beeb816, but that's not quite the same thing since Beeb816 is accelerating the MOS drawing routines in this case too. Just for the record, PiTubeDirect's fast 6502 runs each iteration of Sphere in 1.47s on my Pi 3A+. Enabling Beeb816 Turbo mode gives a 5x speedup, reducing the iteration time to 0.28s.)

[dudleysoft71]

It would be interesting to see how it performs with tube transfers, obviously reading from the tube and writing to video memory would have to work at 2MHz, but presumably the rest of the clock cycles for those instructions would still run at 14MHz as would the rest of the code, it would be nice to see how much memory could be transferred to screen memory in a frame since the biggest limitation on porting to the Native Pi Co-processor currently is the transfer of video data to the host screen memory which is reliant on the host CPU (although even with the slow host video transfer Frontier is still faster on the Beeb than the original ST version it's based on )

Is there a simple potted benchmark I can just load up and run to test this ?

(I have run the PiTubeDirect Sphere benchmark with Beeb816, but that's not quite the same thing since Beeb816 is accelerating the MOS drawing routines in this case too. Just for the record, PiTubeDirect's fast 6502 runs each iteration of Sphere in 1.47s on my Pi 3A+. Enabling Beeb816 Turbo mode gives a 5x speedup, reducing the iteration time to 0.28s.)

Hi, you could try downloading and running a build of Frontier, or DOOM. I've been working on a smacker player, which would actually make a good test case since it plays from memory and can handle different frame rate videos, however my last changes broke the player, if I can get it working I could create a few test videos, perhaps a 50fps 128x144 video (9k per frame) and a 50fps 128x192 (12k per frame). That should give a good indication of the transfer abilities.

[BigEd]

That was what started me on my projects years ago did you see the blitter board I've been (almost as slowly working on). Would you be interested in sharing on the support room, api, etc?

I've still not quite managed 14mhz yet though!

Certainly we can compare notes and share code and so on - our repos are https://github.com/BigEd/beeb816 and https://github.com/BigEd/boot816 although we might yet combine them. I've struggled a bit sometimes to describe exactly what beeb816 offers. I am subscribed to your blitter thread but is there a single current description and/or a repository?

[dominicbeesley]

Thanks Ed

I've not done too much with the 816 other than getting it to work. Looks like you've done some pretty cool demos? I'll be interested as to how you have laid out the banking and booting...I keep changing my mind

I've not got round to putting my stuff up on GitHub yet, mainly because I've not figured out what licence to release it under. I need to do a survey of anything I've borrowed and think it through. I'm happy to send you a copy to look at though.

The support rom is probably easiest as it is mostly my own work but the fpga stuff uses various cores with various licences, which arent all compatible.

It sounds like we've arrived at similar tools though. I've got BLTURBO which turns up the wick and/or shadows the MOS for speed it would probably be sensible to get that working in a similar way?

So far I've let whatever cpu run as fast as it can depending on what memory it is accessing. So stuff from motherboard memory/rom/mos goes at 2MHz but anything shadowed or from the board rom/ram goes at full speed. This seems to work for most games and demos.

I'll be interested to see how you've talked the asynchronous thing. I spent a lot of time getting everything synchronised but have come to realise I shouldn't have bothered!

If you PM me an email I'll send what I can and what documentation I have. I'm looking forward to a good look through your repos tomorrow!

D

[dudleysoft71]

If you want to test transfer performance from the tube I've created a little test, the image attached contains a working non-sound build of my smacker player along with two videos, one is the normal BBC 10fps Dragon's Lair trailer video, the other is a 50fps version of the same video, this video plays slowly on a normal beeb. I've included the original 10fps version so you can compare playback speed between the two.

This is a SCSI HDD image, either copy the files off onto your own image, or rename it as SCSIx.DAT and SCSIx.DSC and replace the original. Unfortunately the video file for 50fps is too large to fit on an ADFS floppy image (even the normal version is too large for a BBC ADFS floppy)

To play back use

Code: Select all

PLAY DL50FPS

this runs the 50FPS version, if you have a VideoNULA then you can use

Code: Select all

PLAY -N DL50FPS

to use the extended palette version.
The original trailer is just called DL, you can run using PLAY DL or PLAY -N DL.

[hoglet]

If you want to test transfer performance from the tube I've created a little test, the image attached contains a working non-sound build of my smacker player along with two videos, one is the normal BBC 10fps Dragon's Lair trailer video, the other is a 50fps version of the same video, this video plays slowly on a normal beeb. I've included the original 10fps version so you can compare playback speed between the two.

At the end, would it be possible for the player to report the number of FPS actually achieved?

Dave

[dudleysoft71]

If you want to test transfer performance from the tube I've created a little test, the image attached contains a working non-sound build of my smacker player along with two videos, one is the normal BBC 10fps Dragon's Lair trailer video, the other is a 50fps version of the same video, this video plays slowly on a normal beeb. I've included the original 10fps version so you can compare playback speed between the two.

At the end, would it be possible for the player to report the number of FPS actually achieved?

Dave

That's a good idea, I'll look into doing that, I'll have to look at what performance metrics available on the native Pi, I normally have a frame counter which is incremented in the VSYNC interrupt, but since I only use that for counting frame intervals it's only 8 bits on the host side, I can count the changes on the Pi side and keep track that way.

[dudleysoft71]

Okay, I've updated my player to show the fps, seems my timing may be a little dodgy since the 10fps one only shows 9.43 fps on my beeb.
I also added a new video this one is 160x176 pixels at 50fps, this is 13.5KBytes per frame, so it's a proper test (it's also the extreme limit of double buffering on an base BBC model B). to run this one use PLAY DL160PX.

Here's the results I got:

50FPS version: 31.44fps
10FPS version: 9.43fps
160px version: 22.49fps

Don't forget that the code does delta frame compression, so the actual data rates in general are lower, however these should be sufficient to see if the 816 makes a difference to transfers over the tube.

It's also shown that with the Gecko build of PiTubeDirect with 236MBytes of memory I can quite easily run a version of Dragon's Lair at 160x176 at 12.5fps, I originally reduced the resolution and frame rate to fit the video into the available 16MByte memory space.

[BigEd]

I've not done too much with the 816 other than getting it to work. Looks like you've done some pretty cool demos?

Oh, all the demos are straight Beeb programs. There's very little '816 code running: we chose to use the 816's block move instructions to copy the ROMs into fast RAM, and the control register is placed in high memory too so you need a few bytes of 816 code to change modes. I think that's about it.

[Colday]

JUST when I start to think I'm frantically grasping the fundamentals and beginning to understand what is feasible with a beeb, someone comes up with something new.

This is very impressive. And not just the trailer which is great in it's own right.

If there are any boards available I would buy one of these (happy to solder).

I appreciate these are likely to be few and far between, but it's an awesome project.

If I can help (which in turn teaches me stuff) let me know.

[BigEd]

There's very little '816 code running...

In true '816 mode, and similarly in 6502 mode if you execute outside bank 0, you need to disable interrupts. (Unless we adjust the OS ROM... which we can because we have our working copy in RAM...) But, even in 6502 mode, you have the x7 opcodes which indirect off a three-byte pointer in zero page, and xF opcodes which take a three byte pointer argument, so there’s a possibility of storing data or bytecode in the high banks. Maybe a 256k arena would be possible. There are a few more potentially useful '816 style instructions in '02 mode, like the B register, TXY and TYX. But always operating in byte-wide ways: all the 16-bit possibilities are accessible only in '816 mode.

[Colday]

You did that on purpose.

[BigEd]

The 816 is quite a beast to get your head around, in my experience. On the one hand that makes it a bit clunky, but on the other hand it means sometimes you get a pleasant surprise - something is possible which might not have seemed so.

I think in my ideal world
- beeb816 works
- people like it and build their own
- someone builds beeb816s and sells to people who want one
- we find amazing ways of using the extra CPU power and RAM

Combined with VideoNuLA and PiTubeDirect, and BeebSCSI or 1MHzPi, the Beeb becomes quite a beast. Not that we yet know beeb816 can work with all those - as I say, more testing needed.

[Diminished]

I'd be tempted.

Partly because I already have one of those RAM chips sitting here doing nothing!

[Ramtop]

Getting hold of that CPLD may be an issue, the XC95108 is mostly an 'order from China and hope you don't get a fake' job now.

[BigEd]

It might be that the 10 years elapsed time is part of that... but there might be ways forward...

[Colday]

Combined with VideoNuLA and PiTubeDirect, and BeebSCSI or 1MHzPi, the Beeb becomes quite a beast. Not that we yet know beeb816 can work with all those - as I say, more testing needed.

Well, I have a PiTubeDirect (not quite finished yet but getting there as been busy) and am willing to help out if I can.

Just say the word (via PM) if you think I can be of any use.

And yes, I'd happily build them for others. Is there any surface mount or BGA soldering required? May need to wait for my heat table to arrive if there is. Otherwise I'm pretty well geared up.

[BigEd]

Sounds great. No surface mount with today's prototype, but that could change. And indeed the current PCB might well not be the final revision, depending on what we learn from further testing.