kevtris

I don't think I could handle it. I only work on hardware that gets released.

I already fixed that one a week or so ago, but I have not pushed the update yet. I fixed a few other audio issues as well, such as the continuous tone on Phantasy Star IV

As far as I can tell, here's two ways used to detect it in the games. The first is checking to see if the extra RAM exists. The other way is to write to some of the AY registers, and see if you can read back the values you wrote. Adding the AY should fix detection on everything else.

It's because the nt mini has 240 lines of picture information. 240*3 = 720. The msg and snt only output 224 lines (well most of the time, and for NTSC msg always). This means a 3x scale will give you 672 lines like mentioned above, thus you will get some letterboxing. You will have to use vertical interpolation if you wish to exactly fill the screen, or you could chop some rows of pixels off your monitor, I guess. (not responsible for loss of warranty, sanity or marriage). There's simply no way to exactly fill the screen with an integer scale vertically for this reason. It's a mathematical impossibility.

I think I found out how they are prototyping things and why it's taking so long... They are using Tortilla-Board technology. http://www.seattlerobotics.org/encoder/199804/breadbrd.html

Well they show a thing with a cart in it, but no footage of it running or anything.

You get proper TMS9918a palette on SG-1000 games.

They showed last year in august their dev board (complete with photoshipped pics to strip identifying information) running centipede. Of course we don't see anything but it running centipede- no OS or anything, so I suspect it was just windows like I did. The pictures do appear genuine- I set this board up just like they had, and got it to run. Compare the pictures in this article with pictures of my board. They are nearly identical. I still am not sure why that one guy in the last picture has his hand down the back of his pants... https://medium.com/@atarivcs/https-medium-com-atarivcs-behind-the-scenes-atari-vcs-mid-summer-hardware-summit-44cddc7e474c

I present to everyone... the Poly Ataco Mega Box VCS! It has a 64 bit AMD CPU! and umm, electrons, and chips and things! First, the M.2 SSD is installed. It has so much POWER that it sticks out past the end of the PCB, and it needs to be held down with a special retention device. Well crap. It has so much drively power that it wasn't bootable... Never fear, the SSD of doom will fix it right up! SATA to the rescue After the drive situation is sorted, I proceeded to install Windows 10, earm, Linux on it... Loading taco.exe.... Success! We have tacos! Oh yeah, it runs Millipede too. Seriously though, it is no joke. I did indeed get this AMD dev board to install windows onto the SATA drive via a USB stick, and loaded MAME onto it and ran Millipede. It took around 3-4 hours total, with about 1.5 hours spent futzing around with EDID hacking to fix my monitor's broken EDID so that I could get the entire image to display. (known problem with this old LCD). This shows that Atari did basically no work last year getting that board to run outside of installing an OS and an emulator. Proving that anyone can make an Ataribox prototype in their own home! One thing, I didn't manage to get into the BIOS so I could not make the M.2 bootable. This is a dev board so it might not be possible, or there's some weird way to do it. If anyone knows, I'd like to hear. I don't even know what BIOS it runs- it doesn't say on boot.

Did we reach 500 pages yet? Woot. yes, yes we did!

As far as I can tell, it's a newer version of the board they have. If you check their board pictures that they photoshopped you can barely see the '14" part of 2014 on it, right where it is on mine. My board was made in 2015 some time. Going by the sticker on the bottom, my board has this CPU on it: https://www.notebookcheck.net/AMD-FX-8800P-Notebook-Processor-Specifications-and-Benchmarks.144074.0.html If you look carefully at their pictures, there's a "35W" written in sharpie on it, so they are using a 35W tdp CPU, most likely. The CPU on my board is also 35W tdp. I suspect their board is slightly older, because it uses some through hole U shaped current sense resistors (these are the silver things that look like small binder clips), while my board has smaller, SMD ones. Now that I have this board, I can tell what they have plugged into it, and where. On one of the pictures there's an SSD or 2.5" harddrive laying next to the PCB on the bubble wrap. This is because that's where a board mounted SATA connector lives. You can see it peeking out from the edge of the board in my picture. We have no way to know what CPU they have mounted to that dev board, but it's soldered in. I think but haven't checked, that the pinout of many of the CPUs is the same, so you can perform an upgrade to your product by replacing the CPU and little else. I have not gotten the board to boot proper, because I am waiting on some RAM. It takes standard laptop style DIMMs, and there's two slots for same on the bottom. When I power it up (3.2A, 10V on the battery connector. yes... it has a complete charging circuit and battery connector!) and press the power button (on the left side, near the top) it gets stuck in a boot loop, with various numbers showing on the POST display (the 7-segs at the bottom left). A green LED flashes each loop, and a red LED lights continuously. There's another green LED that shows standby power is on. Hopefully I can get it to boot windows or something and run tempest 4K on it... proving anyone can make an Ataribox prototype! Yeah... I just need a clear jaguar case now to make it complete...

I will just leave this here for now...

It is going to rely on overdriving the SNES bus and force its values onto the data bus while the SPC is trying to also drive the bus. It's basically a bus conflict between the sd2snes and the SPC that the sd2snes probably will always win. I am not sure if it will work properly on every SNES, but it might if it can drive the bus harder than the SPC can on every rev of SNES. The reason it won't work on the snt is because the SPC signals are mainly internal and the FPGA will listen to its internal SPC data before external data. The sd2snes will put the SNES' SPC "to sleep" and then all audio will be done on the cartridge only, feeding the audio data into the cartridge audio input. Even though the internal SPC is put into an endless loop, it will still be outputting data to the bus when the SPC registers are read, since that's done in the hardware itself. The sd2snes will also output data at the same time, causing the bus conflict that it will win usually when games read the SPC registers. This also means the audio quality will be down to the cartridge now, since the internal SPC is no longer being used.

I had a third type of game gear I have not heard of being reported; It checked the copyright string like the TMSS one did, but didn't have the blue and white screen saying it was licensed or manufactured by sega. I only discovered this trying to run my own ROMs on it. My original launch system played it just fine, but the other GG didn't play it, and just black screened. Turns out it was checking for the TMR SEGA string.

I don't really remember much, I'm working 7 days a week, 10-12 hours a day for the last 3 years so I can't remember what I had for supper the day before. Sorry 'bout that. I am hoping to do some fixes to the ntm/snt this year, but I have to get through my current obligations before I can do that.

It depends on what FDS NSF rips you are using. If they are dirty rips, it won't run them. There can't be CLI or writes to the PPU in there. A lot of NSFs used to write to the PPU and turn NMIs on and things like that. As for IRQs from the port, maybe there's a hardware issue with the IRQ pin. I used the FDS RAM adapters (I have three different ones and three drives and all 6 worked) many times. I tried the FDS units on 20 different boards, as well and it worked on all of them.

The asm for all of the plugins is available in the copynes zip file on my website. I used tasm (telemark assembler) to assemble them. It's nothing too special or hard to make a plugin. Hacking the existing CNROM plugin would probably be the best solution. You could just force it to dump 16 banks all the time and then use a hex editor to trim it down if need be. http://kevtris.org/Projects/copynes/copyware.html

I guess it could be wasting 96K of the 128K PRG ROM, and only using 32K of it. The CHR might be similar- it could be using all 128K of it for CNROM duty- this would be 16 banks of 8K each. My CNROM dumper plugin only goes up to 32K though I think it is. So this is why you have missing graphics and such.

I don't think my MHROM dumps more than 64K of PRG/CHR, and that has 128K. So that's probably part of it. It could also be some kind of copy of the colordreams mapper (#11) - that has 8 bits nominally but you can do 4 since there's less ROM. I don't see any info/data on how the jumpers on the board work, but it can't be difficult. There's only a single '161, and nothing else, so it cannot be mapper 30. There's quite a few famicom-only '161 mapper boards that exist, but I am not sure right now what the mapper numbers are at the moment. A few minutes with a multimeter though should clear it up. Just trace the data lines from the PRG ROM to the '161, then the '161 to the upper address lines of the two ROMs and that will tell how it's wired and thus what mapper it is.

Because there's ambiguity in the 2600 mappers in use, some games require a special file extension to work. Otherwise it will just choose the most common mapper for that particular file size. The "atari 2600 release notes.txt" t tells you which extensions to use for the various mappers.

well they ain't gonna finish themselves. :-)

Yeah something happened to my MMC5 implementation when I ported it from the original FPGA NES prototype, to the nt mini. It used to work perfect for all the koei games, but after the port they had various issues. I am guessing the same thing is wrong with Sim City. When I get time I will try to fix it, but have been super busy doing the usual 7 days a week, 12 hour a day grind on the msg. Yep, I worked on xmas day all day too. No breaks or vacations for me.

nope, it's the same. It's just firmware x.x or greater.

no, the Ghostly unit has unique boot screens, you can only see them on that model.

cough cough. something something check the adopter list :-)