• Chrome just crashed, take the entire Daily News Stuff with it.  Yay.  It did save the title.  Thanks Chrome.
  
  
  
• QB64 is an open-source QBasic-compatible compiler for Windows, Mac, and Linux.  (QB64.org)
  
  It looks pretty good.  Only major weirdness is that to maintain strict compatibility all the extension commands start with _.
  
  This looks like the perfect place to start with Imagine Basic.  Write a compiler that supports a subset of QB64, written only in that subset, and targeting Imagine assembler.  Write an Imagine assembler in that same subset.  Just like that, I'll have a self-hosting compiler.
  
  Easy peasy.
  
  ...
  
  Anyone got a good Write your own Basic compiler in Basic guide?  The assembler I can handle.
  
  
  
• Civilisation* has been announced for the Imagine!
  
  
  
  
  By pure serendipity this tileset was released today.  (Itch.io)
  
  It's part of a bundle that includes all kinds of neat stuff and which I immediately purchased.  I also tried to support the designer on Patreon but Patreon won't let me log in because they're retarded.
  
  Other titles announced for the Imagine include CitySim:
  
  
  
  And LoreWards:
  
  
  
  I don't know how well these will fit into 128k of RAM.  The original SimCity did come out on the Commodore 64, so that's a datapoint.  I may have to lose the unit and water animations unless you have the Imagine 1000D model with 256k; it will be interesting to find out.
  
  These tilesets are nice because they are complete; they provide all the graphics you need including things like leader avatars and UI frames.  A lot of the graphics sets on Itch.io provide one thing only - here's a forest, good luck with the rest of your game.  The other notable exception to this is if you buy the complete Time Fantasy bundle which contains about twenty compatible tilesets, plus objects, plus dozens of animated sprites for heroes, NPCs, and monsters.
  
  Graphics on the Imagine should look much like that though only about half that height - those screenshots are 512x512 and the Imagine runs at 480x270 well what do you know: Graphics on the Imagine should look about twice that good.  I took one of those images, zoomed in, and added some 1x1 pixel dots just to confirm what my eyes were saying, and those screenshots are zoomed in at 2x at the pixel level (plus whatever your browser does to make them big enough to see).
  
  So those sample screenshots represent roughly half an Imagine screen.  That's pretty good; I can certainly see a game being enjoyable at that scale.  (And after all, Kairosoft games run at 320x200 and I've played the hell out of those the last few years.)
  
  * Any similarities to games spelled with a Z are purely coincidental.
  
  
  
• Speaking of Imagine graphics I added another graphics mode that I thought up when I was looking at doing this in hardware on an embedded Arm chip.
  
  Basically it's half-resolution - 240x270 - in 512 direct colours.  That uses 9 bits from our 10 bit byte, so if you set the 10th bit to 1 it splits the pixel into two 16 colour full-resolution pixels.  You can freely mix low resolution in full colour with high resolution in limited colour, so for example the ocean in that last screenshot can be shaded exactly how you want.
  
  Update: That leaves 256 values out of 1024 unused.  I was wondering what to do with them then realised the simple answer: We have 32 colour registers, so use those for a second palette of 16 colours.  32 total colours in high resolution, and 512 in low resolution, on the same screen.  That's a really nice graphics mode if you're working with tiles and sprites, rather than drawing to a bitmap.
  
  Hardware sprites could use exactly the same mode, except that would limit them to 8 pixels wide (instead of 10).  There are 10 sprites so you could pair them for 5 16-pixel sprites per scan line, in up to 512 colours.
  
  I'm also looking at efficient ways to handle 8x8 and 16x16 tilesets, as an alternative to bitmap mode.  That could help make these games an imaginary reality.  With 16x16 tiles we could steal the sprite buffer and load in the tile indexes - once every 16 scanlines - which would leave the full bandwidth available for that 16+16+512 colour mode above.  And still have two sprites left for a cursor.  That's probably fine for Civilisation or LoreWards - those tilesets are indeed 16x16 and those games are turn-based and don't need a lot of sprites running around.
  
  (And if we're using the sprite buffer as a general-purpose buffer now, I might bump it up to 64 bytes, the same as the audio chip.  That will let you load a 30-wide tile map and 4 16-pixel sprites, all in this new 512 colour mode, which is pretty good for 1983.)
  
  The CitySim tileset though is 8x8 - those buildings are composed of lots of tiles stacked together - and you really want to see the cars and trucks running around.  That one pretty much has to be bitmapped.
  
  Also working on an RLL-compressed mode for overlays.  Let's say you have a 3d-rendered scene from your spaceship cockpit, but the cockpit itself is drawn in 2d and mostly static.  You can draw the 3d view directly to one playfield in high resolution 32 colour mode in VRAM (perhaps with fill mode enabled so you don't need to shade the polygons).  Then you can have a mostly-static RLL-mode cockpit overlay, in 16 colour RLL mode, in system RAM.
  
  Thanks to the RLL encoding, the transparent window only only uses 1/16th the normal bitmap memory and bandwidth.  You can shape and colour the opaque parts any way you like, while the transparent parts (or any solid colour) cause almost no overhead.  The RLL parts would be a massive pain to draw arbitrary updates to - totally impractical on a slow CPU - so the sections with lots of controls or displays you'd want to render as uncompressed scanlines.  Any pixels where you don't enable RLL it's just a regular bitmap.
  
  Update: Just realised this is also a brilliant way to extend sprites.  An empty full-screen RLL overlay uses 4k of system RAM and about 5% of the system bus.  You can even use the display list processor to entirely skip the parts where you don't need software sprites.  Or, using that mode from before, but with only 16+512 colours, we can get it down to 540 bytes and 0.4% bandwidth use for an empty overlay.  Yeah.  This is good.  This might be better than actual sprites.  
  
  Update update: So lets say if you turn off two sprites you can enable another playfield - after all we're saving the sprite pointer and position registers and the sprite buffer.  We can say that sprites 0-5 are always sprites, and 6-7 and 8-9 can be switched for additional playfields.  With normal pixel modes we could only do that by using half-resolution and saturating both the VRAM and system RAM buses, but with RLL mode we can do whatever the hell we like.  The demoscene would go nuts with this.
  
  
  
• The Poco X3 NFC is a pretty good phone for €229.  (WCCFTech)
  
  In fact it's a pretty good phone regardless.  Snapdragon 732G - two A76 cores at 2.3GHz and six A55 cores at 1.8GHz.  6.67" 120Hz 1080p screen.  64Mpx main camera, 20Mpx front camera, and three other little cameras along for the ride.
  
  6GB RAM, 64GB storage (the 128GB model is another €40), USB-C, headphone jack, and microSD slot.  The only box it doesn't tick is apparently wireless charging.
  
  On sale tomorrow in Europe, no news yet for the rest of the world.
  
  
  
• Magenta doesn't exist.  (Medium)
  
  The article discusses impossible colours and even provides examples - though since they're impossible the examples do require you to do the old stare at the X for thirty seconds without blinking trick.  If you manage that, though, you get to see a blue that is darker than black and a red that is brighter than white.
  
  Colour is about one third physics, one third biology, and one third bullshit.
  
  
  
• Elon Musk's reading list.  (Most Recommended Books)
  
  Max Tegmark, who is great, Sean Carroll, who is also great but who blocked me on Twitter when I pointed out he was talking nonsense about events in Portland, Iain M. Banks - several times, Robert Heinlein, Isaac Asimov, Frank Herbert.  Also both Adam Smith and Karl Marx, but that's okay so long as your read them both.
  
  
  
• Chrome fixed copying and pasting URLs.
  
  At some point it started turning URLs into URLs in this editor, so you had to go and un-URL them all.  Firefox didn't do that.  Now it's stopped doing that again.

Posted by: Rick C at Tuesday, September 08 2020 01:56 AM (eqaFC)

Posted by: normal at Tuesday, September 08 2020 06:43 AM (obo9H)

Posted by: kurt duncan at Tuesday, September 08 2020 11:04 PM (7AkDP)

Posted by: Pixy Misa at Wednesday, September 09 2020 12:31 AM (PiXy!)

Hide Comments | Add Comment

• HP Basic has a lot of commands.  Just building a spreadsheet merging all these versions of Basic into one is exhausting.
  
  
  
• The HP Omen 15 has the Four Essential Keys.  (Tom's Hardware)
  
  In fact, it has a regular desktop cursor key layout instead of the largely useless numeric keypad.
  
  It also has a Ryzen 4000 APU, two socketed DIMMS for up to 64GB RAM, and two socketed M.2 NVMe devices for up to however much storage you can afford.  The expandability and the standard cursor keys make for a great developer machine.
  
  It has an absolute swarm of I/O ports, including HDMI, mini DisplayPort, three USB-A 5Gb ports, one Type-C port, headphone jack, SD card, and wired Ethernet.
  
  Graphics are provided by an Nvidia GPU with options from the 1650 Ti up to a 2070 Super Max-Q which sounds like a season of Pretty Cure.
  
  Battery life on the model tested by Tom's Hardware was only 6 hours, where the Asus Zephyrus G14 got over 11 hours.  The Asus model only has one DIMM slot and one M.2 slot available, and lacks the FEK, so choices have to be made.
  
  
  
• A PDP-11/70 emulator.
  
  Not a download link for an emulator, but the whole thing running right there on the web page.
  
  
  
• Snap sucks.  (Uncertain Jatan)
  
  Log in to a recent Ubuntu installation.  Type df.  Who the actual fuck thought this was a good idea?
  
  
  
• Bronze age Europeans couldn't drink milk.  (Science Magazine)
  
  To be fair, they didn't have Milo.
  
  
  
• 64K Basic is 2MB.  (Basic-Lang)
  
  It's a stripped down version of Basic with no I/O facilities apart from PRINT, LOAD, and SAVE.  That's a little too stripped down, really.  Written in Rust, so at least you know it's written in Rust.
  
  Wikipedia has a list of Basic dialects.  There's slightly more than an infinite number of them.  But if I can find one suitable for writing a compiler, it will make it easier for me to build a self-hosting compiler of my own.
  
  Chances of cramming everything I want into the allocated 128k of ROM are slim, even though I can redefine the hardware at will to make the software easier.  I'll just make a prioritised feature list and when the ROM is full, it ships.  It will support loading additional functions from disk files - HP Basic does this with LOADSUB ALL FROM "graphics.bas" for example.
  
  
  

Posted by: Rick C at Monday, September 07 2020 04:38 AM (eqaFC)

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

Posted by: Rick C at Monday, September 07 2020 11:31 AM (eqaFC)

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

Posted by: Rick C at Monday, September 07 2020 12:41 PM (eqaFC)

Posted by: Jay at Tuesday, September 08 2020 10:40 PM (0jVI9)

Hide Comments | Add Comment

• 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

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

• 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

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