I have a routine for reading ROM titles that I would like to make 2nd processor compatible.I know that for host main memory you need to access &FFFFxxxx and can use OSWORD 5/6.However:1. To page in a ROM at &F4 and &FE30 (for BBC) - are the addresses in the host or 2nd processor?2. Once paged in are the ROMs, such as utility ROMs, copied across the tube to the 2nd processor like BASIC or are they still in the host?From my reading I cannot pick out the answers.Thanks,Ray

Paged ROMs are only in the host (I/O) processor. The 2nd processor has a normal, linear address space with the exception of a small boot ROM at the very top of the address space.

That means the latch to select the ROM and its OS copy need to be written on the host processor.

At any time the only ROM that would be copied over to the 2nd processor is the current language ROM. As there is no paging on the 2nd processor there would not be room for more than one at a time. Service ROMs are never copied across - they always run on the host processor. In the event a ROM has both language and utility (service) code in the same ROM the service code runs on the host processor and the language code run on the 2nd processor. In the event the 2nd processor is not a 6502, for example a Z80, that means the language code is assembled for the 2nd processor so you can have a ROM with both 6502 and Z80 code in.

Last edited by Coeus on Tue Jan 16, 2018 12:33 pm, edited 1 time in total.

Can you do what you need by issuing a service call to the ROM concerned? There's an OSBYTE for that so you may be able to issue that from the 2nd processor and have the OS look after actually running it in the host processor.

2nd processor compatible, or 6502 second processor compatible? If 2nd processor compatible, that means you're working from BASIC. If 6502 second processor compatible, that means you're restricting yourself to just the 6502 second processor. (Edit, your title contradicts your content and refers to restricting yourself to the 6502 second processor. You should never set off with the plan to deliberately stick two fingers up to your potential users by needlessly doing IF NOT(running_on_6502) THEN PROCfuckoff)

You can't just arbitarily change the ROM selection as if you're running in BASIC on the I/O processor you'll page yourself out.

You can use *CODE to call code in the I/O processor, but unfortunately it can only return the contents of X and Y, and OSRDRM returns the byte read in A. However, we can poke some code across to transfer A to X and call that.

This will work on any second processor, and on either side of the Tube. Note you must ***NOT*** use the "zero page available for language code" locations, as you are ****NOT***** the current language on the I/O processor, the Tube Host is the current language. You *****MUST***** use the "calling operating system routines" memory locations.

Kevin Edwards wrote:It's a bit odd that OSRDRM wasn't implemented 'across the tube' as it was designed to be the 'clean' way to access IO processor ( and ROM ) memory in the first place.

I'm sure there's a good explanation why.

I get the impression it was designed for the ROM filing system, but was exported as a public interface mainly on a why-not basis. The big question is: what is it realistically used for, and why would one be doing that in a second processor?

It's a shame OSWORD 5 didn't include the option to specify a ROM number then that would have been a complete and clean way to read IO memory using an approved API.

OSRDRM was the legal way to select and read the contents of sideways ROMs when running in non-tube mode. Useful for 'ripping' ROM images I suppose!

The 'CMOS11' file in the ASBAS thread's .SSD image is a cmos disassembler that i wrote with the intention of running from Tube or IO memory - this is the full 6502 source code.

It included the ability of switching between IO and Tube memory and also selecting a ROM. However, because OSRDRM was not usable across the tube i had to disable the ROM select feature when running on a co-pro. It's a shame as it would have been really nice to have accessed the ROMs from tube based code.

I have spent some time writing the assembler and watching some tennis, snooker, football, not much time left for the cricket!I have put the 5 byte osword block in zero page to make setting addresses straightforward.It all seems to be working OK with/without a second processor on a Master and Electron.My existing routine for loading a rom image to swram does it a byte at a time so changing it to osword 6 should not be too difficult, though I always make a mistake and am not good at debugging assembler.Having completed that I will move the routines into the new version of my Desktop software.Thanks for the suggestions,Ray

No, not quite right.After the software runs and exits, the filing system is faulty.e.g. *TYPE textfilename shows rubbish; SAVE "file" hangs the system.I have moved the osword block out of zero page but it makes no difference.Found that the problem is in the SWRAM un/lock routine where the Master needs to be set to allow writing.Investigating.Ray

Not read the whole thread, however, if you're using ABR or AP6, with a locking mechanism, then you may need to do what Rob Northen did with the E00 version of ADFS where the ADFS code was in one bank and the ADFS workspace was in the other bank. Effectively he had an unlock sequence in two places, within the main ADFS code, which ensured the RAM was alway unlocked. This was found when Prime used ADFS-E00 and DFS-E00 in his ROM/RAM board for the Acorn Plus 3. It caused every ABR/ATI to be permanently unlocked!

You could run the version 1.02 OSWORD &FF driver, which lets you transfer arbitary memory between the host and any CoPro, and accesses any paged/banked memory, on the Tube Utilities disk and source at: http://mdfs.net/Software/Tube/

You won't be able to use it if your program is running on the I/O processor because your program will be running on the I/O processor. The simplest thing to do is have a generic wrapper around your memory access code that does something like:

early in the program do:io%=FNosbyte(130)=&FFFF:IF NOT io% THEN *OSWFF

DEFPROCreadmem(dest%,src%,rom%)IF io% THEN make multiple OSRDRM calls ELSE make an OSWORD &FF callENDPROC

Not read the whole thread, however, if you're using ABR or AP6, with a locking mechanism, then you may need to do what Rob Northen did with the E00 version of ADFS where the ADFS code was in one bank and the ADFS workspace was in the other bank. Effectively he had an unlock sequence in two places, within the main ADFS code, which ensured the RAM was alway unlocked. This was found when Prime used ADFS-E00 and DFS-E00 in his ROM/RAM board for the Acorn Plus 3. It caused every ABR/ATI to be permanently unlocked!

Dave H

I am only providing lock/unlock for ABR cartridges as in the ABR user guide and am identifying locked SWRAM only in ABR banks 0-3. So hopefully that should be OK.

Thanks for the suggestions JGH.I am having problems getting my head around some of the normal osword 5/6 coding so I am going to complete that first.After I will have a look at your suggestions to see if they provide any advantages.However, the code is going into my Desktop + Browser software which is all BASIC + 6502 assembler so it may not give any advantages.Thanks,Ray

PROCmem_rd(local_address, io_address, rom_number, byte_count) will read a number of bytes from I/O memory with the specified ROM paged in. It is callable from any second processor, or from the I/O processor (tested on Master, 6502CoPro, ARMCoPro). Example:

It's a bit fiddly to write to sideways banks from BASIC as there is no API to do this, you have to manually build some machine code to do it.

The Tube Host code doesn't care what ROM is paged in while it is handling Tube transactions, as they are paged in and out as needed when making service or filing system calls, etc. The Tube Host v3.50 in MOS 3.50 does call some routines in ROM to implement assisted relocated code, but I've checked, and the code it calls are all in the high MOS ROM, so should also be agnostic over what sideways bank is paged in.