Jump to content
IGNORED

Fix my Snowplow - Assembly


Recommended Posts

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

Link to comment
Share on other sites

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 by CharlieChaplin
Link to comment
Share on other sites

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 by slx
  • Like 2
Link to comment
Share on other sites

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 DUMP
TEST LEVEL FILES NAMES SMAP.A/B/C/D/E/F

2nd level loaded
5630: 60 RTS
5631: 82 6A NOP #$6A
5633: 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+1
563A: 0C 05 06 NOP $0605
563D: 02 KIL
563E: 0F 0B 0A SLO $0A0B
5641: 08 PHP
5642: 01 07 ORA ($07,X)
-------------------------------------
5644: 20 20 53 JSR $5320
5647: 4D 41 50 EOR $5041
564A: 20 20 20 JSR $2020
564D: 20 41 20 JSR $2041 ** 41="file A"
5650: 20 20 30 JSR $3020
5653: 32 KIL
5654: 31 9B AND ($9B),Y
5656: 00 BRK
5657: 00 BRK
-------------------------------------
5658: 01 00 ORA ($00,X)
565A: 80 00 NOP #$00
565C: 80 00 NOP #$00
565E: 80 00 NOP #$00
5660: 80 00 NOP #$00

3rd level loaded
5630: 60 RTS
5631: 82 6A NOP #$6A
5633: 76 04 ROR RAMLO,X
5635: 03 09 SLO ($09,X)
5637: 0E 0D 00 ASL DOSINI+1
563A: 0C 05 06 NOP $0605
563D: 02 KIL
563E: 0F 0B 0A SLO $0A0B
5641: 08 PHP
5642: 01 07 ORA ($07,X)
-------------------------------------
5644: 20 20 53 JSR $5320
5647: 4D 41 50 EOR $5041
564A: 20 20 20 JSR $2020
564D: 20 42 20 JSR $2042 ** 42="file B"
5650: 20 20 30 JSR $3020
5653: 32 KIL
5654: 31 9B AND ($9B),Y
5656: 00 BRK
5657: 00 BRK
-------------------------------------
5658: 01 00 ORA ($00,X)
565A: 80 00 NOP #$00
565C: 80 00 NOP #$00
565E: 80 00 NOP #$00
5660: 80 00 NOP #$00

4th level should be loaded... but returned to inbuilt 1st level - note: has 150 fuel in game so is 4th level.
5630: 60 RTS
5631: 82 6A NOP #$6A
5633: 76 04 ROR RAMLO,X
5635: 03 09 SLO ($09,X)
5637: 0E 0D 00 ASL DOSINI+1
563A: 0C 05 06 NOP $0605
563D: 02 KIL
563E: 0F 0B 0A SLO $0A0B
5641: 08 PHP
5642: 01 07 ORA ($07,X)
-------------------------------------
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

-------------------------------------
5658: 01 00 ORA ($00,X)
565A: 80 00 NOP #$00
565C: 80 00 NOP #$00
565E: 80 00 NOP #$00
5660: 80 00 NOP #$00

:)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

-------------------------------------

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 by slx
Link to comment
Share on other sites

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.

  • Like 2
Link to comment
Share on other sites

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.

  • Like 2
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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 :ponder: will try this :) [same]

Edited by therealbountybob
Link to comment
Share on other sites

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 :ponder: 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!

  • Like 1
Link to comment
Share on other sites

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

  • Like 3
Link to comment
Share on other sites

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:

 

post-16447-0-11965200-1483724701_thumb.png

 

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.

 

Link to comment
Share on other sites

Thanks Paul :thumbsup: :thumbsup: 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 by therealbountybob
  • Like 2
Link to comment
Share on other sites

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

  • Like 2
Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...