Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

Mike Harris

Members
 View Profile  See their activity

  • Content Count

    532

  • Joined

  • Last visited

Posts posted by Mike Harris

  4. Posted · Edited by Mike Harris

    Thanks ChildofCV

    I fixed all my jumps.

    I rearranged my joystick routine, implemented a phenomenal mapping system which I am REALLY proud of and the only problems I have before I put characters on the screen is artifacting from the bugs in Colecovision that comes from the NMI.

     

    So, I will be working on that before I put the NPC,s because I want a quality product in the end.

     

    All logic is in place, all maps, all pattern data, I have wandered around my map which at present is 30 rooms.

     

    Map logic is my greatest achievement in Assembly language where I defined one byte of RAM that holds current location and every time I enter a room it reads the location then checks a table with a room number and possible directions N,S,E,W.

    So you can add as many rooms as can fit on a cartridge and it will call a routine that draws the room and updates your position.
    The whole ROM so far is 5.82k

    Now, if I can not fix my artifacting then I will have to cut back my VRAM writes which means sending larger graphic data at one time which means a larger ROM but I have 32k to play with so....

    I am not sure how much sound data will be so at this point t will be a balancing act with the sound and video.

     

     

    I have at least a 10 game list of ports and originality that is on my menu after this so I want to get as much out of this experience as I can.
    All my titles have never been done on the Colecovision to my knowledge.

     

    BTW, I got rid of all my JR Z and replaced them with JP Z but that was not my only problem. It was a combination that hopefully I will never make in the future again.

    Quick tip. If you have a change to your code, do it in increments. It saves on debugging. Also make a lot of backups so you can revisit old code.
    I make 4 backups on separate drives in case one dies.

    52k of writing code and to have it lost due to a storm would send anyone up a wall.

     

    If you come up with a cool routine.
    Comment the crap out of it and save it in a separate library even if your game is changed and doesn't use it, you might want to use it down the road.

  7. Posted

    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.

  8. Posted · Edited by Mike Harris

    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.

  10. Posted · Edited by Mike Harris

    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.

  11. Posted

    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.

  12. Posted · Edited by Mike Harris

    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.

  13. Posted

    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.

    • Like 1

  14. Posted

    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.

  15. Posted · Edited by Mike Harris

    You could unpack a wall map into RAM. If you represent a map position with 1 bit for "blocked" or "not", your 768-byte map can be represented in 128 bytes. Granted that's 1/8 of the total RAM available, but at least it's in the realm of possibility. Anyway, a quick'n'dirty function can find the appropriate bit and return a "blocked" or "not" indication.

     

    Option 2 requires knowing the compression algorithm. If you know that much, you can write an access function that uses the known compression amounts to count its way through the map until it finds the value it wants, then return the data at that location. Both your navigation function and your drawing function can use this same function as a basis for determining if a wall exists. If you're using RLE, then it's probably not too difficult to figure out how it works. For that matter, maybe the source code for your library exists somewhere and spells it out.

     

     

    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.

  16. Posted

    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.

  17. Posted

    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.

  18. Posted · Edited by Mike Harris

    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.

  19. Posted · Edited by Mike Harris

    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.

  25. Posted

    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.

    • Like 1
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...