4 ms·

24bit, at ~70%(?) true m68k speed, because CPU was constantly halted by video chip.

by rasz_pl 12y ago

jacquesm 12y ago
Address space size has nothing to do with access speed, but yes, the video chip and the cpu were competing for access to the ram. This happens in every graphic display interface that does not use dual-ported RAM or some kind of dedicated CPU doing the writing of the video RAM, you're always going to have contention. The ST was a pretty clever compromise to reduce costs, unfortunately they weren't reduced far enough to give the machine a longer production run.
- rasz_pl 12y ago
  >Address space size has nothing to do with access speed hence the comma > happens in every graphic display interface that does not use dual-ported RAM or some kind of dedicated CPU doing the writing of the video RAM Not quite what I had in mind. Atari (called 'Agricultural equipment' by Polish Commodore fanboys https://www.youtube.com/watch?v=oMkCboYJ-tw https://www.youtube.com/watch?v=oMkCboYJ-tw ) had to constantly halt cpu just to fetch pixels. This is on par with how Spectrum did video 8-9 years before it. Amiga on the other hand had a nice separate dedicated 'slow ram' where you were able to actively perform operations (think of it like a very primitive pixel shader - dma with xor/and/not/or on the fly) while CPU was unaffected (running full speed on separate 'fast ram'). Its not like it was a rocket science concept, this is how video was handled on MSX computers/X68000/Sega consoles. Did I mention sprites? What sprites haha, scrolling? ..... Everything at the time had separate video memory bank, everything but the farming Atari ST. Yes, it was the cheapest m68K machine on the market, but it only made it terrible.
  - to3m 12y ago
    The CPU isn't halted - it's denied access to the bus. A lot of the time, this doesn't matter, which is presumably why they chose to do it that way, because most 68000 instructions won't be accessing the bus at the time anyway. (Supposedly, if you have a long instruction that doesn't use the bus, such as DIVx or MULx, and you get your timing right, you can overlap it with the blitter, which on the ST always runs in some approximation of nasty mode - better you than me though.) More info (than you probably ever cared to know) here: http://pasti.fxatari.com/68kdocs/AtariSTCycleCounting.html http://pasti.fxatari.com/68kdocs/AtariSTCycleCounting.html

24bit, at ~70%(?) true m68k speed, because CPU was constantly halted by video chip.

by rasz_pl 12y ago

24bit, at ~70%(?) true m68k speed, because CPU was constantly halted by video chip.

Address space size has nothing to do with access speed, but yes, the video chip and the cpu were competing for access to the ram. This happens in every graphic display interface that does not use dual-ported RAM or some kind of dedicated CPU doing the writing of the video RAM, you're always going to have contention. The ST was a pretty clever compromise to reduce costs, unfortunately they weren't reduced far enough to give the machine a longer production run.

rasz_pl 12y ago
>Address space size has nothing to do with access speed hence the comma > happens in every graphic display interface that does not use dual-ported RAM or some kind of dedicated CPU doing the writing of the video RAM Not quite what I had in mind. Atari (called 'Agricultural equipment' by Polish Commodore fanboys https://www.youtube.com/watch?v=oMkCboYJ-tw https://www.youtube.com/watch?v=oMkCboYJ-tw ) had to constantly halt cpu just to fetch pixels. This is on par with how Spectrum did video 8-9 years before it. Amiga on the other hand had a nice separate dedicated 'slow ram' where you were able to actively perform operations (think of it like a very primitive pixel shader - dma with xor/and/not/or on the fly) while CPU was unaffected (running full speed on separate 'fast ram'). Its not like it was a rocket science concept, this is how video was handled on MSX computers/X68000/Sega consoles. Did I mention sprites? What sprites haha, scrolling? ..... Everything at the time had separate video memory bank, everything but the farming Atari ST. Yes, it was the cheapest m68K machine on the market, but it only made it terrible.
- to3m 12y ago
  The CPU isn't halted - it's denied access to the bus. A lot of the time, this doesn't matter, which is presumably why they chose to do it that way, because most 68000 instructions won't be accessing the bus at the time anyway. (Supposedly, if you have a long instruction that doesn't use the bus, such as DIVx or MULx, and you get your timing right, you can overlap it with the blitter, which on the ST always runs in some approximation of nasty mode - better you than me though.) More info (than you probably ever cared to know) here: http://pasti.fxatari.com/68kdocs/AtariSTCycleCounting.html http://pasti.fxatari.com/68kdocs/AtariSTCycleCounting.html