Asmusr

A short intro music, then only sound effects. How does it sound on your MESS?

My Scramble clone, named TI Scramble, is now in a state where I dare releasing it for beta testing. There are both an E/A 3 version (TISC) and a E/A 5 version (TISCRAMBLE) on the disk, and I have also included an XB loader (thanks to Tursi). Most features of the original game are implemented, except the high score table which I don't consider that useful without saving the high scores (I want to keep the possibility of making a cartridge open). The 32K expansion is required, but apart from that it doesn't require any special hardware, perhaps it would even load from tape? You move the ship using SDEX, fire to shoot and Fctn to drop bombs. If you use a joystick the fire button is shooting and dropping bombs at the same time (which makes the game easier). In two player mode (press 2), player 2 is using joystick 2, but the keyboard keys are shared. If you have an F18A board installed the original 4 color (ECM) sprites will be used, otherwise it falls back to monochrome sprites that also look perfectly fine. Anything else including the scrolling is using features of the 9918A only. If you want to see the monochrome sprites on your F18A enhanced console you can hold down F when the game starts (this key is *not* available as a toggle when the game runs). Disabling the ECM sprites will also maintain your jumper setting for more than 4 sprites on a scanline. With ECM enabled this setting will be overridden to allow 16 sprites on a line. Regarding the sprites, the game is using a flicker routine to cycle the order of the sprites. To facilitate the implementation I'm maintaining a sprite attribute table in CPU RAM that is copied each frame to the VDP. Early in the development I decided to limit the number of sprites to 16, which made it possible to keep both the attributes and the copying routine in scratch pad RAM. Even if you can't afford this luxury and need to keep the attributes in 8 bit RAM I can recommend the general idea because it makes it so much easier to update the sprites, and it may also improve performance (this depends on many factors). Because of the high frame rate the game looks far better on a real console than in emulators, but it works OK in Classic99 (without the ECM sprites). In MESS there is a problem with the sound and with the keyboard control of player 2. It doesn't get past the opening screen in Win994a. I have tested it on my EU console with the 9929A, but not on a 9918A. One last note: Each time the level/map changes there is a short delay while the next level is unpacked. I discovered I could use the speech synthesizer to mask this delay by saying a phrase from the resident vocabulary ('ready to start'). Perhaps it could be changed to say something more relevant, e.g. UFOs approaching, but I don't know if this would require an interrupt driven speech routine (which is not an option)? Finally, a big thank you to PacManPlus, CyranoJ and SpiceWare for providing the original graphics. I hope you enjoy the game, and please let me know if you find any problems. Rasmus tiscramble-beta1.zip

Looks like you had a great time with the kids. But the one you caught looks like small fry to me... For the game, the open water sequences it looks like the graphics would be simple enough for smooth scrolling (9918A based). However, the scrolling would have to start and stop on 8 pixel boundaries, and the diagonal scrolling would have to be done by scrolling vertically 8 pixels and then horizontally 8 pixels. Since smooth scrolling would add lots of complexity to the code, would seriously limit the numbers of available tiles and color transitions, and would not really add anything to the game play, I would consider using 8 pixel scrolling instead. Alternatively 8 pixel scrolling could be used on the 9918A and smooth scrolling on the F18A using the scroll registers. If you want to investigate the possibilities of 9918A smooth scrolling, try designing some sample graphics in Magellan and then use the 'Analyze Character Transitions" tool to count the number of unique transitions (after making sure that the colors are OK). For my algorithms you can have a maximum of 128 transitions, and for 2D scrolling these must be shared between horizontal and vertical transitions.

It's coded in Java. The source is included.

My development of Magellan is guided by my own needs, but here are a few new features that might be relevant to a broader user base: * The most recently used directory is saved between sessions * The Replace Characters dialog shows the actual character images in the pick lists instead of A,B,C... * The export dialog shows the actual character images in the pick lists * Empty character patterns are now exported (Assembler Data) unless the background color is transparent I may also have fixed a few bugs that I haven't recorded. Rasmus magellan-1.8.zip

Thank you for the replies. Perhaps a simple solution would be only to execute the code every 4 or 8 frames? That should prevent another pause from being triggered immediately after one is released. I will try that before moving on to the more advanced solutions. If KSCAN is waiting an entire frame of 16ms that makes it useless for high speed speed games. 16ms is enough for scrolling, sprites, collision detection, sound, and input reading and game logic combined (actually Scramble only uses about 12ms). Edit: Just realized the sample code I posted was misleading. The first loop should not be there. It should jump to PAUSE5 if the key if not pressed instead of waiting .

This gives my an opportunity to post an old question that I was struggling with for Titanium and now again for Scramble. The code below if for a pause key toggle. It works fine to toggle the pause on, but when you try to toggle the pause off again it is often turned back on immediately after. I assume the problem is lack of debouncing, but how can you prevent it except by adding long delays? Even if I could, I wouldn't want to call KSCAN. * Test pause key P LI R1,>0500 * Test column 5 LI R12,>0024 * Address for column selection LDCR R1,3 * Select column LI R12,>000A * P key PAUSE1 TB 0 JEQ PAUSE1 * Wait for press PAUSE2 TB 0 JNE PAUSE2 * Wait for release * Do pause stuff PAUSE3 TB 0 JEQ PAUSE3 * Wait for press PAUSE4 TB 0 JNE PAUSE4 * Wait for release PAUSE5 ...

Hope you will fix it because it's driving me nuts.

When I minimize the Classic99 window with the 'Pause when window inactive' option enabled the last second or so of sound is played repeatedly. It also happens when the debugger is at a breakpoint. Is it only on my system?

Thank you, that will be very useful.

Thank you for the suggestions and I'm glad you like what you have seen so far. The colors are important, of course, but what's essential for me is to recreate the smooth scrolling and update speed of the original. I think that's what we need most on the TI. I would have liked to make the ground more colorful, and tried to make a one character thick border in another color, but soon discovered that it would take up far too many tiles. I only have 112 tiles available and they have to cover all combinations of horizontal transitions on a level of the game, which is about 256 characters wide. Regarding the sprites they will be monochrome on the old VDP, but if you own a F18A you will get the original 4 color sprites with vibrant colors. It looks really nice. I have already implemented the solution where shots and bombs are fired at the same time. It works quite well. You can also use the keyboard if you want separate keys. Is there a decent Scramble clone for the MSX? 'Some day' is not far away! BTW, does anyone know of a 'testbed' for developing sound effects for the TI? I'm trying to recreate the original sound effects, but it takes a lot of time to get them right when I have to assemble the project each time. I'm looking for something where you can easily play around with a sound list and export the result when you got it right.

Yes is does work with the Myarc disk controller, both floppy and hard disk, but only the hard disk root directory. It's beyond my skills to modify the DSRLNK function, but if I don't have some kind of boot tracking in Titanium it will only work from DSK1.

Titanium works if you enable TI Disk Controller support, see: http://atariage.com/forums/topic/165901-classic99-updates/page-28?do=findComment&comment=2830485

I though the BBCode mode would work the same as code tags? Now this is with code tags: BOOTTR MOV @>83D0,R12 * GET THE CRU BASE IN R12 MOV @>83D2,R9 * GET THE ROM ADDRESS FOR DEVICE SBO 0 * ENABLE THE ROM AI R9,4 * ADDING FOUR PUTS US AT THE LENGTH BYTE MOVB *R9+,R4 * PLACE THAT IN R4 AND INCREMENT R9 SRL R4,8 * RIGHT JUSTIFY LENGTH IN R4 LI R10,FILEDV * POINT TO TEXT BUFFER MOVIT MOVB *R9+,*R10+ * MOV ONE BYTE FROM ROM TO TEXT BUFFER DEC R4 * FINISHED? JNE MOVIT * NO, DO ANOTHER BYTE SBZ 0 * DISABLE THE ROM B *R11 * BRANCH TO NEXT SECTION OF CODE This is the code that fails on Classic99. It works on a real console with nanoPEB and also in MESS.

The only issue is that currently the simple GPU test is resulting in a false positive on Classic99 because it's implementing the GPU but not any of the other new features of the F18A, so you need an additional test to distinguish between Classic99 and a real F18A. I'm experimenting with reading SR14, the Major/Minor version status register. This returns a value like 00010011 = v1.3, which should never be returned by the 9918A status register if all sprites are turned off.

Titanium is no longer working in the latest version of Classic99. The 'boot tracking' code is going into a long loop that overwrites the RAM (because the counter R4 is zero): BOOTTR MOV @>83D0,R12 * GET THE CRU BASE IN R12 MOV @>83D2,R9 * GET THE ROM ADDRESS FOR DEVICE SBO 0 * ENABLE THE ROM AI R9,4 * ADDING FOUR PUTS US AT THE LENGTH BYTE MOVB *R9+,R4 * PLACE THAT IN R4 AND INCREMENT R9 SRL R4,8 * RIGHT JUSTIFY LENGTH IN R4 LI R10,FILEDV * POINT TO TEXT BUFFER MOVIT MOVB *R9+,*R10+ * MOV ONE BYTE FROM ROM TO TEXT BUFFER DEC R4 * FINISHED? JNE MOVIT * NO, DO ANOTHER BYTE SBZ 0 * DISABLE THE ROM B *R11 * BRANCH TO NEXT SECTION OF CODE Can anyone explain how to post formatted code on AtariAge?

Thanks for your kind offer and sorry for being so slow to respond. I would like to add some speech to my Scramble clone. We could start with the opening phrase "HOW FAR CAN YOU INVADE OUR SCRAMBLE SYSTEM?". How many bytes would a phrase like that approximately be in LPC? Thanks, Rasmus

Thanks. The first would be most useful to me. The important thing is to be able to see each video frame after it has been drawn.

Another one for the wish list: in the debugger to be able to run to next vsync. You can add your own breakpoint if you know the code, but it would be really nice always to have this available as a one key/click option.

Hmm, it's probably more complicated than I thought. Here is a guy who has made a Commodore 64 disk drive from an RPi: http://www.insentricity.com/a.cl/207/MakingARaspberryPiIn He has written a Linux Kernel Module to handle the timing.

There's a test here where the maximum speed using a native C library is measured to 14-22 Mhz. http://codeandlife.com/2012/07/03/benchmarking-raspberry-pi-gpio-speed/ I don't know if that would be enough? [Edit: note that the above test is for writing to a single pin, we need to do much more than that, of course.]

You can buy a 'IO Pi 32 Channel Port Expander for the Raspberry Pi computer boards' for £17: http://www.abelectronics.co.uk/products/3/Raspberry-Pi/18/IO-Pi-32-Channel-Port-Expander-for-the-Raspberry-Pi-computer-boards You can stack them if you need more pins.

When I'm done with my current game (Scramble) I'm very keen on working (together) on a project where a Raspberry Pi computer ($25) is connected to the side port of a TI for the emulation of various expansion hardware. The 32K expansion would probably be the easiest place to start, but the possibilities are endless (floppy, hdd, SAMS, HDX, RS-232, real time clock, ...). The idea is that anyone can buy a RPi and make a cable for less than the price of a single cart or nanoPEB without any expert hardware knowledge (perhaps we can't avoid a bit of soldering). The software side could be written in C or Java and could become a community project that anyone can contribute to. It's probably possible to have a custom TI case made for the RPi (it's not much bigger than a cartridge case). Do you know if anyone are working on this already? Is there any reason why this would be very difficult to do? Anyone want to participate?

Thanks, I hope Tursi will make a GPU toggle soon. Another question. Below you wrote that for multicolor sprites the first pattern plane contains the most significant bit of the color index: Are you sure this is correct, because I'm experiencing the opposite? I.e. with 4 color sprites I have to put the most significant bit in pattern-plane 2 and the least significant bit in pattern-plane 1. Otherwise the two middle colors of the palette (index 1 and 2) are flipped. I may bee doing something else wrong, of course, like setting the palettes wrong. Thanks, Rasmus.

JLE only works for unsigned values AFAIK.