kevtris

Guessing it was because this could break some 2600 games if they did. Also, the maria is hooked up to /IRQ on the CPU for scanline interrupts as far as I know. Granted they could've wire OR'd the two sources and had some kind of disable on /IRQ to prevent any IRQs from occurring but didn't do it because it'd cost money. Atari was so cheap they didn't even include sound except from the TIA so I can see why they didn't include IRQ functionality from RIOT. Timing would've been fine- /IRQ goes low until the CPU services it and manually clears it via the RIOT registers.

If I had to guess, I'd say that they disabled the lockout chip. The LED on the NES is connected to the reset line to the CPU. That's why it flashes when the lockout chip detects an error- it is resetting the and unresetting the CPU (hence the typical flashing). The reset button on the NES is the wrong polarity (active high) compared to reset on the CPU (active low), so it looks like someone connected the reset button to the /RESET line on the CPU, and grounded the other end of the reset button, and in the process disabled the LED (you will probably find some hacks on the little button/LED board). I made a mod similar to this back in the day because I didn't know you could just cut pin 4 of the lockout chip to disable it. If you remove that wire, you will find the reset button probably won't work any more. Fixing the LED is possible but I guess they figured it wasn't worth it.

First, thanks everyone for the kind words! Oh I'm around, I tend to stick on IRC. I don't make too many updates to my web page since it's a huge pain and I need to dump it and start from new. I have been working on various things and making lots of FPGA containing projects. My youtube channel (name: kevtris) has videos of the various FPGA doodads I have made in the last couple of years. I have not dropped out of the hobby by any means, but my methods have changed over the years. These days I tend to throw an FPGA at most problems that are somewhat large, or microcontrollers at the smaller problems. I kinda miss the discrete logic days, but only sometimes. I did make that NANDputer though- a computer completely out of NAND gates. That's on the blog (blog.kevtris.org). There's a few videos of it doing some basics on youtube also.

Yeah, I had issues finding information back in 1995 on the internet about it. I am not sure why it was so hard but I never did find a datasheet or much else. I actually reverse engineered how the coleco worked enough to program the game. I had no datasheets or other information to help me at the time. These days it's so much easier since information flows faster. Back when I was a kid in the 80's, getting information about electronics was extremely tough. My only conduit was a few books and magazines, and even the magazines weren't all that great. They would always give you that off-hand one liner that used to annoy me greatly. "x is beyond the scope of this article. if you want more information, go to your nearest technical library". I always was bemused about that; living in the sticks outside a small town, there were no such things as "technical libraries". When I started getting information from the internet, things accelerated into high gear and my abilities took off. (I have no "formal" college training in electronics or programming) Yes. it's still blinking away! I made that thing in 1994 or so and almost 20 years later it's still flashing away. Yeah I figured it had been. I was going to have high rez mode too, since I got all the RAM in the world on my board. You are right though, I tend to like to do it all myself. I'm not trying to be stuck up about it, but the main reason I am doing this is for fun and it's no fun if all the work's already been done for you. I like the investigation, implementation and final product and being able to say I did it all myself. The other reason is I tend to be extremely careful about it and leave no stone unturned; I want my simulations to be as close to the "real thing" as possible including internal bus and timing waveforms. Maybe a bit obsessive-compulsive but I strive for extreme accuracy. Aaah, good old sound. Always the last thing that gets emulated accurately. I am not sure why this is, other than it can be somewhat difficult to debug audio vs. video, though my usual method is recording the waveform and seeing what it looks like to suss out what happens. I tend to be very sensitive to bad sound on emulators, and can hear subtle issues and inaccuracies and it is pretty distracting. For the Bally I am going to poke around with an actual console maybe and work my magic on its sound chip like I did with the Odyssey^2. Thanks for the pdfs, gonna poke thru them. Re: off topic, sorry 'bout that, I will start another post maybe in the hardware forum about bally stuff when I get there or similar, hehe.

Thanks for that information! You guessed right on the resistors, going by the schematic that was just posted. A+ job on recreating the S2! I am going to do this for the Video Brain and the Arcadia 2001 since both are quite rare and expensive, not to mention cartridge availability issues. As to the S2, I was curious on a few of the details of how the chips were connected. I did a few minor modifications to put my FPGA in line with the actual circuit. Thanks for posting the schematics. it was helpful.

Thanks! I also have a blog up, which is blog.kevtris.org. I desperately need to update my website (kevtris.org) but it's such a huge time consuming task and I'm very poor at web design so it just kinda sits and languishes. Not for the lack of new stuff, but the lack of desire to do it. Be that as it may, I am going to try and keep pushing stuff to the blog since it's a bit easier to update that. Thanks for checking. I bet they just got a bunch of the service manuals from the various manufacturers and threw them together. Though I think RCA deliberately didn't give the schematics out for some reason. Either they thought "microcomputer repair" would be too tough for traditional TV repair men, or maybe they figured it'd give too much valuable information away to competitors (not likely), or that there just wasn't a schematic available in the first place. I'm very guilty of the latter- I make a PCB for something and don't have a schematic of how it connects- just a block diagram at best, and a few mini schematics of various parts. Yeah I was thinking about that a few minutes after I hit "post". I was going to add that too since I have a perfect cycle accurate Z80 already done (needed that for the sms/coleco/gg). Slapping on the bally frame buffer and "magic" controller chip didn't look too hard, I read the documentation awhile back. I thought it was pretty interesting, all told. I guess sound is still a minor issue with emulation? Re the Arcadia 2001, I almost need to buy some of the chips (or get one of the systems) in to do testing, because the documentation I found is quite lacking. While I have the documentation on the various chips, the documentation is extremely poor. Another job for the logic analyzer I think.

Nope, one didn't surface. I ended up sussing out how things were connected though, reading about the COSMAC ELF doodad, which is very very similar. The only part that I really would be interested in seeing a schematic of is the sound portion. It's just a 555 timer connected to a speaker, but it's got a wrinkle that makes the tone sound like a dying cat if it's left on for more than 50-100ms or so. There's a cap on pin 5 which makes the pitch down sweep a bit. sounds like "Beeeeoooooooo". I have the rest of the system done and functional with all existing software. Interesting that there IS a schematic of it kicking around then, and that such a book exists. Being published in 1978 I could see it being all pong consoles and the S2. This raises another interesting point to me- did those pong consoles fail so often that someone figured a book was a good idea? If I find a copy locally I might pick it up for the kick of seeing the guts of a bunch of old machines. re me getting around. I sure do. I finished the Studio 2 then made the Channel F, and while I wait for things (perf board, etc) to build my own videobrain, I'm working on FPGA'izing the Emerson Arcadia 2001. Currently at the "make a CPU in verilog" stage. The S2650 CPU is a very strange beast. Should have the CPU done in a day or two, then it will be on to video and audio and then bug fixin', then done. After that I should have most of the early underdog systems covered for my uber videogame console board. Next stop's probably going to be 7800 or lynx.

Welll, as I might've previously threatened, I took a few days to make an FPGA Channel F! (Channel FPGA if you will). After the Studio 2 FPGA I did earlier, I thought it'd be fun to try to simulate another underdog console. It took me about 4 days to get this one done, start to finish. Complete ground up everything. F8 CPU, 3853 SRAM interface, and video buffer. I cheated a little on the video buffer. The original buffer isn't terribly NTSC standards compliant. It uses 224 clocks per scanline instead of 228, and there's 264 scanlines instead of 262. Old 1970's TVs were fine with this, but capture cards and modern TVs probably don't take too kindly to that. I ended up with a 228 clock per scanline and 262 scanline frame to make it "NES like", which is good enough for most modern stuff. The audio circuitry was a direct clone, however, so pitch should be accurate. All games run perfectly as far as I can tell, and audio sounds like the various youtube videos I could find. This implemention runs on my standard FPGA board I made, along with all the other systems. Bottom of the post has dirty technical details for those that swing that way. Enough of that, on with the pictures! A good start- the G? selection screen. Built in game, hockey quadradooooooooooodle Alien Invaders Chess, requires extra RAM to function Maze (also needs extra ram, sitting on some IO ports. yep, got that) Pac-man homebrew. (title screen) In game. This game appears to be for a PAL Channel F maybe- the top and bottom get cut off a bit, but the game plays just fine. Technical details: Resource usage by entity: Cyclone EP3C25 FPGA F8 CPU: 723 LEs F3853 SRAM interface: 334 LEs framebuffer: 121 LEs generic SDRAM: 243 LEs This is approximately 6% of the FPGA's resources. (LE = logic element, the "currency" of FPGAs. my chip has 24624 LEs total) The F8 CPU was real "interesting" to simulate. I suspect the designers were under the influence when coming up with that particular bus state / 8 bit bus architecture. There's only a single level hardware stack for calls, no subtracts, jumps and calls corrupt the accumulator (loads PCH of new address into it for temp storage), and the slowness. dreadful slowness. The Channel F's frame buffer is slooow too. You can only write 1 new pixel every scanline, so a maximum of around 16Kpixels/second. This is why clearing the screen or updating too many things is dreadfully slow. Audio was straight forward but had a few wrinkles. If the sound is left on, it will go silent on its own after about 35ms. I noticed in some emulators the sound would continue long past the point it should've been silent because they did not implement this timeout. (It's done on the original hardware using a capacitor). I had a bunch of issues figuring out how the background select bits worked, and the 2102 SRAM on the Maze cart was connected. Some code disassembly helped with that. Overall, this system was extremely easy to simulate. The F8, while weird, ended up being pretty painless to implement and debug. Time taken was as follows: Tuseday - implement F8 CPU verilog, generate the bus state table. Wednesday - implement F3853 SRAM interface doodad (generates the address bus, and controls IO ports). Do some basic CPU testing Thursday - implement frame buffer. Do more CPU testing and debugging. CPU mostly debugged at this point Friday - no work Saturday - Fix final F8 bug (BR7 opcode). Implement XDC instruction- not listed on the datasheet. Demo cart 2 needs it. Add 2102 SRAM doodad. So about four days of work. I used signaltap (a built in "logic analyzer" in the Quartus 2 dev software) extensively to debug the system. Here's what that looks like for the curious. This is showing the various signals in the project. This is what happens at reset. The "Dbus" signal is the F8's data bus and the values on it, RST is reset, and ROMC is the 5 bit ROM control bus. "write" is the F8 write signal. These are a replica of the real chip's pin states. The capture starts when reset goes low to start operation (Yes my signals are all positive polarity even though the real chip's signals might not have been. standardization was used to keep things consistent).

I don't see any burning, just some flux and maybe the plating separating from the box. There's nothing there that'd generate heat anyways. Resoldering miiight help but I dunno. It will take a bunch of heat to get that hot enough to take some solder. It's possible it was a rosin joint from the factory (no solder wetting) too, but I suspect the plating has come off. Even if soldering doesn't work you can test by touching a wire from the metal box to the ground pads. A wire could be added if soldering to the pins is a no-go.

I tried them and they kinda work. the hardware is working properly but my monitor doesn't like the interlace. I checked over the thread on the biglist archive about it, and there's no reason why it shouldn't work. I have a theory why it isn't working right, and I think it miiight be the way the demo is coded. The symptom on my monitor is the TOP of the image *is* interlaced, while the bottom isn't. If the 1/2 scanline is only performed on ONE of the fields, it won't work right on this monitor. It would have a symptom similar to this. The top "slanted lines" part works fine, while the lower slanted lines don't (but you can see they are slightly offset). As the video is progressively drawn, the two fields converge. I have a video capture card, but for some reason I cannot get it to capture in 60fps mode, it will only do 30fps so you can only see one field. You can see this in that Supercharger demo unit video I made- the text in phaser patrol which uses 30Hz flicker so every other character of the message is shown. I tried virtualdub and VLC and both refuse to capture at 60fps or 30fps interlaced.

Yeppers, looks like that's the stock message in there now. When speakjets come from the <cough> "factory" they say "ready" on powerup. I can about figure out what set of codes were used for the powerup message.

Hehe thanks. Yes, I wanted to do this, but I don't think it's documented anywhere and the games haven't been dumped? I can easily add it if I only knew how! It can- if all it involves is adjusting the counter value for more than 262 scanlines. I do support hybrid modes though for the other consoles- PAL 60 directly and I can do PAL 50 using a framebuffer to do the 6:5 pulldown.

The "because it's for the hobby market" price. The chip is just a PIC18F1320 with the part number sanded off and a new one printed on. Checking the cost of the chips, if you buy 100 blanks they cost you $2.65 each on Digikey. Singles cost $4.10. You're paying for the code inside the chip more than the chip itself. Not bad, an 8-10x markup on the blanks. Of course you cannot just buy those microcontrollers and use them without the code, and the Speakjet parts are read protected. Speaking of the Speakjet, does the Atarivox replace the Speakjet default EEPROM data? A stock one stays "Ready" when you fire it up. I suspect this is disabled since it gets annoying each time the system is booted.

Yeppers, seems to work fine. Here's some pics: Title screen in game

Did anyone order an FPGA Studio 2? All this Studio 2 talk got me fired up to make an FPGA Studio 2. I started last friday and here it's friday morning and it's done. I tested all games and they work properly including those recent homebrews that were just posted. I guess that means I don't need to get a system in here to test and reverse engineer- I poked at the 1861 video chip datasheet and COSMAC ELF stuff to figure out the remaining bits. Almost forgot the specs. The CDP1802 CPU core was written from scratch in this time, along with the "pixie" videochip, too. Thanks to Paul Robson for documenting the BIOS code. I used this extensively along with Signaltap (in Quartus II) to debug the 1802 core and the 1861 video- it's pretty tricky timing getting the two to properly synch up. There were plenty of "funny" screens when the synchronization was bad. I have some new respect for the COSMAC ELF after seeing exactly how it works inside. So after saying that, here's some pictures. "Pattern" from the built in set of games "Bowling" again from the built in games "Pac-Man" homebrew

No because I'd have 12 or 13 cart slots on it by now. After 4 or 5 it gets ridiculous I think. I got keyboard/mouse support via USB though. I haven't implemented any computers on it yet for the simple of those two dirty words. D*** D****. they are very dirty words. Disk Drive. hehe. I will eventually give them a shot though. The 1541 is what stops me doing this C64. I actually have what amounts to a complete C64 already but the spectre of the 1541 drive scares me. I could do basic drive emulation I guess but then things like fast loaders won't work, and I would want them to.

That's how I made this. I got a whole lot of classic systems 100% done. I typically finish one completely before working on the next. As the pictures show, my 2600 is pretty much 100% as far as I can tell. All the "hard" stuff runs, and I include all mappers and atarivox and stuff. The only thing missing is harmony support which miiight some day get added, but I dunno. arm7 looks pretty "fun" if ya know what I mean :-) I been working on RCA Studio 2 for the FPGA lately. the 1802 CPU is done and the 1861 video's done. Someone's going to sell me a unit cheap it looks so that will let me finish it. I want to accurately emulate the sound which is somewhat tricky, and even though it's just a 555 timer, it's got a few wrinkles. The other issue is the exact hookup of the video chip, and exact timing and voltage levels of the video signal. These are the little things I try to accurately model. Meticulousness in simulation :-) There was some real good info posted the other day on the Studio 2 thread but unfortunately the service manual doesn't even have a schematic. drat.

You mean this? Not to toot my own horn too much but it exists and it's done! Including that boss bezel around the play area. (yeah it plays SMS also and Colecovision).

Yeah I saw that. it's basically a retrode like device attached to some SoC (system on a chip) kinda like the ras-pi. So you're running what amounts to emulators. Be that as it may, I have to wonder whose emulators they are using on there... if they are using existing ones or if they wrote their own (highly unlikely). This could explain why there's no VCS- they can't get enough performance out of their SoC to run it. This gets back to the whole thing that was mentioned earlier in this thread though, about integrating an SoC and a retrode. Well here's your chance :-) I will be interested to see peoples' tests on this thing to see how accurate it is (and possibly suss out what emulators they ported, if they ported existing ones, based on emulation issues). I still think this is a fairly poor way to go, but then again I'm biased towards FPGAs since I program 'em. hehe The SoC method has merit since it's rock bottom cheap and works for probably 95% of the games people wants to play. Kinda like a boom box vs. a hi-fi setup, I guess. Both play music and the boombox works for lots of people, but if you want something more, the FPGA covers it nicely I think. The real question then becomes: can the FPGA economically cover those that want more? I simply don't know.... but judging by how much money people pay for SD/CF card bearing cartridges (Powerpak for NES, super powerpak and others for SNES, etc) I think there might be.

Oh, creating the schematic from the hardware is the easy part and the time I spent searching for it, I could've traced the board out already. I eat and sleep board tracing and a board like the Studio 2 is a 2-3 hour project. I just need a board to poke with my meter :-)

Does anyone have a schematic for the Studio II? The just-posted service manual unfortunately doesn't have one, but instead has a block diagram with some notes on it. I got most an FPGA Studio II done (CPU + video) but there's some finer details like sound and exact hookups I'd like to get right and not have to guess or look at emulator sources. Exact cycle timing of the video chip is also something I wanted to suss out. I keep looking out for a unit on ebay but they seem to be hot right now. I just need a loose system that ideally works (but not required). carts and adapter/switchbox not needed. (In fact the first step's going to be AV modding it and adding a proper AC adapter input on there)

You got it. Here it is. I noticed some glitchiness on the rotofoils but I see that's normal since the masking wasn't 100% as specified in the thread. Ballblazer at startup after moving around a little. Good job on that, btw. Ballblazer's one of my favourite 7800 games He-Man mid transformation in-game Juno First title screen. Atarivox works good on this game. in-game (some multi-frame blurring thanks to the camera) Miner 2049er (not sure if this is the PAL version, don't think it is) Fatal Run PAL. Hence odd colours. I don't seem to have the NTSC version of the ROM but I think I read one exists. I just never poked around to find it. Well that's all I got right now. Any other suggestions for accuracy checking?

You got it. I tested the 2 or 3 ROM as well as your Circus Atariage demo and a bunch of others. Here's some stills. I can generate video but it's NTSC and this is RGB feeding direct into a monitor (Sony studio monitor to be exact). Pictures taken of the CRT with my camera on a tripod. Just quick and dirty. "2 or 3" demo "Circus Atariage" demo. I did test all positions and they work as expected. Next up is boulderdash playable demo (title screen) playscreen Cosmic Ark (note: camera's kinda slow so there's blurring. I tried several and all had it because of the fast motion.) Extra Terrestrials. I let it sit a bit while I fiddled with the camera so most of the screen filled up. The player positions work properly because I support rsynch. Pitfall 2 Video Life (and my head in the reflection!) those black lines are supposed to be there- they demarcate where the edges of the active area are Anteater. I read this used a somewhat unconventional positioning method for the score? writing to hmove during hblank or something? (insect legs blurred due to the camera) In Search of the Golden Skull Well that's all I got right now. Anything else anyone wants to see?

Thanks, yeah that's what I gathered. The part I was unsure about was there seems to be invisible walls in several places that the ET hits and it causes the screen to flash pink. They seem to stay in the same places game to game and are more or less randomly scattered around the screen. I didn't see the ET hit them in the youtube video but that might be because if you know where they are, they are easy to avoid.

Are there instructions for this game? I poked around the two websites linked in this thread and in the other bigger thread, but I could only find a zip of the ROM and pictures of an owners manual, but no actual instructions for playing the game. I got it working on my FPGA 2600 so I was wondering if a few things I saw were legit or not. I think it's right but would be nice to know for sure.