deater

well it depends on your error bars. On many modern system you can have +/- 5% variation or more run to run just due to the non-determinism present in modern CPU architectures and operating systems (even things like room temperature, time of day, the number of environment variables, etc, can affect this). While you could maybe run a set of careful experiments to characterize and remove this, in my experience most researchers don't bother. So something as small as 3% would need a lot of convincing to me to make the argument that it is significant.

even some of Banks' stuff starts to get a bit dated. I was re-reading Consider Phlebas the other day, and in one sequence he snuck into a high-security concert type event and he's making narrow escapes because concert security is humans checking for paper tickets. And while I am sure you could come up with an in-universe reason for why a super-technological somewhat morally ambiguous future event with pervasive technology would be relying on 1980s levels of surveillance, I think it's just funny how people not that long in the past couldn't easily imagine how willing we'd be to overcomplicate things like that.

back when the Apple II / Applesoft BASIC twitter bot was a thing similar techniques were the best way to inject assembly language into a BASIC program, though we quickly learned there were more compact ways than REM to get a line ignored.

Some examples here, as sadly the apple2twitter bot shut down and deleted their account a while ago.

http://deater.net/weave/vmwprod/appleiibot/part7.html

There are probably so many stories out there of interesting things she did. A few are breifly referenced at her old website here: https://web.archive.org/web/20060116130917/http://www.csl.co...

you wouldn't believe how many people cite that paper as "Wulf et al." when that's practically more characters than saying "Wulf and McKee"

I notice these things a bit more as she was my PhD thesis advisor

you should try running Linpack on them all (you can find the results here mixed in with other machines I own) https://web.eece.maine.edu/~vweaver/group/machines.html

When I did that on Pi3 when it first came out you could crash the system because the thermal throttling wasn't fast enough (the temp sensor was on the GPU not CPU). When I reported the issue on the pi forums the answer was essentially "why would anyone ever want to do that"

I don't know how many of you have seen a 1541 floppy drive in person either but it is massive, it's heavier and possibly bigger that an actual Commodore 64 and pretty expensive at the time too.

it's fun seeing c64 people on the defensive about it, a nice change from getting lectures from them about how their graphics were the pinnacle of 8-bit computing

as the previous commenter hinted, it's because the founders were Vera and Augustin

way back in the day our college LUG (linux user group) had a rep from VA Linux come to speak, but the person running things was unfamiliar with the company and kept calling them "Virginia Linux"

at the time, just out of undergrad, I ended up working for the remnants of the #9 Video Card company that had been bought by S3 and was masking a last effort at making a Linux-based Transmeta-powered "web-pad" (tablet): the "Frontpath ProGear" (new management wouldn't let them give it a Beatles related name that #9 equipment used to get)

in any case due to the unfortunate timing of the dot-com implosion it never really went anywhere (I wish I had managed to keep one, they used to appear on ebay occasionally)

the one thing I remember is that it was memory limited, it had 64MB but I think the code-morphing software really wanted 16MB of it which really cut into the available system memory

saying "windows 98 was bad too" is just an example that Microsoft has always had poor code quality. Back in the day Linux, for all its flaws, was generaly a lot more stable on the same hardware.

microsoft has a lot to answer for after 50 years of normalizing poor quality software

as someone who has written my own OS from scratch (vmwOS) and teach a class on it, I have to agree with a lot of the other comments that x86-based OS projects do end up being exercises in 40-year old PC/x86 retrocomputing.

A few years ago I would have recommended the path I took (writing an OS for the Raspberry Pi) but the Pis have gone off the rails recently. So writing a simple OS for a Pi-1B+ is relatively doable (simple enough, sort of OK documentation, biggest downside is needing USB for the keyboard).

Things led to disaster once everyone wanted to use Pi4 (which was all we could manage to source during the CPU shortage of '23) as the documentation is poor, getting interrupts going became nearly impossible, and the virtual memory/cache/etc setup on the 64-bit cores (at least a few years ago) was not documented well at all.

quite possible because it's from Europe, but remember that Apple was sticking + on the end of their model names 6 years before the Amiga existed.

as someone who has built various raspberry pi clusters over the years (I even got an academic paper out of one) the big shame is that as far as I know it's still virtually impossible to use the fairly powerful GPUs they have for GPGPU work

ironically, you should be thanking Apple that the IBM PC exists

The Apple II was an open system and IBM clearly took a lot of inspiration from the Apple II line. Look at the 5150 motherboard in the picture in the article and compare it to the motherboard from an Apple II+

I had thought maybe it was on the old 0xdeadbeef mailing list, but no luck, but probably it was this from rec.humor.funny which in the end isn't quite as clever as I remember it being.

https://groups.google.com/g/rec.humor.funny/c/4zIyBq1-1_E/m/...

dating myself here but I remember in the 90s reading a really funny spoof article about Microsoft announcing they had developed nuclear weapons. Didn't even seem that implausible at the time.

I would have linked it here but none of the search engines are turning up anything at all, and in fact I don't think it's even possible to find stuff like that with search engines anyore.

it's already happened. So many of the main contributors work for IBM, Microsoft, and Intel. It's extremely difficult to have your voice heard / patches accepted if you're just a hobbyist developer

I've gone to the extreme of writing my own OS because I got fed up with how corporate Linux has gotten

it's funny that a lot of us Linux nuts on comp.os.linux.advocacy back in the 90s predicted this was Microsoft's planned endgame. I personally thought it would take less than 30 years for them to get around to it though.

my plan to rick-roll every major coding competition continues apace. muahahaha

I actually had another entry that I felt had much more clever coding that did some nice sixel animations but from what I understand there were many entries also doing that this year

I think you'll find more systems used DRAM than SRAM.

The Apple II was one of the first 6502 systems to use DRAM (in 1977) and Woz was incredibly clever in getting the refresh for free as a side effect of the video generation

I have to say as a 6502 assembly programmer I have wasted many hours of my life tracking down the same issue in my code (forgetting to put an # in front of an immediate value and thus accidentally doing a memory access instead). Often it's like this case too where things might accidentally work some of the time.

Worse than the floating-bus in this example is when it depends on uninitialized RAM which is often consistent based on DRAM so the code will always work on your machine/emulator but won't on someone else's machine with different DRAM chips (invariably you catch this at a demoparty when it won't run on the party machine and you only have 15 minutes to fix it before your demo is about to be presented)

the problem is I have a whole box of composite capture cards and only one actually does a reasonably good job. I feel like it'd get expensive doing the same thing with HDMI capture boards.

My other big problem with HDMI capture is trying to capture mockingboard audio at the same time, I forget if in your reviews you cover that aspect of things

I have to admit I'm being difficult here and want to capture the output of the composite port from the actual Apple II video circuitry. I feel like having a raspberry Pi replace the video circuitry is cheating somehow, and I know that's inconsistent of me because I'm often using a modern floppy disk replacement.

even if I had an HDMI card it wouldn't help with my other problem which is trying to capture HDMI video and mockingboard sound at the same time with them ideally synced up to the exact 60Hz frame

I still find it nearly impossible to get good video captures from my Apple II for demoscene purposes

the best I can get is an old composite->USB capture device which mostly does a good job but struggles with lo-res graphics (grey ends up being closely spaced black/white lines)

I have a retrotink 2 but to capture things I have to run it through an additional HDMI->USB capture device and that's not the best and I can't get the sound to sync up that way. (I'm doing all of this with OBS/Linux which probably isn't helping things)

not sure if getting an even more expensive retrotink 5 would help

you can also get a regular interrupt from a Mockingboard sound card, these days it's probably more likely people will have one of those (especially if they are running under emulation) than a mouse card.

when writing demos and games that have mockingboard support it's always tempting to take advantage of the timers on the 6522 chips on it, though it does mean that the programs wouldn't have been useful for most people back in the 80s/90s

haha as someone who has spent a lot of time recently doing Apple II graphics coding, both for games, sizecoding, and the demoscene, let me tell you that the weird layout in fact is not easier to deal with.

You have to waste a lot of space on lookup tables, or else complex calculations. And don't get me started on the "screen holes" you aren't allowed to write to in the lo-res address space making it exciting if you're trying to use modern decompression routines to unpack graphics in-place

if anyone is curious, the data structure used in the Apple II version had the idea of "locations" which just hold 4 of the nodes described here. Usually this would be for North/South/East/West, plus there would be an additional clickable area that would call a function callback, usually used for puzzles but it could also be used as a hack to take you to an additional location.

This setup was more or less enough to implement the whole game, the one problem area was Channelwood where the pathway platforms are pentagons and thus had more than 4 backgrounds. There were also a few areas where a location could have used an additional clickable area but had to make do without. Also to fit on 3 disks about half the nodes were left out: generally when walking a straight path every other node was left out for both disk space and also time-consuming-rotoscope reasons.

yes. I also made an Atari 2600 version but that one's only a subset of the game (though it's enough can beat it using the speedrun route)

when making the Apple II version of Myst I more or less generated graphs like this by hand based on playing through the game (in order to hook up the data structures for the custom 6502-assembly language engine) I wonder if it would have been easier to automate it like this.