Jump to content

phaeron

+AtariAge Subscriber
  • Content Count

    2,844
  • Joined

  • Last visited

  • Days Won

    15

phaeron last won the day on March 10

phaeron had the most liked content!

Community Reputation

4,679 Excellent

1 Follower

About phaeron

  • Rank
    River Patroller

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.

  1. I'm glad you find it useful, but please don't @ me multiple times in quick succession, especially for the same thing in two different threads. You already tagged me for this in the Disable 800XL Screen Saver thread. Not resetting the attract counter and the Ctrl+V crash in enhanced text mode are fixed for the next test build, but current tree isn't in publishable state right now. Altirra doesn't have a setting to disable attract mode because there isn't a safe way to do it -- forcing location 77 is only safe as long as the OS is still active, as soon as the program takes over the VBI this can crash the emulated program. The option for this in Atari800WinPLus works similarly to the cheat that was suggested in the other thread with the exception of an additional clock check, but that doesn't remove the possibility of a crash, it just makes it less likely. That's not ideal for such a function that you'd want to keep on all of the time. The enhanced text mode is a terminal instead of a screen editor, so there isn't a mode that allows moving up to and editing previous lines as with the E: device. This is one of the main reasons I haven't implemented support for LiteDOS disks. Not only is there potential for conflict between the DOS 2 / MyDOS formats, LiteDOS relies on other DOSes doing lax checking of the VTOC for read-only interoperability at the cost of allowing write corruption. I can't implement support for it until the format is stable and I've confirmed that it won't interfere with existing DOS disks. Guess I did fix the symbol case handling at one point. Of course, this also means that the current symbol lookup algorithm is abhorrent and needs to be fixed.... Option to disable the default symbols? Think that should be OK. I can't reproduce the Performance Analyzer crash. It's strange, because the Profile button just opens the profile pane in the analyzer, and that won't do anything if you haven't recorded a trace yet.
  2. TIL that not allowing a floppy disk with 0 tracks, 0 sectors, more than two sides, larger than 32MB, or a sector size other than 128/256/512/8192 bytes is being "picky." By the way, LiteINIT is also unilaterally setting the PERCOM block without reading it from the drive first, so it is enforcing a seek rate of 1 for drives that use that field, regardless of the drive's normal seek rate.
  3. This wasn't actually the algorithm I was referring to, but I wasn't aware that this is how Turbo-Basic XL's hash actually worked. In Altirra Extended BASIC, the line cache is simply a direct-mapped cache based on the low 7 bits of the target line number, with each entry pointing to a valid line. A line lookup uses the low 7 bits to index a cache entry and checks whether the line number is a match. If it is, then the pointer is used and the line lookup terminates quickly. Otherwise, a line search is performed from either the start or the current line, and the match replaces the existing entry in the cache. The tradeoffs are different -- this method avoids needing to pre-populate the table with starts for each line group and has faster performance for densely packed lines. On the other hand, it is slower if there is aliasing on the lookup. TBXL slows down if there are a lot of lines with branches between lines 0 and 255, whereas ATXBasic slows down if you have common branch targets separated by 128*N. Even if common branch targets do alias, it'll still help if the aliasing targets aren't used at the same time -- if the program does a bunch of GOTO 1 and then GOTO 129, there will just be a second cache miss to flip the cache entry from line 1 to line 129 and then the second set of GOTOs will be optimized. In practice, the direct mapped cache is effective. Profiles on some BASIC programs show hit rates above 99.9%, the code required to implement it is small, and it works on some common tricks like GOTO STICK(0). I could probably implement it in Altirra BASIC were it not for compatibility issues from the memory for the hashtable, since for that version I don't relocate the evaluation stacks.
  4. Execute debugger command ".unloadsym kerneldb" to unload standard Atari OS symbols. Not currently, the internal symbol storage is not case preserving. It's on my list of things to change. However, you should also check whether you are actually generating case-sensitive symbols as well. MADS requires the -c switch to emit symbols in their original case and with that enabled you must use the correct case throughout your source as well.
  5. Sorry, no interest in porting to the new Atari VCS. It's a plain, modern Linux x64 PC in an ugly box, and it'd be flying a bit too close to the star destroyer.
  6. SIO Command must go low prior to the start of the command frame and then high after the end of last byte of the command frame, when the computer is ready to receive the ACK. If it goes high before the end of the last byte, some devices will reject the command frame (particularly the XF551). Serial framing errors occur when the UART/USART sees a valid start bit and begins shifting in a byte, but the stop bit is invalid. This refers to the framing on each byte and not the SIO command/data frame. Framing errors can happen due to transmission errors, baud rate mismatches, and reception beginning in the middle of a byte being sent. What adds to the confusion is that any timing or transmission errors that derail the SIO command protocol can get either the computer or the device desynced, typically the device getting left hanging and then interpreting the start of the next command as part of the last. This causes the device to try to receive and transmit at the wrong times, leading to some error ping-pong between the computer and the device. The OS will retry commands up to 13 times, which is usually enough to get everything back on track, but in the meantime the overlapped commands will give all sorts of serial errors that can be confusing for diagnosis. For a PC-based device like RespeQt, the most likely culprit would be a timing issue, since USB serial ports generally suck at that. But for an embedded device like an SDrive, I'd be more inclined to suspect transmission errors.
  7. There are two possibilities: You need more beer. You need to turn off Caps Lock in the emulation before pasting, since the emulator is just typing keys on the keyboard and the emulated OS is the one that is converting to uppercase.
  8. Yeah, it's just the old generic obligatory you-can-cause-damage-to-your-system-with-improper-use-of-the-registry-editor warning, just like the California Prop 65 cancer and EU cookie warnings. There's no problem going in and editing or deleting Altirra's settings in the Registry if you're comfortable with the Registry Editor. But for those who are not, the options in the recent versions of the program itself for deleting and migrating the Registry settings are the better and easier choice.
  9. Check the firmware settings, this looks suspiciously like Altirra can't find the OS ROM file you have selected.
  10. The base Atari OS mathpack FMUL works by repeated addition while counting down multiplier digits. It takes ~9750 cycles on average for RND(0)*RND(0) and ~16600 cycles for worst case of all nines in the multiplier, not counting DMA cycles. In the current version of Altirra Extended BASIC, I use a decimal mode version of the classic square-table algorithm that can multiply two standard Atari FP numbers with rounding using 1K of tables. Average is ~2010 cycles, worst case ~2030 cycles. Turbo-Basic XL uses an algorithm that precalculates the multiplicand by all BCD bits and then adds all partial factors for each bit set. Average is ~2180 cycles, worst case ~3120. The final result is not rounded but adding that wouldn't cost much. TBXL's algorithm uses no table space but requires some code space and particularly some temporary space for the premultiplied factors. In the AltirraOS math pack, I convert the multiplier digit pairs from BCD to binary (0-99), then run a transposed loop that processes the same binary bit position across all multiplier bytes before doubling the multiplicand for the next bit position. Result is rounded. Average time is ~2580 unhalted cycles, worst case around 3560. The advantage of this algorithm is that it requires no large tables or unrolled code and not much temporary space, so it can fit within both the ROM and page zero memory constraints of the math pack.
  11. No offense taken, I'm just curious as to what's going on here. I appreciate that you understand the implications of running under Wine, actually. Crashing on D3D11 is not great, that means things are definitely goofy since Wine has supported D3D11 for some time and Altirra's D3D11 support has not changed recently. If you end up in this situation again, run the program with the /d3d9 command line switch to force the display settings back to default to get back in. You could also try disabling the Vertical Sync option under View, in case something is funky there. That having been said, I would have expected something to show up with all display APIs off, in which case Altirra uses GDI -- the bottom of the barrel of graphics APIs in Windows that sucks terribly but should work in all cases. Otherwise, bit of a head scratcher here, I'll just have to run some sanity checks here to make sure everything's at least sane on Windows. The 64-bit version of Altirra wouldn't suffice?
  12. It's true that running on Mac or Linux through Wine is not supported, but I do watch the reports as sometimes the bugs really are in the core and just manifest differently in the Wine environment. In this case, the issue may be related to the display path. Wine doesn't quite emulate everything in DirectX, and if something is going fubar in the display path it could explain what we're seeing here. The reason is that if Altirra thinks it is running faster than real time, it will drop audio frames in tandem with video frames to try to keep playing audio roughly in sync even in turbo mode. Therefore, if something goes wrong and it drops all video frames, it will also go audio silent. This would also mesh with the behavior you're seeing in the debugger which implies that the emulation itself is ticking normally. I need to check 3.90 with Dr.Memory to see if a memory access or GDI handle issue has crept in, but otherwise, something else you could try is changing to a different graphics API in Tools > Options > Display. Direct3D 9 or Direct3D 11 is usually optimal on Windows, but the other modes can be useful to diagnose on Wine.
  13. That's some really great work, but I should fix that rounding issue first in case it influences the results. That particular case doesn't look too bad, as it's in the addition renormalization code and I should be able to re-round the result with a slightly altered rounding constant. It'll be off by a tiny amount, but the ATXBasic math pack doesn't do all out round-to-nearest-even-with-sticky-bits kind of full rounding anyway.
  14. Not sure exactly what you mean by LHS, but a simple hash table on 7 bits of the line number with no collision chaining works fine in practice. It only needs to cache branch targets and not all executed lines, so collisions are rare. It also fits nicely in the 256 byte area normally occupied by the argument and operator stacks in Atari BASIC. It does, but BASIC programs also tend minimize line number searches because of how expensive they are in the stock Atari BASIC interpreter. Caching the line pointer for FOR..NEXT loops also significantly reduces the line search load.
  15. Pretty low, ANTIC is probably the best behaved and best known of the custom chips. So far all of the stupid ANTIC tricks I've found have been pretty useless for actual production use, besides further chip exploration or breaking emulators. POKEY is the least well known and the chip that has seen the most new interesting tricks, followed by GTIA. Probably the most useful ANTIC discovery has been the scanline 247 hires bug (credit Rybags for originally bringing to my attention), which lets you use DMACTL to modify the video signal in vertical blank. The best result of this is opening the vertical border for extended P/M graphics in PAL, though it's too far in overscan for NTSC. Otherwise, interlace experiments have been mixed as you can't actually modify the horizontal timing to do proper interlace, and TVs vary in response to fake interlace. Maybe someone will come up with some interesting hack like closed captioning. With regard to shifting P/M DMA, there's no direct way to do it as the chip is hardwired to route the vertical counter to the lower address bits. Thus, sneakier ways are required: Using HSCROL or mode 9/10 to force abnormal playfield DMA to overlap the P/M DMA slots. This is of limited use because it burns a lot of cycles to set up and for the abnormal DMA, and the address is the AND of the playfield and the P/M DMA addresses. Forcing abnormal playfield DMA in lieu of the P/M DMA slots, by also turning on P/M DMA only in GTIA. This allows DMAing into missiles and two players using playfield DMA, but still takes a bunch of cycles and trashes the other two players. Fooling GTIA into false P/M DMA slots triggered by the display list fetch instead of ANTIC fetching missile DMA, and loading player 3 off the LMS high byte. Arguably useless, you can't have a playfield. Fooling GTIA into false P/M DMA slots triggered by the display list fetch, then loading missiles and/or players off of _CPU_ cycles. Might be useful in limited circumstances where a kernel is already in use, since objects can be loaded for free or almost for free as a side effect of CPU read/write cycles. Fooling GTIA into false P/M DMA slots triggered by a display list LMS fetch without an IR fetch. Haven't checked whether GTIA allows P/M fetch to start this late, and LMS-only fetch is also difficult as it requires either toggling display list DMA at the right time or using vertical scrolling to stretch a jump instruction.
×
×
  • Create New...