Saturday, September 12

Geek

Daily News Stuff 11 September 2020

Together In 12-Bit Dreams Edition

Tech News

Disclaimer: All the trees are gone / And the sky is orange.

  • While I work on the Imagine emulator, I'm going to start figuring out the specs of the Dream, its non-existent 12-bit cousin.

    I'm going to position the Dream as a late-1984 release, just in time to get clobbered by the Atari ST and the Amiga if it had ever existed. But let's make it at least somewhat competitive.

    • 4 MHz 12-bit CPU
      • Or possibly 4.125 MHz.

    • 128k ROM
      • I'm going for the Basic compiler in ROM again here, and it's going to be the same Basic just recompiled. I'm not going to write that twice!

    • 128k system RAM, upgradeable to 256k on board, 512k 768k maximum with two expansion cards
      • I'm envisaging this as a small (pizza box) desktop, where the Imagine is more the classic wedge-shape integrated system, so it can have a larger motherboard with room for RAM upgrades.
      • The C128 launched at the beginning of 19845 with an optional 512k upgrade.

    • 128k video RAM, upgradeable to 256k
      • With the 120 to 150ns DRAM of the era, we can get a 4MHz memory cycle - the BBC Micro managed that in 1981. But at this speed we can't do the page mode trick of the Imagine to get two bytes per cycle. There's not enough time.

        Instead, the Dream can read two bytes per cycle if it's the same page but from alternating memory banks. Programmers have to specifically lay out video memory so that it can be read back interleaved.

    • 640x360, 64-colour graphics, 50 Hz
      • That's a big upgrade over the colour mode on the Imagine. Maybe too much? It's not really pixel art any more. Well, once you put it on a modern 27-inch monitor it's pretty pixelly, I guess.

        On the other hand, that mode would use almost all the available VRAM on the base configuration so it likely wouldn't be used much for games.
      • Lower resolution modes of 320x360 and 320x180 with up to four independent playfields.
      • 1, 2, 3, 4, 6, 8, or 12 bits per pixel. Yay for having lots of factors.
      • There's no reason it can't also do 480x270 at 60 Hz.  Same HSYNC rate, 12MHz rather than 16 MHz pixel clock.
      • We now have 213.33 memory cycles per scan line, which is slightly annoying.  It worked out much more neatly with a 3 MHz memory clock.  If I nudge the primary clock up to 4.125 MHz it comes out to a nice round 220 cycles per scan line.

    • Dedicated RAMDAC / output buffer with 128 colour registers from 4096
      • Different playfields and sprites can use different subsets of registers.  8-bit pixels can assign the 8th bit to indicate the alpha channel.
      • This is more than the Amiga, but in the Amiga the colour registers were built in to the chipset, not on their own chip.
      • This chip gets separate pixel feeds from the video controller and sprite controller and handles the overlay function.
      • This chip also has a line buffer, allowing 180-line mode to be read once by the video controller, so we can have twice as many playfields.

    • Sprite generator with 16k 64k dedicated RAM, upgradeable to 64k
      • The Imagine has a simple sprite engine built into the main video controller; the Dream will have a more elaborate one on its own chip.
      • Each sprite is 16x16 in 64 colours or 24x24 in 16 colours; up to 128 512 sprites in the base configuration.

    • Sound processor with 16k 64k dedicated RAM, upgradeable to 64k
      • Same basic wavetable synthesis DSP approach as the Imagine, but with dedicated RAM to solve the bandwidth problem.

    • Optional FPU
      • Version 1 of the emulator for both machines is going to pretend an FPU is always installed to save me writing assembly-language floating-point code.

    • One or two 800k 3.5" floppies
      • Same variable data rate capacity trick as the Imagine.  The Sirius One / Victor 9000 could get 600k on a 360k floppy.  I'm scaling that to 500k of 10-bit bytes and 400k of 12-bit bytes.
      • Single-sided 3.5" drives appeared in '83; double-sided drives in '84, so the Imagine didn't get the higher capacity.

    • Two expansion slots
      • Available options include 128k 256k additional RAM, SCSI adaptor, and high-speed (1Mbps) serial network card.
      • These cards would be much smaller than ISA cards, more like modern half-height half-length cards.

  • I was looking at the SNES to see what that hardware could do, since the raw specs are similar to the Imagine and the Dream.  It had a 3.5MHz 65816, 128k system RAM, 64k video RAM, and 64k audio RAM.

    But the graphics chip was insane.  In the Imagine I'm worrying about the number of multiplies required in my audio DSP algorithm. The SNES did matrix multiplication just to calculate the VRAM address of each pixel.  Four fixed-point multiplies per clock cycle.



    That was in 1990 though.  None-one, literally no-one was doing that in 83-84.  It's about three times the throughput of the TMS32010 DSP, which came out in 1983 at a price of $500.

    There are some modes mentioned in there that the Imagine and Dream could potentially do.

    He lists the following transformations:

    • Translation - this is hardware scrolling, which is a must-have, and has been baked into the design from the start.
    • Scaling - this can be done by using fixed-point addition rather than integer addition when calculating memory addresses.  This is slightly fiddly but was entirely possible in the early 80s - all you need is some extra bits on the adder.  It's the same trick I'm doing in software in the DSP wavetable algorithm.  If I put it in hardware the DSP will run about twice as fast.
    • Rotation - arbitrary rotation out of the question. That requires multiplication, which is geometrically harder than addition.  Rotation specifically by 90° though might be possible.
    • Reflection - easy peasy.
    • Shearing - probably possible. That can be done by the same fixed-point addition trick as scaling.

  • In another video in that series he discusses colour math - how overlay planes affect the images behind them.  I just discussed using averaging to apply translucent overlays, but the SNES had four main modes: Add, add-and-halve (averaging), subtract, and subtract-and-halve.  It could use these, for example, to simulate a spotlight shining onto a darkened scene.



    Those four main modes were just part of about thirty inputs to the logic that calculated the final pixel colour.  As I said, insane.

Posted by: Pixy Misa at 04:13 AM | Comments (1) | Add Comment | Trackbacks (Suck)
Post contains 1266 words, total size 10 kb.

1 San Francsico got turned into a nightmare hellscape by the smoke from the California fires. 
Are they sure the state didn't just order a rolling brownout on the sky to save energy?

Posted by: Wonderduck at Saturday, September 12 2020 11:42 AM (D9Okp)

Hide Comments | Add Comment




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




55kb generated in CPU 0.07, elapsed 0.3959 seconds.
58 queries taking 0.3542 seconds, 297 records returned.
Powered by Minx 1.1.6c-pink.