Jump to content
Heaven/TQA

Altirra Hardware Ref Guide

Recommended Posts

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

 

Yes, this is probably to allow for 52K ram expansions.

 

Noise "detection" is implemented reading one word twice every 64 bytes at $C000-CFFF. If at least one reading at the same address gives a different word, then it is assumed to be ok (noise). "Normally", reading the same address would return the same value (no noise, protection fail). But probably at least once it will hit a DMA cycle, and then the protection would pass. I am guessing that whoever implemented the protection wasn't aware what exactly was going on.

 

Btw, it would be good if someone could confirm the behaviour on a 400/800 computer.

Share this post


Link to post
Share on other sites

$93 and $9F IIRC involve bus fights and so are unstable.

 

Those aren't entirely unstable..

http://sourceforge.n...21&atid=1057617

 

Interesting. I don't know if this applies here, though -- IIRC, the C64 stops the 6510 using RDY, whereas on the Atari it is stopped using HALT or by stopping the clock. In order to get into a RDY-based halt you'd have to do something crazy like hit WSYNC with one of these instructions, in which case the written data goes into the bit bucket.

Share this post


Link to post
Share on other sites

C64 RAM gets hit at ~ 2 MHz effective, VIC-2 is on the bus almost every 2nd cycle so there'd be residual noise almost every 6510 cycle.

 

No special control is used for those accesses, the CPU is just kept in the low (?) part of the cycle for an extended time - similar to original 400/800 method except VIC controlling the clock.

 

AFAIK it only uses /RDY for burst accesses like badlines and sprite fetches.

Share this post


Link to post
Share on other sites

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

I believe that $9B is identical to $9F, except that it additionally puts A&X in S (this part appears to be stable). Correct me if I'm wrong.

 

As for $BB the only part I don't understand is the Z flag. Sometimes it's not set when it should be according to the result, e.g.

ldx	 #$f0
txs
lda	 #$0f
sta	 m,y
dta	 b($bb),a(m)
; A=00 X=00 S=00 F=__**____

Edited by fox

Share this post


Link to post
Share on other sites

C64 RAM gets hit at ~ 2 MHz effective, VIC-2 is on the bus almost every 2nd cycle so there'd be residual noise almost every 6510 cycle.

 

No special control is used for those accesses, the CPU is just kept in the low (?) part of the cycle for an extended time - similar to original 400/800 method except VIC controlling the clock.

 

AFAIK it only uses /RDY for burst accesses like badlines and sprite fetches.

 

I believe Apple was the first to use this method (leave it Woz to find the tricks). The 6502 doesn't really need the bus during the first half of a cycle- it's the 2nd half where things get latched and whatnot. With a little glue logic and some double-speed RAM, you can make a DMA cycle available for every CPU cycle. The upside is a very simple timing structure (unless you need even more DMA bandwidth, as with badlines). The downside is a slower CPU clock. I believe on the Apple, PWM sound effects were easy to code because the CPU runs in a very deterministic manner.

  • Like 1

Share this post


Link to post
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.

They are all on the Atari 2600 Controllers page here on AA. http://www.atariage....l?SystemID=2600

 

CX23 is the Kids Controller, CX50 is the Atari Keypad, and the CX21 is the one that came with Star Raiders. I have a CX21 I have never taken out of the box, but I have played with the CX50 connected to the 8bit - it's nice if all you want is the ability to read the numbers (since there are just 12 buttons total, unlike the CX85, which has 17). As a side note, I had NEVER seen the CX-43 controllers before! Cool!

Edited by JohnBuell

Share this post


Link to post
Share on other sites

Hmmm. I just tried the code from the VICE bug report on my 130XE, and it shows all of the same behavior from the C64 except for the flickering. It seems that whatever VIC-II is doing to trigger the weird behavior on the C64 doesn't happen between ANTIC and SALLY.

 

What's not so cool is that this test seems to break Atari800 -- looking at CVS it looks like the instruction's odd page crossing behavior is not implemented. :( VICE's 64doc.txt correctly notes the page crossing behavior, while illopc31.txt does not.

shy.zip

Share this post


Link to post
Share on other sites

Reverse engineered 6502 circuit seems to reveal a few bugs related to RDY. But most of them don't apply to the Atari. RDY functionality is limited on the Atari. It is asserted only when writing to WSYNC. This hardwires a fixed relation between the activation of RDY and a write cycle. In addition, RDY is released at a fixed horizontal position. Which in turns means a fixed relation between RDY release and NMI activation.

 

This bug related to SHx and RDY is one case that doesn't seem possible in the Atari. Not even if you use SHx to write to WSYNC. If I undertand correctly the bug description linked above, the bug requires that RDY would be asserted just before the write cycle of the SHx instruction. That would mean too many cycles since the previous instruction writing to WSYNC.

Share this post


Link to post
Share on other sites

I've just uploaded a new edition of the manual. The current revision is available at the same link from the first post, or you can download the attached version if the link doesn't work. This is the list of changes from the last couple of revisions.

 

I'm thinking that the next new section in this manual might have to be recent add-ons like new flash cartridges and IDE/memory expansions, because that info is scattered all over the place and actually a bit hard to find.

This release
  • CPU: Added section on 65C02 and 65C816 compatibility issues.

  • System Control: Added information on Parallel Bus Interface IRQs.

  • POKEY: Added keyboard scan code table.

  • GTIA: Updated with new table of player/missile/playfield priority conflicts and information about priority conflicts in GTIA modes.

  • Serial I/O: Now has its own chapter, including information about type 0-4 polling and device-provided relocatable loaders.

  • 850: Corrected errors in the description of the Write command, expanded description of the Stream command, and added sections on the 850 bootstrap process.

  • Disk: Added more details on 810 FDC controller status and command error conditions, and a new section about disk anomalies used by protection mechanisms.

  • New section on XEP80 device.

  • Reference: Updated to note guarantees on PAL register bits, and fixed errors in PACTL listing and register quick reference.

05/14/2013 release
  • ANTIC updates:

    • Bus activity during WSYNC.

    • Abnormal playfield DMA.

  • GTIA updates:

    • Border behavior in mode 10.

    • Player/missile shift details and lockup state.

  • POKEY updates:

    • Polynomial counter patterns and timing behaviors.

HWMan-20140427.zip

  • Like 12

Share this post


Link to post
Share on other sites

I'm thinking that the next new section in this manual might have to be recent add-ons like new flash cartridges and IDE/memory expansions, because that info is scattered all over the place and actually a bit hard to find.

+1 for that. :)

Share this post


Link to post
Share on other sites

Some pretty indepth stuff re Antic DMA and behaviour when certain registers are messed with during the scanline.

 

Did the information from decap come into play working some of this out? Or was it just from plain old testing of all the various combinations of register hits?

Share this post


Link to post
Share on other sites

Just read through the part about type 0-4 polling and relocatable loaders - stuff which has seemingly just been mentioned in passing elsewhere. Absolutely excellent.

Share this post


Link to post
Share on other sites

I pretty much scrape info from wherever I can find it: the official Hardware and OS Manuals, XL Addendum Manual, formerly internal Atari documents from the AHS, stuff post here on AtariAge, schematics on the web, ROM disassemblies, etc. The Bibliography lists some sources. ijor's decap reschematics are excellent, but it's pretty hard to determine behavior from VLSI schematics, particularly when it comes to 7+ layers of inverted gates, three layers of PLAs, and several sets of couplers. I rely mostly on testing on real hardware, because that's the only way I can absolutely verify that a theory is correct. It also provides an easy way to regression test emulators (or FPGA reimplementations!).

 

For the type 3/4 polling, the authoritative source is the XL Addendum, and for type 0-1 polling and relocatable loaders, the Sweet 16 OS Supplement parts 2 and 3 from the AHS are what you want. The latter's a bit thick, but it provides a lot of information on the OS side of the loader that I haven't put in the hardware manual (because it's software, not hardware). Relocatable loaders are probably mostly useless as I haven't heard of a single device or program that supports them, but maybe one will magically appear one day. I dug this information up while pushing Altirra's built-in OS to feature complete.

  • Like 2

Share this post


Link to post
Share on other sites

It also provides an easy way to regression test emulators (or FPGA reimplementations!).

 

Yes this hardware manual, and acid800, are excellent for this. Think the FPGA reimplementation would run about 2 games otherwise... :)

 

Many thanks - looking forward to reading this new version as soon as I get a chance.

  • Like 1

Share this post


Link to post
Share on other sites

After a long delay... another update to the Hardware Manual:

  • System: Added information about floating PIA port B bits.
  • CPU: Added new sections on new 65C816 functionality, undocumented 6502 opcodes, and opcode
  • tables.
  • ANTIC: New sections on display timing, effects of extending the height of mode lines.
  • POKEY: Added info about keyboard conflicts.
  • GTIA: Added info about color generation.
  • New chapter on cartridges: AtariMax, SIC!, SIDE, Corina, R-Time 8, Veronica.
  • New chapter on Parallel Bus Interface devices: Black Box, Multi I/O.
  • Additional device information: R-Verter, MidiMate, Ultimate1MB, VideoBoard XE.
  • Additional XEP-80 commands.
  • New appendices on polynomial counters and physical floppy disk formats.

 

HWMan-20150705.zip

  • Like 18

Share this post


Link to post
Share on other sites

Just had a quick look in the GTIS color generation. I am very happy that you added it.

Will read it when I have time and muse ;)

 

The HW manual in general is an awesome piece of write up. Only reference I use!

  • Like 1

Share this post


Link to post
Share on other sites

Thank you for this profound and condensed atari compendium.

 

Just one question: what does IR mode stand for? I've seen it often here in connection with antic's graphic modes, but can't think of any meaning for "IR"

Share this post


Link to post
Share on other sites

Thank you for this profound and condensed atari compendium.

 

Just one question: what does IR mode stand for? I've seen it often here in connection with antic's graphic modes, but can't think of any meaning for "IR"

 

"Instruction Register". You can find out more about it here: ANTIC Technical Data

Edited by MrFish

Share this post


Link to post
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...