Anyone developing Tube enhanced software?

discussion of beeb/electron applications, languages, utils and educational s/w
User avatar
Lardo Boffin
Posts: 441
Joined: Thu Aug 06, 2015 6:47 am

Re: Anyone developing Tube enhanced software?

Postby Lardo Boffin » Mon Jun 19, 2017 9:30 am

I know I'd be interested in buying something that made my Beeb twice as quick and was based on hardware available at the time!
BBC model B 32k issue 4, 16k sideways RAM, Watford 12 ROM board, Retroclinic Datacentre + HDD, matchbox co-proc, Viglen twin 40/80 5.25" discs, acorn cassette
BBC model B 32k issue 7, turboMMC, Opus Challenger 3 512k, Pi 3 coproc, Acorn 6502 coproc

User avatar
sydney
Posts: 1817
Joined: Wed May 18, 2005 9:09 am
Location: Newcastle upon Tyne

Re: Anyone developing Tube enhanced software?

Postby sydney » Mon Jun 19, 2017 9:43 am

I think strategy games similar to civilisation and command and conquer would be suited to he copro. Maybe even something like cannon fodder - especially with the new video ula from Robc.

User avatar
Lardo Boffin
Posts: 441
Joined: Thu Aug 06, 2015 6:47 am

Re: Anyone developing Tube enhanced software?

Postby Lardo Boffin » Mon Jun 19, 2017 9:56 am

sydney wrote:I think strategy games similar to civilisation and command and conquer would be suited to he copro. Maybe even something like cannon fodder - especially with the new video ula from Robc.


Absolutely - anything where there is more calculation than drawing would work well I think.
BBC model B 32k issue 4, 16k sideways RAM, Watford 12 ROM board, Retroclinic Datacentre + HDD, matchbox co-proc, Viglen twin 40/80 5.25" discs, acorn cassette
BBC model B 32k issue 7, turboMMC, Opus Challenger 3 512k, Pi 3 coproc, Acorn 6502 coproc

User avatar
Elminster
Posts: 1376
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK

Re: Anyone developing Tube enhanced software?

Postby Elminster » Mon Jun 19, 2017 9:59 am

sydney wrote:I think strategy games similar to civilisation and command and conquer would be suited to he copro. Maybe even something like cannon fodder - especially with the new video ula from Robc.


Which reminds me. Any remake of the FOURMEG is probably going to need to work around VideoNula to get the ulimate gaming experience (AND have a RPI co pro of course :) ) [I am thinking the physical dimensions of getting it all in the case]

Going slightly off topic I wonder how easy it would be to get a Master version of FOURMEG (I know several of us more modern people use Masters over model B's)

User avatar
tricky
Posts: 1620
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: Anyone developing Tube enhanced software?

Postby tricky » Mon Jun 19, 2017 11:30 am

Per pixel collision detection might be a good candidate for the copro, but you might have to "render" everything on the copro too.

User avatar
BigEd
Posts: 1247
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Anyone developing Tube enhanced software?

Postby BigEd » Mon Jun 19, 2017 11:31 am

I think we did something like that in the Life code - render on the copro, so you know what updates need to be sent to the host for display. It does mean the RAM advantage isn't quite so big, but then with more RAM available it might be useful to double-buffer, or triple-buffer, maybe.

RobC
Posts: 1469
Joined: Sat Sep 01, 2007 9:41 pm

Re: Anyone developing Tube enhanced software?

Postby RobC » Mon Jun 19, 2017 2:40 pm

Elminster wrote:Which reminds me. Any remake of the FOURMEG is probably going to need to work around VideoNula to get the ulimate gaming experience (AND have a RPI co pro of course :) ) [I am thinking the physical dimensions of getting it all in the case]

VideoNuLA fits alongside the original FOURMEG board (well alongside and partially underneath) - I have a Beeb with both in...

So, as long as any remake sticks to the original form factor, it should be fine.

User avatar
Elminster
Posts: 1376
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK

Re: Anyone developing Tube enhanced software?

Postby Elminster » Mon Jun 19, 2017 3:07 pm

RobC wrote:
Elminster wrote:Which reminds me. Any remake of the FOURMEG is probably going to need to work around VideoNula to get the ulimate gaming experience (AND have a RPI co pro of course :) ) [I am thinking the physical dimensions of getting it all in the case]

VideoNuLA fits alongside the original FOURMEG board (well alongside and partially underneath) - I have a Beeb with both in...

So, as long as any remake sticks to the original form factor, it should be fine.


FOURMEG, Pi CoPRO, VideoNULA just thow in a BeebSID or OPL and that would be a pretty good game!

jregel
Posts: 35
Joined: Fri Dec 20, 2013 6:39 pm
Location: The Shire of Gloucester

Re: Anyone developing Tube enhanced software?

Postby jregel » Mon Jun 19, 2017 8:35 pm

cmorley wrote:The problem I see with games and the tube copro is that many games are host CPU bound for the graphics. So extra processing and memory which can't be used for graphics/sound doesn't help a lot. It would be great for a game like Simcity but for sprite arcade games a copro doesn't really help. Would be good for a port of the Zork virtual machine...


Newbie question: Given that most games poke the screen directly for performance, is it possible to do this if the main code is running on the Tube?

User avatar
tricky
Posts: 1620
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: Anyone developing Tube enhanced software?

Postby tricky » Mon Jun 19, 2017 8:46 pm

The idea is generally to split the game, logic runs on the copro, display (sprite drawing) runs on the base machine (IO).
Elite works nicely as nearly everything runs on the copro, while the base machine does input, sound and draws lines where it is told.

jregel
Posts: 35
Joined: Fri Dec 20, 2013 6:39 pm
Location: The Shire of Gloucester

Re: Anyone developing Tube enhanced software?

Postby jregel » Tue Jun 20, 2017 4:46 pm

tricky wrote:The idea is generally to split the game, logic runs on the copro, display (sprite drawing) runs on the base machine (IO).
Elite works nicely as nearly everything runs on the copro, while the base machine does input, sound and draws lines where it is told.


As I understand it, OSWRCH is the correct way to write to the screen over the Tube. But if that's not fast enough (e.g., for a game), how do you do it? Presumably you can't just write to a screen address as this would be on the co-pro's memory, not the I/O processor?

User avatar
sweh
Posts: 1810
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: Anyone developing Tube enhanced software?

Postby sweh » Tue Jun 20, 2017 6:18 pm

As tricky mentioned, you split your program into two.

On the I/O processor you have routines that can write directly to the screen memory. The program on the co-processor can talk to the program on the I/O processor.

Now you decide what sort of things you might want to draw. Let's say you normally draw circles. So you might write a fast circle drawing program that pokes directly on the screen. The co-processor could then send a command "draw_circle(RED,FILL,640,128,40)". The program on the I/O processor would receive that command and draw the fastest circle it can.

The good part of this design is that while the I/O processor is drawing the circle the co-processor can carry on doing other stuff.

Obviously it's not quite this easy (e.g. you might need to make sure the I/O processor program is ready to receive data before the co-processor sends it!) but that's the concept; split the work into two and communicate between the two halves.
Rgds
Stephen

User avatar
tricky
Posts: 1620
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: Anyone developing Tube enhanced software?

Postby tricky » Tue Jun 20, 2017 8:03 pm

I've mentioned it in one of these TUBE threads before, but when the beeb came out a popular setup for an arcade games was to have a 1kB buffer for 32x30 characters (8x8 each) and with the remaining 32x2 bytes, store sixteen sprite attributes X, Y, img and colour.
So for Centipede, Warlords and many others, you could change one sprite attribute/screen char with 3 bytes, but as you only need 18 bits, the other six could be for what command was being sent. SPRITE_XYZ, CLS, SOUND or even use the API already defined ;)
You can redraw 16 8x8 mode 1 pixel sprites in a frame, or many more if groups are the same and character aligned.
If 6502 isn't your first language, then you could even write your program in ARM, Z80 or any other supported processor.

User avatar
Elminster
Posts: 1376
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK

Re: Anyone developing Tube enhanced software?

Postby Elminster » Tue Jun 20, 2017 8:16 pm

@Sweh/Tricky

That sounds interesting, I was wondering if I may have hit a tube data flow limited on my code. Is there and example source code for interesting programs for doing this anywhere? I understand the concept but not sure how to go about doing it.

User avatar
tricky
Posts: 1620
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: Anyone developing Tube enhanced software?

Postby tricky » Tue Jun 20, 2017 9:30 pm

I can only think of Tube ELite, the PiTubeDirect test app (spinning dots I think) and maybe tube life.

User avatar
hoglet
Posts: 6083
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: Anyone developing Tube enhanced software?

Postby hoglet » Tue Jun 20, 2017 10:02 pm

The Life program BigEd and I wrote for the 6502 Co Pro is here:
https://github.com/hoglet67/6502Life

There is a video of it in action:
https://www.youtube.com/watch?v=vM9d_xvhCRo&t=71s

And the latest disk image, containing several different approaches.
viewtopic.php?p=154739#p154739

User avatar
Elminster
Posts: 1376
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK

Re: Anyone developing Tube enhanced software?

Postby Elminster » Tue Jun 20, 2017 10:48 pm

Thanks. I will add to my todo list to have a look at. Could be useful for that final little extra bit of speed.

User avatar
Kecske Bak
Posts: 663
Joined: Wed Jul 13, 2005 7:03 am
Location: Treddle's Wharf, Chigley
Contact:

Re: Anyone developing Tube enhanced software?

Postby Kecske Bak » Wed Jun 21, 2017 5:52 am

tricky wrote:You can redraw 16 8x8 mode 1 pixel sprites in a frame, or many more if groups are the same and character aligned.

I'm just idly wondering whether Repton Infinity would have been a candidate for a Co-Pro version. It updates the entire screen with character aligned tiles each frame, but has to do a lot of calculation of the characters on the map. The game speed entirely depends on the complexity of the REPTOL for the characters. The map and display code is separate because you can get a moving map view.

User avatar
Rich Talbot-Watkins
Posts: 991
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca

Re: Anyone developing Tube enhanced software?

Postby Rich Talbot-Watkins » Wed Jun 21, 2017 8:11 am

Yes, I think it would actually be a great contender for a co-pro version. I would also have it go back to hardware scrolling, but a double-buffered version (i.e. using 2 8k screens) which would be faster to update, apart from in the circumstance that there are a lot of moving objects on-screen (in which case it would be no slower than before, at least).

Exile is another game which might benefit a little from second processor acceleration for running physics, AI and fetching map tiles; the host could then focus entirely on screen and sound update.

User avatar
Elminster
Posts: 1376
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK

Re: Anyone developing Tube enhanced software?

Postby Elminster » Wed Jun 21, 2017 8:45 am

Also if I understand correctly you would get even more memory. As you would be able to use the 44k hibasic/asm mem on the copro, but then also use the mem for the bit of code running on the I/O processor? So could you in theory max out bothsides for say 76k + SRAM ?

dp11
Posts: 624
Joined: Sun Aug 12, 2012 8:47 pm

Re: Anyone developing Tube enhanced software?

Postby dp11 » Wed Jun 21, 2017 8:58 am

If you were to limit to PiTube direct you have can over 1Mbyte in 6502 mode. In ARM mode you get lots of RAM and it would be plenty fast enough to run the co pro side in BASIC.

User avatar
BigEd
Posts: 1247
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Anyone developing Tube enhanced software?

Postby BigEd » Wed Jun 21, 2017 9:36 am

(But yes indeed, on any 6502 copro you have about 62k of RAM, plus the host's 32k of RAM with some in use for OS and for screen. So it's more or less a 96k RAM machine. If you have sideways RAM you can add 16k more, or even a bit more for a Master.)
(Edit: but not quite so much in a BASIC world, of course - as noted, HiBasic offers about 44k.)
(Edit: of course it's very nice to have a megabyte and hundreds of megahertz on a pi-based copro tucked under the machine! But it's not quite the most common case yet.)

User avatar
Elminster
Posts: 1376
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK

Re: Anyone developing Tube enhanced software?

Postby Elminster » Wed Jun 21, 2017 10:48 am

Yes I was thinking along the lines of within Acorn guidelines. I guess if you were tweaking existing software you would have to go pretty crazy to go from 32k to nearly 100k in the first place. Some 1MB seems pretty huge. I think I would be 100 by the time I typed in 1MB of text :)

User avatar
Elminster
Posts: 1376
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK

Re: Anyone developing Tube enhanced software?

Postby Elminster » Wed Jun 21, 2017 1:46 pm

cmorley wrote:
Lardo Boffin wrote:Has anyone thought about recreating the Solidisk 4Mhz board or similar?


It's on my list of hardware things to try but I haven't started on that yet so it is months off before i get something working.


The speed of 6502 has moved on and easyily get 14Mhz or quicker. i.e. Is a 'FOURTEENMEG' board feasible, would it make a difference, I dare say the bottle neck would move else where.

RobC
Posts: 1469
Joined: Sat Sep 01, 2007 9:41 pm

Re: Anyone developing Tube enhanced software?

Postby RobC » Wed Jun 21, 2017 3:57 pm

Elminster wrote:The speed of 6502 has moved on and easyily get 14Mhz or quicker. i.e. Is a 'FOURTEENMEG' board feasible, would it make a difference, I dare say the bottle neck would move else where.

I think that the FOURMEG board works by having fast sideways RAM (120ns) so that reads and writes to it happen at 4MHz (as do reads from ROM). However, read and writes involving main memory are still at 2MHz. To do this for a 14MHz CPU, you'd need very fast RAM and would need to think about how fast you can run any ROMs/EPROMs.

You'd ideally want to have the fast RAM replace all of main memory too as otherwise it becomes a bottleneck.

Once you've got that sorted, you'd probably want to look at improving the video system to give higher resolutions and/or more colours...

User avatar
Elminster
Posts: 1376
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK

Re: Anyone developing Tube enhanced software?

Postby Elminster » Wed Jun 21, 2017 4:02 pm

RobC wrote:Once you've got that sorted, you'd probably want to look at improving the video system to give higher resolutions and/or more colours...


Have you heard of anyone that might be working on such a beast? #-o

User avatar
BigEd
Posts: 1247
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Anyone developing Tube enhanced software?

Postby BigEd » Wed Jun 21, 2017 4:05 pm

RobC wrote:You'd ideally want to have the fast RAM replace all of main memory too as otherwise it becomes a bottleneck.

AIUI the likes of the SuperCPU did this by having a full fast local copy of RAM, and just sending writes back to the main board - through a small buffer, so the CPU could keep going, in some cases, in parallel with the write.

RobC
Posts: 1469
Joined: Sat Sep 01, 2007 9:41 pm

Re: Anyone developing Tube enhanced software?

Postby RobC » Wed Jun 21, 2017 5:47 pm

Elminster wrote:
RobC wrote:Once you've got that sorted, you'd probably want to look at improving the video system to give higher resolutions and/or more colours...


Have you heard of anyone that might be working on such a beast? #-o

Sorry - I should have been clearer. I was suggesting an increase in video system memory bandwidth and support ICs that could take advantage of it. As things stand, VideoNuLA isn't capable of doing this.

I suspect you'd need to speed up the 6845 (or have multiple copies) and then look at altering the video ULA.

User avatar
Lardo Boffin
Posts: 441
Joined: Thu Aug 06, 2015 6:47 am

Re: Anyone developing Tube enhanced software?

Postby Lardo Boffin » Thu Jun 22, 2017 8:29 am

BigEd wrote:I think we did something like that in the Life code - render on the copro, so you know what updates need to be sent to the host for display. It does mean the RAM advantage isn't quite so big, but then with more RAM available it might be useful to double-buffer, or triple-buffer, maybe.


How are the updates sent across for this? Reading your post made me wonder if you could do the following: -

Have the screen double buffered on the co-proc
Update a buffer and then work out the byte differences between the buffers
Send the byte differences only across the tube using a specific protocol which results in the bytes being directly copied to the screen memory
Repeat...

The protocol would have to be something like: -

. Action type
. Number of bytes to expect
. Memory address
. Bytes until the correct number sent (this way if a sprite is 8 bytes wide for example you only send one command but 8 bytes after it)

This way if you are only moving a limited number of sprites in a game like pac-man (where the main screen is largely static) very little is going across the tube.

You could possibly get away with a horizontal scroller in a similar manner but would have to have a command to hardware scroll the screen on the Beeb while simulating the same on the co-proc to get the correct differences.

Just a flight of fancy!

Lardo
BBC model B 32k issue 4, 16k sideways RAM, Watford 12 ROM board, Retroclinic Datacentre + HDD, matchbox co-proc, Viglen twin 40/80 5.25" discs, acorn cassette
BBC model B 32k issue 7, turboMMC, Opus Challenger 3 512k, Pi 3 coproc, Acorn 6502 coproc

User avatar
hoglet
Posts: 6083
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: Anyone developing Tube enhanced software?

Postby hoglet » Thu Jun 22, 2017 9:20 am

Lardo Boffin wrote:How are the updates sent across for this? Reading your post made me wonder if you could do the following: -

Have the screen double buffered on the co-proc
Update a buffer and then work out the byte differences between the buffers
Send the byte differences only across the tube using a specific protocol which results in the bytes being directly copied to the screen memory
Repeat...

That's essentially what we do, in quite a crude/simple way.

The data that is sent over the tube (using the VDU FIFO) is:

Code: Select all

<0xff> <Row 0 Difference> <Row 2 Difference> ... <Row 31 Difference>

Each <Row difference> sequence is:

Code: Select all

<Difference> <Next X-Offset> <Difference> <Next X-Offset>...

The end of a row is indicated with a <Next X-Offset> value of zero.

A row with no changes is thus sent as:

Code: Select all

<0x00> <0x00>

Differences are EORed with the current screen byte value to give the new value..

The implementation is currently specific to Mode 4, but could be tweaked for other modes.

Also, as we are only updating a 256x256 window X-Offsets fit in a single byte.

This might seem slightly inefficient, as if there is only one small change on the screen then at least 64 bytes will be sent. The reason we did it this way was try to optimise for the case where about 10% of the screen is changing, which is typical in complex life patterns. The bottleneck becomes the host side VDU driver decoding that data, and this approach keeps that code as minimal as possible.

It you count cycles, the code to process an empty row takes 54 cycles (27 us). So an almost empty frame is 32 x 27us = 0.864ms (i.e. 1157 frames / second). This was fast enough for our needs. :D

This is the entirety of the host-side VDU driver:
https://github.com/hoglet67/6502Life/bl ... driver.asm

Code: Select all

.vdu_driver_start

        ;; Hijack &&FF - this will break plot commands!
       
        CMP #&FF
        BEQ update_display

        JMP (oldwrcvec)

.update_display
{
        PHA
        TXA
        PHA
        TYA
        PHA
       
        LDY #<mode4_base
        STY ptr
        LDA #>mode4_base
        STA ptr + 1
.idle1
        BIT &FEE0
        BPL idle1
        LDA &FEE1
        EOR (ptr),Y
        STA (ptr),Y
.idle2
        BIT &FEE0
        BPL idle2
        LDY &FEE1
        BNE idle1
.zero
        CLC
        LDA ptr
        ADC #<mode4_linelen
        STA ptr
        LDA ptr + 1
        ADC #>mode4_linelen
        STA ptr + 1
        BPL idle1

        PLA
        TAY
        PLA
        TAX
        PLA
        RTS
}

Dave


Return to “software: other”

Who is online

Users browsing this forum: No registered users and 1 guest