What happened?
Twelve years!
You hit me with a cricket bat!
Ha! Twelve years!

Wednesday, September 23

Geek

Daily News Stuff 22 September 2020

Ugh Browsers Proxy Servers Edition

Tech News

  • There's another update out for Chrome already.  Does it fix anything?  It does not.

    Bah.  I'll test a workaround for this mess after I post the news stuff.

    Update: The problem was ENTIRELY DIFFERENT TO WHAT I THOUGHT IT WAS AND NOT A BROWSER ISSUE AT ALL.

    Also, fixed.

    Basically, Caddy (the proxy server we use) failed to automatically renew some of our SSL certificates.  Don't know why exactly, except that it's been running for several months without a restart.

    We've been running it for a couple of years at my day job without this happening, but we push config changes every couple of weeks so it never runs that long without a reload.

    Common JavaScript files for mee.nu live on a shared domain and are always loaded over HTTPS.  That stopped working a couple of days ago.  I'm kind of impressed by how few things broke.


  • Arm has announced two new server cores.  (AnandTech)

    The N2 - codename Perseus - offers a 40% IPC improvement over the N1 core that Amazon is using in its Graviton 2 server platform.

    That's quite a lot.  That performance will also be coming to the A79 or whatever they choose to call their next mobile core.  N2 is due out next year.

    The V1 on the other hand is their new performance core.  Yes, the 40% IPC improvement over their current best offering is now their mid-range core.

    V1 - codename Zeus - promises 50% better IPC than N1 at the same clock speed, plus better clock speeds, and double the floating-point performance of the N2.  Arm estimate overall V1 will be around 20% faster than N2.  And it's available to license today.  

    This is the core used by the SiPearl Rhea that I mentioned previously.

    The V1 is a maximum-performance damn-the-power-consumption design and will not be coming to mobile devices, but it's what Arm needs if they are to compete with AMD in the server space.

    Serve the Home has more.


  • Microsoft is buying Bethesda.  (Thurrott.com)

    Makers of the bad Fallout games.

    It's a shame Microsoft wasn't in the mood when Bioware was on the market.


  • Planet K2-315b has a surface temperature of around 180C (350C) and is "likely not habitable".  (CNet)

    It also orbits its star, EPIC 249631677, in just 3.14 days.

    EPIC 249631677 - let's call it Ted - is 57 parsecs from Earth and not exactly suitable for daytrips anyway.


  • Memory price trends, 1957-2020.  (JCM)

    Interesting to note that early on, vacuum tubes were cheaper than transistors.  I'm guessing though that even in the 50s transistors were a lot more reliable.


  • Okay, since I have that weird comment thing fixed, time to think about game programming on the Imagine.

    Let's take Civilisation - not the popular game, that's spelled with a Z.

    The Pangea tileset that inspired this is 16x16, perfect for the Imagine's tilemap mode.  Load the tiles into RAM once, create a map - a 100x80 world map is just 8k - use sprites for the units, and we're good to go.

    Except...  Not so fast.  Look at this example.

    http://ai.mee.nu/images/ImagineCivimap.gif

    We don't just have the background tiles.  The background tiles are overlaid by terrain and vegetation, rivers, roads, and railroads.  Rivers over terrain can be overlaid by road and railroad bridges. Resources and resource icons overlay terrain and vegetation.  Water is animated.  And over all that there's a rather literal fog of war for unexplored territory.

    Handling all that would require a separate 32-colour full-resolution overlay playfield, and the original Imagine 1000 can't quite manage that; it runs out of clock cycles to access everything.

    So instead it has to be done in pixel mode, and that eats 64k of RAM on top of all the tiles and sprites that need to be loaded.

    There's a reason Civilization - the one with the Z - didn't come out in 1983.

    Looking at the tileset, all the animations for all the units combined are only 40k.  But with 64k assigned to the pixel map, we only have 192k for all the tiles, sprites, code, and data combined.  In virtual 1983, 40k is a lot.

    This is where we say things like "combat animations require the optional 128k RAM expansion cartridge ($89.95)".


  • Ram Packs for Everyone!

    Figured out a two-chip solution that makes the Imagine about eleventeen times better.

    So, the design has three main chips: The CPU, the DSP, which we're going to completely ignore, and the video controller.

    There's 128k of system RAM - called shared RAM for reasons we'll get to in a moment - and 128k of video RAM.

    The video controller has two full buses, and can directly access both video RAM and system RAM.  It was ostensibly designed as a standalone controller for graphics terminals, needing just a suitable UART and ROMs for the code and fonts; one bus for video data and the other bus for everything else.

    It can also use both memory buses for video data.  This lets the Imagine display two playfields at 480x270 in 32 colours, at the cost of absolutely squashing CPU performance.

    While scanning through 1980s Toshiba component databooks looking for memory timing information, I noted in passing that there was a standard 74LS part for a 10-bit three-state bus transceiver.*  Caught my attention because I was looking up stuff for a fantasy 10-bit computer.

    Now, what happens if we take two of those chips, and put them on the data and address buses, so that on one side is the video controller and the two built-in memory banks, and on the other side is everything else?

    Well, if you don't have a RAM cartridge, not much.  The CPU is now free to access ROM on cycles when the video controller is accessing shared RAM, but that's a minor win because the built-in Basic is a compiler anyway.

    If you do have a RAM cartridge, though, that means the CPU can run at full speed even while the video controller is using all the bandwidth of both internal memory buses.  Instead of just giving you 128k of system RAM, it doubles the graphics capabilities of the system.  We can even do a tweak and split sprites across the buses so that they can each be 20 pixels wide instead of just 10.

    With a later 256k or 512k RAM cartridge things get even better.

    So yes, those two chips go in.  

    * The original part was a 74LS861, I think; that's the modern equivalent.


Apropos of Nothing

http://ai.mee.nu/images/NotSoMuch.png


Disclaimer: Fucking Elasticsearch.  28,000 records total.  4.5GHz CPU.  128GB RAM.  Seven second search times.

Posted by: Pixy Misa at 12:08 AM | Comments (5) | Add Comment | Trackbacks (Suck)
Post contains 1108 words, total size 9 kb.

Monday, September 21

Geek

Daily News Stuff 21 September 2020

The Clocks Were Striking Thirteen Edition

Tech News

  • The new version of Chrome has fucked up the comments.  I'll try to fix that tomorrow.  I can at least work around it.


  • China is at war with everyone.  (ABC)

    Including, of course, the Chinese people themselves.

    This is the Australian ABC reporting the story, not the US ABC, proving that a bunch of godless Lenin-worshippers suckling on the public teat for sixty years are more honest than the American mainstream media.


  • The US Air Force has designed, built, and flown a new fighter jet prototype.  (Defense News)

    In under a year.


  • I've done the instruction code layout for the Mirage M1100 CPU - the 11-bit variant.  It was instructive; for example there is now only one type of address postbyte, because one extra bit was enough to combine the indexed and extended register addressing modes.  For regular opcodes the extra bit defines the operand size - byte or word - and thus switches between 11-bit registers A, B, C, and D, and 22-bit W, X, Y, and Z.

    That freed up enough code pages that I could add in instructions to add or subtract 11-bit values to 22-bit registers, with and without carry.

    It also tells me that the best version of this will be the 13-bit one.  Originally that was going to be a weird dual-issue stack-based system, like an Analog Devices SHARC on crack.



    I might still do that version, but it would require an entirely new compiler and would generally be a pain in the bum.  The sane version will come first, but I'll need a new name for it.  (Pokes thesaurus.com.)  The Vision, that's just the ticket.


  • Rule 1 briefly suspended.  (Ars Technica)

    Rule 1 is of course never read the comments but that doesn't apply on personal blogs (mostly) or on Ars Technica's Rocket Report posts.

    Still on display though is the usual Ars Technica trait of aggressively downvoting anything you disagree with; the only difference here is that the point of disagreement isn't politics.

    Also, of course South Australia has a town with the most offensive name possible.


  • From watching gameplay videos on YouTube, I have a whole bunch of minimum specs for these systems, most of which I fortunately already had in mind.

    • 32 colours selectable from 512.  16 colours just doesn't quite do it.  64 is better.  More than 64 starts to make it too easy, and the results look noticeably different.

    • 480x270 resolution.  Yes, this is mostly to upscale nicely to a 1080p monitor, but also because 320x200 isn't actually very good and looks like crap on a large screen.

    • 4-voice music and 2-voice sound effects.  Can be stereo, mono, or split channels like the Amiga.  Music can be wavetable or PCM, or PSG or FM synthesis if the number of voices is increased (two PSG voices can produce one FM voice, for a start).  The Sharp X68000 which we heard in action with Dragon Spirit had 8-channel FM synthesis and sounded pretty good.

    • Some way to do parallax scrolling.  Dual playfields, a really fast blitter, a ton of sprites, tile rotation, something.

    • Hardware smooth scrolling in both X and Y.  Scrolling by a character at a time on an arcade-style game looks like poo.

    • Multi-colour sprites.  Four, or better, eight colours per sprite.  And at least eight of them.

    • So basically an Amiga.  Huh.


  • So in this parallel and much nicer reality, these systems came out one after another starting in 1983 with the 10-bit Imagine, followed in 1984 by the 11-bit Mirage, the 12-bit business-oriented Dream in 1985, then the 13-bit Vision and the 9-bit Phantom in 1986.

    Before 1983 you couldn't meet the specs above at a sane price; by the mid-90s systems were way more complex than anything I want to emulate.  The SNES came out in 1990 and already the video chip in that is Nyarlathotep in silicon form.

    My window of interest essentially starts in 1983 with the Fujitsu FM-7 and ends in 1992 with the Sharp X68000 Compact, the last model with an original-generation 68000.  But that's plenty of room to play around in.


Twelve Hours Worth of Chiptunes Music Video of the Day



Via the X68000's Yamaha OPM 8-channel FM synthesizer.  Don't say I never take you anywhere.


Disclaimer: Ah, there's the music from Eco.  Wait, stop changing scenes and making it change music tracks, go back to-  Ah, thanks.  Wait, you did it again, stop that!

Posted by: Pixy Misa at 11:17 PM | Comments (3) | Add Comment | Trackbacks (Suck)
Post contains 749 words, total size 6 kb.

Sunday, September 20

Geek

Daily News Stuff 20 September 2020

Dundundundundun Edition

Tech News

  • Had the soundtrack to a side-scrolling shooter from the Amiga running through my head this evening.  Could not even remember the names of any of the side-scrolling shooters I played back then.  So I asked YouTube.

    It was Menace.



    That track, the one that plays right at the start, that's what I had stuck in my head.

    If you didn't play this game on the Amiga, though, you would have had completely different memories of it.  Mostly sad ones.



    Menace was created by DMA Design, who also created Lemmings and subsequently a little title named Race'n'Chase.

    Better known today as Grand Theft Auto.


  • Just watching that video I can see the Amiga is using:

      •  Dual-playfield mode (for parallax scrolling).
      •  Hardware sprites.
      •  Blitter objects.
      •  Copper (display list) programming to change the video mode on the fly.
      •  Four-channel PCM audio.  Well, I can't see that one.

    The other three systems have none of those features, and as a result those ports of the game all kind of suck.


  • Went out to lunch today with my brother and sister-in-law, who live locally.  Most things were back to normal, the shopping mall was bustling, and the asian fusion restaurant that does the amazing gluten-free pad siew was still in business and open.

    The Apple store, on the other hand, had a queue where they took your details, sanitised your hands, and gave you a mask to wear inside.  We did not go into the Apple store.


  • Behind every warning label lies a story.  The same is likely true of this motherboard with 20 USB ports.  (Tom's Hardware)

    I'm not sure I want to hear it though.


  • Spider Man, Spider Man, does whatever a 105GB download can.  (WCCFTech)

    That's only approximately one million Imagine 1000 ROM cartridges.


  • Apple has reportedly booked 100% of TSMC's 5nm production capacity.  (ExtremeTech)

    To be fair, Apple, or rather the fools who buy Apple's overpriced toys (cough ignore the retina iMac to my left cough) paid for TSMC's massive CAPEX that enabled the 5nm process in the first place.


  • If at first you don't succeed, try, try, try, try, try, try, try, try, try, try, try, try, try, try, try, try, try, try, try, try, try, try, try, try, try, try, try, try, try, try, try, try, try, try, try, try, try, try again.  (Phoronix)

    Intel have submitted patches to include support for their secure enclave in Linux.  For the 38th time.


  • It took me about two minutes to identify Menace on YouTube from just a half-remembered theme tune.  Find a video of the top ten Amiga side-scrolling shooters and flip through them going nope, nope, nope, cool but nope, THERE, THAT'S IT!

    Some people take a bit longer to find the game they're nostalgic for. (Break Into Chat)

    Like, seven years longer.


  • Russia has announced plans to explore Venus.  (EuroNews)

    And to be fair, Russia's track record with its Venus probes is as good as its record with its Mars missions is bad.


  • I've moved the launch of the Mirage (the 11 bit architecture in my emulator) back to 1984 and downgraded the hardware to match.

    It now has specs very similar to the original Imagine from 1983, but instead of 128k of VRAM, has two video controller chips each with 64k.  And the floppy drive capacity will be 900k, since double-sided 3.5" drives came out in 1984.

    It has just two graphics modes, compared to approximately seventeen thousand on the Imagine, but they are really nice graphics modes:

    Mode 1: 480x270 in 32 colours or 240x270 in 1024 colours, switchable on a two-pixel boundary.
    Mode 2: 480x270 in 32 colours, or 960x270 in 4 colours with 4 palettes, switchable on a two-pixel boundary.

    Update: Three modes.  When I figured out Mode 3, I realised there's no way they wouldn't have pushed it in somehow.

    Mode 3: 320x270 in 256 colours with 4 palettes, switchable on an eight-pixel boundary.

    And you can overlay a Mode 2 playfield on a Mode 3 playfield, and modulate the colours on one-third pixel boundaries.

    The pixel data from the two VDCs is XOR'd and fed into a 1024x12 external palette RAM.  (I looked it up and suitable chips were indeed available in 1984, though I'm not sure how much they cost.)

    By default VDC1 would output the low 5 bits and VDC2 the top 5 bits of the final pixel value, so they combine independently to provide one of 1024 colours. And that means you can precisely define transparency, translucency, and shadow effects, or just output 480x270 in 1024 colours, or anything else that is not actually mathematically impossible.

    If you output two 1024-colour low-resolution playfields, though, things will get weird.  I might not bother to fix that.  Sometimes weird is good.

    I think the 11th bit in the instruction encoding will be used as a size bit - byte or word.  That's a really simple update to the 10-bit architecture but a very nice one; it makes the four index registers (WXYZ) true general-purpose registers. On the Imagine they can be used for arithmetic via LEA, and just gained shift operations in the weekend opcode cleanup, but they don't have the usual AND/OR/XOR, or even subtraction.  And while LEA can do A=B+C addition, by design it doesn't set the carry bit and can't be used for extended precision arithmetic.


Disclaimer: Me listening to 30-year-old Amiga music: Wow, eight-bit PCM audio was pretty rough.  Me listening to 30-year-old Atari, PC, and C64 music: Oh, right.

Posted by: Pixy Misa at 11:31 PM | Comments (3) | Add Comment | Trackbacks (Suck)
Post contains 927 words, total size 8 kb.

Saturday, September 19

Geek

Daily News Stuff 19 September 2020

Pieces Of Ten Edition

Tech News

  • Now if you want to take some pictures of the fascinating witches who put the scintillating stitches in the britches of the boys who put the powder on the noses of the faces of the ladies of the court of King Caractacus you're too late!  (TechReport)

    Because they've just sold out.

    They being the RTX3080 and both models of the PlayStation 5.


  • The WeChat and TikTok bans kick in on Sunday.  (Tom's Hardware)

    Good.


  • VueJS has hit 3.0.0.  (GitHub)

    I haven't done anything real in it, but it does seem to be the least sucky of the major JavaScript frameworks.


  • Based solely on watching videos of Dragon Spirit I have retroactively determined that the Imagine included a cartridge slot.  It could take ROM cartridges mapping up to 128k of address space (plus optional bank switching) or a RAM cartridge for an additional 128k of system RAM.

    The system assigns a single 10-bit bank register to the cartridge port, and leaves it up to the cartridge hardware to determine how to deal with it, but in theory it could support 1024 128k banks for a total of 128M of ROM (or indeed RAM).


  • That means that the big feature of the Imagine 1100 wasn't expandable RAM, but that it came with 128k of system RAM and 256k of video RAM.  You could use the same 128k RAM cartridge to bring system RAM up to 256k, but video RAM wasn't expandable.

    The 1000 and 1100 used page mode RAM, while the 1200 used faster nibble mode RAM, so RAM expansion cartridges weren't perfectly compatible.  They did work, but ran slower than system-specific models.


  • In other fantasy computer news I needed exactly one and a half bits to add a whole new exciting family of addressing modes to the Imagine and clean up an untidy corner of the instruction set.

    I found them.

    Now PC relative addressing only has a range of -128 to +127* instead of -512 to +511, but every instruction has access to special hardware registers, alternate register banks, and on-chip RAM, if they exist in this particular implementation of the CPU.

    So, for example, the DSP variants define AL and AR as left and right audio accumulators, and multiple banks for ABCD and WXYZ, but there was no standard encoding for accessing those registers outside of the specific MAC and BANK instructions.  The OUT $01E, AR to output a calculated sample to the right audio DAC had to be custom crafted into the DSP.

    This new method also encodes 10-to-20-bit conversions like LD A, WL which previously was only possible via LD AB, W - and even that was a special instruction distinct from standard LD.

    These methods require a two-byte instruction encoding, but the second byte is similar to the format used for indexed addressing, rather than a big nasty ad hoc mess.

    This is also how supervisor mode (on variants with a supervisor mode) access the segment and address extension registers (on variants with segment and address extension registers), and how multi-threaded versions spin up and synchronise threads.  None of that will be present in the initial version, but it's all defined so I won't trip over it later.

    * Unless you use indexed mode with P + immediate offset, which has a full 10-bit or 20-bit range but uses one or two extra bytes.


Retro Gameplay Video of the Day



Quick precis: MSX1 bad.  MSX2 pretty good actually.  Also, most MSX systems apparently had two cartridge slots.  Hmm.



Bonus Retro Gameplay Video of the Day



This is Dragon Spirit captured from original arcade hardware.  The video isn't as sharp as from an emulator, but it's the real deal.

Listening to the sound, I'm pretty sure it's using three music voices plus two voices for sound effects.  There are a number of places where you'd expect a fourth instrument to come in, and it never does.

The Imagine can reasonably do five voice wavetable synth at 3MHz, and I've assigned eight sets of registers to the DSP so the other three sets can be used for sound effects, which require less complicated processing.  (The hypothetical Imagine 1200 from 1987 doubles everything, so 10 wavetable voices and 16 sets of audio registers.)

I really like the first couple of tracks here.  Super catchy.


Extra Bonus Retro Gameplay Videos of the Day

Last ones, I swear.

The first is Dragon Spirit on an MSX2 system - 3.5MHz Z80A, 256k of system RAM (though I believe it ran in 64k), and 128k of video RAM.

The second is Dragon Spirit on a Sharp X68000 - 10MHz 68000, 1M system RAM, 512k bitmap video RAM, 512k tile video RAM, and 32k sprite RAM.




The X68000 version definitely looks better, but the MSX system isn't bad at all.  I believe this was a disk-based game and not a cartridge, so that's actually running from just 64k of RAM.  There are some odd hitches in the music on the MSX that aren't present on the X68000, possibly because it had an 8 voice sound chip rather than just 3.


Disclaimer: Bleep bloop.

Posted by: Pixy Misa at 06:13 PM | Comments (4) | Add Comment | Trackbacks (Suck)
Post contains 861 words, total size 7 kb.

Geek

Daily News Stuff 18 September 2020

7-4+2=1 Edition

Tech News


Atari 800XL Gameplay Video of the Day



Some of these games are really impressive for 8-bit hardware dating to 1979.  But there is a reason I'm targeting the Imagine at a notch above most of the real 8-bit systems, a little above even the MSX2 or the FM77.

There are a ton of MSX gameplay videos on YouTube, by the way.  The original MSX was rubbish, but the MSX2 wasn't bad.  People have even got it to run a multi-tasking GUI with TCP/IP.

A lot of the MSX2 games are still pretty bad, but some look quite good, like Dragon Spirit.  Here's the MSX2 version:



This seems to be the original arcade version, emulated via MAME.  It's certainly better looking than the MSX2 could manage.



Disclaimer: Not that I plan to spend the entire weekend watching them.  Not the entire weekend.

Posted by: Pixy Misa at 12:30 AM | Comments (32) | Add Comment | Trackbacks (Suck)
Post contains 445 words, total size 4 kb.

Friday, September 18

Geek

Daily News Stuff 17 September 2020

Zed Eighty Edition

Tech News

  • Sony ran a gender reveal for its new console, devastating three continents.  (AnandTech)

    $499 for the full version with Blu-Ray drive; $399 for the digital-only version.

    That pushes back fairly hard against both the $299 Sbox and the $499 Xbox.  Smart move by Sony, except for the part where they're probably losing money at that price point.


  • Numbers, how do they work?  (AnandTech)

    Sony also announced the Xperia 5 II, a companion to the Xperia 1 II.

    It's not cheap at $949, but it does have a Snapdragon 865, 2520x1080 120Hz OLED display, 8GB RAM,  128GB or 256GB of flash, microSD slot, headphone jack, wireless charging, and IP65 and IP68 ratings.

    Oops.  Wireless charging is only on the 1 II.


  • Taking the Tiger out for a spin.  (Tom's Hardware)

    A look at Tiger Lake on an Intel reference laptop, with some benchmarks run under Intel's watchful eye, so take it with a grain of salt.  Single-threaded performance - on Geekbench - appears excellent, clearly faster than current Intel laptops and beating a Ryzen 4800U by 40%.  That's a lot, but it is just one benchmark.

    And on the other hand, video encoding with Handbrake ran twice as fast on the 4800U.

    The Intel chip is running at 28W, but for single-threaded tests that is only likely to bump the clock speed up by 2% or so, not a significant factor.

    Intel's Xe graphics more-or-less catch up with AMD too.  Both systems tested used LPDDR4X-4266 RAM, and while AMD is still faster for gaming by 5-20% at 15W, it no longer squishes Intel like a bug.  When the Intel chip is freed up with a 28W TDP it can outpace AMD's 15W part, but then AMD has a 35W part, so you can play that game forever.

    Looking forward to see if that single-threaded performance is real across a broad range of benchmarks, and to what AMD delivers with Zen 3.

    Update: AnandTech have the same Intel reference unit and confirm the great single-threaded performance across a wider range of benchmarks.  They ran the SPEC 2006 and 2017 suites and posted individual as well as composite scores, so there's a lot more than one Geekbench score to chew on here.

    Short summary: If you run Dwarf Fortress, Intel's 11th gen chips are 50% faster than AMD.  If you run Blender, AMD is well over twice as fast as Intel.  And if you run Civilization 6 on integrated graphics, you're a masochist.


  • An LL(1) expression parser in exactly 100 lines of Python.  (GitHub)

    Thanks, I'll take it.

    The only imports are enum and re - the Python regular expression library - and it only uses re to check if a string of characters is numeric, which you can do with the isdigit() method.  So it should be nearly as simple rewritten in Basic.


  • That nibble-mode trick I used for the Dream means I can reasonably offer an upgraded version of the Imagine in Imagine-Emu.

    The Imagine 1200 was launched in 1987.  It offered a faster CPU and DSP - 6MHz vs. 3MHz - with 256k system RAM and 256k video RAM, using 100ns nibble-mode chips to deliver 12MB/sec of bandwidth on each bus.  The system also replaced the earlier 500k and 1M double-density floppy drives with a new extended density (ED) drive with a capacity of 4M.

    Which means that all the tricks the original model could do by stealing cycles on the system bus, this model can do just in VRAM.  And then do more tricks by stealing cycles from the system bus again.

    This version will have 256 bytes of cache on the CPU and DSP, which will speed up the cycle-accurate emulation mode but slow-down the free-running mode.


  • Whatever happened to the Z800?  It was announced in 1980 but never appeared.  Turns out it did eventually show up, much delayed, renamed, and converted to CMOS, as the Z280.

    And it a strange little beast it was too.  Instructions could still only directly address 64k of RAM at a time, but it had a complete paged memory management unit capable of mapping 16MB of RAM, a supervisor mode, and a 256-byte instruction cache.  It even supported multi-processor configurations, as if someone really, really wanted to build a Z80-based Unix system.



    The Z800 / Z280 was a commercial failure, as was the Z380, a 32-bit version of the Z80 with eight banks of registers.  The Z180, though, based on the Hitachi 64180, is still being made today, as is the eZ80, which for under $10 delivers the performance of a 150MHz Z80.  Meaning that by today's standards it's dead slow.


Disclaimer: In the future, everything will be dead slow by today's standards for fifteen minutes.

Posted by: Pixy Misa at 12:37 AM | Comments (2) | Add Comment | Trackbacks (Suck)
Post contains 795 words, total size 6 kb.

Wednesday, September 16

Geek

Daily News Stuff 16 September 2020

640k Edition

Tech News

  • The numbers are in, and the RTX 3080 is a solid 50% to 60% faster than the RTX 2080.  (Tom's Hardware)

    That means it easily beats the 2080 Ti as well; right now it's the fastest video card there is.

    The 3080 has nearly three times as many CUDA cores as the 2080, and similar clocks, but isn't remotely close to three times the performance.  That's because half the cores in this architecture are the same flexible FP/INT cores as before, while half are simpler FP-only cores.  A 32-bit integer multiplier is actually about twice the size of a 32-bit floating point multiplier, so it makes sense to save space on a chip this big.

    So if the code for a given game uses lots of integer operations, it won't scale nearly as well on this hardware as the raw floating-point numbers would suggest.  But if Nvidia had made all the cores FP/INT, the chip would have been too large to manufacture on Samsung's 8nm node.  Something had to give.

    And there's still the 3090 to come.


  • Apple has announced new iPads.  (AnandTech)

    The iPad Air comes with the new A14 chip, which is the first volume part I know of to come out of TSMC's 5nm process.  The A14 is...  Well, it's slightly faster than the A13.

    The 64GB iPad Air costs A$899, which is exactly as much as my 64GB Retina iPad from 2013.  It does have slightly more pixels, but still no microSD slot.


  • Pure Storage has acquired Portworx in a deal worth $370 million.  (ZDNet)

    I have heard of at least one of those companies.


  • China has immense capacity and expertise for assembling complex equipment.  But without access to technology from the West, it is stuck in 2007.  (New York Times)

    I include Japan, South Korea, and of course Taiwan as part of the West.

    Basically, Huawei is fucked, and the CCP is resolutely determined to make sure it remains fucked.  (Free Beacon)

    Shame.  They made nice tablets.


  • I ran the numbers to work out what sort of hardware the Dream - the 12-bit model in our lineup - would have had, given just two parameters: First, it launched around 1985, and second, it had a 640x360 display.

    The Imagine is a home computer powerful enough to run business apps; the Dream I'm designing as a business computer flexible enough to run decent games.

    So, first, what's the pixel clock for 640x360 @ 60Hz?  I worked out for the Imagine that at 50Hz that resolution needs around 16MHz - and that my existing HSYNC rate of 18.75kHz was within spec for a 720x350 monochrome monitor.  So for 60Hz we just add 20% to both numbers, and we get a 19.2MHz pixel clock and a 22.5kHz HSYNC.

    If we divide the pixel clock by 4 as the base system clock, we get 4.8MHz, and divide that by 22050 and we get 213.3 cycles per line.  Round that down to a nice even 212, multiply back up again, and...  We have a 4.77MHz system.  Huh.  This was meant to be.

    Now, how do we get the data for a 640x360 display in (say) 64 colours, using commodity 1985 DRAM and a 12-bit bus?  On the Imagine I originally wanted a 5MHz memory clock, looked up the databooks, and realised that wasn't feasible in 1983.  Instead I set the clock to 3MHz but used page mode to read two bytes per cycle.

    On the Dream I'm going to use a different readily-available trick from the early 80s, nibble mode, where a common 256k x1 DRAM chip could stream out four successive bits in a row at much faster rates than regular random access.  Looking through Toshiba's 1984 memory databook, I could hit a 2MHz bus clock with nibble mode on using 150ns RAM, 2.5MHz with 120ns, and 3MHz with 100ns.

    Conveniently, 120ns RAM, not too exotic, lets me pin the memory clock at half the CPU clock.

    So the video controller has 106 memory cycles per scan line (half the 212 we calculated earlier), each delivering four (12 bit) bytes using nibble mode.  Assuming 80 cycles are in the visible area (it was about 75% of the scan line on a typical monitor, so that's close enough) we need 8 pixels per cycle to get a 640 pixel line, and that gives us 6 bits per pixel for 64 colours.

    Which is not a cosmic coincidence; that's what was supposed to pop out at the end from the numbers I fed in at the start.  It just means I did the maths right.

    The only problem is that it still can't do 80 column text mode.  80 columns of text in graphics mode, sure, no problem at all.  80 column text mode, no.  We'd need 80 random accesses, because the character data won't be sequential, and we only have 80 memory cycles per line, no cycles free to read the text map.

    For that we'd need a separate text RAM and....  Well, I could just shove a separate text RAM into this one.  I ruled it out for the Imagine to keep it cheap and simple for the home market, but this is explicitly a more business-oriented machine.

    The Dream won't have the dual-bus architecture of the Imagine: The video chip can't directly access system RAM, and the CPU can't directly access video RAM.  But that leaves me lots of imaginary pins free on the chips to do other stuff, such as having 64k of text RAM in addition to the 256k of main video RAM.

    Do the numbers work out?

    - 12 pins for the CPU interface
    - 12 + 9 pins for main memory
    - 12 + 8 pins for text memory
    - 12 pins for pixel output

    Total 65, plus a minimum of a dozen more for control signals.  With an 84-pin PLCC we can just about do it.  Okay.  That's what it is.  Three 4464 chips in page mode for the text or tile data, twelve 41256 chips in nibble mode for the character cells or bitmap data.

    Hmm.  Does the Dream always run in character mode?  Maybe it does.  Maybe it has no pure bitmap mode, just 4096 user-defined characters.  I was thinking of giving this thing hardware windowing, like the Intel 82786, but the hell with that.  It's going to be a 12-bit Microbee Gamma.

    I wonder if there's a YouTube video of that one?  Those things were rarer than hen's teeth, and I only ever got to touch one for a few minutes at a computer show.



    Looks like someone got to hang onto one for slightly longer than that.  It had a 720x350 display - MDA / Hercules resolution, but in 4096 colours.  So I'm pretty much on target.

    Unlike the Amiga - and very much like the TRS-80 Model 16 - the Microbee Gamma could run Unix.  It had an 8MHz 68000 and two 4MHz Z80s, one to handle display tasks, and the other to handle I/O.  The separate I/O processor allowed the 68000 to properly handle page faults, which would otherwise require a 68010 or later chip


  • I can probably figure out a way to line up the character cells so that you can draw to them as if they were a bitmap.  I'm not a total sadist.  At least not when I'm the one who's going to be writing the graphics library for this beastie.

    To unpack a bit: The Intel 82786 (IEEE.org) let you define areas of the screen to be drawn from different areas of RAM - hardware windows - though you could only have a limited number of those because there were only so many registers on the chip.

    With the Dream's bus design, hardware windows in 640x360 64-colour mode would have to align to 8-pixel boundaries, because we can only switch hardware windows on a new bus cycle, and we read 8 pixels per bus cycle.  And we read 8 pixels per bus cycle because it's the only way we can make it fast enough.

    Now it just so happens that our character cells are also 8 pixels wide.  If graphics are drawn into character cells, we can do proper bitmapped hardware windows in text mode.  Which means we can move and scroll windows 32 times as fast as moving the actual pixels - two bytes instead of 64 bytes for an 8x16 64-colour character cell.

    And this is precisely what the Microbee Gamma did, and it worked really well.  The original Amiga didn't live-drag window contents when you moved a window, just the outline.  The Gamma smoothly dragged the window contents, even if they were actively updating at the time.  For 1986 - I think I saw it in '86 - that was really neat.

    One minor side-effect of that was that the Gamma had wide window borders - you can see that in the video above.  Yes, that was partly because it was a mid-80s system with a relatively low-resolution monitor, but also because the window borders had to be whole characters.

    Anyway, this is the Dream.  The Imagine has a squintillion different graphics modes - different bit depths, pixel packings, switchable palettes, switchable resolutions, text mode, graphics text mode, fill mode, HAM mode, RLL-compressed RGBA overlays with selectable alpha channel arithmetic...

    The Dream does none of that.   Text mode is graphics mode and graphics mode is text mode.

    Update: Yes, we can draw into the character map as if it were a 1024x512 64-colour bitmap, albeit only at the base 2.385 MHz memory clock, not using nibble mode.  We can copy rectangles in nibble mode, though.  Or you can view it as 4096 programmable 8x16 characters with 64 colours.

    There will also be sprites of some sort.  Let's say 16 of them, 16 pixels wide, eight colours, switchable to eight pixels wide and 64 colours.  That fits nicely into our bus cycle and our horizontal blanking period. 

    Update 2: Or I could go with the previous plan and have a separate sprite chip with its own 64k of RAM.  That works nicely, except that now the system has 704k of RAM.  Oh well, can't have everything.  It would help the Dream compete with the Imagine's clever hardware -compressed overlay system, which allows arbitrary numbers of sprites.

    Update 3: No, I have it!  The text RAM is the sprite RAM.  So you can have this neat accelerated super text/tile mode with 16 sprites, or a regular bitmap and 512 sprites.  And now we have 640k again.  This makes a lot of sense.  Why would a business machine have an overpowered sprite processor?  Because the hardware designers snuck it in as an alternate mode for the 80-column text system.  Just don't ask me why it has an overpowered audio processor.

    There's a trick I might steal from the SNES as well - the SNES was an amazing assemblage of tricks.  It could hardware scroll individual segments of the screen.  In text mode the Dream will use two bytes per character - one to select one of 4096 characters, the other to select from 64 foreground and background colours.

    In tile mode - pseudo-bitmap mode - we don't need to select those colours because the tiles themselves are in 64 colours.  So we can steal 7 bits to allow us to rotate the contents of the cell horizontally and vertically.  And still have 5 bits left to do other stupid stuff with.

    This won't scroll a whole area, but if you want to animate a tiled background, you can do it pixel-smooth just by updating the text map.  With one tweak to the video hardware, to pre-fetch a zeroth byte on each line, we can smooth-scroll an entire screen containing multiple independent smooth-scrolling windows just by updating the text map.


  • Oh, and the other thing.  The Dream will have 256k main memory, 256k graphics memory, 64k text memory, and 64k for the sound chip.  So it runs at 4.77MHz and has 640k of RAM.


  • What if someone wants to run Imagine-Emu on a Raspberry Pi?  Does Nim even work on the Raspberry Pi?  What's that, Lassie?  It not only works, it's available as a standard package?

    Well, okay then.  Transpiling via C has its benefits.


Disclaimer: I still prefer Crystal though.

Posted by: Pixy Misa at 10:58 PM | No Comments | Add Comment | Trackbacks (Suck)
Post contains 2057 words, total size 14 kb.

Geek

Daily News Stuff 15 September 2020

Gone Rogue Edition

Tech News



Disclaimer: And stay out.

Posted by: Pixy Misa at 03:41 AM | Comments (6) | Add Comment | Trackbacks (Suck)
Post contains 309 words, total size 4 kb.

Tuesday, September 15

Geek

Daily News Stuff 14 September 2020

Oh Yes Edition

Tech News

  • How to write a Basic compiler in Python, Part 3: Code generation.

    I knew I'd blogged about something I could use.  Now, this does compile to C, but it compiles to really dumb C, s=s+c; b=b+1; level C.  Basically it's used as a portable assembler.  That's fine.

    And it's self-contained, not using any lexer or parser libraries, so it's a good starting point for something that will eventually be translated into itself.


  • Writing A Compiler In Go might also be a useful source.

    It takes a similar approach - no tools or libraries used - to produce a complete compiler for a simple programming language.  Of course I'm no Go programmer, but I can read Go code.  Mostly.  Had to for work.  Don't ask.


  • Nvidia is buying Arm for $40 billion.  (AnandTech)

    This has made a lot of people very angry and been widely regarded as a bad move.


  • Microsoft announced a major win today.  (Thurrott.com)

    Not buying TikTok is probably the company's smartest move since they didn't buy Yahoo.


  • I always thought that the claims coming from Nikola seemed a bit overblown.  (WCCFTech)

    Of course that also seemed true of Tesla and SpaceX, and yet they delivered the goods.


  • Your government at work.




  • Adjusted the hardware design of the Imagine just a little.  Basically, the idea is that the Imagine's CPU is a microcontroller with multiple register banks for fast interrupt servicing - like the Z80 and 8051 - and the DSP is a variant of that, with eight banks of the user registers but only one bank of system registers.

    The DSP also has a nominal 256 bytes of on-chip mask-programmed ROM containing a set of wavetable synthesis algorithms.  These changes achieve two things: It makes it really a wavetable synthesis chip, albeit one developers can tinker with; and it drastically reduces activity on the system bus.  The initial version of the design would have used around 70% of the bus for 5 stereo voices; this version is a little under 10%.


  • I might steal a trick from the HP 150 and have text mode on the Imagine double the pixel clock.  It has the bandwidth to do this; text mode basically wastes one byte every time it reads the character data, so it makes no difference if it reads and uses two bytes.  That would allow it to output readable 80-column text on colour screens (960x270 with the new subpixels), and beautiful 80-column text on monochrome screens (now 1280x360).  Need memory for those fonts though.


  • Working on an emulator generator.  Given the processor definitions, it spits out Nim code for the CPU-specific emulator class, an assembler, a disassembler, and a simple machine-language monitor like the old MS-DOS DEBUG.

    The next step would be to have this spit out a code generator back-end for the compiler as well.  That is probably possible.  Certainly possible for the 10, 11, and 12 bit models, which all ended up with the same underlying Super 6809 design just with progressively more and larger registers.


Disclaimer: For small values of "work".

Posted by: Pixy Misa at 12:35 AM | No Comments | Add Comment | Trackbacks (Suck)
Post contains 519 words, total size 4 kb.

Monday, September 14

Geek

Daily News Stuff 13 September 2020

Pieberry Edition

Tech News

  • Raspberry Pi overkill for you needs?  The Iconikal SBC is $7.99 on Amazon.  (Tom's Hardware)

    That includes - or included; it's currently sold out for some reason - a Rockchip RK3328 with four 1.5GHz A53 cores, 1GB RAM, a free 16GB microSD that you probably shouldn't trust, a power supply, and a 16x2 character LCD screen.


  • The next SpaceX Starship prototype will have the final nosecone and control surfaces and attempt a 60,000 foot flight.  (Tech Crunch)

    Per explodia ad astra.


  • Trying out ASRock's DeskMini X300 with Ryzen 4000G.  (WCCFTech)

    The first time I saw a picture of this thing I thought to myself, what a crappy, cheap case.  Turns out it was more of a crappy, cheap photograph; it's brushed aluminium that they somehow made look like poorly-molded plastic.

    It's a little larger than a NUC - it's a standard mini-STX form-factor measuring 6" x 6" x 3" where the typical NUC is 4" x 4" x2" - but on the other hand it can fit APUs up to 65W, two M.2 NVMe drives, and two 2.5" SATA drives.

    As expected, with a Ryzen 4000 APU it goes vroom.  Not recommended for overclocking though.


  • Windows 10 is getting a new Start Menu.  (Bleeping Computer)

    I only ever see the default start menu for as long as it takes me to install Start10, so I really couldn't comment.  It will suck though, that much is certain.  Couldn't comment apart from that it is certain to suck.


  • I should make the MUL, DIV, and MAC instructions on the Imagine two bytes, shouldn't I?  It won't affect the performance at all, except if you're multiplying by a 10-bit immediate value, and it frees up two whole pages of opcodes.


Retrocomputing Video of the Day



This looks a lot like the HP 200 Model 16, a tiny 68000-based workstation.  It's not, though; it's the HP 150, a tiny 8088-based touchscreen PC.

He's going to do a follow-up video on the disk drive unit, which is the same one as the Model 16.  I'll be interested to see that, since I've heard but can't confirm that these drives ran at 600 RPM, twice as fast as any normal 3.5" drive.

He notes an interesting point on the text mode used on this and other old HP devices.  The 150 has an 80x27 text display made up of 9x14 pixel characters.  But it then says fuck it, I'll do what I want and shifts individual pixels by a half pixel width or widens them by one third as needed to make individual characters more legible.

That's some trick.  Makes me want to reproduce it in my emulator, though you'd need a 4320-pixel-wide display to do that exactly.


Disclaimer: It's basically a bunch of dinosaurs in an industrial blender.

Posted by: Pixy Misa at 12:23 AM | Comments (5) | Add Comment | Trackbacks (Suck)
Post contains 473 words, total size 4 kb.

<< Page 1 of 501 >>
143kb generated in CPU 0.11, elapsed 0.573 seconds.
58 queries taking 0.4957 seconds, 372 records returned.
Powered by Minx 1.1.6c-pink.
Using https / https://ai.mee.nu / 370