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,502 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 }
04 KEY 1 XEQ 01
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
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
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
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: 509 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/DM41X 12/15C/16C DM15/16 71B 17B/BII/bII+ 28S 42S/DM42 32SII 48GX 50g 35s 30b/WP34S Prime G2
& Casios, Rockwell 18R :)
10-25-2019, 09:34 PM
Post: #4
 Dave Britten Senior Member Posts: 1,502 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: 4,158 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: 4,158 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,502 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: 509 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/DM41X 12/15C/16C DM15/16 71B 17B/BII/bII+ 28S 42S/DM42 32SII 48GX 50g 35s 30b/WP34S Prime G2
& Casios, Rockwell 18R :)
10-25-2019, 11:28 PM
Post: #9
 rprosperi Senior Member Posts: 4,158 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,502 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: 4,158 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: 1,014 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)