gauntman

Late to the party, but congratulations on this, Sheddy! It has been a long haul. The results are amazing.

This was indeed terrible event - a great contributor to the 8-bit scene, lost early. My condolences and prayers to family and friends.

You are advancing $d1 to much -- in single resolution mode, Player 1 is 256 bytes away from Player 0 -- so, only increment $d1 once. actually, looking at the code, you could use direct storage instead of a zero page, something like this: ldx #0 ldy vpos drawLoop lda shape,x sta $8200,y lda shape2,x sta $8300,y inx iny cpy #10 bne drawLoop You might want to flip your shape data, then you could decrement x instead of increment, saving a compare. But get stuff working first, optimizations can come later.

Some nice graphics there, thanks!

I really hate to drop NTSC support, since I am an NTSC user... I was always sad to see a cool game that I could not play on my own system back in the day. Of course, now most people probably can/do use emulators, but I still really would like to squeeze this into a game that I could have played back in 1986 on Christmas day! If worse comes to worse, I probably could double buffer and drop to 30 frames/sec - but that would require reworking a lot of logic code and the graphics system (the original UWOL worked at 25 frames/sec).

I am writing this in assembly, using the original C source as a guide. The actual game logic was not too hard to port - I am struggling right now with getting softsprites running quickly enough for NTSC. Currently, I am working on turning off the O/S to get more memory, which should allow me to unroll more code.

Does anyone have a bare-bones replacement kernel that they would like to share? I am looking at needing to put one in place to gain access to extra RAM.

A fairly major bug has been reported and fixed. rmtmerge v1.0 did not properly handle song references to undefined tracks (this can happen with empty tracks). Version 1.1 that addresses this problem is attached - all users are encouraged to upgrade to this version. rmtmergev11.zip

Hi all, Here is a utility that may come in useful when pulling together multiple RMT songs into a single file. I wrote this as part of the UWOL project, where we had 10 songs. Merging the RMT files can save space, particularly if the files utilize many of the same instruments. This saved around 500 bytes. Here is a snippet from the readme file: Basic Usage =========== First, load each of the RMT files you wish to merge into RMT, and then save as rmt .txt files ("TXT song files"). rmtmerge only works on rmt.txt formatted files, not on native rmt files. Once you have saved all of the files you intentend to merge, run the following command line: rmtmerge file1 file2 file3 file4 This will load all the files on the command line, merge them, and save the result as merged.rmt.txt Next, load the merged.rmt.txt file in a text editor and remove any extraneous [MODULE] sections (there should only be one in a legal rmt.txt file). Finally, load the file in RMT, go to the Song menu, select "All size optimizations". Enjoy! rmtmergev10.zip

Slowly... the new year came a bit earlier than I anticipated However, I as a consequence of some of the work, I do have an RMT merge utility... see the programming subsection for details.

And.... I am back. Sorry for the scare. I was indeed on vacation. There are some parts of the world even in the mighty US of A that don't have Internet connectivity (well, or dial-up only). I admit I was starting to go through withdrawls. We should be hearing some exciting UWOL news by the end of the year.

And for graphics, there is G2F and I will put in a short commercial message for EnvisionPC.

Of course! I hadn't thought it would be that simple, I thought that the artifacts might be too noticable -- I will try at 1/12 and 1/6 and see if the music still sounds right. Otherwise, I will look at the more invasive suggestions from Rybags.

Hi all, Looking at the rmtplayer source code, I don't see anywhere that corrects for NTSC/PAL timings. How can I play a song at PAL speeds on an NTSC machine? Note: I want to be doing this during gameplay on a screen with pretty heavy DLI useage. Currently, I am calling the routine during the deferred VBI... moving to a busy loop watching VCOUNT is undesirable. How are other people doing this?

I recently needed RMT for a project I have been working on in ATasm. Attached is a port of RMT 1.28 for the ATasm assembler, in case someone else also finds this useful. From the readme.txt file: This is a quick-and-dirty port of RMT 1.28 to the ATasm cross-assembler. The original assembly code is by RASTER/C.P.U. Any errors in this version have probably been introduced on my part. This port has not been extensively tested yet - certainly not under all possible permutations, so there may still be some problems. The sfx demo from the RMT distribution has been also been converted to ATasm and is included as an example of how to use the source. One difference in usage compared to the XASM/MADs version is that ATasm will include the RMT binary directly instead of linking it. This requires the RMT executable header to be stripped. The header is simply the first 6 bytes of the file. Included is a very simple C program that does just that. This means that you will need to remember the address specified when exporting a song. Then, in the source do the following: *=$4000 ; or where ever the export was set .incbin "song.rmt.bin" ; a regular RMT export, with first 6 ; bytes stripped off As a general rule of thumb, if the sound is not working, probably you forgot to strip the header from the RMT file. rmt128-atasm.zip

Just chiming in to give encouragement to Fandal. It would be easy to be disappointed due to the contest results... however, do not give up! Your contributions to the modern A8 scene are really appreciated. It is obvious that you and Raster put a lot of time and effort into these games. Both Milk&Nuts and Robix are good games in their current state, with a bit more polish they could become classics. Robix in particular is a lot of fun to play, particularly with two people. Back in the day, my brother and I would have stayed up many late nights playing this (although now it is a bit harder since we live in different parts of the country). I look forward to new games from you in the future.

I think there was a program from Electronic Arts called Movie Maker. I remember making animations and telling simple stories with this.

As long as you didn't have them on the same line on screen at the same time, you would be okay... i.e. if you are scrolling horizontally, you could have a chest initially. As soon as that has scrolled off the screen, you could then show the tree, etc. This can be a bit tricky to manage, though, and requires careful map design.

Agreed - for text, mode 2 is much easier to read. If you are blocking out the entire row, all the players and missiles should be available (unless you have a cursor, or different colored text backgrounds) - so some nice portraits should be possible, using DLIs + OR'd colors. If you use the GTIA trick to split the screen, you will need to use Antic F instead of 2. The idea here is to delay until the right side of the screen, then quickly switch in and out of a GTIA mode. This confuses Antic and the rest of the line ends up in an Antic E-like mode (although the palette is a bit different then usual).

The code looks okay - my guess is that it is jumping because the code is executing several times before the screen refreshes. Moving by character steps is much faster in assembly than in Basic, so it is zipping 2-3 times before the screen can catch up. You will probably want to place the movement code (or at least the drawing) into the VBI - and most likely only execute every other frame or so. Alternatively, you could hook up to a timer or for now busy wait. i.e. for testing at the moment, just before the "jmp j1" j0 lda 20 and #7 bne j0 ; delay for 8 jiffies You may wish to change the 7 to a 3 for a faster response.

Hi Avram, The concept to wrap your head around when moving to assembly language, is that you are now in control - not the OS routines. So, while it is possible to call the OS graphics routines to set GR.12, it is more typical to set up the display list and screen memory yourself. Here is a small example... this actually is doing a lot more than necessary, including setting up look-up tables for plotting that is definitely overkill for this example, but might be useful for a larger project. *=$4000 begin lda #<scr ; start by calculating look-up tables sta $d0 ; at the same time, we will clear the lda #>scr ; screen sta $d1 ldx #0 c0 lda #0 ldy #39 ; clear a single line c1 sta ($d0),y dey bpl c1 lda $d1 ; store address into look-up table sta schi,x lda $d0 sta sclo,x clc ; update zero page to next line adc #40 ; 40 bytes per line sta $d0 bcc c2 inc $d1 c2 inx ; for all 24 lines... cpx #24 bne c0 lda #4 ; set some colors sta 708 ; make ANTIC4 slightly more readable lda #6 sta 709 lda #8 sta 710 lda #<DLIST ; finally, point ANTIC to new display sta 560 lda #>DLIST sta 561 ; Plot a character ldx #20 ; vertical position ldy #20 ; horizontal position lda sclo,x ; set up zero-page address sta $d0 lda schi,x sta $d1 lda #33 ; plot the character sta ($d0),y ; Plot a block ldx #8 ; upper corner ldy #8 lda sclo,x ; set up zero-page addresses sta $d0 lda schi,x sta $d1 inx lda sclo,x sta $d2 lda schi,x sta $d3 lda #34 ; plot the character block... sta ($d0),y ; warning - no boundary testing sta ($d2),y iny sta ($d0),y sta ($d2),y j1 jmp j1 ; wait DLIST .byte 112,112,112 ; blank lines .byte 68,<scr,>scr ; 24 lines of ANTIC 4 .byte 4,4,4,4,4,4,4,4,4,4,4,4,4,4,4 .byte 4,4,4,4,4,4,4 .byte 65,<DLIST,>DLIST ; Jump to top *=$5000 scr .ds 40*24 ; 960 bytes for screen sclo .ds 24 schi .ds 24 So, in this case, I created a display list for an Gr.12 screen, with screen data starting at the address scr ($5000). The book Atari Arcade Graphics and Design explains this pretty well in the early chapters, if you want more information.

The just-released-today version 1.07 of ATasm has a new experimental .BANKNUM operative that returns the bank number of a symbol. In addition, the .BANK directive has been extended to allow manual specification of actual and reported-by-banknum number. For instance in the following nonsense code: *=$4000 .bank lda #1 sta 710 jsr j2 j1 jmp j1 label2 lda #77 *=$4fff .byte $ff .bank ,2 ; assemble into next bank, report as bank 2 *=$4000 j2 lda #2 sta 712 rts label3 lda #77 .byte .BANKNUM j1, .BANKNUM j2, .BANKNUM label3 *=$4fff .byte $ff .bank ,0 ; assemble into next bank to keep obj in source order, but report as bank 0 *=$3000 j3 lda #64 .byte .BANKNUM j3 .BANKNUM j1 will report as 0 .BANKNUM j2 will report as 2 .BANKNUM label3 will report as 2 .BANKNUM j3 will report as 0 You can get the ATasm 1.07 release from the primary website or from the trunk of the sourceforge svn server. If the new features look solid, then the sourceforge site will also be updated with binaries and tags. Hopefully this new feature will prove to be useful.

The double-step algorithm could be interesting, because it plots the next two pixels on the line, which may reduce shifting masks. Most versions of this I have seen plot the line from both sides and draw to the center of the line (see for instance: here). This might eat up too much of the ZP on the 6502 - but drawing from a single side may still be a win.

Also, does anyone have information about using one of the banks for saving information, i.e. for save files or persistent high scores. I think the Ultima 4 image did this, but haven't seen documentation about how to do this anywhere.

In addition to the horizontal size mentioned above, the vertical resolution of the PM can also be changed to either single or double. Single resolution is one scanline high, while double is two. To match a pixel in Gr. 7, use double vertical resolution To match a pixel in Gr. 15, use single vertical resolution.