Poor Elk.

Obviously as someone who still uses humble tape only Elks, I am going to be a bit biased but as interesting as pushing a fully expanded beeb as far as it can go would be, surely the magic of retro computing is the challenge of squeezing as much as you can out of the very limited hardware?!

Just as an aside, I think it's worth pointing out that there were probably just as many Electron games hampered by being designed for the beeb and then badly converted (so they run too slow!).

Actually I have meant to start a thread a few times asking how beeb fans feel about the elk - do they resent it for crippling Acorn? Do they think it helped keep the beeb market alive? etc...


Oh and as for easy conversions, would anyone be interested in converting Yar's Revenge from the Atari 2600? It should be pretty easy (not easy enough for me!) and it's a great simple game!

See someone did thrust on the 2600 not long back? Top job!

What's even more spectacular is that he managed to do it on the Electron too! (Even though the inlay stated BBC only ... there was in fact an Elk port on the reverse side of the cassette!)

It did originally have a sticker advertising the electron version didn't it...?

I started my Acorn computing on an Elk and have a really great fondness for it I don't regret it's creation at all, without it as an entry point I doubt I'd have upgraded to a Master when I was earning my own money. Which would have meant I wouldn't have had my Archimedes and wouldn't be here now !

I've ran this on the emulator, it's looks a bit pixely for me. But I'm also viewing on a LCD though, Cubs and TV's display Mode 2 much better due to their fuzzyness

Well, I had two copies of 3D Pool, and neither had that sticker on it.

I sent my spare copy to Dave E @ Acorn Electron world (which, incidentally, is the source of the cover scan you've linked to) so I /think/ Dave might have actually slapped that label on himself!

But then again, he could have easily acquired a second, stickered copy from someplace else.

Yeah I have designed repton 1, 2, 3 levels for superior interactive; the caverns scenario took me ages. I also created a level for pipeline with its own scripts.
I would be happy to help with the graphics and game testing as long as fits in with my other commitments. Count me in!.
Maybe you should approach Orlando and get him involved. I emailed him 3/4 years ago asking for help regarding sprite plotting and fire track scrolling and he was always happy to reply.

Dave, some programmers prefer to work alone but may need help e.g with music or title screens. For example if somebody is an amateur programmer then they might feel working with a very experienced/talents programmer wouldn't be very effective.

My mad skillz on the beeb have always been a bit limited, however, if someone can provide some direction (or a level editor), I guess designing levels might be within my grasp, if that's any use?

Is this a BBC tracker program? How much memory does it use to run in the background?

Background Beeb music is interesting - I often wonder how the Spellbinder music worked.

FWIW I think the pper limit initially should be a BBC B with SRAM and shadow RAM with a slightly cut-down version for the BBC B like Exile. If anything can be loaded the disk can be used (ad infinitum on RISC OS Beeb emulators).

Somebody did Doom on it didn't they?!

Thinking of Hostages (and apparently Beverly Hills Cop) couldn't Doom be done in some way on a BBC?

Hurrah!


Great idea ... though I've never actually been in contact with Nick.

So if you're already in touch, perhaps you could approach him on our behalf?

Say, what do you think the chances would be of him releasing the sources behind Frak, Zalaga, Firetrack, 3D Pool etc? (that's assuming he still has them).

Btw, I've just received a message from Kevin Edwards, and he's willing to release the source code for Galaforce 1 & 2 to help us out. I'm sure the routines contained within should be of great interest/benefit to our new programming team! (remember they also contain Martin Galway's awesome music code/music data, so I can see these being a real inspiration too!)

cool, it would be interesting if Kevin would let me do a commercial protection with him getting royalties.

edit: oh, did he find his protection sources he was going to look up?

Man, I would love to get a copy of that!

Kind regards,

Francis.

It's for the BEEB, I've not seen the code but from what Rich has said it's a carefully timed interrupt driven routine that plays music in the background and will allow games that uses various jiggery pokery with interrupts to get better screen displays to work OK.

What about reduced/split screen e.g. Nutcraka? That could free up 16K in Mode 1.

That sounds like a more than excellent start for someone writing a shoot-em-up based game, that's really generous and will save someone loads of dev time.

Haha, my "music tracker" seems to have reached mythical status! But this is really far too grand a term It's just a nice, optimised routine which you can sit in an interrupt handler (e.g. VSync), point it at some music data, and it'll play it in the background. It accesses the sound chip directly because I wanted to have more careful control over its performance (particularly since I'm doing delicate interrupt timing elsewhere), and the OS sound routines are updated at 100Hz (which is more frequent than necessary) and are not optimal enough.

There's no editor to create the music; my two tunes are literally built out of DATA statements in Basic, though they are to a degree human-readable. I seem to remember it goes something like this:


(Name that tune!)

I was trying to find ways to keep the music data as small as possible... I think I settled on this idea of sequences, the thought being that where you identify commonly repeating themes in the melody, you assign them to a sequence, and then you can insert this sequence into the channel stream at any point with just a single byte - kind of like a macro really.

The other thing was that both my tunes used the tuned periodic noise channel to provide a "bassline" (e.g. the tunes from Icarus, Dunjunz etc) so there's no support in my code for white noise (drums!).

You could define "envelopes" which were a rather more basic version of the OS ENVELOPE stuff, but which I used for basic pitch tremolo and fast arpeggios (to create "chords" on one channel), as well as basic control of notes' attack and decay.

Incidentally, Matt and I used almost exactly this approach for the music in "Frogman", but I lost the source code, so ended up re-inventing it from scratch in no doubt the exact same way!

I've been invited to take part in this by stairwaytohell. I'd like to have some involvement, but I have some doubts about whether I could contribute anything useful.

As a graphic designer, 3D animator and occasional composer, things have changed quite a bit since my former Beeb days. Like everyone else, I'm rather spoilt nowadays with high-end graphics software, MIDI gear and the like.

Because I started out on the Beeb however, I'm familiar with some aspects of its technical limitations - mainly those relating to graphics and sound. The question is how anything I produce (be it title screens, frames of animation, music or whatever) might be implemented into a game. If it requires me to do actual coding, I haven't programmed a Beeb in almost 20 years (and the games I made were usually on the severely crappy side or heavily edited versions of book listings or commercial releases). I'm not sure how much of my former knowledge I could regain! Add to that the possible problems attached to working with an emulator as opposed to an actual BBC computer. The time factor is also an issue, since I'm eye deep in my animation degree Honours year at the mo.

It would be amazing to return to working on Beeb games again, but at this stage I can't say for sure whether I can offer anything without more info.

Looks nice and simple!

Kind regards,

Francis.

hahaha, if only...

the Atari version was a hoax - see here

and as for Doom on the BBC, heh well maybe you should see this?

in other news i think i've been drafted for this project
as i said to Mr Stairway, i never really got out of BASIC programming but perhaps i could do something graphical... i'll see about dragging my sprite designer up as that was for MODE1 and pretty decent.

in answer to his other question then no i can't actually draw but i'm very handy at 256colour pixel art so spriting would be as far as i could go.

Beeby, Pretty sure you'd need to find a custom graphics editor or write one and understand the save format. As I said before, there's one in The Micro User aroud 1992 by Mike Goldberg and he shows how to plot it and animate it in BASIC. You'd need to have a look at the screen memory layout on the Beeb to understand how the data was saved.

Not on a PC at the moment - I take it it's a mock-up?

Ok, well here's the latest copy of the 'Team Sheet':




If anybody thinks that I'm really dropping them in it i.e. I've put your name down against something you haven't actually agreed to (which is quite possible! ) then feel free to hurl some abuse at me via PM and I'll amend as necessary!


So like ... erm ... I don't suppose you fancy taking up the challenge of trying to create some kind of PC-based convertor? Maybe you could work together with Francis?

I think there would be two main stages, though I don't know which should come first:

- Util to convert from Sega VGM File > Individual Sega VGM File > Individual BBC VGM File (no point filling the Beeb's memory with 10 tracks when only 1 needs to be played at a time!)

- Util to take a BBC VGM File and produce BBC Micro code to play it back on an actual BBC (i.e. it spits out a standard playback routine then automatically generates the necessary DATA statements). I acknowledge this won't be anywhere near as easy as I've made it sound!

Maybe if Rich were to be kind enough to supply you and Francis a copy of his mythical(!) music engine, you'd be able to evaluate the feasibility of transferring a "BBC" VGM file to "RTW" format?


Oh, I'm not suggesting that from now on, everyone should work in a team. If people want to work alone then great!

I guess what I'm really trying to achieve is the following:

a) formal list of what's in development

b) establish a 'pool' of creative talent, to lend a hand to programmers if requested

c) encourage knowledge sharing, project updates and feedback (hopefully if developers see a lot of interest in their project, it will keep them focussed on the job!! Incidentally, I think this is already the longest STH thread yet!)

d) convince any would-be programmers that they could expect a very 'professional' (though not necessarily commercial) release. I realise I haven't managed this yet, but I'm working on it!


Well, as you can see you're on the team, along with Kecske and Alf Stewart!

That all looks good to me Dave. Also Swift is very very close to an initial release that is quite rounded, so much so It's probably going to start at release version 1 rather than 0.x etc. And I'm hoping it has enough features to persuade Rich TW to convert his existing code to the new format, which I don't think will be as hard as may appear. If required I may be able to write a simple converter that may help some.

So barring disasters, should be released Sunday evening (hopes !)

You can mark me down for any loading/title screen conversions!

I've got more of an affinity for mode 2 I must say.

Very good points Dave!

Oh, Mother Duck. What have I let myself in for ...

Btw, if you are planning to setup a separate community / website, I do actually have web programming skills (as opposed to any useful beeb ones ) - if I can help out in that regard, I'd be on much more comfortable ground ... (used to be a Perl guy until I got caught up in the murky world of telecoms and VoIP).

Sam.