kevtris

There once was a man in France, who had his hands down his pants. Some day they'll see our glowing LED, but without engineers, there's no chance. (sorry, I had to)

the board looks good. does it work is the question? (I don't know if they showed it running yet) I also don't know if it will fit in their original plastic box. There's no way they will reach consumers by the end of the year if it is not in production right this second. What's another 6-12 month delay at this point? haha. There's no cooliing solution shown either, but there are mounting holes for it.

I was very close to making the SNES 'refresh line' an option you could toggle on and off for lulz. Don't make me do it 🙂

thanks! looks pretty easy to implement.

xboard didn't exist at the time, so no. If you can find a spec and how it works it could be added at some point. melody games won't run because it'd need to emulate an ARM CPU

it's a unique mapper, and it's UNIF format on the ROMs.

I can vouch for the customs in Andorra being the weak link on shipping. My mega sd was stuck in Andorra customs for around 12 days, then it made the rest of the trip in 2 days. Quality is top notch on the box, cart, and PCB design.

The lynx is 8 bits, it uses a 65C02 as its CPU. I'd consider the TG-16 an 8 bit machine also, regardless of the marketing, because its CPU is also 8 bits. The intv is indeed a 16 bit CPU, however, even though the ROMs were usually 10 bits wide (but don't have to be). They got away with this, since there's 1024 opcodes (2^10). To represent 16 bit values there's an extension instruction. Interestingly, the ROMs must return 0's for the upper 6 bits, or else nothing will work properly.

I was talking about how the demo version won't let you proceed. I didn't find the RAM test stuff until later when I got the full version. Interestingly, most games clear RAM out to a known state (all 0's for example) so this isn't a problem. Only a poorly coded game or piece of software relies on the random RAM contents on initialization, because it cannot be relied upon to be in a usable, workable state when the software runs. I highlighted two other Coleco titles with a random number problem because of this earlier, and have found others on other systems. I consider a piece of software broken if changing ram contents causes the game to crash or fail in some way; because this can happen on real hardware by chance. There is no guarantee that say, my Coleco will have compatible RAM trash to your Coleco. Coleco could've used different manufacturers for the RAM in the systems depending on date of manufacture, or simply whatever they could buy cheapest that month for production. It's very possible some brands or revisions of RAM produce all 0's or FFs, or some other static pattern. I have some Motorola 8K SRAM chips that output 0xAA for every location on powerup. Granted, these are military rated parts, so this could be in their spec to prevent problems like this. (For those that are curious) I have actually researched RAM power up values for different kind of SRAMs; specifically 6116 and 6264 and 62256 style SRAMs (2K, 8K, and 32K static RAMs such that are found in many NES era to SNES/genesis/gameboy era systems and carts). Their powerup patterns tend to be repeating blocks of mostly 00 and FF, with the spacing of each run determined by manufacturer and chip size. While the data is mostly 00's the FF's, it is more complex and there will be plenty of single bit flips. These can be static, or change on every powerup, or only sometimes on subsequent powerups. The exact behavior is determined by voltage, temperature, the silicon process itself, and tiny imperfections. It is very possible that some RAMs have a lot of these single bit flips, and others will have very few. The latter will trigger on the first memory test as a failure and the game won't run. It is acceptable to hash the entire contents of RAM (or some portion of it) to generate some entropy for a random number generator, but that is the only valid use of checking uninitialized RAM. On several NES games, they will use two bytes for random number generation. They use whatever value was in RAM as the starting seed but are safe about it. If for some reason, the 16 bits hold 0, it will write a fixed seed into RAM so that the game will function even in this case. Coleco could've learned a thing or two about this for THEIR random number generator! They do not do the test. Also, reading uninitialized RAM is such a problem for current day developers, that many emulators will actually throw a warning if you do it. The easy solution is to simply clear RAM out when your code starts.

I have no reason to contact you about the game; it was having issues on my hardware but turns out it wasn't my hardware after all, and was the game. This means I have to debug it to find out why it happened. I got interested when things didn't add up, and fell down the rabbit hole of figuring out exactly why it didn't work. This is basically my job, to debug why videogames don't work on my hardware. As such, this was just another thing to debug and I approached it like any other game that had problems. That's when I discovered that the problem wasn't my fault. The rest of the procedure was documented on my blog. I am free to explain what I found during the course of the investigation; it was interesting and I figured others might want to see, too. All I did was pull the curtain back a little on what was lurking inside when I discovered the cause of the failure was something more than a garden variety core bug of some kind. I am not saying anyone is lying, but the functionality of those two checks is not in doubt. They are defacto designed to stop it running in certain places. There is literally no other purpose for it. Sending the program counter into the weeds using a bogus PUSH BC : RET leaves no doubt why it was there. This will do nothing but crash the CPU, since no valid address is ever put into BC, and the state of BC depends on what happens before. The DJNZ before that point though will keep it looping through the checking routine for quite awhile and may never actually break out of it. Obvious obfuscation was obvious at the very start of code too. Adding 0x2a to HL and pushing it onto the stack to build a jump address was pretty humorous, and was a giant screaming red flag that I was about to find something really good a bit farther in, and I sure wasn't disappointed. Adding something to HL before setting it up wasn't the smartest way to hide it- I just had to look at what the BIOS did after reset, which is load the start address into HL and jump to (HL). If you want to really learn how to obfuscate, I did a nice writeup on how I reverse engineered the Famicom "pirate original" Earthworm Jim 2 game. It used some truly insane things like strings of seemingly random code that actually manufactured critical routines in RAM, and writing to bank select registers in the "middle" of what looked like a function, but if the bankswitch doesn't take place the code will eventually crash. They hid the bankswitch register using mirrors of it and long strings of what looked like mapper initialization code which really didn't do anything of the sort. They also hid code in what looked like data tables. The link to that is here: http://blog.kevtris.org/blogfiles/EWJ2PROT.TXT

Come on, I wasn't born yesterday 🙂 I have been poking and reverse engineering games for a long time now since I have to implement hardware that runs said games. When things go wrong, I have to break out the disassembler and debug tools to find out why. I never saw the game fail in any way on emulators or my own FPGA Coleco hardware, other than not being able to progress past level 1 (on the demo) or before adding RAM data pattern initialization (on the full version). The game isn't doing anything tricky at all, and isn't stressing cycle accuracy or timing. Having two ROMs for PAL/NTSC makes perfect sense and is a good way to go when it comes to localization. The shielding is only there to keep the FCC happy and serves little to no electrical purpose outside of this. It is not required for operation and just keeps radiation from the digital logic from ripping up your neighbour's TV. (though honestly their TV would have to be pretty darn close. Maybe in an apartment? If so, I feel bad for my neighbors of years past for all the electronic stuff I ran without shielding!) The digital trash might leak into the RF if you're using RF to connect your Coleco to the TV. This was a problem on the 2600, but I ran my Coleco for years without the shielding on RF without an issue. (interesting and related ramble follows) One good thing is this highlights how important it is in emulators and FPGA systems to initialize RAM to a state similar to how uninitialized RAM manifests to get around these tests. As a bonus, at least on Coleco, it fixes two games that rely on randomness in RAM. These games are Fraction Fever (if RAM is zeroed before running, the game will continuously use 1/1 as the fraction). The other is Yolk's on You, which will appear to freeze when the game screen appears. This is because the "random" number generator is an LFSR, and since it's loaded with 0's, it will continue to generate 0. The game checks the random number for 0; if so it re-rolls but it keeps coming up 0. This makes the game hang, because the "random" number never deviates from 0. The fix in all cases is to load RAM with data that simulates the power-on state of a RAM chip.

This isn't very difficult to defeat using an FPGA, where you can monitor the address/data bus in real time and just siphon the data as it comes over. It's kind of like having a debugger that works on actual hardware. A better method would be to do some of the game logic inside the microcontroller, then it wouldn't be possible to reproduce without dumping the microcontroller. If it is protected, this would be fairly difficult and impossible to dump. You'd have to break out the nitric acid to expose the bare silicon then deprotect the micro and dump. This is well beyond most hobbyists and professionals. (no, this is beyond my capabilities too. at least at that point in time. this could change in the future)

I only did the RE work because it piqued my interest. As for a "memory check", if this is the case, why is this memory check not in the demo version of the game, but only in the full version? It is run first on the full version only. A memory check would a piece of code that writes i.e. 55 AA 55 AA then AA 55 AA 55 into RAM then reads it back to make sure the RAM is working properly. Your test is checking adjacent memory locations against themselves first, which is only good for detecting if the RAM contains 00 00 00 or FF FF FF (or some other static pattern), which are common emulator startup RAM patterns. This is literally not a test of RAM- no writes are ever performed. The second check is testing memory for 8 consecutive ASCII characters in RAM; this only has one function and that's to detect any text left over in the RAM when the game runs, such as file names left in by a flash cart. Again, nothing is ever written to, so it cannot be a RAM test by definition. I do not condone piracy in the slightest, especially of homebrew games. But, this whole thing was too good of a puzzle for me to pass up so I had to investigate what was going on and get to the bottom of it. As for the game working on "unmodified or non defective systems", this is not the case. The second memory test can fail on legitimate, nonmodified, non defective systems. There's a chance that someone's got an unlucky RAM chip in the system which just happens to return data in the 0x20-0x7b range for 8 consecutive bytes. There's 1K of RAM in the system, and it's checking 8 consecutive bytes. There's about a 1 in 2 chance that a particular RAM location has a value in that range (for a proper random distribution, the RAM pattern probably won't be truly random but it could be in favor of outside the range or in favor of in the range, depending on the chip). There's a 1/1024 chance that the RAM will have 8 consecutive bytes in a row in the ASCII range. Think of it as 8 coin flips in a row- each is a 1/2 chance, so if you flip 3 coins, there's a 1/8 chance of it coming up all heads. For 5 coins it's 1/32 chance, and so on. The whole 1K range is tested, so this means 1017 tests are being performed. (1024-7 = 1017). The 1017 tests done does not mean there are 1017 chances to come up snake eyes; it's significantly fewer, because the same bytes are being tested 8 times. I am no statistician, but I think it'd be around 128 actual chances in the 1K of RAM. This means you have a 1 in 8 chance of failure if the RAM data is evenly distributed. Since it isn't, the odds are going to be a bit less than that, maybe 1 in 50 to 1 in 100. Beware that this isn't absolute- every power on of the system, the RAM contents will be slightly different, so it can be possible that the game will crash on one system every time; another system never; and yet another system only sometimes. As for the 'modified systems not supported' part, this was just a red herring. People with the VRAM mod were having problems specifically. It was *not* the mod's fault- it was pin 13 no longer getting grounded on the cartridge. This is normally not connected on most cartridges, and was designed for a metal shield that sits over the ROM chips in the cart (similar to an atari 2600 cartridge), but apparently Coleco didn't have to implement it; the 2600 has a similar "shield ground" pin too. My theory on what happened is people with the RAM mod didn't reinstall the metal shielding, which left pin 13 floating on the cartridge slot, since it's only grounded through the shield and nowhere else. No other cartridges use pin 13, so there was no issue until this game came out. It's using pin 13 to detect if the system is 'modified' or not, but in actuality the cartridge copiers don't connect it. So this makes a fairly sure fire way of detecting a copier from a system. The only sticky wicket is removal of the shield. Of course if you just ground pin 13, it works fine, as people discovered. Mods or not. I was actually going to buy a cartridge of the game just so I could open it up and see for myself, but unfortunately it was not available to purchase on the website or on ebay so I didn't get a chance. I didn't write that blog post to drum up drama or anything, it was to document what I found and I found and to educate people on how protections like this are discovered, how they are reverse engineered, and to describe how they work in detail. I figured others would like to read up on it. To be clear: the ROM was never, ever available on that page or elsewhere on my website and never will be.

Yeah honestly, I'd rather the mister talk get its own thread instead of being in here.

Seeing how there's literally thousands of games that run on the msg, it's kind of hard to test all of them. A lot of testing was done, but it's inevitable that some slip through the cracks. This is the first I heard that Bubble Bobble doesn't work. I have been working on a super NT update for awhile actually. The super nt and mega sg cores are brand new, and were developed specifically for those products. It was only the nt mini cores that were already done, though they all required a lot of extra work to polish and debug them for the nt mini. It wasn't sacrificed... this is literally the first I heard it doesn't work. I put it on the bug list so I will look at it when I get a chance. As previously mentioned, with thousands and thousands of games to test, these things can happen.

That board lets you load it with EPROMs containing speech data, and the SPR-X emulates the SPR-016/SPR-128 speech ROMs. The former holds 2K of speech data, the latter holds 16K of speech data. The SPO256-012 chip used in the 'voice is custom programmed with the "mattel electronics presents", then numbers 0-9, "ten" "twenty" etc. All of that speech fits into its internal 2K of ROM. The chip on the board is an SPO256-AL2 which was a stock version of the chip loaded with allophones you could buy from places like Radio Shack. This board lets you develop your speech data that will be mask programmed into an SPO256, and then emulate it in circuit using that cable and plug. Interestingly, any SPO256 chip can be used to emulate any other by using the external ROM bus mode, so they took advantage of this. That board lets you stuff up to 32K bytes of data, which is far more than the chip can normally hold (2K), but I suspect it's designed to let you develop devices with more than 2K of ROM, like the Odyssey^2 "the voice". It has 16K of external speech ROMs to go with the 2K of internal ROM. The intv only has the 2K of built in ROM, though (I believe they called it "resrom"). Any other data had to be manually poked into a FIFO chip on the intellivoice to get it into the SPO256-012 that resides on it. I don't think you could do that with this dev board though; the serial speech ROM bus is being used by the FIFO.

I traced the pins of the MC1372 (which mainly conformed to the datasheet circuit, AFAIR) and switched the circuitry around to match the circuit above in the PDF. I didn't really keep notes because it was relatively simple. I didn't use an op-amp.

The good news is these and a lot of other tabletop VFD/LCD and handheld games are in MAME now. Also, it looks like the Internet Archive has a decent sized archive of these games you can play right in the browser. https://archive.org/details/handheldhistory I checked but these two games aren't in it for some reason; Alien Chase was the second VFD game I dumped the ROM for and vectored the VFD. I managed to dump the microcontroller in the star wars game, and we entered the hex data for it from the game's patent also since it's a different version (earlier than the release). These games are in MAME.

I think it'd have to be on BOTH ends of the 32X to function properly, because the 32X acts like a ROM gatekeeper since it can use the cartridge for its on nefarious purposes while shutting it off from the base system. It also apparently doesn't pass signals in certain address ranges either, which is why CD stuff can't work through it. (note this might not be 100%, just going off what I remember from my research).

The side expansion slot on the genesis is a subset of the cartridge connector. All the signals you need are on the cartridge connector. The expansion connector doesn't have all the address lines, and has a few extra enables, but since the cart slot contains all the address lines, these expansion slot unique signals can be easily recreated.

I have no dog in this fight, but I have been reading the thread all along. I think you should get a PR person to handle day to day interactions with the greater internet at large. You call some dissenting opinions "cyber-bullying", after posting the following personal attack a few pages back: Handling dissenting opinions others have is a valuable skill, and one course of action is to just mentally tune them out and ignore them. Another course of action is to read it, and try and see their point of view and move on (again without replying if need be). It doesn't help from a PR standpoint to berate someone for not fully agreeing with your entire vision and having questions about it. No one is saying the idea sucks or whatever, they are just bringing up doubts they might have about certain aspects. Be that as it may, moving on. I watched the October video and have read this thread, and there really just hasn't been a lot to go on in the way of hard information. We know it is a console. and it has 2 controllers. and comes in colours, and plays games. The video says it will be 2D only. I am guessing this was just an oversight, since even modern '2D' games tend to be made in 3D, which allows for rotation and scaling and easy priority. Of course the view is "flat" so it looks 2D, but behind the scenes it isn't. Limiting games to 2D only wouldn't be terribly smart in 2019 (or 2020). There hasn't been a peep about what kind of hardware this system will contain though. Maybe this is still up in the air, but I would think the hardware has to be nailed down pretty soon or else games won't be ready in time for ship, even this far out. Reading the thread, I got interested in some of the games mentioned so I did a little "youtube research" as it were. I chose four games: Horse Racing, Skiing, Microsurgeon, and Horseshoes. What I found surprised me some actually. note: The following is simply what I found, and is not an endorsement or comparison or anything. I was simply curious about the modern landscape for these particular game genres. Knowledge is power. No links will be given of course, since I am just going over what I found. For Skiing, there's several free to play 3D skiing games that look absolutely amazing. One particular game, "Snow" is free to play, but charges extra for extra game modes. Not ideal, but the base game is free. As for Horse Racing, this field seems pretty crowded. Some of these games look absolutely amazing, with high quality 3D modeling. (examples are Pharlap, and Rival Stars Horse Racing. The latter is a mobile game). My friend bought 'Surgery Simulator' on steam for around $5 a few years ago, and it seemed to be a pretty hilarious. In one game, you have to perform an operation in the back of a moving ambulance, complete with it shifting around as it makes evasive maneuvers. You can even drop things out the back of the ambulance (like the patient's brain!) and it will go rolling off down the road. While not exactly a "Microsurgeon" clone, I think it was a pretty fun take on a surgery game. And finally, horseshoes. I only found an arcade version that used a trackball, but someone did indeed make it. I wasn't sure I'd find a videogame version of it. This is not considered modern though, having come out in 1990 and released by Taito. Speaking of games, so far the only games I know about for the Amico are ports of existing games. These are going to be 25% of the games for it, but so far those have been 100% of the announced and talked about titles. (not that I am complaining, mind you, just pointing that out). So that's my honest look at things as I see it with the information given at the current time. When more hard information comes out eventually, my take on it will likewise update. (btw , you can hit the little + next to reply on each post to do a multiquote reply and reply to more than 1 post at a time.)

This functionality seems buggy. If I am on the last page of a thread, and it's showing say, 3 posts, and hit 'back", it does the scroll to the top thing but only shows 3 posts from the previous page, instead of the entire page of posts. I have to hit refresh to make it display properly. I also noticed that the "click on the last page of a thread thread and go to the last unread post" functionality is broken too, UNLESS you click a thread title on a sub-page link. then it works. Otherwise, it just takes you to the top of the last page and you have to manually scroll down to find the unread posts. If I click a thread title, it just starts on the first page. I noticed that quotations were broken after the upgrade for all posts before the upgrade day, but checking now that seems to be fixed now.

a necropost on a 17 year old thread... that's gotta be some kind of a record.

That thing atari showed off is what's called a 'hand model'. I guess because they make them by hand. Usually these are used for trade shows and for mechanical fit/testing purposes. The "PCB" is most likely a piece of aluminum milled to the thickness of a circuit board, with holes drilled in it for major parts like connectors that will stick through the walls of the enclosure. The original prototype with the LEDs on it are pretty typical of a trade show quality hand model. The LEDs most likely are being run off batteries inside it to give an idea what the finished product will look like. Why atari would show off a clear hand model that is obvious phoney baloney is anyone's guess. It's not much more than a more expensive version of the Retro VGS' cardboard PCB with parts glued on. They stepped things up to aluminum. Hand models like that aren't even terribly expensive- at the very most, a few grand for a really elaborate one like the clear one they showed off. Again, these things are designed for checking fit and form, and not function. The guys that make these things are really good at it, and can replicate the look of injection molded plastic using various finishes on a 3D printed base. They can even do things like make custom connectors that work if you want to put something inside or connect it via a wire to your proper job hardware prototype.

I tested the reprint. I tested it on all three major models of CD unit, too. a US model 1 and 2, and a japanese CD unit (which looks like a model 1). The cart I have is indeed the reprint, and I opened it up to confirm it's legit. It is, and has the schmoo covering the chips like other pictures I've seen.