Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store
StellaRT

StellaRT


Open Club  ·  76 members

StellaRT
IGNORED

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

Al_Nafuur

By Al_Nafuur
in Topics

 Share

Recommended Posts

Al_Nafuur River Patroller

+Al_Nafuur

Posted
Posted

I am currently working on a new project which is in an early WIP/PoC phase (I even haven't come up with a name for the project). Proposals for a project name can be found here

 

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.

 

For my testing I use a Raspberry Pi 3B+ connected to a breadboard, but something similar should be possible with the CPUs used in the Retron77 or the 2600+. I have developed a special driver for Stella to connect the cartridge to the CPUs I/O and emulate a 2600 directly using the cartridge without dumping it.

 

If the driver handles the communication and the timings with the cartridge exactly like a real 2600 would do, a 100% of all bankings (even future bankings) and cartridges will work on this setup.

 

@Thomas Jentzsch, @MarcoJ and @DirtyHairy have supported me with ideas to improve the driver. Currently we are at about 85% of the emulation speed.

 

Current status is:

  • Every std. banking cartridge seems to work (2K, 4K, F8, F6, F8SC tested)
  • Decathlon cartridge (FE banking) doesn't work (Stella debugger shows that the bank doesn't switch on a JSR)
  • PlusCart seems to be fully working (including exit and PlusROM functions. See compatibility list below)
  • GameLine cartridge shows briefly the intro message and then crashes or starts to puls dial. I think it might be an voltage issue here, because the Raspberry Pi shows a "Low Voltage" warning
  • SuperCharger doesn't work
  • I don't have a DPC+ or CDFJ cart to test.

 

Here is a compatibility list for all bankings tested mostly on the PlusCart, because I don't have the real cartridges:

https://forums.atariage.com/topic/354860-compatibility-list-for-all-bankings/

 

Software/hardware list for the breadboard setup:

  • Raspberry Pi 4
  • Pi OS with VS-Code and the SDL2 development libs
  • The latest code from the Stella GIT repository.
  • One 8-bit Logic Level Shifter (SN74LVC245AN) (~ $1.50)
  • 2600 cartridge port connector
  • A breadboard
  • Wires

 

How to connect the components:

https://forums.atariage.com/topic/354887-setting-up-the-unnamed-1970s-console/

 

Setting up the Raspberry Pi development environment:
https://forums.atariage.com/topic/354887-setting-up-the-unnamed-1970s-console/?do=findComment&comment=5317255

 

@ZeroPage Homebrew's reveal video on Youtube:

 

  • Like 37
Link to comment
Share on other sites
johnnywc River Patroller

+johnnywc

Posted
Posted
13 minutes ago, Al_Nafuur said:

I don't have a DPC+ or CDFJ cart to test. (I ordered Load Runner last year at AA but it still hasn't arrived yet!)

 

Great Job, this is very cool! :thumbsup:  If you're interested in trying any Champ Games for (DPC+, CDFJ, and CDFJ+), send me a PM and I'm sure we can work something out. :) 

  • Like 7
  • Thanks 1
Link to comment
Share on other sites
DirtyHairy Dragonstomper

DirtyHairy

Posted
Posted (edited)

Very cool, good job :thumbsup:. If you are talking directly to the cartridge, I would assume you have hard real time requirements. If you miss too much time due to scheduling, you won't be able to catch up within the bounds imposed by the cartridge bus. Emulators usually deal with this by emulating a large timeslice as fast as possible and sleeping after that, but this approach requires you to emulate continuously. Stella's threaded model that we introduced for stable audio doesn't necessarily help with that either. Refactoring Stella (specifically the main loop), manually pinning threads to different cores and playing with preemption and scheduling might help a lot (if you haven't already done that). Ping me if you'd like some assistance.

Edited by DirtyHairy
  • Like 5
Link to comment
Share on other sites
Al_Nafuur River Patroller

+Al_Nafuur

Posted
  • Author
Posted
2 minutes ago, DirtyHairy said:

Very cool, good job. If you are talking directly to the cartridge, I would assume you have hard real time requirements. If you miss too much time due to scheduling, you won't be able to catch up within the bounds imposed by the cartridge bus. Emulators usually deal with this by emulating a large timeslice as fast as possible and sleeping after that, but this approach requires you to emulate continuously. Stella's threaded model that we introduced for stable audio doesn't necessarily help with that either. Refactoring Stella, manually pinning threads to different cores and switching to a RT kernel might help a lot (if you haven't already done that). Ping me if you'd like some assistance.

A RT OS or kernel might help here, but I think it is not necessary. The 2600 is only using the address and data bus to communicate with the cartridge. Basically it was designed just for 4K of ROM. So we only have to assure that the changes on this I/O bus are "instantaneously" and not interrupted by the OS scheduler. And that we are waiting at least the amount of time (~770ns) with fetching the answer from the databus. If this waiting is interrupted for a few ms by the scheduler it shouldn't matter, because the cart should still "hold" the response on the bus.

  • Like 1
Link to comment
Share on other sites
Al_Nafuur River Patroller

+Al_Nafuur

Posted
  • Author
Posted
4 hours ago, splendidnut said:

If you're interfacing with the actual cartridge, then you're not emulating it.  :)

Yes Stella is only emulating the 2600 with its cartridge port and not the cartridge itself. I am not quite sure we have informed Stella's internal debugger about that.

 

4 hours ago, splendidnut said:

Anyways, Awesome job!

thanks

  • Like 1
Link to comment
Share on other sites
DirtyHairy Dragonstomper

DirtyHairy

Posted
Posted (edited)
32 minutes ago, Al_Nafuur said:

And that we are waiting at least the amount of time (~770ns) with fetching the answer from the databus.

You are the one doing the work, and you know better where your bottlenecks are, but I think this wait is an intrinsic problem. On linux, a scheduler quantum is about 100msec. If the scheduler preempts you and services another thread that's roughly the time you loose, which amounts to ~120000 6502 cycles (since each cycle is a bus access). In the best case, Stella can try to catch up by executing the missed cycles the next time it is scheduled, but that will not work reliably because of the limited speed the cartridge ROM can tolerate (the 770ns wait). It will only be able to execute some 1300000 cycles per second, which is just about 100000 cycles surplus per second on top of the 1200000 cycles that it has to do per second in order to achieve full speed.

 

Catching up a single quantum may already take about one second, which is too much to maintain the illusion of steady full speed. If you miss more quanta during that time, then the "backlog" of cycles will keep growing, and you won't even achieve full speed on average.

 

This is just an order-of-magnitude argument, the details depend on the scheduler, the other processes fighting for the same core, etc., but I think this issue must be addressed in order to get this approach working stable at full speed. In addition, Stella's current scheduling is not designed for this and likely will do a bad job.

Edited by DirtyHairy
  • Like 2
Link to comment
Share on other sites
Dionoid Stargunner

Dionoid

Posted
Posted (edited)

Wow, this is so cool!

I had a similar idea a few years ago (see link below) using an arduino, but the Stella devs convinced me the hardware wasn't going to be fast enough (which is true for an arduino).

I'm really happy that @Al_Nafuur is working on this PoC/WIP, and 85% speed is really impressive. What if you switch to the fastest Raspberry Pi? Would that help get that last 15% speed?

 

Edited by Dionoid
  • Like 2
Link to comment
Share on other sites
JetSetIlly Stargunner

JetSetIlly

Posted
Posted
5 hours ago, Al_Nafuur said:

I am currently working on a new project which is in an early WIP/PoC phase ( I even haven't come up with a name for the project)

Excellent work. I was thinking about something like this last week during all the talk of the limitations of cartridge dumpers. It'll be interesting to get Gopher2600 working in a similar manner.

 

Well done! I'm looking forward to seeing it in action. Meanwhile, if you need any help with anything I'm happy to help

  • Like 1
  • Thanks 1
Link to comment
Share on other sites
Al_Nafuur River Patroller

+Al_Nafuur

Posted
  • Author
Posted
2 hours ago, Dionoid said:

Wow, this is so cool!

I had a similar idea a few years ago (see link below) using an arduino, but the Stella devs convinced me the hardware wasn't going to be fast enough (which is true for an arduino).

I'm really happy that @Al_Nafuur is working on this PoC/WIP, and 85% speed is really impressive. What if you switch to the fastest Raspberry Pi? Would that help get that last 15% speed?

 

I am not sure if a RPi 4 would be faster with the current driver. I don't have one to test, so maybe someone can test it when I am ready with the source code and the installation guide.

 

I would prefer to get it working with the RPi 3, because it is cheaper than the 4.

 

As @DirtyHairy pointed out the (~770ns) wait on the bus is whats affecting the emulation speed the most. Most EPROMS and masked ROMs are responding (much) faster (down to 70ns). So we might reduce the time we wait before reading the data bus to "gain" emulation speed. But we would be out of spec with what the 2600 does and some cartridges (Multicarts?) that need the time to response wouldn't work anymore.

 

The current driver is even worse than the 770ns, because the hardware timer we use (seems to) have a resolution of 1000ns. So our waits are currently at an average of ~1500ns (if they are not interrupted by the OS scheduler)

  • Like 1
Link to comment
Share on other sites
Thomas Jentzsch Quadrunner

Thomas Jentzsch

Posted
Posted
41 minutes ago, Al_Nafuur said:

As @DirtyHairy pointed out the (~770ns) wait on the bus is whats affecting the emulation speed the most. Most EPROMS and masked ROMs are responding (much) faster (down to 70ns). So we might reduce the time we wait before reading the data bus to "gain" emulation speed. But we would be out of spec with what the 2600 does and some cartridges (Multicarts?) that need the time to response wouldn't work anymore.

Can't you start a timer before you access the bus? And before the next bus access wait for the timer to elapse? That would get you rid of the Stella code overhead.

 

And maybe with some initial tests, this timer could be automatically adjusted to ROM speed?

  • Like 1
Link to comment
Share on other sites
MarcoJ Dragonstomper

+MarcoJ

Posted
Posted

Do the results change if you use a traditional cart VS the PlusCart? The data load would be almost instantaneous on PlusCart, compared to a traditional EEPROM. Also, wait states could be sidestepped or lessened from getting data from the PlusCart instead of a traditional cart.

Link to comment
Share on other sites
Dionoid Stargunner

Dionoid

Posted
Posted
2 hours ago, Al_Nafuur said:

I am not sure if a RPi 4 would be faster with the current driver. I don't have one to test, so maybe someone can test it when I am ready with the source code and the installation guide.

 

I would prefer to get it working with the RPi 3, because it is cheaper than the 4.

Actually in the Netherlands it's the other way around: the RPi 4 (1GB model) costs € 44.95, while the RPi 3B+ costs € 49.95:

... assuming of course that the 1GB model is sufficient for your project.

Link to comment
Share on other sites
Al_Nafuur River Patroller

+Al_Nafuur

Posted
  • Author
Posted

Proposals for a project name:

  • Stellactic
  • Stellaxy
  • Stellaga
  • StellaR
  • NostagliaBox
  • StellaDream
  • StellaRetro
  • StellaSphear
  • StellaNova
  • Stellander
  • Stellacaster
  • StellaNeo
  • Fun Box
  • NotA2600Dumper
  • Stella+
  • Stellabox
  • StellaRT
  • Stellacharger
  • StellaRcharger
  • Very Cool System
  • VeryCoolSystem
Link to comment
Share on other sites
r_chase Dragonstomper

r_chase

Posted
Posted (edited)

When I first saw something about this on the Discord, I said that it would be something for the Raspberry Pi...and I was partially right. Admittedly, I said that it would be an OS, but this goes beyond what I had in mind. So...will this add-on be compatible with Atari 7800 carts as well?

Also, I think just "Stellabox" would work.

Edited by r_chase
Addendum for project name.
Link to comment
Share on other sites
 Share
Go to topic listing

  • Recently Browsing   0 members

    • No registered users viewing this page.
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2023 AtariAge

×
×
  • Create New...