Jump to content

phaeron

Members
  • Posts

    4,119
  • Joined

  • Days Won

    24

phaeron last won the day on December 30 2023

phaeron had the most liked content!

8 Followers

Contact / Social Media

Profile Information

  • Gender
    Male
  • Location
    Bay Area, CA, USA

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

phaeron's Achievements

River Patroller

River Patroller (8/9)

8.5k

Reputation

  1. 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.
  2. You do have to write to CONSOL to select the controller and allow enough time for the controller to poll, but the #1 mistake is writing %11 to the low bits of SKCTL. That's how you configure the keyboard for the computer, but the 5200 requires debounce to be off (%10).
  3. You'll have difficulty converting .PRO images to .ATX as the PRO format doesn't represent a physical disk layout, it stores sector patterns reported by the drive instead, like flip/flop sectors. It's not generally possible for an offline converter to derive a sector pattern from this because it would need to see the access timing from the game's loader to map the pattern to sector positions. Note that Altirra also doesn't support all of the different PRO pattern modes currently, so some PRO disks simply may not work with it.
  4. Would have been nice if the 8-bits had gotten an 80-column video mode. Problem is, most of the good ways of doing this would have required an AGA-like respin of ANTIC and GTIA to produce an Alice+Lisa like upgrade, since there isn't enough memory bandwidth to double the existing IR mode 2, and GTIA gets all playfield data through ANTIC. That includes doubling the memory bus speed to 3.58MHz, interleaving memory banks to produce a 16-bit video bus, double CAS, or taking the character generator off the main bus. Probably the smallest change would be to add a 640x192 graphics mode and software render text to it, requiring only the ANx bus to be upgraded, but it would have taken 16K RAM and would have been very slow due to the DMA overhead. That leaves the C128-style hack approach of gluing a separate 80-column display output on the side, integrating poorly with the rest of the machine. Best approach would have been to build it into the machine, but the 1090 never made it and it wasn't in the 1400XL plans. The XEP80 shipped but was hobbled by using the awkward and slow joystick port interface instead of SIO, not to mention the marginal video timing.
  5. The 1400XL's modem is indeed similar to a 1030 -- it does implement a T: handler, but with some ESC commands different. It's baked into an internal PBI device instead of a downloadable driver + SIO interface and there's no built-in ModemLink. Tone dialing is also not supported by the T: handler and requires external code due to ROM space limitations. But uniquely, the 1400XL modem hardware supports both audio pass-through and tone dialing, for which the external modems only supported one or the other. Both the documentation for the 1400XL's T: handler and the 1400 Communicator cartridge are available from mirrors of the AHS: http://atarimuseum.ctrl-alt-rees.com/computers/8bits/xl/1400xl/1400.html
  6. Interesting... it almost looks like the circuit was designed to be able to support 16K windows as well as 8K windows, with other unused 74LS139 half being wired up to /S4.
  7. I use a VoIP adapter for this: https://www.amazon.com/gp/product/B01JH7MYKA/ref=ewc_pr_img_1?smid=A2YMFIQYPSZOVO&psc=1 It's intended to bridge between POTS and VoIP, but it has two phone ports and allows inter-port dialing between them without a VoIP server. It emulates a dial tone / ringing and supports both pulse and tone dialing, so you can actually do a standard dial/answer instead of having to preconnect the lines. Have gotten a 1030 modem to dial and connect to an old laptop through it. The main downside is that the connection timing is marginal and even at low baud rates you can get data errors, as these aren't really meant for modem operation. But as long as you're not actually trying to do a data transfer, it's more than enough to test and exercise an old Atari modem.
  8. Definitely can, though it would make any use of extended memory from the main thread rather interesting. Even if there's only one bank and you're just independently toggling the CPU and ANTIC bits with separate ANTIC access, you'd have to create interrupt-safe ways of doing the read-modify-write of PORTB from the main thread.
  9. You are correct, player/missile graphics can only be positioned at 160-pixel resolution. They can't be positioned at hires pixel granularity. The reason for this is that only the playfield can display hires (ANTIC modes 2, 3, and F) and it does so through a special path. Everything else in GTIA, including player/missile graphics, collision detection, and priority runs on lores pixels. This is also what causes all of the strange behavior with hires modes, including interactions with P/M graphics and the color restrictions.
  10. If you are making a new cartridge type, then it is a good idea to fully decode all the address lines. But here we're talking about reimplementing an existing cartridge type, and for that you would want to match the original cartridge's behavior as closely as possible. Otherwise, any difference in behavior is an opportunity for software from the original cartridges to not work on the new cartridge implementation. The thing to realize about old cartridges is that most of them had their banking logic implemented in a very small number of common 74LS chips -- generally 1-2 at most. There's not a lot of gates available for complex logic, and so incomplete decoding was very common. For the Williams cartridge type, schematics or pictures for the original PCB aren't available, but it's likely that the implemented consisted of at most a latch/flip-flop chip and maybe one additional chip with misc gates. Two chip select lines on the ROM means that the latched disable signal can be combined with /S5 for free, and then all that's needed is a bit of logic to clock the latch from accesses to /CCTL and drive RD5. ANDing together A4-A7 would have added additional complexity to the PCB for no real benefit, and possibly real cost if it required another chip. Generally that extra decoding complexity has only been seen in cartridges that were intended to stack with another cartridge, such as the ones designed to work in the pass-through slot of a SpartaDOS X cartridge and need to co-exist with the /CCTL range decoded by SDX. The generally available description for the Williams cartridge types is somewhat underspecified, so Altirra implements it as follows: A4-A7 is ignored for /CCTL accesses. R/W is ignored, and any /CCTL access triggers a bank switch change. This means that a read can trigger a bank switch, including from ANTIC. This is similar to behavior seen on real XEGS and AtariMax cartridges.
  11. 4.30-test4 is old and predates the fix, latest is 4.30-test7:
  12. If you are using Altirra 4.20, there is a regression in that version that causes this lockup; it's a bug in that version of the emulator that interacts with another bug in the game (Star Raiders 5200 accesses a nonexistent PIA chip). I'm going to be releasing a 4.21 release to address this and a few other bugs, but in the meantime the latest 4.30-test release also has the fix. You can find the test releases either further up in this thread, or by using the Help > Check For Updates menu option with the update channel changed from Release to Test (which will just link back to the latest relevant post in this thread).
  13. The asterisk (*) button is used to toggle between speed and non-speed controls. The default keyboard mapping in Altirra maps this to the - key, next to 0. You'll probably want to come up with a more ergonomic mapping for the game, probably using the keypad (if you have one!). You can detach the cartridge and use the controller test that appears to verify the mapping to the original 5200 controllers. Altirra doesn't emulate the 7800, it's a completely different architecture. The 7800 is a 2600 duct-taped to a Jaguar predecessor.
  14. Ah, in the Altirra BASIC manual? Yeah, that's wrong, I'll fix it.
  15. I would recommend replacing the VSEROR/VSEROC handlers instead of trying to reuse the OS ones with XMTDON. The stock handlers are meant to be used for transferring SIO data frames and will try to send bytes on their own; the VSEROC handler also may not do anything if the checksum sent flag hasn't been set. Some of the garbage characters you're seeing may be the result of the VSEROR handler racing against your code for writing to SEROUT.
×
×
  • Create New...