hawk

I think it's a great discovery, but I'm a long way from needing to use it. Possibly it goes over the head of most members of the forum.

:!: Warning: Long Reply :!: I don't have a lot of experience in this area yet, but I thought I'd let you know what I have learnt after getting an Antic 4/5 concept demonstrator working. I prefer to declare my screens, display lists, DLIs and VBIs in an assembler file and export them. Then via a C header I use them in the C code. I then create a custom linker config file to align the segments to the appropriate place. Advantages of this method are that address references can be used when declaring the display lists, which are then resolved at link time. This means that the display list, screen and DLIs can all be moved around within memory without having to update the display list. This results in improved maintenance and understandability. (Two important points in my job as a Software Engineer.) .export _screen .export _dlist .export _dlist_data .export _dlist_next .export _dli .segment "DATA2" .align $100 _newfont: .include "myfont.fnt" _screen: .res 40x24, $00 _dlist: .byte 112, 112 .byte 68 _dlist_data: .addr _screen ; Adreess memory screen .byte 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, .byte 4, 4, 4, 4, 4, 4, 4, 132, 132, 4, 132, 4, 4, 4, # (5) 25 lineas Gr.12 .byte 65 _dlist_next: .addr _dlist _dli: <do something> rti If any of the dlist lines calls my dli, all I need to do is add the .addr _dli declaration in the display list. I also plan on replacing the display list numbers with a more meaningful declaration, again to aid clarity. As you can see, the initialisation required to setup the display list has gone. All I need to do is point to the new display list from C. The C header contains the following extern unsigned char screen[40][25]; extern unsigned char dlist[32]; extern unsigned char* dlist_data; extern unsigned char* dlist_next; Keep in mind that all these extern declarations in C cost no additional storage space, as that is already declared in the assembly file. Creating interlaced display lists is also very easy using this method. Just declare another display list and set the last address of the first to the first address of the last, and vice versa. One really big disadvantage of this method is that if you are trying to create a really small footprint for your program, you will find the space between the and of one segment (eg. code) and the start of the aligned data segment padded with zeros. Perhaps it is possible to declare the data at the start of the program, and the code at the end. The code could then butt up against the the end of the data. Someone else may know the answer to this question, I haven't tried it yet. The linker config file then looks like this MEMORY { ZP: start = $82, size = $7E, type = rw, define = yes; HEADER: start = $0000, size = $6, file = %O; RAM: start = $2E00, size = $8E20, file = %O; # $8E1F: matches upper bound $BC1F } SEGMENTS { EXEHDR: load = HEADER, type = wprot; CODE: load = RAM, define = yes; RODATA: load = RAM, type = wprot; DATA: load = RAM, type = rw; DATA2: load = RAM, type = rw, align = $1000; BSS: load = RAM, type = bss, define = yes; ZEROPAGE: load = ZP, type = zp; AUTOSTRT: load = RAM, type = wprot; } FEATURES { CONDES: segment = RODATA, type = constructor, label = __CONSTRUCTOR_TABLE__, count = __CONSTRUCTOR_COUNT__; CONDES: segment = RODATA, type = destructor, label = __DESTRUCTOR_TABLE__, count = __DESTRUCTOR_COUNT__; } SYMBOLS { __STACKSIZE__ = $800; # 2K stack } Personally, I prefer to not use poke and pokew commands. These can be replaced by C equivalents which are just a single assignment. #define DLIST (*(unsigned char*)560) ... DLIST = &dlist; /* Setup to use my new display list. */ ... For this problem the screen data or character data (I can't tell which right now) is probably crossing a 1k/4k? boundry. Setting up the linker config file to align the data to the appropriate boundry should solve this. I'm still working on my planned Console RPG, which hopefully will demonstrate the techniques I've discussed here with plenty of comments. Much of this I've learnt from all the examples of both CC65 and straight assembler code that people have kindly made public. As a result, mine will also be public...just so people can see where I've reused their ideas. Mike

As well as the samples that come with CC65, there is some good coding examples for the Atari 8-bit platform put into the public domain by a few of the guys on this forum. Check out the Jellybeans source code and the Greed source code. With these examples, I found that it didn't take long to get a demo together that used re-defined character graphics, and DLIs. Beef Drop also uses the CC65 suite, but is pure assembly code. One of them has an example of how to hook RMT in for music. But I'd have to agree with Heaven. Programming for these older 8-bit machines, even in C, is a lot more like embeded programming than application programming. It's important to know what sort of assembly code the CC65 compiler is going to create. For me, this is half the challenge...write C code that is efficient, even on an older platform. Just my 1.03c worth (2c less tax not including GST)

To the guy bidding 10k to ensure an auction win, better hope no one else gets that same idea. ~telengard This looks like an example of exactly what you're talking about. Snipe gone wrong! What's the bet that the guy who won it defaults on payment? (Maybe he's reading this right now )

You don't by any chance have a BASIC cartridge for it that you don't want? I bought one because it was my wife's first computer. But without a BASIC cartridge, all I can do is play the few games that we have on cartridge.

Atari_Kid, I can understand where you're comming from wanting to play the games on the original system for which they were intended. Hell, that's why I have so many retro computers in my shed. I even considered getting a GBC for my son, since you can pick them up reasonably cheap. But when it comes to practicallities of gaming on the go, you just can't go past the GBA SP. The bright clear screen...the folding design...the lithium rechargable battery. I've had mine for a couple of years, and was even starting to aquire a few classic GB/GBC games to play on it, but like you said, the carts hang out the bottom. I've had a Flash Cart since I first got it, mostly for playing with developing for GBA. Then I discovered the GB emulator for GBA. I'm now enjoying playing those GB games that I missed, without having to lug carts with me. My current favorite flash cart take SD cards, so I have a 512MB SD card. That holds a lot of games. I've also just started to check out some of the Game Gear games via emulation. I find the emulators that try to handle the TV resolution to be too ugly, so I'm sticking to the portable formats. Anyway, if you really must have the original machine, I'd go for the later design. It sounds like it has a clearer display. Good luck with you desicion.

I'd have to admit, although I'm not that active on either board, I'm currently monitoring both Atari Age and Denial. I'm learning about using CC65 for both platforms, and both forums are a great source of information. Everytime I start researching a new platform, I find a group of enthusiests who are continuing to develop for their favourite platform, whether it be hardware, software or both. I recently came across a group at SMSPower who continue to play with the Sega Master System, one of which I recently got working.

Here in Oz, Atari games were expensive, so I could never afford any. The only one I ever had was Crossfire. It was a single load.

Gauntman, is it possible to change the colours in the colour set associated with each font? Ooops...just found where to change the colours. However, here's a real challenge...is it possible to paste from the clipboard?

Cybernoid, have you had a chance to try porting this to your Zaurus yet? I'd also like to be able to run this on my Axim. I've yet to compile anything for the Axim yet, and wondered what sort of problems I could expect to come across. Gauntman, I've yet to try out the new tile mode, but that will certainly help me out with my current project. Thanks.

I've only played it on an emulator, on an under powered PC. Does the game flicker as much when played on real hardware using a TV as a monitor?

Great implementation of a classic game. I only played it in an emulator, which was a bit jerky on my old PC, but look forward to playing it on real hardware. It's an amazing amount of color that you squeeze out of the A8s. I also checked out some of your other games on your site. Equally impressive. I think it's very generous of you to include the source for your games so that others can learn from what you do. It's a shame I can't read Polish. Great to see the techniques developed in demos finding their way into real games. Keep up the good work.

Thanks for the response guys. I didn't realise they were so obscure. I thought they may have been a similar platform to the Colecovision, or Intellivision. The Wizzard was they only one that I know of that was released here in Oz. The others I only came across while searching for info. Maybe I'll try some more 6502 generic groups. I was interested in programming for it, but if it's that obscure, I may be better sticking to the A8s and VICs. Cheers.

I love the smoothness of the player animation. Great effort.

Hi All, I was wondering whether anyone here has developed for one of these machines. (They are all different names for the same machine). VTech Creativision Dick Smith Wizzard Funvision Hanimex Ramses They have a 6502 processor, and a TMS9928A display processor. I do not have a BASIC cartridge for mine, and was wondering if there was any other way of getting programs loaded off tape without BASIC. Alteratively, does anyone have a BASIC cartridge that they could spare. Thanks, Hawk

I've had a look at the screen shots of Ultima IV, but I haven't checked out the code. I've been trying to determine whether the additional memory requirements of Antic E are significant or not. The display list will be larger, making some of the other manipulations I want to do more complicated, but the single scan lines will make fine scrolling a text window over the map easier. The sprites will be the same resolution, so there is no change in memory requirements there. It's only that Antic E will allow more sprites without restrictions or "ferkling". The biggest hit, however, is in the screen memory. I was planning to load a whole map into screen memory, and to pan around it. This would be very memory hungry for Antic E, so is not a viable option. I would have to consider an alternative method of scrolling around the map. I might keep playing with Antic 5 for now, with the option of changing to Antic 4 if I decide that the screen looks too 'Chunky'. Thanks for the tips.

Thanks for that link, the game looks great. It's actually using 16x32 in mode 4. The demo I have been working on is currently using 16x16 in mode 5, which gives the same size sprite, but with less detail. For me, I think 16x32 would just chew up too much memory for storing the sprites. I was planning to use PM over/underlays to increase the number of colours. I would also like to have character set changes and colour changes via DLIs embedded into the map file format. But I'm not sure yet how achievable that will be. The target for this will be the A8, mostly because that is what I have. I'm developing it using CC65 and emulators for testing (as we all do) but I really like to see it running on the real hardware. To start with, the easy way out is to make it disk based. I'll keep playing with the idea for now and see how far I get. I'm getting lots of great ideas and techniques from the guys on this forum. Thanks.

Thanks for the links MrFish. I hadn't seen Irata's Quest before. I was trying to achieve the same look and feel as the Gameboy RPGs, which requires a bit more resolution than we have. The Nintendo RPGs have larger sprites, mostly 16x16 that have that great anime style. I like the look of the sprites with the darkened edges but this is difficult to do in 8x? pixels, hence the 12x24 size. I think 12x16 would look too squashed in mode 4. For the sprite animation, I would like to have a moving map, with the character sprite always in the centre of the screen, and always moving to the next whole tile, rather than the free-style movement of Zelda. I haven't decided yet whether to allow the character to overlap objects within the map, or just use flat collision detection. But since I'm planning to overlap the character sprite properly over the map, this should only be an issue of collision detection. But if you're going to allow the player sprite to overlap other non-base map tiles, the question then raises regarding the player being able to walk behind map objects. This adds a whole new layer to the map. As much as I'd like to do it, I sure that processing time and memory will be the issue. Being a console sytle RPG, I have to leave some space for the scripted storyline. Animation of the character sprite will require 12 chars (3x3 + 3), and if double buffering of the character is required to achieve smooth animation, that will be another 12, out of a possible 128 chars in a mode 4 char set.

Thanks A.J., but do you mean in the plug-pack, or inside the case?

Thanks for the reply cbmeeks. It 's just the XEGS. I've used a CBM 1701(?) monitor as well as a TV, and the results are the same. When I get a chance, I'll open it up and replace the electrolyic capacitors in the video circuit to see if thats the problem. The problem is not so much that the display rolls, rather that the interference rolls up the display. When the interference gets to the top of the display, it causes the vertical sync of the monitor to fail briefly.

Does anyone know of a tile based game which uses sprites that are 12x24 pixels in Antic mode 4? Some time ago, emkay explained to me the problem of 16x16 sprites in Antic mode 4. Console Style RPGs So I was planning to use mode 5. However, this left me with very few tiles on the map display. Mode 4: 4x2 chars per sprite (16x16) = 10x6 map tiles per tiles Mode 5: 3x3 chars per sprite (12x24) = 13+1x8 map tiles per screen Thanks, Mike

Hi Cybernoid, I just wanted to put in my 2c worth to say that your demo video looks great. I agree with cbmeeks, the lighting effects look awesome. I feel guilty just lurking here watching you guys put in the hard yards, but right now I have little to offer in return. I'm very interested in the progress of your project, as I'm attempting a NES style RPG, probably more like FF1 than Zelda. It's easier to do non-realtime combat, which is also my preferred style of play. Your project looks more like Diablo ported to A8. Anyway, just wanted to offer some words of encouragement...keep up the good work. Cheers, Mike.

I wonder how long it will take to hit Oz. Time I started patrolling the newsagents again. I'm still reading the last issue. Been trying to make it last. Glad to here it's comming back.

I think Cybernoid (Chris) has done this Yeh, I've had a quick look at his Jellybean code. But right now I'm still struggling with my tile mapping routine, so the sounds are a little way off yet. I haven't heard of the abc format. Does it have a PC Composer like RMT? Ooops! After a quick "Google", it seems that my last statement has been answered. I guess given that all these other tools are available, we'd just need a tool which could ensure that an ABC file was capable of being played on a particular target.

Hi Karri, I'm coding in C for the A8s, but I'm intending to use RMT. I think this differs majorly from what you are suggesting, as it is all implemented in asm, and links in it's own music format. I would just want the C to select the song, and start and stop it. I will also want to play sound effects in parallel if possible. We'll see. Cheers, Mike.