All Activity

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:

Yup, I knew about the kicking. It has a rather short range, but it's effective with practice. I've seen people play Kickman in the arcades, but never tried it. Not sure how it compares other than the Pac-Man references like @carlsson mentioned.

The A8 certainly has some tricks up it's sleeve when it comes to cramming colours in. Check out the likes of Graph 2 font and also the Windows Rastaconverter too, which use a lots tricks and processing (especially Rastaconverter), to produce some astounding static images. With Graph 2 font, (more here), they are painstakingly created by hand and the images are smaller in file size and don't take up much CPU power. A few examples. G2F also can mix graphics modes (the skull is a difference graphics mode/resolution to the rest of the image): Rastaconveter (RC) uses modern computing power needed to computate the millions and often billions of variations needed to create images, where they then get outputted as an executable XEX 20-22k file to then load/run on any A8. Downside is it take up a lot of resources, (using a combo of the aforementioned DLIs, then Player missile graphics (PMGs), Vertical blank interupts/CPU processessing cycles, etc to get up to 9 colours per scanline - resulting in theroretically images with up to 128 colours. I've only managed 113 on screen. The downside is that the images are on average 22k each, and because they take up so much of the A8s resources, it means they aren't really able to easily be integrated into actual games... although... recently we've had International karate enhanced, with RCX versions of the game with new backgrops added, which are RC created and look utterly amazing: https://forums.atariage.com/topic/352421-international-karate-rc-and-rcx-cartridge-conversion-all-in-one/ I am a rastaconverter nut. The Windows software came out around 12 years ago, and thousands upon thousands of images have been created. And recently the original coder who made the software, Ilmenit, and some other dedicated geniuses, have improved the tool. Check out these amazing RC conversions, where these images will run off real A8 hardware(!): IMHO, the biggest scope for RC images is in graphic adventure games - and - if in the right coder's hands, there is potential for point and click game to utilize RC images as part of the games. In fact, years ago - the creator of RC (again the aforementioned Ilmenit), created a Windows tool to create point and click adventures, called Adventure studio. It still needs some coding knowledge, but it had so much potential. Check it out:

You're talking to someone who has done a conversion that ran for 6 months +. During that process, changes would often stop completely for days or even weeks, and then suddenly start back up again at a solid rate. I've also run conversions for 1 to 4 months, and used solution values of 25,000 to 50,000. So, when I say "you'd need to leave this one run for quite a while", I'm talking about something completely different than most people.

Atari heavy 6 Atari light 6 Atari 4-switch Vader Atari Jr. small rainbow Atari Jr. Long rainbow Atari Jr. with 64 games built in (from Argentina, I think) Atari 5200 VCS adapter Sears Telegames 6 Sears Video Arcade II Coleco Gemini Colecovision/Atari2600 adapter module Intellivision/Atari2600 adapter module ...and multiple copies of each. Just in case. -Ben

There's quite a few games that do it, the Master System has a very solid scanline interrupt system that can be configured to generate interrupts every N'th scanline which definitely helps. One unfortunate thing is that you can't change vertical scroll mid frame, so that definitely limits how many fancy scrolling effects you can pull off. One of my personal favourites though has to be the first 2 stages of Aladdin, with a mix of scanline interrupts and animated tiles they created a pretty impressive 3D effect.

Agreed, I have IP and know how it feels when someone rips off your hard work, but at the same time, I try to contextualize things rather than just looking at things from a black / white viewpoint. As mentioned in the video, entities such as Konami were even involved in the whole mess back in the day, likely for the sake of getting people familiar with their brand. I guess what all my entrepreneuring has taught me is that people who steal a product (i.e. software, digital music, etc) likely weren't going to be a paying customer anyway, so the damage and loss of sales is not necessarily what we may think it to be. Anyways, I'm with Tanooki on this one - if these were modern items my feelings would be quite different, but they are historical artifacts from a time long gone by. As mentioned in an earlier post in Taiwan no one buys bootleg stuff anymore, you don't even see it. Even at the culture markets and what not, everyone is selling official cartridges, and these are also being used at retrogaming conventions, etc., despite the majority of the locals not having access to such official cartridges as children or young adults due to financial reasons. Now everyone buys and uses official items though, as now people can afford them. If some regions decided against allowing the sale of bootleg games, yet the locals (aside from the rich) couldn't afford originals, I reckon such regions really wouldn't even be gaming regions at all in today's society. So in that way, we waded through some IP theft playing the long game, knowing that we could reach new customers and access a new market once the country develops and salaries increase.

Hi All, The IDE board in the MPEB format has been created, I am leaving some real-estate for possible 32k Sram, RS232 or MIDI, so any suggestions would be appreciated. I would like to think this board with the extra functions would a very usable TI system. Regards Arto.

You could do an alternative version. The game saves all its settings as a PlusROM. So if you change the color combination for a game, the next time you start the ROM, it will show this combination.

My installation (done by a friend) turned out great. I was worried that miniHDMI might not fit in the RF hole, but it did. 🙂 Some photos and screenshots below.

1. Yes, the AGSP boots normally, but is essentially still in factory default mode because the games.db database will not update. Also, please note that the "update_db" flag in games.ini is still set to "1", so it seems that the AGSP does not even recognize the file. 2. Yes, the games.ini will work after that point if modifications are made manually in a text editor, but it will not be recognized if any modifications are made using AGSP Enhance.

Thank you so much for the tips on extra moves in the game! Looking forward to playing it today. 🙂 - James

Has anyone tried modifying the default Lynx palette in Mednafen? In the documentation, it says: Global Filename: Description: lynx.pal Atari Lynx 12-bit BRG 4096 RGB triplets I'm not sure how to physically lay out a file like this in practice, since Mednafen doesn't provide lynx.pal as a reference. Has anyone messed with this before? I find that Mednafen colors seem "washed out" compared to Handy, which might be more accurate to the real Lynx unit but not as enjoyable to see on an emu.

The 9-track tapes I have were read with an M4 Data 9-track SCSI drive I have. Tapes were converted to digital files, then extracted using specialized programs. The main way I do it now is restore the data on my tape images to the virtual VAX (SIMH) then use FTP to transfer the files to my PC.

Atari Blast! shows some graphic modes.