Isn't that the right DOSBOX behavior? I think it should maintain the original aspect ratio as it looked in the old CRT monitors. I remember drawing circles in CRT monitors on IBM PCs and the circles did look vertically squished. Why should DOSBOX or FFMPEG alter that original aspect ratio? Altering that artificially would be like lying about what the real output looked like in the good old days.
If you use DOSBox with default settings, the pixel aspect ratio will be square. Old PCs, as you remember, had non-square aspect ratios, and so the graphics will look incorrect, they will look squashed horizontally.
I am running DOSBox with default settings. I draw a square and then a circle with these lines of Logo code:
REPEAT 4 [FD 1 RT 90]
REPEAT 360 [FD 1 RT 1]
I find that both the square and the circle appear squashed. On measuring the pixel height and width of these figures as they appear on my desktop, I see that the square is 400 pixels in width and 320 pixels in height. That's an aspect ratio of 5:4. Similarly, the circle is 460 pixels in width and 364 pixels in height. That's an aspect ratio of 1.26:1.
I find the same aspect ratio in full screen (Alt + Enter) mode too. In the full screen mode, the square is 200 pixels in width and 160 pixels in height and the circle is 230 pixels in width and 182 pixels in height.
Edit the dosbox configuration file and change aspect=0 to aspect=1, it'll resize the output to be aspect correct but it might be a bit blurry (IIRC the scale3x scaler will do a pixel-scale and then that will be bilinearly resized, giving mostly crispy pixels with a bit of in-between bleeding which is probably the best you can get with an LCD monitor)
With aspect=1, the square is 400 pixels high and 384 pixels wide, not exactly an aspect ratio of 1:1 but quite close, 1.04:1.
The parent of my earlier comment, i.e., the one by klodolph, claims that the pixel aspect ratio would be square by default in DOSBox, so I thought I would verify it once. As per my experiments, that does not seem to be the case.
This is a misinterpretation of the experiment results.
By default, aspect=false. This gives incorrect results, as you observed, with Logo producing a squashed circle and square.
The fix is aspect=true (or aspect=1). This gives correct results, with non-square aspect for pixels, with Logo producing a more correct circle and square.
Because the Logo implementation was written for an actual IBM PC or compatible, it assumes that the aspect ratio of a 320x200 pixel screen is about 4:3. However, when displayed with the incorrect square-pixel aspect ratio given by default in DOSBox, it will be 8:5.
In other words, DOSBox displays graphics with a square pixel ratio by default, which is different from the original hardware. If you wrote a DOS program to draw a square number of pixels, say 128x128, then you would see that in DOSBox it would also be square, but on real hardware it would be about 20% taller than it is wide. If you use Logo you will get the opposite results, because Logo is correctly designed for the original hardware.
The pixels are square in DOSBox, but the graphics from these old programs are designed for non-square pixel ratio. So, if you display it with square pixel, the display aspect ratio will be wrong.
(Of course, this still contradicts with what
neatcoder said, but I can't remember if these programs were "squished" on CRTs or not.)
The one with aspect=1 looks incorrectly configured.
There are a number of different graphics modes, they have different pixel aspect ratios, you can also adjust the monitor, it is possible that back in school you were using a different mode or a different monitor. I think there are some other factors that can affect this.
The reason why I stick to aspect=0 (the DOSBox default) is that this is the one that more closely reproduces the experience I had with the CRT monitors at school. I agree that the actual monitor or the way it is configured could affect the aspect ratio we observe. Perhaps ours was not adjusted to produce 1:1 square while working with IBM Logo. But it did produce 1:1 square with GW-BASIC SCREEN 1 mode.
CGA/EGA/VGA is supposed to have a pixel aspect ratio of 1:1.2 in 320x200 mode. If you adjusted the monitor to give 1:1 square pixels, then this was unusual.
> Do aspect correction. It only affects non-square pixel modes like VGA Mode 13h, which has a resolution of 320x200 pixels and is used by many DOS games (DOOM, etc).
That mode is also non-square, with an aspect of 0.6:1. The IBM PC and its various video cards in the early days used a number of tricks to keep the cost down, one of those tricks is to keep the horizontal and vertical sync signals the same for different modes as much as possible. (Recently I’ve started to appreciate just how many tricks they used to keep the cost down, without sacrificing hardware reliability in the process!)
For both 320x200 and 640x200, HSYNC ran at 15.75 kHz, VSYNC ran at 60 Hz. When you go from 320x200 to 640x200, all that happens is the pixel clock (the rate at which you read out from RAM) is doubled, so you get exactly two pixels horizontally packed in where there used to be one pixel. The older hardware, like EGA video cards, can only generate one other HSYNC speed: 21.8 kHz, for special 350-line modes. When VGA came out, it doubled the HSYNC frequency and, for these modes, would just read each row out twice.
So SCREEN 1 should have 1.2:1 ratio, and SCREEN 2 should have a 0.6:1 ratio.
One of the better ways to verify this kind of thing is to compare box art from DOS video games to screenshots taken from DOSBox or sprites extracted from the data files. You can see that the screenshots from DOSBox match the sprite files, if you leave aspect unadjusted, but if you look at the box art from the retail packaging, you will (often) see artwork and screenshots with the correct aspect ratio, just like you see on real hardware.
That's not how I see it. Yes, the employer (the organization) may be psychopath but I am not interacting with an organization while having a difficult conversation. I would be interacting with a manager or a colleague or someone who reports to me. These are human beings who are not psychopath. These are also not short-termist. Sure, we would all change jobs sooner or later but I would sure like to maintain good relationships with them and hopefully work with them again in future. So it makes a lot of sense that while talking to them I talk to them with some empathy which I think they deserve.
I am a huge fan of NVC, and I agree most people are not psychopaths. Unfortunately, organizational structures can be such that decent people are forced to behave like psychopaths, and I don't think that NVC, at least not by itself, can fix that.
I think "Programming Languages: Application and Interpretation" does much of what you want: in particular, it takes the view that "from our perspective parsing is mostly a distraction, because we want to study the parts of programming languages that are not parsing." The author, Shriram Krishnamurthi, puts the complete text online for free at http://cs.brown.edu/courses/cs173/2012/book/
What sort of language are you interested in implementing? Once you've got past the lexing and parsing stages, the implementation strategy can be quite different for, say, a functional-style language and an imperative OO-style language, so it would be helpful to know more and then perhaps some of us could suggest suitable material.
Wow! Can you share your story more? What does your application do? Why did you choose BASIC 35 years ago? Did the question about rewriting it another language come up anytime? How did such discussions go? Do you enjoy writing BASIC code?
I've been with the company 20 years so wasn't involved in the original decision. I believe the company started out on PDP's before moving to MicroVAX (and later Alpha and Integrity). BASIC will likely have been the best fit at the time.
It is business software for the Agri industry, originally a terminal text entry system. Now we also have a web front end (running on Windows IIS, communicating to VMS/BASIC via Apache Tomcat/WSIT webservices).
We did try converting to VB6 back when it was a thing, but then .NET happened so we abandoned it as conversion to VB.NET wasn't so straight forward. A rewrite in C# was briefly considered before finally going for the web front end/web services option to avoid rewriting the BASIC business/data layer.
Sadly the application will go end of life in a couple of years, as we're now part of a larger corporation who have similar applications. Ours lost out due to the OpenVMS layer being a hard sell to new customers.
I've never really thought about when I enjoy it! It's mostly a data entry / reporting application, so generally not very exciting :)
Similar topics are coming up often on HN recently. I think it's time Markdown should be supported natively by browsers. Until then, there are things like:
TeXMe (https://github.com/susam/texme): This is my personal favorite because it supports the CommonMark standard of Markdown and also LaTeX via MathJax. I like standards so that I know that the Markdown I write (especially nested lists, code within nested lists, etc.) get rendered the same way everywhere. I write some math too, so MathJax support is useful. If you are looking for something where you can just slap together Markdown and LaTeX and turn the document instantly into a paper-like finish, this is a good choice. The output can be saved as PDF or printed too just like you would print any paper.
Markdeep (https://casual-effects.com/markdeep/): This is like TeXMe but it supports a lot of features like diagrams, tables, etc. But it comes at the cost of standard conformance. Markdeep does not conform to CommonMark. I don't need these additional features for most of my writing but I care about standard conformance, so I go with TeXMe but if you need these features then Markdeep is a good choice.
> I think it's time Markdown should be supported natively by browsers.
I'd rather have AsciiDoc become the default lightweight documentation format. Markdown suffers from competing standards regarding extensibility beyond basic formating, whereas AsciiDoc is a quite direct translation of the solid standard Docbook.
Extending Markdown to anything more complex than bold, italic or headers requires deciding among a number of competing tools with different syntax and installing them as extensions. AsciiDoc has features as tables, references, images or metadata integrated in the standard, and it has been designed for extensibility, while Markdown was not.
There is an advantage of using Markdown over AsciiDoc, which is that it is currently supported by a larger variety of tools. But that advantage is somewhat negated by its different and slightly incompatible flavors.
Does AsciiDoc have a nice way to ignore all LaTeX code enclosed within $...$ (inline math), $$...$$ (displayed math), \(...\) (inline math), and \[...\] (displayed math)?
I think one of the problems of Markdown is that it does not provide a way for the Markdown parser to ignore any text within certain delimiters (I especially care about ignoring text within Latex math delimiters). This is the most crucial reason why I am using tools like TexMe or Markdeep.
Is AsciiDoc better in this area? If yes, it would definitely solve a big problem for me that Markdown does not solve.
AFAIK there are several ways to embed LaTeX and mathematical formulas in AsciiDoc such as asciidoctor-latex [1] or ASCIIMathML and LaTeXMathML [2].
AsciiDoc also allows embedding literal paragraphs or blocks of text [3]. I think the mechanism of passthrough macros [4] can be used to copy raw text to the output and allow further processing down the pipeline, though I'm not sure how it's used.
It's plain text, would parse as valid Markdown for the most part but reads just fine - I didn't even realize that it was MD until someone mentioned it in the comments. Using
Underlined Text
===============
Works as an effective heading (# in MD)
Leaving some empty lines also helped in that txt file
* and these
* type of lists
* work just fine.
Why not just use a .txt file with two or three special format codes: one to make a URL clickable, one to embed an image (with a specified width, clicking goes to the full image), and (maybe? - this is getting kinda complex) one for math.
On the one hand there are barebones formats like what I described, and on the other there are complex ones like MD and the ones you linked to. The issue with all of the complex ones is that they provide leaky abstractions.
With MD you get a compiler that does MD->HTML, and you provide your own CSS file. OK, now you have a neat looking table. But what if you want to make a cell span two columns? You're screwed, you either need to look up complex nonstandard syntax for that (may as well use HTML at that point) or just convert the whole table into HTML (now you have 80% MD and 20% HTML in your file).
But if you have a .txt file, you just delete the | pipes you drew. Sure it's a bit more tedious, but it works and is 100% consistent.
And what if your CSS gives table header rows a yellow background, but you want one column of a specific table to be red? Again you need nonstandard syntax to mark that table with a class and link it to a CSS rule, or you just convert the whole thing to HTML and add an inline color="...". Leaky abstraction.
In this case a .txt helps by removing choice and placing limitations - you can format the whole document as a text file but with clickable links and inline images, and if you need more styling then you can use HTML. Or write in MD and compile into HTML, if that's what you want.
MD and its other formats are in a half-between position where you often use the abstraction but also occasionally have to fall down to the lower HTML level, and I just don't think that it deserves a place as a standard format for web browsers.
When we go from 2 pairs of rabbits to 3 pairs of rabbits, we see a brother and sister rabbit mating to produce a pair of offsprings. This does not sound realistic and could also be disturbing to kids.
But for some reason, I have seen this example cited in many places. Why is this example so popular despite the implication of siblings mating while going from 2 to 3? Surely, we can come up with better illustrations if we try!
