Jump to content

Open Club  ·  76 members

StellaRT
IGNORED

Community-Built Unnamed 1970's Video Game Console-Compatible System (WIP)


Recommended Posts

11 hours ago, Al_Nafuur said:

The story behind this project is that I never liked the approach of the retron77. I always thought that it can be done better. When Atari announced the 2600+ with the same "wrong" approach I decided to test if my idea of doing a better device is feasible.

This is really cool and very exciting. I'm sure I'm stating the obvious, but assuming this is feasible, it'll be bigger than sliced bread and it will sell. Thanks for sharing your WIP with ZPH and the community. Also, thanks to all that have or may help contribute to this in any way. Very, very cool.🙂

  • Like 3
Just now, Karl G said:

Maybe add A26 to whatever name is chosen. This gives an idea as to what system is being emulated without infringing on trademarks. 

 

E.g. StellaR A26

NotA26Dumper

 

  • Like 2

Just a quick question...will the project use buildroot like this thing?
https://github.com/SvOlli/buildroot-stellabox

...or will it be baremetal?

The buildroot thing is why I proposed "Stellabox" anyway.

Edited by r_chase
Clarification
  • Like 2

For a model number, how about 2603.14?

 

One thing I'm curious about with these "Stella in a box" implementations - is it able to use the AtariVox/Savekey functionality built within Stella to save high scores for games that use it?  How about the Stella PlusROM support?  It would be pretty neat to be able to plug in PlusROM-friendly game cartridges into a console and have your high scores uploaded to the web server.

 

 

  • Like 2

Best news I've heard all week.

I've got some scrap Jr PCBs with the cart connectors, ports, switches, etc.

 

An overclocked Pi Zero 2 might do the trick, with an Arduino nano converting the joysticks ports to USB.

 

 

19 minutes ago, marauder666 said:

An overclocked Pi Zero 2 might do the trick, with an Arduino nano converting the joysticks ports to USB.

 

Does the Nano handle 2 controllers and bidirectional controls so the 4-port adapter works? If not, I'd use a 32U4 as OP is going for full compatibility.

16 minutes ago, bent_pin said:

Does the Nano handle 2 controllers and bidirectional controls so the 4-port adapter works? If not, I'd use a 32U4 as OP is going for full compatibility.

The nano software I've used only did inputs.

9 minutes ago, marauder666 said:

The nano software I've used only did inputs.

The 328 is more than capable of doing it all, but you'd have to write the USB stack for bidirectional comms or just connect it by SPI. I think using a 32U4 would be much faster to develop and require less debugging. Just two byte packets for port and data.

9 minutes ago, marauder666 said:

This is what I used for an adapter for the mister.

 

https://github.com/MickGyver/DaemonBite-Retro-Controllers-USB

 

It's a pro micro, not a nano.

 

Makes sense to me. @Al_Nafuur Feel free to call on me for any Arduino help, should you need it.

  • Like 1

Wow, I love this idea. @Al_Nafuur I guess you have a real challenge here with the more complicated bankswitching. These carts rely on exact cycle timing of all instructions of the 6502 and I am not sure how accurate stella emulates the core with regard to putting cycle exact data on the busses, including incorrect addresses that are corrected a cycle later :)
Or ram timing where you don't see the new data on the databus before 400us are over.
I would love to follow the driver development, especially how you solve driving these busses.

28 minutes ago, Kroko said:

Wow, I love this idea. @Al_Nafuur I guess you have a real challenge here with the more complicated bankswitching. These carts rely on exact cycle timing of all instructions of the 6502 and I am not sure how accurate stella emulates the core with regard to putting cycle exact data on the busses, including incorrect addresses that are corrected a cycle later :)

Do you mean indexed reads and writes, which have a dummy access to the non-indexed addresses? This is emulated.

28 minutes ago, Kroko said:

Or ram timing where you don't see the new data on the databus before 400us are over. I would love to follow the driver development, especially how you solve driving these busses.

Sounds like a challenge. :) 

>>Do you mean indexed reads and writes, which have a dummy access to the non-indexed addresses?

Not only indexed reads. All instructions that take longer than one cycle (like JSR, RTS etc.) have some exact sequence of how they put which data to the address and databus during the cycles they are executed. So you need to exactly put to the bus the same data that would be put to the bus in each single cycle of a multi cycle instruction. Because some cartridges monitor the sequence of what happens from cycle to cycle and rely on seeing on the bus exactly what the 6502 puts there in each cycle during a multi cycle instruction. I am not 100% sure, but some cartridges implement delays based on signal changes on the data or address bus, so you would need to do the data change at least roughly at the time this hardware expects the change. I feel this is all a fun challenge :)

5 minutes ago, Kroko said:

Not only indexed reads. All instructions that take longer than one cycle (like JSR, RTS etc.) have some exact sequence of how they put which data to the address and databus during the cycles they are executed. So you need to exactly put to the bus the same data that would be put to the bus in each single cycle of a multi cycle instruction. Because some cartridges monitor the sequence of what happens from cycle to cycle and rely on seeing on the bus exactly what the 6502 puts there in each cycle during a multi cycle instruction.

I think the core emulation does that:

https://github.com/stella-emu/stella/blob/master/src/emucore/M6502.m4

And generated from that:

https://github.com/stella-emu/stella/blob/master/src/emucore/M6502.ins

 

The resulting peeks and pokes seem to do exactly what a 650x does, no?

5 minutes ago, Kroko said:

I am not 100% sure, but some cartridges implement delays based on signal changes on the data or address bus, so you would need to do the data change at least roughly at the time this hardware expects the change. I feel this is all a fun challenge :)

Yes, though many things go way over my head. :) 

  • Like 1
3 minutes ago, Thomas Jentzsch said:

Holy smokes! I didn't realise Stella used m4. Not seen that since Sendmail was all the rage.

Edited by JetSetIlly
9 minutes ago, JetSetIlly said:

Holy smokes! I didn't realise Stella used m4. Not seen that since Sendmail was all the rage.

I guess it shows the age of Stella. And why should be want to change it?

1 minute ago, Thomas Jentzsch said:

I guess it shows the age of Stella. And why should be want to change it?

Indeed. You wouldn't want to change it. M4 is pretty good.

1 hour ago, Kroko said:

Wow, I love this idea. @Al_Nafuur

Thanks

1 hour ago, Kroko said:

I guess you have a real challenge here with the more complicated bankswitching. These carts rely on exact cycle timing of all instructions of the 6502 and I am not sure how accurate stella emulates the core with regard to putting cycle exact data on the busses, including incorrect addresses that are corrected a cycle later :)
Or ram timing where you don't see the new data on the databus before 400us are over.
I would love to follow the driver development, especially how you solve driving these busses.

Yes this is a challenge. @MarcoJ came up with the idea to include a small circuit that can be triggered to generate the ~770ns delay from setting the bus and reading the data.

 

Currently the SN74LVC245An logic level shifter adds ~10ns delay to the data bus this is not the original ~400ns of the 2600, but if some bankings really rely on it we might add a 390ns delay circuit to OE of the shifter. This would be triggered with/by the 770ns delay. 

I don't know how you feel about this, but if you'd be open to partial cart emulation, you can theoretically dump any and all ROM from the cart at boot, because ROM does not change.

 

But if you don't want to dump the cart, at least you could cache known ROM data if you knew it was ROM, and would not need to fetch from ROM every single cycle. That could provide the speed boost you need and allow for more time for when you really have to interact with the cart.

  • Recently Browsing   0 members

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