Video Computer - cross between Video Console and Home/Personal Computer author Neil Franklin, last modification 2005.05.11 Looking at problems with todays computers, musing on how to design better ones. Also how better ones at what time and with what technology, evolution of such designs from simple home computers to high power PC workstations. Large market for video consoles. Early ones must be usable as that, not just as Basic home computers. Later PCs can also double as consoles. Generations of CPU+memory CPUs are same for consoles and home computers, 8bit, 16bit and 32bit generation selection dominated by DRAM size needed to address defined by exponential chip sizes, more address bits, diff address decoder intro year is roughly when these DRAM sizes became available/payable same time add fitting CPU that is needed for addressing all of memory possibly slot/module for FPU/coprocessor if this CPU has one on offer and clock speed, bus width for more code/data and video bandwidth different system types/usages vary in RAM requirements video consoles program in ROM, need RAM only for video bitmap and temp data home computers language in ROM also need RAM for user program and vars PCs boot ROM ans disk system also need far more RAM for OS and CLI|language use 1..4 banks of each 8 chips, as that seems to be best cost range only 1 bank soldered, is cheapest, but has too limited possibility 4 banks board space, and sold with 1|2|4 banks soldered, offers flexibility but needs service to upgrade 1->2 or 2->4, uses lots of board space 1 bank soldered, 3 banks sockets, gets rid of soldering in service but plugging in DIP chips not consumer grade, adds socket cost, still size 2 banks soldered, and socket for add on board with other 2 banks reduced selection (only 2 or 4, no 1 or 3), minimal cost 2 banks too high and needs add-on board, and all systers have socket for it 1 bank soldered, 1 bank sockets, add on board also 1+1 banks, reduces size but also adds 2 banks sockets cost, and still requires board and connector 4 slots for each 1 bank, with DRAM chips sold on SIPP/SIMM/DIMM boards simple for user, but more expensive with 4 sockets, requires special boards 1 bank soldered, and 3 slots, slightly reduces cost, but non uniform 1 bank soldered, and 2 slots 4->8k + 8->16k, reduce connec, but 2 board types only 1 bank soldered, no slots, 4->8k and 8->16k in module slot extenders low system cost, no opening up, but extenders higher cost, worser mechanics only 1 bank soldered, no slots, 4->8k and 8->16k in modules using them low system cost, no opening up, but modules higher cost, duplicate DRAM B and B# are different variants of same 16bit CPU with 8|16bit data bus also possibly use same processor as A, but with own MMU, and ev wide memory Timeline Family 74/75 77/78 80/81 83/84 87/88 89/90 92/93 95/96 98/99 01/02 04/05 07/08 A/8bit A4 A16 A64 B/16bit B64 B256 B1024 C/32bit C1 C4 C16 C64 C256 C1024 C4096 D/64bit D4 D16 Intro Model Memory Chips Proc/Bus M Clock Competition Year Addressing 1971/72 (*1 (1..4)*8*1kx1 8/8 0.5MHz Pong&Co) (odd 8008, only 1 model, only 1k, max bitmap 40x200|80x100|96x85) (40x25 chargen/cell video fits 1000bytes but incompatible with rest) ( and even 64*8x8 font is 512bytes, more than 256|512byte ROM size) 1974/75 A4 (1..4)*8*4kx1 8/8 1MHz Altair, IMSAI, Apple I 4 DRAM banks, at 0xxx,1xxx,2xxx,3xxx 1977/78 A16 (1..3|4)*8*16kx1 8/8 1-2MHz CP/M, Apple][, VCS, 800 3|4 DRAM banks, at [0..3]xxx,[4..7]xxx,[8..B]xxx(,[C..F]xxx) if 4 DRAM banks readROM/writeRAM for mirroring + ROM off switch 1980/81 A64 8*64kx1 8/8 1-2MHz ][e, C64, CPC, NES 1 DRAM built in, at full xxxx, no multiple banks, no slots B64 (1..4)*8*64kx1 16/8 2-4MHz //c, PC, PC/XT, Victor 4 DRAM banks, at 0xxxx,10000,2xxxx,3xxxx or B#64 (1..2)*16*64kx1 16/16 2-4MHz 2 DRAM banks, at [0..1]xxxx,[2..3]xxxx 16 chip minimal higher cost, but cheaper A64 allows this 1983/84 B256 (1..4)*8*256kx1 16/8 4-8MHz //gs, PC/AT, Mac 3|4 DRAM banks, at[0..3]xxxx,[4..7]xxxx,[8..B]xxxx(,[C..F]xxxx) if 4 DRAM banks readROM/writeRAM for mirroring + ROM off switch or B#256 (1..4)*(4+4)*64kx4 16/16 4-8MHz 2 DRAM banks, at [0..7]xxxx,[8..F]xxxx 2 wide banks must readROM/writeRAM for mirror + ROM off switch not allowed higher cost, use 2*4*64kx4, interleave +10% speed 1986/87 B1024 8*1Mx1 16/8 4-8MHz PS/2 Mod 30, Amiga, ST 1 DRAM built in, at full xxxxx, no multiple banks, no slots or B#1024 (4+4)*256kx4 16/16 4-8MHz 1 DRAM built in, at full xxxxx, no multiple banks, no slots C1 (1..4)*8*256kx4 32/32 16MHz PS/2, MacII, A2000, TT 4 programmable DRAM banks, at ppppxxxx (p=programmable) +4*32kx8 ext cache 1989/90 C4 (1..4)*8*1Mx4 32/32 25MHz 486, MacIIfx, ARM +4*128kx8 ext L2 cache (int 8k L1) 1992/93 C16 (1..4)*8*2Mx8 32/64 50MHz Pentium, PPC +4*256kx16 ext L2 cache (int 32k L1) 1995/96 C64 (1..4)*8*8Mx8 32/64 133MHz PPro, PII, G3, Indy ev +4*256kx16 ext L3 cache (int 2*4k L1, 128k L2) 1998/99 C256 (1..4)8*16Mx16 32/128 333MHz PIII, O2 2001/02 C1024 (1..4)8*64Mx16 32/128 1GHz P4 2004/05 C4096 8*128Mx32 32/128 1GHz P4 2004/05 D4 (1..4)8*128Mx32 64/256 3GHz AMD64 2007/08 D16 (1..4)8*512Mx32 64/256 10GHz ??? Modules different system types/usages vary in ROM requirements video consoles pre-CDROM only get software from ROM modules just boot ROM and progr tape (paper or cassette) at every startup too slow home computers pre-floppy get software/language from internal ROMs single ROM, inflexible, single language, no updates, wasted if game ROMs so go for ROM module slot, with langauages as one class of ROM contents PCs use ROM only for booting from disk, small ROM with disk ctrl or internal program modules, sizes with 1|2(|4) chips (= 2|4(|8) DRAMs) in size ROM module, offered both board+case (for own ROMs), needs own ROM manufact or pre-accembled with ROM in it, needs sending ROMs or using ROM service cheapest for lage fabrication, but takes lots of set up time PROM module, always completely assembled with empty PROM, needs PROM burner more work, less space, but good for small series, amateur program at home modules can contain IO devices, such as CMOS RAM for settings or high scores possibly can be used to add video or audio accelerator chip or FPU in module or even missuse module IO for 1 direct bus coupled IO controller + its device poss such as module slot floppy drive, controller in boot ROM module fast access for disk based operating systems, not just disk of files but loses program modules, only usably for disk booted sys and programs if RAM expansion done with module slot extenders (instead of slots) then need-more-RAM ROM modules should only fit onto top of them, not directly for synchronous running DRAM timing/refresh on slot, address mux in module if RAM expansion done in modules themselves 2 types small language module with 1 (2nd) bank large language module with 3 (2nd-4th) banks, or small with 2bank extender large disk system module with 3 (2nd-4th) banks and disk controller for synchronous running DRAM timing/refresh on slot, address mux in module for developers throwing away PROM module after every test is bad, no rewritable PROM module, with ZIF socket, only throw away PROM chip, still too expensive EPROM module, must be in "UV-open" clear case for erasing, or use ZIF socket SRAM module, battery backed, write with PROM-like "burner" without high volt saves time and device for EPROM erasing, no need for UV-open cases only readable on runtime system, like ((E)P)ROMs, no overwriting by bugs but requires many chips because SRAMs are a lot smaller (1/8 ROM 1/4 PROM) for replacing maximal size 4-ROM module 32 SRAMs would be needed DRAMs can not be used because CPU refresh only when in slot, sync problem DRAM module, 8 chips have full 4 ROMs space, or even 2 1.5 year later ROMs only works while in slot, can not be swapped for development ROM as that loses content, so no room for separate devel software module plug into top of developer module and "switch over" before rebooting or even DRAM hardwired into developer module, with ROM/DRAM switch or possibly just reuse above "small language" module, ROM jumps to DRAM or only DRAM, load from an 2nd devel system IO port, by built in "burner" possibly with this module also processor control, access main memory allows remote "front panel" operation from development system but also monitor-like breakpoints, dev sys can write jumps into module for synchronous running DRAM timing/refresh on slot, address mux in module Model Size Addressing A4 [1|2|4]kx8/chip [0(boot-if-0000)|8(operation)..F]xxx A16 [4|8|16]kx8/chip [0(boot-if-0000)|C(48/16)|E(56/8)|-(off)..F]xxx A64 [16|32|64]kx8/chip [0(boot-if-0000)|8(32/32)|C(48/16)|-(off)..F]xxx B64 [16|32|64]kx8/chip [8..F]xxxx (includes boot FFFF:0000, no switch) ev at FFxxx built-in disk boot ROM, B64 1*4kx8, B#64 2*2kx8 so no module needed for the many disk-only users addressed at same space as slot, disabled by plugging in module if boot ROM ev module slot not wired to CPU bus using mem adresses but just access by IO registers, read module ROM in by boot ROM allows B#64 module to not need 2 ROMs, reduces minimal modulecost cheap A64 allows higher 2 ROMs cost, but this is still not ideal if ROM load from IO also compressed code extract, +30% code in ROM space poss no ROM module slot at all, just boot "ROM disk" on normal IO port B256 [64|128|256]kx8/chip [8(512/512)|C(768/256)|E(896/128)|-(off)..F]xxxx ev FFxxx (boot ROM, B64 1*4kx8, B#64 2*2kx8) B#256 not allowed higher cost, definitely boot ROM copy 1 ROM to RAM but also support older 16bit modules, if used in B#64, both modes B1024 [256|512|1024]kx8/Chip same as B256 C1+ [256|512|1024]kx8/Chip FFFFxxxx (boot ROM, 4 accesses to 1 64kx8) 4 small chips for 32bit boot ROM too expensive, so use 4 8bit bus reads that is slow, but acceptable for only boot ROM copying itsself to RAM or memory controller copy boot ROM 1st part to RAM before starting CPU then CPU access to full ROM by IO registers in memory controller can be assumed that OSes and games come from floppy/HD or CD by now and even if from ROM, they are slower than DRAMs, so load/boot to RAM so module definitely only copy from ROM device, wired as IO port so definitely simply ROM device in normal IO port, no mod slot at all Software examples 1k simple games (pong, blockout/arkanoid, car race, submarine) simple binary-only monitor floppy boot (2k) better games (lunar lander, spacewar) monitor with line assembler 4k usable games monitor with line assembler, labels, disk monitor tiny basic, forth (8k) decent games full assembler better basic, full forth with editor 16k larger games advanced basic, pascal, logo small apps (text editor, mini spreadsheet) (32k) larger apps (word processor, spreadsheet), detailed or multi level games 64k more detailed games and languages and apps Browser+Mail+TCP/IP thin client, or serial link Switch/Router smaller OSes (CP/M 2.x or MS-DOS 1.x like), smaller multi-apps 256k very detailed games and languages, multi-app suites OSes (MS-DOS 3.x like), Servers (unless done from disk anyway) 1M larger OSes (MS-DOS 5.x or simple floppy Unix like), smaller app suites very detailed and many multi level games 4M decently usable OSes (multi-floppy small Unix), app suites 16M complete OSes (smallisch HD Unix) (= 2000 USB stick or 1990 PCMCIA) 64M extensive OSes (HD Unix base install, 199xs full Linux system) 256M full bloat OSes all features and all apps possible 1G exerything under the sun (= 2005 largest USB stick, 2000 cheap 2.5" HD) Video Out always full bitmap, costs 8*RAM (64pixel/char) vs char cells (8bits/char) but then saves chips on character pattern lookup logic no dual memory accesses to videoram/chargen with resulting "bad lines" or fixed (= unusable for games) char ROM or costly separate loadable char RAMs or cost of 2 line buffers, reading 8 time 1/8 lines while video retrace so losing bandwidth wanted for loading sprite bitmaps or sound or refresh no picture element limits to cell boundries, can do random shapes no need for sprites, can do random positioning (but sprites also speed advantage, extra colours/resolution, collis detect) dito no need for vertical sub-cell scrolling circuits, late draw, blank lines (horiz scrolling can make faster as no multi-byte shifting of pixels) can do simulated vector drawing and colour fills, usable for 3D scales better with exponential RAM size increases video image direct from full system RAM, no separate video RAM allows flexible size (full RAM) and positioning (and cutting into blocks) uniform memory access speed (no chip vs fast RAM, no bus separator buffers) for speed go for wider RAM buses to reduce video bandwidth access losses poss ROM full speed and only RAM slow, runs modules at full speed at low cost but programs from disk, loaded into RAM, become slowed down, perform bad or even only one RAM bank run slow, separate bus from rest RAM and ROM only video RAM bank contention, rest always fast, but irregular timing only fast when multiple banks of RAM, with more cost for min 2 separate and limits video to part of RAM space, not shiftable, no multi-buffer or separate video RAM, in own address space, access only via IO ports but more expensive, requires 1..4+1..2 RAM banks vs 1..4 for combined Model Video Modes A4 video/TV PAL|NTSC composite signal on yellow cinch connector direct to video monitor or external modulator and TV, ev modu power square pixel [128|256]x192 3/4 2^n RAM vs full 2^n [160|320]x200 [50|60]frames*([652|525]/2)lines/s = [64|63.5]us/line, draw 200 lines poss reduceable, drop lines, [1..3] per 8, to save RAM can be used by text display, capitals 5line, lower case gjpqy 7line unlikely repeat lines (= only 100 lines mode) as enough memory only b&w, [1|2]bit/[2|4]gray-level, no level/colour mapping or simple 2|4 colour if circuits for this not too much 40us drawing @ 1MHz (= 1us/memaccess) = max 40bytes/line 20b/l: 160x1bpp|80x2bpp, 4k, near min RAM, upto 12k for work, -0% proc 40b/l: 320x1bpp|160x2bpp, 8k, half max RAM, still 8k work, -40% proc or 44us drawing @ 0.89MHz (= 1.1us/memaccess) = max 40bytes/line or 36us drawing @ 0.89MHz (= 1.1us/memaccess) = max 32bytes/line likely no sprites, not necessary, lots of hardware to insert them and simple 1bpp bw effects fast enough in software but sprites offer better speed (no copy to move) and high resolution and also add touches of other colour if design with colour support A16 same output as A4, same devices, same frame rate, same line count colour, fixed selection, 16 ("RGBI") of 64 (RGB 3*2bit) colours bk+rd+gn+bl+br+vt+?+ltgr+dkgr+pink+pagr+pabl+ye+mg+cy+wt fixed, no LUT, as no cheap 16x6bit dual port RAMs, 6*8x2bit too much for 1|2bpp modes 4 4bit colour select registers, with 2|4 of them used 40us drawing @ min 0.5us/memaccess = max 80bytes/line 20b/l: 160x1bpp, 4k, 1/4 min 1/16 max RAM, -0% proc 40b/l: 320x1bpp|160x2bpp, 8k, 1/2 minimal RAM, -0% proc 80b/l: 640x1bpp|320x2bpp|160x4bpp, 16k, full minimal RAM, -40% proc 640x1bpp only if no extra circuits needed (combines existing stuff) line drawing delay 0..7 pixel for fast no-shift horiz background scroll together with 4 pixel earlier start and 2*4 pixel blanked out sprites likely, even though they require lots of timing/insert hardware either 4 16x16x1bpp (=4*32byte) from 256x4bit SRAM, 1 colour reg/spr or bitmaps from main memory, only 1 or 2 horiz retrace read buffer(s) also allows n-line sprites, no hight limit, as only line stored possibly integrated chip, in this case all/most A64 stuff below just smaller RAM for sprites, or better fetch bitmaps from main memory A64 same output as A4+A16, same devices, same frame rate, same line count RGB 3*2bit/4*4*4colours, use full 64, integrated LUT with 16 3*2bit regs [1|2|4]bits are only indexes into LUT, so no colour select registers for [1|2]bpp modes [3|2]bit base register to use rest of index bits bitmap sizes same as A16, as bus throughput is at the limit anyway 640x1bpp now definitely as in high integrated chip, so not expensive mode switchable per line, mixed picture/colour and text/hires areas sprites definitely, as now in high integrated chip, slight expense 8 [32|16]x16x[1|2]bpp (=8*64byte) from separate 1024x4bit SRAM or unlimited hight from main memory, load while horiz retrace only count*width*bpp limited by retrace time 24 memory accesses poss 16 generators with each 4 vertical position/bitmap setups or 64 full generators with "load after used" and load priority 1 colour register/sprite, 6bit, LUT 14|15 for 2bpp mode 2nd/3rd very unlikely 2*1kx4bit SRAM to sel 1|2 of 16 colours per 8x8pixel cell as reintro cell colour clashes, particular in 1bpp where most desirab 640 pixel use as (80*25)x4bit, for 1 colour, 2nd from sel reg 320 pixel use as (40x25)x(2*4)bit, for 2 colours 1bpp no colour select registers, 2bpp other 2 from registers 160 pixel use as (20x25)x(4*4)bit, for 4 colours, no colour sel regs B64 DD15|DE15|DB10W3 with video(RGB)+modi-ID(resolution/timing)+power(small) video monitor adapter with yellow cinch, external modulator for TV RGB 3*2bit/4*4*4colours, same as A64 as no >4bit modes 40us drawing @ min 0.4us/memaccess = max 100*2(=200)bytes/line possibly optional draw into overscan, 51us/line, 250|210 lines/frame but this reduced time available for sprites, so stepwise setting 80b/l: 640x1bpp|320x2bpp|160x4bpp, 16k, 1/4 min 1/16 max, -0% proc 100b/l: 800x1bpp|400x2bpp|200x4bpp, 20k, 1/3 minimal RAM, -0% proc 160b/l: 1280x1bpp|640x2bpp|320x4bpp, 32k, 1/2 minimal RAM, -25% proc 200b/l: 1600x1bpp|800x2bpp|400x4bpp, 40k, 2/3 minimal RAM, -40% proc also 2*200 line interlaced modes, same bandwidth, double RAM, flicker hires moni in gray (and ev colour), ev vertical moni (in gray only) 60frames*(n+retrace)lines/s = x-us/line, draw lines 3/4 of time h360li 30us 150b/l: 480x1bpp|240x2bpp, 21k, 1/3 min RAM, -0% proc h420li 26us 130b/l: 560x1bpp|280x2bpp, 32k, 1/2 min RAM, -10% proc h480li 23us 115b/l: 640x1bpp|320x2bpp, 37.5k, 2/3 min RAM, -20% proc v530li 20us 102b/l: 400x1bpp|200x2bpp, 32k, 1/2 min RAM, -30% proc v640li 17us 85b/l: 480x1bpp|240x2bpp, 37.5k, 2/3 min RAM, -40% proc sprites 16 freeform 256x[4|2]x[2|4]bpp (=16*256byte) fr sep 2*4kx4 SRAM more likely to get from main memory, unless leaving that for overscan 3 colour register/sprite, LUT: 0-15 backg, 16/32/48 S0 .. 31/47/63 S15 poss windowing horiz stripes (blocks of lines) for multiple processes bitmaps scattered in mem, in different processes physical RAM slice or lines in 1 block, with base+boundedoffset addressing each with different line draw mode, different LUT and base index, etc definit no 8x8pixel cell colours, enough video bits from memory avail and incompatible w non-8x8 fonts (such as 6x[10|12] for 480pix monis) B256 same output as B64, same or improved devices (multisync monis?) RGB 3*4bit/16*16*16colours, use full 4096, LUT with 256 3*4bit 40us drawing @ min 0.25us/memaccess @ max 160*2(=320)bytes/line or possibly [64|63.5]us FIFO reading = max 256*2(=512)bytes/line 80b/l: 640x1bpp|320x2bpp|160x4bpp, 16k, 1/16 minimal RAM, 1/64 max 160b/l: 640x2bpp|320x4bpp|160x8bpp, 32k, 1/8 minimal RAM, -0% proc 320b/l: 640x4bpp|320x8bpp, 64k, 1/4 minimal RAM, -40% proc hires moni in gray (and ev colour), ev vertical moni (in gray only) 60frames*(n+retrace)-lines/s = x-us/line, draw lines 3/4 of time h360li 30us 240b/l: 480x1bpp|240x2bpp, 21k, 1/12 min RAM, -0% proc h420li 28us 135b/l: 560x1bpp|280x2bpp, 32k, 1/2 min RAM, -0% proc 560x2bpp|280x4bpp, 64k, 1/2 min RAM, -10% proc h480li 23us 184b/l: 640x1bpp|320x2bpp, 37.5k, 1/7 min RAM, -0% proc 640x2bpp|320x4bpp, 75k, 1/3.5 min RAM, -20% proc h600li 19us 152b/l: 800x1bpp|400x2bpp, 60k, 1/4 min RAM, -20% proc v640li 17us 136b/l: 480x1bpp|240x2bpp, 37.5k, 1/7 min RAM, -0% proc 480x2bpp|240x4bpp, 70k, 1/3.5 min RAM, -40% proc v853li 14us 112b/l: 640x1bpp|320x2bpp, 65k, 1/4 min RAM, -15% proc sprites same 16, but 4* SRAM, so 4* size per sprite B1024 same output as B64+B256, same or improved devices (multisync monis) RGB 3*4bit/16*16*16colours, same as B64 as no >8bit modes bitmap sizes same as B256, as bus throughput is at the limit anyway C1+ DB10W3|DD15|DE15 with video(RGB)+IObus(IOports+ID(size))+power(small) monitor control bright/contr vol/bal/tone from sw, knobs just spinners ev comp power off-auto-on and moni power off-moni-both-comp switches video monitor adapter with yellow cinch+SVHS, no extern modu and TV RGB 3*8bit/256*256*256colours, use full 16mio, 3 LUTs each 256 8bit regs also "each LUT separate" 3*5 '16bit', 3*8bit, 3*10 '32bit' truecolour poss windowing proper overlapping rectangles of pixels, with frames bitmaps scattered in mem, in differents tasks page sets different video modes and LUT contents in line sections sprites none as enough processor and bus bandwidth, can do blitting also no good for vector/3D style uses which will become standard here but possibly need 1 "sprite" for mouse cursor, avoid un-/redraw tests also avoid interference with program drawing in window do as transparent overlay window, possibly allow multiple for icons possibly C1 and definitly C4 dual head operation, 2 sets of video output video/TV PAL|NTSC [50|60]frames = [20|16.6]ms/frame (minus vert retrace) FIFO reading @ min ((3+1+1+1)*0.125us)/memquadaccess = max [26666|22222]*4*4(=[416.6|347.2]k)bytes/frame definitely switchable overscan mode, 51us/line, 250|210 lines/frame 200li: 640x1bpp|320x2bpp, 16k, 1/64 minimal RAM, -[3.8|4.6]% mem 200li: 640x2bpp|320x4bpp, 32k, 1/32 minimal RAM, -[7.6|9.2]% mem 200li: 640x4bpp|320x8bpp, 64k, 1/16 minimal RAM, -[15.3|18.4]% mem 200li: 640x8bpp|320x16bpp, 128k, 1/8 minimal RAM, -[30.7|36.9]% mem 200li: 640x16bpp|320x32bpp, 256k, 1/4 minimal RAM, -[61.4|73.7]% mem hires moni (in colour), vertical moni (in gray or ev in colour) 60frame|16.6ms FIFO reading @ min ((3+1+1+1)*0.125us)/memquadaccess = max 22222*4*4(=347.2k)bytes/frame, minus vertical retrace time h480li: 640x1bpp|320x2bpp, 37.5k, 1/27 minimal RAM, -10.8% mem 640x2bpp|320x4bpp, 75k, 1/16 minimal RAM, -21.6% mem h600li: 800x1bpp|400x2bpp, 60k, 1/16 minimal RAM, -17.3% mem 800x2bpp|400x4bpp, 120k, 1/8 minimal RAM, -34.6% mem 800x4bpp|400x8bpp, 240k, 1/4 minimal RAM, -69.1% mem h864li: 1152x1bpp|576x2bpp, 128k, 1/8 minimal RAM, -36.9% mem 1152x2bpp|576x4bpp, 256k, 1/4 minimal RAM, -73.7% mem v853li: 640x1bpp|320x2bpp, 65k, 1/16 minimal RAM, -18.7% mem 640x2bpp|320x4bpp, 130k, 1/8 minimal RAM, -37.4% mem 640x4bpp|320x8bpp, 260k, 1/4 minimal RAM, -74.8% mem v1152li: 864x1bpp|432x2bpp, 128k, 1/8 minimal RAM, -36.9% mem 864x2bpp|432x4bpp, 256k, 1/4 minimal RAM, -73.7% mem D1+ same as same time C models, unless those bandwidth limited Audio Out as standard audio only output, as consoles and computers only need that computer PC beep is enough, console needs more and computer does not mind input (mic amp, ADCs, source selection) for recording via external IO device Model Audio Modes A4 cinch connector, amp+volume+3.5mm(phones) in moni/TV generator single bit software, using TV horiz sync irq good enough for simple beep/tick/click effects A16 same connector as A4, generator same single bit software or [6|8]bit DAC w 2*256x4|512x8 SRAM (clocked by video horiz sync) possibly DAC with retrace time load from main memory A64 same conn as A4+A16, gen definitely full 8bit DAC w 512x8|2*1024x4 SRAM B64 connector audio stereo signals on video DD15|DE15|DB10W3 monitor has for audio 2*cinch+amp+volume+3.5mm(phones)+speaker(mono) on video monitor adapter just 1|2*cinch, rest in video moni or sep amp generator mono|stereo [8|12]bit DAC w [2|3]*1024x4 SRAM sample rate indep from moni, 8|16|24kHz (24kHz+12bit+stereo = FM radio) B256 same signals as B64, just possibly better resolution signals on it full 12bit DAC w 3*4096x4 SRAM, definitly stereo, 8|16|24kHz samples B1024 same as B64+B256, poss already C1 spec add here, or just 2*44.1kHzx16bit C1+ connector audio as S/P-DIF on video DB10W3|DD15|DE15 connector in computer only send S/P-DIF bits, DAC and everything else in monitor or possibly only send raw IO data, even convert to S/P-DIF in monitor monitor has for audio S/P-DIF+DACs+2*cinch+3.5mm+speaker(stereo+woofer) on video monitor adapter S/P-DIF+DACs+2*cinch CD-like 2*44.1kHzx16bit, also 8|16|24|48kHz sample, also 8|12|16|20bit with lower sample and bit rates up-converted before transmission D1+ same as C1+ as no sensible improvement relative to CD quality Timers Family A/8bit only counter/timer+irq, or possibly even just videoscan+irq Family B+/16bit+ counter/timer+irq, RTC/CMOS, CMOS usable by boot ROM f setup IO Ports appart from built-in module, video-out, audio-out, timer, all other IO external multiple identical device IO ports, no slots, small size connectors general purpose, 5V + GND + 6..8 simple IO pins, analog stuff in devices in 8bit tristate to bus + pull up resistors + out 8bit FFs with OC outputs use 8th (and ev 7th) bit to enable interrupt in or even clock out all ports appear in same address space, with port select by select register separates port select addressing from actual register access addressing removes need for address calculation time and non-const addr IO instructs DE9 ("DB9") male in device, has no-shell female on cable, but fairly robust is simple and cheap, like Atari DE9, standard cable for all devices or DIN8 (no mini-DIN in 1970s) female in device, male on cable, ev cheaper or even go for RJ45, also robust, has pull out protection without screws later on, if incompatible ports on C/32bit Family, use Mini-DIN8 for them or even something USB-like, just 4 contacts 5V+GND+out+in with shield or go for RJ45 like stuff such as RJ12 or MMJ, 5V+GND+diff-in+diff-out in addition minimal cost (board edge) expansion connector possibly provide this with extra module slot pins, but bad mechanics Model Ports A4 2 front for 2 person 1 controller or 1 person 2 controller operation ev 2 back for disk/print/comms (or missuse one front) or better 4 front for 4*1, 2*2 controllers and disk/print/comms or only 2 built-in and 2 addable on module slot or expansion connector poss cheap implementation only [5|6]I+4O, joyst 5I, other max 4O select very unlikely 4IO + sep 5[+6]th I register, later bad for adressing devices offered: - joypad 4dir + (2)fire (+ menu), bundled (so must be cheap, so flat) - joystick (digital) 4dir + (2)fire(base) (+ menu) grippier than joypad but larger and more expensive - paddle 1pot (RC charge 1/2V test + software time) + (2)fire (+ menu) better than joypad/joystick for fine positioned bats or steering - keypad hex 0..9+A..F+ops (6x4 3row-selO + 4colI, or 5selO + 1dataI) - keyboard tty-like (8x[7|8] 3row-selO 3col-sel0 + 1dataI) - cassette tape interface for Basic etc to store programs and data - (E)PROM reader/burner, with same slot as module slot, EPROM eraser A16 2 front for controllers + 2 back for disk/print/comms or better 4 front for controllers and disk/print/comms possibly expansion connector or module adaptor for 4 more ports poss implemented with max 4 custom 4-port/chip ICs to save space/cost possibly same abilities as the B64 one, or less for lower market new devices offered: - grip handle joystick (digital) 4dir + (2)fire(stick) (+ menu) grippier than normal joystick, firmer base holding as fire on stick - arcade ball joystick (digital) 4dir + (2)fire(base) (+ menu) more realistic than normal joystick but most expensive variant - RC joystick (analog) 2dir (2* as in paddle) + (2)fire(base) (+ menu) or (2* DAC + OpAmp aprox) + (2)fire (+ menu) better than joypad/joystick for controlled car driving or flght simu - spinner 2dir (quadrature counter read/zero) + (2)fire (+ menu) better than paddle for unlimited movement distance, non-differential - trackball 4dir (2* as spinner) + (2)fire (+ menu) - link cable for 2 systems (GND + 3*2 crossover IOs + 1 straight IO) - Centronics interf (shift reg data/ctrl out + stat in, in 36pin plug) - IEEE488|IEC??? interface (same method as above, in 24|25pin plug) - RS232 interface (bit shift in SW, voltage converters, in DB25m plug) - generic proc based IO dev, case-less board, power by IO port or ext proc+clock, boot/OS ((E)P)ROM socket, 2*256x4 SRAM, poss timer+IRQ host IO use 1 IO port, plug for above link cable, host can reset dev edge conn or chip socket or IDC, w buffers for actual IO and IRQs - floppy disk drive, proc, GCR coding, raw bits and SW based on above proc IO dev board, instead of double design work or alternative based on module slot boot-ROM + RAM + controller 1541-like, but SCSI-like random block access, not filesystem or alternative only small ROM, boot actual floppy OS from host - printer, proc, 10"wide 7|8|9pin 72pin/inch 144motorstep/inch based on above proc IO dev board, instead of double design work - print mechanism, 2.5"wide, 7|8dot thermo 72pin/inch 72motorstep/inch A64 4 front for controllers + 4 back for disk/print/comms possibly expansion connector or module adaptor for 4|8 more ports implemented with (max 4) custom 4-port/chip ICs to save space/cost possibly same abilities as the B64 one, or less for lower speed proc new devices offered: - dual joypad 2*4dir + 2fire(edge) + 2fire(trigger) + menu - cars/boats (left up/dn right ri/le), better separate - tanks/bulldozers/some-boats (left up/dn right up/dn), realistic - mechas (left up/dn/ri/le right up/dn/ri/le) more mobility by more directions input - beat'em'up (left up/dn/ri/le right hand/leg weak/strong) more tactics by more directions and strength input - dual grip hand joystick 2*4dir + 2fire(top) + 2fire(trigger) + menu - dual arcade ball joystick 2*4dir + 2+2fire(board) + menu - dual RC joystick 2*2dir + 2+2fire(board) + menu better than single RC joystick for flight simulat, 3-axis + throttle - phone interface, proc, for soft modem, just DAC/ADC/dial-relay - printer, proc, 10"wide 1hammer 72position/inch 72motorstep/inch - teletext decoder, proc, hw extract bits from signal, sw analyse them B64 4 front for controllers + 4 back for disk/print/comms possibly expansion connector or module slot adaptor 4|4+4|8 more ports implemented with (max 4) custom 4-port/chip ICs, save space, do more standard open collector with pullups and read-in mode PIO mode, O/I direc, data out inverts in, out-modify/in-interrupt mask VIA mode, counter/timer, analog counter, quadrature counter, shiftreg serlink mode, shifters, separate dirs, fixed 8n1, 14.33/16 bitrate for device CPU and IO reset provide signal on an further pin for device reciever+CPU clocking provide 14.33/4 clock on one pin poss data-out/data-in/clock differential, as only 2power+4signals better w transputer-like data/ack bit for 3-wire fast flow control or even other/ack bit and then after other data/error for repeat for dumb devices C011-like byte-out + byte-in, each dir strobe/ack pin to allow OC out mode w internal pull ups, combinable w inputs for uP proc devices C012-like bus connected UART-like chip and/or 8b uC, 1..4k prog RAM, 64..256 data, serlink UART, linkboot and normal IO ports, pinout 5V+GND+Res+Osc+2Link+4*8IO+2?? RAM based program memory for uC so drivers loadable device depend possibly also standard RS232 baud/bitrates, so no bitbanging needed but better for this external uC for bitbanging, serlink to that unlikely only serlink mode (with uC these can do full A series mode) connection to port controller chip full 16bit access (2bytes/load) internal buffer RAMs, can run as 16550-style 16byte FIFOs or adressab DMA buffers, DEPCA-like, REP transfers, but IO space unlikely large external buffers, using an 16kx4 chip this all allows far larger throughput, as is needed for harddisks new devices offered: - one hand joypad 4dir + (2)fire (+ menu) for doing hand writing or using keyboard or mouse in other hand - flightstick+trust+rudder analog 2+1+1dir + coolie + n-fire + menu also steeringwheel+pedals analog 1+1dir + n-action(gears!) + menu better than joysticks, with realistic shape and movement - keyboard PC-like tty+edit+num+fn (16x8 1clkO + 1resetO + 1dataI) - keyboard piano (2*) 4..6 octaves + select buttons + drum buttons system can be now used to build software synths, now good audio out - drum kit multi-drum (diff sizes) multi-field (middle + edge sect) - mouse 4dir (as trackb, 2* as spinner) + 2actio + menu (= 3button) - audio in [8|12]bit ADC, poss stereo, 8|16|24kHz, [2|3]*1024x4 SRAM generally corresponding to audio out, 3.5mm(mic)+cinch+selector will be an serlink device, for the needed throughput possibly implement audio out also as IO device behind internal port - (E)PROM reader/burner, w same slot as B family modules, and eraser - serlink to only data+power adaptor for 4|6-wire networking cabling link A or B family terminals/workstations to B family servers star network using hubs, host powered amplifiers on shared medium for this also some sort of MAC address PROM star network using switches (4* 4-port, CPU, w built in adapters) for this same MAC addr PROM, switch built in adapt only one PROM - serlink based generic uP proc IO dev, like normal generic but faster proc+clock (B 8bit not B# 16bit), boot ((E)P)ROM socket, 2*4kx4 SRAM host IO use 1 IO port, single port vers custom chip, serlink subset? IDC connector with buffering for actual device IO - floppy disk drive, based on above serlink proc IO dev or serlink uC 2*4kx4 SRAM or 2*16kx4 DRAM cache (DD [GCR|MFM] [4|5]k/track raw) serial bit banging slow floppy operation, like C64/1541 serial bus OK for 8bit file only, but not 16bit CP/M|MS-DOS|Unix like OSes now with serlink also fast enough for such disk based systems - hard disk drive, serlink proc device or larger, 8*64kx1 cache - printer, proc, 15"wide 2*12pin 72/144pin/inch 144motorstep/inch B256 same amount and arrangement as in B64 improved serial link mode, 4*larger internal buffers than B64 also near 2 times faster bus, so 4 times transfer rate 14.33/4 new devices offered: - audio in 12bit w 3*4096x4 SRAM, 8|16|24kHz, ster, 3.5mm(mic)+2*cinch only if audio out was improved the same amount from B64 to B256 - MIDI in/through/out - SCSI adaptor - ethernet 10base5|2 (later also 10baseT) - printer, proc, [10|15]"wide [80|132]pin(=12pin/inch) 144motorst/inch B1024 same amount and arrangement as in B64 and B256 improved serial link, 4*larger internal buffers than B256 new devices offered: - audio in 2*44.1kHzx16bit if computer also contains such audio out - compact disc drive C1+ 0 front + 4|6|8 back + 2 monis 4front + 3back + 1int ID(size)+control 32bit and faster bus allow again 4 times faster transfer, 14.33 every 1|2 generations improve by annother 2|4 times speed also larger buffers 16*B64, 4*B256, 1*B1024 allowing faster every generation improve by annother 4*larger ports implemented with new custom IC, with all above modes plus: for ports on monis, each moni an 8 port demultiplexer ports on controller only connect to demuxes, run in serbus mode ev for many devices have demuxes cascadable, 2 or 3 depth so ports of demuxes can themselves run in serbus mode, switchable for to-mux(-hierarchy) bus(es) 6|9bit device address, shifted for 4|6|8 ports direct on back of console same demux chip in console so controller only 4 to-demux ports (base+2moni+reserve) possibly on back an "demux expander port" for 8 further ports also possibly for servers demux expander for on 2nd moni connect identify mode, special bus signalling, use transistors for plug+play in this mode read out an ID/driver EEPROM in device possibly incompatible plug so only extended serial bus mode devices for this use an new different connector to show not compatible need to offer traditional port mode/connector converter, adds cost but can be built into new devices (more new users than existing) converter only for old stuff being taken over, oddball devices easy possib because already B series bus device can simul OC port unlikely support for hypercube hooking up 2|4|8|16 computers parallel in this case top 4 address bits as node number, for NUMA style SMP but better (no address space split) message based data exchange although this costs interrupts on other side, to process them new devices offered: - audio-in ADC, moni DAC spec, 3.5mm(mic)+2*cinch+S/P-DIF+selector - 2nd audio-out, identical to 1st in moni, S/P-DIF+2*cinch+3.5mm so 1st also same circuit, on intern IO port in comp or even in moni ev also intern IO port for timer and RTC, not direct on fast bus ev even controlling video generator registers by IO port all these at cost of some of the 8 ports on comp - ethernet 100baseT - print, 10"wide laser 288dot/inch 288motorstep/inch - scanner, 10"x15" 144|288dot/inch 144|288motorstep/inch - video digitiser, minimal 320x200x8gray later models growing up to full 640x400x(3*8|10)colour D1+ same as C1+, just faster bus bit rates Handhelds aim at Gameboy style market, but also with full (keyboard)PDA functions same as large machines are video consoles, but also with full computer func CPU + 2 CMOS SRAMs + 1 singleROM slot + 1 glue ASIC + LCD + speaker + battery built into an gamepad style/size case, slightly larger for LCD only single ROM modules, as ROMs 16|64 times larger than same RAM size console also adapter cable for development system driven DRAM module ports 0 = internal gamepad, 1 = intern ((E)E)PROM burner, 2 = clip on keyboard 3 = IO using an compact flat 9pin socket - cross connetion for 2 player (no 2nd gamepad as bad LCD view) - micro peripherals, sized down like the clip on keyboard (cass tape interface, 2.5" printer, phone interface, ...) - flat 9pin to DE9 converter for existing peripherals (and also DE9 to flat 9pin convert for micro peripherals on desktop) Timeline given by when 8 DRAM -> 2 CMOS SRAM (= 6 years later than console of same size) Family 74/75 77/78 80/81 83/84 86/87 89/90 92/93 95/96 98/99 01/02 04/05 07/08 A/8bit A4 A16 A64 B/16bit B64 B256 B1024 C/32bit C1 C4 C16 C64 C256 C1024