nickynickell

Coincidentally, I bought one of these recently and it was delivered this morning. Including the MultiPort II port replicator and floppy drive. Boots and runs fine (sans some unhappy memory locations and dead CMOS). Need to clone the disk so I can poke around on the stuff still on it. It's got NetWare on it, excel, word, powerpoint, netscape navigator, and mosaic. Somewhat spooked about spinning it up too many times.

The keyboard mechanism is much more satisfying than I expected. Jealous of anyone who got to use one when they were new.

Many games already throw brass across the screen. To the extent that mirroring weapons or using lefty versions right handed is a thing. It "looks cool."

> we figured out how to send messages to all computers (using Novell Zenworks or something)

The Novell messaging utility[0] thing? For us that was disabled in the registry. Unfortunately that was an easy fix. "Fun" times were had.

[0]: http://www.novell.com/documentation/linux_client/linuxclient...

They were joking, and you're being needlessly hostile. Plus you're wrong on multiple counts. Most of the counter examples are historic, but still.

Yes, barrel is not a unit of rounds, but there are situations where it would be appropriate. Superimposed loading is where multiple rounds are loaded in the same barrel and are fired sequentially. This is a very old idea, but for a modern take on it look up (the now defunct) Metal Storm. Terrifying stuff.

There have been guns with many more barrels than 7 or 8. Volley guns have been made with anywhere from just a few to nearly a hundred barrels. They weren't always big platform mounted monstrosities either. A famous example would be the nock gun: a 7 barrel, shoulder-fired flintlock.

In this context we're talking about death: giving more death to the enemy than they could give to you. Ultimately the meaning is the same as your rewording. Just a bit more grim.

I'd wager they meant drum. Though superimposed loads are a thing too.

Not a hard confirm, but I stood there marveling at the pneumatic ceiling fans in an Amish bakery once. Each one had a little oscillating engine and some plumbing for the compressed air.

Why does it need to be relevant for more people?

It looks as if you're treating it as a means to an end. I would say that it was more of an end in itself. Sure, something else might have been more impactful to a larger number of people, but having an impact isn't the point.

To clarify, I was only talking about audio formats. Not automagically converting everything to run on the new engine. Doing that would kind of be missing the point.

There is a similar project redoing New Vegas in Fallout 4 (F4NV - I'm not affiliated with the project, just a fan snooping on their progress from time to time) and one of the really important things is that they're making their vision of what NV could be. This means all new meshes, textures, and code - not the old content updated to run on the new engine.

I've written some code for fiddling around with the plugins the engine uses (.esp/.esm/.esl files). The basic structure hasn't changed, but a lot of the records and fields have. Automatically converting them well enough to not need manual tidying up would be a pretty arduous task.

Converting the old code into papyrus would be as well.

Supposedly some file formats have changed between Fallout 3 and 4 so you'd need to convert said files as well. Not exactly an insurmountable technical hurdle. There is at least one other similar project that isn't shutting down.

The rule with these things is typically "If you make us give you an answer about if you can do it, it will be no."

Is that number attached or crawling? If attached, how many have you caught before they dug in? I live in the same area and that number would be really low. Stumble on some deer ticks and you'd be lucky if you only end up with 10x that number.

The best 879 pages of urgent meaninglessness and near-constant déjà vu ever written.

I found picking different starting points on later re-reads rather interesting. For anyone who hasn't read it, Dhalgren is circular, but there are a handful of places where it could start that make about as much sense as starting on page 1.

Definitely worth a read, but you'll never figure out how to make that discord on a harmonica.

Pretty slick for what I'm assuming is your first big project.

Tangentially related: do you think your mentor might have been indirectly encouraging you by telling you it was impossible? I've been on both ends of that trick and have seen mixed results. Any mentors here who have done something similar? How did it go?

That is beautifully well documented. Are you planning to extend it further or do any similar projects?

Take it a step lower and do one in assembly and it is even more fun. I almost have enough code together to say that I'm doing one in RISC-V assembly. At this point I have already accidentally picked up a more intuitive understanding of how a lisp compiler works.

So far everything is in Logisim[1], but I'm actually thinking of writing an emulator so I can debug programs quicker. I started a lisp interpreter in risc-v assembly, but testing my code at 3khz (the max logisim will run my design at) was too painful. The assembler and microcode generator are js+node.

risk-vee is a really basic (read: dumb) "common bus" design. All of the internal components of the CPU share the same 32-bit data bus. The heart of the control unit is a ROM that is 32-bits wide. Each bit is connected to one of the various things in the CPU. To make generating the microcode easier I defined a mask for each line.

Taking "move the PC to the memory address register" as an example: The register that holds the PC has an output enable line, and the memory address register has select/enable and both would need to be high. Pulling a few lines from microcode.js:

  pc_read =           parseBin("0000-0000 0000-0000 0000-0000 0100-0000");
  mem_address_write = parseBin("0000-0000 0000-1000 0000-0000 0000-0000");

So the microinstruction we want ends up being

  pc_read | mem_address_write

I feel like I'm simultaneously under- and over-explaining it.

[1] http://www.cburch.com/logisim/

Actually designing an ISA is voodoo, but doing the mircrocode is fairly easy. On a tiny little 4-bit design with only a few control lines you can do it by hand. Past a certain point, though, it is essentially impossible to do manually without going insane.

It isn't very sophisticated, but the project I mentioned above might satisfy some of your curiosity: https://hackaday.io/project/18859-risk-vee / https://github.com/cadpnq/risk-vee

My methodology was to define each microinstruction that made up every instruction (such as "move pc to memory address register"). I then took all of the control lines in my design and assigned them a bit position in the control store. From there it was just a matter of defining each control line symbolically and "assembling" each microinstruction by ORing the appropriate things together.

I'm actually gearing up for a RISC-V processor in Fallout 4. All of the design work is done, but building it with the vanilla logic gates (introduced in the Contraptions DLC) actually isn't possible. Luckily I already had a mod with "real" components when Contraptions was announced.

Assuming you weren't joking, how sophisticated is your design? (as in, "is it pipelined?")

Having done a bit of lisp spelunking myself, I would suggest that you dig into the source of the lisp your program ran under. Trying to figure out behavior from the surrounding context can be rather difficult when you're playing with an archaic, sparsely documented lisp.