andym00 Posted December 19, 2011 Share Posted December 19, 2011 $93 and $9F IIRC involve bus fights and so are unstable. Those aren't entirely unstable.. http://sourceforge.net/tracker/index.php?func=detail&aid=3334602&group_id=223021&atid=1057617 Quote Link to comment Share on other sites More sharing options...
ijor Posted December 19, 2011 Share Posted December 19, 2011 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. Quote Link to comment Share on other sites More sharing options...
phaeron Posted December 19, 2011 Share Posted December 19, 2011 $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. Quote Link to comment Share on other sites More sharing options...
Rybags Posted December 19, 2011 Share Posted December 19, 2011 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. Quote Link to comment Share on other sites More sharing options...
fox Posted December 19, 2011 Share Posted December 19, 2011 (edited) $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 December 19, 2011 by fox Quote Link to comment Share on other sites More sharing options...
Bryan Posted December 19, 2011 Share Posted December 19, 2011 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. 1 Quote Link to comment Share on other sites More sharing options...
JohnBuell Posted December 20, 2011 Share Posted December 20, 2011 (edited) 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 December 20, 2011 by JohnBuell Quote Link to comment Share on other sites More sharing options...
phaeron Posted December 20, 2011 Share Posted December 20, 2011 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 Quote Link to comment Share on other sites More sharing options...
fox Posted December 20, 2011 Share Posted December 20, 2011 You're right. I have a test for SHX and SHY: http://asap.git.sourceforge.net/git/gitweb.cgi?p=asap/asap;a=blob;f=test/cpu_shx.asx;h=4c19668c188003c70fe0cb0a49d70304f0dc17c2;hb=HEAD Regarding what you wrote in post #28, have you tried these instructions with WSYNC ? Quote Link to comment Share on other sites More sharing options...
ijor Posted December 28, 2011 Share Posted December 28, 2011 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. Quote Link to comment Share on other sites More sharing options...
phaeron Posted April 28, 2014 Share Posted April 28, 2014 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 12 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted April 28, 2014 Share Posted April 28, 2014 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. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted April 28, 2014 Author Share Posted April 28, 2014 LIKE Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted April 28, 2014 Author Share Posted April 28, 2014 KUDOS... this manual as standalone book would be killer ("the black magic of A800") 1 Quote Link to comment Share on other sites More sharing options...
Rybags Posted April 28, 2014 Share Posted April 28, 2014 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? Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted April 28, 2014 Share Posted April 28, 2014 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. Quote Link to comment Share on other sites More sharing options...
phaeron Posted April 29, 2014 Share Posted April 29, 2014 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. 2 Quote Link to comment Share on other sites More sharing options...
foft Posted April 29, 2014 Share Posted April 29, 2014 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. 1 Quote Link to comment Share on other sites More sharing options...
phaeron Posted July 5, 2015 Share Posted July 5, 2015 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 18 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted July 7, 2015 Share Posted July 7, 2015 Superb! Quote Link to comment Share on other sites More sharing options...
Guest Posted July 7, 2015 Share Posted July 7, 2015 brilliant stuff...great work Quote Link to comment Share on other sites More sharing options...
Creature XL Posted July 8, 2015 Share Posted July 8, 2015 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! 1 Quote Link to comment Share on other sites More sharing options...
bugbiter Posted July 16, 2015 Share Posted July 16, 2015 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" Quote Link to comment Share on other sites More sharing options...
+MrFish Posted July 16, 2015 Share Posted July 16, 2015 (edited) 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 July 17, 2015 by MrFish Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted July 17, 2015 Author Share Posted July 17, 2015 thanks! best Atari book ever! even better than De Re Atari.... 1 Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
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.