+therealbountybob Posted January 4, 2017 Share Posted January 4, 2017 Ok Assembler fans... As you may be aware I've been adding levels to the Snowplow game (NYD2017) from analog mag #64. Please can someone take a look at the assembly code (MAC/65 & commented, listed in the mag also) and see why the game only loads two extra levels before returning to the inbuilt first level which is hard coded. As far as I read it should support multiple level files. Comments say it will load files in disk order. Looks like it does a directory using CIO. I noticed on line 8530 in the GETDIR routine it has a CMP #'F which I thought was a typo, but it's in the magazine listing too. " ' F " looks like it assembles as $46/#70 which is "ZDRVA" in mapping the atari - if this is any help. It's checking something in the buffer against this and then going to the inbuilt level or not. Was this a typo or something clever? SNOWPLOW-TESTING.ATR On the DOS disk attached is code: SNOW.PT1 AND .PT2 game: snowplow.com test levels: SMAP.A-F, which have 1 blob of scenery to represent the level # and a short road so you can complete them quickly You need to complete the first screen to reach these. The game returns to the title screen after each level and you need to press start to load the next one (providing you have a man left) The first (inbuilt) level starts with 180 fuel and this drops by 10 on each subsequent level. Thanks Jason Quote Link to comment Share on other sites More sharing options...
+CharlieChaplin Posted January 5, 2017 Share Posted January 5, 2017 (edited) Errrmm well, some stupid idea first: Have you booted with Option key and disabled Basic ? And since I know you would not forget this, another stupid idea: I also have Snowplow as a stand-alone file, it still looks for the levels/maps, but when not found it simply starts the built-in level. Some years ago I downloaded the snowplow-editor, which came with one external level and as it turns out, this was/is the same as the built-in level ! So to make the idea stupid, you have taken the editor level as level 3, so maybe (stupid idea) the program is loading level 1, level 2 and then level 3 as you want - but you simply think it just returned to the built-in level (since your level 3 and the built-in level are the same) ?!? Add a test-level 4 and see what happens... Time to take my pills now and hunt some more ghosts in the maze... Edited January 5, 2017 by CharlieChaplin Quote Link to comment Share on other sites More sharing options...
+therealbountybob Posted January 5, 2017 Author Share Posted January 5, 2017 Hi CC, it's nothing so simple unfortunately The board that came with the editor on Analog #65 IS different: Snowplow game level: Editor level: The New Year Disk version has these plus another one I created Quote Link to comment Share on other sites More sharing options...
+slx Posted January 5, 2017 Share Posted January 5, 2017 (edited) Could it be that the "F" belongs to "427 FREE SECTORS" which would be located at DBUF+4 when the line past the last level has been read in by GETFIL. Once that appears there is no more loadable level. While that would explain the mechanism and the 'F but still doesn't explain why the program will not load more than two levels. Maybe the disk directory access gets reset somewhere? Have you tried running this with a debugger and setting a breakpoint at the equivalent of 8530 and check what's inside DBUF at the time? Edited January 5, 2017 by slx 2 Quote Link to comment Share on other sites More sharing options...
+therealbountybob Posted January 5, 2017 Author Share Posted January 5, 2017 Ha! I didn't realise CMP #'F etc was valid code - just had a flick through the MAC/65 manual and saw some other examples. As far as I can tell (so far have resisted reassembling this game as I'm really meant to be working on finishing Space Fortress Omega)... ...DBUF is at $5644-5657 so in the dump below you can see this contains the filename SMAP.A etc and is ok for the first two levels loaded, but then the third one it has other data here (in bold) SNOWPLOW MEMORY DUMPTEST LEVEL FILES NAMES SMAP.A/B/C/D/E/F2nd level loaded5630: 60 RTS5631: 82 6A NOP #$6A5633: 76 04 ROR RAMLO,X ** ** 76 is the last data byte of the inbuilt level followed by variable RANDS length 16)5635: 03 09 SLO ($09,X)5637: 0E 0D 00 ASL DOSINI+1563A: 0C 05 06 NOP $0605563D: 02 KIL563E: 0F 0B 0A SLO $0A0B5641: 08 PHP5642: 01 07 ORA ($07,X)-------------------------------------5644: 20 20 53 JSR $53205647: 4D 41 50 EOR $5041564A: 20 20 20 JSR $2020564D: 20 41 20 JSR $2041 ** 41="file A"5650: 20 20 30 JSR $30205653: 32 KIL5654: 31 9B AND ($9B),Y5656: 00 BRK5657: 00 BRK-------------------------------------5658: 01 00 ORA ($00,X)565A: 80 00 NOP #$00565C: 80 00 NOP #$00565E: 80 00 NOP #$005660: 80 00 NOP #$003rd level loaded5630: 60 RTS5631: 82 6A NOP #$6A5633: 76 04 ROR RAMLO,X5635: 03 09 SLO ($09,X)5637: 0E 0D 00 ASL DOSINI+1563A: 0C 05 06 NOP $0605563D: 02 KIL563E: 0F 0B 0A SLO $0A0B5641: 08 PHP5642: 01 07 ORA ($07,X)-------------------------------------5644: 20 20 53 JSR $53205647: 4D 41 50 EOR $5041564A: 20 20 20 JSR $2020564D: 20 42 20 JSR $2042 ** 42="file B"5650: 20 20 30 JSR $30205653: 32 KIL5654: 31 9B AND ($9B),Y5656: 00 BRK5657: 00 BRK-------------------------------------5658: 01 00 ORA ($00,X)565A: 80 00 NOP #$00565C: 80 00 NOP #$00565E: 80 00 NOP #$005660: 80 00 NOP #$004th level should be loaded... but returned to inbuilt 1st level - note: has 150 fuel in game so is 4th level.5630: 60 RTS5631: 82 6A NOP #$6A5633: 76 04 ROR RAMLO,X5635: 03 09 SLO ($09,X)5637: 0E 0D 00 ASL DOSINI+1563A: 0C 05 06 NOP $0605563D: 02 KIL563E: 0F 0B 0A SLO $0A0B5641: 08 PHP5642: 01 07 ORA ($07,X)-------------------------------------5644: 34 32 NOP BUFRLO,X5646: 37 20 RLA ICHIDZ,X5648: 46 52 LSR LMARGN564A: 45 45 EOR $45564C: 20 53 45 JSR $4553564F: 43 54 SRE (ROWCRS,X)5651: 4F 52 53 SRE $53525654: 9B 9B 00 SHS $009B,Y5657: 00 BRK-------------------------------------5658: 01 00 ORA ($00,X)565A: 80 00 NOP #$00565C: 80 00 NOP #$00565E: 80 00 NOP #$005660: 80 00 NOP #$00 Quote Link to comment Share on other sites More sharing options...
+slx Posted January 5, 2017 Share Posted January 5, 2017 I have set a breakpoint at $4c77 (which is the assembly result of line 8530) and checked DBUF every time it stopped there. As assumed above DBUF contained SMAP.A after the original level, then SMAP.B after new level one but then changed to the free sector line. Unfortunately I have no idea why that might happen. Next idea would be to simulate reading the directory line by line and see what's happening. Another possibility would be to try a different DOS and check for same behaviour. Quote Link to comment Share on other sites More sharing options...
+slx Posted January 5, 2017 Share Posted January 5, 2017 (edited) ------------------------------------- 5644: 34 32 NOP BUFRLO,X 5646: 37 20 RLA ICHIDZ,X 5648: 46 52 LSR LMARGN 564A: 45 45 EOR $45 564C: 20 53 45 JSR $4553 564F: 43 54 SRE (ROWCRS,X) 5651: 4F 52 53 SRE $5352 5654: 9B 9B 00 SHS $009B,Y 5657: 00 BRK ------------------------------------- This would have been a bit easier to read as a character dump 34 32 37 20 46 52 45 45 is "427 FREE" in ASCII Still no clue as to why as the expectation would be for the buffer to contain SMAP .C rather than the free sectors at the end of the directory. The "F" in FREE causes the program to reset to the built-in level (line 8550 an on). Edited January 5, 2017 by slx Quote Link to comment Share on other sites More sharing options...
+playsoft Posted January 5, 2017 Share Posted January 5, 2017 It opens the directory looking for matches with D1:SMAP.* and performs a get record to retrieve the first match. It then opens and reads the matching file. When you finish the level it performs another directory get record expecting to get the next matching file. Unfortunately that won't work with Atari DOS - opening another file while a directory read is open will cause it to go wrong. To fix it you'll need to keep a count on which matching file you want and each time open the directory, repeatedly call get record until you reach the one you want and then close it. 2 Quote Link to comment Share on other sites More sharing options...
+slx Posted January 5, 2017 Share Posted January 5, 2017 One option would be to limit possible level filename extensions to A to Z, hardcode MAPNAM, leave out GETDIR and GETFIL and simply try to read the next filename via LOADMP by incrementing $46EB (MAPNAM + 10) and return to the main screen when an error occurs. Another possibility would be to read all level filenames and store them into a table, then load them one after another by copying from the table to MAPNAM. 2 Quote Link to comment Share on other sites More sharing options...
+slx Posted January 5, 2017 Share Posted January 5, 2017 Unfortunately that won't work with Atari DOS - opening another file while a directory read is open will cause it to go wrong. Is this a problem with Atari DOS only or would other DOSes for the Atari show the same result? Quote Link to comment Share on other sites More sharing options...
+playsoft Posted January 5, 2017 Share Posted January 5, 2017 Is this a problem with Atari DOS only or would other DOSes for the Atari show the same result? I only know Atari DOS but I like the idea of simply incrementing the filename extension. Quote Link to comment Share on other sites More sharing options...
+therealbountybob Posted January 6, 2017 Author Share Posted January 6, 2017 (edited) It opens the directory looking for matches with D1:SMAP.* and performs a get record to retrieve the first match. It then opens and reads the matching file. When you finish the level it performs another directory get record expecting to get the next matching file. Unfortunately that won't work with Atari DOS - opening another file while a directory read is open will cause it to go wrong. To fix it you'll need to keep a count on which matching file you want and each time open the directory, repeatedly call get record until you reach the one you want and then close it. Why does it always load *2* additional levels without problems? I had it on a DOS2.5 disk, wonder if it would be ok on DOS2.0 will try this [same] Edited January 6, 2017 by therealbountybob Quote Link to comment Share on other sites More sharing options...
+playsoft Posted January 6, 2017 Share Posted January 6, 2017 Why does it always load *2* additional levels without problems? I had it on a DOS2.5 disk, wonder if it would be ok on DOS2.0 will try this Page 84 of the Technical Reference Notes (CO16555) clearly states: The opening of another diskette file while the directory read is open will cause subsequent directory reads to malfunction so care must be taken to avoid this situation. The first file loads fine since nothing has gone wrong at that point. That the second file loads is the nature of the DOS code. If you want to explore why the second works but not the third you will have to step through the DOS code and work out what it does! 1 Quote Link to comment Share on other sites More sharing options...
+playsoft Posted January 6, 2017 Share Posted January 6, 2017 I modified the program so that it will attempt to read files D1:SMAP.A, D1:SMAP.B, D1:SMAP.C etc. I created a new GETDIR function which just sets the DIRNAM file extension to "A". I created a new GETFIL function which tries to open the DIRNAM file and then behaves like the original GETFIL, either copying DIRNAM to MAPNAM or doing that jump out to MAP2. It also increments the DIRNAM extension so that the next time it's called it will try the next file in sequence. I also made one other change to clear down an area of memory which is displayed when you are right at the bottom. It is only a single scan line but depending on how you load it might not be empty. sp.atr 3 Quote Link to comment Share on other sites More sharing options...
+playsoft Posted January 6, 2017 Share Posted January 6, 2017 Interestingly in Altirra when the plow is stationary I see flickering little lines to the right of the display. There are 3 in this image: Does anyone else get this? I do not see this on real hardware, I tested on both PAL and NTSC machines. I don't see it on Atari800Win PLus either. It seems to be reads of the P0PL and P1PL collision detection registers which are causing this. The program (unnecessarily) reads these quite frequently - if I take them out the little lines go away. Quote Link to comment Share on other sites More sharing options...
+therealbountybob Posted January 6, 2017 Author Share Posted January 6, 2017 (edited) Thanks Paul I'm trying this now I had the same lines on Altirra and not on the 130XE. If anyone reading this wants to knock up a level please get in touch or if anyone wants to program some other features e.g. Vary the snowflake logic. It's a pretty decent game probably intended as a commercial release from what I read. I just need to order my levels and do some testing to make sure they are possible with the reduced fuel max as the game progresses before posting it [edit] works nicely thanks again. I will make a few tweaks to the game as some of the parameters make the game too hard with more screens! Edited January 6, 2017 by therealbountybob 2 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted January 7, 2017 Share Posted January 7, 2017 An old favorite and some of my favorite people making it what it should be makes it even more endearing! Awesome 2 Quote Link to comment Share on other sites More sharing options...
+CharlieChaplin Posted January 7, 2017 Share Posted January 7, 2017 Played a little with the new bugfixed version of Snowplow and its editor... Alas, the editor is quite awkward to use (compared to other editors or construction kits), e.g. almost all elements consist of two halves, even the roads and there are some rules/restrictions where roads and other elements can/must be placed (afaik only on even lines or columns). Nevertheless, I added a little more content to TRBB`s last level and also created my own mini-level. So now you have one built-in level and four external levels. Still it would be great, if a good level designer creates bigger and more varied levels (especially for the last two levels, SMAP.C and SMAP.D on the disk). On the other hand, the game is not that difficult - you only lose a dozer/snowplower when you are out of fuel/gas or when the storm gets you. There is no time limit and errm, the only thing that makes the levels harder is the storm that is coming more frequently and moving faster and faster in each level (and maybe the fuel stations, giving you less fuel/gas in each level). So after some hours fighting with the editor and testing the levels afterwards (noticing they had quite some small level bugs, since TRBB and me did not take enough care of the rules/restrictions mentioned above), here is the little bit I created... (The Snowplow game had dozens of short memory-segments, I merged them into just three segments, so that is why the gamefile is now much longer than before.) SNOWPLOW.ATR SNOWEDIT.ATR 2 Quote Link to comment Share on other sites More sharing options...
+slx Posted January 7, 2017 Share Posted January 7, 2017 While I don't find the game that enticing I was quite amazed to see such a huge fine-scrolling play area in a type-in game. Worse stuff was sold only a couple of years earlier... 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.