RetroN 77

[mr_me]

Did you at least read Spiceware's reply? The code he posted is 6502 code executed by the cpu in the Atari. Some of the constants in that code are actually datastreams provided by the arm cpu on the cartridge (that means, the arm change those values on-the-fly).

 

Also what you mean with "main program"? In the case of the 2600 many would agree that the kernel (the code actually drawing the screen) is the main program, and that's because of the design of the TIA that needs to be fed with data in real time as the image is being drawn ("racing the beam").

 

The code posted by spiceware draws (a portion of) the screen and it's executed by the 6502 AND the ARM, working together in sync.

 

 

For the record, the arm has no access to the TIA (the display processor), nor to the I/O of the console. You're right that it takes power from the console, tought.

 

 

 

It's not that the Retron77 cannot play those games because they're not "native" Atari games, but because the Retron77 is not a "native" Atari hardware!

 

Those games run fine on real hardware. And on Stella (that is, unless you use a 5 years old version ), since it is modeled after the real hardware. It's not a question of using "new" cartridge technology either. Some "old" cartridge technologies like a Supercharger or a Compumate don't run on the r77 and not because of the presence of a cpu on the cartridge (none of those has a CPU, btw). The reason is that the Retron doesn't really "play" cartridges, it just gives the illusion of doing so by dumping them and then feeding the rom to Stella. The "trick" works most of the times, but there are exceptions. It's a trick, after all.

Yes, the code that Spiceware posted is Atari 2600 programming (the kernel) and is what makes the 2600 the display processor or gpu to the arm cpu. The game logic (the main program) is in a different machine language not recognised by the 2600. In fact those instructions are processed by the arm and never have to leave the cartridge. Display data processed by the arm cpu for the 2600 goes through the cartridge pins. And that's what makes it a problem for the retron77. How would you get at the game program. It's not a problem for software emulation in general because you can emulate different cpus, including arm, as long as the rom image is provided. It's not a problem for fpga emulation because the cartridge's arm cpu is active like a real 2600, the fpga wouldn't even emulate arm.

 

It should be possible to add support for the Supercharger, and other bankswitching schemes to the retron77. They're designed to have their game code pass through the cartridge pins.

Edited July 20, 2018 by mr_me

[Keatah]

Pure software emulators are not supposed to be reading cartridge pins from one-time dumps which are incomplete because of lack of proper heuristics in the dumper itself.

 

And a dumper has to be used because Stella is not architected to read pins and data from a cartridge in real-time. Never has been, and IIRC, never will be.

 

 

It should be possible to add support for the Supercharger, and other bankswitching schemes to the retron77. They're designed to have their game code pass through the cartridge pins.

 

If you smarten up the dumper routine - so that it can create a rom suitable for Stella. Who is going to do that?

Edited July 20, 2018 by Keatah

[+stephena]

And a dumper has to be used because Stella is not architected to read pins and data from a cartridge in real-time. Never has been, and IIRC, never will be.

 

Never is a long time. And Stella is abstracted well enough that this could potentially be done. But I doubt this hardware is fast enough for it. Actually, I doubt mainstream hardware is fast enough for it. That's getting into the same territory as gate-level emulation, and the huge resources that such an approach requires.

[Keatah]

Can't some of it be abstracted away? Or does it have to go all the way and just simply be a rom like we're doing now..?

[+stephena]

I won't get too technical; this is not the place or thread for it. But essentially what the emulator boils down to is a series of peeks and pokes to various devices. Right now, those peeks and pokes access an array that is filled with the ROM data. It could just as well talk directly to the hardware. What would be needed is a way of making sure that the timing works out (ie, a read/write responds fast enough that the game doesn't notice). And on a general-purpose OS, that the OS doesn't sometimes decide to interrupt the app and cause slowdowns.

 

Essentially what would be needed is a real-time OS with the emulator being the only thing running on it. Probably won't happen, but it's technically possible.

[alex_79]

Yes, the code that Spiceware posted is Atari 2600 programming (the kernel) and is what makes the 2600 the display processor or gpu to the arm cpu. The game logic (the main program) is in a different machine language not recognised by the 2600.

Considering the game logic as "main program" (especially in the case of the 2600) is a matter of opinion. I don't concur with that opinion.

 

In fact those instructions are processed by the arm and never have to leave the cartridge. [...] And that's what makes it a problem for the retron77. How would you get at the game program.

What makes it a problem is that the Retron is not an Atari console, but a computer running an emulator + a cart dumper.

A cart dumper doesn't replicate the function of the cartridge port on real hardware. A real console doesn't "dump" the games.

(BTW, The Melody boards are programmed through the connector by a dedicated programmer. I don't know if it can also read the data back from the board, but in that case it could be possible to design a cartridge dumper that will read those games too)

 

It should be possible to add support for the Supercharger, and other bankswitching schemes to the retron77. They're designed to have their game code pass through the cartridge pins.

You can't "dump" a supercharger game like you do with rom based cartridges (you will only get the bios in that way). You have to access it in real time to load the game from tape, or at least read the input from the audio interface (again, in real time) emulating the rest of the device.

[+SpiceWare]

Considering the game logic as "main program" (especially in the case of the 2600) is a matter of opinion. I don't concur with that opinion.

 

 

Definitely an interesting point. Out of 262 scanlines of processing time for NTSC, typically only about 25% of them are used for game logic as the other 75% must draw the screen.

[mr_me]

If the dumper software tells the supercharger bios to load the game code to ram, why can't it be dumped from ram. Sounds like it might be possible to support dumping an arm cartridge. I realize all this is a lot of work but it seems possible. It's much easier to just use rom images that are already dumped.

 

 

Definitely an interesting point. Out of 262 scanlines of processing time for NTSC, typically only about 25% of them are used for game logic as the other 75% must draw the screen.

Don't forget the processing the arm cpu does. The Atari 2600 is unique as a computer; it spends most of it's time drawing the display. Edited July 20, 2018 by mr_me

[alex_79]

To add to that, this is what the official "Stella Programmer's Guide" says:

The portion of the program that constructs this TV picture is refered to as the "Kernel", as it is the essence or kernal of the game.

[alex_79]

If the dumper software tells the supercharger bios to load the game code to ram, why can't it be dumped from ram.

Because the Supercharger doesn't have any CPU in it. It's just rom (the bios), ram, the audio interface and some logic to hadle bankswitching and ram writes. The 2600 does the work to poll the audio interface, decode the data from the tape and store it to the SC ram.

Edited July 20, 2018 by alex_79

[+SpiceWare]

Don't forget the processing the arm cpu does.

 

 

I'm not - just like the 6502, the ARM's can only process game logic during that 25% time period. And it's actually less than because it takes time (about 2 scanlines worth, 1 in Vertical Blank, the other in OverScan) to call ARM functions. That time's spent by the 6507 passing info to the ARM, things like which function the 6507 wants the ARM to run, console switch readings, controller readings, etc.

[RugglesTx]

The problem for me is my general lack of interest in these novelty items that are cheap inferior versions of the original based on what seems to be the retail paradigm that cheap inferior junk is more profitable than a console that is actually superior to the original VCS. I hope that the $200 Collectorvision ColecoVision 2 console will be everything that is promised and then will sell well to inspire someone to build an equivalent $200 VCS console that has a fully compatible 2600 cart slot, sd compatibility with all 8bit Atari systems and keyboard port. It would also need some type of controller port system so you could use a 2600/7800 controller for the 5200 games or some solution I cant quite envision. In 2018, something like this, superior but faithful to the original, would be the only option I could see as a worthy modern 2600 replacement. Otherwise, just stick with the original rather than downgrade. SD Lynx and possibly Jag compatibility would be a bonus.

I paid $200 ish for a RetroUSB AVS this year. Plays all NES and Famicom games via hardware not software emulation for lack of a better term. Not had a issue with any of the carts Ive tried from both systems. Very very well built machine.

 

Id pay the same for a nice HDMI Atari cart taking machine! But yeah they could add a 2600/7800 cart port and a Jag or 5200 port if not all three.

 

Sign me up.

[mr_me]

 

 

I'm not - just like the 6502, the ARM's can only process game logic during that 25% time period. And it's actually less than because it takes time (about 2 scanlines worth, 1 in Vertical Blank, the other in OverScan) to call ARM functions. That time's spent by the 6507 passing info to the ARM, things like which function the 6507 wants the ARM to run, console switch readings, controller readings, etc.

I appreciate all that. I was just going by what I read here. http://atariage.com/forums/topic/272632-super-cobra-arcade/?p=3904060

It sounds like the 70Mhz arm is doing a lot of the game logic among other things. You can get a lot more done in the same amount of time if you're moving thousands of times faster.

[Keatah]

No one complains that NES and SNES emulators cover all sorts of add-on chips and processors and stuff those systems use in their cartridges. Nobody argues that a Super-FX game shouldn't be called a SNES game.

[SIO2]

No one complains that NES and SNES emulators cover all sorts of add-on chips and processors and stuff those systems use in their cartridges. Nobody argues that a Super-FX game shouldn't be called a SNES game.

That is because nobody cares about Nintendo like we care about Atari.

[gorfcadet]

Did anyone put together stephena's updated Stella with Hyperkin's menu update? I don't currently have the set up to put it together. Is there a way to do this on a Mac?

[SIO2]

Did anyone put together stephena's updated Stella with Hyperkin's menu update? I don't currently have the set up to put it together. Is there a way to do this on a Mac?

Last post on page 84 post #2100. You have to look for it. I missed it at first myself. So, not sure about the Mac but if you have an image writer then I think you can.

 

Stephena said, "Very latest firmware image (includes latest Hyperkin changes and latest Stella changes) -> AKA, the most recent version of everything: sdcard.img.zip 8.12MB 18 downloads"

 

I noticed the license on that image does not indicate the 3.9.3 though.

Edited July 21, 2018 by SIO2

[Sneakyturtleegg]

That is because nobody cares about Nintendo like we care about Atari.

Seriously?

[+stephena]

I noticed the license on that image does not indicate the 3.9.3 though.

 

Seems I forgot to update that file. I won't do another release for it though, as it's only cosmetic. If you want to see for sure if you have 3.9.3, run 'Kool-Aid Man'. It will be immediately obvious if you're running the latest 3.x version of Stella or not.

[gorfcadet]

Yeah, I actually made the image and put it on an sd card, but the roms are still capped or I don't know how to get to the other roms.

[SIO2]

Just keep moving the joystick down. If you have lots of roms then it will gradually move through them. The roms are not included in the image. You have to put them in your games folder.

 

I can verify the image works, no rom limit (or at least very much higher) and plays Kool-aid man.

 

Watch the cart titles. The menu does not appear to scroll because all the freaking icons are the same. But if you scroll down through the field you should see the names changing.

Edited July 21, 2018 by SIO2

[gorfcadet]

Just keep moving the joystick down. If you have lots of roms then it will gradually move through them. The roms are not included in the image. You have to put them in your games folder.

 

I can verify the image works, no rom limit (or at least very much higher) and plays Kool-aid man.

 

Watch the cart titles. The menu does not appear to scroll because all the freaking icons are the same. But if you scroll down through the field you should see the names changing.

Thank you! That is a weird way to cycle games. I hope we can add thumbnails or box art someday.

[Mr SQL]

http://relationalframework.com/9LINEBLITZII.binhttp://relationalframework.com/WARPDRIVE_AFP.binhttp://relationalframework.com/WARPDRIVE_AFP.bin

I appreciate all that. I was just going by what I read here. http://atariage.com/forums/topic/272632-super-cobra-arcade/?p=3904060

It sounds like the 70Mhz arm is doing a lot of the game logic among other things. You can get a lot more done in the same amount of time if you're moving thousands of times faster.

 

All excellent points and very good question raised as to weather the gameloop, graphics and sound processing or the kernel constitue the main program.

I'll use the gameloop for WARPDRIVE one of the games bundled with the Retron77 as an example since it's only 9 lines and looks like what we conceptualize as "the program" for being written in a high level language - BASIC:

0 data city 1,4,2,5,3,2,3,1,4,1,1,1,5,2,2,3,1,4,1,4,3,1,4,4,1,1,2,2,3,1,3,4,5,4,4,3,4,5,1,2,4,1,5,2,2,3,1,3,1,1,4,1
1 if g=0 then for j=0 to 7:player1(j)=189:player0(j)=pl(j):next j:BYTErowoffset=120:COLUPF=$42:COLUP0=$b4 else goto 3
2 for j=20 to 71:k=j-20:k=city(k)+14:for i=k to 19:vwpixel(j,i,on):next i,j:player0y=88:player0x=94:COLUP1=$74:y=20:g=1
3 COLUBK=0:AUDV0=0:scrollvirtualworldtoggle=1:BITIndex=BITIndex+1:missile0x=missile0x+2:data pl 0,224,127,231,252,192
4 if joy0fire=1 and y>=20 then AUDF0=6:AUDC0=8:AUDV0=15:x=BITIndex+11:y=11:i=88-player0y:i=i/10:y=y+i:data P 128,0
5 if y<21 then vwpixel(x,y,bindplayer1):j=y-10:y=y+1:COLUP1=M(j):data M $64,$54,$b4,$a4,$32,$44,$c4,$94,$f4,$54,$24,$42
6 if y<=19 and vwpixel(x,y,poll)>0 then vwpixel(x,y,flip):player1x=0:player1y=0:AUDC0=y:y=20:AUDF0=4:AUDV0=15
rem player flies lower each pass over the smoothly scrolling city
7 if BITIndex>71 then BITIndex=0:player0y=player0y-2 else missile1x=missile1x+1:missile1y=missile1y+3
8 if CXP0FB>126 then CXCLR=0:g=0:for i=0 to 255:AUDF0=i:AUDV0=i:COLUBK=$34:next i else missile0y=missile0y+2

(play WARPDRIVE online or download the ROM if you don't have a Retron77)

BASIC makes it easier for more people to conceptualize a game - c gameloops like John described are pretty much the same though Assembly gameloops are hieroglyphic and a mile long (everything is a mile long in Assembly and looks like it must be the program).

A soft blitter graphics engine and sound processing engine get called from the top and bottom vertical blanks like John described but run on the Atari instead of the ARM.

Then the kernel just draws a static image reading what I agree are data streams since the data doesn't stream without calling the graphics engines in the vertical blanks (the kernel doesn't change it).

A good argument for the gameloop being the main program when a high level language is used is that it drives everything else above for being so abstract to the point where you could take the 9 line BASIC program and recompile it with SuperCharger BASIC and the program would drive the SuperCharger instead of CBS RAM.

The graphics and sound processing have a good argument too, a soft blitter is basically a hand written GPU weather it runs on the Atari or the ARM.

I can't see the kernel is the main program argument with even simple graphics because the kernel is always fed by data streams like a dumb terminal; the 2600 is designed that way so any routines that manipulate graphics have to stream the data the kernel reads.

Super Fast Data Streaming - Can you beat WARPDRIVE?

WARPDRIVE runs at 30 FPS of full screen animation and requires a 30th of a second reaction time to win. It's possible to beat with practice and the game encourages you with a unique positive messaging score system!

The Retron has excellent response time - I can beat the game just like on a classic console and the play feels the same. You can even see the same cool special effects over Plasma, and I think LCD though I haven't tried it.

The buildings have an interesting filter effect applied that texturizes them and changes the shape just like on CRT; here's a bonus version that isn't included with the Retron - this one removes the blur filter for crystal clear animation.

For anyone who wants an impossible challenge you can throw the BW switch during play and WARPDRIVE will switch to 60 FPS of full screen animation and require a 60th of a second reaction time.

I can't beat this on any Atari console but I consistently score higher vibes from the positive messaging system when I use a classic console on CRT; detecting input lag only at 60 FPS is negligible since that mode will remain more of a technical demo than an actual game... unless anyone can beat it, I'm still trying.

[mr_me]

It's up to the developer how much or little to use of the arm processor. Regarding the retron77, is it possible to write a rom dumper for these arm cartridges?

Edited July 21, 2018 by mr_me

[DirtyHairy]

It's up to the developer how much or little to use of the arm processor. Regarding the retron77, is it possible to write a rom dumper for these arm cartridges?

No, parts of the ROM image cannot be accessed by the 6507.

Edited July 21, 2018 by DirtyHairy