My first post here - apologies in advance if it's a little verbose

I've a "little" project I've been working on (tho' more off than on) over quite a number of years - a "Sideways ROM"; I started it off as an attempt to write my own versions of the "*SR..." set of commands, as the Beeb I was using didn't have a suitable ROM fitted.

That said, the project has grown somewhat (the source file stands at c. 110KB, and over 5000 lines), and has seen quite a lot of "feature creep" (loadsa extras ).

One "feature" is that the code responds to the RFS "select" and "read" calls; I have successfully added a number of very short files, but I am having a bit of difficulty with a larger - 368 byte - file that needs to be split into two blocks.

Even with the "Advanced User Guide" and "New Advanced User Guide", I still can't figure out the block header formatting needed - I've tried several different approaches without success.

My user-RAM friendly "*SWLOAD" routine - which uses OSBGET to read files - stalls at the 255 byte-mark, and no amout of fiddling with either the block headers or the "*SWLOAD" routine has got anywhare, just changed the error message.

In short, has anyone got an example of (i) a 2-block RFS file, and (ii) a 3+-block RFS file that I can compare my code against, to see where I've gone wrong?

TIA,

--Martin

Hi Martin

I use Clares RAMROD rom to make RFS images. You could either just let it do the work for you or use it see what a larger file layout looks like. I've attached the rom image together with scans of the two relevant commands. Basically, you need to format a bank of SWR first with RFORM and then create the RFS image into the prepared bank using RFILE.

I don't have the manual electronically and I've only had time to scan the two relevant pages. Hope this helps!

Thanks for that!

It's turned out useful, as I've used it to create a "test" ROM, saved this as a ROM image, then used "*SPOOL"/"*DUMP" to get something readable.

That said, though, it seems to be generating the data blocks in exactly the same way that I (think that I) am.

Hmm... more head-scratching needed, I think.

--Martin

It's been forever since I wrote this kind of code on a Beeb, but just to point out that there seems to be a typo in the ROMFS code example in the PDF version of the Advanced User Guide - I think the very first line should berather thanin case you're using that as a starting point.

I've checked my "Advanced User Guide" (original deadwood copy), and you're right; must have been a mis-OCR of the original text.

I've been bashing my source code around a bit this evening, and after much frustration and swearing, have still not resolved the problem I'm having. (That said, I've also found that a "blank" RFS ROM was also borked, so I've gotten rid of it, at least for now.)

All this, and the code I'm using *still* seems to be OK with files that fit in a single block (i.e. no bigger than 256 bytes)...

Yet more thinking needed...

--Martin

This is the code I use to create RFS images.

Hope it is of some use.

Jon.

Thanks for that; a (quick) perusal of the code suggests that I'm (probably) coding the block headers correctly, so the proble would lie elsewhere

If I can't figure this out soon, I may ask for "bug-blatters" to assist me - other pairs of eyes my be able to spot something that is currently evading me (or that I'm overlooking... ).

--Martin

Obvious point: are you updating the high byte of the data address correctly?

i.e. in service call &0E:



That's the only thing I can imagine causing a problem for files with more than one block.

If you have no luck, feel free to post the code and I'll see if I spot anything amiss.

I don't _think_ it's the RFS "select" or "read" routines; I will, though list my versions of these routine here.



As for the data - this file is preceeded by the RFS "title" file, and five previous (small) files, and the "*SWLOAD" routine correctly reads 255 bytes of this file's data (also, including this would make for a long posting...).

--Martin

Postscript: I've checked "*SWLOAD" against a file held on a disc (image) - and it acts the same here; so somehow, during some update or another, I've managed to bork this routine. At least it's now been narrowed down...

Problem fixed - I trying to be too smart in "*SWLOAD" when checking for EOF

I removed the offending code, and it then started behaving properly

Thanks for all the suggestions and help.

--Martin

PS: This whole business of the "multi-block" RFS file was going to be one of the last steps before wrapping this version of my ROM code, updating the "README" file, and releasing it.

As it stands, I've just got a bit more tidying up to do before I sort out the "README" file, so if anyone's interesting in getting their hot, sweaty mitts on the ROM , let me know

A further update - I've found a bug in my routines, one which (I believe) also exists in the code published in places such as the "(New) Advanced User Guide".

Hint: Try using the RFS when an RFS ROM is in sideways bank "0"... and do "*."

The cause? The first "AND #$0F" [*] instruction in the "RFS_SELECT" code masks out the high-order nybble of the RFS ROM byte; it _also_ "mangles" the "end-of-loop" condition, which is "$10" [*], and causes an infinite loop...

The "simple" solution is to remove the "CMP"/"BCC" immediately after this "EOR"/"AND" pair, and put "CMP #$10" [*]/"BCS" immediately before it.

Heh... to think this bug has been sitting around for some 28 years (if my maths is right)

--Martin

[*] I _know_ that BBC BASIC (etc.) use "&" to denote hex.; I'm using a DOS-based assembler that uses "$" for this purpose

On the subject of creating RFS images, I use a tweeked version of Acorn User's ROMFiler here: http://mdfs.net/System/ROMs/SROM/