Jump to content
Mike Harris

Just another Coleco Programer

Recommended Posts

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

Share this post


Link to post
Share on other sites

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)

Share this post


Link to post
Share on other sites

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

  • Like 1

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

ld b,7
ld c,$F2
call 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 by Kiwi

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 by Mike Harris

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 by Mike Harris

Share this post


Link to post
Share on other sites

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 by Mike Harris

Share this post


Link to post
Share on other sites

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 by Mike Harris

Share this post


Link to post
Share on other sites

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 by Serguei2

Share this post


Link to post
Share on other sites

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 by Mike Harris

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...