Basilisk II Atari

[calimero]

Actually, the ST with Spectre GCR is only faster because the clock speed is higher than the Mac. Both have contended RAM access for video in the same way.

Macs from 1984/85/86 was clocked at ~8MHz, like ST.

Even on wikipedia you can read: https://en.m.wikipedia.org/wiki/Macintosh_512K
that effective clock is ~6MHz because of 68000 and video controller took turns accessing DRAM every four CPU cycles during display of the frame buffer.

ST is much smarter designed and does not suffer from this problem.

Although I am not sure when Apple fix this problem…

[mikro]

ST is much smarter designed and does not suffer from this problem.

I wouldn't be so sure about this. :-) As Stephen writes above, ST/STE/TT and its DMA works on a very similar principle.

[calimero]

ST is much smarter designed and does not suffer from this problem.

I wouldn't be so sure about this. :-) As Stephen writes above, ST/STE/TT and its DMA works on a very similar principle.

Yes,
I usually printing books all day along so DMA eating my cycles :coffee:
and I am looking only few minutes on monitor during the day... :geek:

You can not compare DMA "slowdowns"* and stalling CPU during video access. :shock:
btw Stephen even wrote: "Both have contended RAM access for video in the same way" - and this is crucial difference between Mac and ST.

If Mac had 640 x 400 / 71Hz resolution then 8MHz 68000 in Mac would be probably at ~4MHz level... :-D

*it is actually speed up!

Someone mentioned that Atari, in early ST days, used RAM chips out-of-spec to achieve this 'non-stalling-CPU-while-Shifter-do-what-is-need-to-be-done'... ;)

[mikro]

You can not compare DMA "slowdowns"* and stalling CPU during video access. :shock:

You said:

Even on wikipedia you can read: https://en.m.wikipedia.org/wiki/Macintosh_512K
that effective clock is ~6MHz because of 68000 and video controller took turns accessing DRAM every four CPU cycles during display of the frame buffer.

To quote Cyprian from AF:

In ST/TT memory access slots are split into even and odd cycles. Even - used by the CPU, the BLiTTER (ST only) and HDD/FDD drive DMA, and odd - used by MMU (Shifter and Sound DMA) and memory refresh. It means there is no way to disturb CPU code by the video mode or DMA sound. But the BLiTTER (ST only) and HDD/FDD drive DMA can delay the CPU code.

So whatever makes the Mac slower than the ST, it's certainly not interleaved memory access.

[stephen_usher]

Maybe it's time someone ported EmuTOS to the Macintosh Plus and we ran a race? ;-)

[calimero]

You can not compare DMA "slowdowns"* and stalling CPU during video access. :shock:

You said:

Even on wikipedia you can read: https://en.m.wikipedia.org/wiki/Macintosh_512K
that effective clock is ~6MHz because of 68000 and video controller took turns accessing DRAM every four CPU cycles during display of the frame buffer.

To quote Cyprian from AF:

In ST/TT memory access slots are split into even and odd cycles. Even - used by the CPU, the BLiTTER (ST only) and HDD/FDD drive DMA, and odd - used by MMU (Shifter and Sound DMA) and memory refresh. It means there is no way to disturb CPU code by the video mode or DMA sound. But the BLiTTER (ST only) and HDD/FDD drive DMA can delay the CPU code.

So whatever makes the Mac slower than the ST, it's certainly not interleaved memory access.

I suspect that I have language problem. For me, it looks like that you do not understand what I am writing (or Cyprian in matter of fact :D ).

Facts:
1. Mac MC68000 CAN NOT access RAM while video logic displaying picture on monitor lowendmac.com 1)
2. ST MC68000 CAN access to RAM during SAME operation ("displaying picture on monitor") because Atari ST RAM is fast enough, or pushed little beyond specification, so Shifter can access RAM without stalling CPU (like Cyprian wrote: "there is no way to disturb CPU code by the video mode or DMA sound"). MC68000 can read/write RAM at full speed all the time (except in case of 3.)

This is reason of speed difference of 8MHz Motorola in ST and Mac.

3. In addition, ST, like Cyprian wrote, have DMA ability that can stall CPU to access RAM but this DMA operation will do same job as CPU but FASTER: BLiTTER and DMA for HDD/FDD (or so in the perfect world :) ). So ST 68000 is prevented to access RAM when other chips perform faster operation than 68000 would do and it is NOT stalled by REQUIRED operation such is drawing picture on screen.


1) There is also explanation why there was no 8bit Macs without dedicated video card, mode like we had in TT - Apple never get this approach to build faster Mac with FastRAM. They rather put dedicated Video RAM on motherboard.


@stephen_usher nice one! :D

[Cyprian]

@calimero @mikro

I've just found a nice explanation how the Mac 512k memory bus is managed and shared between the 68k and the video:
http://www.merlintec.com/lsi/mac512.html
and here page 39:
https://archive.org/details/byte-magazi ... ew=theater

If I understand it correctly, the CPU has full speed access to the ROM (4 cycles per access I guess) and a half speed access to the RAM (8 cycles per access).
In case of the ST it is 4 cycles for both - ROM and RAM. Therefore it seems the RAM in the Mac 512k is clocked twice slower than in the ST.
That "effective clock is ~6MHz" could be understand as a sum of ROM (a full speed - 8MHz) and RAM (a half speed 4MHz) access: (8 + 4) /2 = 6MHz
Stupid from the Tech side, understandable from the Marketing side.

[ctirad]

Hello. Basilisk runs well on my MegaST/Pak68/3/Frak1/Panther2 using latest Nova Mach64 drivers from idek. It runs pretty well, however there are some gfx issues.

1. In the 256 color mode MAC OS starts in grayscale and so the 256 color games (namely PoP).
2. For other resolutions than 640x480, BII starts but it clearly uses wrong resolution (broken screen).
2. In 65k color mode MAC OS has correct colors, but 256 games claims about incompatible mode. I assume this not BII fault, though.

[Badwolf]

Hello. Basilisk runs well on my MegaST/Pak68/3/Frak1/Panther2 using latest Nova Mach64 drivers from idek. It runs pretty well, however there are some gfx issues.

1. In the 256 color mode MAC OS starts in grayscale and so the 256 color games (namely PoP).

3. In 65k color mode MAC OS has correct colors, but 256 games claims about incompatible mode. I assume this not BII fault, though.

Point 1 is normally configurable in the Mac OS control panel. You can choose greys or colours.

Point 3 is, yes, sadly true of most Mac games. I think BII lets you emulate 256 colours under 16-bit mode, but no point if you have a proper 256 mode.

BW

[ctirad]

I see. I completely overlooked that. Thanks.