Anyone developing Tube enhanced software?

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

Anyone developing Tube enhanced software?

Post by Lardo Boffin » Sat Jun 17, 2017 1:14 pm

Given that pretty much anyone can have a 6502 or Z80 coprocessor etc. now (without relying on one appearing on eBay that isn't made of gold) I was wondering if anyone is developing Tube enhanced software for them?

I remember some discussions about using GXR or similar to draw sprites on the host machine and then using the coprocessor to drive the game but have not heard anything since.

If you are then =D> !

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

User avatar
jgharston
Posts: 3215
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

Re: Anyone developing Tube enhanced software?

Post by jgharston » Sat Jun 17, 2017 8:52 pm

Properly written programs will automatically enhance themselves without any thought. memsize=HIMEM-LOMEM will automatically discover that there is more memory to use without anything else having to be done. Programs whould almost never do IF on_tube THEN run_better ELSE run_worse, it runs better automatically immediately by virtue of it being run on the second processor.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

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

Re: Anyone developing Tube enhanced software?

Post by Lardo Boffin » Sat Jun 17, 2017 10:13 pm

This is fair comment but I guess many people don't write them properly - who can resist having a peek or poke at RAM directly rather than through the prescribed routes (as directly is generally faster).

I know from personal experience that what is in a memory location on the Beeb isn't in the same location in the co proc - assuming it is there at all. I was getting back into BASIC by writing an MMC explorer (thanks again the procedure error handing code!) and it worked by directly reading the RAM where DFS stored the file info in order to list the files present. If I wanted that to run over the tube it would need amendment.

So I guess software that would work over the tube at all as opposed to software that would work better over the tube would have been a better question!
BBC model B 32k issue 4, 16k sideways RAM, Watford 12 ROM board, Viglen twin 40/80 5.25" discs, Acorn 6502 coproc
BBC model B 32k issue 7, turboMMC, Opus Challenger 3 512k, Pi 3 coproc
BBC Master, Datacentre + HDD, pi co-proc

User avatar
aerworuld
Posts: 1708
Joined: Tue Sep 25, 2012 8:40 pm
Location: Basingstoke, Hampshire
Contact:

Re: Anyone developing Tube enhanced software?

Post by aerworuld » Sun Jun 18, 2017 4:01 am

I've been wondering about CoPro... I've got the Slogger MRB for Elk which speeds up most games nicely: would it be worthwhile to get CoPro in my setup, for example?

The only game I know released for it was the Elite CoPro version.

Cool avatar, Lardo 8) if you're into Fallout, check out my RobCo turret terminal demo on the Elk =)

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

Re: Anyone developing Tube enhanced software?

Post by Elminster » Sun Jun 18, 2017 8:15 am

aerworuld wrote: The only game I know released for it was the Elite CoPro version.
I think it is more that the game doesn't hit the hardware directly and make use of the extra memory. Generally games hit the hardware for extra speed and then fall over on co pro.

Non games tend to play nicer and should just run quicker.

I think once the copro is popular on Electron then people might do some to use it.

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

Re: Anyone developing Tube enhanced software?

Post by dp11 » Sun Jun 18, 2017 10:02 am

Hoglets Game of Life uses even more memory on the pitubedirect as we support bank switching.

So you can have a 270MHz 6502 with Iirc a meg of ram.

cmorley
Posts: 662
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford
Contact:

Re: Anyone developing Tube enhanced software?

Post by cmorley » Sun Jun 18, 2017 11:03 am

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...

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

Re: Anyone developing Tube enhanced software?

Post by tricky » Sun Jun 18, 2017 12:14 pm

I think a copro would be good for games with more going on: RTSs, games with route finding, AI or just more things to keep track of.

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

Re: Anyone developing Tube enhanced software?

Post by Lardo Boffin » Sun Jun 18, 2017 1:22 pm

aerworuld wrote:I've been wondering about CoPro... I've got the Slogger MRB for Elk which speeds up most games nicely: would it be worthwhile to get CoPro in my setup, for example?

The only game I know released for it was the Elite CoPro version.

Cool avatar, Lardo 8) if you're into Fallout, check out my RobCo turret terminal demo on the Elk =)
Loving the terminal! I wrote a few sample BCPL programs a while back and used the same green screen appearance.

The only real use I have my co proc is to build compiled languages (such as BCPL) much faster. Apart from Elite that is!
BBC model B 32k issue 4, 16k sideways RAM, Watford 12 ROM board, Viglen twin 40/80 5.25" discs, Acorn 6502 coproc
BBC model B 32k issue 7, turboMMC, Opus Challenger 3 512k, Pi 3 coproc
BBC Master, Datacentre + HDD, pi co-proc

User avatar
jgharston
Posts: 3215
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

Re: Anyone developing Tube enhanced software?

Post by jgharston » Sun Jun 18, 2017 2:39 pm

Lardo Boffin wrote:This is fair comment but I guess many people don't write them properly - who can resist having a peek or poke at RAM directly rather than through the prescribed routes (as directly is generally faster).

I know from personal experience that what is in a memory location on the Beeb isn't in the same location in the co proc
It is in the same location - in the I/O processor. If you want to be looking at a memory location in the I/O processor you must look at the location in the I/O processor, NOT look at a completely different location in the language processor. If you want to look in the sock drawer you must look in the sock drawer, not look in the cupboard in the room you're standing in.
Lardo Boffin wrote:I was getting back into BASIC by writing an MMC explorer (thanks again the procedure error handing code!) and it worked by directly reading the RAM where DFS stored the file info in order to list the files present. If I wanted that to run over the tube it would need amendment.
No, it needs to be written correctly in the first place, using the API calls that tell you what files are present, NOT by welding your program immovably to the arbitary memory layout of the workspace of one specific bit of code.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

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

Re: Anyone developing Tube enhanced software?

Post by Elminster » Sun Jun 18, 2017 2:45 pm

Lardo Boffin wrote:I was wondering if anyone is developing Tube enhanced software for them?
My current project uses a copro to get the extra mem and speed but it is a bit niche requiring also a master and Ethernet card.

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

Re: Anyone developing Tube enhanced software?

Post by Lardo Boffin » Sun Jun 18, 2017 4:55 pm

jgharston wrote:
Lardo Boffin wrote:I was getting back into BASIC by writing an MMC explorer (thanks again the procedure error handing code!) and it worked by directly reading the RAM where DFS stored the file info in order to list the files present. If I wanted that to run over the tube it would need amendment.
No, it needs to be written correctly in the first place, using the API calls that tell you what files are present, NOT by welding your program immovably to the arbitary memory layout of the workspace of one specific bit of code.
I agree entirely with what you say however I found myself with cold feet and no knowledge of socks or where to find them so having read somewhere that there were some nice warm tubes of material to be had I dived in and warmed my feet up. Its an unfortunate situation but I have very little time for my hobby (what little I have I get by sacrificing sleep - I have a full time job currently requiring overtime and two very young children) so didn't have time to research and figure out what the appropriate API calls were or how they worked. I'm not proud of this situation but its where I am.
I suspect I am not the only person in this type of situation hence wondering if anyone was writing stuff properly so it worked on and took advantage of the coproc.
BBC model B 32k issue 4, 16k sideways RAM, Watford 12 ROM board, Viglen twin 40/80 5.25" discs, Acorn 6502 coproc
BBC model B 32k issue 7, turboMMC, Opus Challenger 3 512k, Pi 3 coproc
BBC Master, Datacentre + HDD, pi co-proc

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

Re: Anyone developing Tube enhanced software?

Post by Elminster » Sun Jun 18, 2017 5:03 pm

I suspect using the api will probably more important than ever now co pros are so easy/ cheap to get.

I got new socks for Father's Day so don't need to go to my sock draw for a week :evil:

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

Re: Anyone developing Tube enhanced software?

Post by Lardo Boffin » Sun Jun 18, 2017 5:06 pm

Elminster wrote:I suspect using the api will probably more important than ever now co pros are so easy/ cheap to get.

I got new socks for Father's Day so don't need to go to my sock draw for a week :evil:
Good gift! I never have enough socks, not matching ones anyway.

I do need to get to grips with the APIs but so much to learn and so little time!
BBC model B 32k issue 4, 16k sideways RAM, Watford 12 ROM board, Viglen twin 40/80 5.25" discs, Acorn 6502 coproc
BBC model B 32k issue 7, turboMMC, Opus Challenger 3 512k, Pi 3 coproc
BBC Master, Datacentre + HDD, pi co-proc

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

Re: Anyone developing Tube enhanced software?

Post by Elminster » Sun Jun 18, 2017 5:17 pm

Lardo Boffin wrote:
I do need to get to grips with the APIs but so much to learn and so little time!
Agree 100% with the time problem

User avatar
kieranhj
Posts: 724
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK
Contact:

Re: Anyone developing Tube enhanced software?

Post by kieranhj » Sun Jun 18, 2017 7:20 pm

I started doing some investigations into Tube protocols as I wanted to write some demo effects using my 4Mhz Master Turbo copro unfortunately it's quite painful, not least because my dev environment of choice, B-Em, doesn't seem to correctly implement the 256 byte fast transfer protocol correctly (it never returns from the Tube release request.)

I said this in another thread but, without stating the obvious, the copro system was designed to add a second / different processor to the Beeb with the original CPU used for I/O. It wasn't designed with high degrees of parallelism in mind, mostly the I/O processor has to sit and wait for data to come down the Tube to handle it right away. The overhead of sending data is high (10us per byte minimum) so moving lots of data around is prohibitive.

In a typical real-time app, like a game or demo, on such a low powered machine you need to use the result of any calculation or algorithm right away and plot to the screen to avoid the raster etc. Any calcs on a copro have to be stored, then sent down the Tube, read on I/O then plotted to the screen. It's like having a reasonable CPU (4Mhz, yay!) attached to the world's slowest GPU as the I/O has to do all screen memory access, and keyboard, and sound, and disk, and...

I think you could do something interesting on a copro (demo or game-wise I mean) but it would be a lot of time & effort that I don't have right now. Unless POP ends up being Master Turbo only! Also need better debugging tools within B-Em for multiple 6502 processors and need to debug why Tube doesn't work properly to begin with.
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

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

Re: Anyone developing Tube enhanced software?

Post by BigEd » Sun Jun 18, 2017 7:27 pm

It's certainly an obstacle if your emulation environment of choice isn't accurate enough!

But surely Tube Elite shows that if your game can be divided up into a host part for I/O and a copro part for computation, you can have a bigger and smoother game? You might need to extend the VDU codes or even write your own I/O, and that might be too much, but we know it can be done.

Of course that division might not be practical for some games.

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

Re: Anyone developing Tube enhanced software?

Post by Lardo Boffin » Sun Jun 18, 2017 8:41 pm

kieranhj wrote:It's like having a reasonable CPU (4Mhz, yay!) attached to the world's slowest GPU as the I/O has to do all screen memory access, and keyboard, and sound, and disk, and...
True but with the Pi co proc etc you have a 200Mhz plus CPU for calculations which would presumably allow calculations done live on the co proc?
BBC model B 32k issue 4, 16k sideways RAM, Watford 12 ROM board, Viglen twin 40/80 5.25" discs, Acorn 6502 coproc
BBC model B 32k issue 7, turboMMC, Opus Challenger 3 512k, Pi 3 coproc
BBC Master, Datacentre + HDD, pi co-proc

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

Re: Anyone developing Tube enhanced software?

Post by Elminster » Sun Jun 18, 2017 8:45 pm

Pi is v.fast.

Currently on a 4mhz co pro it takes 45 seconds to refresh TOP command via telnet (with refresh defaulting to 1.5) but with the Pi running it takes 1 second. So a whole .5 second to before refresh is due. running at 16Mhz it takes the 65c102 about 8-9 seconds. So the Pi is v.fast. If you ran it on a standard Electron you could be getting 180 times slower refresh.

User avatar
kieranhj
Posts: 724
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK
Contact:

Re: Anyone developing Tube enhanced software?

Post by kieranhj » Sun Jun 18, 2017 8:55 pm

BigEd wrote:It's certainly an obstacle if your emulation environment of choice isn't accurate enough!

But surely Tube Elite shows that if your game can be divided up into a host part for I/O and a copro part for computation, you can have a bigger and smoother game? You might need to extend the VDU codes or even write your own I/O, and that might be too much, but we know it can be done.

Of course that division might not be practical for some games.
I'm not convinced that regular (original HW) copro Elite is ~that~ much "better" than the standard Master version. I'd need to try them side by side again, or in a more scientific way.

The source for the Tube version shows that the I/O waits for line draw callbacks on oswrch vector and executes them immediately and that's about it (apart from some codes to switch between docked and flight screens.) This is about the most optimal arrangement as you're sending just 4 bytes (x+y coordinates x2) for a good chunk of work (Bresenham line draw) and there are maybe a few 10's of lines per frame. I know the Pi copro version runs unplayably fast but I can't find the vsync code that runs on the parasite side, so I guess it's not sync'ing and frames are just getting dumped somehow, which isn't much better than just setting the frame time delta to a larger number on the regular version - it'll still appear "fast".

Ultimately you're still entirely limited by how many lines a 2MHz 6502 can draw in 20ms, which isn't many.
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

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

Re: Anyone developing Tube enhanced software?

Post by dp11 » Sun Jun 18, 2017 8:57 pm

You could start to think about using the beeb to plot sprites so only a small amount if info is transferred. The copro can do the calculations collision detection, physics engine etc.

User avatar
kieranhj
Posts: 724
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK
Contact:

Re: Anyone developing Tube enhanced software?

Post by kieranhj » Sun Jun 18, 2017 9:03 pm

Lardo Boffin wrote:True but with the Pi co proc etc you have a 200Mhz plus CPU for calculations which would presumably allow calculations done live on the co proc?
Yes but you still have to retrieve that data and display it in <40,000 cycles (2MHz I/O CPU refreshing at 50Hz.). Even if you get the copro to do all the fiddly screen address calculations etc. you're still limited by reading & writing data on the I/O side. I think we worked out with JGH that max throughout would be 100kb/s across the Tube, which sounds a lot but you can't do anything else (that consumes 100% of I/O CPU) and would still only get you 5-10Hz update for a screen copy, for instance.

Personally, as much as I marvel at the Pi copro (I have one), I'm more interested in what might be possible with original HW so 3-4Mhz 2nd processor. Answer is likely "something interesting but not as much as you'd think / hope."
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

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

Re: Anyone developing Tube enhanced software?

Post by Elminster » Sun Jun 18, 2017 9:07 pm

The joy of the master is I have the internal 4/8/12/16mhz John K 65C102 copro, and a Pi external and switch between them.

User avatar
kieranhj
Posts: 724
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK
Contact:

Re: Anyone developing Tube enhanced software?

Post by kieranhj » Sun Jun 18, 2017 9:09 pm

dp11 wrote:You could start to think about using the beeb to plot sprites so only a small amount if info is transferred. The copro can do the calculations collision detection, physics engine etc.
Yes indeed, particularly with lots of juicy swram for sprite data. Still, sprite plotting is hardly the Beeb's strong point and still have to do any masking / clipping (the expensive operations) on the I/O side. I'm not saying interesting things couldn't be done, just that in my initial investigations it was much more limited than I was hoping - I quickly ran out of frame time when aiming for 50Hz by the time I'd got data out of the Tube pipe. More investigation & a different approach needed and that's when I ran into B-Em bug. (Which is also present in jsbeeb, but works in BeebEm.)
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

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

Re: Anyone developing Tube enhanced software?

Post by BigEd » Sun Jun 18, 2017 9:13 pm

Broadly speaking, a Tube program (or game) has double the RAM and double the CPU power, so overall that's 3x in compute and 3x in memory, and going against that advantage - as you say - is a relatively narrow communications channel. But it is a more capable machine overall, so that must count for something, even if it doesn't mean 50 fps full-screen updates.

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

Re: Anyone developing Tube enhanced software?

Post by Elminster » Sun Jun 18, 2017 9:16 pm

BigEd wrote:Broadly speaking, a Tube program (or game) has double the RAM and double the CPU power, so overall that's 3x in compute and 3x in memory, and going against that advantage - as you say - is a relatively narrow communications channel. But it is a more capable machine overall, so that must count for something, even if it doesn't mean 50 fps full-screen updates.
I guess it just depends what you are going to do with it, for me the co pro is amazing performance gain on my code, but I am not bashing I/O particualrly heavily it is all processing.

Feel the pain with the emulators as my hardware I am writing for is not in the emulators. SO I write on mac, copy, test, debug on master, repeat.

User avatar
kieranhj
Posts: 724
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK
Contact:

Re: Anyone developing Tube enhanced software?

Post by kieranhj » Sun Jun 18, 2017 9:45 pm

BigEd wrote:Broadly speaking, a Tube program (or game) has double the RAM and double the CPU power, so overall that's 3x in compute and 3x in memory, and going against that advantage - as you say - is a relatively narrow communications channel. But it is a more capable machine overall, so that must count for something, even if it doesn't mean 50 fps full-screen updates.
Absolutely. For my first use case of doing interesting gfx at 50Hz it turns out to be less useful (or just harder than I thought) as all the stuff required for 50Hz update has to be on the I/O side. More specifically I was trying to see how many particles (points) I could animate & draw individually - my goal being at least 256. I can't remember where I landed but it was nowhere near that and definitely less than the 160 points (admittedly not independent but still) rendered by RTW's beebasm sample demo code running on a 2Mhz machine with raster chasing at 50Hz.

I think there must be some nice use cases that fit the copro architecture, I just need to spend some more time thinking about them from my interest POV. I'm sure others can think of plenty on the thread!
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

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

Re: Anyone developing Tube enhanced software?

Post by Lardo Boffin » Mon Jun 19, 2017 8:40 am

Hmm. Doesn't sound the co processors are very beneficial for games at least (except a few specific types)!

Has anyone thought about recreating the Solidisk 4Mhz board or similar? Assuming it ever worked very well (I have never tried one or even seen one) running twice as fast directly on the Beeb itself must be easier to utilise? But I guess that's a whole other topic!
BBC model B 32k issue 4, 16k sideways RAM, Watford 12 ROM board, Viglen twin 40/80 5.25" discs, Acorn 6502 coproc
BBC model B 32k issue 7, turboMMC, Opus Challenger 3 512k, Pi 3 coproc
BBC Master, Datacentre + HDD, pi co-proc

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

Re: Anyone developing Tube enhanced software?

Post by Elminster » Mon Jun 19, 2017 8:53 am

I remember Prime talking about it, but not sure if it went any further.

viewtopic.php?f=3&t=9181&p=104552&hilit=fourmeg#p104552

The other issue is that would need to sell a lot of them to make it worth while designing software for it (assuming not just for self).

cmorley
Posts: 662
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford
Contact:

Re: Anyone developing Tube enhanced software?

Post by cmorley » Mon Jun 19, 2017 9:16 am

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.

Post Reply