Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Rybags

  1. Also I believe Altirra won't pass through any key that's assigned to a joystick or other controller function so check that as well. Easiest to just disable any controller mappings.
  2. A stick setup like that would suck I do suspect. And those switches in use for stick and kb - I'd not expect them to last a real long time either. If the thing has Bluetooth and you can bring along your own, then it'd be great. But you can pretty well do the same thing these days with a phone and have a much better display into the bargain. As great as all this stuff is, I was emulating a PS1 with the shitty phone I had in 2012 so it's sort of old news now.
  3. Check your emulator settings - usually you'll probably have the cursor keys set to act like cursor keys (as if pressing CTRL on the Atari). But Mac-65's DDT does scrolling through the disassembly by just using the keys without CTRL. Handy on a real Atari but in emulation you'd have to hold CTRL as well - or just set the keyboard option to use the cursor keys as if CTRL isn't held.
  4. Have to say it's looking impressive. I like how the Broderbund intro is a little like the Spelunker one - which until now would probably have been their flagship Atari 8-bit product.
  5. Rybags


    My preference would be for 2 extra fire buttons using the POT inputs. Sure, next to nothing supports it but there's potential that it could become a standard, and motivate new developers to use it and of course old games could be modified to take advantage of it.
  6. Rybags


    Button on top of the stick - that's probably the number one turnoff for me. A mate had one of those Wico ones with the flight type stick and button only on the top, nobody wanted to use it. I've got the 3 swappable handles one with button on top and base - the top button has been used maybe 100 times in 37 years.
  7. I get the feeling that at 100 MHz it could just be autonmously clocked and just listen the the host clock and know when to participate in bus activities. The sync skew you'd get is like 2% which equates to probably less than the propogation delay you'd have talking to other addressable stuff on the board anyway. For onboard Antic - you'd then need a bunch of other signals like the ANx bus, input for light pen etc etc. But if going onboard Antic then may as well do GTIA as well which would reduce the pin count back a bit. Then you're into the realm of "well, just add Pokey and the rest of the legacy system becomes excess baggage" and you may as well do a modern day recreation.
  8. The first and most obvious thing to me is the fact you could do rendering at 50+ times the speed. Such that a 3D engine approaching Quake could just about happen. Not to mention doing dozens of softsprites. Though of course you have that need to make the graphics data available to Antic which is potentially the biggest overhead. Though given this is an addon that's adding non-downward compatible abilities, no reason not to add some extra CPU abilities such as as blitter to shift graphics from the internal to shared Ram.
  9. You could use it to hit the hardware directly (almost every cycle) a bit like the 2600 accelerators. It would overcome a lot of limitations but not be a miracle worker. To reuse a PM object you need to reposition it then optionaly do the graphics and colour. You could change colour registers but 4 palette entries still = 4 cycles. And you still have the limitation when hitting the hardware of the 1.79 MHz external speed. Then you also have to contend with graphics DMA and refresh steals.
  10. For machine language games the extra speed won't make any difference in a lot of cases. Most are VBlank driven and most will do a limited amount of object processing so speed won't matter a lot. Games that will be affected are ones that do rendering which usually takes over a frame, e.g. Mercenary, Rescue on Fractalus. In some cases DLI processing might have glitches. For games that don't work properly, fixing them would usually be fairly easy.
  11. It's got a dedicated page on AtariAge which is the only useful info I've found about it https://atariage.com/software_page.php?SystemID=5200&SoftwareLabelID=2391 And an entire thread, but a lot of the pictures no longer exist https://atariage.com/forums/topic/30390-atari-5200-klax-screenshots-and-game-details/
  12. Yeah - I think the issue is I've got VBXE enabled which seems to make it ignore any palette setting.
  13. That'd be helpful - so possibly a quick and dirty way to get it working, and have a patched OS that sets the write-through / IO space to the bottom of the display list each time the screen is opened. For bootable games, maybe a mode where most of Ram is write-through.
  14. Nice - but suffers from the dreaded colour errors on NTSC. For some reason my Altirra setup is running PAL but using an NTSC palette.
  15. That's probably part of the IO fencing. It's easy on other systems because they generally have a fixed area for video Ram. Even C64 which like us has a complex video system will generally have all it's video related stuff in a 16K bank. We can put video related data anywhere including Rom or seperate banked Ram so the whole thing is a lot more complicated. But no reason why the project couldn't be customised for Atari - the pinout, and build in some extra logic to detect when an extended Ram access is taking place.
  16. No - 65C02 is the CMOS 6502 that has extra instructions like LDZ, BRA and has a few different behaviours to other 6502s. 6502C is the code used for Sally as used in late 400/800 onwards, 5200 and 7800.
  17. Cool - but some hurdles for us. First up it's not pin compatible except for non-Sally 400/800 systems. Next up - it looks like the IO area fencing is simple and possibly hardcoded so not really suitable for use with Antic/GTIA. I don't think it responds to DMA requests by the look of it. What we'd need is to be able to have certain Ram write operations go to normal system memory so Antic can get to them. Or maybe just have all writes go to the legacy hardware (which would occur at the slower speed and slow everything down somewhat)
  18. It's no longer needed - GTIA I believe uses internal delay taps to generate the phase shift of for the colour which is an imprecise method and why the trimmer was included. Sophia - for the modern monitor digital and RGB analog standards it's irrelevant. For the legacy video I would assume there's probably some sort of internal PLL or precise method to generate the required timing so making the trimmer superfluous.
  19. Not yet at least - I've had the desire for a while to port Atari Basic over to that system. It would likely need a 32K cart and part of the computer OS ported and relocated so not a trivial thing. Then you could for what it's worth run some programs that have 16K Ram as their target system.
  20. $580-$5FF is generally used as the input buffer for Basic (usually E: input) and can actually overflow into page 6. But the usage is temporary and you'd generally not have E: input going on during a load/compress operation.
  21. Bounty Bob Strikes Back was on tape and pretty huge though maybe not the longest. Likely that it and the others mentioned have images that could be compared. Though potentially a multipart tape can add an extra 5-10 seconds for each section though some games were mastered with short leader on the extra sections.
  22. Yeah. Naturally why they went 78 in the early days, likely the manufacturing tolerances meant they needed the higher rpm to get the required fidelity. An EP on 12" 45 will just about always sound better than the 7" version and you tend to find those 20 song variety albums sound a bit crap compared to a 8 song original artist album.
  23. It's 8 bytes - so just a .CAS header. All I can ask is - why?
  24. Might not work either, likely the unused portion is just zeroed out. But worth a try.
  • Create New...