PLASMA virtual machine

[SteveF]

This all sounds really cool. Have you had any thoughts about what your scripting language will look like yet? Would it be something vaguely along the lines of TADS or Inform?

[shifters74]

Not settled on anything specific, but it needs to be fairly simple (TADS and Inform are too complex). I will take a look at ALPS and QUILL for ideas and probably produce something similar but tailored more to MUD rather than adventures.

The bulk of the object types will be implemented in PLASMA, e.g. Messages, Locations, Users, Objects, NPC's etc with the scripting language being used to conditionally modify those 'types' to create quests/puzzles/ etc.

There are built in engine commands for the usual stuff but additional game commands can be implemented via the script for the unique requirements of the game.

cheers

Shifters

[shifters74]

I am thinking of using this book: https://www.packtpub.com/product/build- ... 1800204805

And creating a language and byte code with the VM in PLASMA.

cheers

shifters

[shifters74]

Hi Steve,

have you any tests that save a data from PLASMA to disk?

I am trying to save to econet (where i loaded the file from) and keep getting 'Insufficient Access' error and the applications bombs out.

This is the code i use:

Code: Select all

export def save_avatars(file_name)#1
    byte werror
    word file, counter

    #ifdef DIAG_AVTR
        byte index
    #endif

    werror = 0

    // remove the current AVTRFILE
    // TBD maybe rename it???
    fileio:destroy(file_name)

    // create a new one
    fileio:create(file_name, $00, $0000)
    // open the newly created file
    file = fileio:open(file_name)

    // if we failed to open the new file
    if file == 0
        werror = 1
    else
        // file was opened for writing
        counter = 0

        repeat

            jim_set_page(counter & 255, counter >> 8, Avatar16MBank)

            // if we failed to write out the 256 bytes of the record
            if fileio:write(file, 256, JIM_DATA_START) <> 256
                // indicate an error
                werror = 1
            else
                counter++

                #ifdef DIAG_AVTR
                    puts("Avatar: ")
                    puti(counter)
                    puts(" : ")
                    for index = 0 to t_avatar
                        putb(^(JIM_DATA_START+index))
                    next
                    putln()
                #endif
            fin

        until counter == avatar_counter AND werror == 0

        fileio:close(file)

    fin

    // if we had a error writting to disk - say so as DB is LOST!
    if werror
        mess_put(AvtrFileWriteError)

    #ifdef DIAG_AVTR
    else
        puts("Avatar File Written")
    #endif
    fin

    return werror
end

Any ideas?

thanks

Shifters

[SteveF]

I have lots of suggestions but no answers here, sorry!

bench2.pla does writes using fileio in storefileio(). It uses filename "X.TEST" so if you want to try that on Econet you may need to tweak the code or create an X subdirectory. It might be good to confirm bench2 works for you on DFS which whichever version of the PLASMA VM you're using as well, just as a sanity check.

Can you run your code (or a cut down test version of it which still breaks on Econet) on DFS? I am wondering if I'm doing something subtly broken in the fileio library implementation which is upsetting NFS.

It might be a good idea to try to break the problem down, something like this:

• Modify your code to just do the fileio:create() call and exit. Then try to open the file in BASIC using OPENUP - does that work?
• If it does, modify your code to assume the fileio:create() call has already taken place and just do fileio:open() on it - does that work?
• fileio:create() is (I think; I'm not 100% sure) part of the fileio API and you "should" call it before doing fileio:open(), but on the Acorn implementation it's not necessary, so you could also temporarily try not doing that.
• Add some debug print commands to your code to narrow down which fileio call the "Insufficient Access" error is being generated from.

It's definitely not the problem here, but FWIW I think you should be testing the return value from fileio:close() in theory. In reality on Acorn it's likely to generate an OS error instead of returning (which isn't standard, but I haven't fixed this behaviour yet) so it won't matter in practice.

Please try the above and let me know how you get on and then we can take it from there.

[shifters74]

HI Steve,

i failed the sanity check!

Your Bench2 worked fine - my code failed. It looked like it was crashing out in fileio:create in my code BUT it was the parameters to fileio:write that i had wrong which i saw once i reread bench2 source (after going through the advanced user guide and the fileio.pla source with a fine toothcomb!) etc

The source (which works fine) is now

Code: Select all

export def save_avatars(file_name)#1
    byte werror
    word file, counter

    #ifdef DIAG_AVTR
        byte index
    #endif

    werror = 0

    // remove the current AVTRFILE
    // TBD maybe rename it???
    // fileio:destroy(file_name)

    // create a new one
    puts("\nCreate new AVTRFILE: ")
    fileio:create(file_name, $04, $0000)

    // open the newly created file
    file = fileio:open(file_name)

    #ifdef DIAG_AVTR
        puts("Open file for writing: ")
        putb(file)
        putln()
    #endif

    // if we failed to open the new file
    if file == 0
        werror = 1
    else
        // file was opened for writing
        counter = 0

        repeat

            jim_set_page(counter & 255, counter >> 8, Avatar16MBank)

            // if we failed to write out the 256 bytes of the record
            if fileio:write(file, JIM_DATA_START, 256) <> 256
                #ifdef DIAG_AVTR
                    puts("\nFailed to write to AVTRFILE")
                #endif
                // indicate an error
                werror = 1
            else
                counter++

                #ifdef DIAG_AVTR
                    puts("Avatar: ")
                    puti(counter)
                    puts(" : ")
                    for index = 0 to t_avatar
                        putb(^(JIM_DATA_START+index))
                    next
                    putln()
                #endif
            fin

        until counter == avatar_counter AND werror == 0

        if fileio:close(file) <> 0
            #ifdef DIAG_AVTR
                puts("\nFailed to close AVTRFILE")
            #endif
            werror = 1
        fin

    fin

    // if we had a error writting to disk - say so as DB is LOST!
    if werror
        mess_put(AvtrFileWriteError)

    #ifdef DIAG_AVTR
    else
        puts("Avatar File Written")
    #endif
    fin

    return werror
end

Thanks for the advice!

cheers

shifters

[SteveF]

Nice one, well done! I wish I'd spotted that myself, the error message just seemed to point to problems with the create/open rather than the write so I went chasing off in the wrong direction...

[SteveF]

I've merged the latest upstream changes to the Acorn port, which is tagged on github as stardot10.

Of particular interest are changes inspired by shifters74's problems earlier in this thread - thanks to Dave for taking a look at these!

• It's now possible for a module to include its own header (somewhat analogous to foo.c doing #include "foo.h" in C), which used to create a circular dependency. This should make it easier to avoid repeating code between the module's header and its own code. See https://github.com/dschmenk/PLASMA/issues/66 for discussion on this.
• Exported symbols in modules now have 32 significant characters instead of 16, and symbol names will be truncated to 32 characters internally for linking purposes if they're longer than that. See https://github.com/dschmenk/PLASMA/issues/65 for discussion on this.

I am a bit pushed for time at the moment so this tagged version is even less tested than usual, but it does seem to work as far as I've tried it. I'm happy to receive feedback and offer advice in this thread as usual, but please be aware I might not be able to do much more than that.

[shifters74]

Ah nice one!

That some very useful changes!!

Thanks for all the work getting this release out!

cheers

Shifters

[nicolagiacobbe]

Ah, very good new someone is working on it. Bravo. I am always hoping to start building something with it.

[shifters74]

Hi SteveF,

Coprocessor 24 (and others) support 2 meg of ram paged in and out in 8k chunks at each 8k from $0. Is it possible with plasma running on a coprocessor to have a tuneable himem point so for example I could free e000 to ffff or c000 to dfff ( maybe better as it avoids fee0 and up?) and use that as a data page - paging 8k in and out as I need it? This would be used for app data not plasma variables of course.

I do that with Jim ram on the 1mhz interface and can see a real use if the 2meg on the copro24 could be used in the same way but with an 8k window rather than 256 bytes window that Jim gives you. Speed of the jitcopro is of course another bonus!

I know your busy on other projects but I know you like to keep busy!

Thanks

Shifters

[julians]

Coprocessor 24 (and others) support 2 meg of ram paged in and out in 8k chunks at each 8k from $0.
Shifters

Might be one for a different thread (possibly discussing my failure to RTFM...), but I didn't realise this was possible - would you point me in the direction of any documentation or examples on how to do this?

Julian.

[shifters74]

See this thread viewtopic.php?f=3&t=25925&p=377323#p377323

Shifters

[julians]

See this thread viewtopic.php?f=3&t=25925&p=377323#p377323

Shifters

Thanks - I'd missed that thread, will have a read of that this evening.

Julian.

[SteveF]

Coprocessor 24 (and others) support 2 meg of ram paged in and out in 8k chunks at each 8k from $0. Is it possible with plasma running on a coprocessor to have a tuneable himem point so for example I could free e000 to ffff or c000 to dfff ( maybe better as it avoids fee0 and up?) and use that as a data page - paging 8k in and out as I need it? This would be used for app data not plasma variables of course.

Hi Shifters,

This is a neat idea. The simplest way to experiment with this on the tube would be to modify TUBERAMTOP or TUBEJITHEAPTOP in vmsrc/acorn/vmconstants.inc and rebuild your VM. If you get on well with it, we could consider some "official" way to change this, although it is a little bit tricky because these constants need to be available very early in the setup of the virtual machine so it's not likely to be practical to offer a library function a program can call to change this.

Disclaimer: I haven't actually tried this, but I really can't see why it wouldn't work. If you give it a go and get stuck, please let me know. Edit: Also, if things do seem not to be working, please try the non-JIT VM as it's obviously simpler.

Cheers!

Steve

[shifters74]

Hi Steve,

I am trying to compile stardot10 but keep getting the following error

acme --setpc 4094 -o samplesrc/acorn/hanoir.mo samplesrc/acorn/hanoir.a
Error: Cannot open toplevel file "samplesrc/acorn/hanoir.a".
make: *** [makefile:579: rel/acorn/HANOIR] Error 1

There is no hanoir.a file - any idea?

My PLASMA-rom build still works fine (compiling the ssd's etc) but i can't get stardot10 to build either doing a checkout of the branch of just downloading the src tree from the link you posted. As i would like to try the changes in stardot10 any suggests on why it doesnt build?

thanks

Shifters

[SteveF]

Ooops! I suspect this was introduced when I converted the makefile to account for the plasma compiler no longer outputting to stdout by default (although my memory may be faulty there). This worked for me because the hanoir.a file was still present on my local copy of the repo so the fact it wasn't being built correctly didn't break the build.

I've pushed a fix and tagged it stardot11, please have another go with that.

HANOIR is just a slightly hacky build of the Towers of Hanoi demo program as a language ROM. You could probably just have deleted all references to it in the makefile and vmsrc/acorn/demo.beebasm and everything else would have built fine - I haven't tried this, but worth bearing in mind if something like this happens again. (But obviously, please tell me as well so I can fix it properly. And thanks for reporting this!)

[shifters74]

Hi SteveF,

yes that builds fine from a fresh source download - many thanks for the quick fix!

Will try modifying the defines for himem in the next few days and recompile my own local 'PLASMA Special' and give it a whirl.

cheers as always!

Shifters