Extending RO3.1 OS_DynamicArea

Discuss ADFFS development and download test releases
JonAbbott
Posts: 2938
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex
Contact:

Extending RO3.1 OS_DynamicArea

Post by JonAbbott »

As DA's are now in application space, I could extend OS_DynamicArea to support multiple DA's. The only caveat being pre-allocating each DA to it's maximum size on machines where there could be the possibility of a DA conflicting with Application space.

For example, if two DA's are allocated they map to non-overlapping Application space from top down:

DA 6 - ADFFS (2mb max) - E00000 - FFFFFF
DA 7 - QTM2ModXYZ (1mb max) - D00000 - DFFFFF
etc.

Would this be useful?

Q. How does one determine the amount of physical RAM on RO3.1?
steve3000
Posts: 198
Joined: Thu May 02, 2013 9:25 pm

Re: Extending RO3.1 OS_DynamicArea

Post by steve3000 »

This would be very useful indeed!

We'd only require about 512k for music conversion - and not for mus2qtm, as the format is identical. But for Tracker Module conversion this would be ideal.

To find out the memory size, you read the page size and number of pages - SWI OS_Memory, I think?

Steve
JonAbbott
Posts: 2938
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex
Contact:

Re: Extending RO3.1 OS_DynamicArea

Post by JonAbbott »

Does that still work with additional MEMC chips? I don't have one to confirm.

The page counter in RO 3.1 is a byte value, which by my reckoning limits it to 8192KB with 32KB pages. How does it deal with 3 MEMC's? I'd say several modules would need to be updated before before additional MEMC's would work.

It could read the 16mb of physical memory from 2000000 until it get a Data Abort, which is nasty but probably guaranteed to work!
steve3000
Posts: 198
Joined: Thu May 02, 2013 9:25 pm

Re: Extending RO3.1 OS_DynamicArea

Post by steve3000 »

Yep it does - my A540 reads out at 8192k by this method.

Where did you see that it's a 1 byte value?

For > 256 pages, the OS_Memory SWI is still fine, but the OS does do something different with it's CAM entry handling, see this from my ZeroPage review:

Code: Select all

164-563	CamEntries      	#       	4 * 256 	; CAM entries + PPL in here for machines up to
                                						; 8 MBytes - for larger machines they're stored
                                						; in CamEntriesForBigMachines - the location
                                						; CamEntriesPointer points to whichever is used

; PCEmulator requires CamEntries @ &164 (doesn't work with >= 8MBytes)

564	CamEntriesPointer 		#     	4       	; points to where CAM soft copy is
                                					; (CamEntries for machines up to 8MBytes,
                                					; CamEntriesForBigMachines for larger machines)

568	MaxCamEntry     		#       4       	; maximum index into the cam map, ie
                                					; 511 for 16MByte machines, 383 for 12MBytes
                                					; 255 for 8MBytes, otherwise 127
I assume OS_Memory gets its value from the word at &568 = MaxCamEntry ?
Steve
JonAbbott
Posts: 2938
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex
Contact:

Re: Extending RO3.1 OS_DynamicArea

Post by JonAbbott »

Do we know anyone with 3/4 MEMC's?

ps I'll get recoding OS_DynamicArea to support multiple DA's, which give you a few weeks to integrate the latest LCDgm ;)
steve3000
Posts: 198
Joined: Thu May 02, 2013 9:25 pm

Re: Extending RO3.1 OS_DynamicArea

Post by steve3000 »

Just checked on the PC using Arculator - it's not OS_Memory, it's SWI OS_ReadMemMapInfo (I was recalling OS 3.5).

SWI OS_ReadMemMapInfo returns R0=64 for 0.5Mb, 128 for 1/2/4Mb, 256 for 8Mb, 384 for 12Mb and 512 for 16Mb; R1=page size 8 for 0.5/1Mb, 16 for 2Mb, 32 for 4-16Mb.

Steve
JonAbbott
Posts: 2938
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex
Contact:

Re: Extending RO3.1 OS_DynamicArea

Post by JonAbbott »

Thanks for confirming, I'll go add the checks using OS_ReadMemMapInfo
JonAbbott
Posts: 2938
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex
Contact:

Re: Extending RO3.1 OS_DynamicArea

Post by JonAbbott »

I've recoded this and added a lot of checks in to hopefully prevent a disaster should rogue values be passed to it, which has bloated it a bit. Should hopefully have it available soon once it's actually working!

Q. What should I do under the following situation, where there are 3 DA's allocated:

DA 1 - E00000 - FFFFFF (ADFFS)
DA 2 - DC0000 - DFFFFF (QTM)
DA 3 - D00000 - DBFFFF (??)

DA 2 is requested to be removed, leaving a gap. On a 16mb machine I can't hand the memory back as it could potentially overlap DA 3 and DA 3 can't be moved as there's no official mechanism to move DA's.

Do I:

1. Ignore the delete request leaving the DA active. As it will only be us using DA's on RO3.1 we can code so that DA's are removed in reverse the correct order.
2. Flag the DA as deleted, leave it allocated and remove it when DA 3 is removed. Should another DA be allocated, DA2's memory will effectively leak until ADFFS quits and hands it back or DA4 and 3 are removed.


Are there any instances where DA's will need to be permanent outside of ADFFS? I'm only aware of us needing them on a temporary basis for QTM shims and can't think of any other need for them. Where small chunks are required (ie below 32kb) it would be more prudent to use RMA.
JonAbbott
Posts: 2938
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex
Contact:

Re: Extending RO3.1 OS_DynamicArea

Post by JonAbbott »

ADFFS 2.14 module and source are on the dev site, with support for 3 DA's - this can be altered by changing #set RO31_Last_DynamicAreaNo in adffs.vectors.swi_OS_DynamicArea

Still outstanding:

1. It doesn't account for machines with 16mb of RAM fully
2. I've coded it to support removing DA2 prior to DA3, but haven't tested yet due to (1) needing to be implemented first
3. I've not done any testing around creating the 2nd DA

Fully implemented are OS_DynamicArea 0, 1 and 2

When creating an area via OS_DynamicArea 1, the following registers must be set or it will return an error:
  • R1 = -1
    R3 = -1
    R5 = <2MB >0 (max size of DA)

R5 is used to calculate the DA's logical address, so its vitally important it's set correctly.
steve3000
Posts: 198
Joined: Thu May 02, 2013 9:25 pm

Re: Extending RO3.1 OS_DynamicArea

Post by steve3000 »

Great work Jon, looking forward to trying this out.

So for a QTM music translation, when ever a song load takes place, there are some options to consider...

On loading a music file with most tracker modules you have 2 or 3 options:

1) Load a music file from disc to RMA
2) Load a music file from disc to a specified application area memory location
3) Register a music file which has already been loaded at a specified memory address

For music translation module with access to a single dynamic area, I propose we do exactly what the original tracker module would do (ie. 1-3 above), then create the dynamic area, and 'translate' the original music into a new file within the dynamic area. We then run the music file in the dynamic area through QTM.

Upon the next 'load', we clear the file from QTM and resize the dynamic area... if that's possible? Otherwise we could delete the dynamic area and recreate at a larger size? Or just claim all 512k up front, and use as/when needed?

Steve
Post Reply