Running a Program from ROM / Sideways Rom

[DamoJay]

Hi all,

Hopefully you can help an old man re-ignite his grey matter. I've got a Machine Code Program with the following attributes when you do a *INFO.

$.TEST 1A00 1A00 19FF 015

How can I go about loading this into Sideways Ram so I can execute the code by issuing a *TEST command ? Plan it to burn this into a physical EPROM at some point.

Thanks in advance for your help,

Damian.

[BeebMaster]

Unless the file TEST is itself a fully-fledged ROM image (in which case it can be SRLOAD into sideways RAM) then it won't be easy to do this.

The program is set to load and run at &1A00 whereas sideways RAM and ROM is addressed from &8000 upwards. 6502 machine code isn't relocatable, except in a rare case where the only memory references are relative branches, so trying to run it from a different location won't work: all the jumps and loads and stores will operate on absolute memory addresses fixed when the code was assembled, which will be incorrect for a different load address.

If it alters any memory locations within the program then this won't work from sideways RAM as writing to sideways RAM locations is done in a completely different way to writing to main memory. And on ROM it will of course be read only anyway.

If you have the source code then you could rebuild it within a ROM image, with a ROM header, service code to implement an unknown * command and then the code itself.

If you don't have the source code then you could make it into a ROM Filing System image where it will appear as a file in the RFS which could then be *RUN at the original load/exec address.

The file length is &19FF, ie. 1 byte short of &2000 - is that correct, as it's very easy to get *SAVE wrong and miss off the last byte.

[daveejhitchins]

MakeRFS may be the one you want.

Dave H.

[sweh]

You can't easily run the program from the ROM. 6502 code normally isn't relocatable (if you have the source and can rebuilt it that's a different matter).

The standard solution for a "binary object" is to create a "wrapper" ROM that adds a new *TEST command and will copy the program stored in the ROM down to the normal load location and JMP to it.

[DamoJay]

MakeRFS may be the one you want.

Dave H.

Thanks for this. I've created the ROMfile and loaded it into SWRam. I can see the Rom in there. But how do I then access the file on the ROM ? Is there any instructions on using MakeRFS ?

Thanks,

Damian.

[sweh]

Thanks for this. I've created the ROMfile and loaded it into SWRam. I can see the Rom in there. But how do I then access the file on the ROM ? Is there any instructions on using MakeRFS ?

The command "*ROM" switches to the ROM file system, and then you can use normal commands (eg *.) to see the contents. It's similar to tape, so "*OPT 1,2" before a "*." will show extended details.

[Coeus]

The big question here is "Do you have the source code?"

If you do, although a service ROM has an additional layer of complexity over a simple assembler program, in that it needs a header and a routine to respond to a call for unrecognised commands, this is fairly simple stuff and JGH may even have a program that can generate something.

If you don't, then you have two options:

• Put it in ROM for easy access but have it copied to the original location in memory when it needs to run. There are at least two ways to do this:
  • Use the ROM filing system as already mentioned. The advantage of that is that it is easier and there is a tool to automate it. It is probably also more tube-compatible. The disadvantage is the ROMFS is fairly slow and you need to selected it first, with *ROM, before you can run files from it.
  • Write a wrapper that copied the code from ROM down to its original location in RAM and which responds to the unrecognised ROM service call. That would execute faster and work even when DFS or TAPE was the selected filing system. If you wanted to support the tube, though, you'd have to go to some trouble to do that.
• Disassemble it. There are number of disassemblers that will convert binary code back to a kind of source code with labels so it can be reassembled at a different address. Obviously you don't get the original comments and any labels are automatically generated but this can be a useful technique.

[davidb]

Being lazy, I haven't checked, but doesn't MakeRFS give you the option of creating a ROM that fast-loads the file into main RAM?

[daveejhitchins]

Being lazy, I haven't checked, but doesn't MakeRFS give you the option of creating a ROM that fast-loads the file into main RAM?

It does . . . Dave H.

[jgharston]

The big question here is "Do you have the source code?"
If you do, although a service ROM has an additional layer of complexity over a simple assembler program, in that it needs a header and a routine to respond to a call for unrecognised commands, this is fairly simple stuff and JGH may even have a program that can generate something.

MiniROM.src

If you don't, then you have two options:

• Put it in ROM for easy access but have it copied to the original location in memory when it needs to run. There are at least two ways to do this:
  • Use the ROM filing system as already mentioned. The advantage of that is that it is easier and there is a tool to automate it. It is probably also more tube-compatible. The disadvantage is the ROMFS is fairly slow and you need to selected it first, with *ROM, before you can run files from it.

MakeRFS

[*]Write a wrapper that copies the code from ROM down to its original location in RAM and which responds to the unrecognised ROM service call. That would execute faster and work even when DFS or TAPE was the selected filing system. If you wanted to support the tube, though, you'd have to go to some trouble to do that.

ROMCommand

[DamoJay]

Thanks very one for their help.

Ok, I've had some success, but not 100% of what I'm trying to achieve. I've attached a SSD disk here, and on there are the following files :

• TEST - this is the file that works from disk with *RUN TEST that I would like to create a *COMMAND ROM from. It's a test program by S. Cousins from 1984.
  
  RMCMND - this the ROMCOMMAND file for creating a *COMMAND Rom file , for a machine code program. I have tried this for the TEST file but get an error of "File 'TEST' is not I/O code".
  
  RMBASIC this the ROMBASIC file for creating a *COMMAND Rom file , for a machine code program. I have tried this for the TEST file but get an error of "Needs 6502 BASIC IV".
  
  MAKERFS - is the MAKERFS. I have successfully made a rom file (TESTROM) so I can do *ROM and then *RUN TEST. However no text of the rom when doing *H. and also no addition helpdesk when you do *H. RFS.

Would anyone be able to create a Rom Image that would have text appearing on *HELP and can be run directly with *TEST ?Would like to understand how to do this.

Many thanks in advance.

Damian.

[jgharston]

It does indeed claim to want to run in the language processor, and not the I/O processor, so you will need to rewrite the code yourself from the source.

[tricky]

Is this just a case of making the load and exec addresses FFxxxx or is there something more?

[DamoJay]

Is this just a case of making the load and exec addresses FFxxxx or is there something more?

I'm not sure !! I think so, on the disc attached above, you just *RUN TEST and it works. I've managed to use MakeRFS and can run it by doing *ROM and then *RUN TEST. But would be great to create a rom that shows up with *H. and can be run with a command of *TEST.

[jms2]

I had a go, and yes it seems that all you need to do is:

*LOAD TEST 1A00
*SAVE TEST FF1A00 +19FF

Then run RMCMND as usual and it works (takes quite a while though - I had to speed up BeebEm because I thought it had crashed!)

I tested the resultant rom and it appears in the *ROMS list and also responds to *HELP. However I couldn't get the actual command to work, because I was testing it on an emulated Master whereas it only runs on a BBC B. With a bit more fiddling about I think it would work.