RevEng

January 31

40 minutes ago, Bwayne32 said:

I am having issues updating to the newest firmware update. I followed all the steps for the first update and everything seemed to work fine until I get to the point of flashing the firmware in the last step. I open the RKDevTool.exe and it says Found one MASKROM device. I click on the upgrade firmware button and then the firmware button as the instructions say. I open file update - 012324 but nothing shows up in the white box on the right of the screen. In the device manager it shows Rockusb device and driver is 5.12...here is a screenshot of what I am seeing.

There seems to just be some kind of font display issue between rkdevtool and your windows system. If you have another windows system, try that. If not, I'd personally just do it blind, and hit "Upgrade" button. You should immediately hear more beeps as the device gets reset and then you can wait another 2 or 3 minutes.

The nice thing about the 2600+ is the emulator firmware update gets done in MASKROM mode (a bare-metal bootloader baked into the chip) so you can't hard-brick it with an update. If it fails and the console has problems, you can repeat the process.

January 27

1 hour ago, Karl G said:

I've been troubleshooting a weird bug in my code, and I think I finally figured out that it's a corner-case bug, or undocumented limitation. It seems that although plotchars can accept more chars than 32, breaking it up into two DLs, it doesn't seem to handle it correctly if the numbers of chars is given in a variable. In my case, I was trying to plot 36 characters, and that worked fine if I hard-coded the number 36, but when 36 was in a variable, it only plotted 4 characters (the remainder after 32 I suppose).

It's an undocumented limitation, at least for now. The present width>32 support is very much a compile-time feature, that adds extra code to only the affected plotchar statement.

When I have my hands in the code next I'll see what I can do about expanding it to runtime. I'll also look at some of the other recent feature requests too!

January 26

1 hour ago, Kal said:

Dungeon stalker loads to demo mode only

I can’t start the game itself

This one works for me. Did you go down to the "start game" item in the menu first? It doesn't just start with a button press from the default menu position.

January 26

4 hours ago, Jerry0720 said:

hi Ben. Image 12324 would not work for me. It told me the file was corrupt. Can you help me please?

Try re-downloading the image, and make sure the file size on your computer is 72190424 bytes. Then try the update process again.

2 hours ago, jnagy13 said:

This one is giving me the same problem, only this time, under Other Devices, nothing says Unknown Device or Evercade? So I am unable to download this update. Has anyone else run into this issue or know another way to fix it?

Make sure you're following the directions carefully, as the console switches are different for the dumper part of the update vs the Emulator update. If you still don't see the device, try with other USB ports and/or cables. IIRC some people have issues with their (blue) usb-3 ports.

January 25

10 minutes ago, DEANJIMMY said:

Mine will be shipped soon and comes with a Hokey... could this make a difference?

It shouldn't. Pokey-capable homebrews are detected by the 2600+, and the pokey audio is emulated. This is also how the 2600+ can also play stuff like ym2151 music, even though the cart doesn't actually have that hardware.

January 25

1 hour ago, John Stamos Mullet said:

Is there a chance that the default smoothing filter from retroarch could be enabled or optional, so that things aren’t so blocky/hard edged pixels?

one of the things I like about running retroarch on an RPi is the smoothing it does.

or would that slow down the emulation too much?

Honestly we haven't looked at it, as this is the first request I've seen for it. CRT shaders are definitely out, but simple smoothing is supposed to be light on resources, so it might work.

If it's possible, I'm not even sure how the user would go about enabling it. From other threads, it seems people have definite feelings about having configuration menus on the 2600+.

January 25

9 hours ago, Mitch said:

Just curious if the composite smoothing fix works on 7800 Missing In Action? The crashing issue may be similar to 7800 Crossbow.

The composite smoothing is only enabled for Jinks and Tower Toppler. Since it blurs 320 pixels, like a real composite display, it's not worth degrading the display on other games that don't use artifacting.

MIA tends to be very crashy in emulation. The emulation in a7800 is pretty accurate as far as emulators go, but MIA crashes with it, even quicker than here. There's some kind of super-sensitive race condition in this game, involving the interrupts.

9 hours ago, Mitch said:

I seem to remember that Crossbow was shipped on two different cart boards. C300565 and C100339. Maybe one is dumping correctly and the other is not working?

Great point! I don't know how many other people will be willing to mess up their label to find out, but I'll start...

C300565 NTSC Crossbow works (RevEng)

January 24

My NTSC Crossbow is very much working.

There are two roms in a Crossbow cart, a small one that holds the data for the lowest bank at 4000, and a larger one that holds the data for the rest of the game. For some reason the 2600+ units belonging to @remowilliams and @Atari_Warlord aren't reading valid data from that small rom.

January 22

29 minutes ago, Trebor said:

As mentioned, it is based off of batari Basic in which RevEng co-developed with batari.

More details available here and here.

Thanks, but I think co-developed is too strong a word. I contributed some features and a ton of bug fixes, but bB existed for years before I got to it, and I wouldn't want to claim Fred's hard work. Bootstrapping bB and it's dev community was a grand bit of work - when he started the project, some people were saying that developing games on the 2600 with a basic-like language wasn't a viable approach, and the games would all just be variations on the same game.

44 minutes ago, JagChris said:

Is this basic made from scratch or based off of something like Atari 8-bit BASIC?

As the guys have said, 7800basic is based off of batari basic. batari basic is a minimal compiled basic implementation, close to the metal, without support for things that usually make basic both a performance and footprint pig. (e.g. flexible print statements with multiple types, flexible general string manipulation, etc.)

I used batari basic as a base for 7800basic for those same properties. It's one of the reasons that 7800basic games can shine as hard as assembly efforts.

January 21

Thanks for confirming, Walter!

A while back it was suggested that hitting INPTCTRL too many times at the game startup might trigger a hypothetical 7800 bug, but it doesn't look to be so. I didn't think this was an actual issue, but it's good to have it confirmed.

January 21

Just wanted to add an observation that the "silicon lottery" is a thing when chips are being pushed hard and temperatures rise to the point of thermal throttling. In those circumstances lower voltage will also allow you to run cooler and longer. (provided you still hit all of the logic levels)

I'm not saying thermal throttling is what's happening here, but it's one of the possible things that you'd expect to vary a bit between chips and also between usb chargers.

January 21

If anybody with a DF cart and a stock bios has a moment, could you please run the attached rom? I'd like to see if it runs fine and the cursor blinks at the end.

I'm asking for DF, because I really want the test to be pure, with a clean bios startup, and no other non-bios code hitting registers before this program.

7800locktest.a78

Thanks!

January 17

The padfdles are there and working. Have a look with https://hardwaretester.com/gamepad/

January 14

1 minute ago, Blinky said:

I'd say that's exactly whats missing

Ah, got you. :thumbsup:

January 14

I'm not quite sure it's right to say it's not USB-C standard complaint, so long as the CC/A5 line in the port has "legacy port" termination. Legacy devices connected to USB-C is part of the standard.

January 13

Thanks for the kind words! You're most welcome

January 13

7 hours ago, Bakunawa said:

Would it be possible to use this with fewer than 8 banks? Judging from stella's disassembly of the 32kMultikernel.bas.bin, it seems like it could work, but if we only need 16k for the game then there'd be quite a lot of wasted space.

Sure, I've attached a 16k version to the first post.

January 12

The usb c y cable or usb c hub that can deliver power is the usual solution to adding a thumbdrive to a device connected like this. I've done the same for a Google Chromecast+TV device that has the same power+otg type port.

But the y cables and hubs aren't things that most people have laying around. Worse, the cables is very hit and miss for this application. And then if we require new kernel modules to support this, you'll need to update the 2600+ firmware before you can use this solution to update the 2600+ firmware.

January 10

15 minutes ago, Dionoid said:

Is there a way to force a 7800 PAL game into 60Hz in firmware 1.1? Maybe that helps.

I don't think so. I believe the HDMI mode switching is done in the RA core.

4 minutes ago, Dionoid said:

I just reverted my 2600+ back to firmware 1.0 and my Galaga 7800 PAL is playing much smoother at 60Hz.

In 1.0 Galaga PAL was mistakenly flagged as NTSC in the dump, so you're running 60fps at 60hz.

January 10

43 minutes ago, Dionoid said:

When testing out the 7800 PAL games on the 1.1 firmware, I noticed my 2600+ has troubles keeping up with the emulation. For example in the game Galaga, when I move my ship left and right while the enemies fly into formation, the movement is stuttering and never smooth as on my original 7800. My HDMI TV is displaying at 50Hz, so it should be really smooth, but it isn't.

Also I'm having issues with performance of some 2600 games (e.g. EPYX California Games) which other testers don't have.

Do you have another HDMI set and/or cable to test with? I'm told that some TV sets aren't always faithful to the mode they're displaying, esp. with regard to 50Hz. Also, what mode is the TV showing the 50Hz display at?

7 hours ago, Dionoid said:

I also see that retroarch.cfg file, but I wonder how Stella-specific parameters like audio.preset are passed from RetroArch to Stella. Or maybe the Stella-specific parameters are compiled into the stella_libretro.so core itself? I couldn't find a specific config file for Stella inside the image.

No idea here either. I only see/access the prosystem core and dumper. RA is a black box to me.

January 9

7 minutes ago, AtariYMás009 said:

yeah, Don't listen to me, it's true, PAL games run at 50fps.
As for disabling V-sync, this produces graphical anomalies in the games, so I think it is not a solution at all.

It wasn't the suggested solution, just a suggested quick test. That's not a proper display for disabling vsync - worst case glitch should be screen tearing - so there's something in the retroarch+stella that isn't working correctly without vsync.

The actual remediation I suggested was to run the emulated 6502 clock faster, say by 1%. Since vsync was a bust, that would need to be tested instead.

January 9

32 minutes ago, Dionoid said:

I'm assuming the 2600+ is powerful enough to do emulation without frame dropping, but I could be wrong.

It likely is, but if vsync is enabled, the emulator will hang on to the last frame if the new one isn't ready. My guess here is that one frame of emulation plus the framebuffer draw is taking slightly more than 50hz, and one frame of emulation with the dropped framebuffer draw is taking slightly less. That might cause the alternating frame effect.

NTSC would have a bit more grace, as a 262 line display it's actually emulated at 59.92Hz, while modern panel displays are indeed 60Hz.

This could be verified by disabling vsync, if enabled. (I do see it enabled in the retroarch.cfg in the beta1.1 image) If that's right, it could be mitigated by running the pal emulation at a slightly higher clock.

January 7

Really not trying to pester here, but are you sure you got both parts of the update? (i.e. the dumper portion as well) The reason I ask, is screen corruption and slow music in the background was the exact symptom of the problem under original firmware. The problem was traced back to an issue with the dumper, and fixed there.

January 7

7800 PAL games are notorious for not being labelled as such.

Ms Pac Man PAL had a problem with the 2600+ factory 1.0 firmware, and didn't run. This was fixed for the 1.1 beta.

January 6

3 hours ago, MattelAquarius said:

Sorry, I've been away for quite awhile. I was looking to update the SD on my DragonFly cart, but noticed some issue between OM and AM ROM images. Should I not download the latest with Trebor's latest and greatest? Apologize for my confusion.

There's no issue with AM and OM images in the pack, and no reason to avoid updating to the latest pack. The Activision AM and OM roms deliver the exact same thing to the console in the end, and you should use whichever format your cart/emulator supports. (DF = OM)

Profiles

Forums

Blogs

Gallery

Events

Store

Posts posted by RevEng