MapRAM

[reifsnyderb]

Does anyone use MapRAM?

 

It seems to be an interesting way to access the 2k of RAM in the device region of $D000-$D7FF.  Looking at the schematic, it appears that A15 needs to be intercepted on it's way to the RAM and, if all of the inputs are correct, set low.  I believe that on an 800XL, A15 would be intercepted at U27.  I am doubtful that MapRAM gets much use, however.

 

The only schematic I've found is here:  http://atariki.krap.pl/index.php/MapRAM

 

There is a hint that the MMU has to be re-programmed, but I haven't looked into it yet.  I also haven't found any MapRAM MMU code.

 

What brought this on is a thought that it would be nice to have the MMU only enable the ROMs on a read and not on a write.  So, while investigating this, I'd look at MapRAM as well.

 

 

Edited August 19, 2023 by reifsnyderb

[+MrFish]

Maybe @xxl

 

Altirra supports it.

 

 

[tebe]

https://github.com/tebe6502/Mad-Pascal/blob/master/lib/misc.pas

 

DetectMapRam

[Piotr D. Kaczorowski]

xxxxxxxxxxxxxxxxxxxxxxxxxxxxL

[Piotr D. Kaczorowski]

49 minutes ago, reifsnyderb said:

Does anyone use MapRAM?

 

 

 

It will not work with Ultimate 1MB because U1MB holds some config data in that area. MapRAM is a non-standard Atari memory access, and most RAM extensions don't support it.

[+CharlieChaplin]

3 hours ago, reifsnyderb said:

Does anyone use MapRAM?

 

Happy translating:  http://xxl.atari.pl/mapram/

 

[reifsnyderb]

Ok.  It's as though MapRAM is more of a novelty than anything else.  It's an interesting idea, though.

 

I haven't seen anything other than a mention that the MMU would have to have a slightly different program.  I could probably figure it out if needed. 

Edited August 20, 2023 by reifsnyderb

[xxl]

none of the existing memory extensions conflict with MapRAM, only the U1MB modification.

Here is an example of memory expansion with MapRAM on an Antonia board with a 6502 processor:

 

[Piotr D. Kaczorowski]

42 minutes ago, xxl said:

none of the existing memory extensions conflict with MapRAM, only the U1MB modification.

 

 

As can be seen in the picture (but everyone in Poland knows this too) you have a unique version of Antonia with a 6502C processor, not a 65C816. It's nice to have 4MB, but in reality, it's known that only in linear access in 16-bit mode does this make more sense, unless you're using it during development.

 

Unfortunately, we didn't manage to talk in person, although some time ago I spoke quite a bit with your brother Rafal about the game Tony. For several months, I've been working on various extensions for Atari. As for MAPRAM, I know that it is available in Antonia. I talked about it with Candle, who, as is known, is also capricious and takes personal matters related to his projects seriously, and it's not always the case that he's right. Nevertheless, I believe that those 2KB, which let's be honest are a certain addition not resulting from Atari standards, could stop being a bone of contention. A large number of people have Ultimate 1MB, and there are probably thousands of them currently (what it does is an unofficial standard), so it would be bad to create software that will have a problem with those 2KB of memory. As I understand it, Candle keeps the U1MB settings in this area. I don't know whether it's due to time constraints, hardware limitations, financial restrictions, or testing time issues, but it may not be possible to create a U1MB that could provide those additional 2KB. So perhaps it would be worthwhile to respect popular technology and focus on other more interesting things. As you know, we say locally here, 'Is this really what Atari wanted?'  

 

 

[xxl]

you're right, this popular extension, in addition to blocking half of the D3 memory page, also blocks access to RAM under SelfTest (MapRAM), but that doesn't mean that everyone has to agree with it

and here is an example of using MapRAM to write score:

 

 

[flashjazzcat]

This document implies that memory between $D600-$D7FF is shared between parallel device handlers, but on page 310 of the Altirra Hardware Reference Manual, a description of the 1400XL/1450XLD states:

Quote

A unique feature of the 1400XL is 512 bytes of RAM at $D600-D7FF, dedicated for PBI device firmware usage. This address range is mapped by the MMU from memory that is normally hidden by the I/O block at $D000- D7FF. Although some internal documents referred to this RAM being divided by PBI slot, in practice the 1400XL handler firmware uses the majority of $D6xx RAM between the V:, T:, and PDD handlers at addresses that don’t match their PBI slot numbers, and $D7xx is unused.

So, the U1MB's use of the a large portion of this memory for its internal PBI device is hardly unprecedented, and in practice, the majority of external PBI devices map external RAM into the PBI address space. This is what allows - for example - the U1MB PBI device and the external IDE Plus 2.0 PBI device to function side-by-side on different device IDs.

1 hour ago, Piotr D. Kaczorowski said:

I don't know whether it's due to time constraints, hardware limitations, financial restrictions, or testing time issues, but it may not be possible to create a U1MB that could provide those additional 2KB.

The U1MB has a pair of 512KB SRAM chips which provide up to 1MB of extended PORTB RAM. Although a copious amount of bank-switched PBI RAM would - in retrospect - have been highly desirable (and will certainly exist in future hardware designs, such as ExtU1MB), at the time Candle designed the hardware, less than 1K of 'IORAM' in the PBI region seemed ample, so it made no sense at all to place a third SRAM chip on the board simply to provide the 1K of PBI RAM which already existed in the base memory of the machine (contrast this with Incognito, which carries three 512K SRAM chips, one of which provides the entire base memory on the machine). Thankfully, U1MB users are insulated from 'MAPRAM' by virtue of the fact that U1MB supplants the MMU on the motherboard, and MAPRAM itself - coming as it did some time after U1MB's memory usage was already public knowledge - has the characteristics of a modification whose sole purpose was to facilitate the introduction of yet another 'compatibiliy' wedge-issue after the fact, as evidenced by:

Quote

none of the existing memory extensions conflict with MapRAM, only the U1MB modification.

The fact that U1MB has become - for good reason - a comparatively ubiquitous upgrade which exists in a vast number of 8-bit Ataris renders the above statement a complete non-sequitur. It would be like boasting that an upgrade is 'compatible with all existing Ataris, apart from the 800XL'. This is little more than a continuation of an already well-publicised spat between XXL and Candle regarding anomalous U1MB corner-case behaviour concerning repeated PIA registers, which - again - was exploited after the fact to propagate another long-running bone of contention which is of interest to no-one at all but the developers arguing about it, until the point that one of them has the bright idea to publish software which deliberately crashes machines equipped with hardware towards which (or towards whose designer) he holds some arbitrary grudge.

Edited August 20, 2023 by flashjazzcat

[Piotr D. Kaczorowski]

 

Since I returned to Atari only in 2020, it seems I've missed out on a lot. Unfortunately, stirring up pointless sh*tst*rm in Poland is practically a national trait, or perhaps we do it for sport.

 

One of the amusing stories is that a game was written that specifically doesn't work on U1MB and uses MAPRAM. Talented programmers immediately made a fix, which reportedly caused another storm. The truth is that, of course, one cannot distribute a modified version of the game, but what are entirely legal are: 1. the distribution of a patch that modifies the original product, and 2. running this patch by a person who legally possesses the original product that doesn't work with their computer, and the author does not provide a solution that corrects this situation.

[+DjayBee]

17 minutes ago, flashjazzcat said:

This is little more than a continuation of an already well-publicised spat between XXL and Candle regarding anomalous U1MB corner-case behaviour concerning repeated PIA registers, which - again - was exploited after the fact to propagate another long-running bone of contention which is of interest to no-one at all but the developers arguing about it, until the point that one of them has the bright idea to publish software which deliberately crashes machines equipped with hardware towards which (or towards whose designer) he holds some arbitrary grudge.

Not that I support the destructive actions of XXL but to some defense comes that Candle for a long time ignored all remarks about these incompatibilities at all and

only admitted them quite late in the storm (IIRC it was more than a year).

I don't know XXL personally but being ignored with a problem will never lead to any positive attitude.

[Piotr D. Kaczorowski]

13 minutes ago, DjayBee said:

Not that I support the destructive actions of XXL but to some defense comes that Candle for a long time ignored all remarks about these incompatibilities at all and

only admitted them quite late in the storm (IIRC it was more than a year).

I don't know XXL personally but being ignored with a problem will never lead to any positive attitude.

As someone who has recently entered the community, I can only say that I've met Candle (who also lives in Warsaw like me), and he is a brilliant personality with vast knowledge. Like all of us, he has his private and business life, successes, and failures. Let's remember that he designed the U1MB, SIDE, and probably a few other things. While working on new projects, it's hard to fend off attacks from users if the projects have such wide distribution.
 

I disagree with the assertion that U1MB introduces incompatibility. In Atari 8-bit, compatibility essentially ends at 64KB. Some may speak of a standard for 128KB, which was introduced by 130XE. All other extensions are third parties, and developers should care about creating software for the largest number of computers/devices. U1MB is one such extension, and it has its pros and cons.

The thread about the 2KB out of 1088KB has been going on for several years... I admire that people have so much time for this...

 

 

 

Can someone design a badge with the inscription MapRAM OUTSIDE? I'll stick it on the U1MB in my Atari

 

 

 

[flashjazzcat]

34 minutes ago, DjayBee said:

Not that I support the destructive actions of XXL but to some defense comes that Candle for a long time ignored all remarks about these incompatibilities at all and

only admitted them quite late in the storm (IIRC it was more than a year).

This is why I reference a long-running dispute which is of little interest two the two personalities concerned until one personality decides to deliberately capitalise on the corner-case by publishing software which exploits it.

 

It appears to have started way back in 2011, when PBI solutions in general were denegrated and claimed to be 'non-standard':

 

http://www.atari.org.pl/forum/viewtopic.php?id=9527

 

If one is familar with the story of The Boy who Cried Wolf, it might be understandable why the PBI register 'issue', apparently highlighted some years later by means of a series of mocking forum posts, might fall on deaf ears. But this would pre-suppose that the issue is actually a 'bug' at all. Candle thinks not:

Quote

U1MB makes use of addresses from D380 to D3FF, even if only few registers are defined in current specification, rest is RESERVED FOR FUTURE USE, and should be treated as such

PORTB and PIA chip is not mapped into this address space at all

xxl deliberatly makes use of that reserved address space excluding group of 3000+ atari computers (as i was told) to run his software - bravo

just keep in mind this is also the case with Incognito equipped machines

there is limited address space inside atari, and having to waste 256 bytes of space just to map hardware that has 4 locations is wastefull, but understandable from the point of original designers - full address decoder costs, per unit, and every penny counts

U1MB reuses that wasted space - in current implementation only partially, but i rather have some space to grow, than squeeze it in the beggining and worry later how to add something new like DMA or whatever i would come with

Although later, someone asks:

Quote

can U1MB be modified, so it can run all of the software that runs on stock XL/XE computers? Yes or no.

And the response is:

Quote

perhaps, but not without rewrite in some drivers

besides, i won't do it, not because of this person

So who knows.

34 minutes ago, DjayBee said:

I don't know XXL personally but being ignored with a problem will never lead to any positive attitude.

And reporting issues and/or requesting changes in the most obnoxious and derisory manner imaginable is unlikely to earn the favour of the developer.

Edited August 20, 2023 by flashjazzcat

[Peri Noid]

16 minutes ago, Piotr D. Kaczorowski said:

In Atari 8-bit, compatibility essentially ends at 64KB

You'd be suprised, how many users assume, that it's all about compatibility with an 800 (48K) and the rest is not important

[Piotr D. Kaczorowski]

3 minutes ago, Peri Noid said:

You'd be suprised, how many users assume, that it's all about compatibility with an 800 (48K) and the rest is not important

 

I catch myself thinking locally. Right. If we take the whole world into account, then 48KB... should be enough for everyone

[+DjayBee]

58 minutes ago, flashjazzcat said:

If one is familar with the story of The Boy who Cried Wolf, it might be understandable why the PBI register 'issue', apparently reported some years later by means of a series of mocking forum posts, might fall on deaf ears.

This makes sense. I always ever read AtariAge.

 

59 minutes ago, flashjazzcat said:

But this would pre-suppose that the issue is actually a 'bug' at all. Candle thinks not:

I actually never cared if this was real life or purely academic.

... and always had a bag of good popcorn on my lap while watching its evolution on AtariAge. 😈

[+MrFish]

1 hour ago, Piotr D. Kaczorowski said:

Unfortunately, stirring up pointless sh*tst*rm in Poland is practically a national trait, or perhaps we do it for sport.

I'd forgotten MapRAM was part of the candle / XXL saga. Glad I could inadvertently help support one of Poland's national pastimes by inviting one party of the debate.

 

1 hour ago, Piotr D. Kaczorowski said:

In Atari 8-bit, compatibility essentially ends at 64KB.

4 hours ago, Piotr D. Kaczorowski said:

So perhaps it would be worthwhile to respect popular technology

I would add that there are ongoing concerns about various PAL software incompatibilities on NTSC machines (relating to screen refresh differences). I suppose NTSC Ataris could be considered popular technology.

 

4 hours ago, Piotr D. Kaczorowski said:

Nevertheless, I believe that those 2KB, which let's be honest are a certain addition not resulting from Atari standards, could stop being a bone of contention.

It really isn't a bone of contention for the community at large. An extra 2KB is basically irrelevant. It will remain a contention for those parties concerned with how it's enabled.

 

[Piotr D. Kaczorowski]

6 minutes ago, MrFish said:

I would add that there are ongoing concerns about various PAL software incompatibilities on NTSC machines (relating to screen refresh differences). I suppose NTSC Ataris could be considered popular technology.

 

I agree with you. To be honest, I even prefer the screen aspect ratio, and 60Hz makes the image smoother. I'm trying to find contact with the authors of VBXE, who might also recompile the cores to have the NTSC palette right away.

[+MrFish]

8 minutes ago, Piotr D. Kaczorowski said:

I even prefer the screen aspect ratio

Sometimes I prefer it (Antic 2 fonts, Antic 4 / Antic E pixels), sometimes not (when some objects end up looking vertically overstretched).

 

8 minutes ago, Piotr D. Kaczorowski said:

and 60Hz makes the image smoother.

Usually animations are smoother/faster; and this is why people want to push the limits in horizontal and vertical blanks on PAL machines, which is understandable.

 

8 minutes ago, Piotr D. Kaczorowski said:

I'm trying to find contact with the authors of VBXE, who might also recompile the cores to have the NTSC palette right away.

I didn't know correct palettes weren't already being handled.

 

[reifsnyderb]

@flashjazzcat:  For some reason I can't download the first document you are referring to.  But Atari has, in at least 2 documents, divided the $D600-$D7FF memory into 64 byte regions, with 64k available for each board.  (Except board 0.)  I am assuming the document is one of those.  At one point, I spent a couple hours looking at available schematics, and other documents, to try to figure out where this $D600-$D7FF memory actually came from.  None of Atari's 1090 boards even supply or use this memory.  I finally decided that maybe Atari's idea was that the computer was to provide the memory but that thought conflicted with the XL/XE MMU denying access to the memory.  I never read the section about the Atari 1400XL and Atari 1450XLD supplying this memory.  (It's also interesting that Atari not only added the access to the memory but then violated there own standard.)  Looking further, the mention of this memory, as it pertains to the Atari 1400XL and 1450XLD was not in the older versions of the Altirra Hardware Reference Manual so that's why I missed it.  So, for me anyhow, this mystery has been solved!    🙂   I'll add it to my PBI document.

 

I do agree that the U1MB has become a standard and making something that breaks compatibility would be a bad idea.  The thought is reflected in my PBI document as I provide a reference to 3rd party address use so that conflicts can be avoided.  Optionally, new hardware could be created that can be configured so as not to conflict with the U1MB.  (i.e.  Disable a feature by using a jumper.)

 

VBXE also uses memory in the $D600-$D7FF range and can be configured as to which part of that address range it resides in.

 

 

Edit to add:  I just looked at the 1450XLD schematic.  (Tong)  It appears that Atari replaced the MMU with a chip labelled "Carmen".

 

 

 

 

 

Edited August 20, 2023 by reifsnyderb

[reifsnyderb]

8 hours ago, xxl said:

none of the existing memory extensions conflict with MapRAM, only the U1MB modification.

Here is an example of memory expansion with MapRAM on an Antonia board with a 6502 processor:

 

Is MapRAM an Antonia option?  Do you have any information as to where MapRAM connects to on the system board?  (i.e.  On an 800XL, I think MapRAM's A15 out would have to connect to pin 10 of U27.)

 

I am thinking that, for non U1MB users, an advanced MMU board that adds MapRAM, $D600-$D7FF RAM, and only enables the ROMs on a read may be interesting.  (It would also allow that Axlon compatible 1090 board to work.)  Not being compatible with the U1MB is a big show-stopper, of course.  I may be interested in messing around with such a board in one of my computers as long as the amount of spaghetti wire can be minimized.

Edited August 20, 2023 by reifsnyderb

[flashjazzcat]

56 minutes ago, reifsnyderb said:

For some reason I can't download the first document you are referring to.

LOL - my apologies. I was actually trying to link to your PBI guide, but messed up the URL somehow.

56 minutes ago, reifsnyderb said:

I do agree that the U1MB has become a standard and making something that breaks compatibility would be a bad idea.

Of course, but I tend to assume that modern external PBI devices would have their own SRAM onboard anyway, and wouldn't be reliant on scavenging 2K of RAM from the host machine's base memory. To wit:

56 minutes ago, reifsnyderb said:

VBXE also uses memory in the $D600-$D7FF range and can be configured as to which part of that address range it resides in.

VBXE presents its register set on either of those two pages, and does not rely on the host machine's base memory in the same regions. The reason it's configurable (IIRC) is to avoid conflicts with PBI devices like MIO and the Black Box, and I suppose any other inflexible devices.

Edited August 20, 2023 by flashjazzcat

[reifsnyderb]

31 minutes ago, flashjazzcat said:

LOL - my apologies. I was actually trying to link to your PBI guide, but messed up the URL somehow.

lol  Yeah, I have a copy of that.  

 

31 minutes ago, flashjazzcat said:

Of course, but I tend to assume that modern external PBI devices would have their own SRAM onboard anyway, and wouldn't be reliant on scavenging 2K of RAM from the host machine's base memory.

The frustrating part of this is that Atari reserved 512 bytes, never supplied it, and now it has to be supplied by the card.  I ran into this recently, with the 80 column card, in that I needed less than 32 bytes.  Adding the SRAM chip to supply this would have taken up a lot of space on the board, required it be on the other side of the board (with a more expensive 4 layer board), required a bigger board, added to the cost, etc.  All for less than 32 bytes.  Looking at the 800XL, for example, this 512 bytes could have been supplied by adding a single chip.  So, yeah, PBI devices have to either scavenge the memory from somewhere or supply it themselves.

 

On my 320k 1090 card, I found that if I add an extra chip I can supply this 512 bytes.  But then there are incompatibilities with modern devices.