Page 4 of 5

Re: Getting into 8-bit NESdev with only 64-bit free software

Posted: Thu Jan 05, 2017 11:05 am
by freem
calima wrote:You cannot tell what a binary blob does, it is a security nightmare that could do anything from cryptolocking your files to installing Windows 10.
I really honestly hope that you built your own computer. Not just "putting together parts", but literally designing every single piece of hardware in there. Otherwise, you can't trust ANYTHING.

Re: Getting into 8-bit NESdev with only 64-bit free software

Posted: Thu Jan 05, 2017 11:33 am
by tokumaru
Yeah, I've heard that firmwares for example can be extremely dangerous...! :roll:

Re: Getting into 8-bit NESdev with only 64-bit free software

Posted: Mon Apr 10, 2017 9:09 am
by tepples
calima wrote:
tepples wrote:And is it more enjoyable to play-test a Super NES game at one-fourth speed with choppy sound on a free emulator or on a proprietary emulator at full speed with correct sound? Because that's the speed difference between free bsnes and proprietary NO$SNS on the Atom N450 in my laptop.
Is something wrong with snes9x or zsnes?
That depends on whether there's a debugger for Snes9x other than (a) Geiger's or (b) debugging the emulator as an indirect means of debugging your game.

Re: Getting into 8-bit NESdev with only 64-bit free software

Posted: Mon Apr 10, 2017 3:18 pm
by nicklausw
tepples wrote:A user wants to use an NES debugger on a 64-bit Linux PC but refuses to use any non-free software out of principle and refuses to install any 32-bit free software (such as FCEUX for Windows in Wine) out of fear that the 32-bit support libraries will take several gigabytes and "hav[ing] better use for that space".
If higan had debugging features, that would certainly fit the bill. Other than that wine seems to be the only option.

Why are FCEUX's debugging features only on win32, anyway? Do they use Visual Studio's C++ API features?

Re: Getting into 8-bit NESdev with only 64-bit free software

Posted: Mon Apr 10, 2017 3:25 pm
by Revenant
nicklausw wrote:Why are FCEUX's debugging features only on win32, anyway? Do they use Visual Studio's C++ API features?
All of the debugger GUI components are written exclusively using the Windows API.

Re: Getting into 8-bit NESdev with only 64-bit free software

Posted: Mon Apr 10, 2017 3:38 pm
by Myask
Which, if I recall my TAS-emulator history right, was because it was that way on Gens, from which they took said parts.

Re: Getting into 8-bit NESdev with only 64-bit free software

Posted: Tue Apr 11, 2017 11:21 am
by gauauu
Revenant wrote:
nicklausw wrote:Why are FCEUX's debugging features only on win32, anyway? Do they use Visual Studio's C++ API features?
All of the debugger GUI components are written exclusively using the Windows API.
I've been tempted more than once to take the time to start writing GTK versions of the debugging components. But after checking out the code and starting to dig through it, I always end up shrugging my shoulders and installing WINE. :roll:

Re: Getting into 8-bit NESdev with only 64-bit free software

Posted: Tue Apr 11, 2017 12:29 pm
by mikejmoffitt
calima wrote:You cannot tell what a binary blob does, it is a security nightmare that could do anything from cryptolocking your files to installing Windows 10.
If you are going to be so jailed by your own freedoms, then you'd be best off writing your own tools only.

Re: Getting into 8-bit NESdev with only 64-bit free software

Posted: Wed Apr 12, 2017 1:05 am
by calima
Incidentally, I'm typing this in my own web browser, while my own PDF reader and stock watching program are open :D More about the lacking functionality in existing programs, but hey.

From my POV, it's simply stupid to give trust where none is deserved. You're risking everything on your computer just to run a proprietary program. If that program really is worth all your data, and what can be done with it, then do use it.

Re: Getting into 8-bit NESdev with only 64-bit free software

Posted: Wed Apr 12, 2017 7:27 am
by tepples
calima wrote:You're risking everything on your computer just to run a proprietary program.
Which is why one runs it in a container that cannot read or write anything outside the container.

Re: Getting into 8-bit NESdev with only 64-bit free software

Posted: Wed Apr 12, 2017 10:37 am
by mikejmoffitt
calima wrote:You're risking everything on your computer just to run a proprietary program.
Are you running software as root? You may enjoy Jails.

Re: Getting into 8-bit NESdev with only 64-bit free software

Posted: Wed Apr 12, 2017 10:39 am
by calima
Indeed, at the cost of that container/VM.
Are you running software as root? You may enjoy Jails.
Of course not. But I'm aware bugs exist. The kernel I'm running on has easily hundreds of privilege escalation bugs, as well as bugs allowing one to escape a container.

Re: Getting into 8-bit NESdev with only 64-bit free software

Posted: Wed Apr 12, 2017 10:48 am
by tepples
You mentioned coreboot/libreboot earlier. A few PCs are compatible with libreboot. For everything else, the free operating system relies on proprietary firmware components, such as ACPI BIOS or UEFI. These act as the "container" for a free operating system, and like any other container, they may have defects that allow escalation.

Re: Getting into 8-bit NESdev with only 64-bit free software

Posted: Wed Apr 12, 2017 12:13 pm
by mikejmoffitt
tepples wrote:A few PCs are compatible with libreboot. For everything else, the free operating system relies on proprietary firmware components, such as ACPI BIOS or UEFI. These act as the "container" for a free operating system, and like any other container, they may have defects that allow escalation.
What about the small embedded programs and microkernels on the dozens of embedded devices that make a computer's peripherals work? I speak of peripherals like NICs, memory controllers, USB controllers, sound cards, et cetera. Where is the line of trust drawn, and with what justification?

Re: Getting into 8-bit NESdev with only 64-bit free software

Posted: Thu Apr 13, 2017 12:33 am
by calima
A regular NIC, sound card, etc does not have access to memory. Even a thoroughly malicious NIC is limited in what it can do.