7

Do questions like these belong on Retrocomputing?

It looks to me like questions like this should be on Stack Overflow. They are about how to program on a specific assembler language. Just because it happens to be an old language...

I think it's one thing to ask about how the CPU architecture works, in which case they would clearly fit. But these questions are about the syntax of intel ASM86 and a general misunderstanding about how machine code works.

Or maybe it's just because I'm used to seeing such questions in Stack Overflow. Obviously, the community decides.

  • 1
    For what it's worth, both of these questions would be on-topic for Stack Overflow. However, just because a question is on topic for one site in the network doesn't necessarily mean they're off-topic for other sites. I'm not a very experienced user here on Retrocomputing, so far be it for me to make statements about what is or is not on topic, but logically, both of these questions seem completely topical, as they concern programming a clearly vintage machine. The fact that the underlying x86 ISA has remained largely compatible to this day doesn't make MS-DOS or the 8088 any less retro! – Cody Gray Jun 9 '17 at 8:14
  • 1
    It seems to me the real question is whether retro programming questions in general are on-topic. Programming for MS-DOS is just as retro a programming for a Commodore 64. It wouldn't make sense to prohibit questions about the former while allowing questions about the later. – Ross Ridge Jun 9 '17 at 16:39
  • Probably no one on SO will be able to answer the question how to create a .com file on x86. – tofro Sep 12 at 13:52
5

The two questions that you mention could be taken differently.

The mechanism of writing to video memory was not always obvious on retrocomputers. The format of data could also be less than clear. So in this case, a question regarding technique is suitable here.

Why is my JMP not working is more problematic. The bug in that question could be introduced in a similar way in a modern processor. Although I suspect most modern assemblers would pick up the difference between code and data. If the wording of the question specifically related to understanding some feature of old assemblers that is different to modern practice then it would be on topic. However, I don't believe we should be a debugging service.

We have questions on the site regarding the instruction sets of older generation processors. These don't ask for fixing a specific program but for understanding of the operation of certain instructions. Perfectly good for the site and its future readers.

"Write my code for me" is off-topic on most StackExchange sites, including StackOverflow. If that is the limit of the extent of a question, I suggest that it should also be off-topic here.

  • "Although I suspect most modern assemblers would pick up the difference between code and data." Hah! Not even close. Never seen one that would. A modern disassembler probably would (DOS's debug includes a disassembler, but it is extremely unsophisticated), and maybe that's what you meant, but that's not applicable to the question, since he isn't running the code through a disassembler. – Cody Gray Jun 9 '17 at 8:15
  • "The bug in that question could be introduced in a similar way in a modern processor." Yes, the x86 ISA has remained almost 100% backwards compatible for more than 30 years. That's a pretty incredible feat of engineering and strength of will, but I don't think that's sufficient grounds to say 8088/8086 programming questions are off-topic for a retro-computing site. These processors are clearly retro. A question can be on-topic for both Stack Overflow and other sites. In fact, retro-programming questions are never off-topic for Stack Overflow, but this site still exists! – Cody Gray Jun 9 '17 at 8:17
  • The assemblers that I use today will flag a warning if you try to put data in a code segment - I assumed that was normal nowadays. I didn't say that programming questions are off-topic here, I simply suggest that we apply the same criteria as StackOverflow, SuperUser and the rest. – Chenmunka Jun 9 '17 at 8:31
  • Are these x86 assemblers? I don't see how it would possibly tell whether, e.g., a DB directive was meant to define code or data. They're just bytes, after all. – Cody Gray Jun 9 '17 at 12:12
  • I don't believe we should be a debugging service. Exactly. – Leo B. Jun 10 '17 at 0:32
  • @CodyGray The assembler in the question is clearly x86. The registers, int instruction and the syntax of segment:address in the jump are all 8086. – JeremyP Jun 14 '17 at 13:59
  • @JeremyP That wasn't what I asked. I know exactly what architecture the original question was targeting. You jumped into the discussion without reading the full context. Chenmunka says in his answer that "modern assemblers would pick up the difference between code and data". I contested that assertion, since I've never seen an assembler that does this. Chenmunka said that those he uses does have a warning for this, so I supposed that these must not be x86 assemblers, since that's the architecture I'm most familiar with, and I've never seen an x86 assembler that does this, modern or not. – Cody Gray Jun 15 '17 at 12:14
  • @CodyGray Apologies, you are right I got the context wrong. As for the actual point, I would be very surprised if an assembler flagged data in the code segment as "not code". A constant literal string, for example, is a legitimate piece of data to put in a code segment. – JeremyP Jun 16 '17 at 8:51
3

I would agree with the statement "This site should not be a venue for fielding x86 programming questions". However, the two examples of actual questions seem much more about "retro-programming" on "retro-computers" than x86 programming.

The one about the jmp instruction is asked in the context of using a legacy assembler included with MS-DOS. The problem turned out to be a trivial programming error, but someone attempting similar things on unfamiliar retro platforms could have just as easily encountered a problem more related to the old technology that they were interacting with - making it relevant for this site.

The question about accessing video memory was kind of naive, in that the OP seemed to think something more complex than a hard-coded address reserved in the memory map was at issue. I think a really descriptive answer for that could have expanded on the simplicity of early PC's, and their lack of any sophisticated protocol for assigning hardware resources, like memory space, to peripherals during system boot.

To some extent, at least, it is up to those posting answers to expand on the topic enough that the answer is both complete and also educational from the angle of understanding the retro-tech. That care and attention will make for better answers and a more useful site, I think.

2

In my opinion - First one is on topic, because it asks about something in a retro operating system, that can't be, or at least can't be easily replicated in another OS. None other site is more on topic about MS-DOS than ours, so it's on-topic.

The second question though.. It asks about a problem that can be replicated on a modern OS without emulation. Even if it shows that it doesn't work in retro operating system(DOS), it still won't work in any other OS as well. This question can be as well moved to another page like Stack Overflow, and it may benefit from the move.

2

Personally I still have a hard time to think of PCs as retro, but they are. Just because something targets x86 doesn't make therefor it off topic. It's all about the usage framwork the question belongs to. Asking a questiom in a comunity like Retrocomputing already shows that the poster isn't ecactly asking for the latest protocoll to transfer a stereo image over PCI to some 3D goggles.

Without further information I would always assume that such questions are ment to reside in a basic, 16 bit x86 environment. Even thru there are many similarities between an 8086 and a x86-64 capable Opteron, they are quite distinctive environments with different answers.

Just imagine a question about the best way to multiply an integer value by 5. For modern x86 the answer is clear: LEA will do the trick with a scaling factor of 4 and twice the source register. Just, prior to the 80386, LEA didn't have teh scaling ability. So I'd answer the same question in Retrocomputing with a combination of move, shift and add.

So, as hard as it feels, x86 is on topic for Retrocomputing and different from Stack Overflow.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .