• 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.