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

You can talk about almost anything that you want to on this board.

Moderator: Moderators

User avatar
mikejmoffitt
Posts: 1348
Joined: Sun May 27, 2012 8:43 pm

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

Post by mikejmoffitt » Thu Apr 13, 2017 1:54 am

calima wrote:A regular NIC, sound card, etc does not have access to memory. Even a thoroughly malicious NIC is limited in what it can do.
A NIC has access to certain particularly important data - that which enters and exits the computer through it.

You have no idea how the Intel Management Engine in most intel CPUs from the last ten years interacts with any of these peripherals.

User avatar
TmEE
Posts: 712
Joined: Wed Feb 13, 2008 9:10 am
Location: Estonia, Rapla city (50 and 60Hz compatible :P)
Contact:

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

Post by TmEE » Thu Apr 13, 2017 2:12 am

All PCI(-E) cards can be bus masters and they usually are. Typical NIC writes packets to main RAM itself without CPU involement, driver just tells where exactly (and if that NIC happens to have a boot ROM it can do stuff before OS and after BIOS). Same deal with sound cards when they are recording aswell as any USB3 devices (USB2 and 1.1 are polled only, they cannot dump data whereever they want on their own). If the hardware wants it can read or write any part of the system without any involvement of CPU or knowledge on OS side that something happened.

calima
Posts: 999
Joined: Tue Oct 06, 2015 10:16 am

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

Post by calima » Thu Apr 13, 2017 11:08 am

mikejmoffitt wrote:You have no idea how the Intel Management Engine in most intel CPUs from the last ten years interacts with any of these peripherals.
No, I'm quite familiar with that. That's why I don't buy or recommend any such Intel CPUs.

The IOMMU prevents PCI cards reading arbitrary RAM, and I don't have USB 3 hardware.

tepples
Posts: 21710
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

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

Post by tepples » Thu Apr 13, 2017 11:50 am

When were Intel Management Engine and VT-d (Intel's name for IOMMU functionality) introduced? Which was before the other?

User avatar
mikejmoffitt
Posts: 1348
Joined: Sun May 27, 2012 8:43 pm

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

Post by mikejmoffitt » Thu Apr 13, 2017 12:06 pm

calima wrote:
mikejmoffitt wrote:You have no idea how the Intel Management Engine in most intel CPUs from the last ten years interacts with any of these peripherals.
No, I'm quite familiar with that. That's why I don't buy or recommend any such Intel CPUs.

The IOMMU prevents PCI cards reading arbitrary RAM, and I don't have USB 3 hardware.
You can't be familiar with it because nobody is. I'm not questioning that you know about it, just what precisely it is up to.

I don't know which CPUs this leaves you with. AMD has had similar bits in their processors since 2013, and you have to go back quite far to get an Intel machine without it.

You can sidestep almost all of these issues with a computer isolated from any networking, allowing it to communicate only over thoroughly observable I/O at the user's request. But of course, that's absolutely silly when we're talking about developing NES games.

tepples
Posts: 21710
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

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

Post by tepples » Thu Apr 13, 2017 1:09 pm

Until fairly recently, Nintendo used to require that authorized developers have a dedicated office not attached to a residence. I wonder if an air-gapped workstation used to be required. I know it's at least possible because I first tried NESdev back in 1999 with an air-gapped workstation, with an Iomega Zip drive as the only way to get files on and off the thing. I downloaded DJGPP, Allegro 3, x816, NESticle (yes, there was a time when it was the cutting-edge NES debugger), and other tools to a Zip disk on one dial-up-connected computer (a Mac), moved the drive to another computer (a 486 PC), and installed them on the other computer's HDD.

But the root of all this was unwillingness to install (free) Wine to run (free) FCEUX for Windows because of hundreds of MB of (free) i386 libraries it would pull in.

User avatar
rainwarrior
Posts: 7639
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

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

Post by rainwarrior » Thu Apr 13, 2017 1:13 pm

tepples wrote:I wonder if an air-gapped workstation used to be required.
It was not.

User avatar
Myask
Posts: 965
Joined: Sat Jul 12, 2014 3:04 pm

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

Post by Myask » Thu Apr 13, 2017 6:19 pm

TmEE wrote:All PCI(-E) cards can be bus masters and they usually are. Typical NIC writes packets to main RAM itself without CPU involement, driver just tells where exactly (and if that NIC happens to have a boot ROM it can do stuff before OS and after BIOS). Same deal with sound cards when they are recording aswell as any USB3 devices (USB2 and 1.1 are polled only, they cannot dump data whereever they want on their own). If the hardware wants it can read or write any part of the system without any involvement of CPU or knowledge on OS side that something happened.
So, like what the NES expansion port (or SNES expansion port) could do.

Though, the NES lacks address bus and the SNES lacks full address bus, though one can still run code to modify anywhere.

User avatar
TmEE
Posts: 712
Joined: Wed Feb 13, 2008 9:10 am
Location: Estonia, Rapla city (50 and 60Hz compatible :P)
Contact:

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

Post by TmEE » Thu Apr 13, 2017 7:54 pm

Not quite, because you cannot do bus mastering on NES or SNES, the CPU or some part of hardware in the console must do the transaction, and that's fully under CPU control. A Bus master can do anything to the console whenever it wants. US/EU Master System (but not Mark III or JP Master System) have means to do bus mastering, technically you can make a game cart that takes bus from the CPU and runs the entire game off the cart with CPU perpetually frozen pretty much controlling all the hardware in the console as it pleases. That's partially what one game I'm working on does, it uses a small MCU to do DMAs and few other things to fully realize the VRAM bandwidth that the machine has (Z80 can only use up about 10% of what is available).

I'm not yet familiar enough with the IOMMU mechanisms that are present in x86 world to comment more deeply, but from first glance they're primarly for OS side of things to allow virtualisation with hardware assist, with some restrictions on hardware side of things to work, aka not universal. AMD spec seems to be superior to that of Intel's, but for now I will stop digging, I don't have time to read though 500 pages of material, especially since it doesn't benefit the work I'm supposed to be doing right now lol.

User avatar
Myask
Posts: 965
Joined: Sat Jul 12, 2014 3:04 pm

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

Post by Myask » Thu Apr 13, 2017 9:20 pm

You have access to the databus. Inject a converging-clockslide-jump to un-mapped addresses (as sort of in the linked example), and/or continue driving the lines over whatever else is trying to use them.

User avatar
TmEE
Posts: 712
Joined: Wed Feb 13, 2008 9:10 am
Location: Estonia, Rapla city (50 and 60Hz compatible :P)
Contact:

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

Post by TmEE » Fri Apr 14, 2017 12:16 am

Since you cannot tristate the host bus on will (I cannot see any such signal on the schematics), you only cause a bus fight which is harmful to both sides. To do it without harm you got to control the enable signal going to the cart so that you can disable cart on the relevant addresses and supply your own data...

calima
Posts: 999
Joined: Tue Oct 06, 2015 10:16 am

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

Post by calima » Fri Apr 14, 2017 12:40 am

mikejmoffitt wrote:I don't know which CPUs this leaves you with. AMD has had similar bits in their processors since 2013, and you have to go back quite far to get an Intel machine without it.
Currently running a Phenom 2 from 2010. Considering getting the Pinebook when it ships, and would have gotten the Raptor if its price had been more in my budget.

tepples
Posts: 21710
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

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

Post by tepples » Wed Apr 18, 2018 4:44 pm

calima wrote:If I know what happens next in a movie, book, or game, it is no longer fun to me. I acknowledge I'm in a minority in this position.
For the record, the opposite end of the spectrum is this Slashdot user.

As for the topic: Nowadays, if you're willing to install 64-bit Mono, Mesen should be mature enough. The problem comes when you branch out to Game Boy, where one best of breed debugging emulator (BGB) is proprietary, and the other best of breed debugging emulator (SameBoy) is Java-trapped because it relies on parts of Cocoa (macOS API) that GNUstep hasn't replicated, such as audio.

tepples
Posts: 21710
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

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

Post by tepples » Tue Jun 25, 2019 11:59 am

Joe wrote:There's also the x32 ABI, which gives you the advantages of 64-bit mode in a 32-bit address space.
Good for embedded, where everything can be rebuilt for x32. Apple Watch uses an analogous ABI with 32-bit pointers on AArch64. But it's not quite as suitable for desktop because with x32 you need three sets of libraries. Assuming everything whose developers are willing to build and test on x32 is x32, you still need the x86-64 libraries for x86-64-only applications and the x86 libraries for x86-only applications. Its failure to catch on is part of why Linux kernel developers had begun to consider dropping it by December 2018.
Sik wrote:what is Canonical's idea about what to do with 32-bit programs, wrap them in a VM automatically or expect users to run their own VM?
Canonical expects each application's publisher to offer a snap with the application and the 32-bit core libraries. (A snap is a container, which is lighter weight than a full-on VM.) If your application's publisher went out of business in 2010, too bad.
tepples wrote:Run only 64-bit Windows programs, which would require ensuring that FCEUX (Win32) and FamiTracker are 64-bit clean
Discussion of this with respect to FCEUX continues in the thread: Catalina Wine Killer

With respect to FamiTracker: jimbo1qaz nyanpasu64 has announced in the FamiTracker Discord server an intent to resurrect cpow's port of FamiTracker to Qt.

With respect to bgb, a proprietary Game Boy debugger: beware is providing experimental Windows x64 builds.
calima wrote:bugs allowing one to escape a container.
Such bugs exist in ZSNES. A Super NES program using one of the coprocessors can launch native i386 code using an out-of-bounds DMA.

Post Reply