Mike Harris

OK, hate to say I stayed up last night but I did. I had to write my new map routine and I can say I am done with it. 4 bytes per row at 24 rows Here is a sample code that reads the bits BIT_DRAW: PUSH DE PUSH BC LD DE, BLOCK LD C, A BIT 0,C JR Z, RD_BIT_1 CALL DO_IT RD_BIT_1: INC HL BIT 1,C JR Z, RD_BIT_2 CALL DO_IT RD_BIT_2: INC HL BIT 2,C JR Z, RD_BIT_3 CALL DO_IT RD_BIT_3: INC HL BIT 3,C JR Z, RD_BIT_4 CALL DO_IT RD_BIT_4: INC HL BIT 4,C JR Z, RD_BIT_5 CALL DO_IT RD_BIT_5: INC HL BIT 5,C JR Z, RD_BIT_6 CALL DO_IT RD_BIT_6: INC HL BIT 6,C JR Z, RD_BIT_7 CALL DO_IT RD_BIT_7: INC HL BIT 7,C JR Z, END_THIS CALL DO_IT END_THIS: INC HL POP BC POP DE RET It took me a couple of hours and I had to write it into long form then I shortened it into a loop. You may say why but I went from of 12k down to 4 just by saving map data. My character is already moving and I have all my sprite data. So, I am estimating this will be either an 8 or 12k before more optimizations.

It's Christmas time so I will bug him after the holidays. Heck, I haven't even played around with my code because I have been busy running around. So, Merry Christmas everyone. If I don't say anything again don't worry, not like I'm anyone important anyway, I will be back after New Years. Cheers

Final thoughts because I am seeing that this page hasn't been updated in awhile. I noticed on the ADAM Music Box Demo that there was music for the pause routine in Rocky Boxing. Bug? Never implemented? Could or Should be implemented?

Adding two more cents that come from experience and dealing with a REAL Coleco/ADAM with REAL Cartridges that I bought way back in 84ish. I am old BTW. To put on your radar. Smurf Rescue, not talking about the undress Smurfette but talking about moving back and forth between screens can reset your system failure. It has reset my coleco with garbage on the screen and with the ADAM it reset and made my printer go wild. MR. Do's Castle, not necessarily a bug but may have more to do with not enough bytes for the score. When my hands weren't doing other teenage things I was pretty good and the whole game scrambled when I scored too high, maybe when it should have turned over. Destructor had a habit of freezing and crashing and that was one of my favorite games. Black Jack and Poker on occasion would give me two of the same cards. All of these games I am talking about are all North America, non CBS, non European. A lot of these titles, all of my games as a matter of fact, I still have on DDP that I ripped from original Carts using Assembly Language and Smart Basic. I may have Floppies but have no idea what is stored because although I kept the software and some other goodies I pitched my ADAM and Disk drives in the trash when I went into the military. Now that I am back in the scene "quote" "quote" I picked up two ADAM'S, one broken DD Drives and One Never used and never will be.

BTW...I hope you haven't been fixing tricks thinking they were bugs. Like in DK you can pause on a ladder and then go up faster. I think, been awhile, that you can jump under some food on level 2 and get it. Some of those tricks are favorites and add to the game play.

Reading the pdf I do not see the BC Quest for Tires 2 fixes listed elsewhere on Atari Age. I remember owning the original release and never having issues. I did discover the code to get me to the end on my own. Something to look into.

I personally think that a drop in replacement for the DD Drive would have been the way to go with built in flash memory that connects to any PC USB port. Drag and drop all disk and ddp images. And when I say drop in replacement that it would use the internal connectors of the DD drive as well. Cost effective? I know I would pay $200 for that device if the bugs were worked out and the damn screens back light stayed on. Maybe even a little more. It beats Ebay gouging for limited original disk drives.

I have often wondered why someone with a 3D Printer or other modern tools just do not created the Coleco Prototypes for history sake. Sure they are copies but would be able to work with modern internals. Put the spinner back on the Coleco Joystick or a stick with blue buttons. Personally I like the Coleco with the white face plate. This is not like we were 40 years ago. Hell, someone can actually make the original SGM and install the micro string drives which were nothing but a looping 8 track if you ask me.

Speaking of. What is on the market now that I can use to replace my DD and/or Disk Drives so I can easily transfer my work to a real machine for testing. All the usual outlets seem to be shut down and EBAY is the last resort which gouges the crap out of everything nostalgia. Until I pick something up I am stuck troubleshooting on an emulator. I mean seriously, they are making new stuff for the C64 and MSX that would blow your mind 30 years ago. I often wondered why there was never an ADAMNET hard drive/IDE interface designed by some 13 year old Chinese kid.

Does anyone know what happened to ADAMCON.ORG? I used to get lots of source material for programing and it went bye bye

When is the CV Programing guide for Assembly Language going to come out? It's more efficient and in some cases better in accessing low level systems. I know you geniuses that have been doing this for the last 20 years have routines you have collected over the years. Pass them on before you expire....Keep the legacy alive.

My next project I will post screenshots and/or video. I am keeping a log of sorts on my progress but I want you guys to be impressed with my first work without expectations. To my knowledge this port has never been done and it is 100% my own data. Aside from the few pushes from you guys when I get stuck on syntax and some BIOS function. I have the original source code but that only goes as far as the look of the sprites and backgrounds so I can be accurate. All the logic is all mine. This is also not some MSX port where it is a close match to the VDP. This is an Atari Cartridge and most of my issues now are scale in nature because the Coleco was a higher resolution. I am not saying this is easy but it is not difficult either. I taught myself some z80 routines many moons ago on the ADAM when it first came out in 83? 84? Then I graduated to the Amiga and tried my hand at 68000 and Lattice C. I ended up playing games more than programing but I am no stranger to computer logic. If anything, I regret not doing this back in the early days and maybe I would have made some cabbage instead of going into the military. Audience will come with reputation. What I am looking forward to is my name on an official Coleco Cartridge which will end up on the internet for all time. As long as there is an internet I will be remembered.

So far I have 40 rooms, 11 sprites, 2 sets of fonts, basic animations, partial movement. No serious optimizations in my code yet and am just at a 12.4k rom.

Awesome night... I should have slept but amazing breakthroughs Deciphered the color tables and added new routines to change the color of any pattern in VRAM with just a quick command. LD DE, BLUE_PAT CALL ROOM_COLOR LD DE, WHITE_PAT ect.... Where the room color routine writes directly to the patterns color address. I can define any two colors or one solid color for building walls. So I draw my map, building or what not in Black then color it with one command that writes whatever 8 byte color to all three color addresses. I can even cycle the colors to have flashing Atari like graphics. Neat huh.

Have my first sprite animations and now having to size up all 11 sprites to be proportional to each other and the rooms. I have a long way to go but it's coming along. I am thinking if there is more room once the game is completed I may tack on bonus features that extend the original game that I am porting this from but for right now that is the back burner.

Thank you a lot. I already created a new mirror routine that will not take up ram which I found out is a measly 1k so instead it mirrors at the time of printing to the screen. However, your help is extremely useful because I now know how to use RAM when I need it for my next game which I will be necessary. I also came up with a new routine, not implemented yet, that breaks down a screen to between 4 and 8 bytes per row. So that comes to 96 bytes per screen mirrored or 192 just by using bits instead of bytes. This is screen mapping and does not include patterns or color data.

Have my Character Sprite running around in at least 4 directions. Now trying to figure out how to read directly the pattern in VRAM into IX and IY so I can check if it can where a wall is. My approach in the loop is poll joystick, check (IX) (IY) pattern number If yes, move sprite, if no do not increment. When you create walls do you tend to check the pattern or the color? Does it even matter?

Starting my game loop now so I expect even more headaches.

Thanks... That's what I have been using but I found out that it's actually the emulator that is leaving the border blank. I tried it on BlueMSX and MESS. The colors are correct on those two.

Working on the maps now. I have already solved the MAP Compression and have gone from 26k to 11.4 in rom size with all map space accounted for. Now I have to figure out how to swap colors so I don't have to make two of each sets of each room. I also for the life of me can not change the border color in Mode 2. I have always just changed bit 7 in mode 1 which is the background color in mode 2. Does any of this have to do with the external VDP?

Well, if I am going to use up all 32k I want to give as much as I can. The maps I am producing for my first completed coleco game are so bland that all of this could be done in video mode 1. I personally have a sense that it would be lazy to render such bland graphics using 32k when there are games like Pitfall 1 and 2 that have so much in them. Also by developing this system of mapping it will be future proof for my second project. I will also hint that what I am doing are ports that have never been done on a Colecovsion and I hope you guys will be presently surprised.

Just an update. I figured out the mirror effect which I could literally slap myself of how easy it was. I changed from rendering an entire screen of 768 to printing one pattern at a time which save on blank area. Then I print out the first 16 places but at the same time printing another character on the other side but backwards as in... 31 - whatever column I am at. Do that 24 times and you have a screen. To further reduce I have changed my data so now I can render an entire 768 pattern screen using only 48 bytes of the same block pattern for my maze. It wasn't hard to figure out considering you only need 2 bytes plus mirrored to fill a single row or 4 byes non mirrored. So now I am absolutely sure that all of this and much more will be able to fit on a real cartridge. I also received my second ADAM today which I picked up for a couple hundred. Both DD drives have been sitting and as I feared the rubber on both counter wheels are deteriorated and they are jammed with goo. So I will fix them later with a trip to Walmart for some hot wheel cars.

Wrote a new parser last night that will compress all my maps down to the essentials so I can fit it all within 24k for at least 30 rooms.

I think it was something you said earlier and now I get it. I am creating a Coleco ROM as in Read Only. Once the data is created I can't write to that data in the real world so it can't be modified. So, unless I come up with another way to create a map then I need to go to the next step which would be use the Coleco Ram area. Copy the first line of data, mirror it then send it to the display. Repeat 24 times per room.

My original intent was something as follows. take an 8 byte string of numbers such as db 016,016,016,016,000,000,000,000 and mirror them so I end up with a 16 byte mirrored string of numbers. db 016,016,016,016,000,000,000,000,000,000,000,000,016,016,016,016 Which seems to be easier said than done. I wanted to be able to mirror my mazes and save space to fit in a 32k cart for a real colecovision But to do so would be to parse my data set then print them one by one in reverse order or put them all in a buffer then send that to the screen.