10-25-2019, 03:40 PM (This post was last modified: 10-25-2019 10:01 PM by Dave Britten.)
Post: #1
 Dave Britten Senior Member Posts: 1,179 Joined: Dec 2013
This program performs a few specific IP address/subnet calculations:

1. Convert a subnet mask to the corresponding CIDR suffix, and vice versa (e.g. 255.255.0.0 <-> /16)
2. Calculate the total number of host addresses available for a given subnet mask

Usage

XEQ "IPADR" to start the program. All functions are carried out from a single menu.

The "ADDR", "MASK", and "CIDR" keys allow for entry or calculation/display of the IP address, subnet mask, or CIDR suffix respectively. These work like typical solver menu keys. When pressed after entering data, they store the value. When pressed without data, they calculate/display the result.

To enter an IP address or subnet mask, use all four levels of the stack to enter an address. Essentially, you press ENTER instead of putting decimal points between the bytes. T should contain the first byte (0-255), Z the second byte, and so on.

The subnet mask and CIDR suffix will be automatically calculated whenever the other is entered. CIDR will only be calculated if all 1 bits in the subnet mask are left-aligned. In cases where the subnet mask is not left-aligned (e.g. 255.0.255.0), CIDR will be shown as 0.

Calculating "HOSTS" requires entry of either "MASK" or "CIDR".

Calculating "NET" or "BCST" requires entering "ADDR" and either "MASK" or "CIDR". Note that these can still be calculated normally even if you enter a network or broadcast address for "ADDR". You don't have to enter a host address.

Examples

1. Calculate the CIDR suffix that corresponds to the subnet mask 255.255.240.0.

["CIDR"] : CIDR=20

2. Calculate the subnet mask for the CIDR suffix /18.

18 ["CIDR"] : CIDR=18

3. Determine the number of possible hosts on a network with subnet mask 255.255.254.0.

255 [ENTER] [ENTER] 254 [ENTER] 0 : MASK=255.255.254.0
["HOSTS"] : HOSTS=510

22 ["CIDR"] : CIDR=22
["NET"] : NET=172.16.0.0
["BCST"] : BCAST=172.16.3.255

Program Code

Code:
00 { 446-Byte Prgm } 01▸LBL "IPADR" 02 CLMENU 03 "ADDR" 04 KEY 1 XEQ 01 05 "MASK" 06 KEY 2 XEQ 02 07 "CIDR" 08 KEY 3 XEQ 03 09 "HOSTS" 10 KEY 4 XEQ 04 11 "NET" 12 KEY 5 XEQ 05 13 "BCST" 14 KEY 6 XEQ 06 15▸LBL 00 16 MENU 17 STOP 18 GTO 00 19▸LBL 01 20 FC?C 22 21 GTO 11 22 XEQ 10 23 STO 01 24 XEQ 30 25 STO 02 26▸LBL 11 27 "ADDR=" 28 RCL 01 29 XEQ 40 30 AVIEW 31 RTN 32▸LBL 02 33 FC?C 22 34 GTO 12 35 XEQ 10 36 STO 03 37 XEQ 30 38 STO 04 39 0 40 STO 05 41 R↓ 42 NOT 43 XEQ 50 44 1 45 + 46 LOG 47 2 48 LOG 49 ÷ 50 1ᴇ-9 51 + 52 ENTER 53 FP 54 2ᴇ-9 55 X<Y? 56 GTO 12 57 R↓ 58 R↓ 59 IP 60 32 61 X<>Y 62 - 63 STO 05 64▸LBL 12 65 "MASK=" 66 RCL 03 67 XEQ 40 68 AVIEW 69 RTN 70▸LBL 03 71 FC?C 22 72 GTO 13 73 STO 05 74 32 75 X<>Y 76 - 77 2 78 X<>Y 79 Y↑X 80 1 81 - 82 NOT 83 XEQ 50 84 STO 04 85 XEQ 31 86 STO 03 87▸LBL 13 88 "CIDR=" 89 RCL 05 90 AIP 91 AVIEW 92 RTN 93▸LBL 04 94 RCL 04 95 NOT 96 XEQ 50 97 1 98 X<>Y 99▸LBL 14 100 ENTER 101 ENTER 102 2 103 MOD 104 1 105 + 106 STO× ST Z 107 R↓ 108 2 109 ÷ 110 IP 111 X>0? 112 GTO 14 113 R↓ 114 2 115 - 116 "HOSTS=" 117 ARCL ST X 118 AVIEW 119 RTN 120▸LBL 05 121 RCL 02 122 RCL 04 123 AND 124 XEQ 31 125 "NET=" 126 XEQ 40 127 AVIEW 128 RTN 129▸LBL 06 130 RCL 02 131 RCL 04 132 AND 133 RCL 04 134 NOT 135 XEQ 50 136 OR 137 XEQ 31 138 "BCAST=" 139 XEQ 40 140 AVIEW 141 RTN 142▸LBL 10 143 STO 06 144 R↓ 145 1ᴇ3 146 × 147 STO+ 06 148 R↓ 149 1ᴇ6 150 × 151 STO+ 06 152 R↓ 153 1ᴇ9 154 × 155 RCL 06 156 + 157 RTN 158▸LBL 30 159 1ᴇ3 160 STO 07 161 R↓ 162 256 163 STO 08 164 R↓ 165 GTO 32 166▸LBL 31 167 256 168 STO 07 169 R↓ 170 1ᴇ3 171 STO 08 172 R↓ 173▸LBL 32 174 3ᴇ-3 175 STO 00 176 R↓ 177 0 178 STO 06 179 R↓ 180▸LBL 33 181 ENTER 182 ENTER 183 RCL 07 184 MOD 185 RCL 08 186 RCL 00 187 IP 188 Y↑X 189 × 190 STO+ 06 191 R↓ 192 RCL 07 193 ÷ 194 IP 195 ISG 00 196 GTO 33 197 RCL 06 198 RTN 199▸LBL 40 200 ENTER 201 ENTER 202 1ᴇ9 203 ÷ 204 XEQ 41 205 ├"." 206 XEQ 41 207 ├"." 208 XEQ 41 209 ├"." 210 XEQ 41 211 R↓ 212 RTN 213▸LBL 41 214 AIP 215 FP 216 1ᴇ3 217 × 218 RTN 219▸LBL 50 220 2 221 32 222 Y↑X 223 1 224 - 225 AND 226 END

10-25-2019, 05:49 PM
Post: #2
 Luigi Vampa Member Posts: 234 Joined: Dec 2015
Thanks for sharing, Dave.

Saludos Saluti Cordialement Cumprimentos MfG BR + + + + +
Luigi Vampa +
Free42 HuaweiP10 '<3' I + + +
10-25-2019, 08:56 PM (This post was last modified: 10-25-2019 08:57 PM by cdmackay.)
Post: #3
 cdmackay Senior Member Posts: 385 Joined: Sep 2018
Thanks very much for this, Dave.

Is there any reason why it might not work on a DM42? Is it dependent on any particular settings?

I enter:

192 ENTER 168 ENTER 2 ENTER 1 ADDR

and get:

T: 0.0000
Z: 8.0000
Y: 8.0000
X: 8.0000

Am I doing something stupid?

thanks.

Cambridge, UK
41CL 12/15C DM15/16 71B 17B/BII/bII+ 28S 42S/DM42 48GX 50g 35s 30b/WP34S Prime G2
& Casios, Rockwell 18R :)
10-25-2019, 09:34 PM
Post: #4
 Dave Britten Senior Member Posts: 1,179 Joined: Dec 2013
(10-25-2019 08:56 PM)cdmackay Wrote:  Thanks very much for this, Dave.

Is there any reason why it might not work on a DM42? Is it dependent on any particular settings?

I enter:

192 ENTER 168 ENTER 2 ENTER 1 ADDR

and get:

T: 0.0000
Z: 8.0000
Y: 8.0000
X: 8.0000

Am I doing something stupid?

thanks.

Hmm, it SHOULD work; I've run it on both my 42S and DM42. Let me take another look at the code and see if there's anything flag-dependent that's not obvious at first.
10-25-2019, 09:39 PM
Post: #5
 rprosperi Senior Member Posts: 3,621 Joined: Dec 2013
1st, thanks Dave, this is not only interesting but also very useful!

2nd, cd is right, something is amiss with the .raw file. I imported it into Free42, did XEQ "IPADR", but when then following the examples, get incorrect results.

Feasibly an issue with Free42, but highly unlikely. Is the provided file the correct version?

--Bob Prosperi
10-25-2019, 09:47 PM
Post: #6
 rprosperi Senior Member Posts: 3,621 Joined: Dec 2013
(10-25-2019 09:39 PM)rprosperi Wrote:  Feasibly an issue with Free42, but highly unlikely. Is the provided file the correct version?

The .raw file differs with the listing file beginning at line 22 (XEQ 13 vs. XEQ 10). Not sure which is correct, so I'll let you decide.

--Bob Prosperi
10-25-2019, 10:05 PM (This post was last modified: 10-25-2019 10:14 PM by Dave Britten.)
Post: #7
 Dave Britten Senior Member Posts: 1,179 Joined: Dec 2013
Well this is bizarre! There are a couple places in the program that are supposed to be XEQ 10, but somehow that step has been replaced with XEQ 13 LBL 9 in both cases. Some kind of Free42 bug perhaps? A fresh copy of the raw file from my DM42 is 2 bytes smaller than the raw file exported from Free42 2.5.10.

The code listing appears correct, and it runs fine on Free42 after importing the raw file from my DM42, so I think the issue only affects exporting programs.

I've uploaded a fresh copy of the raw file taken directly from my DM42 and not modified/exported in Free42 on my computer. I also took the liberty of making the left-aligned subnet mask detection a bit more reliable. Reimport the updated raw file (or key in the code changes) and you should be good to go.

EDIT:

Enter this tiny program in Free42 2.5.10:

LBL "TEST"
XEQ 10
END

Export it and reimport it, and suddenly it becomes this:

LBL "TEST"
XEQ 13
LBL 9
END

And it's reported as being one byte larger. I've emailed Thomas, so no need to storm his inbox with additional bug reports.
10-25-2019, 10:27 PM
Post: #8
 cdmackay Senior Member Posts: 385 Joined: Sep 2018
(10-25-2019 10:05 PM)Dave Britten Wrote:  I've uploaded a fresh copy of the raw file taken directly from my DM42 and not modified/exported in Free42 on my computer.

yup, perfect now, thanks Dave. And thanks again, this one really is useful; I load lots of fun things onto my DM42, but not all of them are actually useful

Cambridge, UK
41CL 12/15C DM15/16 71B 17B/BII/bII+ 28S 42S/DM42 48GX 50g 35s 30b/WP34S Prime G2
& Casios, Rockwell 18R :)
10-25-2019, 11:28 PM
Post: #9
 rprosperi Senior Member Posts: 3,621 Joined: Dec 2013
Thanks for the rapid analysis and fix!

So, guessing the issue is not in Free42, typically a safe bet, turned out to be a bad guess. The bug is quite odd, I'm curious to hear from Thomas what that's all about.

Thanks Dave!

--Bob Prosperi
10-26-2019, 12:03 AM
Post: #10
 Dave Britten Senior Member Posts: 1,179 Joined: Dec 2013
(10-25-2019 11:28 PM)rprosperi Wrote:  Thanks for the rapid analysis and fix!

So, guessing the issue is not in Free42, typically a safe bet, turned out to be a bad guess. The bug is quite odd, I'm curious to hear from Thomas what that's all about.

Thanks Dave!

To quote the pertinent part of Thomas' email reply:

Quote:fopen(filename, "w") instead of fopen(filename, "wb")

So there was inappropriate CR/LF translation happening in binary data, which I should have immediately guessed upon seeing that the issue involved 10 and 13 and an increase in 1 byte per occurrence.

Thomas already has 2.5.11 uploaded on his site, and the release notes suggest this bug only affected the Windows version.
10-26-2019, 01:07 AM
Post: #11
 rprosperi Senior Member Posts: 3,621 Joined: Dec 2013
(10-26-2019 12:03 AM)Dave Britten Wrote:  So there was inappropriate CR/LF translation happening in binary data, which I should have immediately guessed upon seeing that the issue involved 10 and 13 and an increase in 1 byte per occurrence.

Good eye, noting the 13/10 relevance. I looked up the extra LBL 09, which is 0x0A, but couldn't figure how the XEQ 10 became 13. Like most issues, it's totally clear once you see the answer. :-)

--Bob Prosperi
10-26-2019, 01:46 AM (This post was last modified: 10-26-2019 07:04 PM by Thomas Okken.)
Post: #12
 Thomas Okken Senior Member Posts: 887 Joined: Feb 2014
(10-26-2019 01:07 AM)rprosperi Wrote:
(10-26-2019 12:03 AM)Dave Britten Wrote:  So there was inappropriate CR/LF translation happening in binary data, which I should have immediately guessed upon seeing that the issue involved 10 and 13 and an increase in 1 byte per occurrence.

Good eye, noting the 13/10 relevance. I looked up the extra LBL 09, which is 0x0A, but couldn't figure how the XEQ 10 became 13. Like most issues, it's totally clear once you see the answer. :-)

Yes, when I saw Dave's email, I groaned because I knew right away what was wrong, and it's such a rookie mistake. Introduced, like annoyingly many other bugs, in Free42 2.5, when the logic that creates state and raw files was moved from the platform-specific shells into the portable core.

The LF-to-CRLF translation performed on files opened with fopen(filename, "w") happens only in Windows; on Unix-like operating systems, which is everything else, "w" behaves like "wb", and so raw files were always saved correctly on those platforms.
 « Next Oldest | Next Newest »

User(s) browsing this thread: 1 Guest(s)