Jump to content

DirtyHairy

Members
  • Posts

    926
  • Joined

  • Last visited

Everything posted by DirtyHairy

  1. I agree. There are no hmove pulses in the visible part of the scanline here. Generally speaking, to the best of my knowledge this doesn't happen for a sufficiently late hmove strobe --- afaik (and as we have implemented it in Stella), hmove clocks only happen at hclock values that are a multiple four, and for a late hmove the first clock will coincide with the first clock of hblank, although the "extended scanline" is triggered before (and subsequently reset when hblank starts). Only if the "late" hmove happens sufficiently early there are pulses during the visible part of the scanline, and the result will be influenced by the phase difference Eckhard describes. If I play with the parameters of hmove, (delay, shift the pulse times, etc.) I totally break the kernel (the systematic positioning change smears it over the whole screen), so I think something else is happening here. In addition, we also support changing the "phase" of the movement pulses as Eckhard describes in Stella, and doing so does not affect the moviecart kernel.
  2. I can only repeat myself: enabling PGO (profile guided optimisation) will easily give a 20% - 30% speedup. Moving from Retroarch to plain Stella would probably give another sizeable boost. The R77 has a similar CPU, and while we had to switch to PGO and do some optimisations to Stella for ARM games, CPU usage for non-ARM games was more like 60% to 80% (instead of 70% to 100%). With PGO and plain Stella the R77 hovers around 100% for very heavy ARM games (like Mappy) and much lower for everything else.
  3. Source code needs to be compiled into an executable before you can run it. I am afraid that, unless you know how to build from source, you'll have to wait for a new release. What OS are you using? Sorry, didn't read closely enough, you said .exe, so evidently Windows 😏
  4. Yeah, looks the same on Stella. If you look at the code, you find It uses the value at D9 to index into a table and loads the playfield from there. The players are positioned such that the flags align exactly with the playfield pixels, so any value in d9 will load something that covers a subset of those four flags.
  5. Fixed in git, thanks for discovering and reporting this issue 😏 The technical details (if anybody cares): The code positions P1 and P0 next to each other for the 48 pixel trick on the right side (to display the fuel gauge) and briefly switches to two copies, wide spacing to get an additional decode for both players on the left side (and display 16 pixels worth of lives). The players always show all four flags, and the playfield is used to cover the lives that have been lost, starting from the left. P0 comes first, and it so happens that NUSIZ is written in the same cycle in which the draw is decoded. As we always process the tick before the writes we miss this decode, and P0 is never displayed. Other explanations are possible, but we have very hard constraints from https://github.com/stella-emu/stella/issues/63 and other testcases that work correctly, and the solution that I settled arguably has the smallest possible fallout on all the other tests and testcases that probe those edge cases.
  6. OK, that explains the issues. The original firmware for the R77 uses an ancient version of Stella 3.x. Starting with version 4 has a new and much more accurate TIA core, the old core has multiple accuracy issues.
  7. Is this the official R77 firmware, or the Stella 6 community build? The community build should now have any graphical glitches.
  8. I strongly agree 😏 Either emulation is running too slow, or something is wrong with the timing (I still haven't fully ditched my theory of something being wrong with the oscillator).
  9. @karri The dump is in /tmp, although I don't remember the filename. I suppose you can hex encode and then copy it over the serial line by doing something along the lines "sleep 10; dd if=/tmp/rom.bin.b64 of=/dev/stdout bs=1" on the device and then starting a corresponding dd on your computer while the the terminal is running --- then you can check the contents of the dump.
  10. Sure, in the sense that people would use the same web page to first flash the Linux image, and then flash the dumper.
  11. You can use the proprietary Rockchip flashing tool ("update_tool") for Linux to flash from a Linux VM. On Apple Silicon you can either use a Rosetta 2 enabled VM, or you use qemu-user. Not very convenient, but it works fine *and* it works on Apple Silicon. The elegant solution would be to create a JavaScript flasher that uses WebUSB and runs in Chrome. There are reverse engineered OS tools for flashing, and the protocol looks straightforward. Unfortunately, I couldn't get flashing with those to work, so some reverse engineering would be required to get that working, but I think it is definitely doable.
  12. Good point. My chip just got slightly warm, not hot, so I didn't consider it, but I didn't check the temperature systematically. Maybe someone who has issues should open their device and check the temperature with their fingers.
  13. Yeah, pretty much certain. I couldn't find this for the 3128, but this is from another Rockchip "datasheet" (or what they like to call the public documents that they publish 😏) for a different SOC. Most likely the scheme is similar, and the diverging number is just die lot and production date.
  14. I think this is very unlikely. If this were the reason, that corruption would have to affect several people, all in the same sector, and the damage would have to be just in the right place to corrupt the config and not damage anything else.
  15. If it is really only speed, then yes --- there should be about 30% performance improvement out there to pick up just by compiling with PGO. I still find it slightly mysterious though why some devices seem to act up and others don't.
  16. I already suspected that 0R would be OK, but electronics is not my strong side... 😛 Please post if this works, then I might add a slot too --- I am interested 😏
  17. So that confirms that DRAM should be identical. And if it were faulty it should just fail randomly, not be slower. The CPUs are identical, too, and at least comparing my clock to @remowilliams's showed a clock drift of 0.01% - 0.02%, so the oscillator is not the issue either. I think the only way to find out if and what differs between the consoles that behave well and those that don't is connecting a "good" and a "bad" one to the same equipment, validate the issue and then look for differences from the command line (like CPU usage and clock).
  18. The firmware is currently not set up to support this. Judging from dmesg, MMC support is compiled in, and a card should appear as a device node in /dev. Won't do you any good though out of the box, as the firmware wouldn't even automount it. Would be interesting to see whether it works though, if you have a slot soldered. You can attach a serial terminal via the UART header and log in to check --- root password is "deeplay". EDIT: looking at my board at the slot header I see that a bunch of passives is missing below it, probably resistors. Don't think soldering a slot will do much good without adding those as well.
  19. You can use a Linux VM that supports USB forwarding to run Rockchip's proprietary update_tool. Version 2.1 (i.e. form here) works find. On Apple Silicon you either need a VM that has x64 support via Rosetta 2 (Parallels supports this, and UTM supposedly too, although I haven't tried UTM), or you can use qemu-user to run the binary.
  20. Yeah, it is really remarkable how different games can cause very different CPU load because they light up different code paths. Stella's current TIA core is very different from the previous core though, so the specifics will vary.
  21. What a bizarre statement to make. You are aware, aren't you, that we and @Thomas Jentzsch in particular have been in contact with Plaion long before the release, and that @Thomas Jentzsch in particular has done his best to give feedback during the development cycle in order to ensure that the 2600+ would be as capable as possible, feedback that has become part of the very product you are using. And, after the release, here we (and again, @Thomas Jentzsch much more than me) are, trying to help improve the compatibility and usability of the device, without earning a dime from its sales. And as far as ARM cartridges are concerned: they put additional hardware on the cartridge bus, just as developers did back in the day, within the limits technology permitted them. They are still just a way of extending the VCS through the cartridge slot, just as it was designed, and the developer is still subject to the same limitations that the TIA imposes on video and sound. There isn't an issue with emulation either, and there are at least three emulators that handle them fine --- those games are even developed using emulation! That the 2600+ currently cannot handle them is not a design choice to be more "true", but just a result of decisions taken during development to balance cost and features. It is shortcoming that was a conscious decision, and acknowledging a shortcoming is not critique, but the necessary first step to fixing it (as Plaion are trying do). I am not supposed to do anything, this is a hobby. We invest countless hours of our spare time into developing software that we make available to others at zero cost, and it is bizarre to derive some kind of obligation to offer support from that, even more for a product that we didn't make or earn from. If are looking for anyone who is "supposed" to support the product you bought, look at Atari. And, to get a reality check, please check the Stella bugtracker in order to gauge the level of support that we (and @Thomas Jentzsch in particular) offer. Besides, the current shortcomings of the 2600+ are not related to Stella, but to the dumping hardware, the choice of SOC and the way that Stella has been set up on the device. And, notice something? We are actively trying to help overcome those.
  22. At this point the most widely used "extra chips" are DPC (used in Pitfall II and a few homebrews), DPC+ (an extension of DPC that runs on Melody and Harmony boards and exposes the ARM for running code) and CDF / CDFJ (which run on Melody and Harmony and is more geared to ARM-enhanced games). Apart from that, the only other ones that I know of are Chetiry (which runs on Harmony and uses a special API for music) and a few programs by @ZackAttack that run on the Uno cart and that use the ARM to generate 6502 code on the fly.
  23. I just checked, I can't find it on my laptop, but there's a thread on the forums where @SpiceWare uploaded the source:
  24. 😆 I think the makefile only uses 128.bin and catharsis theory --- the 128 char demo is very taxing on Stella's ARM core, and the last screen of catharsis theory is surprisingly heavy, too, as it lights up a few expensive code paths in the TIA core. I experimented with those for the R77, and the resulting profile worked well, so we kept them.
×
×
  • Create New...