file won't run in ADFS

[brianmartin_2001]

I have a file here ..It's one I downloaded from John Dale's excellent Flaxcottage archive.
It's a CEEFAX emulator recreating 80's frames (maybe some genuine pages from the early 1980's are there)
Whether it was built much later or not is no matter it's a great time capsule, and would be a great
addition if I could run it from within my BBS.

There are a couple of issues though. I have copied it over to ADFS and it won't run.
I can't get at the code and I suspect it is hard wired in the machine code to run DFS only.
I wouldn't know where to begin disassembing this though. I am little out of my depth.

A *INFO on the file gives

006000 006000 00129A 003

It's not a big file and the pages it carousels around are loaded frames from the disk.

My BBS Host theoretically can call this program. although I'd need to make sure is it doesn't
rob the Host of the dedicated memory workspace it uses , being

&70-&CFA and &7600 upwards ..HIMEM is set at &7600 and can't be changed.

In theory ( if I am correct ) I need to

Get the file to run in ADFS ( having copied over with CopyF it wont run).
There is an !BOOT file there to call the program, or type *FAX1982

Make sure it doesn't rob my BBS Host of any workspace when running.

Somehow create an interrupt or key press command to return to the BBS Host.
Essentially something which will execute a CHAIN command to recall the BBS.

I managed to get a MODE7 BASIC game to run within the BBS Host recently although
I did have to change some of the code particularly related to where some things where printing
on the screen. The program wouldn't display things normally so I expect there were some clashes
of screen workspace.

Any help much appreciated guys.

thanks
Brian

beebfax82.ssd

(200 KiB) Downloaded 13 times

[jgharston]

Yes, it is making explicit access to DFS for some reason. I copied it to a hard drive, and ran it, and the floppy drive jumped into life.

[flaxcottage]

The CeeFAX pages are stored directly on the disc surface. Copying the files to ADFS will not copy the data. It was done this way because DFS is limited to 31 entries in the catalogue and there are more than 29 CeeFAX pages viewable.

CommunITel did something similar to enable 195 Viewdata pages to reside on an 80T floppy. They, however, used a very large file, VWDB, that contained a proprietary direct access filing method. The disc you mention does not do this.

[brianmartin_2001]

Ah right , I m goosed then.

[WrightStuff]

The CeeFAX pages are stored directly on the disc surface. Copying the files to ADFS will not copy the data. It was done this way because DFS is limited to 31 entries in the catalogue and there are more than 29 CeeFAX pages viewable.

CommunITel did something similar to enable 195 Viewdata pages to reside on an 80T floppy. They, however, used a very large file, VWDB, that contained a proprietary direct access filing method. The disc you mention does not do this.

Just deduced the same thing after a bit of playing around.
Path of least resistance on this might be to find an alternate source of teletext pages and write your own viewer ?
Can but hope the original author is around on Stardot otherwise.

[jgharston]

There are two calls to OSWORD &7F - Direct FM disk sector access. NOP'ing them out results in no page data being displayed, so it looks like it's reading the page data direct from DFS disk sectors rather than from the file itself. Really kicking-users-in-the-nads as the page data is within the loaded file itself, so there is absolutely no need to do that other than shouting FUUUUUCCDFCVKKKKKJK YOUUOOUOUO to users.

Edit: more investigation shows the page data isn't in the loaded file, as mentioned above, it's stored in the disk sectors - I was looking at the disk image in a file editor. Again, a big FU to users. "HOW DARE YOU TRY AND MAKE USE OF MY PROGRAM, i'M GOING TO PISS YOU OFF AS MUCH AS i CAN". Just ***** put the data in a normal file and OPENIN() it.

[jgharston]

Here's the data in an actual file.

[brianmartin_2001]

JGH ,

Thanks very much for that..

Can you help point me in my next step in relation to
Trying to achieve what I first planned.

Is it possible with ADFS or am I beat ?

This is starting to look beyond my abilities.

Cheers

[Coeus]

I have not looked at the code but, to me, the correct approach to needing to have more teletext pages than the number of allowed files is to put them all in one file and then access that one file using the random access part of the filing system API.

In BASIC, this can be done with PTR#, PRINT# and INPUT#, though that would probably mean each page would need to be stored as a number of strings. That also means the pages need to be placed in the file by BASIC (via PRINT#), or at least something that can deal with its odd encoding in which strings are stored backwards.

In assembler, it would make more sense to use OSGBPB to read a section of the file. That enables both the location in the file, the destination in memory and the number of bytes to transfer to be specified in a single call. This can even be done from BASIC via CALL/USR and possibly writing a BASIC procedure to make constructing the control block easier. This is no harder than using OSWORD &7F to read a certain number of sectors into memory.

I also have no idea who the original author is, so this is speculation, but it may be more likely the author was trying to get higher performance than deliberately locking out users of non-DFS filing systems. It is yet another example, though, of someone having embraced DFS as the "one true filing system" and not been disciplined about accessing files in a way that is portable.

[BeebMaster]

BGET# in BASIC is the answer here to reading bytes, or blocks of bytes, from different positions in any file. INPUT# is only for files which have been created using PRINT# to write string or numeric variables to a file. Calling OSGBPB would be quicker than using BGET#.

[flaxcottage]

I have looked at the code JGH supplied.

The data are not straight Teletext codes. The pages appear to be coded using a proprietary method. This means that the bytes read from the file must be passed through a decoder to display the page properly. In this way a complete Teletext page of &400 bytes can be stored in &300 or &200 bytes.

For example the byte &80 seems to indicate that the following byte is output twice. A byte &00 stands for a space (&20) but what else does it do? Using these codes I can recreate the top line but then the codes &14, &1D and &17 appear. What do they do?

Without the interpreter these pages cannot be displayed from the Beeb82 file.

[BeebMaster]

Mmm, I see what you mean, though it does seem a bit pointless to use &80 to mean "next byte is duplicated", as the two bytes still take up two bytes!

[brianmartin_2001]

John ,

Thanks for looking into this. There actually are a bunch of these programs on your site. I really like them.

The author has really sewn this up though . Not only can I not run on ADFS there is an interpreter needed too which parses the frames so no point in extracting them. If I could get it untethered from DFS , remove any Mode7 calls in it so it doesn't crash my BBS program then I could just *RUN it in the right workspace it might be usable within the BBS host?

[tom_seddon]

The table of encoded page locations can be found at the end of the FAX1982 file, starting at +$b92. There are 2 bytes per entry, as follows:

Code: Select all

     7   6   5   4   3   2   1   0
   +---+---+---+---+---+---+---+---+
+0 | D | Track                     |
   +---+---+---+---+---+---+---+---+
+1 | Unknown       | Sector        |
   +---+---+---+---+---+---+---+---+

D is 0 for drive 0, or 1 for drive 2; Track is the track number; Sector is the start sector. (I think Unknown has something to do with the page linking, but I didn't end up investigating, as the pages seem to decode fine without paying attention to it.)

Read 4 sectors for each encoded page (not all the data will necessarily be used).

The encoding scheme is an RLE-type scheme, as follows:

$00-$7f - store verbatim
$80-$fe - store 2+(value&0x7f) copies of the following byte
$ff - stop decoding

Hopefully unpacked pages attached, a bunch of 1,000-byte Mode 7 screen dumps that might be suitable for *LOAD'ing at $7c00. (I've eyed a few of these using a hex dump and they look about right, but at your own risk! - I can't promise they will actually look right in real life.) If you're hoping to print them out with VDU commands you'll have to do some processing as the control codes typically don't have bit 7 set. Should just be a question of adding 128 if the value is less than 32.

--Tom

P.S. GitHub repo for this stuff here: https://github.com/tom-seddon/beebfax82

[flaxcottage]

Ahaah! That makes a great deal of sense, except, as Beebmaster asks, why use &80 to &FE for the RLE for two bytes? Using &80 for 2, &81 for 3, etc. could be better.

[SKS1]

Ahaah! That makes a great deal of sense, except, as Beebmaster asks, why use &80 to &FE for the RLE for two bytes? Using &80 for 2, &81 for 3, etc. could be better.

That's the scheme that Tom is describing

'$80-$fe - store 2+(value&0x7f) copies of the following byte'

where value is the byte in the range $80-$fe, so encodes runs of 2-128 bytes.

[brianmartin_2001]

thanks very much for that Tom ...

now it's unpacked .. I assume I would just have to write some code similar
to what's already in there to display each frame (calling page number) as per the original program.
Can this be done easily in BASIC?

much appreciated.
Brian

[KenLowe]

Time permitting, we can perhaps have a look at this tomorrow evening.

[flaxcottage]

Been looking at this problem as it peeked my interest.

I have written a prototype program in BBCB4W that reads the original SSD and displays the pages one after another. So far in BeebFAX82 and BeebFAX83 pages are numbered consecutively from 100 to <PageMax>, which is in the 200s. At the same time the reader builds an index file giving the file pointer into the SSD file next to the page number.

The code in the attached zip file will also work on Archimedes machines and Raspberry Pis, I believe. The aim is to develop a Raspberry Pi BeebFAX reader for the SSD files in the archive.

The zip file includes two BeebFAX SSD files for 1982 and 1983, the reader program and a text file of the reader program that can be *EXECed on a RISCOS machine.

The output is:

.
.
The next step is to work this up into a Raspberry Pi Teletext program that takes the SSD files and displays them.

[flaxcottage]

Today saw a lot of work on the problem of reading BeebFAX teletext files on other filing systems.

The application works on a PC using BBCB4W for all the BeebFAX SSDs from 1982 to 1985. It also works on RISCOS machines and this version is attached below. It is a prototype and the only caveats are renaming the BeebFAX SSD files and setting the CSD to point to the application folder (which I called piFAX as the target machine was a Raspberry Pi). The ReadMe file gives further explanation. The zip file contents work on a real or emulated A5000 and should also be OK on a Pi under RISCOS.

The next task will be to get the application running on a BBC/MASTER via ADFS or NFS

[flaxcottage]

Interesting.

The application works fine on RISCOS 3.1 but not on the PI. It seems that somehow the top line of the screen is not displayed. Rather it appears to be on the second line of the screen, which has moved up to be line 1.

Anyone an idea of why this should be. The version of RISCOS is 5.21 (26 Feb 2015) and BASIC is ARM BASIC VI 1989 RISCOS pico. Now this works brilliantly for running native BBC micro programs, why not this?

Anyone got any ideas?

Edit
Using version 5.24 (16 April 2018) from the desk top the application works perfectly. This version is useless for emulating BBC screen modes. Why does it work?

One is puzzled!

Edit again
RISCOS 5.19 works fine too. This is the recommended one for BBC compatibility.

[tom_seddon]

The application works fine on RISCOS 3.1 but not on the PI. It seems that somehow the top line of the screen is not displayed. Rather it appears to be on the second line of the screen, which has moved up to be line 1.

At a guess: because each file is exactly 1,000 chars, the last char printed will cause the entire screen to scroll up one row. This can always be an issue if trying to print something at the bottom right corner.

Looks like this could be something to do with *CONFIGURE NOSCROLL - perhaps the defaults are diferrent on the pi? (And I think this setting also does the same thing on the Master 128, which was what me made to think to search for it - if you were targeting 8-bits of course!)

--Tom

[flaxcottage]

That was my first thought, Tom, thanks, but I did not get as far as checking it.

The last character on the screen is displayed also in BBC4W, A5000 and Raspberry Pi and they display properly. I'll look at the SCROLL setting on RISCOS-pico and see what is happening there.

[flaxcottage]

*CONFIGURE NOSCROLL stops the program moving up one line on a BBC Master. Good call Tom.

However, my A5000 has *CONFIGURE SCROLL set yet does not scroll. Now one is really confused.

[flaxcottage]

As promised earlier, attached is a SSD file of a program that will display the Teletext pages held inside the BeebFAX SSD files downloadable from the Archive. The attached SSD contains the compiled indices for the BeebFAX discs, the display program and a ReadMe file.

To use this display program the following files will need to be in the same folder;

piFAXb - the display program
BFAX<yy>s
BFAX<yy>i

An ADFS floppy could manage up to 3 BFAX<yy>s files. An ADFS hard drive or a NFS folder can accommodate the whole collection.

The BeebFAX SSD files must be renamed as BFAX<yy>s to be usable by the display program. In this convention <yy> represents the two digit year (82, 83, 84, or 85).

The piFAXB program has been tested on an A5000 and a BBC Master. The program works under both ADFS and NFS.

On a Master *CONFIGURE NOSCROLL must be set. The program is second processor compatible and this considerably speed up the display.

The program will not work as yet on a BBC model B as it uses the TIME$ system variable.

[brianmartin_2001]

This is most excellent John , I shall be playing with this for hours this weekend.
thanks
Brian

[tom_seddon]

*CONFIGURE NOSCROLL stops the program moving up one line on a BBC Master. Good call Tom.

However, my A5000 has *CONFIGURE SCROLL set yet does not scroll. Now one is really confused.

Another option could be to print the lines in reverse order, scrolling the screen up before printing each one at (0,0). So I think that's just a question of doing VDU31,11 and then printing the line. Then, once you've printed 25 lines, line 24 is at the bottom of the screen, and line 0 is at the top, and the cursor is at (0,1). No chance of scrolling regardless of the NOSCROLL setting.

This might look a bit weird while it's in progress though...!

--Tom

[flaxcottage]

Going backwards is an interesting idea.

The data in the BeebFAX SSDs though are arranged to be output printed downwards. One would have to parse the page to find the last line and then work backwards through the data, reading backwards to determine the RLE encoding; ouch! my brain hurts.

Anyway, the application has now been developed so that it will run on all RISCOS variants (PI and Archimedes) and the BBC Master (with or without second 6502 processor) from NFS, ADFS, SDFS and SCSIFS (the last two are on the Pi - the SD card or a USB stick).

The display really rocks on the Pi. In BASIC it is easily as fast as machine code on the BBC micro.

The latest download is on the archive website under oddments/teletext.

[brianmartin_2001]

What am I doing wrong John?

cheers
Brian

[flaxcottage]

Basically, I have no idea. That error has never cropped up with me.

Line 390 performs a BGET#F%. F% is the file handle to the BFAX<yy>S file (the renamed BeebFAX<yy>.SSD file). The error means that you have run past the end of the pages file. The most likely cause for this is that the pages file has become corrupted or not saved in its entirety. The BFAX<yy>S file should be 200K long.

Which year was it? Which page was it?

I have just checked the software at my end and it is working perfectly.