Jump to content
IGNORED

Altirra Hardware Ref Guide


Heaven/TQA

Recommended Posts

I worked with this doc for a few months now and it is excellent stuff. It is deep to the hardware and not for beginners but a very well made reference (as said in its title).

The dma pattern in the graphics modes is presented very well. I im totally impressed of Altirra and the documentation.

I first saw the values of the randomgenerator from 0 to $429 in that documentation. Most information is very short and precise.

Very impressive.

Link to comment
Share on other sites

I've been working on a revised edition of this doc -- current draft is attached. I've added a bunch of PIA interrupt and serial port timing info and also started on more peripheral information. I have some XEGS and 1030 modem info that hasn't been integrated yet, and the disk drive info is currently incomplete.

 

I think there's a need for a modern comprehensive OS/programmer manual too, but I haven't had anything gel together there yet. The hardware manual is too big to include how-to programming information since it's already 90 full-size pages, and OpenOffice Writer is already showing strain handling the doc as it is (it takes about a minute to export to PDF).

atari2.zip

Link to comment
Share on other sites

A few suggestions/additions, possible errors (please don't hate me!)

 

- page 21, miscellaneous connections. TRIG2 is used as keyboard sense for the XEGS, this can change coldstart behaviour (also warmstart ?)

 

- p 21, unassigned addresses. Not all systems return $FF for unassigned addresses (this was discussed elsewhere, I'd always thought XL/XE did return $FF but apparently not the case)

 

- p 28, abusing vertical scrolling. Might be worth adding the other useful mode, shortened text characters. Requires 2 character sets since adjacent rows are truncated at the top then bottom.

 

- p 31, hires last scanline bug. The bug can be invoked on any scanline if DMA is turned off for DList fetches. The bug can be averted for a hires mode extending to scanline 248 by setting DMACTL lower bits to 00 or 11 at the right time on that scanline.

 

- p 32, changes to HScrol during scanline. Wasn't it discovered (Antic decap thread) that certain changes to HScrol will mess with the LFSR-indexed lookup of character codes ? Certain changes to HScrol cause corruption, which so far hasn't been found to be useful.

 

- p 36, missed NMIs. I thought the window for this possibility was only 2 cycles ?

 

- p 60, random numbers/audio. Would it be possible to describe the LFSR formula used for each Polycounter type ?

 

- p 75, accessories. Maybe include keypad controller with programming description.

 

- p 83, tape recorder. 64 KHz mode for recording, not 15 KHz.

 

-

Link to comment
Share on other sites

- page 21, miscellaneous connections. TRIG2 is used as keyboard sense for the XEGS, this can change coldstart behaviour (also warmstart ?)

 

Yeah, I haven't added the XEGS info. One of the PORTB bits is different, too.

 

- p 21, unassigned addresses. Not all systems return $FF for unassigned addresses (this was discussed elsewhere, I'd always thought XL/XE did return $FF but apparently not the case)

 

Do you have a reference? I see from the schematics that there are 10K pullups on the data bus, so I'm curious if this is what is causing the $FF and you can fail to get it if there are extra devices on the data bus. The Apple II doesn't have this effect and I'm guessing it's because it doesn't have pullups, so you can read the last byte on the data bus instead.

 

- p 31, hires last scanline bug. The bug can be invoked on any scanline if DMA is turned off for DList fetches. The bug can be averted for a hires mode extending to scanline 248 by setting DMACTL lower bits to 00 or 11 at the right time on that scanline.

 

Shutting off display list DMA is basically the same thing, I think. I forgot about the DMACTL width bit effect, though.

 

- p 32, changes to HScrol during scanline. Wasn't it discovered (Antic decap thread) that certain changes to HScrol will mess with the LFSR-indexed lookup of character codes ? Certain changes to HScrol cause corruption, which so far hasn't been found to be useful.

 

The issue that I know of is that if you change bits 1-3, you can cause ANTIC to miss the playfield stop and leaves bits in the clock loop, resulting in abnormal playfield DMA fetch. I haven't done enough research on this yet to determine all of the exact conditions. I want to do that at some point as this is the last big unemulated bug I know about that can nail you when testing HSCROL tricks on an emulator.

 

- p 36, missed NMIs. I thought the window for this possibility was only 2 cycles ?

 

There's only one magic cycle position, but the 6502 takes 7 cycles to acknowledge the interrupt. I should reword that a bit.

 

- p 60, random numbers/audio. Would it be possible to describe the LFSR formula used for each Polycounter type ?

 

The polynomials are specified in section 5.6. I think all of the polynomials are correct, although only the 9-bit and 17-bit ones can be verified in code.

 

- p 75, accessories. Maybe include keypad controller with programming description.

 

A keypad controller different than the CX-85?

 

- p 83, tape recorder. 64 KHz mode for recording, not 15 KHz.

 

Argh... yeah, that part is totally wrong, it's 64KHz with frequency values of 5 and 7.

Link to comment
Share on other sites

The 2600 keypads are different to the CX-85. Page 159 OS Manual has a sample Pascal program. PIA PORT bits are used to select an individual row, and the columns are determined by the Paddle/Strig states. Also, keypads only have 12 buttons.

 

XEGS - bit 6 for Missile Command, I believe. Unsure how the interaction with bit 1 goes, maybe bit 1=0 means "Select ROM" and bit 6 determines if that ROM is Basic or the game.

 

Unassigned addresses - unsure who came up with the "not always $FF" determination, probably Hias or Ijor. I think the info appeared in a somewhat unrelated thread.

Link to comment
Share on other sites

Alright, shouldn't be too hard to emulate and document the 2600 keypad. (I have bad memories of that keypad, since I got it as a kid with Cookie Monster Munch, which was not a good game.)

 

PORTB bit 6 = 0 enables the Missile Command ROM on the XEGS. I don't have info on whether it has priority over the BASIC ROM, though.

Link to comment
Share on other sites

Unassigned addresses - unsure who came up with the "not always $FF" determination, probably Hias or Ijor. I think the info appeared in a somewhat unrelated thread.

Several other people besides me noticed that. The reason is that the XEs (not sure if it's true for all XEs, at least the 130 XEs I checked) don't have the 10k pull-up resistors on the databus. So the databus is effectively in high-impedance state when reading unmapped addresses, allowing for easy crosstalk of other lines into the databus etc. One pattern we often saw was that we read back the high address lines (A8-A15).

 

A quick test on my stock 130XE gave this: Reading $D5xx gave either $D5 or sometimes 0, $D6xx either $D6 or sometimes 0, $D7xx either $D7 or sometimes 0.

 

Edit: and reading $D1xx gave either $D1 or 0

 

so long,

 

Hias

Edited by HiassofT
Link to comment
Share on other sites

Thanks for the XEGS banking test!

 

I checked my 130XE and I'm seeing similar behavior... although $D1xx and $D5xx always return $D1 and $D5 while $D6xx and $D7xx always return 0, which I can't explain, since I have no peripherals connected. Strange. Do the 400/800 have similar behavior? I don't see any pullups on the data bus in the 800 schematics.

Link to comment
Share on other sites

The reason is that the XEs (not sure if it's true for all XEs, at least the 130 XEs I checked) don't have the 10k pull-up resistors on the databus.

 

This is even worse on 400/800 machines. It is worse because the unmapped address range is bigger, including the $CXXX range. And because some protections break if the emulator returns always $FF.

 

Phaeron, check VAPI images of MULE, or any other older ECA release, under 800 (OS-B) mode.

 

So the databus is effectively in high-impedance state when reading unmapped addresses, allowing for easy crosstalk of other lines into the databus etc. One pattern we often saw was that we read back the high address lines (A8-A15).

 

I don't think this is crosstalk. The reason you read the high address is because that's the last value driven to the data bus. It was driven in the previous cycle when fetching the address bytes for the current instruction. The data bus tends to retain the previous value due to capacitance.

 

Of course, this is not 100% reliable. And any DMA or refresh cycle would interfere.

Edited by ijor
Link to comment
Share on other sites

Yup, ijor's correct... I just tried again, and the sporadic $00 bytes are indeed due to ANTIC DMA. Since the text screen was mostly blank, both the name and character bytes were typically $00.

 

Oddly, while the ECA copy protection mechanism detects all $FF at $C000-CFFF as a custom OS, it does allow RAM at that address.

 

This ranks pretty highly on the ordered list of annoying behaviors to emulate. I had managed to keep data bus tracking to horizontal blank, but in order to emulate this I would need to do it all the time. Bleah.

Link to comment
Share on other sites

I have a rule: if it exists, someone has depended on it, and therefore it is worthy to emulate. I'm not as worried in this case about people relying on it as the differing behavior between 400/800/XE and XL would make it hard to depend on.

 

 

The lack of this emulation actually is visible. Altirra can read VAPI (.ATX) images, and as ijor says, M.U.L.E. does not boot in 400/800 mode with a standard 48K machine for exactly this reason.

Link to comment
Share on other sites

Several other people besides me noticed that. The reason is that the XEs (not sure if it's true for all XEs, at least the 130 XEs I checked) don't have the 10k pull-up resistors on the databus.

I've seen that in a "new" 65 XE (or was it 130 XE). My "old" 65 XE (without the ECI port) reads $FF.

Edit: I'm still looking for correct and complete explanation of the undocumented opcodes 93, 9b, 9f and bb.

Edited by fox
Link to comment
Share on other sites

So the databus is effectively in high-impedance state when reading unmapped addresses, allowing for easy crosstalk of other lines into the databus etc. One pattern we often saw was that we read back the high address lines (A8-A15).

 

I don't think this is crosstalk. The reason you read the high address is because that's the last value driven to the data bus. It was driven in the previous cycle when fetching the address bytes for the current instruction. The data bus tends to retain the previous value due to capacitance.

Duh, of course, this makes a lot more sense!

 

Getting these patterns from crosstalk seemed somehow unlikely, but I was too focussed on it that I completely forgot about the high address byte fetch in the cycle before...

 

Of course, this is not 100% reliable. And any DMA or refresh cycle would interfere.

Refresh cycles could be interesting, as in this case the databus is tri-stated for 2 consecutive cycles (pattern: high address fetch, refresh, unmapped memory access). I guess in this case we could maybe get different results with different Ataris.

 

so long,

 

Hias

Link to comment
Share on other sites

I have a rule: if it exists, someone has depended on it, and therefore it is worthy to emulate. I'm not as worried in this case about people relying on it as the differing behavior between 400/800/XE and XL would make it hard to depend on.

 

 

The lack of this emulation actually is visible. Altirra can read VAPI (.ATX) images, and as ijor says, M.U.L.E. does not boot in 400/800 mode with a standard 48K machine for exactly this reason.

It might be enough just having an option to always return FF or return a random number when reading unmapped memory.

Link to comment
Share on other sites

Alright, shouldn't be too hard to emulate and document the 2600 keypad. (I have bad memories of that keypad, since I got it as a kid with Cookie Monster Munch, which was not a good game.)

 

 

Hmm,

 

maybe a short Atari Basic program for the VCS keypads will do ?!? If so, here are two programs (working with both VCS keypads)...

 

(Please note, compared to most calculators, Atari did change/exchange the first and last row of numbers with these keypads.)

 

And err, the Cookie Monster Munch pad was a kids-controller, not sure if this is fully compatible to the other VCS keypads (released a) as a pair of two pads for keyboard replacement and b) as a single and slighty larger pad for the VCS version of Star Raiders; but the kids-controller is the largest of these keypads)...

 

Damn it, I do not know the official CX numbers for the two VCS keypads, nor for the kids-controller, maybe someone can show a link or a photo of them here...?!?

-Andreas Koch.

VCSKEYBO.zip

Edited by CharlieChaplin
Link to comment
Share on other sites

I haven't included undocumented opcode info largely because I don't have anything original to contribute yet. This is the best doc I know of on the subject:

http://members.chello.nl/taf.offenga/illopc31.txt

 

$9B and $BB appear to agree with Visual6502; $93 and $9F IIRC involve bus fights and so are unstable.

 

Returning $FF from unassigned memory definitely doesn't work -- that's what Altirra does now.

 

I think the data bus could be tri-stated for a long time if the playfield and character set are both pointed at unassigned memory. I wonder how long data would last on the bus.

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...