I don't intend this to be a daily blog of progress made but I will chip in with important milestones when they are met.

I have decided to convert the Frotz source code into BBC BASIC just to get something up and running in a short space of time.

Depending how quick/slow the BASIC code runs, I may end up converting the main interpreter code into 6502.

After a few hours coding tonight, I have managed to write 316 lines of code and am well on the way to getting something printed on screen.

The main interpreter code is very similar in structure to a typical CPU emulator in that it uses opcodes and operands like a normal CPU. There are about 100 different opcodes the interpreter needs to understand so it is just a matter a ploughing through and writing a separate DEFPROC for each opcode.

I'll crack on padding out the opcodes tomorrow and post back when I have text displaying on screen.

Jon.

Wow.

Just wow.

Sam.

Oh, I assume you found the latest sources:

http://frotz.homeunix.org/frotz/

Looking further into it, I think the traditional older 8-bit micros had interpreters which would run Z-Machine version 3 games.

Ideally, it would be great if we could get the interpreter to run the v3 Infocom games and also work out how to write modern games in Inform and compile them to run on the beeb (memory/disk limitations withstanding). I'm looking at Inform now to see if it can compile to the earlier format ... but atm I'm only finding references to it compiling down to v5 Z-Machines.

Sam.

P.S. Added more standards-links to the earlier thread.

Ah - found a reference in the Inform 6 Designer's Manual, fourth edition which appears to reveal that Inform can compile down to Z-Machine v3, which is what I assume you're aiming for.

As far as commercial games go, that should allow us to run the following Infocom v3 games on the Beeb, I think:

Zork I
Zork II
Deadline
Zork III
Starcross
Suspended
The Witness
Planetfall
Enchanter
Infidel
Sorcerer
Seastalker
Cutthroats
Hitchhiker's Guide to the Galaxy
Suspect
Wishbringer
Spellbreaker
Ballyhoo
Leather Goddesses of Phobos
Moonmist
Hollywood Hijinx
Stationfall
The Lurking Horror
Plundered Hearts

Plus any other .z3 games we can find ...

Sam.

I said I'd post back when I got something displaying on screen so here I am again.

Click the link to download a short movie of Zork loading up.

http://www.g7jjf.com/public/zork.zip

Now, you will have to wait a bit cos it is verrrrryyyyy slow in BBC BASIC.

But once I get it working, I will convert to 6502 for a much needed speed increase.

At the moment, the BASIC prog is huge and needs HIBASIC in a 6502 co-pro to run but this will of course reduce in size once the 6502 conversion is underway.

The code is based on the latest frotz 2.43 code and should theoreticallly support up to version 8 of the z-machine but I will probably limit it to version 3 for the moment.

But it's way past my bed time for tonight so more as and when I have something to report.

Jon.

Not sure how to play the movie file - after unzipping it, it has no extension and Windows Media Player doesn't like it, though I haven't tried under Linux yet.

Is it a Mac-specific file?

Sounds like a huge amount of progress if you've got text showing, considering you only started it yesterday!

I did assume that 6502 would be required, which is why I've never picked the project up myself - my assembler skills are pretty limited.

I updated my earlier links thread with some revised standards document links as it appears the links I got from the Inform v6 site are slightly out of date. The Z-Machine v1.1 standard, for instance, was accepted back in 2005 and should, I think, be the standard Frotz is built to. I think the linked documents should therefore complement the Frotz code you're posting ...

There's also links to the save game and blorb standards, which would be nice-to-have features. Though they may come in with the Frotz codebase?

I think v3 would be a sensible limitation because it limits the size of the story file to 128K, the number of objects to 255, the attributes to 32 and properties to 31, which is probably about right for a beeb adventure.

Sam.

If you want to test the code in BASIC without having to put up with the speed/memory restrictions of a BBC then you can probably run it using the Brandy interpreter:

http://jaguar.orpheusweb.co.uk/branpage.html

However there are a couple of bugs in the current version that you'd need to be aware of, so you'd have to be comfortable recompiling the code if the bugs are going to affect you:

Give it a .mov extension and it should work (it does for me).

You're certainly right when you said it was slow

Wow. Yes .. A BASIC interpreter really isn't going to cut it, huh?

I just found two or three Z-Machine Testers/Compliance Checkers, which may be of use for testing a Z-Machine interpreter.

http://ifarchive.heanet.ie/indexes/if-a ... tools.html

Two include Inform source code. That should hopefully make it easier to find bugs than with an actual story file ...

Sam.

Another update ....

After adding more code, it soon became apparent that I was rapidly running out of memory space, even using HIBASIC with it's 48K of RAM.

So, I moved over onto the ARM Co-Pro and used ARM BASIC instead.

As well as running at 8MHz, it gives me 4MB of RAM which should be enough to finish off the BASIC code !

So, after a few more hours of bashing away at the keyboard, I can now enter commands and effectively play the adventures !

It's still a little slow but much more playable than the earlier movie.

Try this one :

http://www.g7jjf.com/public/zork1.zip

There are still a few z-code operations to finish off but the BASIC conversion should be complete by the weekend.

I have also tried THHGTTG and this seems to work OK as well.

Jon.

BTW - 42 Today !

Yep, I never really thought BASIC would be a viable option - well, not unless you had one of those fancy ARM co-pros hanging around ... Actually, that said - the current speed of the video is probably about as fast as games like The Hobbit and The Lord of the Rings: Game One used to run on the beeb. They always slowed down dramatically to decode text.

I have actually discovered the PORTING instructions for Frotz. They contain a copy of an email from Brian Moriarty, author of Wishbringer, who seems quite negative about the chances of porting Frotz to a C64 due to RAM, display or disk drive restrictions. That doesn't bode well to the idea of fitting it into a bog-standard beeb. I sincerely hope you can prove him wrong!

It's amazing to see the progress you're making, watching that video. The only difference I could see between your video and playing Zork on a fully functional, modern Z-machine interpreter is the missing status bar (which is just normal text in yours) and the speed. Other than that, it almost looks finished! (obviously, I know it's not! lol).



Assuming this isn't an April Fool, you mean it's your birthday? Congrats, but isn't it a bit spooky that you just got The Hitchhiker's Guide To The Galaxy working today?!

I assume you realise there is ARM Co-Pro support in BeebEm ? I don't have the actual hardware to play with

The code at the moment is very verbose and there is ample room to increase the speed, even in BASIC. I want to getting it working first before starting to optimise it.

The lack of RAM on a Beeb may be a problem. On the Beeb version, I was reading/writing game code straight from disc. This reduces the memory footprint of the game to nil but may be slow when used on a real beeb. I could page chunks into memory with some sort of virtual memory manager but the game code can jump around so you may end up paging more often than not. Something to look at later.

In the current version, the screen layout still needs sorting. I need to get the status bar at the top of the screen as well as splitting lines at word boundaries when displaying text. Nothing too hard but just need doing.

And yes, today is my bday. And here's me coding into the small hours again when I should be across the road in the pub drinking some beer !

Now there's dedication for you.

Jon.

Yeah, I was kidding about the ARM co-pro.

It was the lack of RAM which made me balk a little when I read Brian's comments. Good to hear leaving the game code on disk is one option. I guess if things really got tight, you could always target the Master 128 only, though that would be a shame. For the record, if it helps you plan the size out, the largest Infocom v3 adventures I've found have data files that are 153,600 bytes long (they are Infocom's Spellbreaker, Ballyhoo, Moonmist, StationFall and The Lurking Horror).

Coding instead of beer on your birthday? That is nuts! I tell you what, if you do enable me to play my Infocom collection and Inform-compiled adventures on a beeb, I'll definitely owe you a beer.

Sam.

Hmm... sadly the free version of Dungeon is encoded as a v5 machine and is 188928 bytes long, which looks pretty large to me ... that's a shame. Peter Killworth's Last Days of Doom is v5 and 200192 bytes!!!

Sam.