Asmusr

I use a USB to serial converter to connect my TI/nanoPEB to a PC using CFHDXS1.

I can't figure out why the sideways cars are appearing, but I have made a few changes in the latest version and I don't think I have seen one (sideways car) since. I have also prevented the shots from hitting the oil. The shot collision is based on the hardware flag, and I think it works pretty well, but there are always problems with fast moving sprites. Regarding collisions between the other cars I don't process more than one collision each frame to save CPU cycles, so it's possible that some are missed.

Is it possible to turn a sidecar RS232 interface (PHP1700) into a HDX interface?

Thanks, this version has the skip bytes added. Now you should always see at least one of the programs - also if your cart doesn't start up in the right bank. atarisoft-multicart-nodups.zip

The problem is not only on hardware. I think the last E/A#5 file of the last update (ROADHUNV) was corrupted. Here's a fixed version. Road Hunter beta 1-2.zip

Here's a version of the muticart with the duplicate menu items removed by corrupting every 2nd header as suggested by sometimes99er. Edit: Tested to work on hardware, but I had to try 5 different 379 chips before I found one that started up in the right bank. The other chips started up with Defender/Donkey Kong/blank/blank. I also noticed that after a soft reset the bank is wrong again, so the Multicart doesn't reappear in the menu. atarisoft-multicart-nodups.zip

I thought the Multicart menu program was supposed to remove duplicate entries. Tursi will know.

It's actually not that difficult to hack other Atarisoft titles (see attached). The titles I have looked at set up a word in scratch pad with the bank switching address (e.g >6020) and then XORs it with >0002 to alternate between >6020 and >6022, for instance. All you need to do is to find the LI R0,>6020 instructions and change them to select the right pair of banks. Ms PacMan was problematic because it also uses the pad word to control the ghost sprites. This means it must run in banks 2/3. Now, if I could only get rid of the duplicate menu entries... [Edit] The attached file contains a 64K multicart image with Moon Patrol, Ms PacMac, Donkey Kong and Defender. I haven't tried it on hardware yet, but should work as long as the 379 chip starts up in the highest bank. atarisoft-multicart.zip

Yes, take a look at the included Magellan files. Note that: 1. the road must have the same width all over, 2. the first 48 patterns (the road) are shared between all maps, 3. the colors of all characters transitions must be valid according to the analysis tool, 4. the resulting "Assembler Character Transition Data" file cannot use more than 24 color sets.

But where would the program look for the config file?

For those interested, here are some technical notes about the game: The game runs at 60 frames per second (FPS), or 50 FPS on EU consoles without the F18A. Timing is done by polling the VDP status register. Interrupts are disabled at all times. All 256 bytes of scratch pad memory are used, but I save a copy of the original content and restore it before file operations. (Also remember not to overwrite the file buffers at the top of VDP RAM.) The maps are made in Magellan and exported using the "Assembler Character Transition Data" option. Because of the smooth scrolling, each unique pair of neighboring characters in the vertical direction uses up one of the 256 characters, and I need characters beyond 192 for the left side panel. Besides, the game is running in the normal graphics mode so to avoid color spills two characters next to each other must have compatible color sets. All in all this is a very limited platform for designing graphics. A map consists of 24 24x24 screens. A track consists of 104 screens in a fixed order specified using a list of screen memory addresses. The maps are 13.5 K each so they have to be loaded from disk for each level. I don't read the map in order to detect if a car hits the side of the road. For each track I store only the starting position of the left side of the road and the (fixed) width of the road. For each screen I store the direction of the road (left, straight, right) as one number. From this information I can calculate the position of the road sides at any point. Reading from VDP is kept at a minimum. Except for file operations I only read the VDP status register. The first 8K of the VDP RAM is used for storing character definitions, in 4 character sets each corresponding to a different scroll offset (0, 2, 4, 6 pixels). A routine is scrolling the original patterns and uploading the data to VDP RAM once and for all before each level. Scrolling is done simply by changing the address of the pattern table. After 4 times or 8 pixels I move back to the first character set and switch to another name table scrolled one character or 8 pixels. There are two name tables in VDP RAM (one at >2000 and one at >2400). I alternate between them each time I have scrolled the screen 8 pixels. I show one table while updating the other. To even out the work between frames I update 1/4 or 1/2 of a table each frame, depending on whether the scroll speed is 2 or 4 pixels. Copying from CPU RAM to VDP RAM is done using a routine in scratch pad RAM that has 8 consecutive MOVB instructions in the loop body. There are also two sprite attribute tables that I alternate between. Each frame I switch to one of the tables while uploading data to the other from CPU RAM. The CPU RAM copy of the table is actually stored in scratch pad memory. The game uses a flicker (reducing) routine where I cycle the quarter of the table that gets the lowest sprite numbers, i.e. the quarter that is uploaded to the beginning of the VDP RAM table. Sound and music is played using my own sound list player. This is based on the format of standard sound lists but also supports loops and calls. Allowing the 'drums' to play continuously without being disrupted by the explosions required a little special coding. Keyboard and joystick are read directly using CRU. A single call to KSCAN would reduce the frame rate by a factor two because of the delay. During game development I have continuously kept an eye on the number of CPU cycles used by the main loop using the debugger in Classic99. I find this essential if you want to make a fast moving game on the TI. It’s easier to fix any speed issues immediately than later when the code has become more entangled. The game is currently using a maximum of about 43000 CPU cycles out of the 50000 available in a frame, but on average only about 26000. There is currently about 2K CPU RAM left.

Do you mean that the software should ask each time it's opened?

Meh...

Since this is a programming forum it would be interesting to know about respondents' interest in programming (professional, amateur, novice) and it would also be interesting to know how many people are from the US/EU/anywhere else.

A few playing tips: Avoid crashing into other cars from the rear since this might send you into the road side. If you hit a car exactly in the rear center it will speed up to escape. Hitting other cars from the side is the easiest way to push them off the road and thereby crashing them. If you happen to hit a car in the front end it will explode immediately. You can also brake in front in the other cars to make them crash into you, but you will soon run out of fuel if you brake a lot. When you pick up a gun fire all you can, because once you hit another car you will lose it. Just avoid shooting the fuel drums or you may run out of fuel. If you just want to get through to the next level, pick up the fuel only and avoid anything else. Points earned: Shot hit: 75 pts, pick up fuel: 25 pts, pick up gun: 50 pts, crash other car from front: 100 pts, bump into other car: 10 pts, other car crash: 100 pts, fuel bonus: 25 pts per unit.

Thank you, I'm not planning on adding much more to the game so it depends on when we're content there are no more serious bugs. The latest version includes a demo mode that kicks in after 10 secs. It's very basic, the car just accelerates and doesn't attempt to avoid the other cars or the road sides. I have also tried to fix the problems mentioned by Kurt: 1. braking too slow, 2. finish line not recognized and 3. sideways car debris on the road. I have never experienced the second bug but I think that has been fixed. The third bug I have seen a few times after adding the collision between the other cars, and I have added code to prevent the cars from colliding outside the screen. I don't know if that will help but perhaps we can see what's causing the problem now? Regarding the cartridges, please don't get your hopes up that I'm going to start a production. All I have said is that I'm going to make a cartridge file for people to burn to their own EPROMs. Firstly I don't want to spend my nights soldering - then I can't do any programming. Secondly I only have a very limited amount of cartridge shells. Thirdly it doesn't make sense to produce TI cartridges in Europe and ship them mostly to the United States - I assume there are customs to pay in that direction too? But if anyone are interested in starting a not-for-profit production you're welcome to contact me. BTW, is a PCB layout for a 128K board available? I have used Fred Kaal's directions here to build one, but it would be easier to have the wire connections on the PCB instead.

I have uploaded a new version to the first post with a 3rd track (probably the last I will add). Let me know if you can reach this level. I want the game to be challenging but not impossibly hard... Other new features include: Extra life every 3000 points. Enemy cars collide with each other. This sometimes creates havoc on the road and makes the game more difficult. The enemy cars move in front of you try to knock you off the road - very slowly at the first, but speed increases with level. Watch out Kevan! Oil spills will not appear until level 3. Keyboard control (S,D,E,X,Space). Regarding questions: - Yes I think I will add a demo/attract mode to the next version, and perhaps a logo. I don't have any other plans for this game at the moment. - There will be a cartridge file at some point, but it will require 32K RAM. I'm also planning to make a 128K cartridge with Titanium, TI Scramble and Road Hunter together: The smooth scrolling trilogy. Regarding emulators, the game runs 100% smoothly on a real TI-99/4A. If you experience unsteady timing of sound or screen updates in your favorite emulator I recommend the latest version of MESS where the game is running as close to the real thing as you can get. Enjoy Rasmus

You need to change: MOVB @*1+,@>8C00 To: MOVB *1+,@>8C00

Press up arrow/joystick up.

Thank you for making it so easy for us!

Thank you. Note to self: always check Thierry's site first.

Is any part of VDP RAM save to use with XB (32K assumed)? Can you, for instance, limit the size of the stack? I'm thinking it would be interesting to write some F18A support routines for XB, but anything except palette changes and single page scrolling would require the use of extra VDP RAM. Two page horizontal scrolling, for instance, would require 2K.

It's a difficult one to replicate, but I think this might do the trick. The oil no longer has any effect when you're driving slowly, and I have also changed the 'spinning on the spot' to move you slightly left. roadhunt5.zip

Funny how disk access always causes problems. This should work on any disk, but only in the root directory. I have used the same boot tracking code as in Titanium. I have also renamed the map files. You will also notice I have added some drums.The trick was not to let them interfere with the explosions. I think it works pretty well... roadhunt4.zip

I have uploaded a new version to the first post with the following changes: XB loader for the Sissy 2nd track (water/beach) with a more narrow road Extended music. I decided to keep the Peter Gunn theme, but have extended it free style Bonus for fuel left when a level is completed There is currently no other difference between the levels than the tracks. After track two you return to track one. I'm planning on adding two more tracks: a winter/snow track and a night track.