Search the Community

So today I wanted to try out my newly received strangecarts. Before I could do so I noticed that my daily driver TI-99/4a system is acting weird. This is what I noticed. 1. The system kinda works, as longs as there is no PEB box connected. If the PEB box is connected it locks up on a blank cyan screen while accessing my stock TI Disk controller 2. If the PEB is disconnected I get the normal TI-99/4a title screen. I can jump into TI-Basic. Fine so far. 3. If I start to type in a basic TI program like “100 PRINT HELLO WORLD” some strange behaviour happens: The string is not properly tokenized. I get some some replaced characters on screen and cannot run the program. All of this kinda makes me believe there is some VRAM problem. But here is the catch, it has an F18a onboard so my assumption is that the still mounted VRAM memory chips are not used anyway. Is that assumption correct? I will try to do a video in the next few days. So is this a VRAM issue or is this something completely different?

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

In January 2024 there was a bit of discussion about games similar to Mario Kart: https://forums.atariage.com/topic/359151-another-youtube-video/?do=findComment&comment=5382710 That made me wonder what we could do on the TI. @TheMole linked to a demo on the MSX1 using the TMS9918A VDP, but I soon came to the conclusion that in order to produce something playable on the TI we needed help from the F18A. The F18A supports two types of bitmap layers that would be suitable for something like this: a 4 color bitmap with up to 256 horizontal pixels and a 16 color bitmap with up to 128 'fat' pixels. I decided on the latter in order to get a more colorful display. The image below is not included in the demo, but shows what the F18A is capable of. 3D view Mario Kart uses the ability of the SNES hardware to scale and rotate a 2D image to make it look like 3D (aka. Mode 7). The source images could be as big as 1024x1024 pixels. I thought the F18A GPU would be fast enough to do something similar, but where would I store the source image? The F18A has only 18K RAM, and a 1024x1024 bitmap would take 512K! And it takes 12K just to display a bitmap that covers the whole screen on the F18A, so after displaying the bitmap there would only be 6K left for the source image and everything else, like sprites and the GPU program. My first approach was to build the source image from 8x8 meta-tiles, which again consisted of standard 8x8 pixel characters/tiles (64 x 64 pixels in total). The meta-tile map for a 1024x1024 image would then only take 256 bytes, plus 1024 bytes to store 16 meta-tiles, plus the space to store the tiles they consisted of. However, my attempts to use this approach turned out to be way too slow for the GPU (drawing an image took several seconds). For my next approach I looked at Mario Kart, which has a 3D image at the top and an overview image at the bottom (also 3D but seen more from above). Maybe I could have a 2D overview image at the bottom of the screen and use that as the source image for the 3D image at the top of the screen? The source image would have a much smaller resolution than 1024x1024 (actually 128x128 fat pixels) so the 3D result would also be much more pixelated. But the transformation from one bitmap to another could be done much faster than the attempt to use meta-tiles. And it turned out to work even faster than I would have thought, actually more than 60 FPS when generating a 128x64 pixels 3D image. It took a lot of time to figure out how to make a proper 3D perspective transformation without any distortion such as fish-eye effects, but I'm not going into details about that here. The resolution wasn't bad either, although nowhere nearly as good as Mario Kart. At this point I had used 12K VDP RAM, plus some more for GPU code in the upper 2K RAM. Background I also wanted a horizontally scrolling background (trees, mountains) at the top of the 3D screen like in Mario Kart. I decided to do that using the normal tile mode and the hardware scrolling of the F18A rather than the bitmap layer in order to speed things up and perhaps save some VDP RAM. I had already used 192 vertical lines (64 lines for the 3D image and 128 lines for the source/overview image), but here the F18A ROW30 mode, which expands the vertical resolution to 240 pixels, came to my rescue, so the top 48 lines could be used for the background and to display other information like time and position. First I added a single layer with mountains, which took little VDP RAM since I only needed 16 characters/tiles plus 6 rows of the name table to implement this. Then I tried adding another layer using F18A TL2 with trees that scrolls at another speed, and I liked it so much I couldn't bring myself to remove it again. Unfortunately that took up much more VDP RAM since TL2 cannot be displayed below the bitmap layer, so I needed space for an additional, full name table, with mostly transparent tiles. All that used about 1.6K VDP RAM, so now I only had about 2.4K left. Still better than using the bitmap layer for background, which would have required about 2 times as much RAM. Sprites The last part of the graphics was to look at how to do the sprites for the player's karts, other karts, and other objects on the track. At first, I thought I could use hardware sprites for everything, but a single sprite pattern in 32x16 pixels 4 colors takes 128 bytes, and for any kind of reasonable 3D scaling effect I would need something like 16 patterns per angle per sprite. Already one sprite would take up the VDP RAM I had left, so I decided only to use hardware sprites for the player's kart, which consists of two magnified 16x16 sprites in 4 colors. The other sprites would have to be scaled and drawn on the 3D bitmap by the GPU. I could foresee two problems with that: firstly the GPU might not be fast enough to also draw the sprites, and secondly, since there was no VDP RAM left for double buffering, maybe the sprites would flicker horrible when the 3D image and the sprites were repeatedly drawn on top of each other? Back in the days scanline renderers, where everything was drawn one scanline at a time, were sometimes used, but I didn't want to go into that kind of trouble yet. But again, it turned out not to be a bad as I feared. Even though you see some flickering, it's not, for instance, hiding important details to the player. But how I wish I had some more VDP RAM to do some proper double buffering... The hardware sprites for the player's kart took 256 bytes for the patterns plus 128 bytes for sprite attributes, now there was only about 2K VDP RAM left for the software sprites. The current demo only includes 6 different software sprite patterns: 4 patterns for the other karts seen from different angles, one for the green oil drum, and one for the stack of tires. Together they take up about 1K, so there is still a bit of VDP RAM left to expand the demo, but not enough, for instance, to make different patterns for each kart. I also used hardware sprites for the top display of time, position, and laps, and for the small karts at the bottom of the screen. Interestingly, the F18A allows you to choose whether each sprite is 8x8 or 16x16 pixels, but the magnification setting is the same for all sprites, so the bottom sprites are magnified 8x8 sprites with very few pixels. What the TMS9900 is doing Although the F18A is continuously drawing the 3D image and the software sprites, there is plenty left for the TMS9900 to do: Reading the joystick Moving the player on the track Updating attributes for hardware sprites Checking that you stay on track Moving the other karts "Uploading" kart data to the VDP Playing sound and music Speech For the player's kart movement I asked in the forum (https://forums.atariage.com/topic/362756-physics-model-for-car/#comment-5425008) and @sometimes99er suggested this approach https://github.com/pakastin/car, which I adopted. All numbers are stored as 8.8 fixed point numbers, where the most significant byte contains the integer part. To move the other karts, I created a low resolution version of the map, where each byte value determines a direction of 8 at that position, whether it's inside the track, and whether it's a checkpoint. In addition to that, each other kart has a base speed and a setting for how much it drifts. This is enough to move the karts around the track for the demo, but hardly enough to make them interesting opponents. So a lot more work would be required to change this from a graphics demo into an exciting game. And here is a video of the current demo, which looks much better on real hardware. You will also find the demo in https://js99er.net under Software/F18A specific, or use the attached file on your real hardware. The source code is available from https://github.com/Rasmus-M/f18a-karts karts8.bin

I hear a lot about this, but so far no sources for one. Suggestions?

Sorry if I unnecessarily create a new topic, but been a while since last visiting this forum as I cought up in Commodore projects instead of exploring my TI. Also has to find time and courage to install my F18A. But FINALLY did install it, and it works! Have to still explore sounds options via DIN cable, but video looks SUPER crisp on my Iiyama CRT. Did of course search the forum, but could not find a generic F18A Starting Guide topic or such, only a development one (which I might explore later but certainly not now directly). Did I miss one? If so, please point me to it. If not there: What are must have demos and programs to try? Did altready find the Zaxon and Cart demos, which look great.

Originally posted on FB... After putting it off for a few years, I finally made a nice looking VGA port for the TI99. Here is my design. I haven't yet tested it on a black console yet, but I am sending it out to a few people to try. It requires you to remove the original AV port and solder your audio wires to the board. And it also requires you to cut a rectangular hole on your console shell 60x16mm. More details to come. EDIT- Posted on Thingiverse: https://www.thingiverse.com/thing:6560819 Darryl

I'm finally getting around to installing my F18A, but the slightest bit of torsion seems to pop it out of the socket. I've now dis- and re-assembled the thing four times. A quick search doesn't seem to show this is a persistent problem, but I thought I'd ask anyway: do I bother trying a different motherboard? Or do I need to go to the trouble of replacing the socket with a machined one?

While trying my cartridge-to-breadboard adapter, I got this screen upon startup: What does it mean? The F18A is an original from 2012, not upgraded, in a silver-and-black console. When I unplugged the adapter the computer started normally. My adapter is this. I was using one of those fancy 80-pin IDE cables to connect to a couple of logic gates on the breadboard. K-R.

This is the development thread for my remake of the NES version of Super Mario Bros for the TI-99/4A with F18A video board. My current plan for this project is to make at least one fully playable level with sub-levels and all details of the original included. After that, let's see... The programming is done in TMS9900 assembly language without use of the original source code. The game physics is based on a guide found here, which has been a huge help. The graphics has been imported from the spriters resource and reworked in Magellan. The music has been entered by hand from the sheet music into Mod2PSG2 and is played using Tursi's VGM compression and playback library. The code is assembled using ralphb's Cross-Development Tools (xdt99). Testing and debugging is done in my own js99er.net emulator, and the program has been verified to work on real hardware. Note that the control is joystick only. Up is used for jumping and Fire is used for running. Use B during the game to turn the background on/off. This is the latest video, which is slightly out-of-date because it doesn't include the secret room: Latest version and source code attached (run E/A#5 MARIO1). Status 18 Feb 2016: World 1-1 including secret room fully implemented. MARIO.dsk Source-18-feb-2016.zip

I normally don't like to announce things before they are ready, but I can't keep making excuses to those waiting and asking about the next F18A board run. For the last 6 months, while requests for the F18A were trickling in, I have been working on a new version of the F18A, called the MK2, to solve the problems of the current board. At the point were I had enough requests for F18A boards, I was not quite ready with the new MK2 design, so I continued to avoid the direct question of "when do you think the next F18A run will be?" To not have to keep making excuses, and with apologizes to those who have been waiting patiently for a long time, I'm announcing the F18A MK2 now, about a month before it will probably be shipping. I wanted to do this so people would have some real status, and to help my conscience (Vorticon, I spelled it right this time... ). Here is a link to the long version of the story: http://codehackcreate.com/archives/592 I'll do the short and sweet version here. The primary features of the F18A MK2 are: * It is 52mm x 19mm, i.e. the same size as a standard 600-mil 40-pin DIP socket, so no tall-pins, short-pins, adapters, etc. will be necessary for it to fit in the host computers. * Digital video output (TBD, probably DisplayPort). No, there is no VGA, sorry. See my post above for the details on that. Digital video to VGA converters are available if you really need/want VGA. * Host audio injection into the video signal for those who can manage to connect one wire internally to pick up the system's audio and get it to a pin on the MK2. The MK2 will run the same core as the original F18A, and I am still committed to supporting, working on, and fixing the original F18A issues (there is a known problem with the interrupt on some systems, etc.) Future features based on the enhanced MK2 hardware. Access to these features will come with future firmware releases (I don't have time to do it all at once, sorry): * The MK2 has 512KiB of 10ns SRAM, i.e. basically 512KiB of VRAM. This VRAM will be available in a 9938-compatible way, and then some. * The MK2 has extra I/O, including the Mode-1 pin to make it possible to do the 9938-update to the 99/4A in a "TIM" manner. * More than double the FPGA resources than the original F18A. This means more possibilities for new stuff in the VDP. Other non-TI related possibilities: * With simple low-cost adapter boards to re-arrange the wiring, plus a firmware change, the MK2 can be used to replace other VDPs like those in the NES, the Master System, MSX2 (i.e. 9938/59 system), etc. * Stand-alone FPGA-based game system due to the on-board 9900 CPU and 14 extra general-purpose IO pins. * General purpose FPGA devboard. * More simple SPI-based host interface to use the MK2 as a video chip for simple micorcontroller projects, i.e. Arduino, etc. I plan to keep this thread updated with status and to gauge feedback. If all goes well, and if I have not just made a big mistake, I hope to have the MK2 shipping by late July. Ironically this will be exactly 6-years after the original F18A shipped! Some renderings and photos of the current prototype:

Hey all! After waiting for a F18A for a long time I finally got my hands on one. Install went well, and powering on the computer I now get a crystal clear image! However, I'm noticing a lot of things seem to be not working now. I use a FinalGROM 99 cartridge and I had it pre-loaded up with Super TI99 Mario Bros. Usually, before having the F18A when launching this I'd get a blank screen with the music from the game playing. Now after installing my F18A, I get nothing but a cyan screen. Some other games do work still, I tried alpiner which ran fine. Is there any known compatibility issues with the FinalGROM 99 and F18A?

On my F18A I only use the 5 pin DIN connector for the audio, so I tried to modify some old headphones to connect to this. However, the sound is EXTREMELY load. Should I just add a resistor to the circuit?

I still have quite a few users that signed up after the deadline and after components and PCBs were ordered. Although I ordered 10 extra, those were used, but I still have a few users still wanting the F18A. I can still get the FPGAs, so Preorder #3 will go through my webstore. https://www.shift838.com/store/index.php?rt=product/product&product_id=5

I’ve developed a conio prototype that otherwise uses libti99 with gcc. It is relatively quick in that vdp writes are aggregated eliminating setting the vdp write address for each byte. Screen scrolls are also faster as the parts of the display that have been written to are cached in ram thus eliminating the reads from vdp. I wrote this as most of my planned work is expected to be text based. But as one could imagine there’s several costs, being extra RAM, and about 2KB code. The RAM is about 1KB and will be around 2 in the 80x24 text mode of the F18A. I understand vdp ram access to be slowed mostly due to the fact that the stock vdp is busy updating the screen. Does the F18A eliminate much of the delay since it runs at 100MHz? The trade off of resources to performance in my implementation are significant and I wonder if the gains will pretty much be lost in using the F18A. I thought I read it has some sort of hardware scroll as well. Thoughts?

Pros/cons of this potential use case CRT model with TI-99 with F18 mod? https://www.ebay.com/itm/285325117937?mkcid=16&mkevt=1&mkrid=711-127632-2357-0&ssspo=2ec012N1Rui&sssrc=4429486&ssuid=l39khcOxRXm&var=&widget_ver=artemis&media=COPY

Here's a thing I've been playing with, and thought about putting it in a separate thread. With the help of @Asmusr I tweaked the f18a emulation in my local clone of js99er, so that it can now run in 60 rows, 80 columns mode. The idea was to see how I need to setup VDP memory to get stevie running in 60 rows, 80 columns mode and do refactoring for the different video modes (24x80, 30x80, 60x80, ...) This is still a work-in-progress and will never be officially released, but it does prove that it's doable. As a starting point I took the stevie build I made for classic99 where I use a character cursor instead of a sprite cursor. (Sprite cursor is possible, but will only get halfway the screen, due to 1-byte for Y in the sprite attribute table, so of no real use here) Anyway, the build for classic99 was also a hack, because I refresh the frame buffer each time the cursor blinks. That clearly shows here, because I'm dumping quite a bit of data to the VDP and it gets a bit slow. So, next thing to do for me is to get that cursor routine a bit smarter. You never know, maybe the f18a mk2 will support a 60x80 mode. I'm still wondering if it'd be doable on the f18a mk1 with a firmware update, but I think Matthew said it won't work because of VHDL already being chuck-full. 16K of VDP memory is enough though, as my demo shows. Enjoy the demo (VDP corruption at the end when turning on the ruler., but that's part of the fun. I still need to fix some things in stevie). js99er-20230123204409.webm

All, I have filled about 1/2 of the requested F18A (VGA) board orders over the last couple of weeks. (these are not the MK2! but the latest version for the VGA version with 1.9 firmware installed) I have enough parts left to fill the remaining users that have gauged interest and filled out my interest form: https://forms.gle/2MQAH79SUqqCuQGz5 If anyone else wants to be on the list for a second run, please go fill out the form. As everyone knows these Xilinx chips are getting quite expensive. I purchased 30 in the last batch, and to ensure they are not counterfeit I have to go with a reputable dealer that guarantees their authenticity. There have been a few users that have passed on their F18A simply because I never got a response when a notification was sent. If you are interested and receive a notification but for some reason are unable to purchase, please let me know, so I can immediately offer it to the next person in line.

Here’s something that crossed my mind this weekend. What if there would be a custom PEB card with a socket to install an F18a on. Thay way you could have a second screen, if one manages to tie up the VDP ports to other addresses. Obviously you’d need the software that goes with it and makes use of that second screen. (ok, got carried away with having a multi-monitor setup for my programming editor).

Hello all, I finished an F18a upgrade for a customer's TI99/4a. It works perfectly for about 10 or so minutes then it goes to a screen that says Matthey Haggarty dev screen and just starts blinking. Sometimes with a tone, sometimes without one. Pulled the computer back apart to see if there's anything I missed or an electrolytic got installed backwards but everything looks fine. F18a is installed into a machined pin socket on the board, not the stock one. The jumpers are set properly. I tried some different power supplies just to rule that out but ran into the same issue. If I let it sit for a few minutes then I can turn it back on and it will work for a little bit and start doing the same thing again. Almost like something is overheating but none of the other chips appear to be abnormally hot. Anyone ever ran into something similar? I've got an email in to Matt but I know he's super busy so I was hoping maybe someone here might know something or offer some help. Thanks!

I got more parts in this past week to build more F18A's (VGA version). If you signed up on my wait list below, then watch your email. If not and you want one go sign up. https://forms.gle/2MQAH79SUqqCuQGz5

I have not seen this anywhere, but I am wondering if there are any examples that can be used for changing graphics modes, colors, etc. with the F18A in C99?

I read the documentation and looked at the register excel file, but questions remains (and I'm assuming I'm doing something wrong in Stevie) What is the proper way to halt the emulated TMS9900 CPU in the F18a? Is it sufficient to use the IDLE instruction as last line in assembly program or do I need to halt the CPU in the F18a GPU by writing 0 to extended register VR56 (>38) ? What is the proper way to lock the F18a GPU after it has been unlocked? Is it sufficient to write >00 to extended register VR57 (>39)?

Hey Guys, Have just installed an F18A in a beige (non v2.2) console and whilst the image on screen is crystal clear, I am getting some herringbone waves (ground loop interference) on the screen. I am using a VGA to HDMI (USB powered) adapter as I do not have a monitor at the moment that has a VGA connector. I have tried the usual ground loop correction things like having the monitor and the TI plugged into the same wall socket etc. I have also tried a number of different brands and model numbers for VGA to HDMI converters. Some are better than others, but all have some sort of interference that comes in waves from time to time. I am considering ferrite beads on all of the wires, but I just need to get some to test. I am running V1.8 of the firmware as when I tried V1.9 there was some strange blurring effects on some spots on the screen. Also the herringbone waves were still there so I downgraded back to V1.8 which at least is clear apart from the waves of interference. I also made sure that there was no interference on screen with the original 9918A chip installed before I installed the F18A. I was wondering if anyone else had seen this issue and if anyone has any advise as to how to rectify? I absolutely love the F18A and I can't wait to see its screen without the interference. Thanks for your help. Cheers, mnielsenau

Hey, does anyone have experience with building an F18A from the design files at CircuitMaker? The soldering job seems doable, but is this the latest version and will it run with the firmware published on Matthew's site? Thanks, Hans

What is the proper way to reset the F18a extended registers so that they have the same values as after a clean power-up cycle? Reason I'm asking is that if you change extended VDP registers the settings stay active even after down a "BLWP @0". In this particular case I have a crash handler in my assembly program that resets the TI to a defined state. But obviously I do not know what was set in the F18a extended registers by the calling program before. Could keep track of any value written to the F18a registers, but with the many extended registers that may get cumbersome. In my last example I turn on position-based attributes, but obviously if I reset the TI, the screen is unreadable. I know how to resolve this particular case, but would prefer a generic solution.