phaeron

I don't think this is a memory bus issue, this looks like one of the memory cells in the ANTIC line buffer is busted and is reading $FF. The interesting part is that the badlines seem to be OK, which is why 1/8 lines are OK in Boulder Dash and 1/16 in Bruce Lee. I forget whether ANTIC re-reads the memory cell or forwards the character name through the memory cell on a badline.

Yes, the Generic mode supports XF551 high speed mode operation but is not limited to XF551 specs, as it supports additional disk formats and a couple of additional commands (e.g. format skewed).

I checked a few of the config settings in Firefox and the one that is triggering the blocked downloads is browser.safebrowsing.downloads.remote.block_dangerous_host. Google's Safe Browsing dashboard seems to indicate that the base invisioncic.com domain is flagged for unsafe downloads: https://transparencyreport.google.com/safe-browsing/search?url=invisioncic.com

No, I've just been working on some stuff that just isn't ready to release yet.

That looks like a GTIA timing problem. GTIA needs to combine two color clocks to form a 4-bit pixel, and it looks like as that machine warms up GTIA's timing goes bad and it's sampling the same 2-bit value twice. If you look closely you can also see that the color tile boundaries have shifted right by a color clock.

Yes, this is a bug. I checked with a capture device and that cycle is a solid $FF on the 800XL while it's floating bus data on the 130XE, same as for other undriven bus cycles. The ANTIC emulation needs to force $FF into the virtual DMA path when they overlap refresh cycles.

The extraneous pixels are from ANTIC reading data from the data bus for a playfield fetch without actually having properly requested a DMA fetch. On a bad line, one of the refresh cycles is pushed all the way to end, where it executes on the first cycle of horizontal blank where there are no other DMA requests. However, refresh cycles don't drive the data bus, so what you should be seeing fetched is open bus data -- $FF on systems that have data bus pullups and last cycle read on ones that don't.

I don't think the proposed W65C832 would have been effective either. It basically takes all of the weaknesses of the 65832 design and makes them worse. What WDC basically did was just graft on an additional hidden E16 mode bit similar to the E/E8 bit, and add yet another set of modes. This means all of the same pains of switching between 8- and 16-bit widths, but with 32-bit width added on top. For instance, when dealing with both 8 and 16-bit quantities in 65816 native mode code, there are two main choices: use REP/SEP to switch modes at a cost of 3 cycles, or stay in 16-bit mode and emulate 8-bit accesses (e.g. LDA + AND #$00FF). But with the proposed 65C832, the E8 bit selects between 8/16 or 8/32 mode, so to switch between 16-bit and 32-bit memory/math, it's at least 4 cycles (CLC/SEC + XCE), and switching from 8-bit to 32-bit takes 7 cycles (REP + SEC + XCE). Compare that to the 68000 series, where all three widths are just encoded in the instruction, and the 80386 which just occasionally needs a size override prefix (66h). On top of that, the 65C832 still only has an 8-bit data bus, so it's throttled like a 68008, except it's worse due to the lack of registers and memory access heavy design. LDA dp + CLC + ADC dp + STA dp to add two 32-bit variables takes 20 cycles while a 68008 can do ADD.L D4,D7 in 10 with a quarter of the bus cycle speed requirement. Finally, none of the original problems of the 65xx series are addressed. If you need to access a strided 16-byte AoS structure, it takes the same old TYA / CLC / ADC #$10 / TAY sequence to do it, except now it's 11 cycles and 8 bytes. On other architectures you just do a single LEA or ADD.

Double-checked on hardware with a scope, this will work for bitmap mode (IR modes E and F) but not for character modes (IR 2 and 4). The character data fetch is one cycle later than the bitmap fetch for the same position on screen, so while you can get bitmap data fetched just in time to cover to the start of horizontal blank, it's short by one color clock at best for character modes.

What do you mean? It shouldn't matter what type of storage the disk image is on.

It doesn't matter why Apple chose 2.8MHz, if it was slow at that speed and the fastest popular 65816-based system wasn't clocked that much higher at 3.58MHz (SNES with fast ROM). Part of the reason for this is that the 65816 requires faster memory than other contemporary 16-bit CPUs running at the same clock speed. The Amiga 500 ran a 7.14MHz 68000 on a memory bus with 280ns (3.58MHz) accesses and 150ns DRAM, with half the memory slots available for the chipset without slowing down the 68000. Effectively, a 7MHz 68000 doesn't need to access memory more often than the 1.79MHz 6502 since it only issues a read or write every 4 cycles. In the meantime, the BBC Micro needed 100ns DRAMs to run a 4MHz bus, which with video interleaving only ran the 6502 at 2MHz. I'm not sure that Apple could have released the IIgs at 8MHz at the start even if they wanted to, at least not without adding cache and making it more expensive. Incidentally, out of curiosity I looked up the state of PC clones around the same time. The IIgs released at basically the same time as the Deskpro 386.

A IIgs-style machine definitely would have extended the life of the platform, but IMO would still have been a dead end. Atari would have needed to evolve the platform for either productivity or game markets, both of which had problems. Game market needed a machine with tiled playfields and sprites that were efficient to program. Not the funky display list + object line buffer stuff of the 7800. The NES could do higher resolution and more animated graphics with less RAM, and without needing a blitter or faster CPU. The next generation of consoles were adding more colors, more sprites, and more layers that were even harder to replicate compositing layers into a framebuffer. Productivity needed better displays, better storage, more memory, but most importantly a better CPU. The 6502 was getting outdated and the 65816 was a dead end -- clunkier to program than both the 8088 and the 68000 and no viable route to 32-bit. The popular 65816 based machines ran at 2.8-3.5MHz; it was cool how far Apple stretched the platform with the IIgs and GS/OS, but I remember it being pretty slow. And eventually, even ~7MHz with cache was not going to cut it against the 68020 and 80386.

The standard GRAPHICS 0 screen is 192 scans tall over the range 32-223. Jumpman's screen is 32-225 where 32 is just at the top of the playfield and 225 is just at the bottom of the status bar. The colored bar you see below the status bar is after the end of the display list at 226+. The playfield starts with one blank row (2 scanlines) before the ladders start. I would adjust vertical centering on the OS standard GR.0 screen as that's known to be centered while the Jumpman display list is slightly lopsided. As the character in Jumpman is drawn using player graphics, it can potentially draw outside of the playfield all the way to the full 240 line range, depending on the game's P/M graphics routines. The game allows the character to go pretty high, as jumping off the top of the ladder gets the top the character to line 12 or so, close to the limit of line 8. Many Atari emulators historically had their display settings calibrated exclusively for PAL, including the color palette and vertical displayed area. ANTIC's display timing runs 240 non-blanking lines, which is almost the max displayable height for NTSC. The PAL ANTIC simply extends the vertical blanking region while keeping the same active region, displaying blank bars above and below. For this reason, many emulators simply show the full 240 lines as they are fully visible in PAL. In Altirra, I made the the Normal overscan mode show 224 lines (16-239) for NTSC unless the vertical override is enabled, while PAL shows 240. The 2600 folks have done some extensive real-world testing of actual displays:

The bullet is drawn in the playfield, so it can't go into the border. Jumpman's screen starts at the regular top position as the OS screen (32) and extends two scanlines lower at the bottom (226). I was a bit curious about the broadcast side of this, so I did a little digging -- apparently for the era, the broadcast recommendation was to use the middle 80% of the screen as the title safe area and 90% for action safe. I can't find a public copy of the original SMPTE recommendation, but a rough translation gives ~192 scanlines non-interlaced height. By the time standards were updated for growth of LCD displays and better CRT technology, the title safe area recommendation had risen to 90% and action safe to 93%. Thus, it does seem that over time TVs got better at displaying a more stable and taller picture view.

I don't think this is an early ROM, it actually looks to be a post revision E ROM if it's official. It has the extra commands from rev. E and almost all of the code is the same, except that several wait loops were changed to check for RIOT timer timeout: Rev. E read sector DRQ wait loop, which is similar to rev. B/C's: L0C19 bvs L0C2A ;exit if FDC error lda $039C ;reset RIOT timer IRQ L0C1E bit $0380 ;read DRQ/IRQ status bpl L0C19 ;keep looping if no DRQ This ROM's read sector DRQ wait loop: 0C2E: 70 19 L0C2E BVS L0C49 ;exit if FDC error 0C30: 2C 95 03 BIT $0395 ;<!> read interrupt flag 0C33: 10 08 BPL L0C3D ;<!> skip if timer not expired 0C35: 2C 80 03 BIT $0380 ;<!> read DRQ/IRQ status 0C38: 30 08 BMI L0C42 ;<!> exit if DRQ 0C3A: AD 9C 03 LDA $039C ;<!> reset RIOT timer IRQ 0C3D: 2C 80 03 L0C3D BIT $0380 ;<!> read DRQ/IRQ status 0C40: 10 EC BPL L0C2E ;<!> keep looping if no DRQ It's not quite clear why this change was made, since all of the places that were modified are places where the FDC would also time out. The 810 firmware relies on a poorly documented quirk of the RIOT where after the timer expires and underflows, it switches to 1T mode and keeps going, firing again every 256 cycles. The firmware loops intentionally clear the IRQ flag constantly so that the FDC starts seeing a quick succession of fake index pulses which then causes it to time out Record Not Found. The changes made in this ROM cause it to check the IRQ first before clearing it, which I suppose is a little more reliable, but I'm not sure why it'd be worth the slower response to the DRQ. Besides this, the other reason I think this ROM is post rev. E is that it also has microoptimizations in a bunch of places to free up space for the above patches -- mainly changing JMPs to Bccs. The "DAVE STAUGAS" string was also sacrified to free up space.