Jump to content
Metal Jesus

First Review of RetroN 77

Recommended Posts

Why would Atari reverse-engineer their own stuff? Why not reference the original blueprints and go from there?

Share this post


Link to post
Share on other sites

Pitfall II be damned... I'm just glad this new "Atari" console is compatible with the plastic joystick coupler that came with Spy Hunter. :lol:

  • Like 2

Share this post


Link to post
Share on other sites

Two questions:

 

1) Has anyone verified that supercharger compatible ROMs run off the SD card?

 

2) Is audio out only through HDMI?

Share this post


Link to post
Share on other sites

Two questions:

 

1) Has anyone verified that supercharger compatible ROMs run off the SD card?

 

2) Is audio out only through HDMI?

 

As ROMs, I've tested the following :

 

  • Official Frogger
  • Phaser Patrol (no clue what I was doing in this one..)
  • Survival Island
  • Communist Mutants from Space
  • Dragonstomper
  • Escape from the mindmaster
  • Rabbit Transit

confirmed working as roms.

 

Audit out is via HMDI there is no other audio out port or jack.

Edited by Muddyfunster
  • Like 1

Share this post


Link to post
Share on other sites

I don't know if it has been posted in the thread, but the review that Metal J was getting feedback for is now on Youtube here.

I have watched that video like 85,000 times now. :)

 

Just kidding.

  • Like 1

Share this post


Link to post
Share on other sites

Simply said I see it as a simulation/emulation because it is a new modern-day part acting like a vintage 1977 chip(s). However accurate or inaccurate it may be.

 

---

 

Another question. How long does it take for your system to start up from power application? Instantly? Does it have to load a core from on-board flash/serial rom? And can it "fry" cartridges like an original console?

 

OK, so let me pose a couple of questions, so that I may better understand your point. Are the TIA chips that Atari produced in the late 80s emulations of the chips produced in 1977? They aren't transistor exact implementations, and they also don't behave the same in corner cases. Also, if Atari was still producing the TIA chip today, it would probably be manufactured on a modern process, let's say a 45 nm process. The small transistors would remove the size constraints, and allow Atari to fix some of the bugs such as the bug in the extra-clocks counter that is responsible for the Cosmic Ark star field effect. Along with that, the fast switching times and tight tolerances would almost certainly guarantee that the anomalies seen in the old chips would be a thing of the past. Would this then be an emulation of the original TIA design?

 

It takes just over one second for the FPGA to load its configuration data from FLASH, and then configure itself. It takes another 750 ms for the FPGA to configure the PLL that generates the core and HDMI clocks. And then finally it takes another 250 ms to configure the HDMI transmitter chip. Once all that is done, it waits another 100 ms, and then pulls the 6507 and RIOT out of reset. I've been very careful to ensure that all of the logic is held in reset long enough, and then pulled out of reset in the correct sequence so that the system comes up in a valid and stable condition every time. So, you wouldn't be able to "fry" carts on my system.

 

Regarding your FPGA implementation: I really am genuinely curious about the level of accuracy you achieve this way and whether the results could be used as a guideline for improving software emulation. From recreating the TIA in emulation it was my impression (but I am admittedly rather lousy at electronics) that there are several aspects of the chip's behavior that actually depend subtly on phase and shape of different signals in the circuit. In particular, I am curious about the detailed structure of the starfield and the effects of sending HMOVE pulse during the visible part of the line. If you like and find time, could you run the testcases linked on GitHub here (starfield) and here (HMOVE) and post the result?

 

Well, our motivations my not be the same. From what I have seen, a design goal for most emulators is to have it behave exactly like the old hardware. A lot of work goes into mimicking odd behavior, corner cases, etc.

 

My goal, on the other hand, is to implement the original design, as it was intended, with modern hardware. At this point, I'm confident that it's correct, and that my hardware is doing exactly what the schematic says it should be doing. I'm basing this assertion on many hours of verifying my FPGA hardware against the logic simulations of the schematics. Because of this, there will most certainly be cases where my hardware doesn't exhibit the same anomalous behavior seen in a lot of the old hardware, and it may not be a good reference to use. It really comes down to what you are trying to achieve.

 

I downloaded the test programs. I'll dust off the Elgato capture box, and get some video for you, probably this weekend.

  • Like 1

Share this post


Link to post
Share on other sites

 

OK, so let me pose a couple of questions, so that I may better understand your point. Are the TIA chips that Atari produced in the late 80s emulations of the chips produced in 1977? They aren't transistor exact implementations, and they also don't behave the same in corner cases. Also, if Atari was still producing the TIA chip today, it would probably be manufactured on a modern process, let's say a 45 nm process. The small transistors would remove the size constraints, and allow Atari to fix some of the bugs such as the bug in the extra-clocks counter that is responsible for the Cosmic Ark star field effect. Along with that, the fast switching times and tight tolerances would almost certainly guarantee that the anomalies seen in the old chips would be a thing of the past. Would this then be an emulation of the original TIA design?

 

It takes just over one second for the FPGA to load its configuration data from FLASH, and then configure itself. It takes another 750 ms for the FPGA to configure the PLL that generates the core and HDMI clocks. And then finally it takes another 250 ms to configure the HDMI transmitter chip. Once all that is done, it waits another 100 ms, and then pulls the 6507 and RIOT out of reset. I've been very careful to ensure that all of the logic is held in reset long enough, and then pulled out of reset in the correct sequence so that the system comes up in a valid and stable condition every time. So, you wouldn't be able to "fry" carts on my system.

 

I consider the original chips from 1977 to be original hardware. I also consider the later 1980's chips to be original hardware. But they are revisions. Version 2 or version 9 so to speak. At the same time I'm also assuming they were designed from the original schematics by the original company. And approved by the original parent company.

 

If they were reverse engineered from scratch using decapping techniques and logic analysis (or made by another company entirely) I'd call them I'd call them clones or reproductions. Much like how someone with a 3D printer might make a reproduction part of gearbox or mechanical assembly of some sort.

 

If a TIA was made on modern 45nm process today I'd call it yet another revision, provided the original blueprints and specs were used. If tweaks and bigfixes happened to happen because of a new process, it's still a revision. Provided it was all approved by the parent company. It bears mentioning that parts are often second or third sourced, I consider those original hardware - they were/are built to the exact specification or approval

 

But one thing is common with all of the above, it's dedicated silicon with one function - to be a TIA. Permanent. Fixed. Unchanging.

 

I still call an FPGA-based TIA a simulation or emulation. There is nothing inherent in a blank array of gates that says it's a TIA. A software bitstream is required to get it operational. To define it. It's programmed. This is a chip being set up to act a certain way, not unlike a microprocessor being told to run a certain program. Similar to a software-defined radio.

 

---

 

On the other hand, an FPGA can be viewed as a self-assembling or automatic-assembling breadboard. And the parts are handled differently. If viewed that way, then I would call it (TIA in FPGA) a recreation. Burn it into the device permanently and I'd call it a replacement, but not a clone - knowing that it is not a transistor-for-transistor precise. Much like how replacement windshield wipers may look different from OEM parts and are constructed of different materials.

 

---

 

Honestly there are a lot of semantics in a discussion such as this. And that can cause some confusion from the tedium and trying to find the right word in quick conversation. I hope that all makes sense.

Edited by Keatah
  • Like 2

Share this post


Link to post
Share on other sites

Perhaps we should all stick to the basics:

 

Original Hardware = single fixed-function original chips made by and approved by the original company.

 

Software Emulation = traditional programming on a Von Neumann architecture system. A program that mimics the behavior of original hardware through programming.

 

FPGA = simulation/emulation of a certain piece of hardware on hardware which is defined and configured by software.

 

---

 

For the more basic early consoles SE and FPGA both do a good job of recreating the experience of interacting with the original hardware. There have been many a times I've lost myself in a VCS game and completely forgot I was playing via SE.

 

If asked to recommend one method, FPGA or SE as substitutes for OH, I would have to ask you numerous questions concerning value-added features, debuggers, selection menus, hardware independence, plug-n-play, cartridge use, updateability, speed, convenience, reliability, versatility, stability, and much more.

 

Things are so cheap these days you can realistically have all three forms and not break the bank.

Share this post


Link to post
Share on other sites

Emulation is not like emulation. Some emulators (e.g. z26 and older versions of Stella) have a more abstract view of the system. This is more a more general approach, simplifying and (deliberately) taking shortcuts (e.g. for performance). They have to gain extra compatibility by adding tweaks and hacks for certain games and break frequently on new tricks.

 

Other emulators (like Stella now) get that compatibility from emulating the chips (more and more) correctly. They are following the schematics, just like Crispy's FPGA implementation.

  • Like 2

Share this post


Link to post
Share on other sites

I follow that the Stella team used Crispy's code to follow the spec for the TIA sound output, but not the video yet.

 

Question for Crispy - does your FPGA Atari sound like the top Video with the real Atari on this thread playing GATE CRASHER or like the Stella vid below it?

I suspect it does, haven't seen an example of Stella sounding better with the reimplementation of your code yet. Would be interesting to compare them.

 

http://atariage.com/forums/topic/276511-gates-gate-crasher-atari-contest

 

 

 

 

Share this post


Link to post
Share on other sites

Well, our motivations my not be the same. From what I have seen, a design goal for most emulators is to have it behave exactly like the old hardware. A lot of work goes into mimicking odd behavior, corner cases, etc.

 

My goal, on the other hand, is to implement the original design, as it was intended, with modern hardware. At this point, I'm confident that it's correct, and that my hardware is doing exactly what the schematic says it should be doing. I'm basing this assertion on many hours of verifying my FPGA hardware against the logic simulations of the schematics. Because of this, there will most certainly be cases where my hardware doesn't exhibit the same anomalous behavior seen in a lot of the old hardware, and it may not be a good reference to use. It really comes down to what you are trying to achieve.

 

I downloaded the test programs. I'll dust off the Elgato capture box, and get some video for you, probably this weekend.

 

 

Thanks alot! What I am curious about is whether the effects that those testcases probe are direct results of the logic as described by the schematics (and implemented by your core), or whether they depend on "dirt" effects. In the first case, I might revisit the schematics in look for a more fundamental description than the implemented effective model for those edge cases. As Thomas said, the new core uses the schematics as a guideline, but 1) I am bad at reading schematics and 2) the simulation models the various interacting counters, not the gate level setup. ;)

Share this post


Link to post
Share on other sites

I suspect it does, haven't seen an example of Stella sounding better with the reimplementation of your code yet. Would be interesting to compare them.

 

That one is simple --- your ROM sounds just the same on real hardware as it does on *all* emulators (I checked on my PAL Jr.) You should fix your TV set or audio equipment.

Share this post


Link to post
Share on other sites

 

That one is simple --- your ROM sounds just the same on real hardware as it does on *all* emulators (I checked on my PAL Jr.) You should fix your TV set or audio equipment.

 

Your initial comment was that it sounded like the real hardware with your implementation of Crispy's code, but I never saw that example.

 

The thread I linked shows three videos on the Real Hardware, Stella 5.x and Javatari.

 

Neither of the emulators sound like the real hardware to anyone that has listened to them, play the vids and see for yourself.

 

There is nothing wrong with my television, if you have an example to share please upload it, I'd like to hear it to compare.

Share this post


Link to post
Share on other sites

Your initial comment was that it sounded like the real hardware with your implementation of Crispy's code, but I never saw that example.

 

That's pretty simple: you posted your ROM and claimed that it didn't sound right in emulation, I referred you to the implementation of Crispy's audio in 6502.ts and in the next (unreleased) implementation in Stella (as I know that the currently released code in Stella is inaccurate). Unfortunately, I made the big mistake of not checking your ROM on real hardware before posting. When I did, it sounded just like emulation: occasional crackling and hissing.

Edited by DirtyHairy

Share this post


Link to post
Share on other sites

 

That's pretty simple: you posted your ROM and claimed that it didn't sound right in emulation, I referred you to the implementation of Crispy's audio in 6502.ts and in the next (unreleased) implementation in Stella (as I know that the currently released code in Stella is inaccurate). Unfortunately, I made the big mistake of not checking your ROM on real hardware before posting. When I did, it sounded just like emulation: occasional crackling and hissing.

 

You wrote that the soundtrack was accurately reproduced in Stellerator, not a hypothetical.

 

Now you have an explanation that the real hardware sounds different because there is something wrong with my Television.

 

C'mon that's not very scientific, anyone can compare the ROM's or just listen to the video's I posted; they all sound different and so far only the real hardware gets it right.

 

btw my Vader sounds better than my Jr and reproduces the instruments in KC Monster Maze with more depth as well.

 

I also created a second version of GATES (R2A) with a soundtrack that sounds much closer in emulation and I can't hear the difference between the Vader and the Jr with it.

Share this post


Link to post
Share on other sites

 

Regarding your FPGA implementation: I really am genuinely curious about the level of accuracy you achieve this way and whether the results could be used as a guideline for improving software emulation. From recreating the TIA in emulation it was my impression (but I am admittedly rather lousy at electronics) that there are several aspects of the chip's behavior that actually depend subtly on phase and shape of different signals in the circuit. In particular, I am curious about the detailed structure of the starfield and the effects of sending HMOVE pulse during the visible part of the line. If you like and find time, could you run the testcases linked on GitHub here (starfield) and here (HMOVE) and post the result?

 

 

 

 

Thanks alot! What I am curious about is whether the effects that those testcases probe are direct results of the logic as described by the schematics (and implemented by your core), or whether they depend on "dirt" effects. In the first case, I might revisit the schematics in look for a more fundamental description than the implemented effective model for those edge cases. As Thomas said, the new core uses the schematics as a guideline, but 1) I am bad at reading schematics and 2) the simulation models the various interacting counters, not the gate level setup. ;)

 

I posted video on Youtube of the two test programs running on my hardware.

Star field test:

 

H Move test:

 

In general, the TIA is a purely digital device, and is not supposed to be affected by analog effects such as the phase between two signals. That's the whole point of synchronous logic. Logic states are sampled at clock edges, and then the logic updates and settles to a new state in between the clock edges. Exactly how this happens, and exactly how long it takes is not important, so long as the logic has reached a stable and correct state before the next clock edge. (Actually there is some analog circuitry in the chip for the audio levels and color clock phase, but that circuitry doesn't really pertain to this discussion.)

 

Unfortunately, due to size and cost constraints, not to mention the state of technology at the time, you can't always get what you want. The chip designers at Atari were obviously well aware of this. Some compromises had to be made, and one of them led to the famous Cosmic Ark star field effect. There's no doubt that the designers took some shortcuts with the extra-clocks counter in order to save space on the die, and they knew that these shortcuts could lead to potential software issues. The evidence can be found in the Stella Programmer's manual where it says, "WARNING : These motion registers should not be modified during the 24 computer cycles immediately following an HMOVE command. Unpredictable motion values may result."

 

It is hardware shortcuts like these that create grey areas when attempting to reconstruct the original intent of a design. The schematic alone might not tell the whole story, and someone who is attempting to recreate the original design will be forced to read between the lines. A good example of this can be found in the CPU register decoding. There are two clock domains in the TIA. The 1.19 MHz CPU clock and the 3.58 MHz system/pixel/color clock. When the CPU writes a value to a register that is used by logic driven by the system clock, there is no clear indication in the schematic that says exactly when the value in that register should be updated. Should it be updated before the next system clock edge, or after the next system clock edge? There are, however, clues that answer this question, and it is obvious after careful examination what that answer is. The original chip designer realized that due to the speed of the logic, and the tolerances of the manufacturing process, that there wasn't enough margin to safely let the register update before the next system clock edge. So he added some extra delay to the decoding logic to ensure that the register will be updated after the next system clock edge. I did the same thing in my FPGA, and found that the resulting behavior matched that of the original Atari chip.

 

So the point of all this is, yes, it will be interesting to see how the results of these tests compare between the original hardware and my hardware.

 

 

 

I follow that the Stella team used Crispy's code to follow the spec for the TIA sound output, but not the video yet.

 

Question for Crispy - does your FPGA Atari sound like the top Video with the real Atari on this thread playing GATE CRASHER or like the Stella vid below it?

I suspect it does, haven't seen an example of Stella sounding better with the reimplementation of your code yet. Would be interesting to compare them.

 

http://atariage.com/forums/topic/276511-gates-gate-crasher-atari-contest

 

 

 

 

 

Mr SQL, I also posted video of your Gate Crasher game.

 

I ran the game on my FPGA hardware, on Stella, and on my NTSC 2600 Jr. To my ear they all sounded virtually the same. I also tried it with the analog audio output from my FPGA hardware connected directly to my Sansui receiver, and while it may have had a bit more depth than the HDMI audio, it sounded mostly the same.

 

In each case, I ran the game from my Harmony cartridge. Do you think that might have something to do with it? I'm not sure if you're relying on something in the Supercharger that isn't exactly the same in the Harmony.

Edited by Crispy

Share this post


Link to post
Share on other sites

 

Mr SQL, I also posted video of your Gate Crasher game.

 

I ran the game on my FPGA hardware, on Stella, and on my NTSC 2600 Jr. To my ear they all sounded virtually the same. I also tried it with the analog audio output from my FPGA hardware connected directly to my Sansui receiver, and while it may have had a bit more depth than the HDMI audio, it sounded mostly the same.

 

In each case, I ran the game from my Harmony cartridge. Do you think that might have something to do with it? I'm not sure if you're relying on something in the Supercharger that isn't exactly the same in the Harmony.

 

I perceived a bit more depth on my Junior like you did with your FPGA, but with my Vader there was considerably more depth. There are likely differences in the spec of these TIA revisions.

 

I also noticed my Vader produces better NTSC artifact colors than my Junior, but the Junior still has them. This is the only feature I think your FPGA may be missing if you did not deliberately design the composite video output to support it; Bill and Boisey have a book out on the Color Computer that discusses Tandy engineers increasing the chroma to get artifact colors back after a video mod.

Share this post


Link to post
Share on other sites

Basically, lightgun games on a CRT and homebrews not available as ROMs are the biggest drawbacks to not use emulation on a PC vs one of these clones these days, aside from nostalgia. If the R77 can't play homebrew carts, you lose the ability to play the two lightgun games -- plus the trackball, keypads, that third party booster grip controller with the extra button -- and a bunch of original release carts don't work, it really seems to be a poor competitor to Stella on a PC. Although you could say the same thing about Flashbacks, which have been very popular...and I had one of the FB joystics break after ten minutes.

 

Edit: On further consideration, that is about what it is: the flashback that people have been asking for: one with sd card and cart slot - if they can get the paddles and rom limit - AND QUALITY CONTROL - sorted out, it may be imperfect, but a couple big steps closer to what people have been asking for in the flashbacks, at about half the price of the Activision Gold 8. Except for the lack of improved cordless joysticks - maybe a small price to pay for $30-$40. Personally, I still prefer Stella on PC and my AV modded 2600 Jr with harmony cart, but that 2nd option could run you $180+, all inclusive.

Share this post


Link to post
Share on other sites

Basically, lightgun games on a CRT and homebrews not available as ROMs are the biggest drawbacks to not use emulation on a PC vs one of these clones these days, aside from nostalgia. If the R77 can't play homebrew carts, you lose the ability to play the two lightgun games -- plus the trackball, keypads, that third party booster grip controller with the extra button -- and a bunch of original release carts don't work, it really seems to be a poor competitor to Stella on a PC. Although you could say the same thing about Flashbacks, which have been very popular...and I had one of the FB joystics break after ten minutes.

 

Edit: On further consideration, that is about what it is: the flashback that people have been asking for: one with sd card and cart slot - if they can get the paddles and rom limit - AND QUALITY CONTROL - sorted out, it may be imperfect, but a couple big steps closer to what people have been asking for in the flashbacks, at about half the price of the Activision Gold 8. Except for the lack of improved cordless joysticks - maybe a small price to pay for $30-$40. Personally, I still prefer Stella on PC and my AV modded 2600 Jr with harmony cart, but that 2nd option could run you $180+, all inclusive.

Honestly people want an actual reproduction system with non-emulated cart port. Like someone pointed out what's the point if its just a dumper? Honestly if ATgames has an SD and can get the newest Stella on it then its an easy choice.

Share this post


Link to post
Share on other sites

Cartridge dumping in R77 is achieving maybe a 60-70% success rate. That's not passing in my gradebook.

  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...