News for hackers. Stuff that matters.
Re:Microsoft GW-Basic Interpreter Source Code by unfocussed_mike on Monday March 07, 2022 @12:12PM (#30590409)
Yes.

There's an even more extraordinary story about them travelling to demonstrate their implementation of BASIC to the MITS team.

They realise they have not written a bootloader for the Altair, and Allen writes out a bootloader on the plane, which works when they get to MITS.

https://en.wikipedia.org/wiki/Altair_BASIC#Origin_and_develo...

My first encounter with a real Microsoft BASIC wasn't for another 15 years; the interpreter-only QBASIC that came with Halvorson & Rygmyr's Learn BASIC Now, which was a great book I gave away and now feel the urge to repurchase for nostalgia's sake. I used it for my GCSE Computer Science project.

Re:Microsoft GW-Basic Interpreter Source Code by WalterBright on Monday March 07, 2022 @02:13PM (#30592024)
Writing an 8080 emulator on the -10 is not extraordinary, after all, it's a trivial instruction set.

What was extraordinary is Allen realizing he could do this as a shortcut.

Re:Microsoft GW-Basic Interpreter Source Code by WalterBright on Monday March 07, 2022 @02:41PM (#30592396)
An 8080 has what, 40 opcodes? All doing simple things like "add" and "mov".

https://altairclone.com/downloads/manuals/8080%20Programmers...

Re:Microsoft GW-Basic Interpreter Source Code by phkahler on Monday March 07, 2022 @03:19PM (#30592803)
I learned on an 8080 system (Interact) that also had MS basic. Almost every one of 256 op-codes is used on the 8080. That's not to say there were that many instructions. For example register-to-register move might be considered one instruction but the source and destination register are encoded into that one byte so there are many reg-reg moves. Same with add sub, etc... My father wrote a disassembler in basic to read out the ROM and he made his own mnemonics which amounted to probably 20-40 actual instructions (I still have it and could look it up), but there were maybe 8 entries in the opcode table that did nothing.
Re:Microsoft GW-Basic Interpreter Source Code by WalterBright on Monday March 07, 2022 @05:02PM (#30593902)
https://pastraiser.com/cpu/i8080/i8080_opcodes.html

As a pragmatic manner, I don't regard having the register and/or addressing mode encoded into the opcode as a separate opcode.

Emulating a modern 64 bit processor would be a major chunk of work, but the old 8 bit ones are simple.

Re:Microsoft GW-Basic Interpreter Source Code by phkahler on Monday March 07, 2022 @08:16PM (#30595391)
If we exclude addressing mode then I think there are less than 26 instructions. Our mnemonic format was one letter (verb/op), one for source (a,b,c,d,e,h,l,w,x,y) and one for destination. I dont recall the letter for immediate, probably i but MIA for move immediate to a doesnt ring a bell for me. :-)
Re:Microsoft GW-Basic Interpreter Source Code by billforsternz on Monday March 07, 2022 @06:36PM (#30594774)
Yes, around 8 spare opcodes, and they were the ones Zilog used to escape into a large set of extensions for the (backwardly compatible to 8080) Z80.
Re:Microsoft GW-Basic Interpreter Source Code by phkahler on Monday March 07, 2022 @08:17PM (#30595400)
Can a Z80 be dropped into an 8080A socket? I'm thinking there were hardware differences.
Re:Microsoft GW-Basic Interpreter Source Code by billforsternz on Monday March 07, 2022 @10:32PM (#30596128)
No absolutely not. 8080 was a 3 chip solution from memory. The 8085 was, like a Z80, a 40 pin DIP, but even here the compatibility was strictly software not hardware. And in fact the software compatibility was a little less than 100% because Zilog decided to add an overflow flag by changing the 8080/8085 parity flag to actually reflect overflow instead of parity on arithmetic instructions.
Re:Microsoft GW-Basic Interpreter Source Code by pieter_mj on Monday March 07, 2022 @12:40PM (#30590863)
Interesting! Could you explain in a bit more detail how you used it for your CS project?
Re:Microsoft GW-Basic Interpreter Source Code by unfocussed_mike on Monday March 07, 2022 @01:28PM (#30591460)
Oh I just mean, QBasic was the language I used for that project.

I can't actually remember it in detail now, but this was when I was 15 or 16. It was a database application; I guess mine would have been music lending.

I wonder if I still have the code. I definitely still wish I had the book.

I really enjoyed QBASIC because of the gentle way you were exposed to better programming practices; I've always admired that.

Five or six years later, my uni project was a BASIC-to-C transpiler for a simple dialect of BASIC as a teaching language with some specific language extensions for message-passing parallel programming. It had a simple IDE, too.

In some ways it is a shame BASIC itself is really gone; modern implementations only have a whisper of its original simplicity.

Re:Microsoft GW-Basic Interpreter Source Code by pjmlp on Monday March 07, 2022 @05:06PM (#30593957)
Python seems to have taken its place, specially with all school calculators having some variant of MicroPython.

It isn't the same thing though.

Re:Microsoft GW-Basic Interpreter Source Code by unfocussed_mike on Monday March 07, 2022 @06:41PM (#30594804)
Yes -- I think sort of the most basic BASIC programming is done with Scratch, and then they graduate to Python.

In the UK I gather kids are taught Scratch and Python in an overlapping fashion, so they see the structure on the Scratch view and then have a better chance of understanding how the code works without being thrown off by the symbols.

This is probably better in a pedagogical sense, and I am sure Scratch programmers have a better early understanding of flow control and things like loop termination conditions than BASIC programmers did; Scratch makes it more physical.

But it does lose that absolute immediacy of being able to type simple words onto an empty screen and see it do things.

Re:Microsoft GW-Basic Interpreter Source Code by zozbot234 on Monday March 07, 2022 @08:53PM (#30595622)
Scratch and especially Python are a lot more complex than BASIC. OTOH, Scratch having a structural rather than solely text-based interface might also make a more complex language immediately usable, by removing the difficulty associated with keywords and surface syntax. This is the kind of thing that would really benefit from a well-designed usability experiment.