Jump to content

Search the Community

Showing results for tags 'fpga'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Atari Systems
    • Atari General
    • Atari 2600
    • Atari 5200
    • Atari 7800
    • Atari Lynx
    • Atari Jaguar
    • Atari VCS
    • Dedicated Systems
    • Atari 8-Bit Computers
    • Atari ST/TT/Falcon Computers
  • Classic Consoles
  • Classic Computing
  • Modern Consoles
  • Gaming General
  • Marketplace
  • Community
  • Community
  • Game Programming
  • Site
  • PC Gaming
  • The Club of Clubs's Discussion
  • I Hate Sauron's Topics
  • 1088 XEL/XLD Owners and Builders's Topics
  • Atari BBS Gurus's Community Chat
  • Atari BBS Gurus's BBS Callers
  • Atari BBS Gurus's BBS SysOps
  • Atari BBS Gurus's Resources
  • Atari Lynx Programmer Club's CC65
  • Atari Lynx Programmer Club's ASM
  • Atari Lynx Programmer Club's Lynx Programming
  • Atari Lynx Programmer Club's Music/Sound
  • Atari Lynx Programmer Club's Graphics
  • The Official AtariAge Shitpost Club's Shitty meme repository
  • The Official AtariAge Shitpost Club's Read this before you enter too deep
  • Arcade Gaming's Discussion
  • Tesla's Vehicles
  • Tesla's Solar
  • Tesla's PowerWall
  • Tesla's General
  • Harmony/Melody's CDFJ
  • Harmony/Melody's DPC+
  • Harmony/Melody's BUS
  • Harmony/Melody's General
  • ZeroPage Homebrew's Discussion
  • Furry Club's Chat/RP
  • PSPMinis.com's General PSP Minis Discussion and Questions
  • PSPMinis.com's Reviews
  • Atari Lynx 30th Birthday's 30th Birthday Programming Competition Games
  • 3D Printing Club's Chat
  • Drivers' Club's Members' Vehicles
  • Drivers' Club's Drives & Events
  • Drivers' Club's Wrenching
  • Drivers' Club's Found in the Wild
  • Drivers' Club's General Discussion
  • Dirtarians's General Discussion
  • Dirtarians's Members' Rigs
  • Dirtarians's Trail Runs & Reports
  • Dirtarians's Wrenching
  • The Green Herb's Discussions
  • Robin Gravel's new blog's My blog
  • Robin Gravel's new blog's Games released
  • Atari Video Club's Harmony Games
  • Atari Video Club's The Atari Gamer
  • Atari Video Club's Video Game Summit
  • Atari Video Club's Discsuuions
  • Star Wars - The Original Trilogy's Star Wars Talk
  • PlusCart User's Bug reports
  • PlusCart User's Discussion
  • DMGD Club's Incoming!
  • DASM's General
  • AtariVox's Topics
  • Gran Turismo's Gran Turismo
  • Gran Turismo's Misc.
  • Gran Turismo's Announcements
  • The Food Club's Food
  • The Food Club's Drinks
  • The Food Club's Read me first!
  • The (Not So) Official Arcade Archives Club's Rules (READ FIRST)
  • The (Not So) Official Arcade Archives Club's Feedback
  • The (Not So) Official Arcade Archives Club's Rumor Mill
  • The (Not So) Official Arcade Archives Club's Coming Soon
  • The (Not So) Official Arcade Archives Club's General Talk
  • The (Not So) Official Arcade Archives Club's High Score Arena
  • Adelaide South Australia Atari Chat's General Chat & Welcome
  • Adelaide South Australia Atari Chat's Meets
  • Adelaide South Australia Atari Chat's Trades & Swaps
  • KC-ACE Reboot's KC-ACE Reboot Forum
  • The Official Lost Gaming Club's Lost Gaming
  • The Official Lost Gaming Club's Undumped Games
  • The Official Lost Gaming Club's Tip Of My Tounge
  • The Official Lost Gaming Club's Lost Gaming Vault
  • The Official Lost Gaming Club's Club Info
  • GIMP Users's Discussion


There are no results to display.

There are no results to display.


  • AtariAge Calendar
  • The Club of Clubs's Events
  • Atari BBS Gurus's Calendar

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start










Custom Status



Currently Playing

Playing Next

Found 22 results

  1. 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.
  2. 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
  3. 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
  4. 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 [email protected] 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
  5. And I do plan to jailbreak it in a future video.
  6. 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!
  7. Great news - FPGAzumSpass, one of the FPGA titans in the MiSTer project, is working on a Lynx core
  8. 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!
  9. Hello all! I like to drop in and show people things that they may not know, or might not have seen before, and as have been a lurker here for years, I thought someone might get a kick out of seeing a full resolution teardown of the Analogue Nt First Edition NES/Famicom console. Serial Number 000123. Let me know if you have any questions I might be able to answer, but otherwise, enjoy! 1. The Aluminum Case; 2. The Nt Motherboard 3. The CPU/PPU Daughterboards; 4. The Zimba Labs (Kevtris) 6502A FPGA HDMI Board; 5. Board/Chip Closeups; 6. Misc. Board Oddities; I hope everyone enjoys the photos as much as I enjoyed tearing down this amazing chunk of engineering! (First Post!)
  10. Hi All, One thing I really wanted to add to the Ultimate Cart was an easy way to use XEX files on the cartridge. Thanks mainly to flashjazzcat, we've now added this as a feature to the firmware. XEX files present on the SD card can now be browsed and launched just like cartridge/ROM files. Loading is practically instantaneous. You can program the attached new firmware to your Ultimate Cart using the (free download) Quartus 15.1 programmer. You will also need a USB Blaster (<$10 on ebay). Consider it a beta - there may be the odd bug. This firmware also replaces my original menu with the improved version by flashjazzcat. Since this is now part of the firmware, you should remove any older version of it from the SD cart (i.e. remove _BOOT.ROM if you have it). This will become the current firmware, and I'll upload the source files to github once this has had a bit of a wider test. I'm sure this will be a very welcome addition to the cartridge firmware, and praise and thanks should be directed to flashjazzcat who wrote the XEX loader and the improved menu - tasks both way beyond my 6502 skills! Robin 10M08SAE144C8G.zip
  11. As discussed a little yesterday in the Pandemic club 4A zoom call (thanks for the interesting discussion!) I started to look a bit how the GPL interpreter could be optimised. My original idea was to add some instructions to my FPGA processor core to speed up the interpretation with special purpose instructions, but as I started to look at the code it's quite clear that a lot can be achieved with normal code optimisation. @RXB mentioned that there has been a discussion with @Tursi about this topic. I somehow recall seeing that thread myself, but couldn't easily find it (which is probably my fault). As an obvious optimisation, instead of the multiple levels of tables, the GPL instruction decoding could be improved at the cost of using some more memory simply by having a 256 entry lookup table (occupying 512 bytes). For that part I could create a new instruction which could combine a few TMS9900 instructions, in pseudo code: // Address 0x78 MOVB *R13,R9 JGPL @TABLE,R9 // Here JGPL would be a new instuction, something like below. // The instruction would only perform 2 memory fetches: Read R9, and fetch the jump vector from TABLE. BANK 1 // Switch bottom 8K to a new bank, which has the jump table MOV R9,TEMP // Temp internal register SRL TEMP,7 // TEMP >> 7, shift to a word index MOV @TABLE(TEMP),TEMP // Fetch from table BANK 0 // Switch bottom 8K to normal bank B *TEMP In the arrangement above since the opcode would be passed to the new instruction JGPL, that instruction could also be developed further to understand some GPL instructions directly, executing them directly by the CPU instead of TMS9900. Many GPL instructions are quite involved, so it would best to be able to incrementally improve things, for example starting with branch instructions which seem to be rather simple. I also realised that I am jumping the gun - I should try to look at some GPL code before going to optimization phase to understand how things work. To that end I started using xga99.py to assemble the GPL code for Minimemory cartridge, as a test. Also since I think this a very cool cartridge which could be integrated and expanded in interesting ways in both my icy99 and StrangeCart projects. So I got the GPL source code for Minimemory from Thierry's excellent TI-99/4A tech pages. I guess that code is for his GPL assembler. But I wanted to use the xdt99 package. So I started to assemble the source with xga99.py, like so: xga99.py --aorg 6000 mmg.gpl -L mmg.lst I quite quickly ran into a few problems, due to differences in syntax, for example: The AORG directive in xdt99 does not accept addresses higher than 8K. This causes a number of problems, because there is a hole in the code, i.e. it AORGs to >70AC skipping a bunch of bytes. I guess I have to manually fill that range with some bytes. The multiplication instruction in the source is MPY, but xga99 uses MUL. Not a biggie. Many lines in the code contain comments (which is great) after the code. I have never understood why the comments don't start with a special character like semicolon or something, that would make parsing easier for the assembler and it could probably also prevent some mistakes. Anyway, xga99 could not assemble a number of lines because the comments were separated by just a space. I just removed those comments after the code (by moving them to a separate comment line). The HTEX instruction (in a FMT block) escapes hex bytes differently, simple change: from HTEX '[>0A]' to HTEX >0A Some other opcodes also are different: CAR -> CARRY, PARS -> PARSE, DCGTE -> DCGT The source code uses the BIAS command also outside a FMT - FEND block, it appears to specify a constant to be added to strings specified with the STRI directive. The source I used has first BIAS >60 to set the TI Basic character code offset. I did not find a way to replicate this functionality in xda99. The advice goes: "use the source, Luke". And so I did, and created a new directive STRI60 for xda99, as follows. It's hack for sure, but I didn't want to enter the text as BYTE statements. * Original source (disassembled and commented by Thierry) BIAS >60 G6E1A STRI "ILLEGAL TAG" G6E26 STRI "CHECKSUM ERROR" ---------------------------------- * Modified source for xda99: *EPEP BIAS >60 G6E1A STRI60 "ILLEGAL TAG" G6E26 STRI60 "CHECKSUM ERROR ---------------------------------- * xda99.py has been modified to support the new STRI60 as follows: # EP 2020-12-13 added new STRI60 operation to add the screen offset to each byte. # Used for Mini Memory porting @staticmethod def STRI60(asm, label, ops): asm.process_label(label) text = ''.join(asm.parser.text(op) for op in ops) asm.emit(len(text), *[ord(c)+0x60 for c in text]) And this is roughly where I am at the moment. I am comparing the generated GPL binary image to the original, and now the first >770 bytes match (except for the pointer to >70AC due the AORG stuff, need to come up with a solution for that - probably I'll just fill in the empty range with some bytes) to get to 70AC.
  12. Hi All, The Ultimate Cart is an SD-card based multicart for the Atari 8-bit, which I've been developing for the last few months. It allows you to browse the SD card on the atari and launch cartridge images from ROM and CAR files from the menu. The PCB is designed to fit in a standard grey cartridge case (after a bit of modification with some clippers and a file). It supports most ROMs up to 1 megabyte in size, including standard 8k and 16k cartridges, XEGS, AtariMax 1 & 8mbit ROMs, SIC! Cart, Bounty Bob, OSS, SDX & Williams. ROM dumps can be easily converted into CAR format with my conversion utility. To learn more about the hardware and development, the original thread is here. The project is open source. PCB files, programming files and source files will be available on github shortly, and I'll open a technical thread for discussion when this has been done. The hardware includes an FPGA and could be used for a lot more than a multicart - co-processor & SD-card based hard disk are two possible future avenues for development. There is a JTAG header to allow the cartridge firmware to be reprogrammed in the future. Now that I've assembled and tested the second board I think its probably time to open a pre-orders thread so I can get some idea of interest. The price will be £70 (+postage) for the cartridge board (ready to use, but uncased). If you are interested in one, please reply to this thread. At the moment, this is only to give me some idea of numbers and to reserve your place in the queue. It is not a commitment to buy or for me to supply one. I'm not sure how many of these I'm prepared to make, and it may take me some time, so I will contact people as I make the boards, and check they are still interested. Since its open source, I'm hoping some others may make the boards too, and might be able to charge less than me. Initially, I've got 3 more PCBs on the way, and I will prioritise any UK or European orders, since it will be easier to post/return if there are any unexpected teething problems. Beyond that I'll see how much interest there is. Robin
  13. 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
  14. *SOLD* *SOLD* *SOLD* Hi everyone! This is my first post here, so I hope I’m doing this right. I have a bundle of goodies to sell. Everything is practically new except for the Ecco games. The games have some wear but still are probably better overall than most copies out there. They were the best I could find at the time, and I can send pictures if I need to. Everything else looks perfect and was bought within the last four months. I only used the HDMI switch on a 1080p TV, so I haven’t tried out the 4K and HDR functionality. 1x Analogue Mega Sg (Complete in box with all original accessories) 1x 8bitdo M30 2.4ghz Controller with Genesis Adapter 2x Retro-Bit 6 Button Controllers (Licensed by Sega) 1x Sandisk Ultra 16gb SD Card 1x 10ft Male to Female 3.5mm Audio Cable 1x 5 Port 4K 60hz HDR HDMI Switch with Remote 1x Ecco The Dolphin (Complete in box with manual) 1x Ecco: The Tides of Time (Complete in box with manual) For those that don’t know, the Mega Sg is a FPGA clone of the Sega Genesis. It’s a great way to play your Genesis games on a modern TV since it doesn’t add any input lag beyond the TV. It also has a previously unreleased game by DICE called “Ultracore” on the system. It also can play Master System games with the included cartridge adapter (still wrapped in plastic), and there are more adapters available to buy that allow you to play Game Gear, Sega My Card, SG-1000, SC-3000 games. Oh, and the system can easily be jailbroken to play games from a SD card. The system can also be customized by simulating scanlines and adjusting the sound. Since the Genesis had several models with different sound chips, it caused trouble with some games audio depending on the console model. The Mega Sg allows you to fix this by switching a setting on or off as needed. The Mega Sg is also region free and accepts cartridges from all regions without modification. There’s a couple of very good Mega Sg reviews by My Life in Gaming and Digital Foundry on YouTube if you want to know more. It also doesn’t have any sound lag like the Genesis Mini. I paid around $350 for everything listed here including tax and shipping. The Mega Sg alone was $190 plus $17 shipping. I’m asking $225 for everything including shipping within the lower 48 USA. If you are worried about me being new on here, I can point you to an amateur astronomy website where I have a lot of feedback from buying and selling things. I take very good care in packaging my items, and I will provide a tracking number. Thanks for looking!!!
  15. 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.
  16. I've been meaning to start a topic about my abbuc hardware competition entry, a replacement for the Pokey chip. It's been mentioned in a couple of threads but I thought many people may have overlooked it. I tried to be sensitive to cost in my design, though once the full details are released (after competition result) it will be fun here to brainstorm ideas to make it even cheaper! Clearly there are still plenty of real pokey chips, however the supply is starting to become more limited and prices are on the increase. --- PokeyMAX Introduction The PokeyMAX is a complete replacement for the Pokey chip. It is derived from the work on the EclaireXL project, a complete FPGA based Atari 800XL clone. The intention is to build replacements for all of the Atari custom chips using this technology and Pokey has been built first. It can be used either to replace a broken/missing pokey, as a stereo upgrade, or just for fun! Features If pokey is socketed, zero wire installation (mono) Dual pokey mode Pins for 3 audio outputs (left channel/right channel/mixed) Small footprint, only a few mm larger than original IC Supports all features: 8x paddle inputs, IRQ, serial I/O, audio output, two tone mode, high pass filter and keyboard scan High level of compatibility Digital logic The PokeyMAX is built around the Altera MAX10 FPGA. This was chosen due to its integrated flash memory, power conversion, small size and low cost. The contained logic itself is described in VHDL and Verilog and then synthesized using the Quartus II software. Level conversion Most modern FPGAs no longer support 5V logic. While it is possible to find a few they are a vanishing breed. The MAX10 only supports up to 3.3V logic, so an IDT quickswitch level converter IC is used to connect to the high speed lines (A/D/IRQ/serial io etc) safely. Chip select Unfortunately I needed more level conversion lines than provided. TI came to the rescue with some 5V tolerant multi-function logic chips with which I was able to combined CS/!CS into one. Power The MAX10 requires a single 3.3V power supply, it then internally generates the rest of its supplies. This is very convenient, since often FPGAs require 3 or more different voltage levels. There is a switch mode regulator (LM3670) to convert from 5V to 3.3v in an efficient fashion. Paddles These are handled by charging a capacitor that we then check the level of using an LMV339. This is similar to the well-known LM339 comparator, except much smaller! The comparator is used since the level can be set very precisely rather than relying on when the FPGA detects a logic high. The level itself is set to 2.2v using the voltage divider on the right. It is also convenient since its open drain output means there are no level conversion issues. For the drain transistors, a 5V tolerant IO extender chip is used. The FPGA communicates with this over an I2C bus. Keyboard scan An IO extender chip drives the 6 keyboard lines and then reads the response. This is convenient since it only requires an I2C bus to the FPGA and the IC is much smaller than the level converters. JTAG The core may be upgraded or debugged using an Altera USB blaster connected here. Several of the JTAG pins are dual use and can be used as general IO. So we could for instance in future plug in i2c devices here or use for A5 (with external level converter) to allow quad pokey or sid etc. Audio filter The audio output uses a delta sigma dac. An RC circuit is used as a simple audio filter to smooth the output from this. There are four audio outputs, which are currently fed to pin 37 and 3 header pins (left/right and mixed). Note that the next stage much not draw a lot of current from the rc filter or it will cause distortion. A4 Pokey has 4 address pins (A0-A3). To make space for a 2nd pokey another address line is needed. For stereo connect to A4. Errata: Note that the "paddle capacitors" should not be populated and RA1 should be 0 ohm since these are already on the main board, this was a schematic error.
  17. Thanks to the efforts of foft (Mark Watson) and his Atari FPGA project, there is an open source FPGA pokey implementation available. As a little Easter bank holiday project, I thought I'd have a go at using it to make a dual pokey cartridge using a prototype of the Ultimate Cart as the starting point... Two of the fpga pins act as audio left and right, and I've hooked them up to a low pass filter on some perfboard, along with a 3.5mm stereo jack (which leads to my TV's audio input). It was pretty easy to make a firmware for the Ultimate Cart that included two of foft's pokeys, his DAC and a bit of VHDL to hook them up to the cartridge port. Then I modified TMC and RMTPlayer (with a hex editor) to output to the two pokeys at $D50x and $D58x. I guess technically this atari has 3 pokeys now (one inside, and two on the cartridge). The two pokeys use about 10% of the Ultimate Cart's FPGA, so there is plenty room for more. This was just for fun, and perhaps to show a little of what is possible with a FPGA hooked up to the cart port. To make a proper external dual pokey, we'd probably want to use ECI+Cart port, so the pokeys could appear in the correct places in the memory map. MP3 of TMC playing via the dual pokeys attached. SynthyGambol_vhdl_pokey.mp3
  18. From the album: UPduino V3 projects

    The orange wire connects pin 23 to ground. This pin is reset, high level = reset active.
  19. Announcing a TI-99/2 on a FPGA. It uses an open source FPGA board, the Radiona ULX3S: The board has a GPDI connector that can be used to send video to an HDMI display and this is used by the TI-99/2 implementation. The USB2 connector is used to hook up a PS/2 keyboard. The TI-99/2 uses only a fraction of the board's capacity. It could easily hold a TI-99/4A, or a Geneve or TI-99/8. In fact, it can run a Minimig Amiga or a simple Linux. Unfortunately, the board is currently sold out, but a new production run is planned: https://www.crowdsupply.com/radiona/ulx3s The TI-99/2 code is written in Verilog and can be synthesised using the open source Yosys/NextPNR/Trellis tool chain. The full source code is here: https://gitlab.com/pnru/ti99/tree/master/ti99_2 Output is to the GDPI port and sends an HDMI compatible video stream in VGA resolution (the 256x192 pixel output area is doubled both horizontally and vertically, so each TI-99/2 pixel is 4 VGA pixels). Input is through a PS/2 keyboard (or a PS/2 capable USB keyboard) hooked up to the USB2 port. Cassette I/O and the HEXBUS interface are not implemented. The implementation is of the 32KB ROM version of TI-99/2. The system has been set up with 32KB RAM. All code is plain Verilog and should be easy to port to other FPGA boards. A standard (black&white) VGA signal is generated internally, so it should not be too difficult to run it on a board with a VGA connector. Many thanks to @mizapf and @speccery for their kind help in getting this done. Enjoy!
  20. We're possibly only a few weeks until the release of a new Intellivsion console with a built in flash cart! Actually the console is already released, it's the Analog Nt Mini. It's not a common console, it's a very special one because it's a FPGA console. That means the hardware isn't based on the Nes or any video game hardware. FPGAs are programmable and thus they can simulate any hardware, including the Intellivision! It's not emulation! Kevtris, an AtariAge member, is releasing many systems for the Analog Nt Mini. Here is the thread where he's posting new platforms for the Nt Mini: http://atariage.com/forums/topic/242970-fpga-based-videogame-system/page-1 Beyond the Intellivision core, Kevtris is also planning to make adapters for cartridges and controllers! You can check his work on Intellivision in his youtube channell.
  21. What is your thoughts on FPGA arcade board replacements? For those who don't know a FPGA is a special chip that can be programed to actually become other chips so it can emulate hardware in hardware which can come close to a perfect re-implementation or replacement if done right. Unlike MAME you can make the chip run at the same speed and act and load the ROM in the same way and have the same exact bugs and you can update the outputs to more modern outputs like Displayport, HDMI or just regular VGA. There are current projects that have re-implemented some games and there are even replacement boards on the market. I know there is a Williams multi FPGA board and a Berzerk FPGA. There also is the MiST FPGA project that is implementing arcade chipsets with some that are Works In Progress. What are your thoughts on this? Is this okay to preserve faulty boards like Berzerk that may not survive much longer. Which boards or games do you think are in need of an FPGA implementation? What are your thoughts on this in general?
  22. Hi All, I thought I'd post to announce my new hardware project - I'm building an SD-card based Multicart. https://youtu.be/PjkCTXqirv8 Although its far from being finished, it already shows the available ROMs/CARs on the SD card on an Atari menu, and will then reboot to the selected cartridge. At the moment it only supports 8k ROMS and 8-mbit Atarimax ROMs, with bankswitching etc, but I plan to support all cartridge types soon. Adding a new ROM is simply a case of copying a new file to the SD card - no more flashing ATRs etc. Not sure if there's any other available hardware that currently does this? I don't have an SIDE or MyIDE. The hardware is a Altera Max 10 eval board, with my 3.3v cartridge breakout board attaching it to the atari. There's an external 1 megabyte SRAM which cartridges are copied to. Initially the atari boots to a small 8k boot ROM which is stored in dual port memory on the FPGA. The FPGA is also running a soft-cpu to copy files from SD card to SRAM. I'm planning to make a PCB for this next, with the aim of fitting inside a standard cartridge case. Never done an FPGA board before, so that may take me some time. The boot ROM is also far from finished - I'm having to learn 6502 from scratch. There are some other possibilities for this too - the same cartridge could be re-programmed e.g. as an atari co-processor/accelerator board. I'm planning to leave a JTAG/USB Blaster header on the board to make this easy. Robin
  • Create New...