All Activity

5200, 7800, Sega CD, Apple Pippin, CD32, 32X were all consoles not delivering what they initially promised. There is not really anything substantial that objectively would back up "worst console of all time". From the technological side, the Jaguar falls short of its potential but that is what keeps people interested.

General, GUI: doesn't make any difference. Fifty or sixty 'gray code' samples a second isn't going to result in a usable mouse pointer. Aside from the drivers examined at the beginning of this project, I recall a driver called 'Multi Mouse' published in Page 6 Magazine which was intended to interface with BASIC, etc, and that just put the machine into a blocking loop reading the mouse until the button was pressed. This of course worked perfectly well (since movement on both axes was being constantly monitored) as long as you don't need the computer to be doing anything at all while the user is moving the mouse around the desk. A great deal of discussion and development was invested in sampling the mouse at the highest possible rate using the least possible machine cycles, and experimentation showed that once the sampling dropped below 500Hz or so, it was crap.

Indeed, there's a lot of that in Colony!

Space Invaders is a pretty good title to have as a first Atari cartridge. My first Atari cartridge came with an Atari 800 Home Computer I bought at a yard sale, years ago. It was Caverns of Mars, also a pretty good first Atari cartridge. I can't recall the first 2600 cartridge I owned, but it was probably something ordinary like Combat, which is still a lot of fun to play as a 2-player game. Be careful, though. 30 or so years from now you may find yourself with more Atari cartridges than you know where to put them. Kinda like The Trouble with Tribbles episode from the original Star Trek series, only more adorable. -Ben

If you're ever at a party with a lot of women and you don't have any cards for strip poker, break out the old TI 99/4a and load up Strip or Skip. Everyone takes turns round robin style. Strip or Skip.wav

This is a great emulator nicely designed. Thank You! I am having an issue if anyone has an idea! Everything loads great! Seems when I load a more demanding Homebrew works fine the first time. If I switch games or leave the computer on and go back to a game it lags then speeds up even less demanding games will do this. But if I reboot the computer the first game I run works fine again. Seems like something’s not clearing out of memory maybe? I have no issues running all my other emulators MAME, RetroArch, Stella, …. Not the best computer but it runs plenty of games, programs with no issues. It’s not a gaming machine it won’t run the latest games. runs pleanty of Steam games. I tried a few suggestions in the thread DirectX and video to auto. With no luck.

This is the longest conversion I ran: Green Acres (I estimated 6 - 8 months continuously running).

One final question. You said you didn't want to do other projects. But are you willing to allow what you publish to be used by someone else to create a derivative product, yet not an exact clone? My question is if I get someone to read what you published so far on this, do I have your permission to have this person make a pc-15 game port connected version of a 16-way Intellivision joystick adapte In other words, do you okay him looking at what you've already typed and if he is able to easily make the substitution between two axis analog stick directly wired like you're doing, and pc15 game port control input, like what I want, are you okay with that? Just checking.

I'd say your going strong, like to see the SAMS as an option, but it's looking good.

Sure, I have both the bat-handle one and the interchageable handle one and they work great on the 2600+ after 35+ years. At first I had some errors with the bat-handle Wico, as it turned out its contacts on the plug didn't make a tight fit with the pins on the 2600+. Maybe these pins are a little bit thinner or shorter than my C64's back in the day, for I used that particular joystick on that computer, or maybe it was the constant port-swapping (a quirk of C64 games). The other one (interchangeable handle) was bought used some years later for my Amiga 2000, and always stayed on port 2. Anyway, I just did a bit of gentle squeezing on the plug, and then only had trouble with the "Right" signal, so I checked the Atari DB-9 Standard diagram on WikiPedia and inserted a single, very short strand of copper wire (obtained from a small-gauge cable) in hole Nr. 4, and the joystick worked great afterwards. In fact, when I (finally) got my official Berzerk Enhanced cartridge, I used that joystick, and now I use nothing else with that game because i get higher scores with the Wico bat-handle !

Cool, just played it a bit in JS99er

Asteroids DeLuxe: 7800 programmed by Robert DeCrescenzo is now available on the Atari VCS 800 store priced £4.99! You might also notice when you log into your Atari VCS account you have a new news notification “ News of April 26,2024" and within it some information regarding new game releases. I don't know if this is a new thing we'll be getting each month but pretty nice if you ask me 🙂

I wasn't talking specifically about the case with the GUI: I was speaking in general. I assumed various mouse routines I've seen that work as ML subroutines in TBXL were just run from the VBI. Maybe not though; that's just an assumption of mine, based on my perception of their simplicity. One that I had in mind was bundled with TBM Draw, which is compiled TBXL. It works quite well, and of course uses a PMG pointer, as most do. I don't think there's any source code available for examining the driver, though.

Very impressive port! Very nice to see the VBXE used to get Arcade perfect ports! How much time did it take to convert?

What I really find annoying to disassemble is code like this: jsr PRINT .byte "Hello World!", $9b jsr PRINT .byte "Press any key", 0 rts PRINT: ; get PC from stack ; print string from PC+1 up to $9b or 0 ; put adjusted PC back on stack rts I understand it's convenient for the programmer, especially with a macro generating the jsr and .byte sequence, but having to manually flag tens of regions of memory as data gets tedious very quickly.

Thanks everyone for your kind words and memories, it means the world.

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. 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 we store the source image? The F18A only has 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 resultions wasn't too 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. 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 the 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, would the sprites 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. And 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. 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 The F18A is not doing all the work, there is plenty left for the TMS9900: 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" other 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 the direction at that position and whether it's inside the track. 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 can also find the demo in https://js99er.net under Software/F18A specific. The source code is available from https://github.com/Rasmus-M/f18a-karts, and the cartridge binary is attached here. karts8.bin

Wow - that's pretty hardcore! I shudder to think of the heat this machine would produce if running a conversion for a solid 4 months. 450 to 500 watts continuous for 2,880 hours - I will have to respectfully pass on this one.

I used it with an Arduino Leonardo, then with a Sparkfun ProMicro (official knock-off of Arduino's ProMicro) and it works great, flashing the firmware with M. Heironimus' excellent Arduino Joystick Library. It works great on windows (right out of the box) and with TheC64Mini and TheA500Mini after some prep work involving Spannernick's excellent PCUAE usb bootloaders. So, in a nutshell, yes, the CX40+ is the real thing, no bull.

Updated WIP: Paddlefield (4K) by Thomas Jentzsch @Thomas Jentzsch | WIP Binary (20240426) | NOTE: Previously called Pong Wars / Inspired by "Screensaver" Pong Wars | Listing Updated: Apr 26, 2024

Nice! I briefly looked into this, and I noticed you introduced a Windows-only dependency for the colored text output. Perhaps you could just send ANSI escape codes instead so it keeps working on Linux, MacOS, etc.? Also, please only print fully formed escape sequences in one go, preferably even full "sentences" that end with the terminal in the original state, as currently it screws up the terminal during parallel builds (i.e. running multiple mads instances with make -j8).

Garry Kitchen said Audacity Games may have an announcement to make at CORGSCON on June 1st. I think this announcement could be about a cartridge release for Alien Abduction. Or you could always buy a VCS 800.

I've released 9.2.19. It has some refinements for TSFX and one bug in the tape image extractor is fixed. Coming next is TSFX and the standard tape records. The ambition is to have ability to create TSFX for everything that can be converted by the Standard plugin. The Standard Plus plugin is not in scope of this effort. I have some difficulties, but I am already getting help.

I'll just leave this here: