3 ms·

Atari ST - Can we start the screen memory on any address in video RAM? No, limited boundaries. - Can we restart the screen display from another address during

by xroche 9y ago

Atari ST - Can we start the screen memory on any address in video RAM? No, limited boundaries. - Can we restart the screen display from another address during the display? No What ? It could definitely be set to any memory address (with same 16-bit boundary as the Amiga)

to3m 9y ago
The bottom 8 bits were alway zero, so all you could really do was 8 row (1280 byte) vertical scrolling. I don’t think you could change the screen base address mid-frame either, so you’d need a double-height buffer to do a continuous scroll. The STe fixed both of these problems, and had variable wid5h rows and the pixel offset thing too. That meant a setup that was roughly equivalent to a 4-bit Amiga screen, though with interleaved bitplanes (which is not necessarily a bad thing).
- cmrdporcupine 9y ago
  The STe Blitter was really great, but totally underutilized because it was such a small fraction of the ST market. Atari really dropped the ball by getting the Blitter to market so late. Interesting the different approaches. Commodore shipped the Amiga 1000 at too expensive a price point, and so Tramiel (who had rushed the ST to market just before the Amiga) got in with a rock bottom priced machine that initially looked like it would kill the Amiga (which was his intention.) But Commodore followed up with the cost reduced Amiga 500 which ended up winning against Atari Corp in the home gaming market (though IMHO the ST and offshoots were still far better productivity machines than the Amiga and did well in that market in Germany). Going back to some of those ST games I loved, they have really crappy frame rates and high latencies.
cmrdporcupine 9y ago
One thing that stuck out for me was this comment: "Amiga Do we have enough CPU time to rebuild everything on the screen every frame? Just about." That seems dubious, given he says the Atari ST is "not really". Both had the same processor and the ST had a higher clock rate. The Amiga could only out-do the ST in graphics performance because of sprites and scrolling, but manually rebuilding the whole framebuffer on every refresh was not possible on _either_ machine. The Amiga could "cheat" by using dedicated hardware for specialized tasks. But could not really rebuild a whole frame each time either.
- boomlinde 9y ago
  Copper, scrolling, sprites etc., sure won't actually touch the frame buffer. What you're forgetting is the blitter, which indeed is a way for the Amiga to redraw the whole framebuffer faster than its CPU alone could handle, AFAIK well within the time span of a frame. Add game logic and other I/O to that and the difference could very well cross the line between not enough CPU and enough CPU.
  - cmrdporcupine 9y ago
    Well, sure, but I guess I read what he was saying as "CPU can rebuild buffer before next frame", not as "CPU + specialized chips can etc." But if you read it the latter way, yeah, the Amiga creams the ST. But if what you're doing isn't something that the blitter can help with, the two are roughly the same. So for example, on the various 3d wireframe games that came out for those platforms (i.e. Starglider, etc.), the ST had a slight edge due to its slightly higher clock rate. In fact anywhere where it's just polygonal drawing, the ST had a very slight edge.
    - z303 9y ago
      The Amiga's Blitter actually has line [1] and polygon fill [2] modes. Obviously this does require code to be rewritten to take advantage of the extra hardware. On a CPU > 68000 the tradeooff between CPu and blitter is different [3] [1] http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node0128.html http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_gui... [2] http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node0122.html http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_gui... [3] http://eab.abime.net/showthread.php?t=50815 http://eab.abime.net/showthread.php?t=50815
z303 9y ago
Just to add some more details to what to3m said. The ST's screen address did have to be on a 256 byte boundary. With 160 bytes per scanline you could scroll 8 scanline vertically by changing the screen address. People did work out a methods of scrolling the screen with finer control. Sync scrolling [1] used overscan techniques. ST screens had a border around the image, not filling the whole screen. Methods were developed to the bottom, right, left and top borders [2]. By combining left and right border removal different offsets could be generated to position the screen on any 16bit/pixel boundary [3]. [1] http://www.atari-forum.com/viewtopic.php?f=1&t=4357&sid=8a77efcf7c22a8117efeec8372136658 http://www.atari-forum.com/viewtopic.php?f=1&t=4357&sid=8a77... [2] http://aldabase.com/atari-st-fullscreen-demos-history/ http://aldabase.com/atari-st-fullscreen-demos-history/ [3] https://blog.troed.se/2015/12/23/overscan-and-sync-scrolling/ https://blog.troed.se/2015/12/23/overscan-and-sync-scrolling...

by xroche 9y ago

to3m 9y ago

The bottom 8 bits were alway zero, so all you could really do was 8 row (1280 byte) vertical scrolling. I don’t think you could change the screen base address mid-frame either, so you’d need a double-height buffer to do a continuous scroll. The STe fixed both of these problems, and had variable wid5h rows and the pixel offset thing too. That meant a setup that was roughly equivalent to a 4-bit Amiga screen, though with interleaved bitplanes (which is not necessarily a bad thing).

cmrdporcupine 9y ago
The STe Blitter was really great, but totally underutilized because it was such a small fraction of the ST market. Atari really dropped the ball by getting the Blitter to market so late. Interesting the different approaches. Commodore shipped the Amiga 1000 at too expensive a price point, and so Tramiel (who had rushed the ST to market just before the Amiga) got in with a rock bottom priced machine that initially looked like it would kill the Amiga (which was his intention.) But Commodore followed up with the cost reduced Amiga 500 which ended up winning against Atari Corp in the home gaming market (though IMHO the ST and offshoots were still far better productivity machines than the Amiga and did well in that market in Germany). Going back to some of those ST games I loved, they have really crappy frame rates and high latencies.

cmrdporcupine 9y ago

One thing that stuck out for me was this comment: "Amiga Do we have enough CPU time to rebuild everything on the screen every frame? Just about." That seems dubious, given he says the Atari ST is "not really". Both had the same processor and the ST had a higher clock rate. The Amiga could only out-do the ST in graphics performance because of sprites and scrolling, but manually rebuilding the whole framebuffer on every refresh was not possible on _either_ machine. The Amiga could "cheat" by using dedicated hardware for specialized tasks. But could not really rebuild a whole frame each time either.

boomlinde 9y ago
Copper, scrolling, sprites etc., sure won't actually touch the frame buffer. What you're forgetting is the blitter, which indeed is a way for the Amiga to redraw the whole framebuffer faster than its CPU alone could handle, AFAIK well within the time span of a frame. Add game logic and other I/O to that and the difference could very well cross the line between not enough CPU and enough CPU.
- cmrdporcupine 9y ago
  Well, sure, but I guess I read what he was saying as "CPU can rebuild buffer before next frame", not as "CPU + specialized chips can etc." But if you read it the latter way, yeah, the Amiga creams the ST. But if what you're doing isn't something that the blitter can help with, the two are roughly the same. So for example, on the various 3d wireframe games that came out for those platforms (i.e. Starglider, etc.), the ST had a slight edge due to its slightly higher clock rate. In fact anywhere where it's just polygonal drawing, the ST had a very slight edge.
  - z303 9y ago
    The Amiga's Blitter actually has line [1] and polygon fill [2] modes. Obviously this does require code to be rewritten to take advantage of the extra hardware. On a CPU > 68000 the tradeooff between CPu and blitter is different [3] [1] http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node0128.html http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_gui... [2] http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node0122.html http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_gui... [3] http://eab.abime.net/showthread.php?t=50815 http://eab.abime.net/showthread.php?t=50815

z303 9y ago

Just to add some more details to what to3m said. The ST's screen address did have to be on a 256 byte boundary. With 160 bytes per scanline you could scroll 8 scanline vertically by changing the screen address. People did work out a methods of scrolling the screen with finer control. Sync scrolling [1] used overscan techniques. ST screens had a border around the image, not filling the whole screen. Methods were developed to the bottom, right, left and top borders [2]. By combining left and right border removal different offsets could be generated to position the screen on any 16bit/pixel boundary [3]. [1] http://www.atari-forum.com/viewtopic.php?f=1&t=4357&sid=8a77efcf7c22a8117efeec8372136658 http://www.atari-forum.com/viewtopic.php?f=1&t=4357&sid=8a77... [2] http://aldabase.com/atari-st-fullscreen-demos-history/ http://aldabase.com/atari-st-fullscreen-demos-history/ [3] https://blog.troed.se/2015/12/23/overscan-and-sync-scrolling/ https://blog.troed.se/2015/12/23/overscan-and-sync-scrolling...