Jump to content
IGNORED

Possible to load to high memory ( > $d800) from .XEX?


Recommended Posts

I want to have some data above the ANTIC/POKEY area, so I have done an .XEX that has some segments that load up here ($d800 and above).

However, it does not seem to work. Is it not possible to get data here straight from a .xex, (ie. correct way is to load to lower areas and then copy it up with code once I'm running) or am I doing something stupid?

Edited by Sdw
Link to comment
Share on other sites

Writes only go to Ram if the Ram is switched in. In some cases emulation (I think Atari800Win+) will allow it but it's not reflecting what the real machine does.

 

Best method is to load segments needing to go under OS Rom into lower Ram and move up with an Init subroutine. Assemblers usually have a directive or means to have the execution address different to the load address.

Link to comment
Share on other sites

Thanks, I did as Rybags susggested and loaded to lower memareas and copied up afterwards.

Now, a follow up question (that perhaps should have its own topic) - how do I load stuff to the additional banks on the 130XE?

That is, I'd like to have data in that additional 64k as well, and now I can't solve this by loading and then copying afterward, as I need data in the lower 64k as well.

Ideally I'd like to switch in a bank, load a 16kb segment, switch in another bank, load again etc. But is this possible somehow with the .xex format?

Link to comment
Share on other sites

Yes, you can use an INIT segment to switch banks. See also EXE File Format. When you RTS from the INIT routine, loading continues. You could also use a segment that writes directly to PORTB but you should probably have an INIT segment before hand to verify that the machine has extended memory and to display an error if not.

 

In XASM/MADS it could look like this:

 

setbank0
   mva #$82 PORTB
   rts
setbank1
   mva #$86 PORTB
   rts
setbank2
   mva #$8A PORTB
   rts
   ; etc.

   ini setbank0
   org $4000
   ; bank 0 data
   ini setbank1
   org $4000
   ; bank 1 data
   ini setbank2
   org $4000
   ; bank 2 data
   ; etc.

 

Or just this:

 

    org PORTB
    dta $82
    org $4000
    ; bank 0 data
    org PORTB
    dta $86
    org $4000
    ; bank 1 data
    ; etc.

Link to comment
Share on other sites

That's bad practice because you could never be sure if the banks of your choice really do exist in the user's computer. $82 etc. in the examples above and such will simply crash the computer (bit 0 cleared = no OS). It is only fairly safe when using 130XE banks, i.e. $E3, $E7, $EB and $EF, because all RAM extensions *should* be 130XE-compatible.

 

In fact, the first init segment should test the extended RAM and store a list of available banks in a safe place (like on 6th page). Next init segments should fetch conecutive PORTB codes from that table and either load data directly, or (safer) load data into base memory, then copy it over. When extended RAM is filled, you load the main segment to the base RAM and execute the entire program.

 

Not to mention that under a DOS the extended RAM, even if physically detectable, may be partially or entirely occupied by ramdisks and resident programs. SDX is the most obvious example, but such TSRs are imaginable also under other DOS-es.

  • Like 1
Link to comment
Share on other sites

Alright, thanks for the info on bank-loading, I think I have the theory down, will need to sit down and implement some stuff soon!

Going back to loading into "normal" memory, how high is it possible to go? Can you load all the way up to $cfff, or do you need to load one segment, run an init routine that disables OS and then load again? Or will disabling the OS mess up the loading altogether?

Yeah, I know I could probably test all of this myself, but since I'm guessing people here already know the answers, it's easier to ask! :)

Link to comment
Share on other sites

You could have a succession of 16KB segments all loading at $4000, but separated by init blocks which first switch in the correct bank from a table built by memory bank interrogation code in the very first segment. Safer to load them elsewhere and then copy them in, though, as Konrad said, since one is making an assumption that DOS will never switch the main bank back in during the binary load process.

Link to comment
Share on other sites

1. With OS ROM and without BASIC you can load any data up to $BFFF. Note, that area around $BC00 and above is by default occupied by standard screen (DL and screen memory). If you want to use this area for loading data, turn screen off or put it in another place.

2. After copying data under ROM turn ROM on again, and continue loading.

3. In practice, if you want to use EXT RAM (up to 4 additional banks) you can just check for any additional memory bank (I never heard about memory expansion <128k). In my last demo, I checked for this, and just use 130XE memory banks. This is also convenient because if you use only 130XE memory, you don't need to create a bank selector (if you require >128k RAM, bank selector is required). Bank selector is a tool (usually integrated with main software) that allow to choose which EXT banks you want to use. For example - check 'Boogie Nights'.

 

edit: one, more thing. 130XE has cool feature - independent access to EXT memory for CPU and Antic (CPU use EXT, Antic use STD, etc...). Try to not use it :). There are many expanded machines, and many of them (with 320k RAM and above) doesn't support this feature.

Edited by bob_er
Link to comment
Share on other sites

This is fascinating stuff and just what I am currently attempting to learn. However, most of the examples here use pseudo operations and special features of a specific assembler. As I am just starting out on this road I would like to learn how to do it 'by hand' as it were.

 

Interestingly I have just read 'Mapping The Atari' about using $D301 to select banks on the 130XE. bob_er says not to use this method however... So. How does one go about telling the machine to use a specific 16k area in extended memory when it wants to read data for the screen? At a first guess I would suggest you use a DLI for the first mode line whereby you can set $D301 manually to the correct bank before each attempt ANTIC makes to retrieve its data. Am I getting close?

Link to comment
Share on other sites

No, you get me wrong. For bank switching you always use D301 register (in 130XE).

By default bits 4 and 5 of D301 choose access to current EXT bank for CPU and ANTIC. So, on 130XE is possible, that CPU read base memory, and Antic read EXT, and so on... (all 4 combinations are available).

But expanding memory at least up to 320k (256k EXT memory) kills this feature. ANTIC and CPU uses the same bit 4 of D301 for access, so you can't set combination that one chip read base memory, and second read ext. Both reads base or ext. Bit 5 has different role - now it is used for bank selection (for 256 EXT ram you has 16 banks and 4 bits are needed).

What I wrote is suggestion to not use different access for chips for EXT memory (CPU->base, ANTIC->ext or CPU->ext, ANTIC->base).

But combinations that both CPU and ANTIC read ext or base memory is compatible with most memory upgrades.

Link to comment
Share on other sites

I see! THAT is why the 'rambo' and 'compy' and the others don't do the automatic bank switching - they need an extra bit to tell them which 16k of expanded RAM to swap in to S4000-$7FFF?

 

I clearly missing something obvious here but 256k is built up from 16 blocks of 16k. If bit 4 is needed to say whether or not to read from normal or expanded memory, how do you specify 16 different blocks of 16k when bits 5-7 only have seven different patterns?

 

0001 bank 1 $00000-$03FFF
0011 bank 2 $04000-$07FFF
0101 bank 3 $08000-$0BFFF
0111 bank 4 $0C000-$0FFFF
1001 bank 5 $10000-$13FFF
1011 bank 6 $14000-$17FFF
1111 bank 7 $18000-$1BFFF

 

OR is it the case if ANY of bits 4-7 are on then read from the resulting bank of memory?

Edited by morelenmir
Link to comment
Share on other sites

You may use bits 2,3,6, and 7 for bank addressing, leaving bits 4 and 5 for access mode.

 

Bit 7 is never used with bit 4, so a little lockout logic allows you to use bit 7 as a selector bit as well as a DIAG select bit.

 

If you are willing to lose BASIC, you can also use bit 1 as a bank select bit. This gives you 512K of external memory, with XE (bit 4 and 5) mode.

 

Bob

Link to comment
Share on other sites

Now I am getting REALLY confused. Part of the problem is there are so many different expanded RAM mods - although 'Rambo' and 'Compy' seem to be the main 320k ones. In the case of the former the automatic ANTIC/CPU bank awareness is non-functional. However apparently with 'Compy' it is and therefore the mod behaves the same as a stock 130XE. Anything above 320k always has the auto ANTIC switching disabled. I think.... Even worse, different mods read different bits of $D301 to determine which 16k bank of expanded memory to slot in to $4000-$7FFF!!!

 

Is there ANYWHERE a definitive list of the main RAM expansions, their ANTIC bank awareness ability and which bits to set for which banks??? I cannot even find the original data sheets for the specific mods anywhere on the internet. The closest I have got is the FAQ about memory expansions on Atari mania - and even that page only lists them without giving any details! It is as if the mod-makers thought you should just guess the bit positions!!!

 

I think I may lose it entirely if I look at this for too long... Apparently Cthulhu invented Atari memory expansions!!!

Link to comment
Share on other sites

1. Bit 4 of D301 is not a bank selector. It just tells MMU that chips should read EXT or base memory. Which bank is available under 4000-7FFF is getting from another bits of that register.

2. Unfortunately - there's no one standard that thells us, which banks are available, and which not. You can assume, that if you need 64k EXT ram (130XE configuration), you can use bits 2 and 3. Check this site (unfortunately in polish): http://atariki.krap.pl/index.php/Obs%C5%82uga_rozszerzenia_pami%C4%99ci_RAM

3. I don't know any software that use original meaning bits 4 and 5. But this feature is cool - double buffering is very easy with that. What a pity, that this feature was removed years ago...

Link to comment
Share on other sites

@morelenmir: you basically do not need to worry which PORTB bits do what, as long as you use a routine, which builds a list of available banks for you. bob_er gave you a link to such a routine, it generates a table of available PORTB values (labelled "banks") which switch in ext banks, and returns the number of them in Y register. Later, whenever you need to switch in a bank, you just pickup a value from that table. The routine should work for any extension, from regular 130XE up to 1 MB Rambo.

 

It of course only detects banks available for CPU. If you want separate access for Antic, you'll have to check if any of the values the routine stored in "banks" array has 5th bit cleared (provided there are more banks than 4). If so, there is no separate Antic access available.

Link to comment
Share on other sites

Humour aside, I can see there is some logic to it. I am sure I will pick it up. Many thanks for bearing with me.

 

I guess the reason we have no 'standard' for bank switching is because Atari never thought anyone would need more RAM than 128k. I guess expense also played a part and in 1983 the cost of a 1mb memory chip was more than the whole machine - if they even existed at all!

 

What I find fascinating is people are STILL coming up with new memory expansions - several of the chaps on here have outlined their own mods in fascinating posts. It looks like the trend is now moving to add RAM via the cartridge slot rather than soldered directly on to the motherboard.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...