Jump to content
IGNORED

Accelerated 6502!


danwinslow

Recommended Posts

Cool - but some hurdles for us.

First up it's not pin compatible except for non-Sally 400/800 systems.

 

Next up - it looks like the IO area fencing is simple and possibly hardcoded so not really suitable for use with Antic/GTIA.  I don't think it responds to DMA requests by the look of it.

What we'd need is to be able to have certain Ram write operations go to normal system memory so Antic can get to them.  Or maybe just have all writes go to the legacy hardware (which would occur at the slower speed and slow everything down somewhat)

  • Like 1
Link to comment
Share on other sites

3 minutes ago, Rybags said:

Cool - but some hurdles for us.

First up it's not pin compatible except for non-Sally 400/800 systems.

 

Next up - it looks like the IO area fencing is simple and possibly hardcoded so not really suitable for use with Antic/GTIA.  I don't think it responds to DMA requests by the look of it.

What we'd need is to be able to have certain Ram write operations go to normal system memory so Antic can get to them.  Or maybe just have all writes go to the legacy hardware (which would occur at the slower speed and slow everything down somewhat)

They said it was 6502C compatible...I thought that was what we used?

Anyway, I bet you guys could do something cool with this.

 

Edited by danwinslow
Link to comment
Share on other sites

2 hours ago, Rybags said:

What we'd need is to be able to have certain Ram write operations go to normal system memory so Antic can get to them. 

This concept is already implemented:

 

"(...) The 65F02 makes sure that all write accesses to video RAM go to both, its on-chip RAM and the host RAM. Then a read access to video RAM will find the required information in the on-chip RAM, and can hence proceed at the full 100 MHz clock rate.

This feature is now implemented for the Apple II and the CBM/PET series. One benchmark where it really shines is “Brian’s Theme”, a graphics demo that shipped with the Apple, programmed by Brian Howard. (...)"

 

But having the ability to being stopped by Antic, altogether, not sure... Should happen on 400 / 800 architecture, since both take regular 6502 like a walk in the park... but it does not seem like the 65F02 is yet designed to be off the bus while ANTIC reads RAM mirrored in host A8 base memory.

 

Also notable is the fact that it may not be possible to accelerate  extended ram access... so code running out of the 65F02 sand-box is hosed at regular speed....

 

Even so, due its flexible design and implementation, the 65F02 has a LOT of potential, and this is just the beginning!

 

 

Link to comment
Share on other sites

That's probably part of the IO fencing.

 

It's easy on other systems because they generally have a fixed area for video Ram.  Even C64 which like us has a complex video system will generally have all it's video related stuff in a 16K bank.

We can put video related data anywhere including Rom or seperate banked Ram so the whole thing is a lot more complicated.

 

But no reason why the project couldn't be customised for Atari - the pinout, and build in some extra logic to detect when an extended Ram access is taking place.

Link to comment
Share on other sites

That'd be helpful - so possibly a quick and dirty way to get it working, and have a patched OS that sets the write-through / IO space to the bottom of the display list each time the screen is opened.  For bootable games, maybe a mode where most of Ram is write-through.

Link to comment
Share on other sites

22 hours ago, Mathy said:

 

@guus.assmann has designed a PCB years ago that will enable you to use a standard 6502 (as in: Non-Sally) in a non 400/800 Atari 8 bit computer.

 

As that 65F02 is based on an FPGA it could be possible to program it to be pin-compatible with a Sally. I read some discussion about its Atari compatibility on FB and the idea there was that it would need to allow ANTIC to access its internal RAM whenever ANTIC does DMA access.

Link to comment
Share on other sites

For machine language games the extra speed won't make any difference in a lot of cases.

Most are VBlank driven and most will do a limited amount of object processing so speed won't matter a lot.

Games that will be affected are ones that do rendering which usually takes over a frame, e.g. Mercenary, Rescue on Fractalus.

 

In some cases DLI processing might have glitches.

 

For games that don't work properly, fixing them would usually be fairly easy.

Link to comment
Share on other sites

52 minutes ago, Rybags said:

In some cases DLI processing might have glitches.

But is not this precisely where a fast CPU would help the most, especially if it runs in exact speed multiples of Antic?

 

Isn't a DLI the reverse concept: we interrupt Antic and then service the interrupt with CPU to perform mid-line chores, and then back to Antic? If this process can speed-up in "harmonious" speed increments, shouldn't we have more time for GFX-tricks (more colors,  more soft-sprites), higher complexity core game-logic, peripheral and user inputs, etc., all still with good-old, simple and elegant 6502 code?

 

Now, on the other hand, running at a theoretical 100mhz, opens the door for keeping ANTIC out of the picture, and driving GTIA directly, with pure muscle... a scenario in which everything is kept under the 65F02 belt, and whatever GTIA can graphically generate... like VCS2600 on steroids?

Link to comment
Share on other sites

You could use it to hit the hardware directly (almost every cycle) a bit like the 2600 accelerators.

It would overcome a lot of limitations but not be a miracle worker.

To reuse a PM object you need to reposition it then optionaly do the graphics and colour.

You could change colour registers but 4 palette entries still = 4 cycles.

And you still have the limitation when hitting the hardware of the 1.79 MHz external speed.  Then you also have to contend with graphics DMA and refresh steals.

Link to comment
Share on other sites

Yeah, it's not going to be a 100MHZ atari. But, I think maybe with some work we could turn it into something that would allow extra processing capability during vblank or dli's, that could be very useful. Yes, it's got to live with the external bus speeds, and access to RAM will be as slow. Even just a system that doubled the 1.79 speed exactly would be an mprovement. I don't know if it makes sense to think about some kind of faster RAM local to the cpu, kind of like a cpu cache that it could use, off the bus and free to use at a faster rate while still being able to use the regular RAM. There's a lot I don't know, but we've seen some amazing things done and this just seems really promising.

Link to comment
Share on other sites

The first and most obvious thing to me is the fact you could do rendering at 50+ times the speed.  Such that a 3D engine approaching Quake could just about happen.  Not to mention doing dozens of softsprites.  Though of course you have that need to make the graphics data available to Antic which is potentially the biggest overhead.

 

Though given this is an addon that's adding non-downward compatible abilities, no reason not to add some extra CPU abilities such as as blitter to shift graphics from the internal to shared Ram.

Edited by Rybags
Link to comment
Share on other sites

3 hours ago, ClausB said:

Wonder if there's enough room in the FPGA for an ANTIC core.

Yeah, this is the other train of thought on this matter....

 

What I see there, however, seems like a complex timing-threesome (not that I am anywhere an expert at it... 8-O 

 

Would not this approach mean that 65F02, RAM-F and Antic-F clocks will need to be controlled individually or at least programmatically, in any down/up-clocking combination required?

Link to comment
Share on other sites

I get the feeling that at 100 MHz it could just be autonmously clocked and just listen the the host clock and know when to participate in bus activities.

The sync skew you'd get is like 2% which equates to probably less than the propogation delay you'd have talking to other addressable stuff on the board anyway.

For onboard Antic - you'd then need a bunch of other signals like the ANx bus, input for light pen etc etc.

But if going onboard Antic then may as well do GTIA as well which would reduce the pin count back a bit.

Then you're into the realm of "well, just add Pokey and the rest of the legacy system becomes excess baggage" and you may as well do a modern day recreation.

Link to comment
Share on other sites

5 hours ago, Rybags said:

Then you're into the realm of "well, just add Pokey and the rest of the legacy system becomes excess baggage" and you may as well do a modern day recreation.

So, this line of argument has been done to death. We all know where we stand. I would want to use this board as an accelerator plugin to enhance the machine, not render it unnecessary. No 100hz, no thousands of of softsprites....just a little faster of a machine but hopefully more compatible than Rapidus. 

Link to comment
Share on other sites

44 minutes ago, danwinslow said:

No 100hz, no thousands of of softsprites....just a little faster of a machine

No, that's sounds to me like plain conventional thinking, sort of a self-inflicted "stuck in limbo" mentality.

 

Retrospectively, I haven't seen anything truly special made of out conventional ideas, so far. Just because an ideal implementation or integration approach has not been fully defined or agreed, it does not mean we need to discard the benefits of 100+ Mhz clock speeds.

 

A system architecture like the 400 / 800 (for instance), where the [CPU, Antic, GTIA] are all located in a dedicated board, and separate from the MoBo, it's been begging for a plug-and-play upgrade like this, since its first day of existence. ?

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...