gauntman

This is quick note to let everyone know that I have brushed the dust off of EnvisionPC and updated it to use a modern graphics library. This means that instead of a DOS binary, EnvisionPC 0.7 is a native Windows program, which is much friendlier to Windows 2000/XP. The Linux version is also much more usable. EnvisionPC can run in fullscreen and in windowed modes. A quick blurb for those who have not used EnvisionPC before: EnvisionPC is a graphics editing program similar to the old Atari program Envision. Features: -EnvisionPC is a full-featured charater editor and map-maker. It supports both native-PC files and .XFD disk images. It is mouse based, and includes all the standard editing methods (flips, fills, rotates, invert, etc.) -Support for all Antic character modes (ANTIC modes 2-7) -Edit 10 font banks concurrently -Edit map sizes of up to 512x512 characters. -Export to many popular formats: MAE, Action!, Mac/65 You can get the program and source code here. A few footnotes: It is a very surreal experience to read C code almost a decade old! Also, since libSDL is also available on the Mac, it should be possible to build a Mac version as well, if there is demand. Here are some screenshots to whet your appitite... Character editing and Map editing Bon Appétit!

Just verifying that you didn't miss the usual solution to the popping problem that was mentioned above - don't set the vscroll bit on the bottom line of the scrolling display. The following display list has information at the top and bottom, set for horizontal and vertical fine scrolling (although this was used in a MWP demo, so no LMS changes on each line -- however, the principle is the same) dlist .byte 112,112,112,64+2,<top,>top,2,0,2,0 lms1 .byte 64+$36,<screen,>screen .byte 64+$36,<[screen+24],>screen .byte $36,$36,$36,$36,$36,$36,$36,$36,$36 .byte $36,$36,$36,$36,$36,$36,$36,$36,$16, ; last line hcsroll only .byte 0,64+2,<[top+120],>[top+120],112 .byte 65,<dlist,>dlist top .sbyte " Top... " .sbyte " " .sbyte " " .sbyte "...and a line at the bottom " Notice that the last line above the text window only has the hscroll bit set, not the vscroll. No palette trickery is necessary (although, it is a pretty cool solution);

A quick primer may be in order here. When addressing in indirect mode, the CPU is actually using 2 zero page locations to determine the final address. So, when writing to address 88: LDY #10 LDA #33 STA (88),Y You are actually using addresses 88 and 89. Memory address 88 is the low byte, memory address 89 is the high byte. Basic code to do the same thing would look like: Y=10:SCREEN=PEEK(88)+PEEK(89)*256:POKE SCREEN+Y,33 Of course, the register Y is a byte, so you can only go 255 characters onto the screen using this technique. I remember running into this in Compute's old Machine Language for Beginners book, which was a pretty good introduction 6502 assembly code, but not so good for Atari specific items (Since the other computers of the era tended to have a screen always located at a fixed location in memory). What you need to do is when you want to go past the 256 character, is bump the high byte. However, modifying address 89 is probably a bad idea. So, you should make a copy, and use that. LDA 88 ; Make our own copy of screen address STA $C0 LDA 89 STA $C1 LDY #10 ; print a character at location 10 LDA #33 STA ($C0),Y INC $C1 ; Bump high byte, same as "adding" 256 to Y STA ($C0),Y; print a character at location 256+10 LDY #5 INC $C1 STA ($C0),Y; print a characater at location 256+256+5 This probably only makes sense if you are writing a routine to be called from BASIC. If you are writing a game or an application that has a custom display list, you would arrange you own display memory instead of using locations 88 and 89. It is then pretty common to use a look-up table to calculate the screen position. Does that help? If you would like an example using a look-up table I can write one up for you.

Asking what source control system to use is a bit like asking which text editor is best So, here are some personal opinions: SourceForge is okay, but has problems. The biggest problem is that SourceForge servers can be very slow -- and check-ins take time to propagate, sometimes over 24 hours. A second (much lesser) problem is that SourceForge uses CVS as a back-end. CVS is starting to show its age a little, but for small projects (like for 8-bit code) is probably adequate. SourceForge does have the benefit of being public, making it easily shared across lots of people (once a project is approved). As a backend, I prefer subversion to CVS. Subversion handles binary data natively, which is good for storing all the bitmaps, character fonts, etc. I use a subversion server set up in my basement for personal projects... It is not too difficult to set up a personal server, but sharing with multiple people in the outside world involves more effort...

Being primarily a lurker, I would encourage you not to drop the scene completely, Mux. Some of the most influential threads on pushing the 8-bit on the AA board have been either started by you, expanded upon by you, or shown possible via proof-of-concept by you. (I am thinking particularly of the MWP scrolling technique, the hard-synth thread, sprite reuse on a single line and -- yes, dare I mention, the MCS stuff.) I know that you have caused me to rethink what is and is not possible on these machines. I understand that real life must take priority, and if you are feeling discouraged, slighted or burnt-out please take a break from the scene. However, I am sure that most here would agree that we would like to see you back at some point in the future. Until then, good luck and take care!

Do you think it would be legal to use dynamically redefined characters as long as the basic shape was kept? (I am thinking soft-sprites here). Or does that violate the spirit of the competition?

I remember using an old type-in program for this ages ago - but cannot recall the original source (Antic, Analog, Compute!). However, a quick search of the Antic archives yields the following items... A Tech Tip from Antic magazine: Antic listing Actual code reproduced here: 10 OPEN #4,8,0,"D:AUTORUN.SYS" 20 FOR I=1 TO 94:READ A:PUT #4,A 30 NEXT I:CLOSE #4:END 40 DATA 255,255,0,6,81,6,216,24,173,48,2,105,4,133,204,173,49,2,105,0,133,205,24,160,0,177,204,105,162,133,212 50 DATA 160,1,177,204,105,0,133,213,160,32,185,49,6,145,212,136,208,248,169,13,141,74,3,96,0,48,47,43,37,0,24 60 DATA 20,18,12,17,18,26,50,53,46,0,2,36,17,26,33,53,52,47,50,53,46,14,34,33,51,2,226,2,227,2,0,6 This will run the program "AUTORUN.BAS". If look at the last sequence starting with "33,53,52..." you may notice that this is where the filename is encoded (A=33, B=34, etc.) -- you can chage this to whatever other filename you want, as long as you keep the number of letters the same. Probably easier to rename the basic file though. It looks like there is another listing that creates an autorun.sys to call any basic program: Another autorun.sys generator Hope this helps...

I am very interested in programming the FadeOut 2 project -- however, it would need to be written for the Atari 8-bit (then ported to the 5200). I could probably put together a proof-of-concept in a week or so for the 2 player version. Most of the graphics already produced should still work fine -- but we might want to modify some things (score, titlescreen, etc) to take advantage of the 8-bit capabilties. Of course, one of the appealing aspects of this game is that it takes advantage of the simplicity of the 2600 platform. Would there be sufficient interest in a version of FadeOut for the 800/5200?

Assuming that the output of cc65 is a true atari executable (one that could normally be run from the DOS "Run Binary" command), you should be able to use the command-line parameter: atari800Win.exe -run <file> I have this command set as a hot key in my editing environment, and it works well. If you are using cc65 with make files, I suppose you could even put it into the Makefile itself...

This is a very cool technique. I have looked at the example code a bit, and am pretty sure I understand what is going on... however, just to make sure, let me describe what I think is happening and you can correct me... 1) A special display list is built that reflects each line of memory 8 times (giving only 3 unique lines to be updated); This allows an entire sprite to be displayed by drawing only 4 characters per sprite instead of 4*8; 2) Each memory line points to a different character set that has the proper graphics strip in it. Each character set contains pre-shifted data necessary for smoothly moving the sprite. Display looks like this.... Line 1 (screen memory line 1; Character set 1 - top chunk of sprite data) Line 2 (screen memory line 1; Character set 2 - second chunk of sprite data) Line 3 (screen memory line 1; Character set 3 - third chunk of sprite data) ... Line 8 (screen memory line 1; Character set 8 - last chunk of sprite data) Line 9 (screen memory line 2; Character set 1 - top chunk of sprite data) Line 10 (screen memory line 2; Character set 2 - second chunk of sprite data) ... Line 24 (screen memory line 3; Character set 8 - last chunk of sprite data) So to move a sprite, the VBI only needs to determine what set of 4 characters need to be written to a single screen memory line (4 characters assuming a 12 pixel wide sprite w/smooth shifting), and the horizontal position to store them. Assuming that ABCD contains the 0 pixel shifted data; EFGH contains the 1-to-the-right pixel shifted data, and so on... A 5 frame cycle might look like: frame 1, screen memory line 1:ABCD frame 2, screen memory line 1:EFGH frame 3, screen memory line 1:IJKL frame 4, screen memory line 1:MNOP frame 5, screen memory line 1: ABCD Is my understanding of the demo correct? 1) Have you thought about how to handle independent vertical movement? This would seem to require removing the LMS hack and -- unless the sprites were very small -- removing preshifted graphics in the character set. At this point, are you required to return to directly manipulating the character definitions? and of course, 2) Is there another SMF demo waiting in the wings?

Here is my take on this label: (These are scaled down versions of the print ready labels...) It looks like everyone has similar ideas! I also designed this before I found this thread... (Is there a reason that none of the entries are on the actual contest page?) I really like the texturing and design of your label, manu_pk!

One thing to consider is the language you are working in. If you are writing in assembly, it is usually easiest to lay out the entire display list as you mentioned above. As an example: *=$4000 lda #0 ; clear screen ldx #200 clr sta bot+20,x dex bpl clr sta 710 ; set some colors lda #190 sta 708 lda #<DLIST ; set new display sta 560 lda #>DLIST sta 561 j1 jmp j1 ; wait DLIST .byte 112,112,112 ; blank lines .byte 66,<top,>top,2 ; 2 lines of ANTIC 2 .byte 71,<bot,>bot,7,7,7,7,7,7,7,7,7,7 ; 11 lines of ANTIC 7 .byte 65,<DLIST,>DLIST ; Jump to top top .sbyte " Antic 2 at the top " .sbyte " of the screen... " bot .sbyte " ANTIC 7 HERE " .ds 20*10 You can do something similar in BASC by storing the dlist somewhere as you mentioned. However, it can often be just as easy to modify the existing display list in place. I used to do this for quick and dirty title screens: For example: 10 GR.18:DL=PEEK(560)+PEEK(561)*256 20 POKE 710,0:poke 708,200 30 POKE DL+3,66:POKE DL+6,2 40 POS.10,0:?#6;"ANTIC 2 TEXT":POS.10,2:?#6;"HERE":POS.3,4:?#6;"ANTIC 7 TEXT HERE" 50 GOTO 50 Notice that in the above example, the OS does not know about the changes that were made. Therefore, even though the display looks like ANTIC 2, the OS will write to it as if it were ANTIC 7. Also, the display list is now short scanlines. This doesn't actually matter for some applications (like a title screen), but can for a main game screen. If it does matter, then you can carefully move the dlist around as shown in Atari Graphics and Arcade Game Design, Chaper 2 section "Moving the Text Window around" (Chapter 2); They give some code to do this here. It is not really necessary to turn off the screen before changing the display list, but if you are performing complicated manipulations in BASIC, it may be less alarming to the user!

Here is an example program that does most of what you reqested. Although fairly simple, the listing is long (although a chunk of that is comments), so it is included here as a file attachment. This example uses method b2) as Shawn described above to track which DLI routine to run. Note, that in addition to the two methods Shawn described, it is also possible to have the DLI watch the VCOUNT register to determine what to run. However, this is probably more trouble than it is worth. A few things to be careful of when implementing the screen you described: 1) Enabling horizontal and vertical scrolling in the ANTIC 4 window at the top of the screen causes a few interesting side effects; When the HSCROLL bit is set, ANTIC will grab extra data on each mode line. In addition, to prevent jumping or popping of the display, a buffer mode line must be put in place for fine VSCROLL. This is done by not setting the VSCROLL bit on the last mode line of the fine scrolling display. ANTIC will treat this as a buffer 2) When the DLI bit is set, ANTIC completes the mode line it is drawing, then handles the interrupt. Because of this, the interrupt must be set on he mode line above the one you want to effect. 3) ANTIC screen memory cannot cross a 4k boundry without a JMP instruction; There are enough 7+ (ANTIC $0e) mode lines to cross this boundry. Therefore screen memory must be carefully arranged to allow seamless access. dlist_demo.zip

Heaven, Notice that the 4k contest allows for larger the 4k foot-print in memory... so if you don't redefine the entire font set in the executable, you should have more room available. (Instead of the full 1024k for the fontbank, only store the portion you need); You *might* be able to squeeze in music and play routines into the extra space. I have only briefly examined the font site, but you might look at Font "nr 086" on the Graphical fonts site; This is a 16x16 font however, which will quickly eat space. Perhaps usable only for numbers; Also for an 8x8 font "nr 165" is nice.

I am working on a project (still under wraps until it gets futher along, no use announcing until it is further along!) that needs to be able to display large maps. The MWP scrolling method works nicely. Attached is a demo of my second approach to implementing the MWP. The first time, I used a method not unlike the one analmux posted earlier in the thread -- however, I become bogged down in the special cases, and eventually bagged that attempt. This approach is almost entirely table driven, and the kernel is straightforward. As such, I thought it might be useful for people to see another implementation of MWP. Included is the source code (ATasm/Mac65) and executable appropriate for your favorite emulator. mwp_demo.zip

On the order site, you mention that card-media cartridges are currently in beta... can you expand on this a bit? Would these be cartridges that take smart media (or compaq media, or whatever the favorite flavour of the month is) cards that can be programmed on the PC? What would the estimated cost and timeframe be for one of these?