Search the Community

Welll, some people seemed interested in my FPGA Videogame doodad that I presented in the RVGS thread and it was suggested I make a post about it, how it works, and what it does. I still don't have immediate plans for selling it, but if there's enough interest, that could change. I will attempt to explain what it is, how it works, and what a sellable version of it would entail, so let's go! First off, nearly ANYTHING is possible. The main problem is going to be how much money people will be willing to pay, and how long they will want to wait for it to be finished. A target price of around $250 is probably going to be a reasonable value, but ideally I'd love to be able to do it for $200ish. What I have right now: At this point in time, I have 17 system cores complete, and pretty much ready to go. This means that the core is done and runs all the games I can throw at it flawlessly. I have spent a lot of time debugging and testing these cores to make sure they are the highest possible quality and completeness. Yes, I spent the time to run every single game available to me on them- many many many times to make sure any changes I made didn't break something. To obtain the absolute highest level of quality and compatibility, I have made special test fixtures, hardware, and test ROMs for every system, and used my 200 channel logic analyzer to inspect exactly what goes on to get exact cycle accuracy on everything. Developing a new 8 bit level core takes around 1-3 months of work depending on how complicated it is. Sometimes it was even faster than this, and sometimes longer. I figure I could get SNES or Genesis going in a 4-6 month time frame and maybe a few more months to debug it to a decent level of operation. There have been several hardware prototypes created up to this point to develop and test my cores and other related things, and I now have full command of the HDMI interface at 1080p/60fps. I have moved onto HDMI now as my interface of choice due to the high quality of today's flat panel monitors and TVs. Analog is still possible, and I can support this too. I still think that some kind of add-on for analog will be the best way to go instead of integrated it into the system due to the cost of the video DACs ($4-5 each) and the connectors ($1 or more each in some cases). By leaving off analog, I can save probably $40-50 by eliminating all the chips and hardware for them. The other option is simply to get rid of analog all together and not support it at all. Would many people be sad to see analog go? Personally I wouldn't, but this is not really my decision- I want to make something the USERS would like. Right now, I am playing games by loading ROMs in through a computer interface for debug, but ideally they would be loaded off of SD cards. I like the idea of cartridge adapters, but the problem with them is making the plastic enclosure for it. Making the adapters themselves is fairly straight forward and easy, and the games would literally be running off the cartridge itself- it would NOT be just another Retron 5 that just dumps the game and plays it- it would actually RUN the actual cart so Powerpaks/Everdrives/etc would still work. Ideally if you can stuff it into an existing system and have it work, I want it to work for sure on my adapters too. I don't know how much these adapters would cost. They would each consist of a cartridge connector, a system connector, and probably level translation logic and maybe a few other minor things. Figure a $20-30 parts cost. So maybe a $40-50 retailish range. Adding more than 1 cartridge port to the adapter would save money, and maybe be a $5-10 cost adder vs. singles. I have been using PCIe connectors because they are cheap, durable, and extremely commodity, which means there's 10 or 20 companies making them. This will stop it going obsolete any time soon, and keeps the price in the basement. All good things for this. The current "high end" board I have designed and manufactured looks like this: (3D render) (main board + analog board, front view) (main board + analog board, back view) There's no less than TWO FPGAs on this board- one was meant to do all the system simulation/emulation, and the other was meant to handle video scaling, SD card access, etc. I ended up not stuffing the boards because I learned a lot about HDMI during the HDMI NES adapter project, and wanted to apply what I learned. This will basically lead to lower costs and more functionality vs. what I have already created on this existing board. All the parts are bought and sitting here in a box, along with solder stencils, etc. but I think holding off and redesigning the board is the best option. I may still stuff parts of the board for testing, however. Right now, my idea to package this thing was to use the laser cutter I have at work and make acrylic laser cut packaging instead of a professional injection mold, but if 1000ish people were on board, I could most likely go for a proper job injection mold to house it. System specs that a proposed system would have: * SD card for storing ROMs/save games/FPGA configurations * Quad RAM busses to allow up to neogeo level systems * Enhanced video scaling (see my HDMI NES project for a taste of my HDMI capabilities) * 49K logic element FPGA * Quad USB ports for controllers/mice/etc Most likely HID only * HDMI video/audio, 1080p and 48KHz audio standard * Port to allow plugging in cartridge adapters * Maybe one or two built in ports for i.e. NES or SNES or similar * 256Mbytes of RAM The existing board has all of the above except cart ports, and a few more things like ethernet which I would strip off. Here's a youtube playlist showing off most of my FPGA videogame cores to date: https://www.youtube.com/playlist?list=PLzIL4C5OsJVtsCIy482JxhbFNLXMYLKdH And a list: * Sega Master System * Game Gear * Colecovision * NES/Famicom * Atari 2600 * Atari 7800 * Intellivision * Odyssey^2 * Adventure Vision * Supervision * RCA Studio 2 * Fairchild Channel F * Videobrain * Arcadia 2001 * Creativision * Gameboy * Gameboy Color (not 100% yet, still debugging. runs 99% of games so far) nonvideogame things: * SPC player (SNES music) * Mandelbrot realtime zoom/pan/julia None of the cores are bare bones, either. The 2600 core for example supports Pitfall 2, Atarivox, Supercharger demo unit, Supercharger proper, and all mappers. The Intv and Odyssey^2 ones have the speech add-ons, and the NES core supports all expansion audio chips and all mappers. And that's about it. If there's any questions lemme know and I will try to answer 'em.

I got my Analogue pocket in recently; what a system! Not only can you play all the classic carts on it, but many many cores are supported in FPGA, both for consoles and for arcade. Info on getting that setup here: Here is also a video with some great tips and tricks: Let's discuss and share tips and tricks in this thread! For the record my Dock is in, as is my GameGear adaptor, but the second set of adaptors has yet to arrive. Here I am playing some TG-16 Bonk's Adventure on mine:

I'm starting this thread as a means to hopefully promote some F18A development, answer specific questions about programming the F18A, and finally as place to look for links to updated documentation and eventually firmware updates. This first post will always have the latest documents and updates attached, so there is no need to go digging through the thread to find the most recent information. I also hope it will contain questions, answers, and code examples. I would like to keep this thread technical and on-topic, so if you have other general F18A questions or comments, please start a new thread or use the other existing F18A thread. * Documentation: On-going. This is something I hope to complete, but until then Rasmus has collected many of the F18A programming posts from the forum and created PDF of them (thank you Rasmus!) See the files attached to this thread, and please ask F18A technical questions in this thread. The main F18A webpage (http://codehackcreate.com/archives/30) has the main feature list, as well as an initial post to getting started with programming the F18A. As I add documentation, I will post it on the website first, then make an update here to let anyone interested know there is something new. * Register Use Spreadsheet: Libre Office / Open Office .ods format. This is the primary spreadsheet I used while developing the F18A, and all functionality was documented in the spreadsheet first, then converted into HDL. That means the spreadsheet is always up to date with respect to the F18A's functionality. While some of the F18A's features require more documentation to use, much of the functionality is very self explanatory and can be used just by looking at the spreadsheet and reading the notes. For example, it does not take much to guessing to figure out what the "horizontal scroll register" does. ************* COMPATIBILITY ************* Pin-compatible replacement for the TMS9918A, 9928, 9929, and TMS9118 Video Data Processors. The F18A has been tested in the following systems: TI-99/4A Home Computer ColecoVison Game Console* ColecoVision ADAM Computer# Toshiba HX-10 MSX1 Computer Toshiba Pasopia-IQ MSX1 Computer JVC Victor HC-7 MSX1 Computer Yamaha CX5M MSX1 Computer@ SpectraVideo 328 Computer*@ Tomy Tutor Computer*@ SEGA SG-1000 Game Console SEGA SC-1000II (replaced a TMS9118 VDP) Telegames Personal Arcade Powertran Cortex Computer * Note1: These systems are known to have the original VDP soldered directly to the system circuit board and will require desoldering and a socket installed. # Note2: The ADAM computer requires an "offset board" to keep the F18A inside the main PCB outline. This is an available option when ordering and F18A. @ Note3: These systems are known to require USR4 jumper removed because the main system uses the CPUCLK output from the VDP as the main system clock. ************************ F18A FIRMWARE Change Log ************************ F18A V1.9 Dec 31, 2018 (CRC: 147A) * Prepare for open source release. * Split up the original "core" to create a top-module for the stand-alone F18A, and a "main core" that can be used as part of a larger SoC. * Fixed the VGA horizontal timing error caused by treating the pixel time as 40ns instead of 39.68ns. Because events were being counted in "pixels", this caused the horizontal sync pulse to be slightly off, and the overall line time to be 32us instead of 31.746us. This error meant each line was around 6.4 pixels too long, and pushed the total frame rate to 59.2Hz. This error was enough to cause games to fail (Pole Position on the 99/4A), and some monitors to not sync properly when run through video converters. The timing error also caused many problems for the PAL ColecoVision. * Removed sprite-linking. This was an unused feature and helped free up FPGA resources to allow the core to better fit in the Spartan-3E 250K. * Removed programmable GROMCLK divisor. Unused feature, free up resources. * Register mode and cd_i inputs to CPU component. V1.8 - Aug 24, 2016 (CRC: F981) * Fixed sprite collision bug where sprite collisions were being incorrectly detected outside of the active display, after line 191 or 239 depending on the line mode. * Added hybrid VR write restriction to mask VR writes to three-bits when the F18A is locked, like the real 9918A does. However, if mode bit M4 is set (80-columns), writes to VRs over VR7 are *ignored* instead of masked to three-bits. This allows various 9938 programs to work (or continue to work), as well as continue to support TurboForth that writes to VRs 0..15 to set up 80-columns (if straight masking was used, VRs 8..15 would over-write VR 0..7). V1.7 - Jan 1, 2016 (CRC: A3B5) * Fixed Bitmap-Layer (BML) display bug * Fixed GPU's PIX instruction to properly calculate BML addresses * Added power-on graphic that shows the current firmware version V1.6 - Apr 26, 2015 (CRC: 40CC) * Removed fixed tile functionality * Removed border scroll limit functionality * Removed banner functionality * Removed host-side 32-bit counter * Removed host-side 32-bit RNG * Removed GPU 32-bit counter * Removed GPU 32-bit RNG * Removed the sprite "disable value" (>F8) in the sprite Y-location when ROW30 is enabled. * Added second tile layer with its own NTBA, h/v page sizes, and h/v scroll regs * Added ECM2/3 pattern table size selections for tiles and sprites. * Added host-side segmented counter with 10ns accuracy. * Added configurable HSYNC and VSYNC GPU triggers. * Added fat-pixel (2x1) with 16-color support to the bitmap layer (BML). * Added 1x1 page scroll support for T40 and T80 modes. * Added option to reset most VDP registers to their power-on values. * Added option to disable Tile Layer 1, which includes GM1, GM2, MCM, T40, and T80. Sprites, the BML, and TL2 are still active and can be enabled/disabled independently. * Added option to allow attribute byte to be fg/bg color select in T40 and T80. * Added per-position tile attribute support. * Added DMA capability to the GPU: 8xx0 - MSB src 8xx1 - LSB src 8xx2 - MSB dst 8xx3 - LSB dst 8xx4 - width 8xx5 - height 8xx6 - stride 8xx7 - 0..5 | !INC/DEC | !COPY/FILL 8xx8 - trigger FILL (active high) will read a single byte at the src address and fill the destination with that byte. src, dst, width, height, and stride are copied to dedicated counters when the DMA is triggered, thus the original values remain unchanged. * Added USR3 jumper to control GROMCLK/CPUCLK output on pin37 to provide support for 9128/29 * Added USR2 jumper to disable/enable simulated scan lines (every other VGA scan line has its color reduced by 50%.) Also controllable via a new VDP register bit. * Added a 5th sprite reporting option instead of reporting the max-sprite, which on the F18A might be different than the original VDP because all 32 sprites can be on a single scan line. * Added a new register (VR51) to limit the maximum sprite processed. This has nothing to do with the number of sprites that can be visible on a scan line, which is controlled by a separate register (VR30). This register is always active and can be used instead of the >D0 byte in the sprite Y-location, and is the only way to limit sprite processing early when ROW30 is enabled. * Changed the GPU interlock so that polling the VDP status register will not cause the GPU to pause. This should greatly increase GPU performance during heavy VDP interrupt polling. * Fixed T80 NTBA two LSbit problem. They are ignored (set to "00") when the F18A is locked to provide compatibility with the 9938 and avoid problem with software that set the two LSbits of the NTBA to other than "11" as the 9938 documentation specifies they should be. This limits the T80 name table to 4K boundaries. When the F18A is unlocked, all 4-bits of the NTBA are used and the T80 name table can be located on 1K boundaries. * Fixed the 5th number update during a scan line. As long as the 5S flag is zero, the 5th number register follows the sprite scanning sequence. Seems to be a transparent latch that follows the input (current sprite being scanned) until latched by the 5S flag. If the status register is being polled and 5S is reset mid frame, then the 5th number begins following the scanned sprites again. This bug is known to have affected Miner49er on the 99/4A. V1.5 - July 2013 Not really a *bug* fix since the problem it corrects exists on the real 9918A, and only has to do with sporadic collision bit reporting during heavy polling of the original 9918A VDP status register. This was discovered while Rasmus was writing Titanium. The 9918A was not designed to have its status register polled which is why it provides an interrupt output. I don't think the original 9918A designers took the hazard into consideration, but I decided to make this correction because it is what the original designers would have done given their preference (and I asked Karl Guttag about it). Thus, the F18A implements what you would consider the "expected behavior", and will work as expected where the original 9918A might not. I did not make this decision lightly. V1.4 - April 2013 Fixed the sprite collision bug and a GPU bug with the divide circuit. The sprite bug is mostly affected by XB when a program uses CALL COINC(ALL). Most assembly games probably don't rely on the collision bit alone for sprites and perform coordinate testing, which is most likely why the bug slipped through all the testing (and I tested with a *lot* of games on a lot of platforms). V1.3 - July 2012 Original release firmware. ******** UPDATING ******** The In-System firmware update is available for 99/4A users. I am very thankful to Rasums and Tursi for their help in making this possible. You can download the F18AUpdate_vXX.zip file below. Detailed instructions are available on my website here: http://codehackcreate.com/archives/418 Alternatively you can update your F18A in any system via a JTAG programming cable. You can purchase a JTAG programming cable for about $59 USD from Digilent: JTAG HS3 programming cable/ This is very inexpensive for a JTAG cable (my Xilinx-brand cable was over $250!), and Digilent makes quality gear. You also need the Xilinx ISE-Webpack tools: http://www.xilinx.com/support/download/index.htm This is a free download from Xilinx, but it is BIG! About 6GB the last time I checked. There is a smaller download that contains just the programming tools called "Lab Tools" and is only about 1G. I'm still looking for a smaller / simpler solution. You will have to create an account (which is free). The primary program you need is called IMPACT and is used to program the FPGA and SPI-flash. Once you get the tools installed, download and unzip the f18a_250k_vXX.zip file. In the zip file you will find the MCS file: f18a_250k_vXX.mcs The .mcs file is used to update the SPI-flash ROM attached to the FPGA. Here are the quick instructions. The term "system" means your 99/4A, ColecoVision, MSX, etc., and "PC" means the modern personal computer you are running the Xilinx tools on. 0. Make sure your system is powered OFF to begin 1. Open your system to get physical access to the F18A 2. Plug the JTAG programmer in to your PC (via USB) and the F18A (via JTAG) 3. Power ON your system 4. Launch the Xilinx IMPACT tool 5. Double-click on "Boundary Scan", then right-click in the main area and select "initialize chain" 6. The FPGA should be detected and show up in the big area. A window will open with device properties, just click "ok" 7. Above the FPGA icon should be a dotted line with "SPI/BPI ?" in it. Right-click on that box and select "Add SPI/BPI Flash..." 8. Navigate to the f18a_250k_vXX.mcs file you extracted from the .zip file and choose "Open" 9. Select "SPI PROM" and "M25P80" from the two drop-down selections and click "OK" 10. The box above the FPGA should now say "FLASH" in it. Right-click the box and select "Program" Once the programming is finished, cycle power on your system and make sure it comes up. ******** Examples ******** Included in the zip file is a demos disk that shows many of the enhanced features of the F18A. The source for all the programs are included. I did not write these programs and I am very thankful to Rasmus and Tursi for contributing them. rasmus_scroll.zip F18A documentation.pdf f18a_register_use.zip F18A_V19.zip

This is intended as a discussion thread for the Ultimate Cart hardware - an SD-card based multicart for the Atari 8-bit, featuring an altera FPGA and 1 meg of SRAM. If you want to ask me (or someone else) to build you one, you can ask in the pre-orders thread. This is an open-source project and has its own github repository: https://github.com/robinhedwards/UltimateCart The fpga firmware source will follow in the next few days, but for now there are PCB files, programming files for the FPGA and a Bill Of Materials. Everything needed to assemble a board yourself should now be there. If you want to build one yourself and need some help, ask here. Since it features an FPGA, the hardware will allow lots more to be done with the cartridge. Co-processors, hard-disk functionality, other cartridge types (e.g. Corina) and stackable (e.g. SDX+other) carts should all be possible. The JTAG header makes it possible to reprogram the FPGA with a $10 USB blaster. I'm hoping people can get together to implement and discuss this some of this stuff here. Robin

Hello all! I've been chatting with some people on this forum and decided to start posting updates here on my project to emulate discrete game chips. There are no true emulations, and only a few simulations have been done so far due to the fact that they don't contain microprocessors and because most of the circuitry is inside a literal black box. Hopefully this will change soon. https://nerdstuffbycole.blogspot.com/2019/03/febuary-progress-update.html

Again it's been a long while since I wrote anything here... I thought to write a short update about my work on my new FPGA version of the TI-99/4A. This is work in progress. In short, I'm in the process of creating a version for the Blackice-II FPGA board. This is an affordable board (I hope it is still available) with a fairly small ICE40HX4K FPGA chip, 512K RAM and a fairly powerful microcontroller. The board is supported by the open source Icestorm toolchain, and I have used that for development work. This has been an interesting adventure so far. Icestorm very nice and compact toolchain compared to the bloated Xilinx and Altera tools. However, Icestorm only supports the Verilog hardware description language, so I had to learn Verilog and port my existing VHDL code base to Verilog. Most of the work so far (and I have but a fair amount of hours into this already) has gone to porting and modifying the code to work on this fairly limited platform, changing the language to Verilog and designing around the limitations. In the context of recreating the TI-99/4A the biggest drawback is that the small FPGA only has 16K of internal RAM (compared to 64K on the chip I used for the VHDL version). Also, the internal RAM is a lot less sophisticated. The result has been that I have had to redesign the system architecture quite a bit, so that the external 512K RAM chip is now used for code, data and video memory - as opposed to using on-chip RAM for video memory in the past. This may seem like a small change, and in a way it is, but in practice I had to design a much more involved memory controller which can arbitrate between CPU, VDP, and the bootloader accesses in real time. Although I have converted my whole code base to Verilog, currently only a portion of this has been fully ported and works. Namely I have a system now that has the TMS9900 CPU, TMS9918 VDP with VGA output, memory controller driving the external RAM, EVM-BUG debugger in a 8K ROM block, and finally pnr's TMS9902 UART. The ICE40HX4K chip is only supposed to have 4K LUTs (look up tables), but in practice the silicon is the same as ICE40HX8K with 7680 LUTs and the Icestorm toolchain enables access to all of them. Which is good, since the design already uses 4421 LUTs. The design runs at 25MHz, which is the VGA pixel clock. I am hoping I can fit in the whole thing into this FPGA. As the chip's resources gets close to full utilization the routing probably becomes impossible, so I cannot add too much more. I don't know yet where the limit is. One of the consequences of having the VDP use external RAM is that it now is possible to map video RAM to CPU's address space directly, and that is what I have done during debugging (I'm not yet using TI-99/4A ROMs, just EVMBUG). There are now two ways to access VRAM: using the standard indirect registers - this is obviously necessary for compatibility, and alternatively by just directly mapping it to CPU address space. Direct access to VRAM vastly increases the bandwidth and makes it very easy to use, but of course no existing software supports this... Next I need to add GROM support, which should be easy. When that is in place I should be able to boot this thing with the TI-99/4A ROMs. I still need to figure out how to split the 512K RAM between different functions, probably something like this: 8K system ROM (0000..1FFF) 8K disk support (4000..5FFF) 256K paged cartridge space (6000..7FFF) 64K GROM space (24K used by console GROM [actually 18K but multiplies of 2 are easier]) 64K VRAM space 32K normal RAM expansion That leaves 80K still to be allocated to something. If I can fit in my memory paging unit, it probably would make sense to have the ability to configure either 256K AMS memory space or 256K cartridge space.

Pokeymax v3 is now available for pre-order. Features: Quad Pokey Dual SID Dual PSG Four channel Covox, with Paula style DMA GTIA audio digital pass though SIO audio mixing PBI audio mixing May be updated/configured via software on Atari Larger 10M16 FPGA, leaving adequate resources for future enhancements Spare 5V safe IO for future enhancements For the pre-orders Retronics are offering a special promotional price of 99USD. Note that version 2 will remain available for the simpler mono/stereo Pokey/Covox options. --- Ordering info from @Duddie --- Additional features confirmed: SPDIF digital output (TTL level, excludes SIO in/PBI in) PS2 keyboard input

*** Tomy Tutor/Pyuuta/PyuutaJr: Games & Homebrews MegaPack for MiSTer and MAME - by TMOP *** Due to the recent release of the beta core for Tomy Tutor for MiSTer FPGA (see MiSTer Tomy Tutor Core) I decided to prepare a MegaPack to have in one .zip all the released games and homebrews. I've also included a Excel file in which, for each game/homebrew, there are the tests results and some additional information. If you have some carts/homebrews not in this pack, but in the list, please share them, so can be included in the next update! Have fun! ? TomyTutor_Pyuuta_MiSTer_FPGA_Core_v1.0.0_08052022_by_TMOP.zip TomyTutor_Pyuuta_SW_List_V1.0.0.xlsx

I'm looking to trade my Super NT and AVS systems. I'm the original owner of both. I'm mainly interested in getting a good 600XL or 800XL for them. I'm located in North Carolina 27707. Thanks!

CollectorVision just announce that the ColecoVision FPGA console, the CollectorVision Phoenix, will also be launched with added Atari 2600 core, with more details coming soon. http://atariage.com/forums/topic/283794-collectorvision-phoenix-kickstarter-is-now-live/?p=4138644 See the Kickstarter here: https://www.kickstarter.com/projects/1408938247/collectorvision-phoenix-an-fpga-colecovision-conso

The community support keeps making the Pocket better all the time!

This is the one everyone has been waiting for!

A new core for MiSTer FPGA is available for Tomy Tutor/Pyuta/PyutaJr. It's from @Flandango that was also working on the lates updates on the TI99 core on MiSTer (he added disk, TIPI, SAMS, F18A, etc. support to the TI99 core). ? It's the initial version and you can read more on the official MiSTer forum: Tomy Tutor. I'm not an expert for this system, so I cannot help him testing as I've done for the TI, however I'm sure some on the community will help him for the tests and improvements.

I just recently became aware of this newer device. A more powerful system, supposedly. Does anyone here have one yet? Any thoughts of advantages of one over the other? I can think of one -- MIST can be purchased off-the-shelf, while MISTER may need DIY daughter boards, (which I don't really understand.) I've watched Nir's nice video on the MISTER, but still leaves questions about the boards. I did find this thread here: http://atariage.com/forums/topic/260994-mist-experience-with-atari-8-bit/?hl=+mister -Larry

This is my first attempt in FPGA world. To prove myself that I'm capable of I made this simple VGA 640x480 output via FPGA Cyclone II develop board (https://tinyurl.com/2p9xbyxn) for the glorious Mattel Aquarius. I connected directly to the bus on cartridge slot to get the 16bit address line and I soldered 8 wires directly to the data pins (D0-D7) on the Z80 cpu. Unfortunately the databus pins (DE0-DE7) on cartridge slot are not connected directly to the cpu (as those of the address bus), but instead there is PLA2 chip that routes signals, so I had to solder wires directly to the cpu. My verilog code listen to memory writes on address between 0x3000 and 0x3800 and catch bytes to characters and color memory, then reproduce the screen image using a character generator based on bitmapped chars image (found here on this forum )plus a color decoder based on TEA1002 specifications. I'm on early prototype stage. If you are intrested on this project I've planned a little radmap: adding colorful (8bit RGB332) hardware sprites (controlled via simples POKEs to screen memory) adding paged screen memory (and break the 2k barrier) adding hw scrolling adding pcm sounds (mod or similar) adding hw timers (via NMI interrupt) and finally bring the "a system for the seventies" at least to the "system for the nineties" Here's a short video

Is this a good option for transporting the Analogue Pocket?

Thought I would share this video from RMC. Definitely looking forward to further information and details (especially pricing). May have to finally jump into the FPGA pool.

I have written a new core for the Ultimate Cart. It is an implementation, a behavior based clone, of the Project Veronica 65816 cartridge. The 65816 implementation is not cycle exact but seems to run fairly reliably so far. In order to get it running you need to download and flash http://www.64kib.com/veronica/veronica20180414.pofusing the USB blaster. You will need to flash back the standard core to use it as a flash card reader later. You will then need software, I suggest trying the following two: http://atariage.com/forums/topic/164097-project-veronica/?p=3190927:atr file with tests and demos http://atariage.com/forums/topic/164097-project-veronica/?p=3227906:Veronica Basic Many thanks to Zenon/DIAL, Marek Konopka, and Simius for their work on the original. Thanks for Robin Edwards for his work on the Ultimate Cart. Thanks to Robert Finch for his 65816 core. Thanks for Avery Lee for his work on the documentation of the Veronica cart and Veronica Basic. See https://github.com/robinhedwards/UltimateCartfor details about the Ultimate Cart. See http://atariage.com/forums/topic/164097-project-veronica/for details about Project Veronica. See https://github.com/robfinch/Cores/tree/master/FT816for the 65816 core. See http://www.64kib.com/atarixlfpga_svn/trunk/atari_800xl/ultimate_cart/veronica/for my core to tie it all together. Video demos:

As I promised in another thread, here are some details of a project I'm working on. I hope it will be of interest. I studied microprocessor design at University some 10-15 years ago. Since I work as a software developer I have never had a chance to put it into practice. Now an opportunity has presented itself since I'm on gardening leave from work for 6 months! I decided to spend much of this time learning about hardware by building a new Atari 8-bit computer. I'm doing the development for now on an Altirra DE1 FPGA board. An FPGA is basically re-configurable hardware. A special chip with a bunch of logic gates that can be connected any how. Used usually for prototyping new hardware, with lower cost than actually creating an ASIC. They are also used on Atari for a few things - e.g. VBXE and the recently discussed accelerator board. My development is done in VHDL. This is a hardware description language. It can be written very low level, i.e. this logic gate connects to this. It can also be written as a slightly higher level behavioral description. Which is simpler but leads to slower hardware. It is easier to understand and I've mostly written (register aware) behavioral code for now - later we can write faster implementations if we need to! Or even base the logic on the de-cap projects for more accuracy. The current status is: i) Basic runs, including all non-gtia modes. ii) SIO working, so I can boot via SIO2PC. iii) Self test runs. iv) Much software 'almost' runs. I think a few big issues will fix 80% and the rest will be harder... A little more detail on the chip status: i) Pokey. All sound features including 2-tone. I'm doing non-linear mixing in hardware for now, though we could use an equivalent analog circuit for more accuracy. SIO working. Interrupts working though I need to verify correct timing. Keyboard support via PS2 port. I plan to later add support for the XEGS keyboards. ii) Antic. All modes and correct DMA/(fake) refresh timing/PMG DMA. I think DLI timing and VBI timing is incorrect. I think bugs here are preventing me running much software for now. iii) PIA. Near complete - at least all the features used on the Atari. iv) GTIA. AN0-AN2 and sync support done. Sound and consol buttons. All colour registers and palette done. PMGs partial. GTIA modes not yet done. I'm currently part way through GTIA... v) Memory. The board has 512MB SRAM. This can easily be mapped 130XE style etc with Antic/CPU bank switching. The board also has a large ROM, though this is slower. vi) CPU. Runs at ~1.8MHz by default for compatibility. There is a switch to run the CPU at 25MHz. I hope to run at 40MHz to 50MHz eventually. Currently I'm using T65. I plan to write my own 6502 implementation with illegal instructions, or at a minimum, implement the illegal instructions in T65. I will complete the functionality in the next week or so. Then I will work on debugging and improving reliability. It will pass Acid 800 by the end of August (I'm unable to work on this for much of July...). Then I will work on some break out boards to allow real joysticks to be connected, real sio devices and cartrides + hopefully ECI. As 'stretch goals' I then intend to try a few things like - for now just a brain dump: a) Adding SD card support b) Adding double/quad colour clock modes. c) Scan double for VGA? d) HQ2X e) Quad Antic with GTIA to overlay? f) VBXE?! Is the VHDL or verilog available? Any questions? If anyone is interested in trying out the SOF file for the DE1 then send me PM. I'm keeping the VHDL code private for the time being, at least until I finish the project. If anyone is interested in doing a commercial version and building real hardware let me know please. Mark

I've been working on this project off and on (mostly off) since 2010. It's still a work in progress, but it's far enough along now that I feel comfortable in sharing it. The original goal of the project was to recreate an Atari 2600 in an FPGA, but as things progressed the project goals became more ambitious. What I ended up with is an FPGA based Atari 2600 that uses HDMI instead of RF for its television interface, and USB for a slew of implemented and planned features, all wrapped up in an enclosure that is styled to resemble a Walkman. For those who are interested, I wrote the RIOT and TIA cores in Verilog from scratch, and used the FPGA Arcade branch of Daniel Wallner's "T65" 6502 CPU core. Special thanks to Mike Johnson and Wolfgang Scherr over at FPGA Arcade (www.fpgaarcade.com) for updating the T65 core, and for sharing their work. Features Atari 2600 hardware faithfully recreated in an FPGA. HDMI video/audio output for connecting to modern TVs. Analog audio line output for use when connecting to a DVI monitor that doesn't have sound. Full support for most Atari 2600 peripherals. Enclosure styled to resemble a Walkman for total immersion in nostalgia. Pause button that will freeze the game for those times when you need to take a break. USB connector for upgrading the firmware, and also for a multi-protocol communications bus. Test pattern generator that can be used to aid in adjusting your TV settings. Planned Features Capture screen shots to FLASH, and then transfer to a PC via USB. Capture live game video and audio to a PC via USB. Save and recall machine states. PAL timing and palette. Wish List Complete debugging/monitor environment on PC via USB with flexible user specified triggering for trapping any hardware condition. Other things I have yet to think of. Specifications HDMI Video Formats 640 x 480 @ 59.94 Hz 800 x 600 @ 59.94 Hz 1024 x 768 @ 59.94 Hz 1280 x 720p @ 59.94 Hz 1600 x 1200 @ 59.94 Hz 1920 x 1080p @ 59.94 Hz 1920 x 1200 @ 59.94 Hz Audio Formats48 KHz linear PCM, 2 channels Analog Audio 940 mV P-P into 47K ohms 360 mV P-P into 600 ohms Test Patterns H Ramp V Ramp H grayscale bars V grayscale bars 100% color bars 75% pseudo SMPTE color bars 16 x 16 cross hatch H burst Photos View of the rear side: HDMI and joystick connectors. Another view of the rear side. View of the left side: buttons, USB connector, B&W/Color switch, left and right difficulty switches. Another view of the left side. Top down view of the main PCB. All ready to go. Just press PLAY.

And I do plan to jailbreak it in a future video.

My MiSTer FPGA set-up, and some questions/issues... First of all, here's my MiSTer FPGA set-up, in a basic aluminum box that I found in the garage. I had a smaller box available, but the USB hub would have had difficulty in fitting, and I didn't want this to be an exercise in getting something to fit into something really small. It's not too fancy, but it'll only sit behind or underneath the TV anyway. Maybe I'll paint it red, or better yet, put an Atari logo on it. With many of these types of boards, it can be annoying that there's I/O on several sides of the board, making it sometimes difficult to put the thing in a generic box. I opted to put the board in a corner, so on the left side in the pictures, there's power and HDMI, and on the front is the MicroSD card, and breakout from the USB hub. I did make sure the USB hub only had inputs on one end. I forgot to buy an OTG hub with microSD connection, so I have a separate OTG adapter cable plugged in between the MiSTer and the USB hub. Plugged into the USB hub I have a wi-fi dongle, and mini-keyboard dongle. There's of course space for USB controller. I have a 32 MB SDRAM board plugged into the DE10-nano board. This SDRAM will play about 98% of the games/systems available, and only cost about $20-25 instead of $80-100. Apparently when you buy the DE10-nano board from different places, there are different extras such as power supply, cable, and 8 GB microSD card. I bought from Digi-Key, and it came with all these. I'm using a 32GB card, but I think the supplied 8 GB card likely would have been enough (at least enough to start with), unless getting into CD based games, and that sort of thing. The MiSTer also seems to play well with zip files, which is a bonus. I'm also currently using an HDMI to VGA adapter. This a ~$10 device. I made sure it included a 3.5mm audio output. Note that my MiSTer does not have the standard stack of 3 boards that you'll often see. That's too pricey for me. I'll probably switch to HDMI to a large TV, but for now, the VGA adapter works well on my desk. One thing I'll be looking for is a heatsink for the FPGA. I'm still looking for one that is cheap and uses tape to connect. If you want a simple set-up that can play thousands and thousands of games, get the DE10-nano from Digi-Key ($135), 32MB SDRAM ($20), OTG USB hub ($10), wired keyboard (you have already?), wired mouse if you want (you have already?), USB SNES controller ($15), case ($10), heatsink ($10). All prices estimated. Total is about $200 US. Not too cheap, but in my opinion, great value, for a very stable system. So far I've been pretty happy with the system. There's definitely some growing pains, setting up different things, though. It took me a while, with a few false start with some of the scripts out there, but I found a script that downloads all the arcade ROMs, as well as updating other things. Search for "All-in-one script for updating your MiSTer". Next is the good news, bad news, for the controller. I had been testing with a cheap SNEZ USB controller, which worked okay for what it was, but I really wanted to make my own controller... one that fits my style of play, and my style of games that I like to play. So, I built this: The thing is huge. I'm not compensating for anything, except for years of trying to use controllers for all sorts of systems, most of which don't work well for me. I wanted a single controller that would do all the things I wanted it to do. I grew up with early '80s arcade games, and CX-10 style joysticks, and really, anything else doesn't work for me at all. Don't get me started on D-Pads where I can only effectively move in one of 4 directions successfully. That's just me... my kids seem to do just fine. Anyway, I've got a digital joystick, analog joystick, paddle, keypad for Intellivision/ColecoVision, menu/select/start buttons, a shift button (for some reason), and a bunch of multi-colored buttons. Also space for a keyboard, that I'll Velcro on at some point. I'm not likely to get into the computers too much, but if I do, I'd be using a different keyboard than this one. This one was lying around, so here it is. If I had to buy another mini keyboard today, I'd find one a bit bigger, with clearer lettering (for computers, I'd buy something at or near full size). The digital joystick and main buttons use leaf switches, so they're pretty quiet, which works best for me. The joystick has a circular "gate" - for me this is fine, as I've never had a problem playing Pac-Man or Time Pilot or whatever else on this type of joystick. I don't need 2/4/8 way gates. Your mileage may vary. I haven't built a case yet, but so far I'm happy with it physically. If I can get it working well, I'll build a simple wooden frame for it. The panel is built from an aluminum/plastic/aluminum laminated sheet that I had in the garage. I quickly painted it black. It holds fingerprints well. If I like the joystick the way it is, maybe I'll fix it up so it looks better. Maybe not - it's not too bad right now. Unfortunately, however, I seem to have spent money on the wrong thing. I bought an Ultimarc A-PAC which can handle up to 4 analog controls and quite a few buttons, including enough for the keypad. I thought it had a couple more, actually, but I was able to double up on some of the buttons vs. keypad, so it's okay. It's perfect, except that the A-PAC is intended to be used for 2 players on the one USB input, but the MiSTer FPGA is intended to be used one player per USB input. There doesn't seem to be a way to use two joysticks for one player. I did some quick rewiring, so at the moment the analog controller and the keypad can't really be used, but the basic digital controls can be. If anyone has any suggestions on how best to proceed on getting all the controls to work, that would be awesome! Ideally with the existing A-PAC, but if I need to build/buy something else, that's not the end of the world, either. There's a few other quirks in the MiSTer FPGA, but I'm sure I'll get those figured out at some point... coin and start buttons for the arcade games, and getting the paddle controller set up for the Atari 2600 core simply/easily. Other than the controller issues I've got, I'm very happy with the MiSTer FPGA. This is basically my Zimba 3000 system. It's got everything I need in one package, and hopefully one day, I'll be able to control all the systems with one controller, which for me, will be pretty awesome! A big thank you to anyone who's contributed to the MiSTer FPGA project!

Great news - FPGAzumSpass, one of the FPGA titans in the MiSTer project, is working on a Lynx core

I've been back-porting some of the EclaireXL features to the various FPGA boards. I've just uploaded the latest core builds to my site, for many of them its the first update in 3 years so I thought its reasonable to announce it here. There are more details here, including highlights on the changes: http://www.64kib.com/redmine/news/57 Please let me know how you get on. I tested each board individually as I went but due to time I can not reasonably go through every single version!