Jump to content

Photo

Altirra Hardware Ref Guide


67 replies to this topic

#1 Heaven/TQA OFFLINE  

Heaven/TQA

    Quadrunner

  • 10,338 posts
  • Location:Baden-Württemberg, Germany

Posted Thu Dec 15, 2011 8:28 AM

never had a deep look into the PDF

http://www.virtualdu...ence Manual.pdf

but that's a great source of information and well written... people would have been paying for that info crunched into a book in the 80s.

#2 Rybags ONLINE  

Rybags

    Quadrunner

  • 15,163 posts
  • Location:Australia

Posted Thu Dec 15, 2011 8:34 AM

Yep. The official docs were lacking with a lot of the DMA pattern stuff. Not to mention the advanced Pokey features being poorly documented.

#3 1NG OFFLINE  

1NG

    Chopper Commander

  • 133 posts
  • Location:Lübeck, Germany

Posted Thu Dec 15, 2011 1:08 PM

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.

#4 phaeron OFFLINE  

phaeron

    River Patroller

  • 2,251 posts
  • Location:USA

Posted Fri Dec 16, 2011 12:12 AM

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

Attached Files



#5 Rybags ONLINE  

Rybags

    Quadrunner

  • 15,163 posts
  • Location:Australia

Posted Fri Dec 16, 2011 5:02 AM

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.

-

#6 Heaven/TQA OFFLINE  

Heaven/TQA

    Quadrunner

  • Topic Starter
  • 10,338 posts
  • Location:Baden-Württemberg, Germany

Posted Fri Dec 16, 2011 8:30 AM

yup. had forgotten the 40x39 text mode, too... ;)

and I would suggest the "De Re Programmers Card" to include as yesterday I found it difficult to find register adresses... ;)

#7 xxl OFFLINE  

xxl

    Dragonstomper

  • 990 posts
  • Location:Rabka-Zdrój /Poland

Posted Fri Dec 16, 2011 8:51 AM

page 12 and below: undocumented opcodes 6502c

Edited by xxl, Fri Dec 16, 2011 8:53 AM.


#8 phaeron OFFLINE  

phaeron

    River Patroller

  • 2,251 posts
  • Location:USA

Posted Sat Dec 17, 2011 12:25 AM

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

#9 Rybags ONLINE  

Rybags

    Quadrunner

  • 15,163 posts
  • Location:Australia

Posted Sat Dec 17, 2011 12:41 AM

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.

#10 phaeron OFFLINE  

phaeron

    River Patroller

  • 2,251 posts
  • Location:USA

Posted Sat Dec 17, 2011 1:05 AM

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.

#11 Rybags ONLINE  

Rybags

    Quadrunner

  • 15,163 posts
  • Location:Australia

Posted Sat Dec 17, 2011 1:06 AM

If nobody else steps in, I'll get an XEGS out later and work it out.

Yes, those membrane keypads are utter rubbish - I've got one too.

#12 snicklin OFFLINE  

snicklin

    River Patroller

  • 2,066 posts
  • Location:Australia

Posted Sat Dec 17, 2011 6:27 AM

This is such a high quality document, putting a lot of other books to shame.

If it wasn't a work-in-progress document, I'd like to print it all out and have it bound.

#13 Rybags ONLINE  

Rybags

    Quadrunner

  • 15,163 posts
  • Location:Australia

Posted Sat Dec 17, 2011 6:58 AM

OK, got it.

PORTB bit 2 overrides bit 6. So, Missile Command will only work if bit 2=1.

So, combinations bit6/bit2:
0 0 = Basic
0 1 = Missile Command
1 0 = Basic
1 1 = RAM

#14 HiassofT OFFLINE  

HiassofT

    Stargunner

  • 1,028 posts
  • Location:Salzburg, Austria

Posted Sat Dec 17, 2011 9:03 AM

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, Sat Dec 17, 2011 9:04 AM.


#15 phaeron OFFLINE  

phaeron

    River Patroller

  • 2,251 posts
  • Location:USA

Posted Sat Dec 17, 2011 5:45 PM

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.

#16 Rybags ONLINE  

Rybags

    Quadrunner

  • 15,163 posts
  • Location:Australia

Posted Sat Dec 17, 2011 6:38 PM

400/800 return address bus noise, not sure if it's high byte always or if some show $FF - it's been a while.

Strange about the 130XE - $D6 / $D7 don't have any physical selection other than the unconnected mux output but $D1 / $D5 have select lines going to ECI / Cart.

#17 ijor OFFLINE  

ijor

    Stargunner

  • 1,900 posts

Posted Sun Dec 18, 2011 12:01 AM

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, Sun Dec 18, 2011 12:02 AM.


#18 phaeron OFFLINE  

phaeron

    River Patroller

  • 2,251 posts
  • Location:USA

Posted Sun Dec 18, 2011 2:14 AM

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.

#19 Rybags ONLINE  

Rybags

    Quadrunner

  • 15,163 posts
  • Location:Australia

Posted Sun Dec 18, 2011 2:24 AM

But how important is emulating it? Does Altirra even support the image types with protection parameters?

And for newly developed software it's not really needed and might encourage bad practices if people assumed unused addresses always returned known values.

#20 phaeron OFFLINE  

phaeron

    River Patroller

  • 2,251 posts
  • Location:USA

Posted Sun Dec 18, 2011 2:38 AM

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.

#21 fox OFFLINE  

fox

    Chopper Commander

  • 228 posts
  • Location:Poland

Posted Sun Dec 18, 2011 6:56 AM

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, Sun Dec 18, 2011 6:59 AM.


#22 HiassofT OFFLINE  

HiassofT

    Stargunner

  • 1,028 posts
  • Location:Salzburg, Austria

Posted Sun Dec 18, 2011 9:08 AM

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

#23 Bryan OFFLINE  

Bryan

    Quadrunner

  • 10,711 posts
  • Cruise Elroy = 4DB7
  • Location:Chesaning, MI

Posted Sun Dec 18, 2011 10:18 AM

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.

#24 CharlieChaplin OFFLINE  

CharlieChaplin

    River Patroller

  • 2,548 posts

Posted Sun Dec 18, 2011 10:48 AM

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.

Attached Files


Edited by CharlieChaplin, Sun Dec 18, 2011 10:58 AM.


#25 phaeron OFFLINE  

phaeron

    River Patroller

  • 2,251 posts
  • Location:USA

Posted Sun Dec 18, 2011 2:27 PM

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.chell...ga/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.




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users