One small correction here, but C does have complex numbers. They were added with C99 and have been expanded on in subsequent versions. You can actually declare and define a complex variable with: double complex c = 1.1 + 2.2 * I; and if you check with creal() and cimag() you can see that the real and imaginary parts match. (Note that the "I" in the assignment is the capital letter "i".)
I didn't realize they added that in C99 - thanks! It's been a while since I needed complex values in C, so that's new to me. (Last time was when I wrote an ASCII Mandelbrot generator, which only needed z^2 + c so I rolled my own struct and function for that.)
Given how narrow terminals were in the '70s, it's a truly unusual decision to have interesting lines waste 5 blank columns at their start ... Any idea what's behind that design choice?
As user-jm3xl7rg5k said, this comes from punched cards. And punched cards had 80 columns, so that's where that comes from. Here's what it says in the FORTRAN 77 FIPS standard: (summarized) →A comment line has C or * in column 1 →An initial line (the start of a regular instruction) is any non-comment line that has a blank or the digit 0 in column 6. (I knew I remembered that "0" rule from somehere!) Initial lines may have numbers in cols 1-6 as a line label. →A continuation line (glued onto the previous initial line, or another previous continuation line) is any non-comment line that has any valid character (other than 0) in column 6. So I guess you could have A or Z in there too. (In practice, programmers used + or $ or a non-zero digit like 1, 2, 3, 4..) Continuation lines may not have numbers in cols 1-6, because continuation lines cannot have labels. →Program statements can only be written in cols 7-72. (Cols 73-80 were used for a special machine that could sort punched cards, like if you dropped your box of punched cards and needed to put them back into some kind of order.) If you had a really long instruction that wouldn't fit into cols 7-72 (like if your instruction requires 100 characters) you can add a continuation line. And because FORTRAN is not space sensitive, you can actually break a line in the middle of a variable name and that's fine. Although for readability, you'd want to break the line somewhere else. I'll do a video sometime where I "abuse" the continuation marker, just to show how that works. 😛
@@freedosproject Wowza! I remember you said that it's not sensitive to spacing ... but I didn't realise that you could break lines in the middle of a token ... That must be a very special parser -- probably hand-coded (I think Yacc / similar existed by then?!), too.
I hope there will be in the series a way to use Fortran programs from C. For example, you construct the program interface in C (wcl) using the Watcom graph library facilities, but you do all the calculations in Watcom fortran (wfl).
I hadn't thought about that, but there's OpenWatcom C and OpenWatcom FORTRAN (both in the FreeDOS 1.3 distro) so this should be easy. I'll look into it and see if I can cover that in a later video.
Like any DOS, FreeDOS requires an Intel-compatible CPU and a BIOS. ARM systems are a completely different architecture; not an Intel CPU, and no BIOS. Even if you wrote a "DOS-like" system for ARM, I doubt any DOS programs would run on it. DOS applications access hardware directly (like BIOS calls) and that won't work on ARM.
@@freedosproject Still, I have read that Microsoft managed to create a translation layer, in their Windows 11 for ARM, still in an experimental state, but it works. I imagine it would not be impossible to create a bootable system, as an intermediary, simulating Bios, to translate the binary commands needed by ARM systems. And thus not having to use a Virtual PC that consumes many resources.
If you're using the code presented at 11:18, that compiles and runs fine on my GFortran on Linux. Here's the code: (leading spaces stripped because of RUclips comments) PROGRAM CIRCLE REAL AREA,R PARAMETER(PI=3.141592) R=1.0 AREA = PI*R*R PRINT *,AREA END
It's possible that the program overflowed the AREA variable. The spec says that when you define a variable, it just gets whatever value is in memory at the time. You're always supposed to give the variable a value on your own. So if the bit pattern in memory was a very large REAL value, then R would be very very big. If you square it and multiply by PI (AREA = PI * R * R) then you could overflow the AREA variable, which would be why the PRINT statement says "Infinity." The next demo in the video gives R an initial value, which is what you should do.
![Kodak Black - Catch Fire [Official Music Video]](http://i.ytimg.com/vi/A4ch-olIuZo/mqdefault.jpg)
Amazing !!! Thanks a lot Tim for this Fortran 77 programming videos series. FreeDos for ever!!!
Glad you like it!
I really love your videos. They are super chill and educational!
Thanks! 👍
One small correction here, but C does have complex numbers. They were added with C99 and have been expanded on in subsequent versions. You can actually declare and define a complex variable with: double complex c = 1.1 + 2.2 * I; and if you check with creal() and cimag() you can see that the real and imaginary parts match. (Note that the "I" in the assignment is the capital letter "i".)
I didn't realize they added that in C99 - thanks! It's been a while since I needed complex values in C, so that's new to me. (Last time was when I wrote an ASCII Mandelbrot generator, which only needed z^2 + c so I rolled my own struct and function for that.)
Thanks for the video!
Given how narrow terminals were in the '70s, it's a truly unusual decision to have interesting lines waste 5 blank columns at their start ... Any idea what's behind that design choice?
This all came from 80column punch cards.
As user-jm3xl7rg5k said, this comes from punched cards. And punched cards had 80 columns, so that's where that comes from.
Here's what it says in the FORTRAN 77 FIPS standard: (summarized)
→A comment line has C or * in column 1
→An initial line (the start of a regular instruction) is any non-comment line that has a blank or the digit 0 in column 6. (I knew I remembered that "0" rule from somehere!) Initial lines may have numbers in cols 1-6 as a line label.
→A continuation line (glued onto the previous initial line, or another previous continuation line) is any non-comment line that has any valid character (other than 0) in column 6. So I guess you could have A or Z in there too. (In practice, programmers used + or $ or a non-zero digit like 1, 2, 3, 4..) Continuation lines may not have numbers in cols 1-6, because continuation lines cannot have labels.
→Program statements can only be written in cols 7-72. (Cols 73-80 were used for a special machine that could sort punched cards, like if you dropped your box of punched cards and needed to put them back into some kind of order.)
If you had a really long instruction that wouldn't fit into cols 7-72 (like if your instruction requires 100 characters) you can add a continuation line. And because FORTRAN is not space sensitive, you can actually break a line in the middle of a variable name and that's fine. Although for readability, you'd want to break the line somewhere else. I'll do a video sometime where I "abuse" the continuation marker, just to show how that works. 😛
@@freedosproject Wowza! I remember you said that it's not sensitive to spacing ... but I didn't realise that you could break lines in the middle of a token ... That must be a very special parser -- probably hand-coded (I think Yacc / similar existed by then?!), too.
I love these videos! ❤
Glad you like them! I am planning several other F77 videos, coming soon!
I hope there will be in the series a way to use Fortran programs from C. For example, you construct the program interface in C (wcl) using the Watcom graph library facilities, but you do all the calculations in Watcom fortran (wfl).
I hadn't thought about that, but there's OpenWatcom C and OpenWatcom FORTRAN (both in the FreeDOS 1.3 distro) so this should be easy. I'll look into it and see if I can cover that in a later video.
Is there a project to make FreeDOS compatible with ARM processors?
Like any DOS, FreeDOS requires an Intel-compatible CPU and a BIOS. ARM systems are a completely different architecture; not an Intel CPU, and no BIOS.
Even if you wrote a "DOS-like" system for ARM, I doubt any DOS programs would run on it. DOS applications access hardware directly (like BIOS calls) and that won't work on ARM.
@@freedosproject Still, I have read that Microsoft managed to create a translation layer, in their Windows 11 for ARM, still in an experimental state, but it works. I imagine it would not be impossible to create a bootable system, as an intermediary, simulating Bios, to translate the binary commands needed by ARM systems. And thus not having to use a Virtual PC that consumes many resources.
@@dariob833 We need open X86
@@dariob833Unfortunately, there's a significant scope difference here; what you're describing is essentially DOS in a VM that supports JIT.
@@zombie_pigdragon Ok Thank =)
I have no interest in FORTRAN but wow this is interesting stuff!
Thanks! 👍
I did the area tutorial on Linux and it gave me the string "Infinity." Very bizarre.
If you're using the code presented at 11:18, that compiles and runs fine on my GFortran on Linux. Here's the code: (leading spaces stripped because of RUclips comments)
PROGRAM CIRCLE
REAL AREA,R
PARAMETER(PI=3.141592)
R=1.0
AREA = PI*R*R
PRINT *,AREA
END
It's possible that the program overflowed the AREA variable. The spec says that when you define a variable, it just gets whatever value is in memory at the time. You're always supposed to give the variable a value on your own. So if the bit pattern in memory was a very large REAL value, then R would be very very big. If you square it and multiply by PI (AREA = PI * R * R) then you could overflow the AREA variable, which would be why the PRINT statement says "Infinity."
The next demo in the video gives R an initial value, which is what you should do.
Maybe I missed something, but you forgot to explicitly mention that arrays in Fortran are 1-based, not 0-based, which is very unusual these days.
I can't believe I forgot to mention that. Yes, that's a very big point: FORTRAN arrays start at 1, not 0.