Super Subroc Bug

[jblenkle]

I have discovered a graphic glitch bug on some versions of Super Subroc...at least all the copies I have. This is on the DDP image that has the altered ADAM title screen that says, "This software has been released into the public domain...". All disk versions I've tested without the altered ADAM title screen appear to be fine.

 

It occurs right after you destroy this ship on the opening level.

After you destroy it, the screen does this:

 

If you have a DDP image of this game, you might want to check your image to see if it also does this.

 

 

 

[Captain Cozmos]

If I have time this weekend I'll go over the code and see if I can fix it.

I remember when I first got this game back in 84 or 85 it came in a bulk purchase I bought from a guy who went over to the Amiga.
I had two version that did not work.  I think I was screwing around with it and saved the first 2 or 3 blocks of ddp 1 to a blank tape then the rest from ddp 2 and the thing worked after that.

[jblenkle]

9 hours ago, Captain Cozmos said:

If I have time this weekend I'll go over the code and see if I can fix it.

I remember when I first got this game back in 84 or 85 it came in a bulk purchase I bought from a guy who went over to the Amiga.
I had two version that did not work.  I think I was screwing around with it and saved the first 2 or 3 blocks of ddp 1 to a blank tape then the rest from ddp 2 and the thing worked after that.

That would be cool if it can be fixed. I'm wondering if the modification to the ADAM screen had something to do with breaking the game. The version on disk that doesn't have the modified ADAM screen works fine.

[Captain Cozmos]

I completely dropped the ball on this.

But again, if I can get around to it this weekend.

I would suspect that the only thing that needs to be done is replace the corrupted block with a working version from a donor.

[Captain Cozmos]

I have not been able to recreate this bug to diagnose.

 

[jblenkle]

On 10/9/2023 at 4:56 PM, Captain Cozmos said:

I have not been able to recreate this bug to diagnose.

 

I had several people report they had a similar problem with the ddp version. I will test mine again and see if it still does it. I had some power issues with my ADAM which are now fixed, but I don't know if that would have caused it, especially since the corrupted screen happened in the same spot every time.

[jblenkle]

On 10/9/2023 at 4:56 PM, Captain Cozmos said:

I have not been able to recreate this bug to diagnose.

 

Yup, still does it on my ADAM. I played the same ddp image in emulation and it did it there too.

[Captain Cozmos]

1 hour ago, jblenkle said:

Yup, still does it on my ADAM. I played the same ddp image in emulation and it did it there too.

I'll try again but if I had to guess, it would end up being one of two things.

The message shifted the bits to the pointer where the graphics are placed in VRAM or
It was just a corrupted directory block that is correct on the disk version.

I would never lecture someone like yourself that has far more experience with the ADAM but for those who reading this that do not know....

The ADAM DDP is media that is 256k divided into 1k blocks while the disk is 160k
You can copy things directly from Disk to Tape but not necessarily from tape to disk.  Common sense right?  meh.....
Even if a Super Game is less than 160k to fit on a disk, Coleco arranged the game so a 1k block of data was closest to where the drive head was at the last time of reading.  Let me explain.

The drive had to travel the tape to get to the data.  This took a lot of time.
Each side of the two track tapes has 128k on each side = 256k

So, (math in my head), if a game block was on say track 71 then the next level of the game would be on the other side of the tape, track 2, where it was lined up next to 71.  Again, math in my head, say it was block 200.  So, despite being able to fit on a disk, ADAM is looking for the data on block 200 which does not exist on a disk.

 

So you say, who cares.  Just copy block 200 to a place that does exist on disk.  Well, we get into another issue.
There is a directory block that tells where on a DDP the data block is.  So you have to update the disk to tell it that the block that was on DDP 200 is now on Disk at 120 or whatever.

Think of it as a cartridge, memory or whatever.  It is a pointer and without a pointer...pointing then you will not find the data.
You can think of a FAT table with a directory, the directory keeps track of where on the hard drive the file is.

 

Now, Super Games are static locations because they are essentially nothing other than large cartridges (roms) on tape and not files.
A file can be moved and the directory address will be updated by the DOS but these were never meant to be moved.
Some Super games have shorter tapes that maybe missing blocks that are logically in your head supposed to be there but unnecessary because ADAM would never use them unless the user told it to.

 

I could go on and on but then I would lose the reader if I have not done so already.


 

Edited October 15, 2023 by Captain Cozmos

[NIAD]

This subject has always been a fun one to describe to people as far as not being able to copy the data pack versions of Super Games directly to disk. While you may have confused some that aren't as familiar with the system and these Super Games... I understood!!!

 

[Captain Cozmos]

55 minutes ago, NIAD said:

This subject has always been a fun one to describe to people as far as not being able to copy the data pack versions of Super Games directly to disk. While you may have confused some that aren't as familiar with the system and these Super Games... I understood!!!

 

I did not even go into Interleaving....
You want a lecture to fall asleep to then I can give one.

[jblenkle]

8 hours ago, Captain Cozmos said:

I'll try again but if I had to guess, it would end up being one of two things.

The message shifted the bits to the pointer where the graphics are placed in VRAM or
It was just a corrupted directory block that is correct on the disk version.

I would never lecture someone like yourself that has far more experience with the ADAM but for those who reading this that do not know....

The ADAM DDP is media that is 256k divided into 1k blocks while the disk is 160k
You can copy things directly from Disk to Tape but not necessarily from tape to disk.  Common sense right?  meh.....
Even if a Super Game is less than 160k to fit on a disk, Coleco arranged the game so a 1k block of data was closest to where the drive head was at the last time of reading.  Let me explain.

The drive had to travel the tape to get to the data.  This took a lot of time.
Each side of the two track tapes has 128k on each side = 256k

So, (math in my head), if a game block was on say track 71 then the next level of the game would be on the other side of the tape, track 2, where it was lined up next to 71.  Again, math in my head, say it was block 200.  So, despite being able to fit on a disk, ADAM is looking for the data on block 200 which does not exist on a disk.

 

So you say, who cares.  Just copy block 200 to a place that does exist on disk.  Well, we get into another issue.
There is a directory block that tells where on a DDP the data block is.  So you have to update the disk to tell it that the block that was on DDP 200 is now on Disk at 120 or whatever.

Think of it as a cartridge, memory or whatever.  It is a pointer and without a pointer...pointing then you will not find the data.
You can think of a FAT table with a directory, the directory keeps track of where on the hard drive the file is.

 

Now, Super Games are static locations because they are essentially nothing other than large cartridges (roms) on tape and not files.
A file can be moved and the directory address will be updated by the DOS but these were never meant to be moved.
Some Super games have shorter tapes that maybe missing blocks that are logically in your head supposed to be there but unnecessary because ADAM would never use them unless the user told it to.

 

I could go on and on but then I would lose the reader if I have not done so already.


 

Your explanation is 100% correct although I am dumb enough that while I know what you mean, I would have no idea how to act on it. There indeed is probably a bad block on the ddp version or perhaps a portion of a block just bad enough to glitch the graphics, although I did play past the point it glitches once so I don't know how that could happen. I will experiment with it more tomorrow.

[jblenkle]

3 hours ago, Captain Cozmos said:

I did not even go into Interleaving....
You want a lecture to fall asleep to then I can give one.

Well, I fiddled some more and got nowhere. I used the Fujinet debugger to see the last block loaded before the glitch and it was Block 56. I thought I'd be clever and copy Blocks 50-60 from a good disk to the ddp image, but that seemingly failed - as in I couldn't copy it. I tried to block copy the whole disk image to ddp image and that also failed. I have no idea why it wouldn't copy, but as I got the same "public domain" loader screen that's only on the ddp and not disk image it apparently didn't copy anything at all.

[Captain Cozmos]

37 minutes ago, jblenkle said:

Well, I fiddled some more and got nowhere. I used the Fujinet debugger to see the last block loaded before the glitch and it was Block 56. I thought I'd be clever and copy Blocks 50-60 from a good disk to the ddp image, but that seemingly failed - as in I couldn't copy it. I tried to block copy the whole disk image to ddp image and that also failed. I have no idea why it wouldn't copy, but as I got the same "public domain" loader screen that's only on the ddp and not disk image it apparently didn't copy anything at all.

My curiosity is peeked now.
I'll check and update this in a minute but the million dollar questions is this just to get it working or to identify it for history?
Do you want a working ddp version for yourself?

We the community have a lot of options and I can even disassemble all of Subrock if I ever get the time.


EDIT:

I just looked in my various collections and I can not find a Subroc ddp image that is not the one with the PD text.

Is this a thing?  There is not a working version for a DDP?
If so, I never noticed and if no one actually has one fine.  Otherwise I can make one fairly easy.
I can create a DDP image from a disk but you guys will have to use real hardware to transfer it to a physical DDP.

Let me know because all of this is news to me.

Tell you what.
I'll make a new, working version of Super Subroc and post it here.
Then anyone who wants, can act on it.

Put it in the official record that it came from, maybe a promotion on the board, a beer...pizza...a shot of Macallan 16 preferably 25
 

Edited October 16, 2023 by Captain Cozmos

[Captain Cozmos]

Try this.

 

All what I can tell, whomever put this together kind of overwrote a bunch of data when creating the DDP.

Is that to say the disk version is any better?

At first I disassembled the boot block and found that despite the corruption the disk and datapack are similar except for one area which was a repeat of data with a portion of it overwritten.

 

So I took a chance and just copied byte for byte the disk version to the DDP and altered/updated a couple of things.
It seems to run just fine but I am sure you fine gents will find any issues if any exist.

I am also finding out that ddp timing is essential to certain enemies.

In CoolCV I had the ddp/disk set to turbo and ColeEm does it by default so it may be screwy if these things are not disabled.

Let me know if I can improve it.

The manual does not relay that 989 erases the high score screen.  It's in the Zaxxon manual so I tried it and reset the scores before I added mine for testing.  I did not try the printer.  I also did not put this on a physical DDP for testing, something for when I have more time unless one of you get to it first.

So, if everything is working then I have now contributed a clean DDP version of Subroc into the official record.

Impossible because there is no way up till now that no one has a clean version of DDP subroc...Something I would never believe but "I" could not find it if it exists.  Maybe you guys have something sitting somewhere.

 

BTW, if you do find bugs they may be part of the game as is because it was released before it was finished from what I understand.
If I were to ever fix or add something I would have to disassemble the entire product then go from there.
I'm not getting paid so there would have to be some incentive down the road.  Personally, I like it the way it is with all it's Coleco charm.

 

 

03 Cosmos

Subroc (1983)(Sega).ddp

Edited October 16, 2023 by Captain Cozmos

[Captain Cozmos]

OK, I had a data drive sitting in the corner so I plugged it in then used it with an emulated drive and backup+ block copy.
I transferred everything over to a Buck Rodgers DDP and it works as it should.

I played until I died so it was not a full test.  The main thing is that it works on a real Data Drive on a real ADAM.

So there you go.
Add it to your ColecoADAM.net archive saying that the corrupted version has been fixed.  Maybe leave the original PD version there for history sake.

Just don't forget who's your buddy in the credits.

Edited October 16, 2023 by Captain Cozmos

[jblenkle]

4 hours ago, Captain Cozmos said:

OK, I had a data drive sitting in the corner so I plugged it in then used it with an emulated drive and backup+ block copy.
I transferred everything over to a Buck Rodgers DDP and it works as it should.

I played until I died so it was not a full test.  The main thing is that it works on a real Data Drive on a real ADAM.

So there you go.
Add it to your ColecoADAM.net archive saying that the corrupted version has been fixed.  Maybe leave the original PD version there for history sake.

Just don't forget who's your buddy in the credits.

I applaud your efforts! Quite honestly until I played the high score enabled version of the ddp on Fujinet I did not realize there was a flaw in the ddp version. I had always played the disk version in the past and it worked fine. I don't know who originally changed the startup screen and added all the "public domain" stuff to the ddp version, but that was a big deal to some ADAMites back in the 80s and they felt it was important to announce what was in the public domain and what wasn't. I have no idea of the history of either the disk or ddp version of the game or which came first. I'm guessing the disk since it works...and then the ddp since it was modified and didn't work. I will give your fixed version a spin and report back.

 

[jblenkle]

7 hours ago, Captain Cozmos said:

Try this.

 

All what I can tell, whomever put this together kind of overwrote a bunch of data when creating the DDP.

Is that to say the disk version is any better?

At first I disassembled the boot block and found that despite the corruption the disk and datapack are similar except for one area which was a repeat of data with a portion of it overwritten.

 

So I took a chance and just copied byte for byte the disk version to the DDP and altered/updated a couple of things.
It seems to run just fine but I am sure you fine gents will find any issues if any exist.

I am also finding out that ddp timing is essential to certain enemies.

In CoolCV I had the ddp/disk set to turbo and ColeEm does it by default so it may be screwy if these things are not disabled.

Let me know if I can improve it.

The manual does not relay that 989 erases the high score screen.  It's in the Zaxxon manual so I tried it and reset the scores before I added mine for testing.  I did not try the printer.  I also did not put this on a physical DDP for testing, something for when I have more time unless one of you get to it first.

So, if everything is working then I have now contributed a clean DDP version of Subroc into the official record.

Impossible because there is no way up till now that no one has a clean version of DDP subroc...Something I would never believe but "I" could not find it if it exists.  Maybe you guys have something sitting somewhere.

 

BTW, if you do find bugs they may be part of the game as is because it was released before it was finished from what I understand.
If I were to ever fix or add something I would have to disassemble the entire product then go from there.
I'm not getting paid so there would have to be some incentive down the road.  Personally, I like it the way it is with all it's Coleco charm.

 

 

03 Cosmos

Subroc (1983)(Sega).ddp 256 kB · 1 download

Yup, your fixed DDP version appears to run just fine!!! Many thanks for that. I'm all about preserving the ADAM software before it's lost to the ages. Glad we now have another piece that runs correctly!!!

[NIAD]

On 10/15/2023 at 8:31 PM, Captain Cozmos said:

I did not even go into Interleaving....
You want a lecture to fall asleep to then I can give one.

Ouy!!! Interleaving!!!

 

I thank you for refraining as I don’t need any help in falling asleep unlike when I was a youngster.

[NIAD]

For historical reference, Coleco requested that all reference to Copyrights be removed/replaced on the title screen and any other screens where it may appear in Sub-Roc Super Game in order for THEM to release it to the Public Domain. I read the Coleco letter that Lyle Marschand had received from them.

 

This also holds true with some of the other Coleco titles that were released to the Public Domain like The Best of Electronic Arts, Troll’s Tale, Jeopardy, SmartBasic v2.0, etc. Thankfully the original unedited versions were saved by some smart people.

 

Concerning copying Super Games that were converted from there original data pack version to a disk version and then copying that disk version back to a data pack… it all boils down to WHO did the conversion to disk for copying back to a data pack will work. Because of this, at NIAD we had a specific disk version to use for copying to another disk and then a 2 disk version to copy to a data pack (disk #1 contained blocks 0-127 and disk #2 contained blocks 128-256) using a Block Copy option.

 

Unfortunately I lost some stuff over the years due to hard drive issues and some BEST VERSIONS of software were lost forever along with other software that I never got around to archiving before I sold my collection in the late 90s.

[NIAD]

I guess I finally stopped being lazy and took a look at copying the known GOOD disk version back to data pack to see if we could get a known GOOD data pack version with the original/unedited title screen. So...

 

In ADAMem SDL and mounting the following image files:

 

- disk drive #1: Backup+ 3.0

- disk drive #2: SubRoc disk version

- data drive #1: 256K Right Directory Data Pack

 

Boot ADAMem which loads Backup+ 3.0

 

- choose option VI - BLOCK UTILITIES

- choose option II - SPECIAL BLOCK COPY

- SOURCE DRIVE is D

- DESTINATION DRIVE is A

- SOURCE STARTING BLOCK is 000

- SOURCE ENDING BLOCK is 159

- DESTINATION STARTING BLOCK is 000

- press RETURN to start copying

 

When finished, I play tested this new data pack version with the original Coleco title screen and made it past the mothership that has the force field in front as well as played a little further into the game. After the game ended, was able to enter my score in the Hall of Fame and start a new game.

 

Whie a lot more play testing needs to be done to make sure everything is working properly, in my short test, it is playing past the part where the OP was experiencing issues.

 

So now we have two new data pack versions to test out! My apologies to Captain Cozmos for not getting around to this before. However, on my version, no changes were made, it is an exact 1:1 copy from the disk version to a right directory data pack whereas you mentioned making a couple updates to the code.

 

Time for a High Score Competition using both new data pack versions as a means to verify everything is working properly!

 

 

SubRoc Super Game (1984) (Coleco) (Prototype).zip

[Captain Cozmos]

3 hours ago, NIAD said:

I guess I finally stopped being lazy and took a look at copying the known GOOD disk version back to data pack to see if we could get a known GOOD data pack version with the original/unedited title screen. So...

 

In ADAMem SDL and mounting the following image files:

 

- disk drive #1: Backup+ 3.0

- disk drive #2: SubRoc disk version

- data drive #1: 256K Right Directory Data Pack

 

Boot ADAMem which loads Backup+ 3.0

 

- choose option VI - BLOCK UTILITIES

- choose option II - SPECIAL BLOCK COPY

- SOURCE DRIVE is D

- DESTINATION DRIVE is A

- SOURCE STARTING BLOCK is 000

- SOURCE ENDING BLOCK is 159

- DESTINATION STARTING BLOCK is 000

- press RETURN to start copying

 

When finished, I play tested this new data pack version with the original Coleco title screen and made it past the mothership that has the force field in front as well as played a little further into the game. After the game ended, was able to enter my score in the Hall of Fame and start a new game.

 

Whie a lot more play testing needs to be done to make sure everything is working properly, in my short test, it is playing past the part where the OP was experiencing issues.

 

So now we have two new data pack versions to test out! My apologies to Captain Cozmos for not getting around to this before. However, on my version, no changes were made, it is an exact 1:1 copy from the disk version to a right directory data pack whereas you mentioned making a couple updates to the code.

 

Time for a High Score Competition using both new data pack versions as a means to verify everything is working properly!

 

 

SubRoc Super Game (1984) (Coleco) (Prototype).zip 66.24 kB · 1 download

If you look at my version, they will be the same as the version you just released except for the High Score Table.
The changes I made were to block 0, and on the screen animation water dripping, the data at $2000 (disk) and $6000 (data pack) are identical but reversed and both resumed on $2400 and $6400.  The corruption was on multiple blocks.

 

Being as Subroc's table does not bring any necessary meat to the party, as far as where the loading comes from, like say...Zaxxon, and it does not matter on disk because everything is below block 160.  So, I deleted everything above $2400 and used the disk to realign the tracks.

After a check with my editor it matches the disks but it is not optimized for a running on a DDP like Donkey Kong or DK JR, where you do not need the entire tape.  I would suspect that once the game was finished, optimized and released it would have been on a half sized tape.  The game is just not that big.

 

Joe Blenkle said he tried something similar to what you did with, blocks 50...56, if I remember the post and it didn't work.

So I took a different route but at the end of the day it resembles the disk version.   As long as the tables find the data, ADAM does not care.

 

Now, I can realign tracks so that the whole thing could fit on a DK sized tape but I found that there was no need being no one uses them anymore.

I mean, if you want to do that by all means but what I really think is that all you did was copy the disk version over to DDP without a clear understanding of how any of it works and am trying to steal my thunder.  But I could be wrong....

 

I mean, if it were that easy then you would have done it 10...20 years back.  but I fixed it and I did it first a couple of nights ago.

So here, let me get you started on that conversion so you can create an optimized data pack originally intended by Coleco

 

START_OF_SUBROC_BOOT:                              ; 16 OCTOBER 2023 BY CAPTAIN COSMOS
    LD      HL, $45ED
    LD      (NMI_VECTOR), HL
    LD      A, B                                                  ; BOOT ID, DISK OR TAPE
    LD      ($C843), A                                        ; TEMPORARY BOOT ID LOCATION.  PRESERVE ABOVE $8000 FOR BANK SWITCH

    LD      BC, $0182                                         ; VRAM REGISTER 1, 16K, MODE 0, REGULAR SPRITES
    CALL    WRITE_REGISTER

    LD      SP, $73B9                                          ; STACK POINTER
    LD      HL, $CC00                                         ; MEMORY LOCATION TO LOAD BLOCK TO.  ABOVE $8000 FOR BANK SWITCH
    LD      DE, 1

    LD      B, 3                                                  ; START WITH BLOCK 3
    CALL    $C825
    LD      A, ($C843)                                        ; RETURN BOOT ID (DISK OR TAPE) TO COMPLETE LOADING
    LD      B, A                                                  ; PUT BACK INTO B
    JP      $CF37                                                ; TRANSFER CONTROL TO TITLE AND LOGO

 

 

I'll leave the rest up to you because I know you don't need my help.

Edited October 18, 2023 by Captain Cozmos

[Captain Cozmos]

EDIT:

NIAD has inspired me to disassemble Subroc in it's entirety as a Super Game.
I will try and divide each part and explain how each section is loaded off the media.

How...Where....When...

Hopefully by the end you can make your own Super Game or screw with Subroc and make it better.

I will attempt to create a make file that will assemble the whole game into a DDP or Disk.


A quick and dirty proof of concept.

The title Patterns disassembly

How did I know where they were.  I'm just that damn good.

 

 

Title Patterns.asm

Edited October 18, 2023 by Captain Cozmos

[Captain Cozmos]

A plethora of sounds anyone?

Sound Table.asm

 

Future updates will be in a new thread called I disassembled the Subroc Supergame

Edited October 18, 2023 by Captain Cozmos

[NIAD]

2 hours ago, Captain Cozmos said:

A plethora of sounds anyone?

Sound Table.asm 9.15 kB · 0 downloads

 

Future updates will be in a new thread called I disassembled the Subroc Supergame

Please, not all all trying to steal your thunder. There has been way too much of “that stuff” that has gone on in this Forum over the years, so absolutely do not want to go down that rabbit hole.

 

All I did was take a VERY low tech approach to copying the known good disk version to a data pack and post the exact process in case it can help others in understanding a simple process for those familiar with the ADAM like us for those not as familiar. Even the OP had issues when he tried and experienced issues.

 

Your approach to making a good data pack version is the preferred method to actually insure that the program code is indeed correct and that there will hopefully be no issues and I am thankful for the time that you invested in this endeavor. There are very few people like yourself in this community who have this ability to lock at the code and understand or figure out what it is doing… I definitely am not one of them.

 

BTW, I made my version before you posted your’s but didn’t get a chance to post about it, but I wasn’t going to just scrap it especially if it helps someone understand a little better the process of copying a disk to data pack or vice versa.

 

Your version, and I should have stated this is my post, is the better choice to use and test for reasons which you have detailed and that is why I didn’t post anything in your SubRoc thread about what I had done to test why the OP couldn’t make a data pack version.

 

It’s not a competition and if it was, I would surely lose as I don’t possess the skills to examine and understand code like you do.

 

[Captain Cozmos]

34 minutes ago, NIAD said:

Please, not all all trying to steal your thunder. There has been way too much of “that stuff” that has gone on in this Forum over the years, so absolutely do not want to go down that rabbit hole.

 

All I did was take a VERY low tech approach to copying the known good disk version to a data pack and post the exact process in case it can help others in understanding a simple process for those familiar with the ADAM like us for those not as familiar. Even the OP had issues when he tried and experienced issues.

 

Your approach to making a good data pack version is the preferred method to actually insure that the program code is indeed correct and that there will hopefully be no issues and I am thankful for the time that you invested in this endeavor. There are very few people like yourself in this community who have this ability to lock at the code and understand or figure out what it is doing… I definitely am not one of them.

 

BTW, I made my version before you posted your’s but didn’t get a chance to post about it, but I wasn’t going to just scrap it especially if it helps someone understand a little better the process of copying a disk to data pack or vice versa.

 

Your version, and I should have stated this is my post, is the better choice to use and test for reasons which you have detailed and that is why I didn’t post anything in your SubRoc thread about what I had done to test why the OP couldn’t make a data pack version.

 

It’s not a competition and if it was, I would surely lose as I don’t possess the skills to examine and understand code like you do.

 

Actually, you inspired me to disassemble the whole thing.

In doing so I learned new things about the ADAM.
Such as, it has the ability to add graphics and sound expansion cards that will bypass the ports assigned to the internal hardware.
Be it the tech of that day.  The programmers of EOS set aside hooks for those devices.
I guess someone forgot to mention that when they wrote the manual but it's in the EOS code.

One has to wonder why there was never an 80 column internal card like on an Apple 2