Mike Harris

Come on people, I need a different IF THEN ELSE Statement other than using CP It sucks balls! And the frustration is mounting.

Let me ask. If you uses CP earlier in your program do you have to do anything to reset it or does it reset as soon as you use A again. I know I branched out using a CP in my directional routine then again way down the line. It's the ones way down the line that refuse to work.

Figured out a new mapping system that takes less checks and is based of a map table instead of checking room to room. Now that I think about it an array works better. Just keep your current position in a 1 byte ram location then check the table based on your current room number. Based off the table you can determine the room you are traveling to once you hit the doorway. Far simpler and less cpu intensive than what I was toying with. My second issue will have to be fixed in post which is artifacts galore. I know has to be the NMI. I draw the rooms on the fly and if I can't fix it I may go back to a simpler draw routine that doesn't use so many cycles. I want to use as little rom as I can get away with to prove to myself I can but at the same time I want a quality game and I do have 32k to screw with. At present I am still under 7k with only movement of players and sound to complete. Total: Rooms 30 NPC 04 Player 01 Objects you just have to find out. Loot you just have to find out Puzzles you just have to find out The fun of discovery in a little over 6k so far.

Hey, I said I wasn't going to bother you until after the holidays and here you are.

I've tried pretty much everything and the routines work, Just the CP statement isn't working and my mind fills in the blanks with maybe the compiler is being overloaded but every time my code screwed up it was because a previous CP went over 127 bytes. All of this is part of the joystick routine and after sleeping for 12 hours I have a new mapping system that will ease room coordinates. In any case this is the best If then Else that I am aware of in assembly. I use TNIASM with Notepad ++ but I have not set it up for building and debugging. Up until now it was just drag and drop. I started using Sublime but I think it wanted me to buy it, register or something so I found Notepad working to my satisfaction. As far as space, I am just over 6k for my rom with all environments defined. Just trying to put the puzzle together.

I was buzzing along last night.... Spending a good 11 hours making progress and everything then this racked my brain and progress came to a halt. LD A, 1 CP 1 JR Z, ISIT_03S JMP Goodies CP 2 JR Z, ISIT_04S ect... ISIT_3S: dostuff Goodies: blah blah But no matter what I do, it will not pick 1 and goes strait to Goodies. A = 1 so it should jump to ISIT_O3S I was suspecting another jump over 127 or some deal but I could not find anything.

Forgive me if I am wrong but from what I remember you can copy a disk straight to a DDP and boot with no problem. Copying a DDPack to Disk is not really a big deal but it is involved. The only difference between a DDP is that it lays out it's blocks for the shortest route to the information being is that it is not a disk. A Super Game track 0 is at the beginning of the tape and on a blank tape for Smart Basic and such track 0 is in the middle. A Super game will load and go through it's motions but if it needs a critical piece of information instead of it going so far down the tape Coleco programmers just put it on say track 130 or whatever was closest to where you were at on tape. So when you converted the tape to a disk you would have to edit the table entry after you copied the block over to disk. But booting from a disk drive after copying a Super game off DDP always worked for me up until it tried to load a specially laid out 1k block. 000 (B) 001 (p1) 002 (p2) 003 004 -----------------127 128 129 130 (p3) 131 (p4) 132------------------256 Something like this (b) is boot (p*) is program parts So putting it on a disk and it's looking for track 131 on a disk drive is when it fails. If I remember, I have a copy somewhere, DK JR was on a shorter tape which looked something like this. 000 (B) 001 (p1) 002 (p2) 003 004 ------032 128 129 130 (p3) 131 (p4) 132-------160 It was a regular DDP that they cut off to cut the cost. BTW Do you people out there see any reason to buy two of these drives for one machine? I could see two REAL disk drives way back when but not with this deal.

I now have working walls. I want everyone to know that I had help in these early days of getting over hurdles from Tony over at Electric Adventures. He inspired me to get off my lazy rear end and make a game. I mused over his shell that is online and learned how it all worked, the ports, the ins and outs. Now he just helped me with the last part which was to define walls in assembly inside an open world. So, I am going to get cracking but I really wanted him to get some credit because I was stumped with a one little SRL statement that made everything work.

Thank you for that. My starting point is in a wide open blank area so in whatever direction I am looking ahead to the block I am moving to and pretty much if that block is occupied I will not proceed. So any offsets I will toy with once I finish the game but I get what you are saying. So far I have had a lot of great input from many of you with each a slightly different take on the math. Even the Coleco BIOS math seems to be off but I will get there one way or another.

Awesome idea but I would have to change all of my code at this point when I know that the Sprite position algorithm written in Z80 is out there and I am hoping that one of my good buddy's will post it. In the mean time I am trying to tune my own to see if I can get it to work. It exists in C but is harder to come by online because everyone decided to start using C to program the Coleco due to the tools are more abundant and C is easier to work with. Z80 unto itself is fairly easy for me and I am not a fan of the C IDE. Accessing the Colecovision environment is where the challenge is.

Well, what I could have done to avoid accessing VRAM would be to have my maps 768 bytes long zero's and everything and traverse that as an array but then I would be stuck with a very large rom. Considering I have a minimum of 40 rooms of what is basically one half the screen mirrored then that would just be wasteful. So, I have everything working so far just by disabling NMI before any reads or writes and I can optimize once I get to the end of the road. But for now I need an assembly routine that will tell me the pattern location underneath my Sprite so I can do a check to make sure I can not go through a wall. I have tried several formulas that I found in C and what was given me by generous helpers. Something to the effect of VRAM_NAME + X+Y*32 where VRAM_NAME is based at $1800 I have tried everything and just get garbage numbers. Does anyone have an idea? This is the last roadblock that is keeping me from building the rest of my world.

The original intent was to walk around and use the check to see if I am bumping into a wall. Now my biggest issue is trying to calculate my SPRITE location and the pattern next to or underneath it on a grid of 768 locations. Another gentleman showed me a formula but it is in C where I am writing in Z80 Assembly. I guess these early days take the longest because you are trying to learn the land. Once I have the pieces then I can actually build a working model. So if anyone wants to share the Z80 code that tells you where your sprite is on the play screen that would help me greatly over another hurdle. The rest is just gravy on the mash potatoes of building mazes and then filling them with players and treasures.

Thank you for all the help thus far. Tony from Electronic Adventures helped me out with a call and read from the data port and it worked out great. I did learn a lot from the code you put up and I am so appreciative because everything you guys pass along helps me down the road. Up until now I may have build a 40 room world but it is still based off basic fundamentals. My next game is definitely going to be more complicated and needs some of these more advanced routines.

All this time I have been writing to VRAM making all of these beautiful patterns and graphics but for the life of me I can't read a single byte of data from VRAM Say VRAM Start is at 1800h or VRAM: EQU 1800h So I decide to put a line at the top of the screen and for giggles the data looks like this. DB 38,38,38,38,38,38,38,38,38,38,38,38,38,38,38,38,38,38,38,38,38,38,38,38,38,38,38,38,38,38,38,38 How would I read that the number 38 is at any one of those addresses? If I were to reason it out I would say that VRAM+12 would be 32 or in this case DB 38,38,38,38,38,38,38,38,38,38,38,16,16,38,38,38,38,38,38,38,38,38,38,38,38,38,38,38,38,38,38,38 VRAM+12 would equal 16 At present I have been stumped for two days just trying to read a single byte of data from a VRAM memory location and I have tried BIOS Calls and have come up with zilch. Any help would be greatly appreciated BTW, everything is in Z80 Assembly.

2009 and obviously this will never be released but how about the source so we can learn from it.

Too confusing to me. I just make the games. Let upper management do the distribution.

I enjoy the part about not shipping to other countries because it is too expensive then says...BTW, buyer pays shipping... If it costs you nothing then why do you care where it's shipped to.

sorry I missed the auction

HA! I'm smart but not that smart. Let's call that guy from Myth Busters who builds this kind of crap all the time.

Thanks for the heads up. I had the impression that you guys were going around fixing all the bugs in the games. NOW I AM SUPER STOKED!!! One of my all time favorite games has been Victory and I had no idea that there was more content than what was already there. Other than a simple passage in the instruction manual that something like beware of the quarks or some deal. I loaded the European version up and like wtf... all kinds of crap flying on the screen. I love it.

When I wrote that piece I was using CPM. I haven't booted into SmartBasic in maybe 20 years other than trying it on an emulator. Seriously there is 100% no reason as in it is nothing more than Basic while CPM is an actual Operating system that allowed me to play Zork. BTW...CPM 3?? source code has been released if anyone wants to tackle the update to ADAM.

Refined my routine to 2 bytes per map data with mirror. Great routine to reverse any 8 bit number. Got the idea from the original OS7 Reverse Sprite Routine listed in my ADAM Technical Reference Manual I bought back in 84. MIRROR: LD b,8 ; All 8 bits LD l,a ; Byte to be reverse REVERSE_ME: RL l RRA DJNZ REVERSE_ME RET ; return from call

BTW, the reason why they didn't use the standard ADAMNet connector internally was because of the +12v for the drive motors. Does the Disk Drive use an external power supply not connected to the ADAMNet??? I even asked the dude why they didn't use the DDDrive connector and he said he didn't want to rely on a 35 year old power supply. Well, hate to tell you but the Digital Data Drive do, they still work and I promise you that those motors draw more power than that SD Card emulator. You want to lower the cost then have an internal connector so you save on an adamnet cable and power supply. There are so many ways to improve this product but as far as I am concerned, right now I just need a way to transfer my game that I am working on to a real ADAM to test. BTW, I don't want to sound like I am knocking a solid product but lets hope there is a version 2 down the road that fills in the gaps.

As an experiment to prove OR disprove my theory I am going to disconnect one of my internal DDP dives and connect it to an external power supply I have coming in the mail and then connect it to the external ADAMNET on the side. I bet you it will work. If I screw up my machine then oh well. I am also ordering the SD card drive emulator after Christmas. Look, I have nothing better to do with my life since I retired so I might as well screw with this thing. I'm already working on a game so this is just icing.

I looked at the connectors on the schematics and they are very limited. You have Adamnet, Ground + 5 +12 for motors and filter for logic -5 -12 ect...going off memory. They are just Adamnet connectors. The Digital Data Packs are no different than disk drives and only the bios inside the drives themselves has their limitations. They are tapes that think they are disk drives. If you read the System manuals they even say that each peripheral has an independent cpu, 6801 I believe, that is on the Adamnet. The keyboard has one, the printer has one, all the drives have one. Whatever drive you boot from becomes drive A or 1 and then the next one on the net becomes B, 2 and so on. The ADAM is an amazing machine for it's time and I have zero clue why no one has expanded the thing way beyond it's designation. It has plenty of address lines, a place for the modem, memory and that slot number 1 was used for an alternate or expanded Rom in Europe to change the fonts. Slow by today's standards but I bet I could connect it to my WIFI and control the lights in the house if I seriously wanted to. Hell, the Roller Controller is nothing but an upside down mouse when mice were unheard of on a home computer back in 1984.