phaeron

Short IRG mode with a delay between SIOV calls should be enough -- it should already be writing continuous mark tone (1) after the end of each block.

In assembly source, you of course write code and data differently, but at execution time the distinction is based on how the bytes are used, not what they were intended for. Code can be handled as data and data can be executed as code. The most direct example of this is DOS: sectors are loaded off disk and into memory as data, and they become code when DOS jumps to the starting address to begin program execution. There's no explicit command or mark to indicate when code becomes data or vice versa, that just happens when it's used that way. In some cases, code is intentionally also used as data, such as 2600 games that reuse part of their program code as noise or flak graphics. This poses problems for disassemblers, which have to use heuristics to guess what is code or data. They have trouble with constructs like jump tables, where the bounds of the jump table are hard to determine statically. They're also often fooled by constructs like CLC+BCC to do an unconditional branch, as they can trace past into regions that aren't actually executed. On some CPU architectures, there is more of a distinction. Some older CPUs had tag bits to mark memory regions as code or data, and newer CPUs have read/write/permissions in the page tables. Some CPUs even had separate memory buses or address spaces for code and data. On the 8048, for instance, you can't even read code as data without external hardware support or using special MOVP instructions, and similarly it isn't normally possible to execute data because it's simply not mapped into code address space.

Like the others, I also thought that Atari800 used to emulate this but couldn't find any older builds that did so. I took a look at the Atari800 SIO and sound code and it looks like the existing SIO sound approach would need to be reworked. Fundamentally, the characteristic Atari SIO sound comes from the way that POKEY's serial port interacts with timer 3 and 4, particularly in asynchronous receive mode. This is a scope of when the Atari is transmitting a command frame over the SIO bus, specifically a type-3 poll. This is the farting you hear after DOS 2 boots or when no bootable devices are connected. CH1 (yellow/TX) is SIO DATA OUT, CH2 (cyan/RX) is SIO DATA IN, CH3 (purple) is audio out. During a send -- SKCTL=$23 -- timers 3+4 are continuously counting to provide the transmit clock for any bytes that are queued to send. It runs continuously regardless of whether a byte is actually being sent or not. Timers 3+4 are configured for a period of 1/38400th of a sec for 19200 baud and the OS configures channel 4 for square wave output ($A8), so the output tone is 19200Hz. This is inaudible, so the primary component heard is the change when timer 4 starts and stops, and not the tone output itself. This is also why the tone starts a little bit before and some time after the actual command frame bytes, since it depends not on the end of the last byte but when the SIO routine in the OS gets around to reconfiguring the serial port. Each command sent produces a single "putt" of sound. The farting noise comes from the OS SIO routine retrying the type 3 polling commands 27 times, with a timeout driven by OS timer 1. This is VBI-based with a timeout of 2 vblanks, so the puttering occurs at 30Hz for NTSC and 25Hz for PAL. During a receive, SKCTL is changed to $13 to enable asynchronous receive mode: This mode sounds a lot different than transmit because of the way asynchronous receive mode affects timers 3+4. In this mode, POKEY has to synchronize to the device's transmit clock, which is out of phase with POKEY's serial clock. Therefore, in this mode, POKEY holds timers 3+4 in reset while waiting for a start bit, and those timers don't run. At the leading edge of the start bit, timers 3+4 are started, and then count off half-bits in phase with the transmit clock so POKEY can sample in the middle of each bit. Upon sampling the stop bit, timers 3+4 are stopped again to wait for the leading edge of the next start bit. This process causes timers 3+4 to underflow and fire a pulse to the audio circuit 19 times -- which crucially is odd. This means that the output bit is toggled at the end of each byte, which you can see above in the gaps before and after the ACK byte ($41). The result is that the audio output has a fundamental square wave at half the byte rate of the transmission, with bursts of inaudible 19200Hz on top of it. The fundamental frequency varies based on the device, a bit higher or lower than the nominal 960Hz depending on the device. 810s, for instance, produce a slightly higher pitch than a 1050. Note that the byte rate is not the same as 10 times the bit rate, as devices often have a bit of a gap between the stop and start bits. It also means that the tone doesn't depend on the computer's clocks, which means that it is invariant to NTSC/PAL. What Atari800's SERIO_SOUND appears to be doing is rendering the 10 bits for each byte at channel 4 volume -- 1 start bit + 8 data bits + 1 stop bit. There is often a component of this in the audio output due to the SIO data leaking into the audio output, but it's faint and not subject to POKEY volumes. It's what you sometimes hear when a loader shuts off the main SIO sound and you hear still hear tinny buzzing during the sector loads that varies a bit in timbre depending on the data bytes being received. That's not the same as the stronger transmit/receive effects above, which are independent of the data bytes being sent and received. As far as I can tell, the sio.c/pokey.c/[mz]pokeysnd.c don't implement timers 3+4 being held for asynchronous receive mode, which is a main requirement for emulating this effect. Probably the simplest starting point would be to override the connection from timer 4 to audio channel 4 and drive audio channel 4 at 0Hz/960Hz when asynchronous receive mode is enabled, running it only when bytes are being received. It's an approximation but would go pretty far towards something representative. More importantly, it's compatible with cheaper asynchronous audio, so it's easier than the next steps of either properly starting and stopping timers 3+4 during async receive mode or driving audio channel 4 with machine synchronized timing. AFAICT Atari800 isn't set up for the latter anyway because it doesn't actually emulate device transmit timing -- it instead sends bytes at the rate that POKEY is set up to receive them, which is not accurate but works most of the time (though it allows some bogus configurations like receiving at the wrong baud rate). The majority of SIO devices send bytes back-to-back at a consistent pitch, though, so it's not necessary to emulate at that level to attain representative pitch. The nominal pitches for receiving from the 810 and 1050, based on the controller clocks and firmware loops, are 943.4Hz and 910.75Hz.

The option you have showing will prevent the CPU from executing such instructions, and break into the debugger when one is encountered. There isn't currently an option to disable illegal instructions in the disassembly.

As long as the joystick is exposed to the regular Windows APIs for a controller, sure. Altirra supports the DirectInput and XInput APIs. If it appears in the Game Controllers control panel in the OS, then it should work. The easiest way to set up a new controller is to either create a new input map in Input > Input Maps with the Preset button, or Edit an existing one. Then click Rebind, which will step through each input binding waiting for you to press the controller button to assign to it.

This doesn't emulate the PIA enough to avoid compatibility problems. In particular, it will fail with any software that does 800/OS-B style initialization, such as this startup loop from Star Raiders: A162: A9 00 LDA #$00 A164: AA TAX A165: 9D 00 D0 STA $D000,X A168: 9D 00 D4 STA $D400,X A16B: E0 0F CPX #$0F A16D: B0 03 BCS $A172 A16F: 9D 00 D2 STA $D200,X A172: 9D 00 D3 STA $D300,X A175: 9D 67 00 STA $0067,X A178: E8 INX A179: D0 EA BNE $A165 With the PORTB snooping scheme you describe, this would capture $00 writes and assume that the extended memory window should be turned on since it sees bit 4 cleared. But that's not what happens on the PIA, because the PIA doesn't have four registers, it has six registers, and two of them are the data direction registers DDRA and DDRB, stacked on top of the same $D300 and $D301 addresses as output registers ORA and ORB, selected by bit 2 of PACTL ($D302) or PBCTL ($D303). When this code runs, the PIA hasn't been initialized yet -- Star Raiders is a diagnostic cart -- and so all of its registers are set to $00 from hardware reset. This causes $D301 to write to DDRB instead of ORB and change port B to input (a no-op) instead of changing port B outputs. To properly emulate PIA port B, it's necessary to shadow writes to both ORB and DDRB at PORTB ($D301), and bit 2 of PBCTL ($D303) to select between ORB and DDRB. Then, actual banking state can be computed as (ORB or not DDRB).

Think you had a typo due to the diagonal lines, but no matter... the alternating blue lines are confirmation of what's going on: That's PF2 from the $FF bytes on the odd lines where the line is being replayed from the line buffer. So good data is definitely coming through on the badlines, and then the data goes missing on the subsequent scan lines.

You could try this as well, this program draws a series of vertical stripes in GRAPHICS 7 (160x96 4-color) and changes the screen to wide hscrolled, slowly incrementing the hscroll value. In theory, we should see corruption in the bottom half of each line on the broken cell since the line buffer is also used in bitmap modes. It'll glitch momentarily every time the scroll increments, that's normal since BASIC is too slow to synchronize properly. 10 GRAPHICS 7 20 FOR X=0 TO 79 30 COLOR X 40 PLOT X,0:DRAWTO X,79 50 PLOT X+80,0:DRAWTO X+80,79 60 NEXT X 70 DL=PEEK(560)+256*PEEK(561) 80 POKE DL+3,93 90 FOR I=0 TO 78:POKE DL+I+6,29:NEXT I 100 POKE 559,35 110 FOR I=0 TO 15 120 POKE 54276,I 130 FOR X=0 TO 500:NEXT X 140 NEXT I 150 GOTO 110 I looked over the ANTIC re-schematic again, and it does look like the ram cells are read on alternate cycles from the precharge+write... so my armchair IC engineer guess is that with the blown cell the data is being held on the internal RAM bus by capacitance from the write cycle, and then on the subsequent lines there is no write so the precharge sets the internal RAM bus to $FF.

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.