Jump to content

Photo

Just another Coleco Programer


33 replies to this topic

#26 Mike Harris OFFLINE  

Mike Harris

    Star Raider

  • Topic Starter
  • 63 posts

Posted Sun Dec 9, 2018 8:44 PM

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 by Mike Harris, Sun Dec 9, 2018 9:33 PM.


#27 nanochess ONLINE  

nanochess

    Processorus Polyglotus

  • 5,678 posts
  • Coding something good
  • Location:Mexico City

Posted Sun Dec 9, 2018 10:34 PM

    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)

#28 CrazyBoss OFFLINE  

CrazyBoss

    Moonsweeper

  • 365 posts
  • Location:Skåne, Sweden

Posted Mon Dec 10, 2018 3:47 AM

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 :)



#29 Mike Harris OFFLINE  

Mike Harris

    Star Raider

  • Topic Starter
  • 63 posts

Posted Mon Dec 10, 2018 3:54 AM

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.



#30 Mike Harris OFFLINE  

Mike Harris

    Star Raider

  • Topic Starter
  • 63 posts

Posted Mon Dec 10, 2018 10:20 AM

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.



#31 Mike Harris OFFLINE  

Mike Harris

    Star Raider

  • Topic Starter
  • 63 posts

Posted Wed Dec 12, 2018 6:30 PM

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 by Mike Harris, Wed Dec 12, 2018 6:32 PM.


#32 ChildOfCv ONLINE  

ChildOfCv

    Space Invader

  • 19 posts

Posted Wed Dec 12, 2018 6:41 PM

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?



#33 Mike Harris OFFLINE  

Mike Harris

    Star Raider

  • Topic Starter
  • 63 posts

Posted Wed Dec 12, 2018 7:25 PM

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.



#34 newcoleco OFFLINE  

newcoleco

    Stargunner

  • 1,327 posts
  • Always Tired
  • Location:Quebec

Posted Today, 6:54 AM

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!






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users