The simplicity, again in my view, of 8 bit type hardware is very helpful. The distinction being computation, and that's not too much different of an experience, and making things actually happen, which can be a widely different experience! In my view, playing with assembly is best done while also either playing with hardware, or really understanding and having access to said hardware at the 'raw metal' level. The instruction set and overall CPU complexity, and the hardware it's running on. Some of the graphics seen near the end of SD were sweet! Like almost every issue woven into a nice looking, very clever package. Were there placement limits per glyph to keep these things consistent? Did you guys get down to that detail? Good placement against say a blue background, maybe gradient to also mask even odd line effects. Placing the glyph on an even pixel start might generate a bluish artifact, and a reddish one on an odd pixel. Going sharper would mean a potential color artifact amd or different ones, depending on the alignment between the color clock and the ramp pixel start? (How many TV newscasts went with blue and white?) Avoiding it entirely is gonna be soft, or strict limits on color combos. That ramp seems like it needs to align with that clock too, or there would be color fringing. (We had a couple of those and it was crappy obvious) If, say target frame buffer was some multiple of the color clock, it would be 320, 640, maybe as low as 160 pixels. It also explains some of what we would see on various systems too. You could get away with it on CATV bulletin board devices, but not in high quality titlers.Ĭool. The font on this type was very crude- either fixed width characters like a terminal or semi-proportional spaced, where the width had to be a multiple of some number of pixels (so still character cells). On the other hand, we did roll and crawl effects using fast 6809 assembly on other products. This is not so easy to do well because the vertical sync detector in the monitor is pre-charged by the nearest horz sync (this is why NTSC has the double-rate serration pulses for interlace).

To make smooth slow scrolling without complex sampling we moved the screen by changing the vertical sync position. Anyway, we could get very high resolution this way with a tiny fast SRAM frame buffer, it looked great.Ī problem was that even with the 68000, composing a page from text was quite slow: 10 seconds for single line, something like that. The hardware decoded it on the fly when generating the video. So the frame buffer was compressed using run-length coding. (on previous products they experimented with bubble memory and even shipped a product using CCD memory).

This was before the great DRAM price decline, so every effort was made to reduce the memory including the frame buffer. At VDS, there was 68000-based titler called Vidstar or Videostar, something like that.

Os9 68k emulator -mac -macos