RetroN 77

[Keatah]

The Retron77 plays these games too but the Flashback cannot; I played Super Cobra Arcade and Super Cobra on the Retron last night and both games are pretty awesome but I only consider Super Cobra a classic Atari game.

 

How did you get the Champ Games' Super Cobra Arcade running on Stella 3.9.3?

Edited July 18, 2018 by Keatah

[Mr SQL]

I don't agree. Adding extra chips or whatever to a game is no different than what they did back in the day (RAM chips in CBS carts, The Supercharger, the chip in Pitfall II etc.) As long as you still have to write within the constraints of the console hardware, it's a legit expansion, even if the chip adds more RAM or whatever.

 

When the new hardware bypasses the Atari's core design (say by replacing the display hardware to allow for more sprites) completely, then it isn't a real 2600. If you still have to program within the architecture of the 2600, it's just fine, and honestly, really cool.

That's precisely what the ARM has been used to do, drive more sprites and graphics than are possible with legacy hardware; it's not obvious if you're not a programmer.

I like ARM games too but it's apples to oranges based on your definition.

 

 

How did you get the Champ Games' Super Cobra Arcade running on Stella 3.9.3?

 

I used the earlier build of Stella, and possibly an earlier build of SCA - I'll post the version I used tonight.

[Keatah]

FPGA projects are just like software projects they can be closed source like Kevtris' or they can be open-source like this one.

https://retromaster.wordpress.com/a2601/

Software or fpga, these things are often primarily one man projects with other occasional contributors. They sometimes get handed off or forked.

 

I've seen many Software Emulation projects get handed down over the years. And they seem to do very well, sometimes even better than before. The longevity allows for lengthy crowdtesting, which is important in emulation developement. As corner-cases are fixed in one game, undiscovered issues with other games are automagically fixed too. Longevity is a key point, it allows these tiny fixes to accumulate and, well, that just improves accuracy.

 

I also say that SE is oftentimes bigger than any one tiny, puny, developer. Like the space program.

 

 

I do agree that there is an unfair bias against PC based software emulation. But consider that there are still computer phobic people and others that want an out of the box solution.

Hopefully boxes like R77 will possibly help change that perspective. Maybe they will act like an introduction to software emulation and encourage others to explore the PC platform more.

 

I just think back to when I was a kid, and if the "brains" that powered a console I just got could be removed and placed into "super hardware" where I could change settings and run thousands of games from a slick text-only menu, you bet I'd be learning how to use this new "super hardware"!

 

 

Regarding a new game that runs on an emulator but doesn't run on original hardware; I don't understand why any developer would want to do that. I understand it happens but the risk is it may not run on other compatibles as well. If it runs on original hardware it should run on emulators. If it doesn't than it's the emulator that should be fixed not the program. Add-on processors are a separate issue.

 

I've never met a developer that's made something that worked on Emulation exclusively. They were all bothered by it. At one time or another, sooner or later, if they DID do that, they were uneasy about it and vowed to revisit the problem.

 

---

 

Add-on processors. Indeed a completely separate issue from whether or not a game works in emulation only. Or worse yet, on certain emulators only.

 

If I wasn't clear on my take on Add-on processors.. Try this one.. It's simple. If they've been around, have a large fanbase and software support, if it fits in the cart slot, then great! It becomes part of the overall ecosphere.

 

Add-on procs are a natural evolution, just like flash carts with uber high-density storage chips are. Add-on procs are like intelligent memory that can change itself. At least that's how the VCS would see it if it could offer opinions.

 

As a matter of fact, when I was a kid, I ALWAYS envisioned putting a processor onto a memory chip. And I envisioned that the cartridge would sometimes return one hex value when "A439" memory location was accessed. But would return yet a different hex value from "A439" memory location if something else put in an entirely different "A570" memory location.

 

I also thought that accessing "A401" every 100ms would return a certain value like "11h". But if we accessed "A401" every 200ms, it would be returning "57h". And by adjusting the timing, we could retrieve all sorts of patterns. Patterns for backgrounds, or the scaling of object sizes. Shit like that.

 

A kid's description of an active cartridge - Smart Memory Cartridge! SMC. The cartridge that thinks!

 

And I don't believe there should be a cut-off date saying this is as far as we go, any tech after xx-xx-xxxx is not allowed - ridiculous. Might as well not have ever developed a bank switch scheme beyond 4K.

[atarifan88]

I know the Atari Flashback had similar issues where you could run early versions of certain homebrews to play, but I think for the product to be worthwhile (Retron 77 or Flashback), they need to be able to run the final versions of the game as you are truly playing a demo/unfinished version without all the features. Same goes with having to modify a game just so it will work on a clone system (this was touched on earlier). I'm done with settling for less...

Edited July 18, 2018 by atarifan88

[Andromeda Stardust]

 

We had a lot of teamwork doing precisely that for the Flashback Portable to ensure new homebrews could be compatible and existing titles could be patched.

 

The reason for this seems fairly obvious - the new Atari consoles have much broader exposure than the legacy consoles. Simply put, many more players can play Atari because new consoles are being produced!

 

The same holds true for the Retron77 and it's far easier to support from a Development standpoint, Hyperkin designed it to encourage more game development as a programmer friendly system.

 

Consider that we support the Flashback even though it is a closed system which made it much more challenging because we had to figure out how code was broken we couldn't see. We succeeded in supporting the console with near 100% compatibility, even wrote code translators to make SuperCharger titles run using alternate legacy protocols.

 

 

From my perspective that's up to the programmer.

 

your perspective as a player is equally valid and also extreme - how do you feel about ARM games where the gameloop and graphics routines run on the 32-bit chip in the cart?

 

The Retron77 plays these games too but the Flashback cannot; I played Super Cobra Arcade and Super Cobra on the Retron last night and both games are pretty awesome but I only consider Super Cobra a classic Atari game.

 

The Video Game Critic expressed the opposite extreme from your perspective doing a simultaneous review of both games and gave the 8-bit Atari game an F comparing it to the much larger 32-bit ARM version of the game:

 

https://videogamecritic.com/forums/viewtopic.php?f=39461&t=17053

 

 

ive read a bunch of vg critics reviews, and he has slammed f-ratings on stuff ive enjoyed, as well as highly praised stuff i found to be mediocre from a gameplay perspective. a review is one persons opinion. i personally believe f or 1/10 should be reserved for games with no redeemable qualities or are so broken/buggy as to be unplayable. even et i would probably give a d rating to.

[Andromeda Stardust]

 

Games that run on an emulator but not original hardware are broken by design. The original hardware ALWAYS dictates what is correct and what is incorrect. You should never have to patch a game that runs on real hardware to work correctly anywhere else. That means the 'anywhere else' (emulator, 3rd-party console, etc) are broken.

 

We've spent considerable time making Stella as faithful as possible to a real console, warts and all. We could take out some of the limitations in the software, to allow for more colours, less flicker, more objects, etc. No doubt it would make for a great game if all of that was incorporated. It would look great from the POV of the 2600, but IT WOULD NOT BE A REAL 2600.

 

i try to explain this logic to the n64 hacking community and it fell on deaf ears. they literally dont give a rats bottom that 99 % of mario64 hacks dont work on real hardware.

[Keatah]

If ARM games required an HDMI connector on the cartridge and video was output in glorious HD @ 1900x1080, then I could say we're looking at whole new system.

 

On the other hand who is to say it's not a valid video expansion option?

Edited July 18, 2018 by Keatah

[mr_me]

If the main game program is not running on the 6507 but rather on a processor on the cartridge, it's not an Atari 2600 game. The 2600 is just a display processor to another computer on the cartridge. If the main program is running on the 6507 and uses helper chips (e.g. math coprocessor) on the cartridge, it becomes an expanded Atari 2600 system; no different than if they put the chips in an expansion module you bought once.

[Thomas Jentzsch]

Now it depends on what you call the "main program" here.

[Keatah]

I would say the VCS becomes more like a front-end to the ARM game. The pace is set by the VCS, the controllers and switches from the VCS are controlling the ARM game.

 

I suppose the definition of where the main program is running also makes sense.

 

But if you draw a box around the VCS and show connections for RF, Power-in, and controllers; electrically the VCS proper and any circuits that plug into it are still VCS.

 

The wife calls these ARM games DROM games. Dynamic Read Only Memory. Noting that (from the VCS viewpoint) the memory doesn't change states, but has a huge amount of states that can be accessed in the time domain too. Certain signals sent to the cartridge at a certain time mean different things. They go through a different lookup table and can come back differently based on the time they were sent.

 

Unlike a standard 2K ROM, no matter when the VCS sends the access signals, the same information comes back.

[Andromeda Stardust]

If the main game program is not running on the 6507 but rather on a processor on the cartridge, it's not an Atari 2600 game.

 

Erm, not quite. Most Melody based ARM games use an ARM to run the game logic, then writes 6502 code to the cartrdige bus which instructs the 6502 to stuff registers in the TIA with specific values in order to push graphics and audio to the rf output. You still have only 2 8-bit player sprites, 2 balls, 2 missiles, and extra wide playfield background to work with. You are still limited by the number of writes to the TIA that can be made in a single scanline. It is also necessary to query the 6502 using native 6502 code to retrieve the joystick inputs. So it is technically a game running 6502 code and ARM code.Is a Super FX or SA-1 Super Nintendo cartridge (ie Yoshi's Island or Super Mario RPG) not an actual SNES game? Because if it plugs into the slot, and the console provides video to the TV set, than it qualifies as a game. Though the Super Game Boy might be a gray area. Is it a Game Boy game? Yes. Is it an SNES game? Well technically it is both...

[mr_me]

 

Erm, not quite. Most Melody based ARM games use an ARM to run the game logic, then writes 6502 code to the cartrdige bus which instructs the 6502 to stuff registers in the TIA with specific values in order to push graphics and audio to the rf output. You still have only 2 8-bit player sprites, 2 balls, 2 missiles, and extra wide playfield background to work with. You are still limited by the number of writes to the TIA that can be made in a single scanline. It is also necessary to query the 6502 using native 6502 code to retrieve the joystick inputs. So it is technically a game running 6502 code and ARM code....

Sounds like the main game program is running on the cartridge processor. Edited July 18, 2018 by mr_me

[+SpiceWare]

Close, but that makes it sound like the ARM is writing 6502 code. The 6502 code is all in ROM like any traditional 2600 game, and was written by the programmer. What the ARM code does is populate datastreams which, like the datastreams in Pitfall 2, allow the kernel to update TIA more frequently than normal.

This short example is Draconian's 6502 code for the score/radar display. Anything that's LDA #DS_xxx is loading data from a datastream. In Pitfall 2 those instructions would be LDA DS_xxx, which take 4 cycles rather than 2. The source code is in my blog if anybody cares to look at it.

ExitKernel:                     ;   20
        ; currently drawing the last line of the gameplay area
        ldx #0                  ; 2 22
        stx GRP0                ; 3 25 <- for next scanline, VDELP0 on
        stx ENABL               ; 3 28 <- for next scanline, VDELBL on               
        sta WSYNC               ; 3 31/0
        
        ; blank line before condition color
        stx GRP1                ; 3  3 <- also updates GRP0 and BL
        stx ENAM0               ; 3  6
        DIGITAL_AUDIO           ; 5 11
        stx HMCLR               ; 3 14
        stx ENAM1               ; 3 17
        stx NUSIZ0              ; 3 20
        stx NUSIZ1              ; 3 23
        ldx #HMOVE_R2           ; 2 25
        stx HMBL                ; 3 28
        lda #DS_RADAR_CONTROL   ; 2 30 <- status color
        tax                     ; 2 32 <- in X for duration of status display
        ldy #4                  ; 2 34
        sty CTRLPF              ; 3 37 <- 1x ball, display priority over player
        ldy #HMOVE_R8           ; 2 39
        sty HMP0                ; 3 42 <- finetune for radar
        ldy #HMOVE_L6           ; 2 44
        sty HMP1                ; 3 47 <- finetune for radar
        
;        dec Sleep5              ; 5 52 3 byte sleep 7
;        SLEEP 2                 ; 2 54
        PHA                     ; 2 byte sleep 7
        PLA                     ; 
        
        sty RESP0               ; 3 57
        sty RESBL               ; 3 60
        sty RESP1               ; 3 63
        sta WSYNC               ; 3 66/0
        
        ; condition line color
        sta HMOVE               ; 3  3
        stx COLUBK              ; 3  6
        DIGITAL_AUDIO           ; 5 11
        stx COLUP0              ; 3 14
        stx COLUP1              ; 3 17
        sta WSYNC
        
        ; first line of top radar frame
        ldy #0                  ; 2  2
        sty COLUBK              ; 3  5
        DIGITAL_AUDIO           ; 5 10
        lda #DS_RADAR_GRP0      ; 2 12
        sta GRP0                ; 3 15
        lda #DS_RADAR_GRP1      ; 2 17
        sta GRP1                ; 3 20
;        ldy #RADAR_HEIGHT - 5   ; 2 22 loop replaced with jmp FASTJMP
;        sty LoopCounter         ; 3 25
        lda #DS_RADAR_CONTROL   ; 2 27 <- position player in radar
        sta HMBL                ; 3 30
        lda #DS_RADAR_CONTROL   ; 2 32
        sta FormationColor      ; 3 35
        sta WSYNC
        
        ; second line of top radar frame
        lda #<DS_RADAR_GRP0     ; 2  2
        sta GRP0                ; 3  5
        DIGITAL_AUDIO           ; 5 10
        lda #<DS_RADAR_GRP1     ; 2 12
        sta GRP1                ; 3 15
        ldy #HMOVE_R2           ; 2 17
        sty HMP0                ; 3 20
        ldy #HMOVE_L2           ; 2 22
        sty HMP1                ; 3 25
        lda #DS_RADAR_CONTROL   ; 2 27
        sta COLUPF              ; 3 30     
        jsr SLEEP12             ;12 42
        jsr SLEEP12             ;12 54
        jsr SLEEP12             ;12 66
        
        ;dec Sleep5              ; 5 71
        ;SLEEP 2                 ; 2 73
        PHA
        PLA
        
        ; first line of score/radar
        sta HMOVE               ; 3 76/0
        DIGITAL_AUDIO           ; 5  5
        lda #<DS_PF0L           ; 2  7
        sta PF0                 ; 3 10
        sta ENABL               ; 3 13 - on VDEL
        lda #<DS_PF1L           ; 2 15
        sta PF1                 ; 3 18
        lda #<DS_PF2L           ; 2 20
        sta PF2                 ; 3 23
        lda #<DS_RADAR_GRP0     ; 2 25
        sta GRP0                ; 3 28 - on VDEL
        lda #<DS_RADAR_GRP1     ; 2 30
        sta GRP1                ; 3 33 - updates GRP0 and BL as well
        lda #<DS_RADAR_CONTROL  ; 2 35
        sta COLUP0              ; 3 38 - enemy color in radar        
; TODO        
; change this to lda #<DS_STATION_COLOR and eliminate entry in radar control
; TODO
; change the formation color and enemy color to work the same
        lda #<DS_RADAR_CONTROL  ; 2 41
        sta COLUP1              ; 3 43 - station color in radar
        lda #<DS_PF0R           ; 2 45
        sta PF0                 ; 3 48 - PF0R, 28-49
        lda #<DS_PF1R           ; 2 50
        sta PF1                 ; 3 53
        lda #<DS_PF2R           ; 2 55
        sta PF2                 ; 3 58 
        ldy #HMOVE_L2           ; 2 60 - prep to shift players to draw the
        sty HMP0                ; 3 63 - radar frame AFTER ScoreLoop is done
        ldy #HMOVE_R2           ; 2 65
        sty HMP1                ; 3 68
        ldy #2                  ; 2 70
        sty NUSIZ0              ; 3 73 - 2 copies medium for formation display 
        sty NUSIZ1              ; 3 76 - 2 copies medium for formation display
        
ScoreKernel: ; this was originally called ScoreLoop, as seen in some of the other comments
        lda #<DS_PF0L           ; 2  2
        sta PF0                 ; 3  5
        sta ENABL               ; 3  8 - on VDEL
        DIGITAL_AUDIO           ; 5 13
        lda #<DS_PF1L           ; 2 15
        sta PF1                 ; 3 18
        lda #<DS_PF2L           ; 2 20
        sta PF2                 ; 3 23
        lda #<DS_RADAR_GRP0     ; 2 25
        sta GRP0                ; 3 28 - on VDEL
        lda #<DS_RADAR_GRP1     ; 2 30
        sta GRP1                ; 3 33 - updates GRP0 and BL as well
        lda #<DS_STATION_COLOR  ; 2 35
        sta COLUP1              ; 3 38
        lda #<DS_FORMATION_GRP0 ; 2 40
        sta GRP0                ; 3 43 - on VDEL
        lda #<DS_PF0R           ; 2 45
        sta PF0                 ; 3 48 - PF0R, 28-49
        lda #<DS_PF1R           ; 2 50
        sta PF1                 ; 3 53 - PF1R, 39-54
        lda #DS_FORMATION_GRP1  ; 2 55
        tay                     ; 2 57
        lda #<DS_PF2R           ; 2 59
        sta PF2                 ; 3 62 - PF2R, 50-65
        lda FormationColor      ; 3 65
        sty GRP1                ; 3 68 - updates GRP0 as well
        sta COLUP1              ; 3 71
        SLEEP 2                 ; 2 73
        jmp FASTJMP             ; 3 76 <- this loops to ScoreKernel, eventually falls to code below

ExitScoreKernel:        
        ; draws lower corners of radar frame
        sta HMOVE               ; 3  3
        DIGITAL_AUDIO           ; 5  8
        ldy #0                  ; 2 10
        sty PF0                 ; 3 13
        sty PF1                 ; 3 16
        sty PF2                 ; 3 19
        sty ENABL               ; 3 22
        sty NUSIZ0              ; 3 25 - 1 copy, no more formation display
        sty NUSIZ1              ; 3 28 - 1 copy, no more formation display
        lda #<DS_RADAR_GRP0     ; 2 30
        sta GRP0                ; 3 33
        lda #<DS_RADAR_GRP1     ; 2 35
        sta GRP1                ; 3 38
        stx COLUP0              ; 3 41 - X holds status color
        stx COLUP1              ; 3 44 - X holds status color
        ldx #RUN_GAME_OS        ; 2 46 - for PrepArmCall on next scanline
        lda #<DS_RADAR_GRP0     ; 2 48 - for sty GRP0 on next scanline
        tay                     ; 2 50 - cannot use STA due to DIGITAL_AUDIO        
        jmp SecondRadarLine     ; 3 53

; in order to free up a few cycles of time, the following is actually located
; towards start of ROM, not after ExitScoreKernel

SecondRadarLine:        
        ; second line of bottom radar frame
        ; having this here frees up a few cycles of time for the ARM code
        ; Y is preloaded with value for GRP0
        ; X is preloaded with value for PrepArmCall
        sta WSYNC           ;    0 
        DIGITAL_AUDIO       ; 5  5        
        sty GRP0            ; 3  8
        lda #<DS_RADAR_GRP1 ; 2 10
        sta GRP1            ; 3 13
        jsr PrepArmCall     ;44 57 or 58 71 if SHOW_DIAGNOSTIC = 1
        ldy #2              ; 2 59     2 73
        ldx #OS_TIM64T      ; 2 61     2 75
        DIGITAL_AUDIO       ; 5  5     5 80/4        
        sty VBLANK          ; 3  8     3  7 - Video Blank ON (thus image output off)
        stx TIM64T          ; 4 12     4 11
        
OverScan:

---

[SIO2]

No science here. Just an observation. I play a fair amount of Dintar's Pac-man 8k v7 on real hardware and I made an sd card for the Retron 77 of each the latest Hyperkin card which still uses Stella 3.7.5 and the Stella 3.9.3 v2 patched original sd card.

 

So what I find is that my scores are fairly consistent on each platform but my scores with Stella 3.7.5 are much closer to my scores on real hardware. To me, 3.7.5 seems to turn out better speed and control response than 3.9.3. Using 3.9.3 I find that I end up cruising past intersections a lot which leads to me dying more often.

 

Oh, probably should say I am playing with a Slik Stick in all 3 cases. Slik Stick has a short throw and I find it to be a very quick and reliable controller.

Edited July 19, 2018 by SIO2

[Keatah]

Emulators do not get faster as newer versions come out. Given the same hardware, their response time becomes ever so slightly slower due to more code being incorporated.

 

I would want to say they bloat out. But that's a strong term. They bloat out just a little. Moreso their libraries and APIs bloat much more.

[Mr SQL]

Sounds like the main game program is running on the cartridge processor.

 

Yes John explains the ARM chip runs the gameloop and the graphics and sound processing for anyone confusing it with Pitfall II.

 

Turns out the two awesome games I played on the Retron77 the other day were Super Cobra and Scramble, not SCA.

 

 

No science here. Just an observation. I play a fair amount of Dintar's Pac-man 8k v7 on real hardware and I made an sd card for the Retron 77 of each the latest Hyperkin card which still uses Stella 3.7.5 and the Stella 3.9.3 v2 patched original sd card.

 

So what I find is that my scores are fairly consistent on each platform but my scores with Stella 3.7.5 are much closer to my scores on real hardware. To me, 3.7.5 seems to turn out better speed and control response than 3.9.3. Using 3.9.3 I find that I end up cruising past intersections a lot which leads to me dying more often.

 

 

Emulators do not get faster as newer versions come out. Given the same hardware, their response time becomes ever so slightly slower due to more code being incorporated.

 

I would want to say they bloat out. But that's a strong term. They bloat out just a little. Moreso their libraries and APIs bloat much more.

 

I was wondering if someone was going to make those observations about the newer version; agree code bases tend to get heavier over time and slow down particularly in projects with many programmers.

 

If the current version offers best performance for the hardware don't upgrade it. Better option would be a new branch if needed to keep the performance optimized. One general problem with programming today is that the dev processors are too fast; programmers don't optimize their routines as much as they would have when they were writing their emulators for 32-bit 100 Mhz CPU's.

[SIO2]

I think that the original (actually both) Hyperkin images save that Stella config file when a cart is swapped. I had the complaint that my system did not remember the 4:3 setting and I had to set it each time. What I discovered though was if I loaded a rom then set the 4:3 setting to 4:3 and then inserted a cartridge (Space Invaders) and waited for it to load then removed that cartridge, the next time I booted up from cold it had saved my 4:3 setting.

 

Stephena said that improper shutdown might be the cause of the corruption in the config file. I can see that happening if the console looses power while saving. So, knowing when it saves that file is important in the unpatched image anyhow. I would think it would be safe to switch off the console once a game had loaded or if you are parked at the menu but pulling the cart and switching the power off at about the same time might be a problem. Just a guess.

 

Of course Stephena fixed the problem by limiting what is saved in the config file and making it save immediately when the setting changes but that has not been incorporated to the Hyperkin image yet.

Edited July 19, 2018 by SIO2

[Andromeda Stardust]

 

Stephena said that improper shutdown might be the cause of the corruption in the config file. I can see that happening if the console looses power while saving. So, knowing when it saves that file is important in the unpatched image anyhow. I would think it would be safe to switch off the console once a game had loaded or if you are parked at the menu but pulling the cart and switching the power off at about the same time might be a problem. Just a guess.

It is very likely I may have done this. Either way, intalling the v2 Stella 3.9.3 image provided by Stephena, and deleting the controller configuration files, permanently fixes the issue.

 

The new Hyperkin image which allows more than 18 roms does not support Stephena's 3.9.3 v2 build, sadly. I have no idea why this is. Presumably the Stella binary file did not change from Hyperkin's initial 3.7.5 build? Odd...

[dashv]

My Retron 77 arrived today in an inside out UPS box shipped USPS covered in packaging tape.

 

There was no packing materials for it. Thankfully it arrived without damage. It just looked like a n00b eBay seller packed it.

 

Based on that and the long trail of tears Ive read on this topic I honestly expected my experience to be a dumpster fire burning with regret.

 

I unboxed it. Removed the SD card. Copied the small handful of hombrew games I sometimes play and grabbed a physical copy of my wifes favorite Lost Luggage.

 

I downloaded the community version of Stella 3.9.3 from the Retron 77 page. Updated my SD card. Plugged in Lost Luggage and played until I got a score my wife could not beat. (took about 5 minutes).

 

Pulled the cartridge out with the game running.

 

The game selection menu does honestly need some work. My feeling is get rid of the icons and just show us the list of our games.

 

I powered off the console at this point. Powered it back on.

 

My homebrews loaded and played fine.

 

Panky the Panda

Donkey Kong 2014

Pac Man (the good one with the arcade layout, cut scenes, etc).

 

Popped in Kaboom and plugged in my one plug 2 player paddles.

 

Even not touching the dial the input is twitchy (like some others have mentioned). But it was playable.

 

It doesnt seem to remember the aspect ratio setting between power cycles, but I can live with that and surprisingly I find that I dont mind 16:9.

 

I dont have a game to test my racing controller with.

 

I popped in Star Raiders and plugged in my Video Touch Pad. The game plays but does not recognize the touchpad.

 

Graphics and sound are wonderful. This is a great way to play Panky.

 

My original 7800 joystick works.

 

I did not sense any lag with this connected to my 4K Roku TV in Game Mode.

 

Overall I am happy with my purchase.

 

Wishlist items:

- Fix the paddle sensitivity

- Add Video Touchpad Support

- Get rid of the icons, just show the game list

- Add 7800 game support

Edited July 19, 2018 by dashv

[SIO2]

@dashv

 

I am glad you like your Retron 77. It really is a neat little console and while they could have done a better job testing it, I think it is a good value.

 

My console arrived packaged as yours. It didn't receive damage exactly but the retail box fits the packing box so tightly and it must have got compressed somewhere along the way. Anyhow, the cardboard of my console box got pressed to where you can see the corrugation lines. While I don't consider myself a collector first and foremost, I was hoping to have a nice display box for this unit. So, maybe Hyperkin wants to think about their packaging. With only $10 for shipping though, they did a fair job.

[+stephena]

I was wondering if someone was going to make those observations about the newer version; agree code bases tend to get heavier over time and slow down particularly in projects with many programmers.

 

If the current version offers best performance for the hardware don't upgrade it. Better option would be a new branch if needed to keep the performance optimized. One general problem with programming today is that the dev processors are too fast; programmers don't optimize their routines as much as they would have when they were writing their emulators for 32-bit 100 Mhz CPU's.

 

I know I'm feeding the troll, and I already have you on block, but: Again, you don't know what the hell you're talking about.

 

I'm kind of tired of these thinly veiled accusations from someone who obviously has no experience with development at this scale, and working on a project for so many years.

 

We take great effort to make sure that nothing is bloated or slowed down in newer versions of Stella. Including testing on older hardware to make sure there are no regressions. In fact, the major reason for moving to SDL2 in Stella 4 was to take advantage of hardware acceleration, so that as long as your video card was not absolutely ancient, the minimum CPU needed actually dropped from 3.x to 4.x!

 

Another major issue here that many people are forgetting is that the version of Stella on this device is over 5 years old. Almost all the bug reports I'm getting are for things that have already been fixed years ago! So TBH it's getting somewhat annoying to have to explain why certain areas are deficient when from my POV I've already considered and fixed those issues, and moved on years ago.

[+stephena]

Seeing that Hyperkin has put a 'Community Build' on their website, and the fact that many people are requesting my latest changes to be incorporated with theirs, I will post an updated firmware later this evening.

 

I have sent the changes to Hyperkin, but since they seem to have a time lag in responding, and everyone here is anxious, I will get to it later.

[+SpiceWare]

I knew I shouldn't have clicked it...

 

 

Looks like someone still has some misplaced anger over the Video Game Critic declining to review his game. Might be time to seek some professional help.

 

For everybody else, I'm curious, do you also find it odd that a person will:

1. actively denigrate new games that run on all the classic 2600s
2. actively denigrate Stella, which runs all the classic games
3. while actively promoting new "2600" hardware that can't run all the classic games?

I'm sure there's a word for that

 

Edit: inserted #2

Edited July 19, 2018 by SpiceWare

[Mr SQL]

 

I know I'm feeding the troll, and I already have you on block, but: Again, you don't know what the hell you're talking about.

 

I'm kind of tired of these thinly veiled accusations from someone who obviously has no experience with development ...

 

 

I knew I shouldn't have clicked it...

 

Screen Shot 2018-07-19 at 7.38.32 AM.png

 

Looks like someone still has some misplaced anger over the Video Game Critic declining to review his game. Might be time to seek some professional help.

 

For everybody else, I'm curious, do you also find it odd that a person will:

1. actively denigrate new games that run on all the classic 2600s
2. while actively promoting new "2600" hardware that can't run all the classic games?

I'm sure there's a word for that

 

Looks like e-stalking to me, you keep posting images whenever I post to someone else, your recently did that on the 2600 programming forum posting a picture of my reply to Enthusi over the same topic. Please stop it, if you want to have an intellectual discussion though that's fine.

 

Calling ARM games awesome games isn't denigrating them, they're tremendous fun to play however it isn't fair to group them in the same category as classic Atari games; I agree with John that it's a lot easier to code in c on a 32-bit CPU, why not keep it real and promote them as 32-bit ARM games that drive the TIA?

 

Stephana stop throwing insults and being a prima donna, I support all Atari systems with programming languages, IDE's and development tools:

[+stephena]

I was able to create a build here at work, but I can't test it, as my R77 is at home. I'm almost 100% sure it will be fine though. Since there have been so many requests and confusion/miscommunication in this thread, I will outline fully:

1. Everything I am about to describe has been sent to Hyperkin, but I assume it will take them time to analyze and respond.
2. The builds that I provide are not official, in that I offer no support for it; I may be able to answer a quick question or two, but in the end the responsibility falls to Hyperkin to provide updates, and you (the end-user) to apply them.
3. I created a new branch on the Stella Github page specific to this device: https://github.com/stella-emu/stella/tree/stella3-r77

The following explains how to re-build the firmware (and assumes general Linux knowledge):

1. Download the latest 'source code' from the Hyperkin site and decompress it.
2. In the parent directory, delete 'BTE_H3/app/stella' and decompress the one attached to this posting to that same location.
3. Delete the config file at 'BTE_H3/rom/stella/stellarc'; you do not need a config file at all, Stella will generate it as necessary
4. (Re)-build the image.

Changelog for the included Stella as follows:

• Updated to last 3.x version (3.9.3)
• Fixed bug where sometimes the config file became corrupted and the joystick fire button stopped working
• Removed '0' from the state load/save messages
• Added included ROMs to the ROM properties database, so that less flicker is present for ones needing phosphor effect enabled.

Latest Stella code (to decompress as described above): stella.tar.gz

 

Very latest firmware image (includes latest Hyperkin changes and latest Stella changes) -> AKA, the most recent version of everything: sdcard.img.zip

 

This is all the work I will be doing on Stella 3 for this device. If someone can get the system into such a state that I can install Stella 5, I would be happy to offer guidance/help on getting it working correctly.

 

Good luck,

Steve A.

Stella maintainer