Jump to content

Search the Community

Showing results for tags 'vdp'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Atari Systems
    • Atari 2600
    • Atari 5200
    • Atari 7800
    • Atari Lynx
    • Atari Jaguar
    • Dedicated Systems
    • Atari 8-Bit Computers
    • Atari ST/TT/Falcon Computers
  • Gaming General
  • Marketplace
  • Community
  • Game Programming
  • Site
  • Classic Gaming News
  • 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
  • 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
  • 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
  • ZeroPage Homebrew's Schedule

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 7 results

  1. When I was working on my "L23Dump" package I noticed some strange behavior. I placed my PABs at the top of free VDP RAM, to avoid interfering with any PABs that the calling programs had set-up. For example, C99 sets theirs at 0x1B00-1FFF, if I recall, and Tom Bentley's TCIO uses 0x2000-2500. Anyway, I took the value at CPU RAM 8370 and subtracted the amount I used for buffers and PABs, then saved these VDP pointers in my program. Upon exit I restored the original top-of-free-VDP-RAM pointer to CPU RAM 8370. Sometimes the program would crash for no reason I could tell. Everything looked OK, until I realized that I had not set 8370 to the new top-of-free value. After that everything was okay. Naive me, I figured that the disk DSR would not stray outside the addresses that Thierry Nouspikel said they used. Obviously, I had not "reserved" the region of VDP RAM I had used for my buffers, and so I can see it getting nuked at some point. K-R.
  2. I'm thinking of using these routines I wrote to read/write VDP RAM. Are there any obvious errors? I was thinking of using them to avoid the BLWP that the TI routines use, along with the lack of zero-byte-count checking. These can also sit in the 16-bit workspace that C99 uses. Forgot to mention that these routines are called with BL @VSPEEK, BL @VSPOKE, BL @VMPEEK, BL @VMPOKE. I used these names to avoid conflicts with the Ed-Assem loader. K-R. * vdp.i (TI-name "VDP;I") */ * C'99 Rev#5.1.CC (C)1994 Clint Pulley & Winfried Winkler ***** VDP RAM read/write routines. ***** * File-name pointer is in R8. * External REFerences for TI linker. REF VDPWA,VDPWD,VDPDD * Address definitions to allow these * routines to function without the * TI linker. * * Read VDP data from this address. *VDPRD EQU >8800 * * Read VDP status from this address. *VDPSTA EQU >8802 * * Write VDP data to this address. *VDPWD EQU >8C00 * * Write VDP command or RAM-address * to this address. *VDPWA EQU >8C02 VMPEEK * Get multiple bytes from VDP RAM and * place them in CPU RAM. * R0 = VDP RAM start address. * R1 = CPU RAM start address. * R2 = Byte count. * Save caller's return address on stack. DECT R14 MOV R11,*R14 * Check count for zero. The TI routine * does not check for this. MOV R2,R2 JEQ VMEXIT * If zero, exit. * Save caller's registers. DECT R14 MOV R2,*R14 DECT R14 MOV R1,*R14 DECT R14 MOV R0,*R14 * Set VDP read-address. ANDI R0,>3FFF BL @VMADDR VMLOOP * Get VDP data and place in * caller's buffer. MOVB @VDPRD,*R1+ * Done? If not, get another byte. DEC R2 JNE VMLOOP * Restore caller's registers. MOV *R14+,R0 MOV *R14+,R1 MOV *R14+,R2 VREXIT * Restore caller's return address, * then exit. MOV *R14+,R11 B *R11 VMPOKE * Send multiple bytes from CPU RAM * and place them in VDP RAM. * R0 = VDP RAM start address. * R1 = CPU RAM start address. * R2 = Byte count. * Save caller's return address on stack. DECT R14 MOV R11,*R14 * Check count for zero. The TI routine * does not check for this. MOV R2,R2 JEQ VMEXIT * If zero, exit. * Save caller's registers. DECT R14 MOV R2,*R14 DECT R14 MOV R1,*R14 DECT R14 MOV R0,*R14 * Set VDP read-address. ANDI R0,>3FFF ORI R0,>4000 BL @VMADDR VMLOOP * Get VDP data and place in * caller's buffer. MOVB *R1+,@VDPWD * Done? If not, get another byte. DEC R2 JNE VMLOOP * Restore caller's registers. MOV *R14+,R0 MOV *R14+,R1 MOV *R14+,R2 VWEXIT * Restore caller's return address, * then exit. MOV *R14+,R11 B *R11 VSPEEK * Get a byte from VDP RAM and place * in R1 MS byte. * * R0 = VDP RAM address. * R1 (MS Byte) = Data byte. * Save caller's return address on stack. DECT R14 MOV R11,*R14 * Save caller's registers. DECT R14 MOV R1,*R14 DECT R14 MOV R0,*R14 * Set VDP read-address. ANDI R0,>3FFF BL @VMADDR * Get VDP data and place in * caller's R1 MS byte. MOVB @VDPRD,R1 * Restore caller's registers. MOV *R14+,R0 MOV *R14+,R1 * Restore caller's return address, * then exit. MOV *R14+,R11 B *R11 VSPOKE * Send byte in R1 MS byte to VDP RAM. * R0 = VDP RAM address. * R1 (MS Byte) = Data byte. * Save caller's return address on stack. DECT R14 MOV R11,*R14 * Save caller's registers. DECT R14 MOV R1,*R14 DECT R14 MOV R0,*R14 * Set VDP read-address. ANDI R0,>3FFF ORI R0,>4000 BL @VMADDR * Get VDP data and place in * caller's buffer. MOVB R1,@VDPWD * Restore caller's registers. MOV *R14+,R0 MOV *R14+,R1 * Restore caller's return address, * then exit. MOV *R14+,R11 B *R11 VMADDR * Send address to VDP. * This routine expects address in R0. * Send LS byte of address. SWPB R0 MOVB R0,@VDPWA * Send MS byte of address. SWPB R0 MOVB R0,@VDPWA * Return to caller. B *R11 EVEN K-R. VDP.i
  3. I stumbled accross this and thought it might be interesting to share: https://retrobrewcomputers.org/n8vem-pbwiki-archive/0/35845334/48860720/33053543/SRAM Replacement for TMS99x8 VRAM.pdf
  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. I've been playing around with user ISRs, and I'm somewhat puzzled by the result of this program: . main: lwpi ws li r0, handler mov r0, @>83c4 ; set user ISR limi 2 jmp $ position: data 0 handler: mov r11, r10 mov @position, r0 li r1, '# ' bl @vsbw ; standard implementation inc r0 andi r0, >1ff mov r0, @position b *r10 . This does not fill 2/3 of the screen, but simply displays two chars. Even more bizarely, the second char only appears after a couple of seconds. Now I realize that you probably wouldn't want to write to the VDP in the handler itself. In fact, I wouldn't enable interrupts in the first place but use vsync polling in my game instead. But can someone explain to me what is happening here? Is access to the VDP triggering another interrupt?! And what is causing the delay? (This is all in MESS, BTW.)
  6. Ladies and Gents, at the request of one of the members here I am posting some photos of the TIM video upgrade that was produced by OPA back in the 'day'. I have had this in storage since 1999 and used it during the mid-90's. Also find attached a couple of photos of the SOB that was sold to go along with the TIM and if you have PC99 you can play with the included SOB console grom upgrade, in it.
  7. Regarding a recent discussion on the various aspect ratios available to the stock console (or emulations thereof), there seems to be some clarification needed on what the actual aspect ratios are of the original TI output (both 60Hz and 50Hz). I say "needed" because, firstly, this info is very hard to find, and, secondly, there is a belief among some that the TMS9918, at least, has a 4:3 aspect ratio addressable pixel area with square pixels. This is not true, and, consulting the datasheet to solidify the numbers in my own mind, it is clear that neither the TMS9918A nor the TMS9929A employ use of square pixels. Most of the emulators I've seen use square pixels. Hopefully these numbers will be of use to someone else at some point. On page 5 of a document entitled TMS 9918A 9928A 9929A VDP Preliminary Specification 1981, there's this section: The hasty handwritten figures aren't mine; that's how I found this document on the web, and boy, it is not an easy document to find. Here it is for posterity, and, from this datasheet, plus the F18A documentation here, I've put together a side-by-side comparison of the different aspect ratios offered by each VDP. Remember that all of these are designed to send their output to a 4:3 screen. With the TI's addressable pixel area being 256x192, or also 4:3, you may think that this is a great match: 4:3 addressable area to a 4:3 screen = 4:3 aspect ratio. But no, the timings of the various analogue video systems have to be respected, so extra pixel rows and columns are required to border the addressable area. The 60 Hz VDP outputs an area of 284x243, although only 256x192 pixels are addressable, while the rest of the 'pixels' are set to a solid background colour. The 50 Hz VDP outputs an area of 284x294, although, again, only 256x192 pixels are addressable. Of course, there are no actual 'pixels' in the border area, but the pixel clock is running, nonetheless, and a pixel width is used as a reference in the above datasheet for the amount of vertical or horizontal space occupied by this area. The F18A outputs square pixels, as asserted by the chip's designer. However, square pixels (1.333:1) are a slightly different 'squeeze' to what you'd get from an NTSC console (1.52:1), and very different to what you'd get from a 50 Hz console (1.82:1). Given the numbers provided by the creators of all three products, the side-by-side comparison of aspect ratios looks like the following diagram: Personally, I most prefer the NTSC shape. It's a nice fit for the available screen area. The 50 Hz (PAL) that I have access to I.R.L. is too squashed in the vertical direction (or "short"), while the F18A is too "tall" for my liking. That being said, my previous sentence is merely my opinion, and not a slight on anyone nor any reason to take offense. I'm just stating a preference, and y'all are welcome to your own! Also, please note that results may vary, depending on the knobs and settings on your old CRT. On some of them, you can adjust H-WIDTH, and even V-HEIGHT is often a possibility. Both of those will alter the aspect ratio by squeezing or stretching the image. LCDs do a better job of remaining faithful to the input signal and not chopping anything off, but, if you fiddle with the menus, you can usually override that as well, depending on the monitor. If I've made any errors, please let me know!
  • Create New...