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.




Apple pies are delicious. But never mind apple pies. What colour is a green orange?




59kb generated in CPU 0.34, elapsed 0.7883 seconds.
56 queries taking 0.4871 seconds, 318 records returned.
Powered by Minx 1.1.6c-pink.