Accessing ROMs from the 6502 second processor

discussion of beeb/electron applications, languages, utils and educational s/w
Post Reply
rharper
Posts: 348
Joined: Sat Sep 01, 2012 5:19 pm
Location: Dunstable
Contact:

Accessing ROMs from the 6502 second processor

Post by rharper » Tue Jan 16, 2018 9:45 am

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 :)
Raycomp

Coeus
Posts: 777
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: Accessing ROMs from the 6502 second processor

Post by Coeus » Tue Jan 16, 2018 12:25 pm

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.

rharper
Posts: 348
Joined: Sat Sep 01, 2012 5:19 pm
Location: Dunstable
Contact:

Re: Accessing ROMs from the 6502 second processor

Post by rharper » Tue Jan 16, 2018 8:11 pm

Thanks Coeus, that's helpful.
I've got as far as reading the ROM table.
Now for paging in the ROMs.
Ray.
Raycomp

Coeus
Posts: 777
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: Accessing ROMs from the 6502 second processor

Post by Coeus » Tue Jan 16, 2018 11:08 pm

rharper wrote:Now for paging in the ROMs.
Ray.
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.

User avatar
jgharston
Posts: 3060
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

Re: Accessing ROMs from the 6502 second processor

Post by jgharston » Wed Jan 17, 2018 1:23 am

"I would like to make 2nd processor compatible"

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.

Using the memory read/write/call routines in http://beebwiki.mdfs.net/OSWORD_%2606 gives us (untested):

Code: Select all

DIM ctrl% 31:X%=ctrl:Y%=X%DIV256
DIM data% at_least_five_bytes

...

REM address%=address you want to read
REM rom%=ROM you want to read from
:
!data%=&AAFFB920:data%?4=&60        :REM JSR OSRDRM:TAX:RTS
PROCmem_wr(&A8,data%,5)             :REM Copy code to I/O
!data%=address%                     :REM Address you want to read
PROCmem_wr(&F6,data%,2)             :REM Copy address to &F6/7 in I/O
byte%=FNio_call(&A8,0,rom%) AND 255 :REM Call the OSRDRM trampoline
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.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

Kevin Edwards
Posts: 86
Joined: Tue Mar 14, 2006 9:16 pm
Contact:

Re: Accessing ROMs from the 6502 second processor

Post by Kevin Edwards » Wed Jan 17, 2018 9:44 am

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.

johnkenyon
Posts: 149
Joined: Wed Jul 20, 2011 2:21 pm
Location: Coventry
Contact:

Re: Accessing ROMs from the 6502 second processor

Post by johnkenyon » Wed Jan 17, 2018 10:24 am

Stick the data in a RFS rom and then *load the data into the co-pro memory space.

Works on any co-pro, no manipulation of &F4 or &FE30 required, no need to know which SWR slots your ROM code is located. Want more space - install another ROM.

It also makes development easier - store the code/data destined for the ROM on another filing system until you are ready to commit to SWR.

crj
Posts: 834
Joined: Thu May 02, 2013 4:58 pm
Contact:

Re: Accessing ROMs from the 6502 second processor

Post by crj » Wed Jan 17, 2018 11:26 am

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?

Kevin Edwards
Posts: 86
Joined: Tue Mar 14, 2006 9:16 pm
Contact:

Re: Accessing ROMs from the 6502 second processor

Post by Kevin Edwards » Wed Jan 17, 2018 12:05 pm

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.

rharper
Posts: 348
Joined: Sat Sep 01, 2012 5:19 pm
Location: Dunstable
Contact:

Re: Accessing ROMs from the 6502 second processor

Post by rharper » Sun Jan 21, 2018 12:27 pm

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 :)
Raycomp

rharper
Posts: 348
Joined: Sat Sep 01, 2012 5:19 pm
Location: Dunstable
Contact:

Re: Accessing ROMs from the 6502 second processor

Post by rharper » Mon Jan 22, 2018 12:02 pm

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
Raycomp

User avatar
daveejhitchins
Posts: 4149
Joined: Wed Jun 13, 2012 5:23 pm
Location: Newton Aycliffe, County Durham
Contact:

Re: Accessing ROMs from the 6502 second processor

Post by daveejhitchins » Mon Jan 22, 2018 3:36 pm

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!

Dave H :D
Parts: UM6502CE, GAL22V10D, GAL16V8D, AS6C62256A, TC514400AZ, WD1772, R6522, TMS27C512, AT28C256
Products: ARA II, ABR, ATI, AP6, MGC, AP5 . . .
For a price list, contact me at: Retro Hardware AT dave ej hitchins DOT plus DOT com

User avatar
jgharston
Posts: 3060
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

Re: Accessing ROMs from the 6502 second processor

Post by jgharston » Tue Jan 23, 2018 3:13 am

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/
Accesses sideways ROMs and shadow screen memory
OSWORD &FF transfers blocks of memory between I/O and CoPro memory
X%?0 =&0D
X%?1 =&01
X%!2 =I/O address
X%!6 =CoPro address
X%!10=Number of bytes to transfer
X%?12=0 for C->H, =1 for H->C
:
I/O address can be:
&FFxRxxxx for ROM R
&FF8xxxxx for workspace RAM
&FFFFxxxx for I/O memory
&FFFExxxx for current display memory
&FFFDxxxx for shadow display memory
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 call
ENDPROC

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

rharper
Posts: 348
Joined: Sat Sep 01, 2012 5:19 pm
Location: Dunstable
Contact:

Re: Accessing ROMs from the 6502 second processor

Post by rharper » Tue Jan 23, 2018 11:27 am

daveejhitchins wrote: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!

Dave H :D
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.
Raycomp

rharper
Posts: 348
Joined: Sat Sep 01, 2012 5:19 pm
Location: Dunstable
Contact:

Re: Accessing ROMs from the 6502 second processor

Post by rharper » Tue Jan 23, 2018 11:33 am

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
Raycomp

User avatar
jgharston
Posts: 3060
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

Re: Accessing ROMs from the 6502 second processor

Post by jgharston » Wed Jan 24, 2018 4:15 pm

rharper wrote: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.
Here we are, updated version of MemIO (slightly snipped):

Code: Select all

   10 REM > BLib.MemIO 1.02 24-Jan-2018
   50 REM v1.02 24-Jan-2018 mem_rd() can select sideways ROMs
   60 :
   70 DIM ctrl% 31:X%=ctrl%:Y%=X%DIV256
   80 END
   90 :
  100 REM Requires: X%=>5-byte block, Y%=X%DIV256
  110 :
  120 DEFPROCmem_rd(mem%,io%,rom%,num%)
  130 IFFNfx(130,0)=&FFFF:LOCALY%,!&F6:Y%=rom%:FORA%=0TOnum%-1:!&F6=io%+A%:mem%?A%=USR&FFB9:NEXT:ENDPROC
  140 PROCmem_wr(0,0,rom%,0):IFnum%=0:ENDPROC
  150 A%=5:REPEAT:!X%=io%:CALL&FFF1:?mem%=X%?4:io%=io%+1:mem%=mem%+1:num%=num%-1
  160 UNTILnum%<1:ENDPROC
  170 :
  180 DEFPROCmem_wr(mem%,io%,rom%,num%)
  190 IFFNfx(130,0)=&FFFF:FORA%=0TOnum%-1:io%?A%=mem%?A%:NEXT:ENDPROC
  200 IFnum%=0:X%?4=rom%:PROCmem_wr(X%+4,&F4,0,1):mem%=X%+4:io%=&FE30:num%=1
  210 A%=6:REPEAT:!X%=io%:X%?4=?mem%:CALL&FFF1:io%=io%+1:mem%=mem%+1:num%=num%-1
  220 UNTILnum%<1:ENDPROC
  310 :
  320 DEFFNfx(A%,X%):LOCALY%:=((USR&FFF4)AND&FFFF00)DIV256
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:
Image

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.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

Post Reply