Having just sorted out Mode emulation problems it seems that using 6502em will be feasible again personally. The good thing about 6502em is that it treats the host hard disk as the native computer does effectively giving the Beeb limitless storage - not sure how many other emulators do that. !Beebit I think do it via an add-on called !BFS but it's less convenient.

I don't think many people realise this but on RISC OS Beeb emulators it's possible to create games with infinite disk space and instant access.

This is good for text adventures for a start (although accepted text adventures probably should be within certain confines as DaveE from Acornelectron.co.uk pointed out I think) but imagine the possibilities for graphical games. The graphics could be loaded almost instantaneously being slowed only by the 6502 emulation itself and repeatedly giving the illusion of vast stores of graphics. Or it could be used to load in a standard amount of graphics above a particularly long program or program and music.

The only downside would be distribution - it might be too big for an SSD or DSD.

b-but.... then you might as well just code it to run natively in RISC OS!

It seems strange to choose the Beeb platform, with its limited spec and all the challenges it presents, but then to 'cheat' by using an emulator feature which would prevent it from running on a real Beeb, or even other emulators!

(Well, I'm a purist! )

If you can't get all your data onto a 100k or 200k DFS disc, wouldn't your title perhaps be better running under RISC OS?

Or you could have it as a multi-disc title.

Kind regards,

Francis.

I agree with Rich. If you need more oomph, I can see you writing a Master-specific game (or a game with Master enhancements), but that's not the same thing.

If a DFS disk is too small, an ADFS disk might do the trick.

Anything bigger than that, tho, and I think the project design needs looking at again ...

My 2p's worth,

Sam.

But I'm thinking that people have been bringing out IDE interfaces and 200MB harddrives for BBCs so surely there's some interest? The main idea was to push the Beeb beyond what was possible previously to get even more from the machine itself.

After all, isn't the most important part what the BBC can do with the data it receives? For all it cares the BBC could be connected to a CD and that has been suggested.

The only problem with multidisk is that in an emulator it might even be more cumbersome changing disk than on a real machine.

Saying that, if a DSD is 200k(?) then as people suggest 400K of instant access (e.g. loading 2 disk images in Beebit) would be possible. However you'd have to take all the data from the harddrive and section it onto 4 "sides" after development then implement drive switching in the main program.

Thoughts?

Hmm ... I'm not so sure.

People tend to do things with hardware and software which make life easier for running such a retro system. Hardware add-ons like IDE hard disk drives, GoMMC and even CD-ROMs are great technical feats, and they make managing huge amounts of software much easier - no more maintaining hundreds of less-reliable floppy disks. Similarly, the Retro Software PC tools like BeebAsm, SWIFT and the BBC Micro Image Converter are great for making retro development much easier.

But even with those modern extras - the goal is still to develop and run for the original target system, and a typical BBC Micro generally only has access to DFS or ADFS for it's storage system.

A standard Acorn DFS double-sided .DSD disk image, btw, can hold 400 KB (less 1 KB for the DFS catalogue), I think. If you need more than that, I think ADFS will go up to about 640 KB. If that's still not enough, I'd be asking questions about what exactly you were trying to achieve with the project and whether you're doing it the right way ...

Sam.