Adventure games to put to disc.

[leenew]

Hi there,
Can anyone put these UEF's of various adventure games to Disc?
I believe they are not on disc anywhere in the archives.
(feel free to correct me as I am the worst at searching )

Demon Knight by ASP
Dr. Who And The Warlord by BBC Soft
Mystery of the Lost Sheep by Central Computing
Not a Penny More, Not a Penny Less by Domark
The Hobbit (Version 2.0) by Melbourne House

**I believe BillC may have a disc version of "Not a Penny More"... Am I right Bill?

And, while we are at it... can anyone extract Quest of Gondor by Doctor Soft
and Operation Safras by Shards from Pernod's Adventure disc 08 to standard SSD's?
(They require Watford 62 filename DFS as it stands..)

PEAD08.zip

(268.09 KiB) Downloaded 74 times

Adventures.zip

(193.09 KiB) Downloaded 77 times

Thanks all,
Lee.

[MartinB]

Hi Lee

I've converted the complete disc to standard Acorn DFS. Is that what you want and if so, can you check it's ok?

PEAD08a.zip

(273.4 KiB) Downloaded 72 times

[Arcadian]

Dr Who & The Warlord is already here:
http://www.stairwaytohell.com/bbc/archi ... arlord.zip

[leenew]

Thanks for Dr. Who and the Warlord Dave

Thanks for converting the Watford Disc to DFS Martin, that's one step easier.
What I am wanting now is for the files from Gondor and Safras to be pulled off this disk to make stand-alone SSD's of each game.

Lee.

**It looks like SAFRAS has problems with BeebEm too (similar to the "Alien from Outta Space" graphics glitches...**

[duikkie]

why stand-alone ssd's ?? do you know how much a disc cost in the 80's and today ??

is everything working on a real beeb ?? or is it not playeble ??
maybe i have to look with my pirate eye ??

Thanks for Dr. Who and the Warlord Dave

Thanks for converting the Watford Disc to DFS Martin, that's one step easier.
What I am wanting now is for the files from Gondor and Safras to be pulled off this disk to make stand-alone SSD's of each game.

Lee.

**It looks like SAFRAS has problems with BeebEm too (similar to the "Alien from Outta Space" graphics glitches...**

[MartinB]

What I am wanting now is for the files from Gondor and Safras to be pulled off this disk to make stand-alone SSD's of each game.

Ok, here you go then. (In Beebem, Safras does have some screen memory access showing as you say, not tried with a real Beeb.)

gondor.zip

(13.73 KiB) Downloaded 70 times

safras.zip

(17.46 KiB) Downloaded 75 times

[duikkie]

as normal i can't even play the game , well what ??

the game safras on real beeb pauze a little while before starting
so i think the screen mode is turned off for a while , to load and download the game in memory. after break the beeb gives the stanges things on screen , what you get when playing with memory like d00.. 1100 or lower 0000.. 0800

What I am wanting now is for the files from Gondor and Safras to be pulled off this disk to make stand-alone SSD's of each game.

Ok, here you go then. (In Beebem, Safras does have some screen memory access showing as you say, not tried with a real Beeb.)

gondor.zip

safras.zip

[leenew]

Hi Duikkie,
The reason for separate ssd is just for the archives. Eventually all games will be available individually as well as on Compilation discs. It is also easier to make your own Compilation if all the files needed to make a game are easy to see on a ssd.

@MartinB - Thank you. I will look at them after work.
@everyone - I see 6 people took the ssd challenge but only 3 took the uef challenge

Lee

[duikkie]

safras is terible programming again !!!

>>>>>>> is this the original files ?? <<<<<<<<<<<<<



look at srun and sarfas they are both basic programs
why someone put srun with line 20 chain "safras"in it ??
i see no reason why you have a file srun
sarfas is for the begin title the real program starts with adv1

and what i see in adv1 my hairs in my neck are rising again

the hole "game"can problely go in 1 file , because adv1 loads first all other files in memory and then starts ??

Hi Duikkie,
The reason for separate ssd is just for the archives. Eventually all games will be available individually as well as on Compilation discs. It is also easier to make your own Compilation if all the files needed to make a game are easy to see on a ssd.

@MartinB - Thank you. I will look at them after work.
@everyone - I see 6 people took the ssd challenge but only 3 took the uef challenge

Lee

[MartinB]

You're very abrupt aren't you duikkie...

I put the extra BASIC two-liners in. You will see I did the same for the Gondor disc because if you don't do this, it won't work. A !BOOT *EXEC doesn't come for free and is equivalent to having one file open which often causes subtle problems for low-loading programs. It causes Gondor to fail. I did the same for Safras because why not - there's room on the disc and it's the safest method.

Like most people, I used to spend hours hacking and cracking so I am aware of all the techniques but I prefer to develop my own stuff these days, it's more of a challenge.

[leenew]

Hi,
Back from work
Yep, those both work, thanks Martin

I think you have inadvertently answered a question I didn't really ask...
I sometimes was left scratching my head when a simple program just didn't work when put to disc.
Sometimes, a *TAPE before the relocate cured a few, and I am sure the CLOSE#0 may have cured a few more

Lee.

[MartinB]

Hey, no worries - I actually did very little. I was just twiddling my thumbs at bedtime when I saw your post and because the job looked really easy, I thought I'd help out...

As duikkie says, the programs could probably be rationalised but why bother when you can take the path of least resistance

That !BOOT effect has caught me out a few times - in the case of Gondor, it looks as if it's loading ok but then randomly fails whilst confusingly, a manual CHAIN of the same sequence works fine! Putting in a simple extra step to close down the EXEC often sorts this particular quirk of operation, especially where a program is being loaded really low down in the DFS work area.

[leenew]

Well ya learns sumthin' new ev'ry day
(Seeing as I have about 1000 of these to do, it may actually be the best tip I ever did learn )

Lee.

[MartinB]

Incidentally, *FX119 can be used in place of CLOSE#0 and is obviously better if you are working in assembler.

[duikkie]

did you allso do something to adv1 ?? because that is allso very strange ??
at 5600 jmp 624a and then do strange things ?? or is that from another remaker ??
in these day i can make it in 1 file , nothing to to with loading low- loading
loading from 1300 still 6b00 or someling like that downloading the 8c0-d00 part and than start the game.
but first i have to follow what is done wrong with the program.

You're very abrupt aren't you duikkie...

I put the extra BASIC two-liners in. You will see I did the same for the Gondor disc because if you don't do this, it won't work. A !BOOT *EXEC doesn't come for free and is equivalent to having one file open which often causes subtle problems for low-loading programs. It causes Gondor to fail. I did the same for Safras because why not - there's room on the disc and it's the safest method.

Like most people, I used to spend hours hacking and cracking so I am aware of all the techniques but I prefer to develop my own stuff these days, it's more of a challenge.

[richardtoohey]

A !BOOT *EXEC doesn't come for free and is equivalent to having one file open which often causes subtle problems for low-loading programs.

Is that because the file handle means it uses some memory between &1100 and &1900?

So (trying to work this through, will probably fail!)

*EXEC !BOOT (so handle open, memory in use in &1100-&1900 space)
Subsequent code loads in &1100 to &1900 and up
OS (?) decides to close the !BOOT handle and changes some bytes in that memory space? Leading to a corrupted program.

Or something more subtle than that?

[sweh]

There's that potential, yes. Each open file handle has a page from &11 upwards, and there's other data pointers.

The other is that with the EXEC filehandle open, random writes to that location could end up as keyboard input if you're not careful (this seems to impact "The Hobbit", definitely; it caught me out BITD but wasn't until a similar thread here that I realised why).

This is why a lot of my !BOOT files now read

Code: Select all

NEW
10CLOSE#0
20*FX21
30*HOBBIT
RUN


(line 30 varies according to need).

[richardtoohey]

with the EXEC filehandle open, random writes to that location could end up as keyboard input

I did a bit of and then figured it out (I think!).

You write in that space, and the OS thinks it has got input from the EXEC file to process (because you've just whacked some bytes into the still-open file's buffer), and the OS sends those bytes on by sending them as keyboard input?

[sweh]

Pretty much. Your filehandle is open and has read 30 bytes and then you overwrite the buffer then the read from location 31 is gonna be something random. Depending on how many bytes are left to read _or_ if you overwrite another data element (number of characters to be read from EXEC stream) and you could end up with lots of random input.

I never bothered to delved into the low levels (memory locations etc) 'cos the concept seemed reasonable and matched observed behaviour

[duikkie]

in my eye it is still bad programing
you can easyly make the close #0 and any fx calls in m/c code in the program
you want to run or load. but then i program things in mc code, and hardly in basic. the !boot is mostly for a chain"menu"program. as many programs in 1 file on the disc , in the 80's they cost a lot

it is always a good idea to close all files when starting things

There's that potential, yes. Each open file handle has a page from &11 upwards, and there's other data pointers.

The other is that with the EXEC filehandle open, random writes to that location could end up as keyboard input if you're not careful (this seems to impact "The Hobbit", definitely; it caught me out BITD but wasn't until a similar thread here that I realised why).

This is why a lot of my !BOOT files now read

Code: Select all

NEW
10CLOSE#0
20*FX21
30*HOBBIT
RUN


(line 30 varies according to need).

[MartinB]

Yes, Richard and Stephen, you've pretty much covered it. There's essentially the case where the loading program effectively corrupts the DFS space at $1100 onwards (which is in use for the boot *EXEC) causing an OS hang or invoking strange DFS behaviour and the then the second case where the DFS succeeds but effectively corrupts the program code or data just loaded in Page $11 with consequently variable effects on the program(s) being run.

Basically, if you ever have the head-scratcher where manual chaining (or *RUNning) of the first program in a sequence works fine but an identical auto !BOOT chain fails, expect this to be the problem. There are then lots of ways to address the issue, the easisest being the simple insertion of a new two-liner with a CLOSE#0 or *FX119 as I did.

why someone put srun with line 20 chain "safras"in it ??
i see no reason why you have a file srun

It's good that you learned something new

[duikkie]

why spill by saving more than to basic lines ?? like srun ?? if basic users like this i do care if i see it , i allways will remove it and use a !boot the *run option , with the close and fx calls and fuse buffer in m/c code.

if you mess with locations like 400-800 or lower and d00-1100 , you better use m/c code, put out the basic rom and you have the hole ram for your 6502 codes

but i have seen more strange thinks with basic language

Yes, Richard and Stephen, you've pretty much covered it. There's essentially the case where the loading program effectively corrupts the DFS space at $1100 onwards (which is in use for the boot *EXEC) causing an OS hang or invoking strange DFS behaviour and the then the second case where the DFS succeeds but effectively corrupts the program code or data just loaded in Page $11 with consequently variable effects on the program(s) being run.

Basically, if you ever have the head-scratcher where manual chaining (or *RUNning) of the first program in a sequence works fine but an identical auto !BOOT chain fails, expect this to be the problem. There are then lots of ways to address the issue, the easisest being the simple insertion of a new two-liner with a CLOSE#0 or *FX119 as I did.

why someone put srun with line 20 chain "safras"in it ??
i see no reason why you have a file srun

It's good that you learned something new

[duikkie]

oke i have safras in 1 file , but is there somewhere the original tape version ?

the break key pionts to a line that is not there so you see strange things when pressing the break key.

allso wrong is that is you press the red button's f0 till f9 , it goes wrong on screen

i can fix it but i see in adv1 lots of strange commando's in mc that is there because someone f*ck up the hole begining of the game.

[leenew]

I can't see either Gondor OR Safras in the tape archive
There are the other tape images in the first post of this thread, in uef format, to sort out too Duikkie if you are getting bored

Lee.

[duikkie]

BORED ??? i think i make myself difficult , but later i will post safras , have to go now , and disable software keys , maybe make the break key

what must you fill in by well if you are standing by the door ??
i am not a player

I can't see either Gondor OR Safras in the tape archive
There are the other tape images in the first post of this thread, in uef format, to sort out too Duikkie if you are getting bored

Lee.

[leenew]

He he he the solution is here: http://solutionarchive.com/file/id%2C3375/

Lee.

[duikkie]

oke i have a version with disable softkey input now

but still

WHAT was the code for diable the soft break key ???

and an error if you enter QUIT answer y/n if you answer y
then game starts again ??

[duikkie]

oke one file only safras

not totally happy with it
by break there is that rubbish line

when put in the text QUIT
and answer y it start all over , no prompt
>

[duikkie]

this is not working ??
jmp &d9cd locks up the beeb
if i put there a
RTS
it works
but the beeb is not clean
with *fx200,2 ??

i have a version "saf10t"
not fixed the quit part

intrest in saf10t ??

maybe this works ?

?&287=&4c
?&288=low
?&289=high

.highlow
lda #&12
jsr &fff4
lda #&c8
ldx #00
ldy #02
jsr &fff4
rts

jmp &d9cd

this is for the strange line input when area b00 is filled by mc code, and left behind.

[duikkie]

i uploaded the final fixed safras in topic games