Looking for opinions on video...

[cj7hawk]

Hi all,

Well, Project Loki continues. Operating system is pretty much complete as is the disk subsystem code and memory management strategy. I'm about to start working on laying tracks on PCBs with hopes for a prototype later this year. Some of the early video circuit POC testing has blown away my early theoretical maximums, and I get the feeling that it was entirely possible to build a GBP200 computer at the time that would have blown a typical 286/EGA computer away, using a normal z80, which is pretty amazing when you think about it - We could have seen a decade's growth in 1985, instead of waiting to 1996 to play games like Quake...

So far the computers I've stolen ideas from include;

Osborne 1.
Apple Mac.
IBM PC (right up to the 286)
Amiga
Atari ST
PC-8801
And, of course, The Speccy 48K.

And I've finally come up against the video problem - and best as I can tell, I get minimum chip counts with 256x192 and 512x192 using only mid-80s low-cost technology - though the funny thing is that there's no penalty for additional vertical resolution. In fact, the same chip count can go up to 256 vertical lines without any real difficulty... Well, maybe just a little after line 240....

Additionally, it seems that it should be expandable without too much additional circuitry to a maximum resolution of 512x384 - ie, Apple Mac resolution, except in 16 colours, and still support genlock addons with overscan possible so that both the horizontal and vertical frames can overscan.

Which seems pretty neat and aligns with the theoretical outcomes I stumbled upon when I started the project. It also possibly explains why I keep hearing of alternative vertical resolutions such as 512x192 and 512x200 and even 512x226 which gives up to 9 vertical lines per character, and would give the same pixel resolution as the ADM-3A monitors, which were well respected in the era... Which brings up the questions I'm looking to throw to the wisdom of those who remember the computer we never got to see.

So without making resolutions optional, what would be the optimal vertical resolution for a super-speccy?

And would you accept 512x384 interlaced over having a full compatability mode? Or would it be more important to dedicate the extra circuit to a full non-contention version of 256x192 Block Attribute as an operating mode for 48K compatability?

Finally would you do anything about the Spectrum's tiny screen in a wide border on a TV? Keeping in mind that the Speccy has a near-perfect aspect ratio at 256x192 with that horizontal width on many PAL TVs, and a 10% wider screen would make circles a little wider.

Though with the Genlock installed, the screen can be stretched horizontally as required (eg, wide, Overscan etc ) without extra circuitry and the video board would be pretty much moddable.

Also, I'm not planning on installing all modes in the final proof of concept circuit, but as to where to focus, well, in the words of the Bloodhound Gang, I'd appreciate input.

[1024MAK]

Given the limitations on the resolution on colour CRT monitors and TVs, it would be good to make use of some of that “wasted” border space…

And if the border is the same colour as the background, a thin border does not matter

Mark

[AndyC]

First and foremost, I'd say that interlaced resolutions all sucked. The flickering was horrible and pretty much makes it hard to draw acceptable images, it might have been ok for realistic images with a large palette but for anything else was just headache inducing. Not to mention that interlace immediately halves the best frame rate you can get out of anything.

Similarly, I'd be surprised if a high horizontal resolution was much use. The Amstrad could do it, but having the monitor (which was a glorified TV) connected via RGB rather than a standard (for the time) RF signal probably is the only reason it was acceptable. And even then it wasn't perfect. The SNES could do it as well and almost nothing every bothered, because it just wasn't sharp enough on a real TV to be worth the bother. Obviously if you're hooking up to a modern display the results are quite different, so it depends upon how authentic you really want to be.

The real killer on 8-bit machines was the amount of video RAM required and the CPU effort involved in manipulating it. Machines with fancy displays, like the CPC and Sam tended to chug as a result.

[catmeows]

1985 Super Speccy ? Probably just 320x200 with attributes (16 colors for paper, 16 colors for ink from 6bit -64 colors- RGB pallete), 160x100 with 16 colors, 320x200 with 4 colors, perhaps 640x200 mono for people who can afford monitor.
Because I don't understand how you want get more data from 85ish DRAM and allow cpu to run at the same time without stealing too much of its cycles.

[catmeows]

Yeah, what AndyC said.
With 6MHz and fast DRAM, using same contention scheme like CPC did, you can get effective speed around 5Mhz.
Using same pixel width as Spectrum has and widening pixel area into left and right border, little more than 320 pixels would be visible on TV.
You can tune things little bit but you really should have timing diagram that respect access and cycle times of contemporary memories and timing of cpu used and I don't believe you can get much more than about 160 bytes during ~48us period that is visible on TV.
If you give half bandwidth to cpu and half to video, you end with 80 bytes for pixel line.
You could read whole line in advance, cache it and use most of 64us scan line (minus DRAM refresh) but that is still about 200 bytes per pixel line.
The only way to go further is either 16 bit bus (Hi Atari, Mac & Amiga) or separate dedicated ram for video (hi MSX, Nintendo and Sega).

[cj7hawk]

Thanks for the input so far - it's greatly appreciated.

I suppose if original Speccy hardware configs are assumed, that much memory would be a problem to move around, but in 1985 other options were emerging, and Sinclair mentioned Video Ram at the time - In fact it even came capable of bit operations by 1985. However I was looking at a slightly cheaper alternative that also emerged around then, and using Static Ram. Static Ram was available in common configurations down to 60ns in 1985 and to well below 15ns in specialist applications. Also, 27512 Eproms were around 200ns, which rounds out the requirements for a zero-wait system z80 based on 1985 technology.

With SRAM, I think it should be possible to maintain resolution as high as 512x384 interlaced 50Hz while allowing zero-wait uncontended access to video memory asynchronously at up to 20 MHz, so was also thinking of using a z80H overclocked to 10.5 MHz ( Three times the speccy speed ) and possibly as high as 14 MHz which I think the z840008 can be pushed - or four times the normal Speccy CPU, and possibly even supporting the z840020 at 20 MHz as an option, though might have to insert a wait state at times, as it's borderline then.

This would mean that a video card can be made with baseline memory for 256x192x64+4 per pixel (about EGA) at a low cost with lots of performance and Spectrum compatability while running a rebuild OS that gives CP/M compatability and access to 1 Mb of memory at full expansion.

The Proof Of Concept for the video memory seemed OK, and ran well enough with 1985 era low-cost logic components that I think this is achievable.

320 or 640 is not, due to the additional constraints it places on both logic and code - it means a lot more gates need to be used, while vertical resolution changes require very little change, since it's already a lot of effort to arbitrarily generate the blanking signals from a single macrocell.

Also, the baseline Speccy display is 36.6 uS across, while if I changed the goal frequency, that becomes 42. uS across - A lot of PAL screens had way more overscan back in the day than they do now. But that's the effect of reducing the dot-clock to 12 MHz rather than 14 MHz necessary for the 512 pixel modes, which still only use 256 bytes/line, but pack two pixels into every byte - That is a standard mode for PCs also BTW... So when I wrote the emulator I built the OS in, it set the pixels up that way by default also.

The only downside of 12 MHz dot clock is that circles displayed will be visually flattened a little horizontally due to the mismatch between the aspect ratio for vertical and horizontal - though I can't get hard data yet to support that so will have to test empirically. In any case, both should be supported by the same board and the only differences are with a 28 MHz source oscillator, the Speccy could be 3.5, 7, 10.5 and 14 MHz (10.5 and 14 overclocked) while a 24 MHz source would provide 3,6,9,12 which should definitely run on a z80H from 1983, but is still a little slower as a maximum speed. The video circuit I've designed is asynchronous, so at 14 MHz dot clock, should support asynchronous read and write at 210ns, and will still recover in time for the next cycle as the intent is to buffer both writes and reads and offload the timing from the z80 to the video arbiter circuit.

The 256 pallette and 64+4 RGB options are kind of mutually exclusive. Supporting both outside of allowing a daughterboard becomes quite complex and takes up a lot more board space, and really pushes the cost up. One of the key elements of the project is to ensure that the entire thing can be built for under GBP200 in 1985 pounds - Which ironically is still about GBP200 today given current chip and short-run PCB costs.

The entire design runs it's own raster generator, sync and blanking included, on just two common chips, but the raster timing can be overridden and then the display is synchronised to an external source - eg, Genlock. Again, that would be a daughterboard/second card solution, due to the cost of video circuitry in 1985. ( I was planning on using the TEA2000 as Sinclair clearly preferred this over the LM1889 by then. ) Adding an extra chip would let me change vertical refresh locally also, and support both NTSC and PAL, but the chips available in 1985 would have supported both with local reprogramming so I get the feeling that's the way Sinclair would have gone rather than a single design supporting both options.

Finally, the intent is to include a BLT/Vector circuit that can draw vector lines or copy "sprites" at better than a pixel per microsecond without affecting either the screen raster or the zero-wait to the CPU. This is effective since the z80H @14MHz won't require more than around 50ns for a write operation, and there's 210ns between operations even with a three-cycle read/write operation.

This means BLT/Vector hardware can operate for around 90,000 cycles each screen ( 50 times per second ) which even assuming a poor case of 4 cyles/BLT-op, should be around 22500 pixels/update, or enough to cover half the screen - and that's at 64 colours in four bit planes.

So video speed should not be an issue. Especially at 256x192x64+4 - that's more than enough to render "Mortal Kombat" at 25 fps with two frame buffers. All without the CPU making a single video write - which it can do concurrently - as well as supporting general DMA at speeds of more than 3 bytes per microsecond... Although that's not possible since the z80 DMA 6MHz is not really available any more.

Though I still have to define what video modes will be supported at the base-level since it greatly affects the configuration of the chips involved.

And I still might install some CPU-side DMA rather than relying on block transfer. Then again, at 10 to 14 MHz, Block Transfer is still pretty impressive on a z80. I'm in two minds about that... But I believe a z80 system running CP/M could have challenged PCs well into the 90s.

[4thRock]

I think it's important that the graphics retain a certain "Spectrum feel". In my opinion, the only enhancements that still look Spectrum are ULAPlus, 8x1 attributes, and 256x192x16 (ex: ATM / Pentagon no attributes).

I think the ULAPlus/ULAPlus HAM modes are interesting because they are designed to minimize memory and processing power footprint.
This is an impressive example image, considering that it only uses the standard Spectrum screen memory and attribute limitations:
https://spectrumcomputing.co.uk/entry/2 ... 256_Viewer

I think ULAPlus/ULAPlus HAM would look great if used with the 256x192x16 no attributes.

(I don't have much technical knowledge, so sorry if this is nonsense But from a user/gamer POV, those are types of graphics I'd like to see on an advanced Spectrum machine )

[Lethargeek]

i thing most cost effective for a 1985 would be -

same 32x24 attribute tiles, but...
1) IF ink != paper THEN it's the same 8x8x2 colours tile like the old Spectrum
2) IF ink == paper THEN it's something different, like 4x8x4 (rectangular pixels in 4 colours out of the 16 configurable mini-palettes)
and maybe (but not for TVs)
3) IF ink == paper AND flash = 1 THEN it's 16x8x2 (that ink over one global bg colour)

so we could have regions of mid-res with colour clash, low-res without it and maybe less coloured hi-res for text work

[1024MAK]

Similarly, I'd be surprised if a high horizontal resolution was much use. The Amstrad could do it, but having the monitor (which was a glorified TV) connected via RGB rather than a standard (for the time) RF signal probably is the only reason it was acceptable. And even then it wasn't perfect.

Point of order!

Firstly, the Spectrum wastes a significant amount of horizontal screen display due to the borders. That could be improved by using some of that area for display, as some of its rivals did. Heck, even the humble ZX81 can be coaxed into having a slightly wider horizontal resolution if a custom display driver is used.

The horizontal “safe area” is approximately 44.8 µs. So 512 pixels needs a pixel clock of 11.43MHz or faster.

Secondly, there were other home computers that did offer a significantly better horizontal resolution and which worked acceptably using either monochrome composite video or RGB on what was a standard colour CRT TV with suitable inputs (suitable TVs were available in 1985). And even before then, suitable monitors existed. So I don’t think we should limit the design based purely on what a colour UHF picture would look like. Indeed, the only reason for an UHF output to be included on home computers was because back in the early 1980s, many TVs did not have any other inputs.

In terms of other home computers that had a better horizontal resolution, the most comparable being the Timex TS2068 and TC2068 which both had a 512×192 pixel display (although in this mode, only two colour).

Yes, there does need to be a balance between the amount of display data that needs to be moved around and the capability of the processor (or other system) to do this. But the whole point of the Loki was to have a better video system and faster processor.

The ZX Spectrum clocks it’s Z80A (rated at 4MHz) at 3.5MHz (approximately) only because it is a multiple of the frequency used by the video system and this was cheap and easy to do. Very occasionally a Z8400B (Z80B 6.17MHz) part is discovered in a Sinclair computer (still running at 3.5MHz, of course, it’s impossible to know if the faster part was used as a replacement or was originally fitted during manufacturing).

The very existence of the BBC Micro shows that DRAM chips that were fast enough were available. By 1985, DRAM was more reliable and faster DRAM access time chips were available.

The normal compromise is a split between cost and performance, with the video system, performance includes a compromise between resolution, colour depth, and the amount of RAM needed.

With a more complex design, you can reduce the problem of both the processor and video system trying to access the same RAM at the same time.

Mark

[cj7hawk]

Interestingly, also in 1985, two different kinds of video ram were appearing, static video rams and dynamic video rams.

Dynamic video rams were dual-port, but required a complex video controller as the line address had to be written into the video ram from the computer side of the bus, so some contention would always be present.

But the static rams were hitting 10 to 15ns and you could get SRAMs designed for video purposes with a single bit output where the slowest in the series began at 70ns and got faster from there. That lets you run multiplexed addresses at 14 MHz, with a 7Mhz share time, allowing for 256 VRAM addresses at 7 MHz with 70ns Static Video Ram, which was even reasonably priced back then in any quantity. Worst case, running asynchronously, you miss your timeslice, but you'll still pick up the next one with a total cycle time that shouldn't exceed around 210ns for read or write ops.

These rams hit in 1981 IIRC, with 16K x 1, then by 84/85 there were 64k x 1 bit rams, with separate data input and output ( though like DRAM you can connect them together if you want ) - Super cut-down chips. No output enable, just Chip Select and you pretty much just keep them selected and change the addresses, and the timing lends itself to time-multiplexed access, and will arbiter the write even if you do connect the din and dout, and just a little more circuitry gives you a fully asynchronous 5MHz processor side bus with zero wait.

Just a few years later, you could even use normal static rams for the same purpose, but the technology was definitely emerging in 1985. Hence I'm pursuing a design to provide an asynchronous zero-wait design with a best-speed of 4~5MHz, but that's assuming you need to read ram at 200ns... Which is what you approach with a z80 at 20 MHz... Also the z80H can be well and truly ( and quite stably ) overclocked. Tests show the fastest stock z80s can usually run at 33 MHz, which is pretty decent. So I imagine 12 to 14MHz should have been possible in 85 with 8 MHz still a "safe" frequency.

Not to mention once you have the zero-wait non-contention architecture, you're using less than half the time available for the raster, so you start looking and what else the video circuit could do during that time - especially if you've got extra memory in video space that isn't used - so you start looking at sprites and hardware vector graphics as possibilities.

A spectrum running about 4 times as fast should have no problems working with a high colour display. Especially if there's some hardware support for block transfers and vector drawing and a lot of RAM. If you can draw lines on the screen at something even approaching a million pixels a second, with no CPU overhead on that, then it should be possible to create some decent video output, not to mention that sometimes it's easier to push pixels at higher colour resolution around than at lower colour resolution, as the calculation overhead for pixels is eliminated at 256x192 - No translations are required.

Anyway, I decided to aim at 14 MHz for the pixel clock became it matches RAM speeds of the era, and also matches the original Speccy... However it has space for a Genlock to be added, which even if one is not added, the horizontal clock loses relevance, so it would be entirely possible to add a small simple hardware "Stretcher" module in place of the Genlock since it can also change the horizontal clock rate and vertical resolution. Both necessary capabilities when using a genlock. Also there's no hardware overhead to implement it. I still have to build it and try it on era-specific RGB monitors anyway, and if I don't like it, the circuit can take almost any primary frequency up to about 16.5MHz. After that, it's going to exceed the chips I am using.

But a z80 based Spectrum running at 33 MHz would perform pretty well. Maybe not like a 33MHz 386, but certainly better than a quarter of it's speed.

I imagine that I'll hit more issues. Seems that the more I build the more some of the specs want to lean a little more one way or the other - but I'll definitely have a 256 and a 512 pixel horizontal mode. I'm wrestling still with whether to add in an extra chip and make it 50/60hz selectable.

[cj7hawk]

So some chips came in and I built the video card out of 6 chips - 2 would have been GALs and one the memory chip (64K x 1) but the other three could have been latching or tristating buffers that act as arbiters and latch the video signal for the output stage. I built the proof of concept PCB and turned it on...

And got video, aligned with the Spectrum video timing. It's only 1 bit at the moment, since I didn't have enough spare PCB to add the other 7 RAM chips, but the theory has now been tested and works off of a very low chip count. The only problem is that I simplified it so much I pretty much have to double the chip count to add a "Spectrum" screen mode...

256x192x64 colours and 512*x192x16 colours would have been possible, with a 7 MHz synchronous access time, so would have worked with a 14 MHz z80 back in 1985 with one wait state half the time on read ops, and zero wait states on writes ( or zero read/write at 7MHz ). I have been testing the video with an 8051 and pushing out vector points ( angle plus distance ) at about 100,000 pts/sec, which isn't bad for old technology. Though it is a one-cycle-8051... So about 10 times faster than a normal 8051. The video is very quick with only a few relatively inexpensive chips and would have given EGA a run for it's money. Seems that 70ns ram is needed to achieve the goal, but otherwise it's very doable with minimal logic and would have easily fit within a Speccy ULA.

But... What to do about the missing Spectrum video mode?

Anyway, as a thought, how would the Loki have been received if the original sinclair video mode was an add on, and you could have retained the original "Speccy" as the keyboard and with it's own video? That would have allowed people with a 128K or 64K to plug in a small dongle to the back and keep their keyboard as well as being able to connect microdrives and use the Spectrum as a second screen.

Or a second "Spectrum" compatible screen add-on could be inserted into a slot or a daughterboard riser.

I'm looking for creating concepts about how to maintain backwards compatability while driving towards a new architecture with around 4 times the speed and much higher resolution graphics with, as they put it, "Cartoon Quality" Graphics. Though B&W photo images would have been quite possible without much circuitry.

I'm still looking to add hardware vector graphics ( aiming at around 2 pixels/microsecond ) and two dimensional DMA for sprites and the like, and will try to combine them ( textured vector lines ). But I'd really appreciate thoughts about how important it would have been to retain old spectrum modes - For some it's an absolute but for others, especially "Business Users" that Sinclair so deperately wanted, it would have been unnecessary.

What are the creative options to maintain backwards compatability even if it's an optional extra? Any thoughts?

OH, BTW, in the current iteration of the design spec I've done one thing I don't think they Loki would have done. I've switched to the ISA BUS... Since they were stealing ideas like there was no tomorrow, so theoretically, it should be possible to stick an EGA or a VGA card in it also....And other cards like the Serial and Parallel port cards.

David