+DrVenkman Posted June 29, 2021 Share Posted June 29, 2021 Just now, mozzwald said: ATR on SD card I wonder if that's the key? MOST of my tests have been from my TNFS server on the LAN because it's just so damned convenient to drag-and-drop files from the Downloads folder on my PC to the TNFS SMB share folder instead of manually copying stuff to SD cards. SLIGHT ASIDE: have you guys considered caching mounted ATRs from the non-SD Hosts list to the SD card to eliminate network latency for edge cases like this? I know you or Thom once told me that's what is done for ATX files. Quote Link to comment Share on other sites More sharing options...
mozzwald Posted June 29, 2021 Share Posted June 29, 2021 9 minutes ago, DrVenkman said: have you guys considered caching mounted ATRs from the non-SD Hosts list to the SD card to eliminate network latency for edge cases like this? I know you or Thom once told me that's what is done for ATX files. I think it has been mentioned before. It could get difficult to implement if you want to write to disks. Would be easier if it only applies to read only disks. 12 minutes ago, DrVenkman said: MOST of my tests have been from my TNFS server on the LAN I'll do you one better and put it up at fujinet.online tnfs in the games dir. We'll see how long this runs... 1 Quote Link to comment Share on other sites More sharing options...
+DrVenkman Posted June 29, 2021 Share Posted June 29, 2021 Just now, mozzwald said: I think it has been mentioned before. It could get difficult to implement if you want to write to disks. Would be easier if it only applies to read only disks. I'll do you one better and put it up at fujinet.online tnfs in the games dir. We'll see how long this runs... Thanks for looking into it. We can take this to PM or the FujiNet forum - clearly I'm pissing off some folks in this thread by stress-testing the game on too many obscure or unusual hardware configurations. But I will also note that the file versions have only caused me problems on my NTSC systems. My PAL 1088XLD will run the "bugfix" full-game ATRs for hours from my LAN, not the local SD card. Quote Link to comment Share on other sites More sharing options...
+Stephen Posted June 29, 2021 Share Posted June 29, 2021 51 minutes ago, DrVenkman said: I wonder if that's the key? MOST of my tests have been from my TNFS server on the LAN because it's just so damned convenient to drag-and-drop files from the Downloads folder on my PC to the TNFS SMB share folder instead of manually copying stuff to SD cards. SLIGHT ASIDE: have you guys considered caching mounted ATRs from the non-SD Hosts list to the SD card to eliminate network latency for edge cases like this? I know you or Thom once told me that's what is done for ATX files. As much as I hate to admit this, and I'm not taking sides as I have no stake nor interest truthfully in this game, but if the issue is only from FujiNet device across a TNFS server, then I don't think it's at all fair to point the finger at PoP nor XBios. The issue lies squarely with the Fujinet device right? 3 Quote Link to comment Share on other sites More sharing options...
+DrVenkman Posted June 29, 2021 Share Posted June 29, 2021 Just now, Stephen said: As much as I hate to admit this, and I'm not taking sides as I have no stake nor interest truthfully in this game, but if the issue is only from FujiNet device across a TNFS server, then I don't think it's at all fair to point the finger at PoP nor XBios. The issue lies squarely with the Fujinet device right? Could be. On the other hand, in ~11 months of using FujiNet devices across all my A8 machines very heavily, this is literally the *only* title I've run into that has any issues with running indefinitely from my LAN's TNFS server - and that includes quite literally hundreds of ATR, ATX, CAS and XEX files both vintage and modern. We already know the core PoP game code runs stably when formatted to run as a cartridge image on real hardware; it's only when running from a LAN TNFS server on NTSC hardware via FujiNet that I've had problems. Does that point a finger at XBios for exposing an edge case in FujiNet or does it point a finger at XBios for being an edge case in terms of file systems? You be the judge of that one. I point this out simply because FujiNet has rapidly become the single best, most capable and flexible SIO device available and is being used by a LOT of hobbyists. If there are compatibility issues with a prominent and dare I say maybe even important new piece of software for the A8 platform, it's best to hammer out the compatibility edge cases no matter if they're on the game's file system side, the FujiNet firmware side, or a combination of both. That said, and in the interest of providing feedback to both @mozzwald and @rensoup, I've had the June 18 "bugfix" full-game ATR running from my FujiNet's local SD card on my 576NUC+ for over an hour when previously I had difficulty even getting it to load successfully on this hardware from my LAN server, or getting the later optimized demo versions to run for very long. 1 Quote Link to comment Share on other sites More sharing options...
Mazzspeed Posted June 29, 2021 Share Posted June 29, 2021 (edited) I have to say, obviously xbios is timing critical - It's highly unlikely it's going to work correctly via a TNFS server... Edited June 29, 2021 by Mazzspeed Quote Link to comment Share on other sites More sharing options...
+Stephen Posted June 29, 2021 Share Posted June 29, 2021 I have no say in this. I also have zero experience with FujiNet - I have used it a total of perhaps 25 minutes total. Hopefully the cause of this can be worked out. For everyone's sanity, let's all say a prayer at the alter of Fuji, that this is not a machine dependent timing case, like many of the Phi02 issues, or god forbid - U1MB + Rapidus in the same room. Quote Link to comment Share on other sites More sharing options...
chevymad Posted June 29, 2021 Share Posted June 29, 2021 Been running the fastest file now for 4.5hrs via TFNS on fujinet with no problems. This is a PAL 1088xel/vbxe machine. So biggest difference between DrVenkman's machine and mine appears to be pal vs ntsc. 2 Quote Link to comment Share on other sites More sharing options...
rensoup Posted June 29, 2021 Author Share Posted June 29, 2021 2 hours ago, mozzwald said: I've been running PoP_DD_20210619_bugfix.atr for over 1.5 hours with no issue yet. Will let it ride until bedtime unless you have another test to try instead. This is what I'm using: 800XL 512k No HSIO FujiNet hardware v1.5, latest firmware ATR on SD card 42 minutes ago, chevymad said: Been running the fastest file now for 4.5hrs via TFNS on fujinet with no problems. This is a PAL 1088xel/vbxe machine. So biggest difference between DrVenkman's machine and mine appears to be pal vs ntsc. Do you know if there are any retry errors ? I would almost suggest trying the PoP_DD_20210610.rar version... but there is also an uninitialized display list issue which can cause it to crash at boot with certain configs. The bugfix version only dodges potential issues by trying to avoid retry errors... the PoP_DD_20210610.rar has tons of retry errors but loads with real drives (very slowly). So if you want to expose potential driver bugs easily, this might be the version to use. Alternatively I could make another test build with the fast mouse drawn many times to force retry errors. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted June 29, 2021 Share Posted June 29, 2021 10 hours ago, DrVenkman said: This is a hobby programming project and I’m a hobbyist. My children are adults and grown. My wife has a real job and hobbies of her own. I have a real job that lets me work from home and allows me to have the toys I want within reason. All of the above means that if I want to set up a system and let it run a game demo as a stability test for 24 hours straight, I have no one to answer for but myself. You’re welcome to productively contribute or not. That said, I have run a number of your demos for extended periods of time and they generally don’t crash. And I can run them from a CF card or SIDE3 as well. *shrug* My productivity contribute is that the game runs flawless on my 65XE VBxE PAL with 320XE ram board and sio2SD run the DD image and demo mode run for at least 30 min… game loaded faster than stunt car racer… and of course I know I was sarcastic… but honestly sometimes it feels like egos against egos instead of being chilled yeah ok it does not run on this hardware but I have another one… i had this kind Of effect when releasing Arsantica 2 which used an early version of xBios and got same kind of flame war at Silly Venture back those days… Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted June 29, 2021 Share Posted June 29, 2021 11 hours ago, Level42 said: Are you a manager at Boeing maybe ? Haha… well…. I would say loading routines on A8 are not that much important then autopilot software and sensors on the machine outside… 1 Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted June 29, 2021 Share Posted June 29, 2021 11 hours ago, Level42 said: My 2 cents: The developer (rensoup) seems to be willing and interested in getting PoP bug free and DrkVenkman has the hardware AND TIME to try out stuff and provide feedback. I see both communicating in a constructive way so we should keep out of this unless we can also provide valuable (test) information. if rensoup would decide to call it a day on fixing the bugs (if any are his) then we’ll have to accept that and be happy with whatever we will get and adjust our setups accordingly. By the way Rensoup, I didn’t provide any logs AFAIR, so the credit for that goes to someone else. That’s what I appreciate of both… but what not is wining “it does not ran here” plus personal attacks on xxl or whoever… 2 Quote Link to comment Share on other sites More sharing options...
mozzwald Posted June 29, 2021 Share Posted June 29, 2021 9 hours ago, DrVenkman said: I've had the June 18 "bugfix" full-game ATR running from my FujiNet's local SD card on my 576NUC+ for over an hour when previously I had difficulty even getting it to load successfully on this hardware from my LAN server 8 hours ago, rensoup said: Do you know if there are any retry errors ? Failed loading from tnfs server seems very random. First test froze in 15 minutes. I let the second test run overnight and it stopped around 4.5 hours. Both times Atari is requesting the same data (a retry error I presume?) which forces Fujinet to reload it's small cache of the disk image which it sends over and then no more command frames are sent by Atari. Fujinet debug output does not show any other duplicate command frame requests, although I only skimmed it over and did not go through all 4 hours of log. Of note is that it takes Fujinet longer to reply with data when it must read and cache from the tnfs server (100-200ms), but why this particular frame failed/froze/crashed is a mystery to me. Here is output from FujiNet: Spoiler 01:05:44.953 > CF: 31 52 6f 01 f3 01:05:44.953 > disk sio_process() 01:05:44.958 > ACK! 01:05:44.958 > ATR READ 01:05:45.009 > ->SIO write 256 bytes 01:05:45.009 > COMPLETE! 01:05:45.153 > 01:05:45.153 > CF: 31 52 70 01 f4 01:05:45.153 > disk sio_process() 01:05:45.158 > ACK! 01:05:45.158 > ATR READ 01:05:45.158 > ->SIO write 256 bytes 01:05:45.158 > COMPLETE! 01:05:45.314 > 01:05:45.315 > CF: 31 52 52 02 d7 01:05:45.315 > disk sio_process() 01:05:45.318 > ACK! 01:05:45.318 > ATR READ 01:05:45.318 > tnfs_lseek currpos=93840, pos=150528, typ=0 01:05:45.318 > _tnfs_cache_seek current=93840, destination=150528, cache_start=93328, cache_end=93840 01:05:45.321 > _tnfs_cache_seek outside cached region 01:05:45.363 > tnfs_lseek success, new pos=150528, response pos=150528 01:05:45.405 > tnfs_lseek currpos=150656, pos=150528, typ=0 01:05:45.405 > _tnfs_cache_seek current=150656, destination=150528, cache_start=150528, cache_end=151040 01:05:45.406 > _tnfs_cache_seek within cached region 01:05:45.406 > tnfs_lseek currpos=150528, pos=151440, typ=0 01:05:45.407 > _tnfs_cache_seek current=150528, destination=151440, cache_start=150528, cache_end=151040 01:05:45.407 > _tnfs_cache_seek outside cached region 01:05:45.450 > tnfs_lseek success, new pos=151440, response pos=151440 01:05:45.493 > ->SIO write 256 bytes 01:05:45.493 > COMPLETE! 01:05:45.657 > 01:05:45.657 > CF: 31 52 53 02 d8 01:05:45.657 > disk sio_process() 01:05:45.657 > ACK! 01:05:45.657 > ATR READ 01:05:45.657 > ->SIO write 256 bytes 01:05:45.658 > COMPLETE! 01:05:45.836 > 01:05:45.836 > CF: 31 52 54 02 d9 01:05:45.836 > disk sio_process() 01:05:45.836 > ACK! 01:05:45.836 > ATR READ 01:05:45.879 > ->SIO write 256 bytes 01:05:45.879 > COMPLETE! 01:05:46.014 > 01:05:46.014 > CF: 31 52 54 02 d9 01:05:46.016 > disk sio_process() 01:05:46.026 > ACK! 01:05:46.027 > ATR READ 01:05:46.027 > tnfs_lseek currpos=152208, pos=151552, typ=0 01:05:46.027 > _tnfs_cache_seek current=152208, destination=151552, cache_start=151952, cache_end=152464 01:05:46.029 > _tnfs_cache_seek outside cached region 01:05:46.071 > tnfs_lseek success, new pos=151552, response pos=151552 01:05:46.113 > tnfs_lseek currpos=151680, pos=151552, typ=0 01:05:46.113 > _tnfs_cache_seek current=151680, destination=151552, cache_start=151552, cache_end=152064 01:05:46.114 > _tnfs_cache_seek within cached region 01:05:46.114 > tnfs_lseek currpos=151552, pos=151952, typ=0 01:05:46.115 > _tnfs_cache_seek current=151552, destination=151952, cache_start=151552, cache_end=152064 01:05:46.116 > _tnfs_cache_seek within cached region 01:05:46.163 > ->SIO write 256 bytes 01:05:46.163 > COMPLETE! and from the tnfs server log: 123.456.789.0 s=4567 c=21 q=5b | REQUEST cmd=0x21 TNFS_READ 123.456.789.0 s=4567 c=25 q=5c | REQUEST cmd=0x25 TNFS_SEEK lseek: offset=151440 (24f90) whence=0 tnfs_whence=0 lseek: New location=151440 (24f90) 123.456.789.0 s=4567 c=21 q=5d | REQUEST cmd=0x21 TNFS_READ 123.456.789.0 s=4567 c=21 q=5e | REQUEST cmd=0x21 TNFS_READ 123.456.789.0 s=4567 c=25 q=5f | REQUEST cmd=0x25 TNFS_SEEK lseek: offset=151552 (25000) whence=0 tnfs_whence=0 lseek: New location=151552 (25000) 123.456.789.0 s=4567 c=21 q=60 | REQUEST cmd=0x21 TNFS_READ 123.456.789.0 s=4567 c=21 q=61 | REQUEST cmd=0x21 TNFS_READ 3 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted June 29, 2021 Share Posted June 29, 2021 (edited) Holy f*** this blew up! There seems to be a fundamental misunderstanding on how network performance impacts timing on FujiNet: Basically, we don't send a complete back, until we have the sector we want in question. This can take a variable amount of time, and in order to keep performance up, we ask for approximately 512 bytes of data from the TNFS server. Again, we do not send the complete until we have the sector we're asking for in fujinet memory. This is completely within the SIO spec, as SIOV will wait until DTIMLO has expired before re-attempting the command. one of two things can be done: (1) an ATX format disk can be made, which will ensure that timing is correct, because we cache that entire disk into the FujiNet memory. (2) a read only fetch mode can be implemented from our side, again, to ensure that timing is correct. I am a bit worried that we are assuming things like best effort sector timing in our loaders. -Thom Edited June 29, 2021 by tschak909 3 Quote Link to comment Share on other sites More sharing options...
xxl Posted June 29, 2021 Share Posted June 29, 2021 (edited) don't change anything - in xB we have to set a longer waiting time for a reply and that's it. but being able to cache the entire ATR into the FujiNet memory is tempting, and would also do the trick - perhaps even speed up the loading of data under all conditions. Edited June 29, 2021 by xxl Quote Link to comment Share on other sites More sharing options...
xxl Posted June 29, 2021 Share Posted June 29, 2021 (edited) 2 hours ago, tschak909 said: (1) an ATX format disk can be made, which will ensure that timing is correct, because we cache that entire disk into the FujiNet memory. (2) a read only fetch mode can be implemented from our side, again, to ensure that timing is correct. the ATR header has a read-only flag - maybe if it was set, FujiNET would always cache such ATRs? --- on the other hand, the stupid idea - ATR can be huge. Edited June 29, 2021 by xxl Quote Link to comment Share on other sites More sharing options...
mozzwald Posted June 29, 2021 Share Posted June 29, 2021 1 hour ago, xxl said: being able to cache the entire ATR into the FujiNet memory is tempting, and would also do the trick - perhaps even speed up the loading of data under all conditions. Maybe better idea to cache ATR to SD Card (if available). It could also save some tiny fractions of bandwith for public tnfs servers in some cases 44 minutes ago, xxl said: the ATR header has a read-only flag - maybe if it was set, FujiNET would always cache such ATRs When user mounts a disk image in fujinet config, they decide if read only or write. If read only, then we can cache the ATR. Issue is open for comments on fujinet github https://github.com/FujiNetWIFI/fujinet-platformio/issues/455 Quote Link to comment Share on other sites More sharing options...
VinsCool Posted June 29, 2021 Share Posted June 29, 2021 22 hours ago, rensoup said: .CAR work 100% I believe... I can say this may be the case based on my own tests. I had played for nearly 3 hours in a row, died a ridiculous () amount of times between the first few levels I was able to play. Then, I left to cook dinner a bit later that day, and kept the Atari 800xl + AVGCART running the game, which eventually went back to the demo + title screen loop, and that alone ran for the entire evening until I came back in my office and powered it off. Everything was still running perfectly fine. In total, the game ran for nearly 6 hours without a single problem. In fact, I couldn't even tell if there was any bug present during the entire time the machine was powered on. When I posted the photo a couple pages earlier, I was well into the 3 hours of gameplay, I had just let it run idle at that moment because I had to do some other stuff shortly after. This was the day before the "bug fixed mouse animation" version if I am not mistaken too. 1 Quote Link to comment Share on other sites More sharing options...
rensoup Posted June 29, 2021 Author Share Posted June 29, 2021 6 hours ago, tschak909 said: (1) an ATX format disk can be made, which will ensure that timing is correct, because we cache that entire disk into the FujiNet memory. @DjayBee mentioned that DD ATX aren't supported/available though ? 5 hours ago, xxl said: don't change anything - in xB we have to set a longer waiting time for a reply and that's it. but being able to cache the entire ATR into the FujiNet memory is tempting, and would also do the trick - perhaps even speed up the loading of data under all conditions. That seems wrong since it works with real drives with the slow dancer (and crashes with fujinet) 3 hours ago, mozzwald said: Maybe better idea to cache ATR to SD Card (if available). It could also save some tiny fractions of bandwith for public tnfs servers in some cases When user mounts a disk image in fujinet config, they decide if read only or write. If read only, then we can cache the ATR. Issue is open for comments on fujinet github https://github.com/FujiNetWIFI/fujinet-platformio/issues/455 if there's no card, perhaps it's possible to cache the entire disk to RAM if size < 360K ? For huge ATRs it's safe to assume that they will all be directory based. So for those: how about just caching the directory sectors ? it would perhaps also be possible to cache the first few sectors for each entry ? Quote Link to comment Share on other sites More sharing options...
rensoup Posted June 29, 2021 Author Share Posted June 29, 2021 2 hours ago, VinsCool said: Everything was still running perfectly fine. In total, the game ran for nearly 6 hours without a single problem. Good to hear, I'd be more worried about the machine itself overheating after that long ? Quote Link to comment Share on other sites More sharing options...
+CharlieChaplin Posted June 29, 2021 Share Posted June 29, 2021 On 6/28/2021 at 8:34 PM, rensoup said: This is also interesting. The unfixed version worked on a real 1050, even though the number of retries must have been insane. that same version failed to load on modern SIO devices. So I have tried to dodge retries with the newer versions because it's good practice and obviously much faster and as a side effect allows it to run on those modern SIO devices. So your loop test wil be interesting... my guess is that it will work (can you leave it for 2 hours ?), because it will retry a lot less than the unfixed version anyway ? Done. Test equipment: Atari 800XL, PAL, XL-OS Rev. 2, Atari Basic off, 512k SRAM enhancement by tf_hh set to 512k XRAM (so a total of 576k RAM was available, but no sep. Antic access in this mode), 1050 with Speedy in normal mode (standard mode after switching power on) Tested the "pop_DDfastestmouse_notplayable2.ATR" yesterday night from 11:00pm to 1:15am (2h15min) and it did not crash. Had to go to bed then with less than 6 hours sleep. Tested the "pop_DDfastestmouse_notplayable2.ATR" today directly after work from 5:00pm to 11:08pm (more than 6 hours) and it did not crash. The demo mode loaded and loaded and after more than six hours the 1050 was quite hot, even the disk was very warm - but the demo mode was still loading (looping) and there was no crash at all. Who will do the 48hour burn-in, ermm, looping test of this demo ATR ? P.S.: Afaik, the Speedy 1050 enhancement always caches Boot and DIR sectors of DOS 2.x disks. 1 Quote Link to comment Share on other sites More sharing options...
xxl Posted June 29, 2021 Share Posted June 29, 2021 after the PoP test, we can immediately see who has poor internet. maybe let's make a donation to a colleague Venkman for a better router? Quote Link to comment Share on other sites More sharing options...
+Stephen Posted June 29, 2021 Share Posted June 29, 2021 2 hours ago, rensoup said: Good to hear, I'd be more worried about the machine itself overheating after that long ? Nope - countless people used to run BBSes back in the day, 24/7 for years. 1 1 Quote Link to comment Share on other sites More sharing options...
+Stephen Posted June 29, 2021 Share Posted June 29, 2021 1 hour ago, xxl said: after the PoP test, we can immediately see who has poor internet. maybe let's make a donation to a colleague Venkman for a better router? I'd rather start a Kickstarter campaign to surgically remove that stick from your ass (and maybe even your head while the surgeons are in there). 1 4 Quote Link to comment Share on other sites More sharing options...
adam242 Posted June 30, 2021 Share Posted June 30, 2021 (edited) 6 hours ago, VinsCool said: I can say this may be the case based on my own tests. I had played for nearly 3 hours in a row, died a ridiculous () amount of times between the first few levels I was able to play. Then, I left to cook dinner a bit later that day, and kept the Atari 800xl + AVGCART running the game, which eventually went back to the demo + title screen loop, and that alone ran for the entire evening until I came back in my office and powered it off. Everything was still running perfectly fine. In total, the game ran for nearly 6 hours without a single problem. In fact, I couldn't even tell if there was any bug present during the entire time the machine was powered on. When I posted the photo a couple pages earlier, I was well into the 3 hours of gameplay, I had just let it run idle at that moment because I had to do some other stuff shortly after. This was the day before the "bug fixed mouse animation" version if I am not mistaken too. I can verify this as well. I've left the .CAR image running for days on my Incognito 800 with the Ultimate Cart. Mostly demo mode, but I've taken a few stabs at actually playing the game. I'm not very good at it yet... having a hard time with the controls, figuring out the different moves. Is there an unofficial manual for this somewhere? Edited June 30, 2021 by adam242 3 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.