Up front: I used AI to do the cross-referencing for this, and this summary is AI written too. Trying to hold all of this in my head and type it out myself would have taken a week and I would still have got half of it wrong. Several of the findings were then put to ijor, who confirmed some and corrected me on others, so it is not just a machine talking to itself. More on that at the end.
The short version is that the memory map pages had a proper going over. Several real errors fixed, a new page added, and a few things flagged where the sources contradict each other.
What was actually wrong
The DMA status register at $FFFF8606, bit 0, was listed as 0 meaning no error and 1 meaning error. It is the other way round. The bit is clear on error and set when there is no error. Atari's own TOS source tests it that way in bios/floppy.S, EmuTOS does the same in bios/dma.h, and ijor confirmed it. This is the sort of bug that never crashes anything, it just quietly tells you the opposite of the truth. The same error is in the Dan Hollis hardware register listing that gets mirrored all over the place, so the wiki almost certainly inherited it rather than invented it.
The IDE block was listed at base $FFFF0000, which is unassigned I/O space. It should be $FFF00000. The offsets within the block were already correct, so it looks like a transposed digit that has been sat there quietly for years.
The Mega STE floating point coprocessor block had the Operand Register and the Instruction Address Register both at $FFFFFA46, which already belongs to the Restore Register. Three registers, one address. Four more registers of that block were missing entirely.
The Falcon sound mode control had the mono and stereo states both printed as 0, which makes the choice somewhat academic. It is 0 for stereo, 1 for mono.
The whole Falcon sound matrix and CODEC block from $FFFF8930 to $FFFF8942 was missing. That is what the old "DSP registers still missing" note was pointing at. All twelve registers are now in.
New page
There is now a System variables and low RAM page covering $140 to $5B3. That whole region was never documented. It includes the TT MFP vectors, the SCC vectors, the crash save area, and the TOS system variables, so things like _v_bas_ad, _hz_200, _vblqueue, hdv_rw, _drvbits and flock. Arguably the part of the map people actually use.
There is also a Complete memory map listing page now, which pulls all six sections into one continuous list for reading and searching. The individual pages are unchanged and are still where edits happen.
Flagged rather than fixed
A few things are marked CHECK or CONFLICT in the listing because I could not settle them. The IDE status register offset, where EmuTOS says $1D and the Atari Compendium says $1E. $FFFF8E0F appearing twice, once as a VME register and once as Mega STE cache control, where the Compendium puts cache control at $FFFF8E20 instead. The RAM_END arithmetic, which is annotated 14MB but the address given is 13MB. And an entry at $FFFFFF82 that has never had a description at all.
Source order
Where documents disagree, the listing now resolves in this order. Atari TOS source and EmuTOS first, since both are executable and run on real hardware. The Atari Compendium second, which is the best of the paper sources but not perfect, as it gets the IDE status offset wrong and contradicts itself on the FPC range. Everything else after that.
On the AI side of it
The useful thing here was not the writing, it was having something that could hold five wiki pages, the Compendium, the TOS source, the EmuTOS source and a couple of datasheets in view at once and notice where they disagree. That is a tedious job and not one I would ever have got through by hand. It also flagged things I would not have thought to question.
It is not infallible either. It got a couple of things wrong along the way and overstated its confidence on at least one finding, which is exactly why the results went to ijor rather than straight onto the wiki. He confirmed several points, corrected one, and wants to double check two more before committing. That is roughly the process I would want for any of this.
The honest bit, and a request
What has been checked is only the part that had a second source to check against. The blitter block, the VIDEL timing registers, the palettes, the MFP bit assignments, the ACIA, the RTC and the DSP host registers have not been cross-checked against anything, because nothing available covers them. They are unverified rather than confirmed correct. If there are more errors, that is where they are hiding.
Which leads to the request. What is commonly floating about on the internet for this stuff turns out to be wrong in places, and the same errors have been copied between listings for decades. If you know a particular chip or register block properly, please have a look at the relevant page and correct anything that is off, or flag it if you are not sure. The pages have not been touched in years and could do with more eyes on them than mine.
Wiki pages.
https://www.atari-wiki.com/index.php?ti ... and_Falcon
REMINDER - Stay logged in for at least 2 hours a week to get whitelisted.
Also it helps build a picture where our "good traffic" is coming from for detection scripts.
:o)
Also it helps build a picture where our "good traffic" is coming from for detection scripts.
:o)
Wiki Memory map pages updated
-
exxos
- Site Admin
- Posts: 28563
- Joined: 16 Aug 2017 23:19
- Location: UK
-
sporniket
- Site sponsor
- Posts: 1169
- Joined: 26 Sep 2020 21:12
- Location: France
Re: Wiki Memory map pages updated
Is it only me, or the page is empty ?
-
exxos
- Site Admin
- Posts: 28563
- Joined: 16 Aug 2017 23:19
- Location: UK
Re: Wiki Memory map pages updated
Looks like the link got chopped when i pasted it. Fixed now.
-
sporniket
- Site sponsor
- Posts: 1169
- Joined: 26 Sep 2020 21:12
- Location: France
-
exxos
- Site Admin
- Posts: 28563
- Joined: 16 Aug 2017 23:19
- Location: UK
Re: Wiki Memory map pages updated
Memory map pages: overhaul in progress
The memory map pages are being given a proper going over. Errors fixed, missing registers added, and bit level detail being filled in where it was never documented. This will take a few days so please bear with it while pages are in flux.
Why the pages look different
What I wanted was to keep the compact register list as it is, but let you click a register and see the full bit detail without cluttering the page. Turns out the wiki markup simply cannot do that. Preformatted text keeps your column alignment but refuses to allow links inside it, and the moment you switch to something that allows links, the wiki helpfully inserts its own paragraph breaks and mangles the spacing. Several hours of trying every combination confirmed it was not going to happen.
So the pages now use raw HTML instead. The upshot is that any register with extra detail shows its address in blue with a small arrow. Click it and the bit detail drops down underneath. Everything else looks and behaves exactly as before.
The blitter section on the IDE, Memory control and video page is the first one done, if you want to see how it works.
Where the information is coming from
In rough order of how much I trust them:
Atari's own TOS sources, reconstructed by Thorsten Otto, covering TOS 1.04 through 3.06. There is also one file of genuine TOS 4.04 Falcon code in there.
EmuTOS, which is actively maintained and boots on real hardware across the whole range.
Hatari, which as an emulator has to implement every bit correctly or software breaks. Its blitter code in particular is exceptionally well documented and some of it derives from ijor's reverse engineering and Verilog work.
The Atari Compendium, which is the best of the paper references but not perfect.
Where sources disagree I have noted it on the page rather than silently picking one. Anything resting on a single unconfirmed source is marked UNVERIFIED so you know what you are looking at.
Please check it
Triple check anything you know about. Some of these listings have carried the same errors for thirty years, copied from one document to the next, so do not assume something is right just because it looks familiar. If something is wrong or missing, post it in this thread, ideally with what it should say and where that comes from. A source reference is worth ten times a correction on its own, because it can be verified later.
If you have a wiki account you can edit the pages directly, which is very welcome. But please still post here saying what you changed. Several pages are being rewritten wholesale at the moment, and if I paste an updated page over the top of an edit I did not know about, your work vanishes. A quick note in the thread and that will not happen.
On the AI question, since it will come up
Yes, AI is being used for this. Cross referencing five wiki pages against four independent sources and spotting where they contradict each other is exactly the sort of tedious work it is good at, and doing it by hand would have taken weeks rather than days. It is not infallible either, it got several things wrong along the way and overstated its confidence more than once, which is precisely why the results are being checked against source code rather than taken on trust, and why I am asking you lot to check them too.
The memory map pages are being given a proper going over. Errors fixed, missing registers added, and bit level detail being filled in where it was never documented. This will take a few days so please bear with it while pages are in flux.
Why the pages look different
What I wanted was to keep the compact register list as it is, but let you click a register and see the full bit detail without cluttering the page. Turns out the wiki markup simply cannot do that. Preformatted text keeps your column alignment but refuses to allow links inside it, and the moment you switch to something that allows links, the wiki helpfully inserts its own paragraph breaks and mangles the spacing. Several hours of trying every combination confirmed it was not going to happen.
So the pages now use raw HTML instead. The upshot is that any register with extra detail shows its address in blue with a small arrow. Click it and the bit detail drops down underneath. Everything else looks and behaves exactly as before.
The blitter section on the IDE, Memory control and video page is the first one done, if you want to see how it works.
Where the information is coming from
In rough order of how much I trust them:
Atari's own TOS sources, reconstructed by Thorsten Otto, covering TOS 1.04 through 3.06. There is also one file of genuine TOS 4.04 Falcon code in there.
EmuTOS, which is actively maintained and boots on real hardware across the whole range.
Hatari, which as an emulator has to implement every bit correctly or software breaks. Its blitter code in particular is exceptionally well documented and some of it derives from ijor's reverse engineering and Verilog work.
The Atari Compendium, which is the best of the paper references but not perfect.
Where sources disagree I have noted it on the page rather than silently picking one. Anything resting on a single unconfirmed source is marked UNVERIFIED so you know what you are looking at.
Please check it
Triple check anything you know about. Some of these listings have carried the same errors for thirty years, copied from one document to the next, so do not assume something is right just because it looks familiar. If something is wrong or missing, post it in this thread, ideally with what it should say and where that comes from. A source reference is worth ten times a correction on its own, because it can be verified later.
If you have a wiki account you can edit the pages directly, which is very welcome. But please still post here saying what you changed. Several pages are being rewritten wholesale at the moment, and if I paste an updated page over the top of an edit I did not know about, your work vanishes. A quick note in the thread and that will not happen.
On the AI question, since it will come up
Yes, AI is being used for this. Cross referencing five wiki pages against four independent sources and spotting where they contradict each other is exactly the sort of tedious work it is good at, and doing it by hand would have taken weeks rather than days. It is not infallible either, it got several things wrong along the way and overstated its confidence more than once, which is precisely why the results are being checked against source code rather than taken on trust, and why I am asking you lot to check them too.
You do not have the required permissions to view the files attached to this post.
-
exxos
- Site Admin
- Posts: 28563
- Joined: 16 Aug 2017 23:19
- Location: UK
Re: Wiki Memory map pages updated
Memory map pages: register documentation now done
The memory map overhaul is finished. Every register across all six pages now has expandable bit detail, so you can click an address and see what each bit actually does rather than just its name.
What is there now
Around 130 registers have full bit documentation. Where a register has fields, value tables or quirks, they are written out. Where several registers work as a group, they share one entry rather than repeating the same explanation five times.
Registers that genuinely have nothing more to say, plain counters and address pointers, are left as they were. There is no point clicking through to be told that the sector count register holds a sector count.
Some of what turned up along the way
The NCR 5380 SCSI block had five of its eight register names wrong. Two of them were describing entirely the wrong register. The cause looks like several 5380 registers doing different things on read and on write, and the old names conflating the two. Anyone who wrote TT SCSI code from that page was working from bad names.
The STE palette has a trap that was not documented anywhere. The four bits within each colour nibble are in the order 0-3-2-1, not natural order. The extra bit the STE adds sits at the top of the nibble so that ST programs writing only three bits still produce the right colour. Read an STE palette value as a plain 4 bit number and you get the wrong intensity. I have been caught out by this myself.
The Mega ST clock chip has two entire banks of registers at the same addresses, switched by one bit in the mode register. The wiki documented only the first bank. The second holds the whole alarm register set, the 12/24 hour select and the leap year register.
The VME bus address space was missing completely. Adding it also answered a question I had left open: on a Mega STE the VME window starts at $00A00000, which means it does not sit above the alt-RAM area, it sits inside it. An 8MB alt-RAM board overlaps VME from $00A00000 and a 10MB board covers the whole range. Fine when no VME card is fitted, which is the usual case, but the two cannot coexist there.
Also added: the Falcon sound crossbar and CODEC registers, the full WD1772 command set, the complete MFP interrupt register maps, the YM2149 register list, and the STE LMC1992 mixing bug with the fix P. Putnik worked out.
Hardware add-ons
I have started adding add-on hardware addresses to the map, since those addresses are otherwise shown as unused and someone will eventually build something that collides. My own boards are in there now, marked as not present on stock hardware.
This part is nowhere near complete. There are a lot of add-on boards out there and I only know my own in any detail. Where I have no bit information the entry says so plainly rather than guessing.
One real collision has already turned up. EmuTOS supports the MonSTer board at $FFFFFE00, and my SEC Booster uses that exact address for its first control register. EmuTOS only touches it when built with MonSTer support, which is off by default, but it is there. That is one collision found by checking one source against one board, which gives you an idea of how many more are probably sitting undiscovered.
If you have made or use an add-on that claims addresses, please post the details and I will add them.
This needs more eyes
Everything has been cross checked against Hatari, EmuTOS, Atari's own TOS sources and the Atari Compendium, and the sources are now listed on the index page with links so you can check the working yourself.
That said, four sources agreeing is not the same as being right, and some of these errors had been sitting there for thirty years being copied from one document to the next without anyone noticing. A few entries rest on a single unconfirmed source and are marked UNVERIFIED. Where sources contradicted each other and I could not settle it, the entry says CONFLICT or CHECK and explains what the disagreement is rather than quietly picking one.
So please have a look at whatever you know well. If something is wrong, post it here with a source if you have one. If you have a wiki account you can edit directly, but please still post here saying what you changed, otherwise your work can get overwritten when I paste an updated page over the top.
The parts most likely to still be wrong are the ones fewest people use: the TT specific registers, the DSP host port, the STACY entries and anything marked UNVERIFIED.
EDIT:
I have also opened up a placeholder for datasheets for common chips
https://www.atari-wiki.com/index.php?ti ... datasheets
Would really need to know the best quality and the latest data sheet before I upload them to the wiki.. But I don't have time for that project.. So if anyone has really good copies of something already, then just let me know and I will dump them on the wiki :)
The memory map overhaul is finished. Every register across all six pages now has expandable bit detail, so you can click an address and see what each bit actually does rather than just its name.
What is there now
Around 130 registers have full bit documentation. Where a register has fields, value tables or quirks, they are written out. Where several registers work as a group, they share one entry rather than repeating the same explanation five times.
Registers that genuinely have nothing more to say, plain counters and address pointers, are left as they were. There is no point clicking through to be told that the sector count register holds a sector count.
Some of what turned up along the way
The NCR 5380 SCSI block had five of its eight register names wrong. Two of them were describing entirely the wrong register. The cause looks like several 5380 registers doing different things on read and on write, and the old names conflating the two. Anyone who wrote TT SCSI code from that page was working from bad names.
The STE palette has a trap that was not documented anywhere. The four bits within each colour nibble are in the order 0-3-2-1, not natural order. The extra bit the STE adds sits at the top of the nibble so that ST programs writing only three bits still produce the right colour. Read an STE palette value as a plain 4 bit number and you get the wrong intensity. I have been caught out by this myself.
The Mega ST clock chip has two entire banks of registers at the same addresses, switched by one bit in the mode register. The wiki documented only the first bank. The second holds the whole alarm register set, the 12/24 hour select and the leap year register.
The VME bus address space was missing completely. Adding it also answered a question I had left open: on a Mega STE the VME window starts at $00A00000, which means it does not sit above the alt-RAM area, it sits inside it. An 8MB alt-RAM board overlaps VME from $00A00000 and a 10MB board covers the whole range. Fine when no VME card is fitted, which is the usual case, but the two cannot coexist there.
Also added: the Falcon sound crossbar and CODEC registers, the full WD1772 command set, the complete MFP interrupt register maps, the YM2149 register list, and the STE LMC1992 mixing bug with the fix P. Putnik worked out.
Hardware add-ons
I have started adding add-on hardware addresses to the map, since those addresses are otherwise shown as unused and someone will eventually build something that collides. My own boards are in there now, marked as not present on stock hardware.
This part is nowhere near complete. There are a lot of add-on boards out there and I only know my own in any detail. Where I have no bit information the entry says so plainly rather than guessing.
One real collision has already turned up. EmuTOS supports the MonSTer board at $FFFFFE00, and my SEC Booster uses that exact address for its first control register. EmuTOS only touches it when built with MonSTer support, which is off by default, but it is there. That is one collision found by checking one source against one board, which gives you an idea of how many more are probably sitting undiscovered.
If you have made or use an add-on that claims addresses, please post the details and I will add them.
This needs more eyes
Everything has been cross checked against Hatari, EmuTOS, Atari's own TOS sources and the Atari Compendium, and the sources are now listed on the index page with links so you can check the working yourself.
That said, four sources agreeing is not the same as being right, and some of these errors had been sitting there for thirty years being copied from one document to the next without anyone noticing. A few entries rest on a single unconfirmed source and are marked UNVERIFIED. Where sources contradicted each other and I could not settle it, the entry says CONFLICT or CHECK and explains what the disagreement is rather than quietly picking one.
So please have a look at whatever you know well. If something is wrong, post it here with a source if you have one. If you have a wiki account you can edit directly, but please still post here saying what you changed, otherwise your work can get overwritten when I paste an updated page over the top.
The parts most likely to still be wrong are the ones fewest people use: the TT specific registers, the DSP host port, the STACY entries and anything marked UNVERIFIED.
EDIT:
I have also opened up a placeholder for datasheets for common chips
https://www.atari-wiki.com/index.php?ti ... datasheets
Would really need to know the best quality and the latest data sheet before I upload them to the wiki.. But I don't have time for that project.. So if anyone has really good copies of something already, then just let me know and I will dump them on the wiki :)
-
exxos
- Site Admin
- Posts: 28563
- Joined: 16 Aug 2017 23:19
- Location: UK
Re: Wiki Memory map pages updated
I notice there are basically a few conflicts between register listings pages
https://www.atari-wiki.com/index.php?ti ... edirect=no
But that contains a lot of errors compared to the pages I updated earlier. So I have just put a redirect on their the time being with a note that that they should not be updated anymore and the new pages should be the ones to update in the future.
Also a more CT60 page which also duplicates Falcon registers..
https://www.atari-wiki.com/index.php?ti ... sting_V1.0
I will update the main register lists with anything missing from those pages, then "retire" the pages with a note as they are now outdated compared to the now master listings. Its to confusing having (IMO anyway) multiple pages of basically the same registeers. Having just 1 set will be easier to maintain than multiple pages of similar contents. I will sort out a better method of separating machine types later as well.
The main issue is the amount of information from various sources, which either copy each other or conflict with other stuff. So it's difficult to know what the "proper" list actually is. I am using A.I. to try and figure it all out. It be humanly impossible to audit everything otherwise.
https://www.atari-wiki.com/index.php?ti ... edirect=no
But that contains a lot of errors compared to the pages I updated earlier. So I have just put a redirect on their the time being with a note that that they should not be updated anymore and the new pages should be the ones to update in the future.
Also a more CT60 page which also duplicates Falcon registers..
https://www.atari-wiki.com/index.php?ti ... sting_V1.0
I will update the main register lists with anything missing from those pages, then "retire" the pages with a note as they are now outdated compared to the now master listings. Its to confusing having (IMO anyway) multiple pages of basically the same registeers. Having just 1 set will be easier to maintain than multiple pages of similar contents. I will sort out a better method of separating machine types later as well.
The main issue is the amount of information from various sources, which either copy each other or conflict with other stuff. So it's difficult to know what the "proper" list actually is. I am using A.I. to try and figure it all out. It be humanly impossible to audit everything otherwise.
Who is online
Users browsing this forum: ClaudeBot, Perplexity [Bot] and 6 guests