microprocessor on a 2600 cartridge?

[Curt Vendel]

Like I said in the PM to you the other day, I'll do anything I can to help out...

 

 

Curt

 

 

 

OKay, here is a little light reading on the Graduate computer keyboard add-on:

 

http://www.atarimuseum.com/archives/pdf/vi...esign_notes.pdf

 

This give a LOT of very useful information on how to enhance capabilities onto the VCS cartridge bus.

 

 

 

Curt

Thanks for posting! The 6502 data sheets are sorely lacking in timing waveforms, and this has answered many questions.

[supercat]

This give a LOT of very useful information on how to enhance capabilities onto the VCS cartridge bus.

 

It's interesting that they seem to have been analyzing write cycles in terms of finding the data-valid window "in advance". I wonder if any RAM cartridges for the 2600 latch the address bus and then hold the write enable until the address from the 2600 changes. My 4A50 cart managed to time the data-valid window very nicely, but it needed a crystal-controlled clock to do it. Using the address change to flag the end of a write cycle would have allowed for much looser timing.

[Curt Vendel]

Perhaps it more like a housekeeping setup, when you revue the hardware, you have essentially a standalone computer system there... so I would think all that they were doing was just addressing to the TIA and Riot for video, sound and IO control, the 2600 wasn't going to be doing much else, the computer was going to essentially be doing most of the real work at that point.

 

 

Curt

 

 

This give a LOT of very useful information on how to enhance capabilities onto the VCS cartridge bus.

 

It's interesting that they seem to have been analyzing write cycles in terms of finding the data-valid window "in advance". I wonder if any RAM cartridges for the 2600 latch the address bus and then hold the write enable until the address from the 2600 changes. My 4A50 cart managed to time the data-valid window very nicely, but it needed a crystal-controlled clock to do it. Using the address change to flag the end of a write cycle would have allowed for much looser timing.

[falcon_]

Hi folks!

 

Dang - I just started work on this exact project! THEN I came here, and find this thread....

heebeegeebeez.... hehehe But, the idea must be in the air...

 

I've picked out pretty much all the parts, and I'm gathering whatever it looks like I'll

need. I picked an ARM because it's simply and undeniably the best uC on the market IMHO!

I believe I have a handle on the theory of this lil beastie, and I think it

will work wonders. The ARM is **hundreds** of times faster than the vcs, so I

do think it will keep up np!

 

I'd like to bring it into a full product, with usable code development too...made up of

free tools and some custom parts and libraries for doing almost anything.

 

Thankyou Curt for providing that designnotes .pdf for checking timing, tho I'm not certain

I need it. The project is only going to be dealing with the cartridge port pins.. pretty basic.

 

 

I'm not trying to hijack this project/threat, but this is my idea also and I plan on working

towards my own plans. I would love a couple other smart folks to join and help, and any

support and encouragement from the group would be gold.

 

I don't know much about actually programming the 2600, but I know 6502 asm and

how pcb's are assembled. So I need a real good 2600 programmer who can think simultaneously

in 6502 asm, +AND+ 32bit C code - to help with making at least one Wow-Game on the beast.

 

I have plans of doing a lot more than whats been mentioned here so far. It'll be kewl, but

it may be a challenge to program as it is a bit of a mind-bender to think in two cpu's at once.

The venerable 2600 will be able to do things only joked about in the past.

 

First post!!

 

peace

falcon

[GroovyBee]

I don't know much about actually programming the 2600, but I know 6502 asm and

how pcb's are assembled. So I need a real good 2600 programmer who can think simultaneously

in 6502 asm, +AND+ 32bit C code - to help with making at least one Wow-Game on the beast.

IMHO "C" won't cut it for emulating a VCS ROM. Far too much overhead. You'll be in cycle timed assembler for the most part.

[falcon_]

I don't know much about actually programming the 2600, but I know 6502 asm and

how pcb's are assembled. So I need a real good 2600 programmer who can think simultaneously

in 6502 asm, +AND+ 32bit C code - to help with making at least one Wow-Game on the beast.

IMHO "C" won't cut it for emulating a VCS ROM. Far too much overhead. You'll be in cycle timed assembler for the most part.

 

Yes - the low level bits of talking with the VCS certainly will be asm.

 

Much of the rest of the system can be C (or another language potentially?)

for much of the library's and game code. Keep in mind, that the ARM is

a 32bit cpu, running MINIMUM *250* TIMES FASTER than the 2600!

It will be going FAASSST.

 

peace

falcon

[GroovyBee]

Yes - the low level bits of talking with the VCS certainly will be asm.

 

Much of the rest of the system can be C (or another language potentially?)

for much of the library's and game code. Keep in mind, that the ARM is

a 32bit cpu, running MINIMUM *250* TIMES FASTER than the 2600!

It will be going FAASSST.

If this is going in a cart, you'll be looking at a 60MHz to 80Mhz ARM chip to keep the cost as low as possible in my mind. At 60Mhz, you can execute 50 ARM instructions per 6502 clock cycle. A load, test and branch will take at least 7 cycles in an ideal ARM7 world (LDR, TST, BNE - taken). In the real world it'll take a few cycles longer if you have access to fast I/O. Where does this "250 x faster" come from? You have to feed the 6502 instructions all the time, theres no CPU halt on the cart connector, even if you feed it a NOP instruction that gets you a window of ARM execution time of 6.9ms before the 6502 has to branch back.

[+batari]

Yes - the low level bits of talking with the VCS certainly will be asm.

 

Much of the rest of the system can be C (or another language potentially?)

for much of the library's and game code. Keep in mind, that the ARM is

a 32bit cpu, running MINIMUM *250* TIMES FASTER than the 2600!

It will be going FAASSST.

If this is going in a cart, you'll be looking at a 60MHz to 80Mhz ARM chip to keep the cost as low as possible in my mind. At 60Mhz, you can execute 50 ARM instructions per 6502 clock cycle. A load, test and branch will take at least 7 cycles in an ideal ARM7 world (LDR, TST, BNE - taken). In the real world it'll take a few cycles longer if you have access to fast I/O. Where does this "250 x faster" come from? You have to feed the 6502 instructions all the time, theres no CPU halt on the cart connector, even if you feed it a NOP instruction that gets you a window of ARM execution time of 6.9ms before the 6502 has to branch back.

I'm guessing he's thinking of an ARM9 or ARM11. Sure, that could be done, but right now it would be a little expensive. Such a thing would probably be fast enough for C instead of asm, though.

 

The Harmony is running an ARM7 at 70 MHz. You get 58 cycles per 6507 cycle. Also, polling the bus takes longer than 7 cycles in the loop, as you must consider the setup time of the address bus and your count starts from the first cycle after the LDR. I don't recall the exact figures but I think that worst case it could be 20 cycles to be certain you have a valid address.

[GroovyBee]

I'm guessing he's thinking of an ARM9 or ARM11. Sure, that could be done, but right now it would be a little expensive. Such a thing would probably be fast enough for C instead of asm, though.

Agreed. Even then you have to get an ARM chip with fast I/O. Some of the high end ARMs I've worked with are not very good with interfacing to the real world using general purpose I/O. However, they do excel with their on board peripheral capability.

The Harmony is running an ARM7 at 70 MHz. You get 58 cycles per 6507 cycle. Also, polling the bus takes longer than 7 cycles in the loop, as you must consider the setup time of the address bus and your count starts from the first cycle after the LDR. I don't recall the exact figures but I think that worst case it could be 20 cycles to be certain you have a valid address.

I'd figured at least twice round the loop to make sure you weren't seeing false positives on the address bus. I was just trying to get the OP to realise that they need to do some investigation and research of their own.

[+batari]

I'd figured at least twice round the loop to make sure you weren't seeing false positives on the address bus. I was just trying to get the OP to realise that they need to do some investigation and research of their own.

I got a few similar comments when bB first came out, about how others thought of the basic idea first. I'm sure others thought of the microcontroller on a cart before I did as well (my first idea was in around 2004-2005) and on the [stella] list, the idea was discussed before that.

 

There is a big difference between thinking of something and actually doing it successfully, though. Best of luck to the OP... he's got his work cut out for him We've been working on Harmony for nearly a year and a half now.

[falcon_]

Hi guys

 

Yes, I believe the ARM7 will be able to do it. I've been looking into them

for a while now and they are very impressive. There seems to be some

doubt as to why the ARM would be excellent for such a project.

 

Concerning the speed...

 

The 2600 runs at 1.19 Mhz. The ARM runs at 72 Mhz. Ergo,

72 / 1.19 = 60.5 times faster than the 2600.

The 2600 is 8bit data, and the ARM is 32bit data.

32 / 8 = 4 times 60.5 = 242 times the speed of the 2600.

 

And of course there are other ways the ARM is faster as well, so hence,

why I stated the ARM7 is minimum 250 times faster (within the ARM).

This is just a computational comparison however. The real issue is how

much time is taken to maintenance the Atari bus. IMHO, it can be shorter

than 1/3 the 6507 cycle -- but you folks are the experts on the 2600.

I've already done several days worth of investigating, and that's also

why I'm Here, so I can chat and work it out with and raise interest

with all you wonderful folks.

 

GroovyBee and bAtari, both you guys already are knowledgeable enough to

quote relative instruction timings to me which is perfect. So then don't you think

that ~10-20% (as you yourselves cited to me) of the ARM cycles is acceptable?

The remaining 80% (or even 50% whatever it might be) is going to be that

250 times faster in computing on the ARM side. No, I don't think an ARM9 or 11

is needed at all. But I'm checking through the user manual in detail to see

that everything I have in mind is still on the table.

 

Which ARM are you using for your Harmony project? Where do I read

more about it? I'm not trying to walk on your project of course, but

my project will easily do multicarts as well, any format. Just program

in the banking methods. Because it emulates a ROM 'dynamically'.

So it can change any byte in that so-called "ROM" at any time for

any reason you wish! Can you see the power of the idea yet?

 

peace

falcon

[+batari]

Which ARM are you using for your Harmony project? Where do I read

more about it? I'm not trying to walk on your project of course, but

my project will easily do multicarts as well, any format. Just program

in the banking methods. Because it emulates a ROM 'dynamically'.

So it can change any byte in that so-called "ROM" at any time for

any reason you wish! Can you see the power of the idea yet?

 

peace

falcon

Of course we see the power of your idea, because we are already doing all of the things you describe

 

There are at least two threads about Harmony (though one did start out as a thread about the Chimera project, which is now dead.)

 

http://www.atariage.com/forums/index.php?showtopic=144469

http://www.atariage.com/forums/index.php?s...15077&st=26

[GroovyBee]

The 2600 runs at 1.19 Mhz. The ARM runs at 72 Mhz. Ergo,

72 / 1.19 = 60.5 times faster than the 2600.

The 2600 is 8bit data, and the ARM is 32bit data.

32 / 8 = 4 times 60.5 = 242 times the speed of the 2600.

Did you have a previous job in marketing? Bus width has nothing to do with it in my opinion, the cycle(s) per instruction is the most important.

And of course there are other ways the ARM is faster as well, so hence,

why I stated the ARM7 is minimum 250 times faster (within the ARM).

This is just a computational comparison however. The real issue is how

much time is taken to maintenance the Atari bus. IMHO, it can be shorter

than 1/3 the 6507 cycle -- but you folks are the experts on the 2600.

I've already done several days worth of investigating, and that's also

why I'm Here, so I can chat and work it out with and raise interest

with all you wonderful folks.

I suggest you look at the relationship between PHI2, R/W# and the address and data bus on a 6502. Funnily enough its not 1/3 of a cycle. Also bear in mind you don't get access to PHI2 or R/W# on a 2600 cart interface.

GroovyBee and bAtari, both you guys already are knowledgeable enough to

quote relative instruction timings to me which is perfect. So then don't you think

that ~10-20% (as you yourselves cited to me) of the ARM cycles is acceptable?

20 cycles on Harmony is 34% of the total time available. That does not include fetching data to put on the bus (inside the ARM) or turning the data bus around if you are emulating a superchip cart or any bankswitching code. I suggest that you look at MAM on the NXP range of ARM7 microcontroller.

The remaining 80% (or even 50% whatever it might be) is going to be that

250 times faster in computing on the ARM side. No, I don't think an ARM9 or 11

is needed at all.

Marketing speak again

But I'm checking through the user manual in detail to see

that everything I have in mind is still on the table.

I think you need to read much, much more and have a play on an ARM devkit.

So it can change any byte in that so-called "ROM" at any time for

any reason you wish! Can you see the power of the idea yet?

Have fun!

[+batari]

The 2600 runs at 1.19 Mhz. The ARM runs at 72 Mhz. Ergo,

72 / 1.19 = 60.5 times faster than the 2600.

The 2600 is 8bit data, and the ARM is 32bit data.

32 / 8 = 4 times 60.5 = 242 times the speed of the 2600.

Did you have a previous job in marketing? Bus width has nothing to do with it in my opinion, the cycle(s) per instruction is the most important.

True, especially since with the 2600, you often must access a byte or a halfword at a time, so bus width doesn't always help.

 

And of course there are other ways the ARM is faster as well, so hence,

why I stated the ARM7 is minimum 250 times faster (within the ARM).

This is just a computational comparison however. The real issue is how

much time is taken to maintenance the Atari bus. IMHO, it can be shorter

than 1/3 the 6507 cycle -- but you folks are the experts on the 2600.

I've already done several days worth of investigating, and that's also

why I'm Here, so I can chat and work it out with and raise interest

with all you wonderful folks.

I suggest you look at the relationship between PHI2, R/W# and the address and data bus on a 6502. Funnily enough its not 1/3 of a cycle. Also bear in mind you don't get access to PHI2 or R/W# on a 2600 cart interface.

Yes, and this has been the chagrin of hardware designers ever since

 

1/3 of a cycle is too optimistic. Once you have a valid address, you need to decode the address into a physical location on flash/SRAM (this includes bankswitching), read the flash, set output mode, put the byte on the bus.

 

My best estimate was that you have about 2/3 of the cycle to get the byte on the bus. After getting a valid address, reading flash can take 7 cycles, as you must consider worst case (non-sequential access of a flash block not latched.) Output mode is a write which will stall the pipeline. Storing the byte on the bus also creates a stall whose length depends on the speed of the bus. The device I am using supposedly takes 4 cycles for this write, which is faster than many other devices.

 

You must consider worst-case for everything, and while it may seem unlikely for all timings to hit the worst case, consider that even one time in a million 6507 cycles would crash your game in a second.

 

For writes, since there's no phi2, you need to precisely time the read of the data bus (you have a window of about 100 ns, IIRC.) Also, you need to consider that some write instructions spend two cycles at the same location and the write occurs on the second cycle. The first cycle is a read, but since there is no R/W line, you can't tell the difference.

[falcon_]

The 2600 runs at 1.19 Mhz. The ARM runs at 72 Mhz. Ergo,

72 / 1.19 = 60.5 times faster than the 2600.

The 2600 is 8bit data, and the ARM is 32bit data.

32 / 8 = 4 times 60.5 = 242 times the speed of the 2600.

Did you have a previous job in marketing? Bus width has nothing to do with it in my opinion, the cycle(s) per instruction is the most important.

True, especially since with the 2600, you often must access a byte or a halfword at a time, so bus width doesn't always help.

 

And of course there are other ways the ARM is faster as well, so hence,

why I stated the ARM7 is minimum 250 times faster (within the ARM).

This is just a computational comparison however. The real issue is how

much time is taken to maintenance the Atari bus. IMHO, it can be shorter

than 1/3 the 6507 cycle -- but you folks are the experts on the 2600.

I've already done several days worth of investigating, and that's also

why I'm Here, so I can chat and work it out with and raise interest

with all you wonderful folks.

I suggest you look at the relationship between PHI2, R/W# and the address and data bus on a 6502. Funnily enough its not 1/3 of a cycle. Also bear in mind you don't get access to PHI2 or R/W# on a 2600 cart interface.

Yes, and this has been the chagrin of hardware designers ever since

 

1/3 of a cycle is too optimistic. Once you have a valid address, you need to decode the address into a physical location on flash/SRAM (this includes bankswitching), read the flash, set output mode, put the byte on the bus.

 

My best estimate was that you have about 2/3 of the cycle to get the byte on the bus. After getting a valid address, reading flash can take 7 cycles, as you must consider worst case (non-sequential access of a flash block not latched.) Output mode is a write which will stall the pipeline. Storing the byte on the bus also creates a stall whose length depends on the speed of the bus. The device I am using supposedly takes 4 cycles for this write, which is faster than many other devices.

 

You must consider worst-case for everything, and while it may seem unlikely for all timings to hit the worst case, consider that even one time in a million 6507 cycles would crash your game in a second.

 

For writes, since there's no phi2, you need to precisely time the read of the data bus (you have a window of about 100 ns, IIRC.) Also, you need to consider that some write instructions spend two cycles at the same location and the write occurs on the second cycle. The first cycle is a read, but since there is no R/W line, you can't tell the difference.

 

Hi again!

 

Well, I've done some looking into the timing aspects more and Groovy and you are totally right - The timing of the ARM's

pipeline will fail too much. Thank you guys for saving me a headache! I don't know when I would've found that issue out.

 

I imagine that it should be no problem if the program was running from the ARM's SRAM, however? What if the entire

relevant program was copied out of Flash (in the arm, upon boot) and put in SRAM and run from there. That would remove

the massive penalty of refilling the cache, I mean pipeline? No?

 

Alternately, I am seriously looking at the AVR's as a better choice. They are about the same price, but looks to have way

better responsiveness than the ARM's. Especially the AVR32 UC3B chip. Their Flash access time seems to be 30Mhz,

no extra clocks and full cpu speed is 1 wait. Atmel also claim their instructions are 20-30% more compact than ARMthumb2!

Plus Atmel gives away more development s.w. too, ya gotta love that.

 

peace

falcon

[GroovyBee]

Well, I've done some looking into the timing aspects more and Groovy and you are totally right - The timing of the ARM's

pipeline will fail too much. Thank you guys for saving me a headache! I don't know when I would've found that issue out.

At the start is always good . I don't think the pipeline is a problem.

I imagine that it should be no problem if the program was running from the ARM's SRAM, however? What if the entire

relevant program was copied out of Flash (in the arm, upon boot) and put in SRAM and run from there. That would remove

the massive penalty of refilling the cache, I mean pipeline? No?

There is no I-Cache or D-Cache on the NXP range of ARM7 micros. There is the ARM7 3 stage pipeline and MAM. I suggest you look at how the Memory Acceleration Module (MAM) operates. The internal RAM on those devices can be accessed in 1 cycle.

Alternately, I am seriously looking at the AVR's as a better choice. They are about the same price, but looks to have way

better responsiveness than the ARM's. Especially the AVR32 UC3B chip. Their Flash access time seems to be 30Mhz,

no extra clocks and full cpu speed is 1 wait. Atmel also claim their instructions are 20-30% more compact than ARMthumb2!

IMHO the only good reasons to use THUMB on the NXP range would be to double the effective size of MAM in intensive operations or to reduce application code size.

Plus Atmel gives away more development s.w. too, ya gotta love that.

You don't get any more free (as in beer) than GCC for ARM. Because this kind of project will mainly be done in assembler it doesn't really matter how inefficient the C-compiler side of it is. I've used GCC on ARM for over 14 years now. I've also used a variety of commercial packages too.

[+batari]

Well, I've done some looking into the timing aspects more and Groovy and you are totally right - The timing of the ARM's

pipeline will fail too much. Thank you guys for saving me a headache! I don't know when I would've found that issue out.

 

I imagine that it should be no problem if the program was running from the ARM's SRAM, however? What if the entire

relevant program was copied out of Flash (in the arm, upon boot) and put in SRAM and run from there. That would remove

the massive penalty of refilling the cache, I mean pipeline? No?

 

Alternately, I am seriously looking at the AVR's as a better choice. They are about the same price, but looks to have way

better responsiveness than the ARM's. Especially the AVR32 UC3B chip. Their Flash access time seems to be 30Mhz,

no extra clocks and full cpu speed is 1 wait. Atmel also claim their instructions are 20-30% more compact than ARMthumb2!

Plus Atmel gives away more development s.w. too, ya gotta love that.

 

peace

falcon

The ARM's pipeline is totally deterministic - it can be hard to count cycles, but it's possible. The flash timing in NXP devices depends on the MAM (as mentioned by GroovyBee) and while it does work somewhat like a cache, it doesn't require a huge penalty to fill, per se, just 7 cycles per access unless/until data is latched. If you require constant timing, you can disable the MAM and it will be 7 cycles every access. The problem with constant cycles is it wouldn't do you much good without a crystal that was an integer multiple of the 2600's clock, and while that is possible (for NTSC consoles at least), it will not allow for the full clock speed of the CPU (unless overclocked, but that's not a good idea.) I decided on a crystal that would allow the full clock speed and used a polling method. I should also mention that an interrupt method *might* work under certain conditions. Supposedly a fast interrupt can take fully half the 6507 cycle time to service, but this is the worst case and some of this latency can be avoided if you are certain what sort of code your compiler will produce (much of the latency stems from the fact that the current instruction must complete, so avoid LDM instructions) or code in pure assembly

 

Also, the flash is fast enough to deliver one byte per 2600 cycle along with the other work that needs to be done, so in general, the 2600 binary does not need to be copied to RAM. It's not fast enough, except for straight 4k schemes (i.e. no bankswitching) to run code from flash, however.

 

It's true that ARM isn't in the business of giving away their software, but we aren't using it - we are solely using freeware tools.

[supercat]

For writes, since there's no phi2, you need to precisely time the read of the data bus (you have a window of about 100 ns, IIRC.)

 

A nicer way of handling writes, which I believe is used in some of the Harmony schemes, is to repeatedly sample the data bus until the address bus changes, and then use the second-to-last value that was read before the change (if the address bus changes before two samples are taken, go with the last one and hope for the best). Note that (1) if writes don't cross page boundaries, the first cycle following the address change will always be an instruction fetch, so it may not be necessary to perform all of the usual bank-switching logic; (2) if the 'write' zone spans multiple pages, and the 'changed' memory address is within the zone (read it twice to make sure), the cart could ignore the first address and use the second. That would allow addresses that span page boundaries to work "normally".

[+batari]

For writes, since there's no phi2, you need to precisely time the read of the data bus (you have a window of about 100 ns, IIRC.)

 

A nicer way of handling writes, which I believe is used in some of the Harmony schemes, is to repeatedly sample the data bus until the address bus changes, and then use the second-to-last value that was read before the change (if the address bus changes before two samples are taken, go with the last one and hope for the best). Note that (1) if writes don't cross page boundaries, the first cycle following the address change will always be an instruction fetch, so it may not be necessary to perform all of the usual bank-switching logic; (2) if the 'write' zone spans multiple pages, and the 'changed' memory address is within the zone (read it twice to make sure), the cart could ignore the first address and use the second. That would allow addresses that span page boundaries to work "normally".

It is easier to time the window backward from

an address change, but you still need to hit the window. It works on Harmony because the timing of instructions works out conveniently. As for RAM schemes that are larger than a page and thus may be susceptible from page-wrap issues, the second address may be used as you say, but doing so is simpler than you imply - instead of timing backward from an address change, time backward from an exit from the "write" addresses and there should be no need to read of twice that I can ascertain.

Edited June 2, 2009 by batari

[falcon_]

Hi guys (batari, groovy, others)

 

Thought I would just post here again to show I haven't vanished. I still am slowly working

towards my own project ideas. I haven't been able to do much yet, as I have some

other big concerns I'm trying to take care of, and then hopefully I will have some extra

time to work things out.

 

I'm not quite following what you guys are talking about with reading the address bus till

it changes, then use the value previous.. that doesn't make any sense to me yet.

 

Also, not to say I know so much, but it sounds to me that just maybe you don't

follow some of my ideas regarding my project, and it's possibilities. I literally don't

know if my idea(s) will work or not, I really need to experiment myself and gain

experience, I just think I see some neat potential there. I really want to find out.

 

So I hope to start getting the experience asap, and see what is possible.

Hopefully I can come here one day this summer and show a demo of some sort!

BTW, I have a few ideas I have not mentioned here, just yet.

 

peace

falcon

Edited June 16, 2009 by falcon_

[+batari]

Hi guys (batari, groovy, others)

 

Thought I would just post here again to show I haven't vanished. I still am slowly working

towards my own project ideas. I haven't been able to do much yet, as I have some

other big concerns I'm trying to take care of, and then hopefully I will have some extra

time to work things out.

 

I'm not quite following what you guys are talking about with reading the address bus till

it changes, then use the value previous.. that doesn't make any sense to me yet.

This is only needed for RAM writes (i.e. when the 6507 attempts to write to RAM located on the microcontroller.) The data is only valid for a brief period in the middle of the cycle, and you don't have access to the control signals normally used to latch the data, so you need to precisely time it.

Also, not to say I know so much, but it sounds to me that just maybe you don't

follow some of my ideas regarding my project, and it's possibilities. I literally don't

know if my idea(s) will work or not, I really need to experiment myself and gain

experience, I just think I see some neat potential there. I really want to find out.

We've already done pretty much everything you mentioned, and can say that what you have posted is indeed possible. What is it that we aren't following?

 

As for experience, I suggest you study a bit about how to program the 2600 - at least enough to know its limitations. There are some things the 2600 will never do no matter what hardware you throw at it.

So I hope to start getting the experience asap, and see what is possible.

Hopefully I can come here one day this summer and show a demo of some sort!

Good luck!

 

If you have any more questions, let me know.

[+grafixbmp]

ever thought about usung a dedicated chip for the bus. that way it can handle the I/O throughput probably more efficiently and more uniformly. It could be time synced to the 6502 speed (a multiple of) and supply what the ARM (or whatever microcontroler is used) needs as far as reliable comunication. As long as it's responsiveness is fast enough to compensate for having it in the first place instead of just using the microcontroler alone.

[GroovyBee]

If you are going for the lowest cost solution its not cheap to add a PLD/FPGA into the mix. If the ARM uC has enough processing power free to do the job you might as well let it.

[+grafixbmp]

I don't know about others but I am the kind of person who wouldn't mind paying a bit more if ease of use and reliability are better. Also any extra strain on the ARM that is eliminated could give just a bit more processing time and every little bit more helps, no mater the amount, for anyone dealing with the 2600 I just felt that a more uniform way of dealing with a bus interface would be a good way of standardization for this concept.

[+batari]

I don't know about others but I am the kind of person who wouldn't mind paying a bit more if ease of use and reliability are better. Also any extra strain on the ARM that is eliminated could give just a bit more processing time and every little bit more helps, no mater the amount, for anyone dealing with the 2600 I just felt that a more uniform way of dealing with a bus interface would be a good way of standardization for this concept.

If you want to create your own board with bloated hardware and charge a premium for it, go ahead.

 

IMO, there is beauty in simplicity, just like the 2600. The standalone Harmony is about as simple as it gets, but it still gives you lots of power at a price competitive with an ordinary EPROM cart. No other modern RAM cart has ever done that.

 

Maybe the programming model is a little more difficult, but that's only if one wishes to create new bankswitching schemes for it. If you want to add your own user C code to existing bankswitching to enhance a game, stubs are going to be added to the bankswitch schemes to allow that. That will make possible things like large-scale memory manipulation that the 6507 wouldn't be able to manage between frames.