• There really is no news at the moment.  Everyone is on repeat on the Tiger Lake and RTX 3000 launches, but no-one has anything to benchmark so there's no new information to be had.
  
  
  
• So here's some more olds: Bullfrog after Populous.  (The Digital Antiquarian)
  
  Powermonger, Theme Park, and a little game called Syndicate.
  
  
  
• Since we're in the 21st century now and not 1987 how about text-editing your podcasts?  (Six Colors)
  
  Descript is a tool that transcribes your podcasts into text - and then lets you edit the audio by editing the transcript.  You can't change the words, but you can remove or rearrange sentences.
  
  And this being the 21st century it's a monthly subscription, not something you can just buy.
  
  
  
• This is the Holtek HT48C06.
  
  
  
  It's an 8MHz 8 bit microcontroller with up to 96 bytes of on-chip RAM and an IF instruction like the Imagine's A108 DSP.  It's used in disposable digital pregnancy tests.
  
  
  
  Which, it turns out, contain the classic paper strip and a little circuit that reads the paper strip.
  
  
  
  
  
  
• So, speaking of the Imagine, I figured out a nice additional graphics mode.  I mentioned that text modes are actually harder to do than graphics, because on every scan line it needs to read the text information, and then the bitmap data for the font.
  
  The basic text map has two bytes per character: One to specify which of 1024 characters to display, and one to specify which of 32 colours to use for the foreground and background.  The video controller can read those two bytes in one cycle, and then spends the next cycle reading one line from the font bitmap, before processing the next character.
  
  So, instead, let's try this: Store the colour information, then the bitmap data, and repeat.  We can display one character width per memory access, half as much as in genuine text mode.
  
  Then, rather than directly interleaving the colour and bitmap data, we can have them in two separate banks.  Read two colour bytes in one cycle, then two bitmap bytes the next.  We can easily buffer a couple of bytes of colour data while we read the bitmap.
  
  That means we can have a 1296 byte array for colour data, and a 12,960 byte array for the bitmap, and have 32 colour text with no fuss at all, using 40% of the available memory cycles.  We have 120 cycles available in the visible section of each scan line, and we're display 48 (or maybe 60) characters per line.  Since we can read two successive bytes per cycle, and we need two bytes per character, that works it to a very simple 48 (or maybe 60) cycles used.
  
  We can step that up in two ways: First, with four-colour mode like the C64.  The C64 didn't let you freely assign the third and fourth colours, but we can.  We now need two bytes of colour data (four five-bit values) and two bytes of character data (ten two-bit pixels).  Now we're using 96 cycles out of 120 in 48-column mode, and all 120 in 60-column mode.  But on the other hand we're using half the memory of standard 32-colour mode and can change the colour of text by changing one byte rather than rewriting the entire character.
  
  Finally, we can provide 10-bit colours directly rather than using the colour registers, for 1024 colour text.  In two-colour mode that uses 3 cycles per two characters, so 72 in 48-column mode and 90 for 60 columns.  In four-colour mode it... 
  
  Wait, that doesn't work, does it?  I'm an idiot.  Three cycles per column times 48 columns is 144 cycles used out of 120 available.  Well, it can be made to work if you move the colour map data over to system RAM.  That's perfectly fine; it only takes up 5k and only uses, oh, 50% of available bandwidth.  In fact, if you move the colour map to system ram this mode will work for 60 columns, though that will use 100% of the available cycles during the visible phase of each scan line.
  
  
  
• One small problem with all that - this uses two memory maps, one for colour data and the other for pixel data, so effectively both playfields are combined to produce a single layer.  That means you can't use it and also overlay graphics, and you can't use it with the dual-monitor trick I mentioned.  Not unless I add in more playfield registers anyway.
  
  If you use the interleaved mode it does use just one playfield and can be overlaid on any other single playfield mode, bandwidth permitting.  That mode uses nearly twice as much memory  - but it does allow colour selection per scan line rather than just per character cell.
  
  

Posted by: normal at Sunday, September 06 2020 05:24 AM (obo9H)

Posted by: Pixy Misa at Monday, September 07 2020 12:38 AM (PiXy!)

Hide Comments | Add Comment

• No, we can't send you your shiny new ERC721 token,  Why?  This is why.
  
  
  
  
  For every "gwei" of gas price the token costs around 10¢ to process.  Used to be cheaper but the cost of Ethereum itself has also increased.
  
  So this simple digital transaction would cost $2892.50.  If it even works.
  
  Admittedly if you're willing to wait a while, we can send you the token to confirm your $20 purchase at a cost of just $38.70.
  
  
  
• Via the comments over at Wonderduck's:
  
  
  
  
  
  
• Melbourne seems to be determined to lead the world in arresting people for Facebook comments.
  
  
  
  
  I recommend the Bugs Bunny / Florida solution.
  
  
  
• Samsung announced the Galaxy Fold 2.  (AnandTech)
  
  Still a chunky puppy at 17mm thick (compared to Microsoft's... What's it called?  Duo, at just under 10mm) and doesn't actually fold flat.
  
  Still $2000 and now for some reason with half the storage of the first model.
  
  
  
• NEC made a 9MB 3.5" floppy drive.  In 1988.
  
  
  
  
  This was basically a 2.88MB ED floppy but with 240 tracks instead of the usual 80.  It could read but not realistically write older formats.
  
  
  

Imaginary Computer Specifications of the Day

So after much cycle-counting and cross-referencing of old component databooks on Archive.Org I've pretty much settled on the specs for the original 1983 Imagine system.

• 3 MHz 10-bit A103 microcontroller
• This is the main CPU.  It's a low-cost embedded version of an imaginary single-chip minicomputer like the LSI-11.  The full version has segmented addressing and other fancy stuff, that I can introduce as a imaginary upgrade if people are interested.
• 3 MHz 10-bit A108 audio processor
• An even more stripped down version of the same architecture, with half the registers removed, but with 64 bytes of on-chip RAM and two partly pipelined MAC units.
• 128k ROM
• That's a lot, but I need 24k just for the two font tables (10 bits means 1024 characters), and I'm going to throw something like Turbo Basic in there, and a screen editor (as opposed to a line editor) and an assembler / disassembler.
• 128k system RAM
• Because I want to see that magical 130024 bytes free at boot or whatever it comes to.
• 3 MHz memory clock, supporting two-byte bursts or single-byte read-modify-write per cycle.
• 128k video RAM
• Double buffering for Elite!
• Same clock and burst mode tricks as system RAM.
• 500k single-sided 3.5" floppy drive
• Formatted capacity, and that's 10-bit bytes too.  I'm stealing a trick the Sirius 1 and Apple Lisa used to increase capacity - they wrote more sectors to the longer outside tracks of the disk, keeping the bit density relatively constant.  The Sirius 1 could store 600k of 8-bit bytes on what was a 320k or 360k floppy on regular IBM compatibles.  Track 0 will always be formatted as 8 sectors of 8-bit data so that the disk can be identified.
  
• Subsequent models could upgrade this to double-sided, then HD, then ED, then to the NEC TD model from the tweet above.  By 1989 or so it could have stored 12MB per disk based on hardware that really existed at the time.
• 5 voice wavetable synthesis
• This is the task of the A108.  It's fully programmable, so you can coax more voices out of it if you simplify the processing, though the 64 bytes of on-chip RAM are limiting.  It doesn't have its own memory bus and if you use main memory too heavily it will slow down the CPU.
• 480x270 colour video @ 60 Hz
• Alternate modes of 320x270 and 240x270 to reduce memory and/or increase bandwidth available for drawing.
• 640x360 monochrome video @ 50 Hz
• I added this in after looking up the details of old Hercules / MDA monitors and realising that my planned HSYNC rate was already within spec.  I just needed to bump the pixel clock up from 12 MHz to 16 MHz for the monochrome output.  The FM-7 had both RGB and monochrome ports, so it's reasonable to do it here too.  The one small cheat is that you can steal the video controller's second playfield registers to convince it to output different screens to the colour and monochrome ports at the same time.
• 32 colour registers from 1024
• 9-bit RGB for 512 colours, plus a common low bit that gives slightly brighter versions of each of those - and 16 proper shades of grey.
• 1, 2, 4, 5, or 10 bits per pixel
• 10 bit mode is only really possible at half resolution - 240x270
• Two independently scrollable playfields
• As long as you keep within the constraints of 120 available memory cycles per scan line.  480x270 in 32 colours is already using the full 120 cycles, so that mode doesn't support dual playfields unless you put the second field in system RAM, which you can totally do - the video controller has access to both memory banks - but will kill CPU and DSP performance.
• There are 160 total memory cycles per scan line, but the visible period is only 75% of that, an the video controller can only buffer a few pixels at a time, not an entire line.
• Text and tile modes
• 48x27 and 60x27 text modes, in regular 2 colour text (32 foreground and background colours), and in C64-style 4 colour text.
• Surprisingly it can't easily do 80 column text, though it can do 640x360 graphics without difficulty.  Text mode actually requires more memory bandwidth if you don't have an independent character ROM/RAM circuit, and it doesn't.  The C64 did, but I'm deliberately leaving that out.
• 320 bytes of on-chip RAM would be enough to fix this, but that was a lot for the early 80s.  With 10-bit bytes and classic 6-transistor SRAM that's 19,200 transistors.  That's about as many as the entire Z8000 CPU design.  The 68020 has 256 bytes of cache and that was a big deal; Intel didn't have on-chip cache until the 486.
• Tile mode...  I'll have to figure out the numbers again.  I think it can do 48x27 of 10x10 16-colour tiles.  Oh, right.  In tile mode the tile map has to be in system RAM so it can be read in parallel with the pixel data.  The map is only 2592 bytes per screen, the problem is we need to re-read 96 bytes on every scan line because we don't have the on-chip RAM to buffer it.  This uses about 25% of the system bus - 48 cycles out of 160 per active scan line, but none during vertical retrace.  Five voice audio requires 40 cycles per scan line, so you can see where this starts to eat into available bandwidth.
• This is why I defined a couple of alternate A100-family CPUs.  The A101 would have dual memory buses and could be happily computing away while graphics and sound operations were eating 55% of the bus cycles.  But I was holding off on including that in the original model.  Constraints are good, it's only impossible that's bad.
• 10 sprites, 10 pixels wide, 16 colours
• As with other systems the sprites can be reprogrammed on the fly so you can have more than 10 in total as long as you don't have more than 10 on any one scan line.
• Though apparently some bright spark convinced the original Amiga to reprogram the sprite registers in the middle of the scan line to get around even that restriction.
• Complex pixel modes
• Fill mode (Apple IIgs)
  
• Hold-and-modify mode (Amiga)
• Palette selection per byte/word (Apple II)
• For example, one 10-bit byte can contain four 2-bit pixels and a 2-bit palette selector, for 16 total available colours but half the memory requirements of 32 colour mode
• Graphics text mode
• Reads two bytes at a time.  The first byte specifies foreground and background colours; the second byte specifies 10 pixel values, or 8 for 60 column mode.  Uses up to 60% less memory than full 32 colour mode, and doesn't require software translation from bitmapped fonts to pixels.
• Display list processor
• This is a very simple but Turing-complete engine to update video registers - or any other hardware register in the entire system - at scheduled times.  Based on the Atari ANTIC chip and the Amiga Copper.  Switch graphics resolutions and pixel modes per scan line.
• Accelerated 2D drawing operations
• Line, circle, fill, copy rectangle, rotate
• Not a general-purpose blitter though
• Built-in networking
• Two 250kbps RS-422 ports.
• These are used for additional floppy drives, printers, and to connect computers together.  Daisy-chainable.
• Similar to AppleTalk and the BBC Micro's EcoNet.
• Up to 32 nodes per network and 32 channels per node.
• The emulator will include an HTTP proxy so you can not only write a web browser, but deploy a web server.
  
• Just thinking about this, and the current speed of the emulator, there's no reason for me not to allow one emulator instance to spin up an entire network full of Imagines.

I think next I'm going to define the Basic.  I'm going to smoosh together Microsoft and HP Basic with maybe a dash of AMOS and Turbo Basic.  I'll write the initial compiler in Python or maybe Nim, but the goal is for it to be self-hosting.

• If you store arbitrary dicts as subfields in MongoDB it will chug along just fine.  Not a care in the world.
  
  Mirror that data to Elasticsearch and your server will die.  It doesn't take much; a few hundred records will do the trick quite nicely.
  
  
  
• Qualcomm announced the Snapdragon 8cx Gen 2 laptop chip.  (Tom's Hardware)
  
  What core does it use?  I don't know.  They don't say.  They never say.
  
  It probably sucks.  I doubt it's more than a thousand times faster than the Imagine.
  
  Oh, it's a Kryo 495.  (WCCFTech)
  
  What the ever-loving-fuck is a Kryo 495?  Looks like it's a 2018 design.  In other words the Gen 2 design is precisely the Gen 1 design, which failed completely in the marketplace two years ago.
  
  
  
• The Cortex R82 is a 64-bit embedded processor core that can directly address up to 1TB of RAM.  (AnandTech)
  
  For all the people building embedded systems with 1TB of RAM.
  
  
  

Hide Comments | Add Comment

This is the core of the wavetable synthesis algorithm, in Imagine assembler.  The advantage of this approach is that it runs on a completely general CPU as long as the multiply instruction is reasonably fast - not more than, say, 20x slower than the TMS32010.

The problem is it uses memory-mapped registers, and makes 23 memory accesses per sample to read the instructions and data.  With five voices and a 18.75kHz sample rate it would use 70% of the 3MHz system bus.

Only one of those 23 memory access actually reads the audio samples, though. So as little as 2k of RAM attached directly to the audio chip would reduce that from 70% to 3%.

It uses four registers - AB and CD as 20 bit accumulators, W and X for indexing.

I'd like to work out some DSP instructions that would reduce this count, and also figure out a nice way to handle stereo.  This code is mono only, though it can assign a voice to either left or right the way the Amiga did.

Registers per LFO:

$0    Sample base

$9    Balance

While this approach is limited in the number of voices unless I can speed up that loop - five or six at most - modulators can run at a much lower sample rate.  For example, the ADSR envelope might be defined as 128 values with a sample rate of 500 Hz or so.  Twenty such modulators would use fewer cycles than a single voice.

How about if we gave our audio processor 64 bytes of on-chip RAM, accessible as registers R0-R63?  Just a simple single-ported register file, but with a 20 bit datapath and available same-cycle rather than next-cycle for selected operations only.  We now have:

• Gack.
  
  
  
  
  I'm not convinced this chart is entirely accurate.  I'm mostly convinced the algorithm producing it said this is fine at some point.
  
  
  
  
  
  
• Intel has launched Tiger Lake.  (AnandTech)
  
  Laptop parts only so far, and with a maximum of four cores, when AMD has been shipping eight core parts at the same TDP for months.  But Intel has a small frequency advantage and a potentially larger IPC advantage and will likely run single-threaded tasks around 15% faster.
  
  I do like how Intel claims "more than a generational increase in performance" when they're comparing with an architecture from 2015.  Yes, well done, have a cookie.
  
  The chips also have integrated USB 4 / Thunderbolt 4, which should mean rapid adoption of both, and PCIe 4.0.  The chips feature Intel's new Xe graphics, which should be a big update, and support for LPDDR4X-4266.  I was expecting LPDDR5 for some reason, but it's not mentioned anywhere.
  
  One slight catch: This is purely an announcement.  Not even review samples have been delivered so far.
  
  
  
• Asus has announced three new laptops based on Tiger Lake.  (Tom's Hardware)
  
  The most interesting one looks to be the Zenbook S, with a 13.9" 3300x2200 touchscreen.  The other models include a 13.3" 4k OLED display, and a cheaper option with a 14" 1080p panel.
  
  Screens aside they're all very similar; they use LPDDR4X memory so they're all limited to 16GB of RAM soldered to the motherboard.
  
  A nice touch is that on all three models the trackpad is a small touchscreen itself.  The Zenbook S, due to its narrower aspect ratio, lacks the Four Essential Keys, but they are present and accounted for on the other two models.
  
  
  
  Shipping in October and November.
  
  
  
• Speaking of new hardware that looks great that you can't actually buy, Nvidia announced its RTX 3000 lineup.  (AnandTech)
  
  The RTX 3070 promises 50% more raw TFLOPS than the 2080 Ti at half the price.  Nvidia don't claim that 50% more TFLOPS translates to 50% more performance, and the architecture has changed enough that we can't easily predict how it will run.  But the half the price part certainly sounds good.
  
  At this point they look like awesome cards, and we'll just have to wait a couple more weeks to find out how awesome.
  
  
  
• Ah shit, here we go again.  (WCCFTech)
  
  A stock Radeon 5700XT can earn about $5 per day mining whatevers with minimal effort.  Good thing I wasn't planning on buying a new system any time soon.
  
  
  
• This is a demo of the Ys II opening credits running on the FM-77 AV.  It looks more like a 16-bit game here than an 8-bit one.
  
  
  
  Not sure exactly which model this ran on.  All had similar CPUs (dual 1.6 MHz or 2 MHz 6809s) but they ranged from 64k to as much as 448k of RAM.  But this isn't showing off the AV's signature 4096 colour mode, and the Ys wiki lists the platform as just the FM-7 which had 64k.
  
  There are some compilation videos of FM-7 gameplay on YouTube, which show what the system really did - which in turn shows what is possible with something like the Imagine. 
  
  A couple of things stood out: First, the graphics used a limited number of colours, with dithering to smooth things out.  I'm not sure if the original FM-7 could display more than 8 colours at once, though AV models increased that first to 4096 and later to 262,144.
  
  Second, three voice FM-synthesis sound is not really that great.  I'm planning at least five voices using wavetable synthesis, with something between 10 and 20 source LFOs. 
  
  By chaining the LFOs you can get all sorts of combinations of AM, FM, and PWM effects; it's kind of like the way the ANTIC chip could display impossible graphics modes by reprogramming the hardware on the fly.
  
  Simple examples: Each voice has a sample table and a volume register.  By updating the volume register on the fly, you can build an ADSR envelope in any shape you want - AM synthesis.  A step register controls how fast the voice plays back the sample; by updating that register on the fly you can apply FM synthesis.
  
  The computationally intensive part is applying the volume calculation, which is the only function that requires multiplication.  Hence the realistic limit of perhaps five voices at full sample rate, with a bunch of other oscillators at lower sample rates providing modifiers.
  
  Just need to figure out a simple and efficient way to handle stereo.  A sensible approach of having one volume register and one balance register requires four multiplies per sample, which requires four times more hardware than mono.  I'd like to figure out the trick an 80s audio engineer would use to handle that.   Although very likely they'd just do it with an analog circuit, which would be cheating.
  
  I think for the Imagine emulator I'm going to target an emulated system with 128k each of ROM, RAM, and VRAM, and a single 400k 3.5" floppy (with an emulator option to attach one or two external drives).  That's a lot for 1983 (the year 3.5" drives first appeared), but not entirely unreasonable given that the FM-8 came out in 1981.  64k each of RAM and VRAM and some weird storage like Sinclair's Microdrive might be more period accurate, but I want this thing to be fun to program for, and at some point period accuracy turns into period pain.
  
  The CPU will be the 10 bit design, emulated running at 3 MHz, with a free-run switch to go as fast as your real hardware can push it (which judging by my current code should be well over 100 MHz).
  
  480x270 graphics in up to 32 colours from 512, 10 sprites, 5 sound voices as mentioned above.  And a Microsoft Extended Colour Basic compatible compiler built into ROM.
  
  The FM-7 and my Tandy Colour Computer both ran versions of Extended Colour Basic, since it was Microsoft's standard offering for the 6809.  But I want to make it a compiler to make it easier to get good results.
  
  I'm thinking of making the core engines of the video, audio, and I/O processors cut-down versions of the Imagine's 10-bit CPU, so they all have a common core set of assembler instructions, plus their own special extensions.  The FM-7 could have three CPUs in 1982, so that's not as insane as it sounds, and would mean less weird stuff for programmers to learn.
  
  Update: And map the chip registers into the quick page.  That would mean the audio processor could have as many LFOs as would fit in 1k of virtual* registers - still only 5 output voices due to the multiplication bottleneck, but free reign on the modulators.  That would be a lot of fun to tinker with.  The TMS9900 took this approach to its registers back in '79, but didn't have enough fast static RAM for them, and as a result ran like a salted slug.
  
  Update Two: I have a devious way to do this on a 6809-like chip as long as it has a moderately fast multiply instruction - say 10 to 15 cycles for a 10x10 multiply.  The only problem is it would perform a lot of memory accesses; the sound chip would need its own RAM.  Not a lot of it, but separate from the CPU.
  
  * Virtual virtual registers, in fact.
  
  
• Oh, and I mentioned bubble memory yesterday.  The FM-8 supported 128k bubble memory cartridges, which are something I could throw into this emulator.  But a bit of poking the archives has largely dissuaded me.  While the access time was good (40ms for the Intel 7110 chip) the data rate was just 100 kbps, slower than a double-density floppy's 200 kbps or so.  And I found an ad for a 128k Apple bubble memory card from 1982 - it cost $895.
  
  So floppies it is, I think.  Imaginary ones.  The best kind.

Posted by: Mauser at Thursday, September 03 2020 12:44 PM (Ix1l6)

Hide Comments | Add Comment

• The RTX 3000 beans have been well and truly spilled.  (Tom's Hardware)
  
  Yes, the 3090 really does come with 24GB of DDR6X memory, moving at just short of 1TB per second.  It's going to cost significantly more than my current PC, which also happens to have 24GB of RAM.
  
  
  
• This is the Sharp X1, from 1982.
  
   
  
  I was looking up details of the X68000 and saw this mentioned as its predecessor, so I dug around a bit more.  While it's certainly striking in appearance, it's not remarkable inside: A 4MHz Z80, 64k of RAM, 6k of ROM, and 4k of video RAM.  (Apparently that last was upgradeable, though I haven't found specifics.)
  
  That 6k of ROM wasn't enough to hold a Basic interpreter, and it didn't try - you had to load it from tape.  The reason it looks like a fancy cassette deck is because that's exactly what it was.
  
  This guy actually has one - though not that model - with 48k of video RAM.  (VintageCPU)
  
  He also has not one but two X68000 models, and some computers I've never even heard of, like the Fujitsu FM New 7 from 1984, with 64k of RAM, 44k of ROM, 48k of video RAM, and two Motorola 6809 CPUs.
  
  
  
  1984 is the year I smashed my piggy bank and bought my first computer - the Tandy Colour Computer was going at something like half-price at just A$250 for the advanced model.  16k each of ROM and RAM.  Upgradeable to 64k in theory but I never had the money for that, after saving up for my own B&W TV set, and then a little thermal printer.  And the editor/assembler ROM cartridge.  And the joystick, which was rather nice.
  
  Anyway, the FM New 7 was basically the Colour Computer squared and cubed.  Instead of 256x192 2-colour graphics, it had 640x200 in 8 colours.  It had a proper 3-voice sound chip.  It could run OS-9, a Unix-like multi-tasking operating system that also ran on the CoCo, and is still around today.  It had three expansion slots, somehow, including one that could take a Z80 for a total of three CPUs.
  
  I saw several mentions of its densely-packed motherboard, and then found an actual photo.  
  
  
  
  Yeah, that's a lot of chips.  You can see the sockets for the three expansion cards.  This thing must have run pretty warm when fully equipped.
  
  This is amazingly close to what I've been thinking about for the Imagine, only it was real.  Oh, and bank-switched, of course, so you only had about 32k of the 64k RAM available for your Basic code.  And it was only a minor update over the original FM7 from 1982.  And that was a cost-reduced version of the FM8 from 1981.  (IPSJ Computer Museum)
  
  Just look at this in all its early 80s glory.
  
  
  
  It was so 80s it even supported bubble memory.
  
  The New7 was followed by the FM77 with up to 256k of RAM and a built-in 320k floppy drive, then by a whole family of FM77AV models.
  
  
  
  By the late 80s these were clearly eclipsed technically by the Amiga and Atari ST, not to mention Sharp's X68000.  But - bank switching aside - my dream computer actually existed.

Posted by: David at Wednesday, September 02 2020 04:01 AM (ZVBMd)

Posted by: Pixy Misa at Wednesday, September 02 2020 10:04 AM (PiXy!)

Posted by: David at Wednesday, September 02 2020 04:25 PM (ZVBMd)

Posted by: Wonderduck at Thursday, September 03 2020 07:39 PM (D9Okp)

Hide Comments | Add Comment

• There were at least two chips available in 1983 that could have handled my wavetable synthesis requirements for the Imagine: The TMS32010 which as we've noted cost around $500 a pop, and the 80286, which reduced the 70 cycle 8x8 multiply on the 8086 to 13 cycles.  The 68000 could do a 16x16 multiply in a maximum of 70 cycles, so its worst case was twice as fast as an 8086's best case, but not quite fast enough.
  
  Still, calculating the number of bits multiplied per second, I'd only need about 3% of a TMS32010 to handle 10-voice 10-bit wave synthesis.  That's something that could have existed even if it didn't.
  
  
  
• Nice work if you can get it.  (Quanta)
  
  Mathematicians have been wondering for two thousand years if you can travel a straight path on a dodecahedron, starting at one vertex and returning to that starting point, without ever encountering another vertex.
  
  On the other Platonic solids, it's long been known that you can't.
  
  On the dodecahedron, turns out you can.
  
  It's also the best die in D&D.
  
  
  
• Hacker News wasn't actually down.  It's just that nobody could get there because BGP.  (Cloudflare)
  
  BGP considered harmful.
  
  
  
• Pinterest has decided it doesn't need a $90 million artist's rendering.  (SFGate)
  
  The company paid $90 million in penalties to terminate its lease agreement on a yet-to-be-completed office building.
  
  Expect more of this.  It will probably be ultimately good for everyone, except the SF city council.
  
  
  
• Apple is working on 5nm in-house GPU chips.  (Tom's Hardware)
  
  This is the undropped shoe of moving Mac to Arm.  I have less than no interest in buying another Mac, now or after the transition, though I might need to at some point just to compile code for it.
  
  After being delighted with my original Nexus 7 I bought an iPad as well.  The retina screen was great, but the operating system and user interface were terrible and - more importantly - could not be fixed.  Apple are doing the same to the Mac.
  
  

• Even Jonathan Swift would have trouble with this one.
  
  
  
  
  
  
• The reason not to burn down cities is that it might help Trump.
  
  
  
  
  
  
• Ugh.
  
  
  
  
  
  
• Overhead, without any fuss, the stars were going out.