Freddie chip: why aren't the XE machines faster?

[billyc]

Hi, newbie question here.

 

After reading a bunch of stuff all over the web, I understand the 800XLF and XE machines use a new "Freddie" chip for memory management. From what I understand, Freddie and the faster internal system clock work together so that the ANTIC chip no longer needs to halt the 6502 while it accesses video RAM. In a pre-Freddie setup, ANTIC steals around 20-30% of the clock time away from the CPU! That's a lot, and that's why some programs turn ANTIC off while they're doing slow calculations. I even wrote a few of those back in the day for my (non-Freddie) 800XL.

 

So here's my question: why aren't the XE machines 20-30% -faster- than the XL computers? What happened to that 20-30% of clock time? Did it just... disappear?

 

Curious if anyone has thought about this and if I just haven't found the answer in my searches.
 

Thanks everyone!

..billy

 

 

 

Edited February 3, 2021 by billyc

[TGB1718]

I think you have to set the RAM access mode to achieve this, maybe the default is not to use the feature.

 

Here's a good read on the subject.

 

https://www.atarimagazines.com/v4n7/memorymanagement.html

 

Edit: just had a quick read, it looks like the default for bit's 4 and 5 which control RAM access

is 11, so in that mode the share the same RAM

Edited February 3, 2021 by TGB1718
Update

[Rybags]

Freddie just replaces a bunch of generic LS series ICs that were involved in memory selection (mostly Ras/Cas type stuff).

 

It does a whole bunch of stuff in less space and probably less power consumption but doesn't really add any new features.

It runs at ~ 14 MHz which gets divided down - NTSC uses ~ 3.59 MHz for video generation and that speed is also half a machine cycle which can provide the Ras/Cas transition.  Then 1.79 MHz for the CPU.

But we still have memory refresh and Antic DMA like older machines.  In theory the XL/XE could probably have gotten away with less refresh cycles, like 5 per scanline instead of 9 but then you'd have gotten a small performance gain with the tradeoff that a whole bunch of software (mostly games) wouldn't work the same any more.

[drac030]

5 minutes ago, Rybags said:

In theory the XL/XE could probably have gotten away with less refresh cycles, like 5 per scanline instead of 9 but then you'd have gotten a small performance gain with the tradeoff that a whole bunch of software (mostly games) wouldn't work the same any more.

While the performance gain (3.5% if I calculate correctly) indeed would probably be not worth any effort, I somewhat doubt if this could have any noticeable impact on significant amount of software - this considering how much old stuff works at really faster clock speeds.

[Rybags]

The impact as I see it would be on kernal and DLI based stuff.   Likely most RastaConverta images wouldn't work properly.

 

The obvious solution though would have been to put a control bit in an Antic register to select small/big refresh.

[drac030]

That would be taken care of by the authors, if XE were this faster in comparison to XL. I guess no additional hardware flags necessary (although nice), as this probably would be detectable in software to make cycling delays adjusted. 3.5% may seem like nothing, but this is like adding nearly 12 rasterlines to a frame.

[xrbrevin]

several computer manufacturers did something similar back in the day. they found they could reduce production costs and outsourcing by lowering the chip count - achieved by building as many glue logic chips as possible into a single unit. i wondered if the gains/benefits were stifled in order to maintain 100% compatibility with the original 'bloated' design?

[Rybags]

Well, in theory with the lower latency Ram in use they could have added a little extra hardware to buffer CPU accesses and done refresh and DMA transparently.

[+Nezgar]

I had previously pondered about if extended memory was enabled, but only for ANTIC, not CPU, and the display list and screen data is all within that extended bank, if in an alternate reality ANTIC could access that RAM without blocking CPU access to main RAM, giving the 30% speedup with a full screen... but I guess that would need a whole separate bus redesign on the hardware side...

[Rybags]

Yep... like ChipRam vs FastRam on the Amiga.  Though my idea before would probably be just as complex.

[billyc]

38 minutes ago, Nezgar said:

I had previously pondered about if extended memory was enabled, but only for ANTIC, not CPU, and the display list and screen data is all within that extended bank, if in an alternate reality ANTIC could access that RAM without blocking CPU access to main RAM, giving the 30% speedup with a full screen... but I guess that would need a whole separate bus redesign on the hardware side...

 

I guess this is exactly what I was thinking about -- but yeah, that's not how it was designed, was it.

 

OK thank you everyone!

[_The Doctor__]

give antic/(possibly gtia) their own ram, could be sram (avoids need for refresh), once you load all your bits and pieces into that ram cpu can trigger them on demand and keep chugging along... instead of halt line stopping cpu, you might repurpose halt signal from antic/graphics to signal done with whatever for syncing/acknowledgment. Sounds VBXE ish in a way

Edited February 5, 2021 by _The Doctor__

[+Stephen]

That is another advantage that can be gained by using VBXE.  If you are not using it in overlay mode, it provides the full display with ANTIC off, so CPU gets the full 1.79MHZ all the time.