ataylor284_

Commodore had bought out MOS by this point and manufactured 6502 chips themselves, so the drive CPU was "free" in a sense.

Also it's worth noting that the Commodore DOS talked about in the article was implemented and ran entirely on the drive, not the host computer. Commodore computers only understood a simple serial protocol and DOS commands like rename, delete or format disk were just sent as text commands on the serial command channel, which were interpreted and run by drive itself.

The computers had no concept of a filesystem at all: displaying the disk directory involved a hack where the drive would construct a fake BASIC program and stream it to the computer when a special filename "$" was loaded. That's why displaying the disk directory on a Commodore computer would clobber any BASIC program in RAM. A common blunder was to list the directory before saving and losing your work.

While the disk drives were smart, the tape drives were dumb. Tape drives came first and were designed along side the computer architecture starting with the PET. The disks were an add on later once disk drives caught on as the home computer medium of choice. The computers actually had a significant amount of precious ROM space dedicated to tape drive operation which was completely wasted in the later C64 timeline when most users were using disks exclusively. Some later ROM replacements like the excellent JiffyDOS system repurposed the tape code in their ROMs to provide a built in fast loader and DOS wedge (a whole other rabbit hole).

A better comparison would be the Motif/CDE GUI that commercial Unix workstations were using at the time on workstation-class hardware. I think NeXTSTEP still wins on style, particularly since X desktops were a garish mix of raw X, Xt toolkit and Motif apps all coexisting.

The 8086 was designed to be a 16-bit 8080, and 16 times the address space of that chip was a nice incremental leap forward. If you didn't expect the chip to become the foundation of the PC industry for the next 4 decades, it was probably a reasonable choice. At the same time, Intel made the iAPX432 chip, which was the one that was supposed to be future proof and look how that turned out.

They're both called the "D" flag, and they both globally control the behavior of certain processor instructions. Besides that, they're totally different.

The 8086 D flag is the direction for string instructions, whether to increment or decrement the index registers after each repetition. One use was for moving memory between overlapping regions by starting at the end and working backwards.

The 6502 D flag is for decimal mode. When set, the instructions ADC and SBC do BCD arithmetic instead of binary, e.g. 0x09 + 0x01 = 0x10 instead of 0x0A as you'd expect. The 8086 also has support for BCD, but took a different approach, using separate instructions DAA/DAS for the same purpose.

Both can lead to bugs when you assume the flag is in the "normal" state but it somehow got flipped.

Learned that one the hard way. I built a 6502 single board computer and tested it out running my customer built monitor. I spent hours verifying the hardware to isolate a problem where programs would crash and memory would become corrupted. Turns out my monitor was popping garbage into the flags register when it returned control and sometimes setting decimal mode.

These 8086 instructions were pretty cool coming from a 6502 background. The usual way to copy a block of memory in 6502 was something like this:

    ldy #len
  loop:
    lda source-1,y   ; memory accesses: loads opcode, address, value
    sta dest-1,y     ; memory accesses: loads opcode, address, stores value
    dey              ; memory accesses: loads opcode
    bne loop         ; memory accesses: loads opcode, offset

So 4 instructions and a minimum of 9 memory accesses per byte copied, more if not in the zero page. Even unrolling the loop gets you down to 6.

Compare this to the 8086:

      mov cx, len
      mov si, source
      mov di, dest
  rep movsb            ; memory accesses: read the opcodes, then 1 load and 1 store per byte

Even forgetting about word moves, you're down to 2 memory accesses per byte. No instruction opcode or branching overhead.

This blurs the real issue. You can still have different compensation and PIPs and everything else without stack rankings.

The real issue is that stack rankings compel managers to meet a quota for low performers. Even if the team is full of top tier engineers, one or more get dealt the short straw every review period.

As pointed out in another comment, it really is 4MB, since the segment register the memory is accessed through is exposed on the bus. You could include those extra 2 bits for a 22-bit total address space, although I don't think it's really practical to have such a partitioned memory model for a general purpose computer.

I can see mapping CS to 1MB and DS, ES, and SS all to another 1MB for 2MB as moderately viable. This would make the system a Harvard Architecture instead of a von Neumann, with the escape hatch of segment prefixes.

It would be even more of a nightmare to program than the already janky segmented memory model we ended up with, so I'm happy IBM wisely decided to avoid it.

All the visualizations of the mandelbrot set I've seen use a threshold of iterations that define the edge. I think that threshold is more significant than any instability due to floating point numbers. A more formal analysis of numerical stability comes down to whether the iterated function is considered well-conditioned. I don't have the math to state it formally, but my intuition is that the mandelbrot function is, in that a small change to the function input will have a small effect on the number of iterations except at the very edge where the threshold will define the boundary anyway.

Very cool! I just finished a for-fun mandelbrot drawing program; I was familiar with the image, but I had never delved into the math. It's an extremely simple algorithm, which makes it that much more surprising it creates so much complexity.

The first computers DOS ran on were from a different era. The first PC model had 16kb of memory and a 160kb floppy drive. There was literally no space for error messages.

DOS itself literally took up an entire disk. You'd have a DOS disk with the DOS utilities like fdisk.exe and format.exe, but you'd boot off that, then swap to a program disk to do actual stuff.

One early DOS IDE (Turbo Pascal 2 or 3 I think?) would prompt you to load error messages off disk at startup. If you chose not to, it would free up some memory for your project and you'd need to look up the messages in the manual by error number.

Only a few years later, every PC had a hard drive, >1MB storage on a floppy, and the full 1MB real mode address space filled with RAM.

Not surprising.

Back in the heyday of POSIX standardization, the Emacs camp and the POSIX camp were both very opinionated and not entirely aligned. One example is the standard disk block size used in command line utilities such as du and df. RMS made GNU use 1kb instead of the POSIX standard 512 byte size, but this could be overriden by setting the environment variable POSIX_ME_HARDER.

4C is correct. My INT 21 function codes memory is a bit fuzzy.

Yeah, segmented memory was such a headache. The large memory model that used "far" pointers broke some things that were taken for granted in C. Comparing pointers especially was an easy place to introduce difficult to find bugs. A given memory location could have multiple valid pointers, so you couldn't do an int compare. The 32-bit int 0x00000011 is smaller than 0x00010000 but 0000:0011 pointed to the byte after 0001:0000.

Ah, debug. I used debug extensively for machine code programming on DOS. I couldn't afford MASM and certainly didn't have access to free assemblers. My first hello world program was almost exactly this.

However, I always ended my programs with INT 20 instead of RET, or INT 21 with AH = 0. RET worked both for standalone programs or in debug, but there was one exception: if you ran your code repeatedly in debug with G 100. It would work the first time, but IIRC the stack wasn't reinitialized to return to the correct place on subsequent G commands. I spent a lot of time typing, running and patching in a single session and INT 20 always worked correctly.

I also tend to have important stuff in a buffer before doing anything destructive outside emacs although I definitely keep backup files on.

Reminds me of a time a hard drive failed on a computer I had. I had an active ssh connection, running terminal display emacs remotely, with a very important file -- with no backup copy -- in a buffer. The computer continued to function, but I couldn't access the disk at all, and I figured as soon as I closed the ssh connection, it was game over. I managed to salvage the file by cutting and pasting through my terminal emulator.

When I started doing Java, everyone else was using JBuilder. Then Eclipse came along, and JBuilder died. Next, IDEA showed up, and Eclipse started to whither. Don't get me wrong, IDEA is great but IDEs do come and go, and are subject to the fortunes of the company that pushes development.

Though all of that, I have used GNU Emacs, definitely an unconventional choice for Java development. I've occasionally tried the leading IDE, and while it's sometimes been helpful to ramp up on new projects with tools shared with other teammates, the productivity of a comfortable and customized Emacs environment has always drawn me back.

In 10 years, IDEA and VS may or may not be still widespread, but Emacs will definitely still have its niche.

The 65816 is a fascinating chip, even though it's a dead end in the evolution of home computing. It falls in a category with the Z8000 and maybe even the 80286: backwards compatible with their predecessors, but extending them in odd, idiosyncratic ways. Processors evolved and mostly discarded the vestigial weirdness of the original 8-bits, but its a special kind of fun to revisit assembly language programming in that style with some of the oppressive constraints (address space, addressing modes, minimal registers) lifted.

The 8080 lacked this, but even though the 8086 was more or less based on the 8080, this probably inspired the 8086 LOOPNZ instruction. Same idea, hardcoded to use the CX register instead of B on the Z80. The unoffical nicknames for the AX, BX, CX, DX were accumulator, base, count, and data. CX was used for the count for all looping and string move instructions. Similarly, BX was special purpose for indirect operations and AX/DX for certain logic and arithmetic instructions.

A good chunk of Transactor is also available at https://archive.org/details/transactor-magazines, which does happen to be a huge database to store this kind of information.

It's nice to see it available elsewhere too. At first glance, the quality of the files at commodore.ca seems higher than archive.org. And having redundant sources rather than relying on one source for archiving this sort of thing is encouraging.

A while back I did a demo and wanted a diagram to show what was going on. I stumbled on http://www.plantuml.com which did exactly what I wanted: it took mark up and turned it into an image that could be embedded in a github markdown document.

That said, diagrams can either be rare, focused, and useful; or common, unfocused, and distracting. Automated processes tend to generate the latter.

It remained unchanged for over 30 years, but there are actually two versions of the GIF file format. The second revision, known as 89a, added a few minor refinements like a frame rate for animations and transparency (but only binary, e.g. fully opaque or fully transparent).

PNG could arguably be seen as GIF 2.0, since it addressed the major shortcomings of the format. But since PNG had no animation capability, it could never fully replace GIF which held on for that one niche use.

Very cool. One of the c64's glaring omissions for a hackable machine is a built-in monitor. My suggestion: throw a monitor program (my favorite: https://github.com/jblang/supermon64) onto the one of the disks and you'd have a just enough to do some actual debugging.

It's unfortunate that Commodore shipped BASIC 2.0 on the 64. They already had shipped PETs with the much superior BASIC 4.0 years earlier. It was likely a cost saving measure: they had a more favorable licensing deal with MS on BASIC 2.0 and it fit on fewer ROM chips. Too late the C128 came with BASIC 7.0 which was actually quite good (for an 8-bit BASIC anyway).

CBM had 5 byte floats, but when they were copied into the floating point "registers", they were expanded into a 6 or 7 byte representation for speed. It was 8 bits of exponent, 1 bit sign, and 31 bits of mantissa (with one extra implicit bit since the leading bit is always 1).

It's true there was very little performance gain to using BASIC integer variables, since they'd be converted to floats internally almost always. The one real advantage of integers is that a DIMed array of ints was more compact than an array of floats.

An upgrade card with a 20Mhz 65816 and 16MB RAM was actually sold as a product: https://en.wikipedia.org/wiki/SuperCPU, but it didn't really make anyone happy. The C64 purists stuck with the 6510 and those looking for more power just switched to modern architectures.

I'm not following things as closely as I once did, but I think one of the main drivers was using gcc/clang for analysis, to e.g. make parse trees available inside emacs.

The big change for this release is direct access to shared libraries. Traditionally, emacs has executed binaries directly for all its external interaction, using stdin and stdout for all communication. Now it will be able to call libraries and use their native APIs rather than just two text streams.

This had been long resisted on the grounds that this feature could be used to link emacs with non-free code.

From the ChangeLog:

  ** Emacs can now load shared/dynamic libraries (modules).
  A dynamic Emacs module is a shared library that provides additional
  functionality for use in Emacs Lisp programs, just like a package
  written in Emacs Lisp would.  The functions 'load', 'require',
  'load-file', etc. were extended to load such modules, as they do with
  Emacs Lisp packages.  The new variable 'module-file-suffix' holds the
  system-dependent value of the file-name extension ('.so' on Posix
  hosts) of the module files.

Reimplemented, not ported. They wrote it from scratch, using innovative techniques to get the smooth side scrolling that was supported by hardware in consoles.