| Near |
Posted on 18-12-27, 00:22 in amethyst (text editor)
|
|
Burned-out Genius Developer
Post: #1 of 51 Since: 10-30-18 Last post: 1421 days Last view: 1344 days |
I wrote a text editor, for various reasons. It's like VS code, Sublime, or Atom I guess, if any of those programs were written in ~500 lines of code and ran natively on FreeBSD. GTK only (so Linux and BSD, or if you're adventurous enough ... potentially Windows or macOS.) You must run "make install" for now, since I don't have a fallback for missing config files yet. The default mimetypes.bml file is missing a huge amount of extensions, but I'll get to them in time. Three modes of operations: amethyst -- open an empty new document amethyst filename -- open an existing document with no tree view amethyst directory -- open a folder and allow recursive access to all subfiles/subfolders The editor itself has a text mode and a simple hex mode (currently read-only though, hiro::HexEdit needs more work.) No real features beyond save, save all, find (forward and backward search), and goto (line.) Has a safeguard against files being modified externally when you go to save changes, tells you if it can't save for some reason, detects read-only files, and has a snazzy close dialog to choose which still-modified files you want to save or not. You can't (currently) do things like rescan folders in directory mode to find new/deleted files/folders, rename files, create/delete files/folders, spawn new documents with the editor already open, save an open file as a different filename (that creates too many gotchas like saving it as a different file that's already open in the editor), use the search function all that well in hex mode (strings that wrap on 16-byte boundaries will miss), do a find+replace, etc. But probably in the future I'll add more stuff. I'd appreciate if anyone able to run it could do some testing. My own testing shows it works fine, but I'm obviously a bit worried that if I missed something serious, it could mess up my source code or worse, which would be extremely bad. If you can't run it, peeking at the source for issues would be helpful, too. I'm only planning to develop this to the extent I want to use it. Idea being, it's 500 lines, feel free to add any features you want yourself. Thanks in advance! https://files.byuu.org/releases/amethyst_v1.tar.xz  |
| Near |
Posted on 18-12-27, 00:24 in LineEdit widget on Windows bug [hiro]
|
|
Burned-out Genius Developer
Post: #2 of 51 Since: 10-30-18 Last post: 1421 days Last view: 1344 days |
Fixed, thank you! |
| Near |
Posted on 18-12-27, 00:29 in Higan decided to not work ever again
|
|
Burned-out Genius Developer
Post: #3 of 51 Since: 10-30-18 Last post: 1421 days Last view: 1344 days |
The idea of disabling the drivers was to prevent higan/bsnes getting stuck in a crash loop, where every time you start it, things crash. I didn't consider the use case of someone dismissing the warning about the crash on the next run. I will update it to display the warning every time the program is run and all three driver types are still set to "None". |
| Near |
Posted on 19-01-04, 20:03 in amethyst (text editor) (revision 1)
|
|
Burned-out Genius Developer
Post: #4 of 51 Since: 10-30-18 Last post: 1421 days Last view: 1344 days |
> I'm a tad disappointed that the hiro/source-edit widget hasn't yet made its way over to non-gtk implementations yet The thing is, it uses GtkSourceView. That gives us: * color syntax highlighting based on a set of rules * color scheme selection * highlight current line * visual brace matching * show line numbers on the left Plus a bunch of other things I don't want. Plus, if I were willing to use GTK3 only, GtkSourceView3 can highlight a phrase everywhere it appears, which is *incredibly useful* for searching. Unfortunately, I have no idea how they ad-hoc implemented that on gedit 2 before GtkSourceView2 even supported it. We could create a kind of light-weight custom SourceEdit control with Windows and Qt, but in the end it'd basically just be a TextEdit control, and if we're lucky, with line numbers. Not very nice. But even line numbers I'm not sure how we could really do those. The basic idea is we'd need a widget container with two widgets, but then how do we keep the two widgets in perfect scrolled synchronization with one another with only a single scroll bar? Hard problem. I don't want to approach it like HexEdit, where I actually put the addresses in the text itself, because that complicates the hell out of everything, including that you can't select multiple lines of text without pulling in the offsets (fine for a hex editor, bad for source code.) > The much bigger issue that took me ages to figure out was why the program was then always closing immediately. Ah, sorry, Talarubi recently found the same issue. I don't have a non-hacky fix for it yet. C++ object construction ordering is a trainwreck. |
| Near |
Posted on 19-01-09, 00:06 in Sneeze9x
|
|
Burned-out Genius Developer
Post: #5 of 51 Since: 10-30-18 Last post: 1421 days Last view: 1344 days |
> it's even better than bzsnes Irony is dead. > I can fix the SA-1 speed at a slight speed penalty > There, the SA1 speed is fixed, so half this patch is unneeded. True SA-1 timing is *insane*. Cycle-accurate isn't enough, you have to synchronize every clock tick. And even then I only got things about 90% correct (much better than the 10% we were at before.) Granted, the test cases are extremely unlikely to ever occur in real games. Still, if you want some fun, try out https://github.com/VitorVilela7/SnesSpeedTest ^-^ |
| Near |
Posted on 19-01-15, 05:20 in bSNES beta
|
|
Burned-out Genius Developer
Post: #6 of 51 Since: 10-30-18 Last post: 1421 days Last view: 1344 days |
There's a few things holding up bsnes v107. The main thing is needing to rewrite and unify the configuration of all cores: * what are the hardware characteristics? (PCB ID, CPU/PPU revision#, DAC highpass/lowpass settings, etc) * what are the supported optional features? (interframe blending, color blending, scanlines, etc) * what speed hacks are available? (scanline renderer, audio decimation, etc) * what can be modified at run-time, and what has to wait until a power-cycle / system reload? * how do we expose all of the above to the higan and bsnes GUIs? Then there's also the fear I have of finalizing the manifest format. At this point, I'm thinking I'll pass on setting it in stone for v107 again. Most bsnes users will be using ROM files anyway, so that's fine. Finally, I still need to have the logos redone to not be so embossed. Hard to find people who are good at vector art for that. ... > This is the "GameBoy Z80" thing all over again. It's the complete opposite. The Sharp SM83 (GB CPU core) is a somewhat stripped down Z80. The TLCS900H is like, "what if we took the Z80, and added the complexity of a 68K on top of it, and then built in timers and micro DMA into the core itself? Oh and just for fun, what if we marked about 40 things as undefined behavior, and didn't provide publicly available instruction cycle timings? Oh yeah, and SPARC register windows sound like a good idea, let's add those too, only let's make it even more complicated." Then as the cherry on top, there's the fun of supporting a CPU that was never used in anything else, so there's nothing out there like krom's 65816 tests, or zexall/zexsms, or ARMwrestler, to refine your new core. And it's obscure enough that 100% of NGPC emulators are all based on NeoPop, which was never good to begin with. |
| Near |
Posted on 19-01-16, 05:01 in Sneeze9x (revision 1)
|
|
Burned-out Genius Developer
Post: #7 of 51 Since: 10-30-18 Last post: 1421 days Last view: 1344 days |
> By "fixed", I meant it's significantly more accurate than before, which simply ran 5 SA1 opcodes for every S-CPU one, and fixes the Super Mario World SA1 hack that they're talking about. Not going to bother with bus conflict for now, which is the major speed hit. That sounds like a major improvement, indeed. Thanks so much for your continued hard work! :D |
| Near |
Posted on 19-01-27, 00:32 in higan: interface redesign (revision 1)
|
|
Burned-out Genius Developer
Post: #8 of 51 Since: 10-30-18 Last post: 1421 days Last view: 1344 days |
Originally, bsnes started as a simple emulator: you start the game by passing it a filename. Ah, the good old days. Then support was added for games with cartridges slots on the games themselves: Super Game Boy, BS-X Satellaview, and the dual-slotted Sufami Turbo. A few awkward attempts at custom load dialogs to select all of the carts for these didn't go well, but it worked. Then I added more systems, and to plan for a future with Game Genies and Sonic & Knuckles lock-on carts, bsnes/higan moved to its until recent design: you now start the emulator with no games specified, and the core will ask the GUI to load games as it needs them. This will allow you to chain an infinite recursion of stacking Game Genies if you wanted. It does have the downside that if you load a Sufami Turbo game, you get forcefully prompted for two sub-slots after it, but it worked. Then I added more systems, and now we have the MSX and Neo Geo Pocket. The MSX has two cartridge slots, one of which can be used for audio or RAM expansions. It would be very unfortunate to open two load dialogs in a row on every MSX game. The MSX also has peripherals that can be added to load games from floppy disks or from cassette tapes. The Neo Geo Pocket (and others, like the Sega CD) can be booted with no game inserted (well, the Sega CD BIOS acts like a game cartridge through the expansion port), which leads you to a BIOS. Not pleasant to have to dismiss load dialogs to get to that. We will need to be able to dynamically swap and flip floppy disks, dynamically swap CD-ROMs, etc. So in an effort to support all possible use cases, I need to revise the higan interface yet again. The key observation is that the GUI doesn't know about every possible variation. And some cases are recursive (Sonic & Knuckles & Knuckles & Knuckles & Knuckles & Knuckles ...), and other cases are based on what you've connected to the expansion ports. While we're at it, let's also consider that controllers will be getting more complicated in the future: there are devices like the Super Turbo File that contains multiple save RAM files. The BS-X Satellaview base unit apparently has a CompactFlash-like slot on it. Many CD-based systems have memory cards, and spawning one memory card for every game would limit us on games that want you to migrate your saved data to a sequel. The Voicer-kun needs CD-ROMs. So we need peripherals that also have storage capabilities (eg folders) now. So my new proposal is that we expose everything that can be plugged in as a recursive array. Kind of like an enumeration API that isn't a pain in the ass to use. There will be a base result for an initial state of a system: an SNES will always have two controller ports, one expansion port, and one cartridge port. And as you connect devices, by scanning for ports again, the new ports will be exposed. The GUI can allow us to build our own configurations out of the base hardware plus a pre-configured layout of connected peripherals. For instance, the Sega Genesis with a Sega CD on the expansion port, which will save us from having to load the Sega CD BIOS every time. The Famicom with the Famicom Disk System on the cartridge port, which will save us from having to load the FDS BIOS every time. The Super Game Boy is another good example. But from this configuration interface, the GUI is not going to be able to know that if you select the Super Game Boy, that will expose a new Game Boy cartridge port to the SNES hardware. Because the GUI is generic, and we learn about the slot on the Super Game Boy through parsing the cartridge manifest inside the emulation core. In practice, this doesn't feel like an extreme limitation. You won't be able to make a configuration that direct-boots into Link's Awakening on a Super Game Boy. To allow that functionality, we would have to return to manifests, and the issues they caused with new versions revising their syntax. So then we have a systems configuration dialog where we can build out configurations. Upon loading one, it will initialize the interface for the given hardware, and connect/disconnect all the default cartridges/peripherals as requested. I cannot think of a design that puts all of this into the menu bar. If we tried to make stacking cartridges recursive it would quickly get overwhelming. No, we need a new window with a tree view, that dynamically updates as things are plugged into and disconnected from the various ports (and sub-ports ...) Once we have things connected as we want, we will have to start and stop the system power. It isn't going to be fun to use, but it's worth noting that we've essentially modeled the real world here. Whoops. I might very well have two Sega Genesis units: a model 1 with great sound, and a model 2 that I connect a Sega CD to. Then I have an MSX machine that has a floppy disk drive attached to it. The systems configuration dialog allows us to represent multiple machines in whatever configurations we want. One we decide to play a real machine, we have to plug in our controllers and cartridges. And indeed, the emulator is the same here. After everything is connected, we can turn the power on and off. And while the system is running, every connected device can be forcefully disconnected, even if that means triggering a stop-and-swap behavior. Yep, we can emulate that too, now. And if we want to take all of this to its true logical conclusion, we can only allow the configuration of system profiles from the main higan window. In this way, we can plug in cartridge, etc and dynamically have the ports enumerate, and we can populate even sub-slots. While we're doing this, we can't allow the configuration of a different system, because higan cheats a bit and reuses global objects for the Game Boy core inside the SNES core for Super Game Boy support. But that's really, truly not any kind of serious problem. Once a system is configured and started, then the systems configuration dialog would be disabled, and all the default connections, including sub-ports, would all be connected. Then we can customize that by adding the games we want to play, and finally turning it all on. We can even force the creation of folders for each connected peripheral (say, a game pad), and dump in key assignment configuration files there. This would allow you to model having multiple physical SNES controllers to your multiple physical Xbox 360 controllers. Because that state is going to have to go somewhere. It's definitely going to be massively more complex than any stand-alone emulators. But hey, that's why we have bsnes now, too. The one emulator people actually want to use that I made will continue to work like Snes9X, and higan can spiral into infinite complexity as an experimental project, down to simulating write limits on flash media, battery life on handhelds, etc. Why not? A quick peek at this is here: https://twitter.com/byuu_san/status/1089111967980126208 But you'll notice the controller/expansion ports aren't there. That's because I use writing these posts to think about these things, and I come up with new ideas while doing so. Anyway, I think I have my design now. I'll spend some time designing how I want things to look, and then start on yet another new higan GUI. |
| Near |
Posted on 19-01-27, 17:00 in higan: interface redesign (revision 2)
|
|
Burned-out Genius Developer
Post: #9 of 51 Since: 10-30-18 Last post: 1421 days Last view: 1344 days |
Screwtape, interesting ... pretty similar to what I put into the latest WIP, hopefully you'll like it then ^-^; My takeaway was that I was trying to join two distinct concepts into one before: SNES { Port1=Gamepad, Port2=Gamepad, Cart=SGB ( Cart=Zelda DX) ) A better modeling needed for a tree-view hierarchy is to separate connectors from things connected to them. The SNES has an expansion port even if something isn't plugged into it. And a Satellaview is a Satellaview even if it's not plugged into an expansion port. As for what to call the base system and all things connected to connectors, well ... I had to go with object. It could be a console, a handheld, a controller, a cartridge, a floppy disk, a CD-ROM ... literally anything. So any name I chose other than object (or thing) would not cover all cases. The system needs to be an object visible in the hierarchy, because for handhelds (and some consoles), the system itself is a type of controller. At least, it has inputs. Be it a Game Boy D-pad and buttons, or a Master System pause button. And really, the reset button should be here too. The only thing every system in existence will have to have is a power switch ... and even then, it's not always a switch. It's a button on the Neo Geo Pocket that sends games an interrupt. Currently, I'm grappling with how to handle the spiraling complexity. If everything is an object (the system, controllers, etc), then everything should get a folder for data. That's a good thing ... a Super Turbo File needs a place to write its save games to. But how do we design this? You can't (yet) download controllers from the internet :P Including a bunch of pre-made folders seems silly. So when connecting an object to a connector, we'll evaluate the context of: which system is this? Ask the system what connects to that port ... a list of controller strings, or a folder. If it's the controller type, then we'd open a different kind of dialog, a controller manager, that lets you create a compatible controller folder or use an existing one. The complexity is straight up horrifying, I know, but ... if we only have one fixed controller in one fixed place, then we limit ourselves a bit. You might want different Super Turbo File devices for different games. You might want to use this same kind of UI as a memory card manager. And once we've gone this far ... we have to ask ourselves about games themselves, too ... do we really want games in ~/Emulation/<system name>? We have a chance here to do away with a really ugly kludge: game folder extensions. What if the connectors were configurable in the same way the connected devices were? What if I said, "the SNES cartridge connector here will look in this directory for games"? Or what if I said, "the SGB cart port will look in the GB (gray) + GB (black) directories, but not the GB (clear) directory"? We could then allow people to have a different configuration entry for "SNES RPGs" and "SNES Shmups" (but not "RPGs for all systems"), if they wanted to, of course. Connectors could also include filters for the scanned directories. "SNES PAL" would have a filter for "*(PAL)*", for instance. This is so far beyond anything I've ever planned ._. |
| Near |
Posted on 19-01-27, 22:53 in higan: interface redesign (revision 1)
|
|
Burned-out Genius Developer
Post: #10 of 51 Since: 10-30-18 Last post: 1421 days Last view: 1344 days |
A CD-ROM disc isn't a device. Now granted you don't technically "connect" a CD to a CD drive, but it's at least a reasonable thing to say. |
| Near |
Posted on 19-01-30, 05:11 in higan: interface redesign (revision 1)
|
|
Burned-out Genius Developer
Post: #11 of 51 Since: 10-30-18 Last post: 1421 days Last view: 1344 days |
I understand we can do things like: * show Game Boy Color games for the regular Game Boy * show WonderSwan Color games for the regular WonderSwan * show Neo Geo Pocket Color games for the regular Neo Geo Pocket And we should definitely allow it to be possible if someone really wants that, but ... 99% of the time, it's just going to be visual clutter. If we give people the option to add both GB + GB (black), then they can add GB (clear) or just decide that it's probably better to run GB (black) carts on GBC (I would. SGB features aren't impressive enough to lose GBC coloring.) |
| Near |
Posted on 19-02-18, 07:50 in board.byuu.org has been closed; byuu.org upgraded
|
|
Burned-out Genius Developer
Post: #12 of 51 Since: 10-30-18 Last post: 1421 days Last view: 1344 days |
So obviously, it officially closed a few months back, but I was keeping up an archive of it for existing members to login and see. Sorry for the short notice on closing it. Kawa has graciously set up a mirror of it here, so the posts aren't lost at least. I'm now saving the money and only running a single server instance, which I don't want to put PHP, MySQL, or phpBB onto. So for now, the board is closed. On the bright side, byuu.org has been updated. I fixed OCSP stapling, and I now use TLS v1.3. Regrettably my version of nginx doesn't support 0-RTT, but TLS v1.3 at least allows four trips instead of six for HTTPS connections, so the site should be snappier now, given the mandatory HTTPS. I also renewed the TLS certificate a little early, just to get it out of the way (eg I didn't realize the private SSL key I had saved was for my self-signing cert, and I just deleted the instance that had the last copy of it, so I had no choice :P) Anyway, obviously that accelerates the need for me to make some kind of WIP release / bug tracking setup, so ... I guess I'll get on that here soon. |
| Near |
Posted on 19-02-21, 22:19 in Retroarch's (controller) interface is an bad abstraction
|
|
Burned-out Genius Developer
Post: #13 of 51 Since: 10-30-18 Last post: 1421 days Last view: 1344 days |
> The more cores you have (>100 with RetroArch, thousands with MAME), the heavier the burden of option 2. The weirder the input scheme of the core, the heavier the burden of option 1. A key point to consider is, how many of the emulated systems are people actually using? higan currently has 22 unique hardware devices supported. Of them, I imagine 90% of people only use the SNES core. The other 10% probably use no more than three or four systems. I doubt a single person is playing ColecoVision + SNES + Benesse Pocket Challenge V2 games in higan. My focus is on allowing absolutely anything to be emulated with higan. I'm intending to have things like solar sensors, barcode scanners (eg Barcode Battler), card scanners (eg eReader), toy scanners (eg Soul Dollz), save devices (eg Super Turbo File), etc supported. Trying to map all of this to a universal controller is never going to work. |
| Near |
Posted on 19-02-23, 12:14 in BSNES Beta question
|
|
Burned-out Genius Developer
Post: #14 of 51 Since: 10-30-18 Last post: 1421 days Last view: 1344 days |
I should have updated the missing firmware popups to say the DSP-n variant names instead of the architecture names. Too late now though ... |
| Near |
Posted on 19-02-25, 05:45 in Nintendo Switch emulation is now among us
|
|
Burned-out Genius Developer
Post: #15 of 51 Since: 10-30-18 Last post: 1421 days Last view: 1344 days |
> Do you remember that time? Access to games was much more limited. Games disappeared from store shelves shortly after they were released and the only way to get them was through mail-in companies like Funco. That isn't still the case? I even pre-ordered Riviera on PSP from Gamestop, and the store employee opened the only copy they received -- mine -- before I arrived to pick it up. And there was only one Gamestop I could find in Columbus, OH with a sealed copy of Yggdra Union PSP. After that, I just started buying games online. |
| Near |
Posted on 19-02-27, 13:47 in bsnes v107 released
|
|
Burned-out Genius Developer
Post: #16 of 51 Since: 10-30-18 Last post: 1421 days Last view: 1344 days |
The reason it took this long is because I didn't have a 4K monitor until very recently. I now own a really, really, really bad, low-quality one that manages 144dpi (150%.) Good enough I guess. To get rid of the blur in bsnes, choose Settings->Video Shader->None, and don't use the DirectDraw driver because that one lacks the ability to control the magnification filter. I just confirmed it works here. HiDPI in bsnes, well ... the core is undergoing a very large rewrite, and I will need to shift focus away to other things for a while, so v108 is a very distant thing. If bsnes v107 were to catch on, and there's significant demand for HiDPI, then I can backport it to a v107.1 or something release. In the mean time, I didn't notice any performance penalty from using "System (Enhanced)" mode with bsnes here. A few text labels clipped a bit, but it was entirely usable. |
| Near |
Posted on 19-03-12, 09:42 in Announcing the bsnes history kit (revision 2)
|
|
Burned-out Genius Developer
Post: #17 of 51 Since: 10-30-18 Last post: 1421 days Last view: 1344 days |
You're amazing. Always humbled by your support and interest. Thank you for doing this. > As for the direction of this site in the future... given that I now have a domain, I want to present a more professional appearance. So for now, I've removed the rants section. History sure repeats itself, doesn't it? > Maybe I'll move that over to my LiveJournal page and get some use out of that. I never posted anything at all to it. > Due to the robots.txt file on byuu.org, IA's scrapes of it aren't public. No, I specifically asked archive.org to exclude my domain and Twitter accounts. I also blackholed archive.org and archive.is from accessing my domain. > That day would come someday, but not then. My guess is we'll reach a 50/50 split when Windows drops 32-bit binary support, Dosbox is abandoned and stops working on the latest Windows, and so you have to run ZSNES inside Dosbox inside Virtualbox. > I just asked Derrick and he said he doesn't. No one back then anticipated it'd ever be useful to keep these things ... Even today, the interest still surprises me, honestly speaking ^^; |
| Near |
Posted on 19-03-17, 01:47 in Announcing the bsnes history kit
|
|
Burned-out Genius Developer
Post: #18 of 51 Since: 10-30-18 Last post: 1421 days Last view: 1344 days |
For whatever it's worth, I've no qualms if you wanna just extract the RARs, and recompress them with XZ or whatever. Worst case, throw the RAR inside of the new XZ archive that ends up on Git if people really desperately want a bit-for-bit identical historical copy. |
| Near |
Posted on 19-03-23, 14:27 in Announcing the bsnes history kit
|
|
Burned-out Genius Developer
Post: #19 of 51 Since: 10-30-18 Last post: 1421 days Last view: 1344 days |
As a preservationist, I never would have imagined people spending so much time trying to preserve my own stuff. You live long enough, and you get to experience everything from both sides, I guess. > it was archived for posterity and deleted from the database Oooooh, is that what happened to it? That would be super fun to read through again. > Just looking at the thread myself, the earliest version mentioned is v011 Odd, I'm pretty sure I had been posting most revisions publicly somewhere. Especially since v005 onward was archived by tukuyomi. It's a shame Deathlike had to go and delete all my posts from the Snes9X phpBB2 forum. There was a lot of interesting technical content that probably would have helped any future SNES emudevs fix common problems with new emulators. Those kinds of notes are always the first thing I go to when I implement new systems myself. > but the ZBoard famously uses the Hermes theme I guess whoever did the upgrade really liked the theme on my board. |
| Near |
Posted on 19-04-01, 12:55 in SNES DSP initialization and Magical Drop
|
|
Burned-out Genius Developer
Post: #20 of 51 Since: 10-30-18 Last post: 1421 days Last view: 1344 days |
About 18 months ago, Jonas Quinn found the cause of Magical Drop hanging after a game over. It was determined that the game reads from DSP registers that it hasn't yet initialized, and if the values are zero, it will hang. This was the original attempt at a fix: https://gitlab.com/higan/higan/commit/1ca4609079bf8a8ec21171238da344048daf0de1 This caused various regressions because it turns out that the underlying 128 bytes of DSP memory isn't directly used for the internal registers. So while the internal registers *do* get initialized, the memory does not. We ended up having to back the change out due to the design of blargg's DSP that links the registers and memory as one and the same. And due to the loss of the spc_dsp6 test ROM, that had to go on hold. Recently, spc_dsp6 was found, and today, I finally got around to working on this. I've now updated higan's DSP core to separate the two concepts completely. No internal register is directly referenced through the RAM anymore, but the cases where the internal processing updates registers will fall through and also update the underlying RAM for read-out as well. spc_dsp6 ended up being absolutely essential. Saved us from four extremely difficult regressions. ... So now on to the main point: unfortunately I didn't keep a copy of the old board myself, and the development forum posts weren't made public. So, does anyone have a copy of the dev forum post about this issue? And if not, then ... any chance Jonas Quinn is around and still remembers this after 18 months? Heheh ^^; I want to know which game regressed with the old register randomization, and the technical details of which registers we found to assuredly be internally initialized. |
[Your ad here? Why not!]