Mike Harris Posted December 10, 2018 Author Share Posted December 10, 2018 (edited) 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. Edited December 10, 2018 by Mike Harris Quote Link to comment Share on other sites More sharing options...
+nanochess Posted December 10, 2018 Share Posted December 10, 2018 LD HL,source LD DE,target LD B,16 loop: LD A,(HL) LD (DE),A INC HL DEC DE DJNZ loop This copies data in reversed form, notice that DE should point to the last byte of your buffer (because it will be decrementing) Quote Link to comment Share on other sites More sharing options...
CrazyBoss Posted December 10, 2018 Share Posted December 10, 2018 It's HL = Source address, DE = Target address, BC = Total bytes to be copied. For it to work, DE must point to an area between $7000-$73ff (the RAM memory of Colecovision) or $6000-$63ff 1 Quote Link to comment Share on other sites More sharing options...
Mike Harris Posted December 10, 2018 Author Share Posted December 10, 2018 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. Quote Link to comment Share on other sites More sharing options...
Mike Harris Posted December 10, 2018 Author Share Posted December 10, 2018 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. Quote Link to comment Share on other sites More sharing options...
Mike Harris Posted December 13, 2018 Author Share Posted December 13, 2018 (edited) 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. Edited December 13, 2018 by Mike Harris Quote Link to comment Share on other sites More sharing options...
ChildOfCv Posted December 13, 2018 Share Posted December 13, 2018 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. Just wondering: Why 24K? CV should support up to 32K. Or do you mean just the maps, and the other 8K for the program? Quote Link to comment Share on other sites More sharing options...
Mike Harris Posted December 13, 2018 Author Share Posted December 13, 2018 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. 1 Quote Link to comment Share on other sites More sharing options...
newcoleco Posted December 14, 2018 Share Posted December 14, 2018 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. Already into memory space optimization? and planning ahead to reuse that strategy for a second project? You already impress me! We all reach a point in our projects that either force us to simplify some parts (cut a music, a cutscene, some graphics, a level, etc.), to find clever ways to optimize the available space (data compression), or to consider bank-switching (one of the hardware solutions to everything). In the 80s, to minimize the production cost, games were released quickly (don't wanna pay workers for too long) and had to fit into 8K, 16K or at most 24K, which forced to cut parts of the games and use basic clever data compression like a mirror effect, a color swap, and a run-length encoding. The ColecoVision BIOS was made in a way to help reducing codes needed in the game cartridges; it has many clever routines available and some still to be explored by homebrewers, but no data compression routine... or is it? No there isn't any data compression routine in the BIOS, but there are graphics tricks including a rotation or mirror effect, and a few other things. With time, I needed better and better data compression, I wanted to push the limits, and I've developed my own tools. Quite frankly, I may have hurt my head too much, but it was worth it - very satisfying when things just work! Good continuation! Quote Link to comment Share on other sites More sharing options...
Mike Harris Posted December 16, 2018 Author Share Posted December 16, 2018 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? Quote Link to comment Share on other sites More sharing options...
Kiwi Posted December 16, 2018 Share Posted December 16, 2018 (edited) ld b,7ld c,$F2call WRITE_REGISTER This is the register of the TMS9918 to write the text color and border color to. The first 4 nibbles is for the text color(used for 40 tiles across Text mode.) And the last 4 nibbles is for the border color. So, 'ld c,$F2' the F is the color white for the text, 2 is the medium green color for the background. I attached the TMS9918 manual to the post since it seems hard to find on the internet. TMS9918.pdf Edited December 17, 2018 by Kiwi Quote Link to comment Share on other sites More sharing options...
Mike Harris Posted December 17, 2018 Author Share Posted December 17, 2018 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. Quote Link to comment Share on other sites More sharing options...
Mike Harris Posted December 17, 2018 Author Share Posted December 17, 2018 Starting my game loop now so I expect even more headaches. Quote Link to comment Share on other sites More sharing options...
Mike Harris Posted December 17, 2018 Author Share Posted December 17, 2018 (edited) 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? Edited December 17, 2018 by Mike Harris Quote Link to comment Share on other sites More sharing options...
ChildOfCv Posted December 17, 2018 Share Posted December 17, 2018 It may be better to check your internal map. This also has the benefit that if you later decided to have invisible walls or secret passages, you aren't dependent on what's on screen. Collision detection is typically for sprite to sprite stuff. Besides, the CPU to VDC interface is, metaphorically speaking, a single-lane dirt road, so you should strive to avoid using it as a highway as much as possible. Just my opinion. 1 Quote Link to comment Share on other sites More sharing options...
Bruce Tomlin Posted December 17, 2018 Share Posted December 17, 2018 SO using DE then duplicating all the data in LEVEL to the address at HL would work? Or do I have to reserve space such as LD HL, LEVEL LD DE, TEMPADD LD BC, 08 LDIR Level: db 016,016,016,016,016,016,016,016 TEMPAD: db 000,000,000,000,000,000,000,000 You would think this was a simple process just to load all of the data from LEVEL into TEMADD so you have identical data sets. TEMPAD would still be in ROM. You need to put it in your RAM variables section. I'm not sure what assembler you are using, but the standard opcode is DS (define space), which means set the label to the current address, then add that many bytes to the current address. No data is left behind, which you want because this is for RAM, not ROM. So you would have a section for your RAM data something like ORG 7000H VAR1 DS 1 ; 1 byte VAR2 DS 2 ; 2 bytes TEMPAD DS 8 ; 8 bytes at this point the current address would be 700B. If you tried to make a binary from just these four lines, it would be empty. Later you would have an ORG 8000H and the start of your code. Quote Link to comment Share on other sites More sharing options...
Mike Harris Posted December 17, 2018 Author Share Posted December 17, 2018 (edited) 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. Edited December 17, 2018 by Mike Harris Quote Link to comment Share on other sites More sharing options...
Mike Harris Posted December 19, 2018 Author Share Posted December 19, 2018 (edited) 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. Edited December 19, 2018 by Mike Harris Quote Link to comment Share on other sites More sharing options...
Mike Harris Posted December 19, 2018 Author Share Posted December 19, 2018 (edited) 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. Edited December 19, 2018 by Mike Harris Quote Link to comment Share on other sites More sharing options...
Mike Harris Posted December 19, 2018 Author Share Posted December 19, 2018 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. Quote Link to comment Share on other sites More sharing options...
Serguei2 Posted December 19, 2018 Share Posted December 19, 2018 (edited) For this kind of information, you should start blogging: write your progress, post screenshots, or even put binaries likes I do. You'll get more audience this way. 40 rooms??? Impressive. You're a fast learner. I need times to learn something. Edited December 19, 2018 by Serguei2 Quote Link to comment Share on other sites More sharing options...
Mike Harris Posted December 19, 2018 Author Share Posted December 19, 2018 (edited) 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. Edited December 19, 2018 by Mike Harris Quote Link to comment Share on other sites More sharing options...
Mike Harris Posted December 20, 2018 Author Share Posted December 20, 2018 Does anyone know what happened to ADAMCON.ORG?I used to get lots of source material for programing and it went bye bye Quote Link to comment Share on other sites More sharing options...
newcoleco Posted December 21, 2018 Share Posted December 21, 2018 Does anyone know what happened to ADAMCON.ORG? I used to get lots of source material for programing and it went bye bye Dale Wick is the one dealing with the website ADAMCON.ORG Real life is very important and busy for him, so the website (server) is kinda not up and running and that's expected when you focus your energy on something else. Perhaps we can contact him by sending an email or even a personal message on Twitter. Quote Link to comment Share on other sites More sharing options...
Mike Harris Posted December 22, 2018 Author Share Posted December 22, 2018 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 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.