Sideways RAM Utilities

discussion of beeb/electron applications, languages, utils and educational s/w
User avatar
sweh
Posts: 1847
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: Sideways RAM Utilities

Postby sweh » Wed Oct 11, 2017 3:26 am

jgharston wrote:Coming to this late, but...
unplug_table = &39F/&3A0 - what ROMS should be unplugged

You may as well use locations that other ROM managers use for an unplug bitmap.

Remember, I wrote that ROM in the 90s. Who says that "D6E/D6F" is properly usable memory? That would seem to be very dependent whoever had the NMI space not using memory that high. I picked locations the AUG claimed were unused.

extended_osbyte = &3A4/&3A5 - Old extended OSBYTE vector
This is part of saving BYTEV, WORDV, WRCHV and RDCHV, and you're using it because there's only three SPAREV vectors which you've stored WORDV, WRCHV and RDCHV in.

Do you need to be chaining WRCHV and RDCHV? Does your code absolutely have to continue via anybody else who may have happened to have claimed WRCHV and RDCHV? If not, that's what UnVectoredWRCH and UnVectoredRDCH are for. Instead of jumping through hoops to daisy-chain along previous claimants, if you know that your code is going to be the final claimant, exit by jumping to NVRDCH at &FFC8 or NVWRCH at &FFCB.

My ROM isn't the final claimant. I intercept these calls to ensure the right memory bank is paged in (WRCHV so printing is sent to the screen, rather than the shadow bank; RDCHV so the cursor COPY reads from the screen and not the shadow bank). I do bank switching, call the original routine, then bank switch back again. I wanted these routines to work as transparently as possible, so chained. Probably 99.999% of the time I could have just done a JSR to the NV versions... but I wanted to be better than the original Solidisk ROM that broke lots of things.

That just leaves you with srdata_status, ramdisk_present, status_byte. The SRAM utilities that live in the DFS ROM steal 18 bytes from the DFS's private workspace at (&0DFX)00. Somewhere I noted down where the Master keeps the SROM/SDATA flags.

Which won't necessary work with Solidisk DDFS or OPUS DDOS or other ROMs.
Rgds
Stephen

User avatar
tricky
Posts: 1916
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: Sideways RAM Utilities

Postby tricky » Wed Oct 11, 2017 6:43 am

What I want to do is make my games that use see as compatible as possible, and that means checking for see that use the user port to select the write bank.

I don't know of any discovery/uploading code that doesn't upset MMC based solutions, except when smartspi is using pb4/5 as on my original beeb.

After upsetting an MMC FS, reselecting the MMC FS seems to get things working, but that looses the currently mounted discs (*din).

What I wanted to try was discovering the FS, them finding the currently mounted images, accessing the swr, resting and restoring.

Otherwise things only work on image 0.

duikkie
Posts: 2707
Joined: Fri Feb 07, 2014 3:28 pm

Re: Sideways RAM Utilities

Postby duikkie » Wed Oct 11, 2017 8:09 am

With smart spi there is a diffents between *card and *dmmc *card don,t clean area &d00 futher smart holds the old bytes from fe60 and fe62 maybe troubles there if you check all banks


tricky wrote:What I want to do is make my games that use see as compatible as possible, and that means checking for see that use the user port to select the write bank.

I don't know of any discovery/uploading code that doesn't upset MMC based solutions, except when smartspi is using pb4/5 as on my original beeb.

After upsetting an MMC FS, reselecting the MMC FS seems to get things working, but that looses the currently mounted discs (*din).

What I wanted to try was discovering the FS, them finding the currently mounted images, accessing the swr, resting and restoring.

Otherwise things only work on image 0.

User avatar
tricky
Posts: 1916
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: Sideways RAM Utilities

Postby tricky » Wed Oct 11, 2017 11:20 am

I'll try *card with an ON ERROR and see if I can get it working on all three MMC FSs.

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

Re: Sideways RAM Utilities

Postby jgharston » Wed Oct 11, 2017 12:24 pm

sweh wrote:
jgharston wrote:Coming to this late, but...
unplug_table = &39F/&3A0 - what ROMS should be unplugged
You may as well use locations that other ROM managers use for an unplug bitmap.

Remember, I wrote that ROM in the 90s. Who says that "D6E/D6F" is properly usable memory? That would seem to be very dependent whoever had the NMI space not using memory that high. I picked locations the AUG claimed were unused.

Acorn. Not 'probably usable memory', but 'allocated for the Electron Plus 1 ROM Manager/Allocated to Master Econet services' and those two locations are the locations used for the unplug/insert bitmap. If you're running on a Master you wouldn't be implementing an unplug/insert bitmap as the MOS already does it, if you're not running on a Master and implementing an unplug/insert bitmap then there is no Master Econet system as you're not running on a Master.

The space for NMI code goes up to &0D5F and &0D60-D67 is Econet space. Admittedly, not listed in the AUG, but lots of stuff isn't listed in the AUG and has had to be found by investigation. Eg &03A4 is the GXR status byte. Why, when there's one spare byte in the VDU workspace at &037F anyway? And why are there four bytes of CFS data in the kernel workspace when there's 8 bytes spare in the CFS workspace? Somebody blinked when finalising MOS 1.

A particular annoyance for me is that I deliberately bought the NAUG for the expanded information and then discovered that it didn't have things like the UPTV details listed, so I had to buy the AUG as well; even the Electron AUG omits some crucial differences from the BBC/Master systems which can bite you when your code runs on an Elk and falls over (eg disables the ROM next door to the one you want).

Code: Select all

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

User avatar
tricky
Posts: 1916
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: Sideways RAM Utilities

Postby tricky » Wed Oct 11, 2017 7:28 pm

I know I'm butting in (again), but I have made a little progress.

JGH, I know this is not legal, but I think it is valid for B/B+/master.

Call OSARGS (&FFDA) with Y=0 to get the currently active filing system in A, I haven't checked, but I am assuming that the MMC FSs return 4 for compatibility.

If (A=4=DFS) then

Call OSBYTE (&FFF4) with A=&A8, X=0 and Y=&FF to get the address of extended vector table in XY (&D9F in OS1.2)
Get the ROM slot by assuming that FILEV will point to the MMC FS, so ?(&D9F + 9*3 + 2) XY + FILEV*3 +2 = ROM slot.

Then I think I can just scan the ROM data, string matching for the type of MMC FS.

Finding the currently mapped images (*DIN) is another thing, but can anyone see a problem with this approach?

Bear in mind that I want this to have compatibility with as many sideways RAM solutions and filing systems as possible.
If it doesn't say it is DFS or I can't identify it as TurboMMC/SmartSPI/MMFS, it probbaly doesn't use the user port and I don't need to worry.
Hopefully this could be used to make some of the games in the STH MMC archive compatible.

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

Re: Sideways RAM Utilities

Postby jgharston » Wed Oct 11, 2017 7:49 pm

tricky wrote:Call OSARGS (&FFDA) with Y=0 to get the currently active filing system in A, I haven't checked, but I am assuming that the MMC FSs return 4 for compatibility.
...
Call OSBYTE (&FFF4) with A=&A8, X=0 and Y=&FF to get the address of extended vector table in XY (&D9F in OS1.2)
Get the ROM slot by assuming that FILEV will point to the MMC FS, so ?(&D9F + 9*3 + 2) XY + FILEV*3 +2 = ROM slot.

You probably don't even need to check if the current FS is 4, just get the current filing system's ROM number from XFILEV and look in the ROM's title.

Checking XFILEV does appear to be the standard way of finding a filing system's ROM number, it's used in a lot of Acorn code including the Master MOS.

And the extended vectors have never moved in any MOS, so reading XFILEV+2 at &0DBC directly could be done. Again, done in a lot of Acorn code.

Code: Select all

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

User avatar
sweh
Posts: 1847
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: Sideways RAM Utilities

Postby sweh » Thu Oct 12, 2017 12:01 am

jgharston wrote:A particular annoyance for me is that I deliberately bought the NAUG for the expanded information and then discovered that it didn't have things like the UPTV details listed, so I had to buy the AUG as well

Yeah, I wasn't very happy with NUAG. 9 times out of 10 I went to AUG first because it was easier to find the info I needed.
Rgds
Stephen

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

Re: Sideways RAM Utilities

Postby crj » Thu Oct 12, 2017 12:55 am

I was (and am) glad to have both.

I found NAUG was better at describing how to do a thing, but AUG was better at saying what a thing was if I saw it done. To be concrete, NAUG is better for "write a filesystem"; AUG is better for "what does this OSBYTE call do?".

Plus each has information the other entirely lacks, alas.


Return to “software: other”

Who is online

Users browsing this forum: Google [Bot] and 3 guests