Understanding X68000 graphics modes for smooth scrolling

The Sharp X68000 is remembered for sharp arcade conversions, colourful computer games and unusually capable graphics for a Japanese home computer of its era. Much of that character comes from the way its video hardware separates graphic planes, colour depth and display timing. Understanding those choices makes smooth scrolling easier to reproduce in original software and modern homebrew projects.

The phrase “graphics mode” can mean several different things on the X68000. It may describe the horizontal resolution, the number of colours available, the amount of VRAM assigned to a plane, or the CRTC timing used by the monitor. These settings interact, so selecting a mode is less like choosing a single screen preset and more like balancing memory, bandwidth and visual detail.

Smooth movement also depends on how the program uses VRAM. A game can move a complete background by changing a scroll position, copy new map data into an off-screen area, or redraw the visible scene every frame. Each technique has a different cost on the 68000 CPU and the graphics bus.

For Australian collectors and developers, there is an additional practical concern: original Japanese hardware is often connected to modern displays through scan converters, RGB interfaces or specialist upscalers. A mode that scrolls perfectly in software may still show tearing, unstable synchronisation or incorrect borders if the display chain cannot handle the X68000’s signal.

How the X68000 display system is organised

The X68000 uses dedicated graphic VRAM rather than treating the screen as a simple block of ordinary system memory. Graphic screens are arranged as bitplanes or colour-indexed pages, with the video hardware combining those planes to produce the displayed pixels. This arrangement allows a program to select a palette entry quickly while keeping the memory requirement lower than a full true-colour framebuffer.

Common display choices include 256-pixel and 512-pixel horizontal widths, with corresponding vertical arrangements suited to games, productivity software and high-resolution artwork. Lower-resolution modes generally leave more memory and transfer time available for animation. A 512-pixel-wide screen gives finer detail, yet the same scrolling operation may touch twice as many bytes across a line.

Colour depth affects the calculation as well. A 16-colour mode uses fewer bitplanes and is comparatively economical, while 256-colour modes provide richer artwork at the cost of more VRAM traffic. Some later or specialised modes support a much larger colour range, but they are not automatically better for scrolling. The X68000 technical archive provides useful background for identifying the hardware and software conventions behind these modes.

The display also has text and graphic functions that should be considered separately. Text VRAM is well suited to status panels, menus and debug information, whereas graphic VRAM is the natural home for scrolling playfields. Keeping a fixed score bar in a separate layer or region can prevent the program from redrawing it every frame.

Choosing a mode for moving playfields

A side-scrolling game usually benefits from a modest horizontal resolution and a limited colour depth. A 256-pixel-wide, 16-colour playfield can be updated quickly, especially when the scenery uses repeated tiles and a compact palette. This leaves processor time for collision checks, enemy logic, sound commands and sprite-like object drawing.

A 512-pixel mode makes sense when the design depends on fine text, detailed maps or large character art. It can still scroll smoothly, but the programmer must be more disciplined about what changes each frame. Updating an entire 512-pixel-wide strip at every movement step wastes bandwidth when only a narrow column has entered view.

The best approach is often to divide the scene into a scrolling background and independently positioned objects. The background can move through a hardware scroll register or a carefully managed screen origin, while characters and effects are drawn relative to the camera. When the camera crosses a tile boundary, the program updates only the newly visible map column or row.

Palette planning matters as much as pixel throughput. A 16-colour scene can look rich when several palettes are assigned to different objects or regions, but palette changes must be coordinated with the display timing. A carefully designed palette reduces the need for large graphic transfers and can make an older screen mode look far more detailed than its colour count suggests.

Hardware scrolling and software scrolling

Hardware-assisted scrolling changes the part of VRAM that is treated as the visible origin. The image remains in memory while the display window moves across it, which is much faster than copying every pixel to a new framebuffer. This method is especially effective for tile maps that are wider or taller than the visible screen.

The map still needs to be maintained. Once the viewport advances far enough, new tiles must be drawn into the area that has moved off-screen and is about to become visible again. A ring-buffer layout is useful: the program treats the background as a repeating VRAM surface, writes new columns into the vacated area, and allows the display hardware to reveal them through scrolling.

Software scrolling is more flexible but more expensive. It may involve shifting a whole screen, copying rectangular blocks, or redrawing the scene from map data. This can be acceptable for a small puzzle game or a mostly static image, but a full-screen copy at 50 or 60 updates per second quickly competes with every other task.

Fine scrolling needs special care. If the hardware scroll position moves by a pixel while the map is stored in larger tiles, the program must separate pixel movement from tile replacement. The camera advances smoothly each frame, then triggers a map update only when it crosses the chosen tile width. This avoids the jerky movement caused by redrawing the complete background on every step.

Timing, buffering and the 68000

The vertical blanking interval is the natural point to update scroll registers, exchange buffers and commit changes that should appear together. Making critical updates during this period reduces visible tearing, where the monitor scans some lines before a new position has been installed and other lines afterwards.

Double buffering can keep drawing away from the currently displayed page. The CPU renders or updates the hidden page, then switches the visible source at a controlled moment. This uses additional VRAM and may require more copying, so it is most valuable when the scene contains many moving objects or when a complete frame is being composed.

Direct Memory Access can help transfer blocks without making the 68000 perform every individual move instruction. It does not make the graphics operation free: the transfer still occupies system resources, and poorly timed DMA can interfere with sound or input processing. Large, contiguous transfers are usually more efficient than many tiny ones.

The frame budget should be measured rather than guessed. A program targeting the common 50 Hz television-style rate has roughly 20 milliseconds per frame; a 60 Hz target has roughly 16.7 milliseconds. The exact budget depends on the selected display timing and software design, but the principle remains the same: reserve time for input, game logic, audio and housekeeping before assigning every available cycle to graphics.

Australian users may encounter this issue when testing Japanese X68000 software on a modern LCD in Brisbane, Adelaide or Perth. A display may accept the signal yet buffer it unpredictably, making a stable game appear to stutter. Testing with an RGB-capable scaler, checking the refresh behaviour and comparing output on original-compatible equipment can distinguish software timing problems from display latency.

Practical testing on original and modern setups

Begin with a small scrolling test rather than a complete game. Fill a graphic page with a repeating grid, move the scroll position by one pixel per frame, and display a counter or timing marker. This reveals whether the mode supports the intended movement and whether the update is synchronised with vertical blanking.

Test horizontal and vertical movement separately. Horizontal scrolling can expose incorrect line pitch, page wrapping or narrow transfer routines, while vertical scrolling can reveal mistakes in screen height and origin calculations. A pattern containing alternating colours and labelled tiles makes it easier to spot a one-byte or one-line alignment error.

Hardware condition also affects results. Ageing power supplies, oxidised connectors and failing capacitors can produce noise or unstable video that looks like a graphics bug. Australian owners often source replacement parts through local electronics suppliers in Sydney or Melbourne, while specialist X68000 components may need to be imported from Japan. Freight costs, GST and limited availability can make preventative repair more sensible than repeated overseas purchases.

The second-hand market has its own complications. X68000 machines sometimes appear on eBay Australia, Gumtree or at retro-computing events, but a low purchase price may conceal a damaged floppy drive, missing expansion memory or a non-original power modification. A reliable scrolling test is useful when evaluating a machine because it exercises the video output, memory and timing under sustained activity.

Display approach	Visual character	Scrolling cost	Suitable use
256-pixel, 16-colour playfield	Compact artwork and strong palette discipline	Low	Fast arcade-style backgrounds and tile maps
256-pixel, 256-colour playfield	Richer colour with moderate detail	Moderate	Detailed action scenes and demonstrations
512-pixel, 16-colour playfield	Fine resolution with limited palette	Moderate	Interfaces, maps and precise graphic layouts
512-pixel, 256-colour playfield	Detailed image with heavier VRAM traffic	High	Artwork-rich scenes and slower-moving displays
Larger-colour or specialised modes	Broad tonal range and demanding transfers	Very high	Static images, experiments and selected demos

A smooth result comes from matching the mode to the movement the software actually needs. If the game scrolls constantly, a lower-cost indexed-colour mode with a well-designed tile set is usually preferable. If the screen changes rarely but demands fine artwork, a higher-resolution mode may be the better compromise.

For preservation work, document the selected CRTC settings, page arrangement, palette format and update method alongside the source code. Future developers may have the same machine but a different monitor, scaler or memory expansion, and those details make the difference between a reproducible technique and an unexplained visual effect.

Experiment with a small VRAM scrolling demo, record its timing on your own display chain, and keep notes about every mode that behaves reliably. Sharing those observations through the X68000 enthusiast community helps maintain practical knowledge of a computer whose graphics hardware still rewards careful, hands-on programming.