_The Doctor__ Posted June 10, 2020 Share Posted June 10, 2020 This started to sound a little bit like the ROM/RAM simulators on S-100 development platforms that were used to develop cartridges for 2600/800 and other machines... they made changes on the fly, behind the back of whatever was executing so to speak... you made the change and it appeared on the target in short order. Quote Link to comment Share on other sites More sharing options...
rensoup Posted June 10, 2020 Share Posted June 10, 2020 15 hours ago, phaeron said: Yup. Given that the emulator is a separate process, there are only two choices: re-launch the emulator with a new image, or use an IPC mechanism to talk to it. The first one is simple but involves relatively long delays, the second is more complex. It is possible to do what you're looking for with a custom device, but you have to think in device terms as if it were a real Atari: have the custom device map an 8K boot/monitor ROM at $A000-BFFF and its own RAM at $0000-9FFF. The monitor ROM handles refreshing the hardware registers every VBLANK, and then the network connection can be used to write arbitrary data into device RAM, which is effectively main RAM. But in order to do this, you need to set up a TCP/IP server that talks the custom device binary protocol. It's not too complicated, just a simple packet exchange, but I don't have a C# implementation of it. I think I might go with a simple relaunching since I don't really know what functionality and if it actually is of any use... I need something more accurate than just vblank refresh (but I guess it's still possible with a custom device), I'd like to change colors and/or reposition PMGs per scanline... it's kind of hazy. Quote Link to comment Share on other sites More sharing options...
rensoup Posted June 10, 2020 Share Posted June 10, 2020 16 hours ago, Stephen said: Neat idea - please let us know if you get a working solution. Sure (perhaps I'll try to avoid mentioning anything WIP though ?) 1 Quote Link to comment Share on other sites More sharing options...
+Stephen Posted June 10, 2020 Share Posted June 10, 2020 7 minutes ago, rensoup said: Sure (perhaps I'll try to avoid mentioning anything WIP though ?) HA - I'm sure you'll get TONS of suggestions on what you're doing wrong 1 Quote Link to comment Share on other sites More sharing options...
rensoup Posted June 11, 2020 Share Posted June 11, 2020 Got 2 requests regarding the history debug window: 1.is it possible to choose its buffer size ? I'd like to have it least 10-15 sec of buffering. 2.Could I copy everything to the clipboard instead of just what's visible ? or perhaps save it to a file ? Thanks Quote Link to comment Share on other sites More sharing options...
phaeron Posted June 12, 2020 Author Share Posted June 12, 2020 8 hours ago, rensoup said: Got 2 requests regarding the history debug window: 1.is it possible to choose its buffer size ? I'd like to have it least 10-15 sec of buffering. No, the history buffer in the CPU emulator is hardcoded to a ring buffer of 128K instructions. 10-15 seconds would require around 6M instructions. The performance analyzer can record a much longer trace, as it periodically spools off the data from the ring buffer into a separate, compressed trace buffer. It is limited to a total trace size of 500MB on 32-bit builds and limited only by total memory on 64-bit. However, it still only lets you look at a 400K instruction window at a time to prevent the UI from blowing up as the tree construction algorithms can slow down on really big traces. 8 hours ago, rensoup said: 2.Could I copy everything to the clipboard instead of just what's visible ? or perhaps save it to a file ? There is currently no option to do this in the UI. You can dump the entire history buffer with the debugger's 'h' command with appropriate arguments and spool it to a big text file with .logopen/.logclose, but it will not do the structure analysis that the UI does for loops/calls/interrupts. It also only works off of the CPU's history buffer and not the performance analyzer trace. 1 Quote Link to comment Share on other sites More sharing options...
ilmenit Posted June 12, 2020 Share Posted June 12, 2020 15 hours ago, phaeron said: There is currently no option to do this in the UI. You can dump the entire history buffer with the debugger's 'h' command with appropriate arguments and spool it to a big text file with .logopen/.logclose, but it will not do the structure analysis that the UI does for loops/calls/interrupts. It also only works off of the CPU's history buffer and not the performance analyzer trace. I see I need to read the help again, because I was missing this option a lot when debugging recently ? If I could have a request it would be ability automate debugging of executables started from ATR. While I can keep a single instance of Altirra and have debugger startup script for XEXes, in case of debugging ATRs I cannot easily replace the ATR with new version of the program and have a script that will load new symbols automatically (preferably keeping currently set breakpoints). One of the options would be great to have: 1. ability to reload "startup.atdbg" on warm/cold start - to unload and load new symbols or preferred: 2. ability to load on-demand a script with debugger commands (I could reload symbols there and set some breakpoints "ba w my_symbol") Quote Link to comment Share on other sites More sharing options...
Xuel Posted June 12, 2020 Share Posted June 12, 2020 2 minutes ago, ilmenit said: I see I need to read the help again, because I was missing this option a lot when debugging recently ? If I could have a request it would be ability automate debugging of executables started from ATR. While I can keep a single instance of Altirra and have debugger startup script for XEXes, in case of debugging ATRs I cannot easily replace the ATR with new version of the program and have a script that will load new symbols automatically (preferably keeping currently set breakpoints). One of the options would be great to have: 1. ability to reload "startup.atdbg" on warm/cold start - to unload and load new symbols or preferred: 2. ability to load on-demand a script with debugger commands (I could reload symbols there and set some breakpoints "ba w my_symbol") For #2, there is the ".batch" command. Is that sufficient? Altirra> .help .batch .batch Run debugger batch script Runs the contents of a text file as a series of debugger commands. .batch <filename> Quote Link to comment Share on other sites More sharing options...
ilmenit Posted June 12, 2020 Share Posted June 12, 2020 (edited) 16 minutes ago, Xuel said: For #2, there is the ".batch" command. Is that sufficient? Altirra> .help .batch .batch Run debugger batch script Runs the contents of a text file as a series of debugger commands. .batch <filename> shame on me. I really need to read the whole help... Edited June 12, 2020 by ilmenit Quote Link to comment Share on other sites More sharing options...
rensoup Posted June 19, 2020 Share Posted June 19, 2020 On 6/12/2020 at 4:32 AM, phaeron said: There is currently no option to do this in the UI. You can dump the entire history buffer with the debugger's 'h' command with appropriate arguments and spool it to a big text file with .logopen/.logclose, but it will not do the structure analysis that the UI does for loops/calls/interrupts. It also only works off of the CPU's history buffer and not the performance analyzer trace. When I encounter hard to reproduce bugs, I get into the debugger as quickly as I can but when I trace back, sometimes the history isn't there anymore... I don't think the 'h' command + log file would work for me ? I've tried building Altirra locally so I could change the buffer size (finally installed W10 in a virtualbox and done a fresh install of VS2019). But yasm can't be found even though I downloaded it: I modified Yasm.props in the build directory and also placed it in the localconfig/active directory Quote Link to comment Share on other sites More sharing options...
phaeron Posted June 19, 2020 Author Share Posted June 19, 2020 47 minutes ago, rensoup said: When I encounter hard to reproduce bugs, I get into the debugger as quickly as I can but when I trace back, sometimes the history isn't there anymore... I don't think the 'h' command + log file would work for me ? I've tried building Altirra locally so I could change the buffer size (finally installed W10 in a virtualbox and done a fresh install of VS2019). But yasm can't be found even though I downloaded it: I modified Yasm.props in the build directory and also placed it in the localconfig/active directory I hate MSBuild. Modify src\Build\YASM.targets to add the following CreateProperty block: <Target Name="_YASMCheck"> <CreateProperty Value="0"> <Output PropertyName="YASMCheckErrorCode" TaskParameter="Value" /> </CreateProperty> <Exec Condition="!Exists('$(YASMPath)')" Quote Link to comment Share on other sites More sharing options...
rensoup Posted June 19, 2020 Share Posted June 19, 2020 16 hours ago, phaeron said: Modify src\Build\YASM.targets to add the following CreateProperty block: That worked... until building the kernel.rom with mads (?) I had to comment out the line if !KERNEL_XLXE in kerneldb.inc because mads complained that pbufsz was undefined after that I just waited, waited more (forgot how slow C++ is to build...) and suddenly I had a working Altirra executable! So back to my cpu history tweak: C:\altirra\a400t2\src\Altirra\h\cpu.h(256): return mHistory[(mHistoryIndex - i - 1) & 131071]; C:\altirra\a400t2\src\Altirra\h\cpu.h(260): uint32 GetHistoryCounter() const { return mHistoryIndex; } C:\altirra\a400t2\src\Altirra\h\cpu.h(437): int mHistoryIndex; C:\altirra\a400t2\src\Altirra\h\cpu.h(450): HistoryEnableFlags mHistoryEnableFlags; C:\altirra\a400t2\src\Altirra\h\cpu.h(484): HistoryEntry mHistory[131072]; C:\altirra\a400t2\src\Altirra\h\cpumachine.inl(1570): HistoryEntry& he = mHistory[(mHistoryIndex - 1) & 131071]; I'm guessing I just need to change those 3 values ? Quote Link to comment Share on other sites More sharing options...
phaeron Posted June 20, 2020 Author Share Posted June 20, 2020 6 hours ago, rensoup said: That worked... until building the kernel.rom with mads (?) I had to comment out the line if !KERNEL_XLXE in kerneldb.inc because mads complained that pbufsz was undefined Odd, this shouldn't be the case because there's another definition of pbufsz in under #if KERNEL_XLXE further below. 6 hours ago, rensoup said: after that I just waited, waited more (forgot how slow C++ is to build...) and suddenly I had a working Altirra executable! You probably have VirtualBox set to only one 1 vCPU or Windows Defender is scanning the build tree. It takes longer than other languages but it's not that long, I build Altirra on a potato (XPS 13). The Profile configuration is what I use most often, as it generates optimized code but doesn't do the link-time optimization that Release does. 6 hours ago, rensoup said: So back to my cpu history tweak: C:\altirra\a400t2\src\Altirra\h\cpu.h(256): return mHistory[(mHistoryIndex - i - 1) & 131071]; C:\altirra\a400t2\src\Altirra\h\cpu.h(260): uint32 GetHistoryCounter() const { return mHistoryIndex; } C:\altirra\a400t2\src\Altirra\h\cpu.h(437): int mHistoryIndex; C:\altirra\a400t2\src\Altirra\h\cpu.h(450): HistoryEnableFlags mHistoryEnableFlags; C:\altirra\a400t2\src\Altirra\h\cpu.h(484): HistoryEntry mHistory[131072]; C:\altirra\a400t2\src\Altirra\h\cpumachine.inl(1570): HistoryEntry& he = mHistory[(mHistoryIndex - 1) & 131071]; I'm guessing I just need to change those 3 values ? One more, GetHistoryLength(). There is also a limit of 500K instructions in the history UI (uihistoryview.cpp). It's a separate limit because it relates to the history tree that the UI incrementally updates from the flat history ring buffer. There's no fixed buffer in that case, it is just a safety limit. Quote Link to comment Share on other sites More sharing options...
rensoup Posted June 20, 2020 Share Posted June 20, 2020 9 hours ago, phaeron said: Odd, this shouldn't be the case because there's another definition of pbufsz in under #if KERNEL_XLXE further below. yes indeed... (using MADS210 btw) Not sure if it's spawning threads all over the place but I can't really tell where it's complaining exactly Spoiler ------ Build started: Project: atbasic, Configuration: Release Win32 ------ ------ Build started: Project: Kernel, Configuration: Release Win32 ------ C:\altirra\a400t2\src\Kernel>"c:\altirra\mads210.exe" -i:autobuild -i:autobuild_default -d:_KERNEL_XLXE=0 -s -p -i:source\Shared -b:$d800 -l:..\..\out\Release\\kernel.lst -t:..\..\out\Release\\kernel.lab -o:..\..\out\Release\\kernel.rom C:\altirra\a400t2\src\Kernel\source\main.xasm ... ... $FE4E -> $0A60($0000) Display routines $FFCF -> $0181($0000) Keyboard routines Free space: $002B bytes C:\altirra\a400t2\src\Kernel>"c:\altirra\mads210.exe" -i:autobuild -i:autobuild_default -d:_KERNEL_XLXE=1 -s -p -i:source\Shared -b:$c000 -l:..\..\out\Release\\kernelxl.lst -t:..\..\out\Release\\kernelxl.lab -o:..\..\out\Release\\kernelxl.rom C:\altirra\a400t2\src\Kernel\source\main.xasm ... ... $FE42 -> $0AE2($0000) Display routines $FFE0 -> $019E($0000) Keyboard routines Free space: $000E bytes C:\altirra\a400t2\src\Kernel>"c:\altirra\mads210.exe" -i:autobuild -i:autobuild_default -d:_KERNEL_XLXE=1 -d:_KERNEL_SOFTKICK=1 -s -p -i:source\Shared -b:$c000 -l:..\..\out\Release\\kernelxlsoft.lst -t:..\..\out\Release\\kernelxlsoft.lab -o:..\..\out\Release\\kernelxlsoft.bin C:\altirra\a400t2\src\Kernel\source\main.xasm ... ... $FE42 -> $0AE2($0000) Display routines $FFE0 -> $019E($0000) Keyboard routines Free space: $000E bytes C:\altirra\a400t2\src\Kernel>"c:\altirra\mads210.exe" -i:..\..\out\Release\ -s -p -i:source\Shared -l:..\..\out\Release\\kernelxlsoftkick.lst -t:..\..\out\Release\\kernelxlsoftkick.lab -o:..\..\out\Release\\kernelxlsoftkick.xex C:\altirra\a400t2\src\Kernel\source\softkick.s C:\altirra\a400t2\src\Kernel>"c:\altirra\mads210.exe" -i:autobuild -i:autobuild_default -d:_KERNEL_XLXE=1 -d:_KERNEL_816=1 -s -p -i:source\Shared -b:$c000 -l:..\..\out\Release\\kernel816.lst -t:..\..\out\Release\\kernel816.lab -o:..\..\out\Release\\kernel816.rom C:\altirra\a400t2\src\Kernel\source\main.xasm ... ... $FE3D -> $0ADD($0000) Display routines $FFD5 -> $0198($0000) Keyboard routines Free space: $0019 bytes copy /b "..\..\obj\Release\Kernel\\nomio.rom"+"..\..\obj\Release\Kernel\\nomio.rom"+"..\..\obj\Release\Kernel\\nomio.rom"+"..\..\obj\Release\Kernel\\nomio.rom" "..\..\obj\Release\Kernel\\nomio2.rom" ..\..\obj\Release\Kernel\\nomio.rom ..\..\obj\Release\Kernel\\nomio.rom ..\..\obj\Release\Kernel\\nomio.rom ..\..\obj\Release\Kernel\\nomio.rom 1 file(s) copied. ..\..\obj\Release\Kernel\\nomio2.rom(8192) -> ..\..\out\Release\\nomio.lzrom(459) copy /b "..\..\obj\Release\Kernel\\noblackbox.rom"+"..\..\obj\Release\Kernel\\noblackbox.rom"+"..\..\obj\Release\Kernel\\noblackbox.rom"+"..\..\obj\Release\Kernel\\noblackbox.rom"+"..\..\obj\Release\Kernel\\noblackbox.rom"+"..\..\obj\Release\Kernel\\noblackbox.rom"+"..\..\obj\Release\Kernel\\noblackbox.rom"+"..\..\obj\Release\Kernel\\noblackbox.rom" "..\..\obj\Release\Kernel\\noblackbox2.rom" ..\..\obj\Release\Kernel\\noblackbox.rom ..\..\obj\Release\Kernel\\noblackbox.rom ..\..\obj\Release\Kernel\\noblackbox.rom ..\..\obj\Release\Kernel\\noblackbox.rom ..\..\obj\Release\Kernel\\noblackbox.rom ..\..\obj\Release\Kernel\\noblackbox.rom ..\..\obj\Release\Kernel\\noblackbox.rom ..\..\obj\Release\Kernel\\noblackbox.rom 1 file(s) copied. ..\..\obj\Release\Kernel\\noblackbox2.rom(16384) -> ..\..\out\Release\\noblackbox.lzrom(563) $0001 bytes free before $D8E6 $0005 bytes free before $D9AA $0002 bytes free before $D9D2 $0001 bytes free before $DA44 $0001 bytes free before $DA60 $0001 bytes free before $DBA1 $0002 bytes free before $DBFF $0006 bytes free before $DD3E $0005 bytes free before $DD87 $0005 bytes free before $DE95 $0001 bytes free before $DECD stx pbufsz source\Shared\printer.s (62) ERROR: Undeclared label PBUFSZ (BANK=0) inc pbpnt source\Shared\printer.s (65) ERROR: Undeclared label PBPNT (BANK=0) ldx pbpnt source\Shared\printer.s (66) ERROR: Undeclared label PBPNT (BANK=0) cpx pbufsz source\Shared\printer.s (76) ERROR: Undeclared label PBUFSZ (BANK=0) source\Shared\printer.s (86) ERROR: Undeclared label PBPNT (BANK=0) source\Shared\printer.s (104) ERROR: Undeclared label PBUFSZ (BANK=0) sty pbpnt source\Shared\printer.s (113) ERROR: Undeclared label PBPNT (BANK=0) sta pbpnt NMAKE : fatal error U1077: 'c:\altirra\mads210.exe' : return code '0x2' Stop. source\Shared\printer.s (150) ERROR: Undeclared label PBPNT (BANK=0) ------ Build started: Project: Altirra, Configuration: Release Win32 ------ Generating code Not all modules are compiled with -Gy (function comdat), build without incremental LTCG. So I changed it to this and it's not complaining anymore .if _KERNEL_XLXE pbpnt = $02de ;Printer: Buffer index (XL/XE location) pbufsz = $02df ;Printer: Record size (XL/XE location) .else pbpnt = $001d ;Printer: Buffer index (OS-A/B location) pbufsz = $001e ;Printer: Record size (OS-A/B location) .endif 9 hours ago, phaeron said: You probably have VirtualBox set to only one 1 vCPU or Windows Defender is scanning the build tree. It takes longer than other languages but it's not that long, I build Altirra on a potato (XPS 13). The Profile configuration is what I use most often, as it generates optimized code but doesn't do the link-time optimization that Release does. This is where it stays for a while (so that's the linking indeed): Quote Not all modules are compiled with -Gy (function comdat), build without incremental LTCG. So I switched to profile, and yes big improvement! 13 hours ago, phaeron said: One more, GetHistoryLength(). There is also a limit of 500K instructions in the history UI (uihistoryview.cpp). It's a separate limit because it relates to the history tree that the UI incrementally updates from the flat history ring buffer. There's no fixed buffer in that case, it is just a safety limit. I also missed one in cpu.cpp, seems all good now. and I'm able to dump megabytes of history... any chance of making this a #define for the next release ? Quote Link to comment Share on other sites More sharing options...
rsh Posted July 28, 2020 Share Posted July 28, 2020 On 6/8/2020 at 10:24 PM, phaeron said: This is a bit strange. You might notice slightly more latency than A8WP but it shouldn't be that bad, and it sounds like something is causing the emulator to bog down. Enable View > Show FPS and make sure you're hitting 60 (may bounce around 59-61 but shouldn't be significantly below that), and check that GPU usage isn't spiking in Task Manager. Altirra's default configuration should be lean on the GPU usage but enabling some options like high artifacting can be bit heavier. Custom devices can interface to a local network server but don't currently have the ability to access the full memory map, they can only affect their own local device memory. I've thought about the possibility of an automation profile that can access the full address space but it is not currently implemented. Thank you for the response. I did some testing and restarting Altirria and resetting the config. I got it to work much better, but still does not seem as responsive as WinPlus. Altirria my have some leak that can slow usb device input down. Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted February 12, 2021 Share Posted February 12, 2021 (edited) On 4/15/2020 at 4:36 AM, phaeron said: It's not so much the extra bytes in the handler so much as the handler doing something that the Atari handler doesn't and that others may not want. Unilaterally switching to 50Hz would definitely fall under this. But I can give you custom builds that auto-switch to 50Hz: xep80.sys 1.52 kB · 27 downloads xep80f.sys 1.79 kB · 25 downloads Pulled out the scope and as I feared, 4X mode is a no-go as the rise time on the PIA inputs is too slow. 2X mode is about on the border of what the joystick inputs can handle, 4X simply doesn't have enough recovery time per bit to send 1 bits properly: The only other possibility for speeding up comm would be to try symmetric 31.5Kbaud instead of 31.5K transmit / 15.7K receive, to speed up the reception of the status bytes. The XEP80 hardware is capable of this, but the reason I haven't tried it is that the async receive is more difficult with ANTIC @#*$ refresh cycles. As for changing the NTSC display, you can try this BASIC program: 10 PRINT CHR$(0); 20 XIO 22,#16,12,246,"" 30 FOR I=0 TO 8 40 READ X 50 PRINT CHR$(X); 60 XIO 22,#16,12,247,"" 70 NEXT I 80 PRINT CHR$(23);:XIO 22,#16,12,248,"" 90 DATA 108,79,82,95,128,28,25,2,23 This reprograms the NS405 timing chain and VINT register. It reconfigures the display timing to 109x29 characters cells of 9 scans/row + 1 extra scan, giving 15.727KHz H x 60.02Hz and reducing the number of display scanlines for the main 80x24 display from 240 to 216. You are correct, this will not work because my XEP80 driver will force off the ANTIC display. This is to work around the problem with BASIC XE turning the ANTIC display on and screwing up XEP80 receive timing. BobTerm doesn't have that problem because it uses burst mode, but the XEP80 driver doesn't know that it is working with an XEP80-friendly program and I'm not sure it sees the burst mode switch in time. why not just have a driver for BXE etc. it wouldn't be the first time another driver is needed for this or that combination. also did the status bug byte error get fixed as BillC has also tried some driver and what not and said it only worked with Atari's driver... Edited February 12, 2021 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
BillC Posted February 15, 2021 Share Posted February 15, 2021 On 2/11/2021 at 6:04 PM, _The Doctor__ said: why not just have a driver for BXE etc. it wouldn't be the first time another driver is needed for this or that combination. also did the status bug byte error get fixed as BillC has also tried some driver and what not and said it only worked with Atari's driver... The issue was with BASIC code that used XIO to reprogram the XEP80 to use only 216 scan lines, the SDX and Altirra release XEP80 drivers don't have XIO enabled. The additions disk for the Altirra beta/test releases has updated drivers and an XEPVHOLD ML program that does the same as the BASIC code. Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted February 15, 2021 Share Posted February 15, 2021 1 hour ago, BillC said: The issue was with BASIC code that used XIO to reprogram the XEP80 to use only 216 scan lines, the SDX and Altirra release XEP80 drivers don't have XIO enabled. The additions disk for the Altirra beta/test releases has updated drivers and an XEPVHOLD ML program that does the same as the BASIC code. yup Quote Link to comment Share on other sites More sharing options...
vitoco Posted May 12, 2021 Share Posted May 12, 2021 (edited) (removed) Edited May 12, 2021 by vitoco not the thread Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.