Thoughts on StarWars for the beeb

new games to be launched and discussed here
Post Reply
User avatar
tricky
Posts: 2705
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Thoughts on StarWars for the beeb

Post by tricky » Sat Mar 03, 2018 12:51 pm

I was thinking ages ago about writing a Star Wars "emulator" for the beeb and RobC's SprectROM has got me thinking about it again.

Originally I was thinking about using the MatchBox CoPro running a 6809, probably overclocked to run the game and have the beeb do the gfx, sound and speech (it is a good choice for speech as they both use the same tmd5220 chip).

I have code to draw Atari vectors, but it needs optimising and for maximum line drawing time, the scaling would be best done on the CoPro as well as some of the line setup. There wouldn't be enough time to fill the screen with lines like the arcade does, but most models might be OK.

Here are my old memory requirement notes:

Code: Select all

StarWars emulator for the beeb

6809 CPU
40KB ROM
12KB RAM (vectorram)
 2KB RAM
 4KB RAM (mathram)

Mathbox
4KB PROM 4KB RAM

AVG vectors
4KB PROM

POKEY (x4) sound
8KB ROM

tms5220 speech
8KB ROM
The reason that I never did anything more about it is I didn't want to learn 6809 and thought that doing MathBox work in 6809 would be too much.

With RobC's approach, I was wondering if something like PiMame could be built to emulate the game and produce beeb friendly line drawing data, similar to what I was hoping to do originally.

I have recorded my beeb playing back the speech data through my portable TV and attached it as starwars_speech.mp3, the phrases are:

Code: Select all

use the force luke
remember
i'm on the leader
the force is strong with this one
red 5 standing by
this is red 5 i'm going in
r2 try to increase the power
you're all clear kid
let go luke
(darth vader's rasping)
yahoo
i have you now
look at the size of that    thing
stay in attack formation
the force will be with you
always
(bleeps)
(wookiee    growl)
i'm hit but not too bad, r2 see what you can do with it
i've lost r2
great shot kid that was one in a million
i can't shake him
luke trust me
The sound effect conversions are probably beyond me, I wrote code to convert POKEY to sn76489, but I doubt that it would do a great job of mixing four POKEY chips (assuming that they are all used for sound). The game seems to be mostly music and a sound effect, so should be possible.

I'm sure that I have heard some OK Star Wars music on the Master System and I thought that I had on the beeb, but can't find it.

Another option might just be to add speech and music to the beeb version of Star Wars, as the game is OK.

I'm not saying that I am going to do any of this, I just wanted to "put it out there".
Attachments
starwars_speech.mp3
(482.63 KiB) Downloaded 57 times

User avatar
Arcadian
Site Admin
Posts: 2940
Joined: Fri Nov 24, 2000 12:16 pm
Contact:

Re: Thoughts on StarWars for the beeb

Post by Arcadian » Sat Mar 03, 2018 1:20 pm

Do it.
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk

Image
ABug SOUTH (Hampshire) (1-3 June 2018)

dixiestoat
Posts: 256
Joined: Tue Oct 09, 2012 8:58 am
Location: Warwickshire
Contact:

Re: Thoughts on StarWars for the beeb

Post by dixiestoat » Sat Mar 03, 2018 2:16 pm

You beat me to it Arcadian... =D> =D>
If in doubt, CTRL-BREAK thou should clout..

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

Re: Thoughts on StarWars for the beeb

Post by Lardo Boffin » Sat Mar 03, 2018 2:57 pm

Hell yes!
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

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

Re: Thoughts on StarWars for the beeb

Post by RobC » Sat Mar 03, 2018 3:32 pm

tricky wrote:With RobC's approach, I was wondering if something like PiMame could be built to emulate the game and produce beeb friendly line drawing data, similar to what I was hoping to do originally.
Definitely do it. This would be awesome :D

Rather than line data, it might be worth thinking about using the Pi co-pro to calculate which screen bytes to poke. I found that there was no need to implement delays on the VDU queue if I got all the data lined up before starting to send it (so data transfers were essentially free).

It might seem like cheating but it meant that it was quicker to use the Pi for anything requiring more than a few 6502 cycles.

crj
Posts: 834
Joined: Thu May 02, 2013 4:58 pm
Contact:

Re: Thoughts on StarWars for the beeb

Post by crj » Sat Mar 03, 2018 3:52 pm

The back of my envelope says the absolute maximum you could possibly achieve is updating 4444bytes of screen memory per frame, using a tight LDA abs : STA abs,X loop. (And you'd need some evil shenanigans to approach that.)

Question is: is that enough?

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

Re: Thoughts on StarWars for the beeb

Post by tricky » Sat Mar 03, 2018 4:18 pm

There might be enough BW to send diffs, but it feels too much like cheating.
Plus like I said, I don't really have any plans to do this any time soon.
I'd be happy to help anyone else wanting to do it though.

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

Re: Thoughts on StarWars for the beeb

Post by RobC » Sat Mar 03, 2018 5:14 pm

crj wrote:The back of my envelope says the absolute maximum you could possibly achieve is updating 4444bytes of screen memory per frame, using a tight LDA abs : STA abs,X loop. (And you'd need some evil shenanigans to approach that.)

Question is: is that enough?
You might squeeze a bit more out by grouping multiple writes of the same value.

One thing I keep meaning to try is whether it's possible to get the co-pro to poke 6502 code into the Tube registers and get it to execute from there. You could then do LDA immediate, STA abs etc. (but you'd lose a bit on the branch back).
tricky wrote:There might be enough BW to send diffs, but it feels too much like cheating.
That's what I do with SpectROM: maintain a copy of the existing display and send differences as LDA abs, STA abs,X. It definitely does feel like cheating but it's very effective!

I'd definitely encourage people to think about using the Pi co-pro for stuff like this as you can program in high-level languages, have loads of memory and the video I/O is generally at least as quick as it would be if you were running exclusively on the host.
tricky wrote:I'd be happy to help anyone else wanting to do it though.
So would I.

crj
Posts: 834
Joined: Thu May 02, 2013 4:58 pm
Contact:

Re: Thoughts on StarWars for the beeb

Post by crj » Sat Mar 03, 2018 5:44 pm

RobC wrote:One thing I keep meaning to try is whether it's possible to get the co-pro to poke 6502 code into the Tube registers and get it to execute from there.
If you mean into a Tube ULA, or emulated Tube ULA then no, definitely not.

If you mean relying on the Tube socket giving you 32 bytes of memory-mapped I/O in the host (how come there are 8 address lines, come to think of it?) then firstly ew... but secondly you might just pull it off.

If you placed:

Code: Select all

.loop
  LDA #b0 : STA a0
  LDA #b1 : STA a1
  LDA #b2 : STA a2
  LDA #b3 : STA a3
  LDA #b4 : STA a4
  LDA #b5 : STA a5
  BCC loop
...as the 32 bytes, replacing them as they were executed, that would be 39 cycles per six bytes written to screen memory, so you could sustain 6,153bytes written per frame.

As a warning, however, I've given some thought to such tricks and realised you have to be extremely careful of some details. Mainly, you have to be aware that the CPU can and will read the same instruction byte multiple times, while it's executing a multi-cycle instruction. Worse, it won't read each instruction a deterministic number of times, because the pipeline is flushed on interrupt then refilled on RTI. The fiddliness and precision of what you need to do in real-time is considerable.

You'd also somehow have to make sure the Tube Host System didn't blow you out of the water from an interrupt handler the first time it tried to tell the parasite the user had pressed Escape.

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

Re: Thoughts on StarWars for the beeb

Post by dp11 » Sat Mar 03, 2018 6:01 pm

7 address lines on an external tube connector
3 address lines on an master internal tube connector

crj
Posts: 834
Joined: Thu May 02, 2013 4:58 pm
Contact:

Re: Thoughts on StarWars for the beeb

Post by crj » Sat Mar 03, 2018 6:25 pm

Mmm. Three address lines makes a lot more sense!

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

Re: Thoughts on StarWars for the beeb

Post by tricky » Sat Mar 03, 2018 7:22 pm

Sounds like it would be fairly easy to tell where the 6502 is reading and to update the half not being read when the other half is first read.
With multiple writes of the same value, you could do a whole mode 4+.
Still feels like cheating ;) but I like it.

crj
Posts: 834
Joined: Thu May 02, 2013 4:58 pm
Contact:

Re: Thoughts on StarWars for the beeb

Post by crj » Sun Mar 04, 2018 12:57 am

tricky wrote:Sounds like it would be fairly easy to[...]
At that point, you're trying to do three things simultaneously:
  • Reliably support reads every 500ns
  • Reliably replenish 16 bytes of code every 10µs
  • Keep running the thing you actually wanted to run
I know PiTubeDirect can do the first and third OK, but apparently it's a fairly close-run thing? Could it cope if the replenishment was added as another hard real-time activity?

I was contemplating a similar scheme where the replenishment would be done by an FPGA, and abandoned it as way more trouble than it was worth. Instead, I'm now intending to pull a very similar trick using 4Kbytes of sideways "ROM". The advantage there is that the performance degradation is negligible if it takes a moment once per kilobyte to check the next kilobyte of code is available before proceeding. Doing that means supporting the Beeb reading from the "ROM" is the only real-time aspect; the rest can be done in a far more leisurely fashion.

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

Re: Thoughts on StarWars for the beeb

Post by dp11 » Sun Mar 04, 2018 1:26 am

PiTubeDirect hasn't been tested for back to back reads as that is against the tube spec. It almost certainly won't work.

crj
Posts: 834
Joined: Thu May 02, 2013 4:58 pm
Contact:

Re: Thoughts on StarWars for the beeb

Post by crj » Sun Mar 04, 2018 1:54 am

Really?

The closest thing to a Tube "spec" I've ever seen is Application Note 004 (PDF). The Electrical Specification on p11 shows ~CS being asserted on two consecutive cycles, and it alleges the cycle time can be as short as 250ns. That suggests the Tube ULA itself ought to cope with unremitting 4MHz access.

Of course, anyone using the Tube either has to adhere to the timings for data transfer operations (pp8-9 of that document) or use the status registers for flow control. The maximum actual data transfer rate would be 2Mbytes/sec, and that would require stonkingly fast hosts and parasites the like of which the world has never seen. So far as I know. (-8

(My expectation was that PiTubeDirect could handle back-to-back accesses at 2MHz to the emulated Tube ULA, just that it might not get very much else done at the same time!)

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

Re: Thoughts on StarWars for the beeb

Post by tricky » Sun Mar 04, 2018 8:34 am

I was assuming 128 bytes delivered by the GPU arm with half of it replaced at a time, but you are correct about the main CPU not having much time, unless the GPU arm can read from a larger buffer giving the main CPU bigger chunks of time to do more things.

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

Re: Thoughts on StarWars for the beeb

Post by BigEd » Sun Mar 04, 2018 8:58 am

I'm going to have to be vague here, but as I recall PiTubeDirect needed to do something special to support the multiple accesses of a RMW instruction on the host. It hangs around after an access in case there's a followup, and as a consequence there's something it couldn't do... which turns out not to happen in any conventional host-side code. As I recall, handling RMW cost us a little performance because the code is spinning, mostly to find out there is no RMW. But, all this said, it might have been when we were doing all the bitbanging in an ISR, and might not apply now it's handled by the GPU.

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

Re: Thoughts on StarWars for the beeb

Post by dp11 » Sun Mar 04, 2018 9:16 am

The spec says if you are reading a FIFO you need 10.5us between reads. Pitubedirect will be quicker than this but almost certainly not back to back.

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

Re: Thoughts on StarWars for the beeb

Post by RobC » Sun Mar 04, 2018 4:21 pm

I need to dig out my SpectROM code but I'm pretty sure I am (or at least was) doing LDA &FEE1:LDX &FEE1 on the host at some point. I left the Beeb running SkoolDaze in demo mode for about four hours to make sure it was reliable!

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

Re: Thoughts on StarWars for the beeb

Post by dp11 » Sun Mar 04, 2018 4:37 pm

For PiTube direct LDA &FFE1:LDX &FFE1 will be fine as as there is 1.5uS between reads, but this is currently a case that we don't check for in testing.

crj
Posts: 834
Joined: Thu May 02, 2013 4:58 pm
Contact:

Re: Thoughts on StarWars for the beeb

Post by crj » Sun Mar 04, 2018 11:51 pm

dp11 wrote:The spec says if you are reading a FIFO you need 10.5us between reads.
I think you misunderstand. That's when performing a bulk transfer without flow control. The delay is not for the benefit of the Tube ULA, but the parasite, which is required to sustain the data rate reliably.

Post Reply