Atari v Commodore

[atariksi]

You misunderstood. Supercat is right-- logic is simple if you only make cycles free for those instructions you are guaranteed to have bus on rather than complicate the circuit by conditional free cycles. As Supercat stated, you can know through simple logic when opcode is fetched. Depending on opcode, you can make a logic for a guaranteed free cycle for refresh without involving a complex circuit like another 6502. You don't have to get all the possible free cycles. A simple circuit that gets a few from Inc/Dec or implied instructions would fit the bill.

 

IMHO, this doesn't make any sense.

 

The logic required to implement this (even just for the simple cases that unconditionally have a dummy cycle) is not simple at all, and the task is not a minor one.

 

If you were going to implement something like this, it would be much better and simpler to use static ram instead of DRAM. Then avoiding the need of refresh cycles alltogether. And while you change to SRAM, you could easily make it work at twice the system clock. Then you could interleave Antic and CPU bus mastering, recovering not just refresh cycles, but all the DMA cycles as well.

 

In either case you need much more than just minor simple logic. More than Bob's brilliant XL7 design (which is simpler and more powerful at the same time).

 

You need to consider that refresh cycles do not have to occur exactly at the same position-- you can defer them like ANTIC already does for overloaded DMA scenarios. There's a whole bunch of leeway. The logic should include a disable/enable so it's backward compatible (obviously), but by even setting up a simple logic where you only do implied single byte 2-cycle instructions, you can gain almost the 7% CPU time loss on the refresh cycles. As soon as you detect opcode fetch of single byte implied instruction, you know the next cycle is free from bus.

[potatohead]

Merry Xmas everybody.

 

I've learned a ton from this thread, and really appreciate the screenies! Several new games to play in that lot! Sweet!

 

C64 Atari C64 Atari -- 8 bits rule. Game on people!

[ijor]

The logic should include a disable/enable so it's backward compatible (obviously), but by even setting up a simple logic where you only do implied single byte 2-cycle instructions, you can gain almost the 7% CPU time loss on the refresh cycles.

 

Unless your definition of "simple logic" is taken in a very loose sense, then I'm not sure you have an idea of what you are talking about.

 

I don't see how you could do this in such a simple way that it would be worth. It is of course feasible, but (once again) the logic required wouldn't be much simpler (if at all) than using SRAM. Let alone comparing this with Bob's 7.16 MHz accelerator.

 

If you still insist you could do this with simple logic, can you please describe that simple logic/circuit that would accomplish the task?

[Rybags]

It'd probably be easier and cheaper to just have shadow RAM. Writes go to both, reads from Antic and the CPU only goto the relevant "copy".

 

Then you'd have no cycle steals at all vs some piddly improvement that's barely worth the effort.

 

Writing programs for better efficiency or using certain techniques that aren't used much would save cycles anyway.

How many games use PMGs on only 150 or so scanlines - there's about 500 cycles gone to waste just there, you could selectively turn off DMA when the objects are guaranteed not to be there.

[atarian63]

35 - MR. DO !

 

Atari screenshots

 

There is no doubt where you want to mix colors, graphics, sound and motion on one game, Atari is the best system to work, not easy, but the results worth the wait. Atari version was programmed using hardware sprites and software sprites, good set of colors on screen, nice arcade music, intermediate screen. In brief the best version, only comparable to the NES counterpart.

 

 

C64 screenshots

 

Mr. Do is awesome on the Atari - I only wish other authors put as much time and effort into the little things like this one........................Dig Dug should've been almost arcade perfect

I have a Mr Do! at the office, the Atari version is pretty much spot on!

[ijor]

It'd probably be easier and cheaper to just have shadow RAM. Writes go to both, reads from Antic and the CPU only goto the relevant "copy".

 

Duplicating the RAM won't work, not without extra logic. You'll have a problem when CPU writes and Antic reads on the same cycle.

 

Dual-port ram might be a better option. Dual-port RAM would sove the write/read conflict as long as each port doesn't attempt to access the same address. You would still need extra logic to implement a delay if there is a same address conflict.

 

Either way, once you go to that extent, it doesn't take much more to allocate separate time slots for Antic and CPU.

 

Then you'd have no cycle steals at all vs some piddly improvement that's barely worth the effort.

 

Even then, I'm still not sure it is worth the effort. All these ideas make much more sense when you combine them with some kind of CPU accelerator.

[ijor]

Even then, I'm still not sure it is worth the effort.

 

EDIT:

 

To get an idea of the complications involved, consider how you would solve the conflict if the CPU writes to Antic ($D4XX) at the same cycle that Antic is performing a DMA cycle.

[atariksi]

The logic should include a disable/enable so it's backward compatible (obviously), but by even setting up a simple logic where you only do implied single byte 2-cycle instructions, you can gain almost the 7% CPU time loss on the refresh cycles.

 

Unless your definition of "simple logic" is taken in a very loose sense, then I'm not sure you have an idea of what you are talking about.

 

I don't see how you could do this in such a simple way that it would be worth. It is of course feasible, but (once again) the logic required wouldn't be much simpler (if at all) than using SRAM. Let alone comparing this with Bob's 7.16 MHz accelerator.

 

If you still insist you could do this with simple logic, can you please describe that simple logic/circuit that would accomplish the task?

 

Actually, this topic started when the theoretical question was raised as to what Atari could have done with the refresh cycles. So from that point of view at least, it was simple enough for Atari to just use the idea I suggested which is more optimal than just moving the refresh cycles to another part of the scanline. I NEVER compared this method to bob's 7.16Mhz accelerator. It's an algorithm to reduce DMA cycles during a scanline. It is simpler than making an entire accelerator board. It's obvious you haven't read the 99 pages-- regardless I would still claim it's simpler than an entire accelerator board or some other method of static RAM buffering.

 

Here's one implementation that Atari could have done-- just use a pin like S3 on GTIA or something to disable refresh so it only happens if a 2-cycle implied instruction occurs-- i.e., leave it to software to when refresh takes place at same positions. Another one might be to just pass the signals through some ROM that outputs a HALT/refresh signals according to input signals.

[atariksi]

It'd probably be easier and cheaper to just have shadow RAM. Writes go to both, reads from Antic and the CPU only goto the relevant "copy".

 

Then you'd have no cycle steals at all vs some piddly improvement that's barely worth the effort.

 

Writing programs for better efficiency or using certain techniques that aren't used much would save cycles anyway.

How many games use PMGs on only 150 or so scanlines - there's about 500 cycles gone to waste just there, you could selectively turn off DMA when the objects are guaranteed not to be there.

 

The original question was what Atari could have done with the refresh cycles. Your solution requires more modifications to the motherboard and is more expensive and not simple. As far as being "piddly", saving 9 cycles per scanline for all scanlines is more than 5 cycles/scanline for 240 scanlines and they are mutually exclusive-- you can do both optimizations. Your remarks of not worth the effort remind of this story of the fox and grapes. The fox tried to jump and grab the grapes a few times but could not get them so decided that the grapes were sour anyway so why bother with them, and then he left them alone.

 

And you can also use it optimize other DMA cycles as well not just refresh cycles.

[Crazyace]

Did the 4116's support transparent refresh? I was looking at some datasheets and I saw that they supported fast page mode - I think having support of fast page mode would have great.

Trying to analyse for unused 6502 instructions might breakdown on a bit/bpl wait loop

[ijor]

Actually, this topic started when the theoretical question was raised as to what Atari could have done with the refresh cycles. So from that point of view at least, it was simple enough for Atari to just use the idea I suggested which is more optimal than just moving the refresh cycles to another part of the scanline. I NEVER compared this method to bob's 7.16Mhz accelerator. It's an algorithm to reduce DMA cycles during a scanline. It is simpler than making an entire accelerator board. It's obvious you haven't read the 99 pages-- regardless I would still claim it's simpler than an entire accelerator board or some other method of static RAM buffering.

 

Indeed it started as how Atari could have handled the refresh, but it ended in something completely different. You were talking about "without motherboard redesign", "backwards compatibility", so you obviously were talking about some kind of modificiation/upgrade, not about a change in the original design. At least that the way I interpreted it, and all my comments were from this point of view. Obviously, doing this from the start, where you could "easily" make changes to Antic internals, makes the issue orders of magnitude simpler and easier than a "post" modification.

 

I know you never compared this with an accelerator, I made the comparison. My point is that implementing your idea (as a mod, not in the original design) is as complicated (and possibly even more) than an accelerator. Talking about an accelerator or using SRAM in the original design doesn't make any sense, it would have been too expensive back then.

 

And once again, if you still claim it's simpler (as a mod to the current models), then please provide a circuit description. Detecting those "free dummy cycles" is not big deal. The problem is, once you know you have a free cyle, how to perform the refresh. Even more challenging is how to "recover" the "standard" Antic refresh cycles (otherwise, if you don't recover these cycles, you didn't gain anything at all). And then you have further problems, as the one mentioned above when the CPU would try to access Antic. Possibly there are even more issues that we didn't consider.

 

Here's one implementation that Atari could have done...

 

Atari could have done lots of things. Personally, I think that "what-if" retrospective discussion is not very interesting. But even then, it would still be a technically challenge. For starters, you have a timing problem, a ROM implementation would definitely have been too slow. But above all, I'm not sure it would have been, conceptually, a very good idea back then (it is completely different now that we know all the history).

[ijor]

Did the 4116's support transparent refresh? I was looking at some datasheets and I saw that they supported fast page mode - I think having support of fast page mode would have great.

Trying to analyse for unused 6502 instructions might breakdown on a bit/bpl wait loop

 

I don't think the original 4116 chip supported CBR refresh (possibly later variations did). But in the case of the A8, it is not too important, you wouldn't gain too much. For a post modification of current motherboards, yes, it could be useful on one hand. But on the other hand you would need to modify the CAS/RAS generation logic. And at this point, it might be better again to use SRAM and forget about refresh at all.

 

Page mode would have been quite difficult to use efficiently.

[atariksi]

Did the 4116's support transparent refresh? I was looking at some datasheets and I saw that they supported fast page mode - I think having support of fast page mode would have great.

Trying to analyse for unused 6502 instructions might breakdown on a bit/bpl wait loop

 

We are not using all the free cycles so there are cases where implied instructions won't exist but at least you have the option of disabling/enabling the refresh to optimize according to code. So if this was a i/o port time critical loop, you would disable the refresh first and your code would be something like:

 

LDA #8

Sta 53279

Loop: BIT 54016

BPL Loop

Lda #0

Sta 53279

 

However, if your code was in ROM and you didn't care about RAM refresh:

 

Loop: BIT 54016

BPL Loop

 

Here it's more optimal since worst case is 9 cycles whereas with refresh on, it's >10 cycles.

[atariksi]

Actually, this topic started when the theoretical question was raised as to what Atari could have done with the refresh cycles. So from that point of view at least, it was simple enough for Atari to just use the idea I suggested which is more optimal than just moving the refresh cycles to another part of the scanline. I NEVER compared this method to bob's 7.16Mhz accelerator. It's an algorithm to reduce DMA cycles during a scanline. It is simpler than making an entire accelerator board. It's obvious you haven't read the 99 pages-- regardless I would still claim it's simpler than an entire accelerator board or some other method of static RAM buffering.

 

Indeed it started as how Atari could have handled the refresh, but it ended in something completely different. You were talking about "without motherboard redesign", "backwards compatibility", so you obviously were talking about some kind of modificiation/upgrade, not about a change in the original design. At least that the way I interpreted it, and all my comments were from this point of view. Obviously, doing this from the start, where you could "easily" make changes to Antic internals, makes the issue orders of magnitude simpler and easier than a "post" modification.

...

We agree here as ANTIC can determine if next cycle is free from bus internally and have less HALTs.

 

>I know you never compared this with an accelerator, I made the comparison. My point is that implementing your idea (as a mod, not in the original design) is as complicated (and possibly even more) than an accelerator. Talking about an accelerator or using SRAM in the original design doesn't make any sense, it would have been too expensive back then.

 

Okay, I don't agree it's more complicated than an accelerator if implemented today. Original implementation would involve just upgrading ANTIC.

 

>And once again, if you still claim it's simpler (as a mod to the current models), then please provide a circuit description. Detecting those "free dummy cycles" is not big deal. The problem is, once you know you have a free cyle, how to perform the refresh. Even more challenging is how to "recover" the "standard" Antic refresh cycles (otherwise, if you don't recover these cycles, you didn't gain anything at all). And then you have further problems, as the one mentioned above when the CPU would try to access Antic. Possibly there are even more issues that we didn't consider.

 

You're complicating things. CPU can't write to ANTIC during a implied 2-cycle instruction. You don't have to perform the refresh-- just let ANTIC do it as it's doing it-- you just have to code it so enough implied instructions exist required for refresh.

 

>Atari could have done lots of things. Personally, I think that "what-if" retrospective discussion is not very interesting. But even then, it would still be a technically challenge. For starters, you have a timing problem, a ROM implementation would definitely have been too slow. But above all, I'm not sure it would have been, conceptually, a very good idea back then (it is completely different now that we know all the history).

 

It is interesting since I did turn the "what if" into today's implementation. ROM requires one cycle to do the look-up of the signals which you have. Main circuit is just feed the data lines and other signals into the address lines and take whatever signals are needed from the data output. The whole thing can just plug into CPU socket. ROM idea would have been good even in 1980s as Atari was producing millions of ROMs already so it would have been cheap for them.

[ijor]

>And once again, if you still claim it's simpler (as a mod to the current models), then please provide a circuit description. Detecting those "free dummy cycles" is not big deal. The problem is, once you know you have a free cyle, how to perform the refresh. Even more challenging is how to "recover" the "standard" Antic refresh cycles (otherwise, if you don't recover these cycles, you didn't gain anything at all). And then you have further problems, as the one mentioned above when the CPU would try to access Antic. Possibly there are even more issues that we didn't consider.

 

You're complicating things. CPU can't write to ANTIC during a implied 2-cycle instruction. You don't have to perform the refresh-- just let ANTIC do it as it's doing it-- you just have to code it so enough implied instructions exist required for refresh.

 

Sorry atariksi, but you either have no idea how refresh is implemented, or either you are being completely unreasonable.

 

ANTIC performs a refresh according to its own logic and (well known) algorithm. There is no way to tell Antic to perform a refresh at the cycles you want. If you want to perform ram refresh in any other cycle, then you are on your own. You can take control of the REF signal, that's not big deal. But your logic would need to generate the RAM row address by yourself.

 

And that's just the easy part. Generating refresh cycles on "free" CPU cycles is not enough. You must sill prevent ANTIC to perform its "own" refresh cycles, which halt the CPU and take control of the address bus. You must do this, because you want to recover those cycles for normal CPU usage (that's the whole point, isn't it?).

 

This is both complicated and challenging. In first place you would need to disconnect ANTIC from the system address bus on those cycles, otherwise ANTIC would drive the bus and would conflict with the CPU. You would need to cut all the ANTIC address bus from the motherboard, and bring all the ANTIC address signals to a mux.

 

After you did that, you still need to handle HALT. Even when you disconnect ANTIC from the address bus, it would still assert HALT, something that obviously you need to avoid (you don't want the CPU to halt on those cycles, do you?). And you must disable HALT only on the Antic refresh cycles, not on Antic DMA cycles. The problem is that there is no simple easy way to distinguish among both of them (DMA and refresh). You can't use the REF signal because it is activated too late, HALT is asserted on the previous cycle. So you need to have logic that would need to trace ANTIC activity to detect beforehand when it would attempt a refresh cycle.

 

Of course that the CPU won't access ANTIC on a simple implied instruction, that's not the problem. The problem is that the CPU might attempt to access ANTIC on one of those refresh recovered cycles. How you would handle that? There is no way to perform an ANTIC access on those cycles because it is driving the address bus. You would need to HALT the CPU, and somehow defer the cycle for a more "suitable" time.

 

Does this look like a "simple logic" to you?

 

ROM requires one cycle to do the look-up of the signals which you have.

 

The problem is that you don't have a full cycle, not even half a cycle. It is only by the end of the opcode cycle that RAM (or ROM) would return the actual opcode data. And you need to prepare the system for refresh before this same cycle ends.

 

The whole thing can just plug into CPU socket.

 

Do you still think so? In the best case, using the ANTIC socket would be much better.

Edited December 26, 2008 by ijor

[atariksi]

>And once again, if you still claim it's simpler (as a mod to the current models), then please provide a circuit description. Detecting those "free dummy cycles" is not big deal. The problem is, once you know you have a free cyle, how to perform the refresh. Even more challenging is how to "recover" the "standard" Antic refresh cycles (otherwise, if you don't recover these cycles, you didn't gain anything at all). And then you have further problems, as the one mentioned above when the CPU would try to access Antic. Possibly there are even more issues that we didn't consider.

 

You're complicating things. CPU can't write to ANTIC during a implied 2-cycle instruction. You don't have to perform the refresh-- just let ANTIC do it as it's doing it-- you just have to code it so enough implied instructions exist required for refresh.

 

Sorry atariksi, but you either have no idea how refresh is implemented, or either you are being completely unreasonable.

...

OR you don't understand the simpler implementation.

 

>ANTIC performs a refresh according to its own logic and (well known) algorithm. There is no way to tell Antic to perform a refresh at the cycles you want. If you want to perform ram refresh in any other cycle, then you are on your own. You can take control of the REF signal, that's not big deal. But your logic would need to generate the RAM row address by yourself.

 

You don't perform the refresh in the simpler implementation-- ANTIC does it. If you were trying to squeeze out every free bus cycle, you can have a generic more complex circuit. I'll answer the rest later after I look up the opcodes for various 6502 instructions... So far you are making things more complicated as I stated.

[atariksi]

...

And that's just the easy part. Generating refresh cycles on "free" CPU cycles is not enough. You must sill prevent ANTIC to perform its "own" refresh cycles, which halt the CPU and take control of the address bus. You must do this, because you want to recover those cycles for normal CPU usage (that's the whole point, isn't it?).

...

That's not the whole point-- you only recover the cycles where it fits in using the simplified approach. If there's a cycle available not using the bus and HALT is going to happen on the same cycle, you don't do the HALT. So whatever caused the HALT (refresh or DMA) occurs in parallel with the execution of the instruction. Just like Pentium pairs up instructions if it's do-able.

 

>...cycles. The problem is that there is no simple easy way to distinguish among both of them (DMA and refresh). You can't use the REF signal because it is activated too late, HALT is asserted on the previous cycle. So you need to have logic that would need to trace ANTIC activity to detect beforehand when it would attempt a refresh cycle.

 

It does not matter if it's refresh cycle or DMA doing the halt as you have the bus available for both without halting CPU. If HALT is on previous cycle, you can still deal with it without making it complex.

 

>Of course that the CPU won't access ANTIC on a simple implied instruction, that's not the problem. The problem is that the CPU might attempt to access ANTIC on one of those refresh recovered cycles. How you would handle that? There is no way to perform an ANTIC access on those cycles because it is driving the address bus. You would need to HALT the CPU, and somehow defer the cycle for a more "suitable" time.

 

Already explained.

 

>Does this look like a "simple logic" to you?

 

Yes (my version). Not your implementation.

 

>>ROM requires one cycle to do the look-up of the signals which you have.

 

>The problem is that you don't have a full cycle, not even half a cycle. It is only by the end of the opcode cycle that RAM (or ROM) would return the actual opcode data. And you need to prepare the system for refresh before this same cycle ends.

 

I would say you have one cycle, but I just browsed through all the opcodes and it's quite easy to select which opcodes use implied 2-cycle instructions without involving ROM (just simple gates). All opcodes with 2-cycle implied modes are $X8 or $XA where X is don't care. ROM method is better in that you can also throw in opcodes like $60 (RTS) which also don't use the bus on the 2nd cycle although it's not a 2-cycle instruction.

 

>>The whole thing can just plug into CPU socket.

 

>Do you still think so? In the best case, using the ANTIC socket would be much better.

 

Last I checked SYNC signal is on 6502 not ANTIC and HALT signal is also available on 6502 and refresh doesn't matter as you can remove some DMA cycle HALTs as well while we're at it. Look at from this perspective, even if you do NOT align instructions so that bus-free cycles don't correspond to DMA/refresh cycles, it won't slow down anything. It can only speed up things especially if you align things. Nine refresh cycles still occur, but if your code happens to be aligned or you purposefully align it, they will be free-bies (along with some graphics DMA cycles as well).

 

The other *SIMPLE* implementation I was thinking with regards to the BIT/BPL example was to try to reduce the number of refresh cycles (when you don't need them 9/scanline). So if you only did 5 refresh cycles, you won't try to make up for them some down the road; they just won't occur.

[ijor]

OR you don't understand the simpler implementation...

So far you are making things more complicated as I stated...

That's not the whole point-- you only recover the cycles where it fits in using the simplified approach. If there's a cycle available not using the bus and HALT is going to happen on the same cycle, you don't do the HALT. So whatever caused the HALT (refresh or DMA) occurs in parallel with the execution of the instruction. Just like Pentium pairs up instructions if it's do-able.

...

>Does this look like a "simple logic" to you?

 

Yes (my version). Not your implementation.

 

Are you serious?

 

You brought the idea of gaining the refresh cycles, by moving them to cycles that the CPU doesn't really need. You debated with everybody about your idea. You claimed it needed simple logic only. You even made fun out of Rybags when he said it was not worth, and that he reminded you about the Fox and the Grapes.

 

Then, after I showed you that implementing your idea is complicated almost beyond imagination, you abandon it completely and come up with a completely different approach. But instead of saying "yeah, I was wrong, it was a nice idea but honestly, I had no idea it would be so difficult to implement, let's try something different" ... instead of saying "sorry Rybags, I am now the one that feel like the Fox in the Grapes"...

 

No, instead you blame me and claim that the problem was my implementation ??? It wasn't "my implementation", it was the only possible way to implement your idea of moving the refresh cycles.

 

>>The whole thing can just plug into CPU socket.

>Do you still think so? In the best case, using the ANTIC socket would be much better.

Last I checked SYNC signal is on 6502 not ANTIC and...

 

That's a good one, keep taking the comments completely out of context. Both yours and my statements you quoted here, were about idea "A", not about idea "B".

[Allas]

36 - NINJA

 

Atari screenshots

 

Atari forget the graphics intro, but the game have a lot of colors. Great chambers at oriental style. Now, it looks easy to finish, but on his time was really hard to play.

 

C64 screenshots

[atariksi]

OR you don't understand the simpler implementation...

So far you are making things more complicated as I stated...

That's not the whole point-- you only recover the cycles where it fits in using the simplified approach. If there's a cycle available not using the bus and HALT is going to happen on the same cycle, you don't do the HALT. So whatever caused the HALT (refresh or DMA) occurs in parallel with the execution of the instruction. Just like Pentium pairs up instructions if it's do-able.

...

>Does this look like a "simple logic" to you?

 

Yes (my version). Not your implementation.

 

Are you serious?

 

You brought the idea of gaining the refresh cycles, by moving them to cycles that the CPU doesn't really need. You debated with everybody about your idea. You claimed it needed simple logic only. You even made fun out of Rybags when he said it was not worth, and that he reminded you about the Fox and the Grapes.

 

Then, after I showed you that implementing your idea is complicated almost beyond imagination, you abandon it completely and come up with a completely different approach. But instead of saying "yeah, I was wrong, it was a nice idea but honestly, I had no idea it would be so difficult to implement, let's try something different" ... instead of saying "sorry Rybags, I am now the one that feel like the Fox in the Grapes"...

 

No, instead you blame me and claim that the problem was my implementation ??? It wasn't "my implementation", it was the only possible way to implement your idea of moving the refresh cycles.

 

>>The whole thing can just plug into CPU socket.

>Do you still think so? In the best case, using the ANTIC socket would be much better.

Last I checked SYNC signal is on 6502 not ANTIC and...

 

That's a good one, keep taking the comments completely out of context. Both yours and my statements you quoted here, were about idea "A", not about idea "B".

 

The algorithm still works whether the implementation changes according to how simple you want to make it. You could move the cycles as well if you were making this part of another hardware upgrade. The fox and grapes example fits in perfectly-- if you jump and you can't get it; you can modify your approach not give up. Your worse than Rybags-- your complaining that now that there is a method to get the grapes, why did you modify your original approach. Always looking at the negative. If you were so good about your information about 6502, you would have stated "perhaps, there's another way" not it's too complex and not worth it.

[atariksi]

Great SID Tune links, BTW!

 

Of course, you can have nice music on both systems. It would be more interesting to look at the hardware perspective on both and see if one is achievable on the other rather than what has been done.

[emkay]

Great SID Tune links, BTW!

 

Of course, you can have nice music on both systems. It would be more interesting to look at the hardware perspective on both and see if one is achievable on the other rather than what has been done.

 

 

Actually, I'd prefer to do comnparisions of the stuff that is done already. You'll clearly see the advantage of the SID for making music. Another clear thing is that the used software for POKEY music is all but perfect. POKEY's biggest suffer is the lack of analogue filters and the volume resolution. Many people blame Pokey for the 8 bit pitch resolution, but this fact is not that essential for creating music. You can build very much "tricks" for gaining similar volumes, slides etc. as SID can do. It seems, for coders it is too hard to create sufficient software. And, if you want to "top out" SID Music (not sound), you need CPU powers, leaving not enough time for other stuff then.

[potatohead]

For me the matter is settled. There are some things each machine can do, that are difficult or lower quality or something on the other.

 

What I find most interesting is advances on what the Atari can do. The areas where people appear to be pushing the edge are areas I find interesting. I like all the retro efforts, and look at advances or good quality work on any machine, and can easily say, "wow! That's great for machine X". So the link to the great SID tunes was very enjoyable.

 

To me though, working double over time to get SID tunes out of POKEY seems foolish. Why not just make better POKEY tunes?

 

I suspect there is a lot in the chip that's not yet been exploited because it's a tougher chip. I also suspect what's in there isn't gonna sound like a SID, so much as it will sound like a really well handled POKEY.

 

That, to me is what is interesting more than anything else. I like the Atari feel, look and so that's where I pay the most attention to new tricks and productions.

 

Looking back is fun too. There are great games and productions all over the place. Sometimes there are good ideas in there, missed, or glossed over. All good. Seeing if what can be done on C64 can be done on Atari isn't really where it's at for me though. Much better to just see what else can be done on Atari.

[ijor]

Your worse than Rybags-- your complaining that now that there is a method to get the grapes, why did you modify your original approach.

 

I didn't complain because you changed the approach. There is nothing wrong in changing the approach, disregarding if it does let you get the grapes or if it does not.

 

I "complained" because you blamed me that your original approach didn't work as you expected.

[atariksi]

Your worse than Rybags-- your complaining that now that there is a method to get the grapes, why did you modify your original approach.

 

I didn't complain because you changed the approach. There is nothing wrong in changing the approach, disregarding if it does let you get the grapes or if it does not.

 

I "complained" because you blamed me that your original approach didn't work as you expected.

 

All the approaches I mentioned work and as I expected; some are more complicated to implement than others. If you look at your posting #2531, you already claimed it was too complicated before I even gave a simplified algorithm for doing it. Even if you consider my earlier version complicated, it's STILL worth the effort to get those cycles since even an accelerator has to deal with HALT states.

 

By the way, you shouldn't be taking my comments about the fox/grapes to be negative-- the story is used as a means to encourage people not to give up. I am sure Rybags wouldn't give up so soon if we were talking about PM graphics or VScrolls.