Rybags

I'd lift & reseat the PIA. If that makes no difference then I'd suspect most likely a damaged PIA or severed trace.

I'm fairly sure setting RAMTOP to the 52K base can be dangerous as the early OSes have a bug where sometimes memory above that can get overwritten. Not normally a problem since with 40 or 48K there's usually empty space or ROM at the location but at 52K is the hardware registers.

My initial post wrong - the Atari OS does in fact have BRK as the last checked for IRQ type. If the status copy on the stack doesn't indicate an instructional push, then it just returns from the IRQ handler (something that should never happen on stock hardware)

The only difference with 80-col mode is the horizontal resolution is 640 rather than 320. It'd be interesting to see how it looks with bitmap 640 mode though I suspect it'd be the same. It might be some behaviour from the scan doubler. Do you have specifications for it? It might be that the peak to peak voltage is out of range or something and VBXE is exceeding it. I have a couple of video converters, one of which takes the RGB and converts to S-Video (it was created with the Amiga as the target machine). The p->p voltage the device expects is lower than what VBXE produces so before ever using it I rigged up a voltage divider circuit for each video component and it works fine. Though the question arises, why would yours behave as such only in the hires mode. I also have a scan doubler, GBS 8200 V4 (probably clone), the target audience there mainly being old arcade hardware. I can't recall it having problems though my main use for VBXE has been the lower res, higher colour situations.

Depends on usage case - at first it looks like not many locations are available but Basic uses a lot, so they're free if Basic not in use. But other language processors will generally use much of the top half of z-page. The floating point area is good for temporary use. If you know what you're doing the lower half (OS) has numerous locations you can temporarily use.

The trakball in native mode just outputs grey codes for the X/Y axes like an ST mouse. It's pretty unlikely the computer would have a problem - the bit pairs just come across the same as joystick input (though somewhat faster). It's up to software on the host to interpret the bit changes and determine direction/velocity. If the mechanism is experiencing jitter then you'll likely end up with what you're getting. I've not pulled down an Atari trakball so don't know what to look for - not sure if they're electromechanical or optomechanical - the optical types of mechs tended to be more reliable. You might try pulling it apart, take the ball out and operate the rollers direct by hand and see what results you get.

No, I think the point he's making is that you just flip the image horizontally and leave it there for cases where more colour changes occur on the left. For most types of pictures, you'd not notice the difference. If there's text content, it could probably be edited to flip it around beforehand.

On the other hand, left side has an advantage that the colour registers can be preloaded during HBlank. Also 6502 registers can be preloaded for the next required colour changes (though I'm not sure RC does preemptive optimisation such as that) But still - it's worth a shot. The creation process - where it runs isn't really relevant. There's consideration of the DMA going on otherwise the timing wouldn't work.

No. Looks OK though. Though the curious part would be the feel and durability of the buttons and stick - likely they use the carbon pads that just mush against the 2 adjacent contacts to close the switch. So generally no microswitch or bubble type switch to wear out but often need something else to provide springiness and feel.

The battleship pic Popmilo posted yesterday - Mode 5 but stretched vertically 2x. So, original aspect ratio would mean the same bigger pixels but the graphics with half the vertical detail. A quick and dirty job using Paint - problem is the filtering tends to generate more colours so it's not a good representation of what you'd actually get, plus the original I used had lots of JPEG noise.

I'd be interested in seeing ship detail in Mode 5 with original aspect - I do suspect it'd not fare as well as the enemy sprites.

I'd say they chose a 7 over 2 pin off-the-shelf connector to lessen the chance of people using incorrect PSUs. Of course that was a huge failure since the C64 one will work and kill the machine in the process.

I don't see memory as being the biggest hurdle for this game. If it needs 128K then it needs 128K. Most of the enemy flight congurations are pre orchestrated - some optimisations might be had there, like keep some on vertical character boundaries.

I'm just about sure I read here that some USB PSUs generate lots of noise. I guess it's totally feasible that some cheap ones with poor filtering could let AC noise through. The plug - only two wires are actually used so even if your soldering aint that great it's not an entirely hard job to make one up. I've been meaning to make one for some time. In fact, I've bought some of the cheap micro USB breakout boards on fleaBay - the plan there is to make an adaptor so I can just use a USB charger + normal USB cable same as charging a phone.

It wouldn't look that good if done as Mode 5 characters but scaled to the same aspect ratio - plenty of detail would be lost. I don't think the game would work well with V-scrolling as well... maybe if done using 240 scanlines and only a single Mode 2 line for the score which would mean most of the world vertically would be present. But... with Mode 5 vs 4. The bad news is you're only saving DMA from 50% of the badlines which equates to 12-15 lines in total. Since Antic doesn't buffer character set data, it gets fetched every scanline. So really, the only reason to use Mode 5 would be if the graphics retained their AR which would mean less softsprite detail to render.

Nicely done, really has the feel of Terra Cresta and similar type games.

PIA's only involvement with the SIO port is /Command, Motor Control and the /IRQ and /Proceed lines. Much of the rest goes to Pokey.

The Jaguar case was used for a piece of dental equipment after Atari disappeared. Molds cost a lot of money to create so using an existing design can be a good way to save $ Possibly this is a similar situation but it's hard to imagine anyone wanting an Apple II clone around 1996. It's hard to tell but the back portion looks smaller than the ST/FM one - remembering on the original ST the vented portion was small but later ones bigger to make room for the floppy drive.

Not really - fine scrolling just means an offset calculation is needed, not much extra overhead. Although greater DMA load = less rendering time. I'm fairly sure the enemy count is limited to 5. Though throw in mines and shots it means extra objects. Though be warned - Atari has already once been embarrased by this game. Poor ST conversion from in the day. Apparently there's been recent work on an STE version that more closely matches the original but I don't know if anything has been released.

If it's a Dos type disk and the bad sector is part of a needed file then you might need to use a disk editor to recreate the file# and next sector link which is embedded at the end of sector. Generally a bad sector won't return any data - the program you use to copy it might produce zeros or the contents of the previous sector depending on how it works.

I do believe if a key is mapped to a controller in Altirra then it doesn't get passed through to the host as a key also. So that's what to look into. (would be nice if like Atari800Win+ you had the tick box to pass thru such keys as my layout uses the cursor + left CTRL for the stick)

I would say likely a 555 timer would be the easiest way to do this. https://www.homemade-circuits.com/interesting-timer-circuits-using-ic-555-explored/ Generally the intervals can be altered by external components like resistors or pots. Alternatively use an autofire joystick as donor then modify it to change the pulse interval.

It wouldn't be a simple thing to do. Main differences - the OS is very different, 5200 just calls it a BIOS and it's 2K of which 1K is the character set. - aside from Antic the chipset addresses are different. No PIA on 5200, so controller input processing is very different on both types. - only 16K Ram on the 5200 - memory addresses used by BIOS/OS in Ram are different on both machines. - OS provided functions on the computer will often not exist for the 5200. If you're new to programming 6502 then these hurdles might be too great. Many games have been ported among the 2 systems so no need to reinvent the wheel.

That's a tape boot request sound. Either the Start key is stuck occasionally or some problem elsewhere such as GTIA or a grounded trace. If GTIA is socketed try lifting and reseating it. You should be able to cancel the tape boot by pressing Break twice quickly.

First up you'll need it as uppercase. Next up you'd want optimizations. Easiest is to do statement stacking, Atari Basic runs much better if there's less total line #s to have to scan for when the program branches. Also string handling is way different to other Basics - no MID$ so you'd need to convert that to our way of doing it. In Altirra I think you'd need to use the right-click with mouse pointer - CTRL-V would likely just get passed to the Atari.