Jump to content
IGNORED

Alex Kidd on Miracle Island - Playable Demo


TheMole

Recommended Posts

I burned the .bin, but get scrambled graphics similiar, but different to OLD CS1. So I verified that my chip and the bin inside the .rpk, and and the alexkidd8.bin are indeed all the same.

 

Any chance you can take a photo of the screen, and list the setup your using?

Link to comment
Share on other sites

Here's my INI:

 

[audio]
max_volume=83
samplerate=22050
sid_blaster=0
[Disk0]
Type=0
[Disk1]
Type=1
Path=.\DSK1\
FIAD_WriteV9T9=0
FIAD_ReadTIFILES=1
FIAD_ReadV9T9=1
FIAD_WriteDV80AsText=0
FIAD_WriteAllDVAsText=1
FIAD_WriteDF80AsText=0
FIAD_WriteAllDFAsText=0
FIAD_ReadTextAsDV=1
FIAD_ReadTextAsDF=1
FIAD_ReadTextWithoutExt=0
FIAD_ReadImgAsTIAP=0
FIAD_AllowNoHeaderAsDF128=1
FIAD_EnableLongFilenames=0
FIAD_AllowMore127Files=0
DISK_AutoMapDSK1=0
DISK_WriteProtect=0
IMAGE_UseV9T9DSSD=0
[Disk2]
Type=1
Path=.\DSK2\
FIAD_WriteV9T9=0
FIAD_ReadTIFILES=1
FIAD_ReadV9T9=1
FIAD_WriteDV80AsText=0
FIAD_WriteAllDVAsText=1
FIAD_WriteDF80AsText=0
FIAD_WriteAllDFAsText=0
FIAD_ReadTextAsDV=1
FIAD_ReadTextAsDF=1
FIAD_ReadTextWithoutExt=0
FIAD_ReadImgAsTIAP=0
FIAD_AllowNoHeaderAsDF128=1
FIAD_EnableLongFilenames=0
FIAD_AllowMore127Files=0
DISK_AutoMapDSK1=0
DISK_WriteProtect=0
IMAGE_UseV9T9DSSD=0
[Disk3]
Type=1
Path=.\DSK3\
FIAD_WriteV9T9=0
FIAD_ReadTIFILES=1
FIAD_ReadV9T9=1
FIAD_WriteDV80AsText=0
FIAD_WriteAllDVAsText=1
FIAD_WriteDF80AsText=0
FIAD_WriteAllDFAsText=0
FIAD_ReadTextAsDV=1
FIAD_ReadTextAsDF=1
FIAD_ReadTextWithoutExt=0
FIAD_ReadImgAsTIAP=0
FIAD_AllowNoHeaderAsDF128=1
FIAD_EnableLongFilenames=0
FIAD_AllowMore127Files=0
DISK_AutoMapDSK1=0
DISK_WriteProtect=0
IMAGE_UseV9T9DSSD=0
[Disk4]
Type=0
[Disk5]
Type=0
[Disk6]
Type=0
[Disk7]
Type=0
[Disk8]
Type=0
[Disk9]
Type=0
[emulation]
AVIFilename=D:\Classic99\Classic99.AVI
cputhrottle=1
systemthrottle=0
maxcpf=50000
pauseinactive=0
ctrlaltreset=0
invertcaps=1
speechenabled=1
system=1
slowdown_keyboard=1
ps2keyboard=1
sams_enabled=1
sams_size=3
enhanced_clipboard=1
[joysticks]
active=1
joy1mode=0
joy2mode=0
[roms]
cartgroup=2
cartidx=0

FilterMode=0
frameskip=0
fullscreenmode=6
heatmapfadespeed=25
hzRate=60
MaintainAspect=1
StretchMode=1
Flicker=1
ScreenScale=-1
topX=430
topY=249
Enable80Col=0
EnableF18A=0
Enable128k=0
InterleaveGPU=0
ScreenX=832
ScreenY=683
[debug]
ScrambleRam=0
CorruptDSKRAM=0
[tvfilter]
hue=100
saturation=100
contrast=100
brightness=100
sharpness=100
scanlines=1

Link to comment
Share on other sites

Interesting... I was able to reproduce the Classic99 issue using the settings in those INI files. For reasons I will need to investigate, turn ON the 80 Column Hack under Video and the game will work.

 

Clearly I'm doing something stupid there, but it's only supposed to be hacky when it's ON, not when it's off! ;)

 

Link to comment
Share on other sites

Hmmm. According to Classic99, Alex Kidd is setting the VDP into 4k mode. This seems to be backed up by the register dumps. This will fail on real 9918As and Classic99 without the 80 col hack enabled (the hack disabled 4k mode emulation). I think it's telling the truth.

 

On the title page, VDP register 1 is >62 -- the most significant bit needs to be set for 16k mode, otherwise data does not land in VDP memory where you think it does (because we set 4k mode, but there is 16k physically attached, it gets somewhat scrambled). Setting VDP1 to >E2 clears up the problem.

 

Classic99 reports these addresses as locations where the mode is set, in case it helps:

 

>729C, >72A4, >6388, >72CE, >6574, >6D22, >668E, >63C2

 

It seems to be correct on most of the screens after the title page, but the graphics are already loaded into the wrong locations in memory.

 

I'm a little disappointed that the 80 column hack masked this... I'll have to think about how to keep the detection functionality in place while still supporting the hack.

  • Like 3
Link to comment
Share on other sites

@Tursi: Neat! (No, really, it is actually neat to me at a level of intellectual curiosity.) Works as expected now, thank you. I have to get a 120GB SSD working on a Solaris 8 x86 machine with an IDE-to-SATA adapter, so after I get that going I will be able to give this a play :)

  • Like 1
Link to comment
Share on other sites

Good catch, this is what I normally do when loading a bitmap screen:

// Blank screen so we don't show garbage
VDP_SET_REGISTER(VDP_REG_MODE1, 0);
VDP_SET_REGISTER(VDP_REG_COL, (COLOR_BLACK << 4 | COLOR_BLACK) );

// Load Graphics
do some stuff here

// Set bitmap mode
VDP_SET_REGISTER(VDP_REG_MODE0, VDP_MODE0_BITMAP);
VDP_SET_REGISTER(VDP_REG_MODE1, VDP_MODE1_16K | VDP_MODE1_UNBLANK | VDP_MODE1_INT | VDP_MODE1_SPRMODE16x16);

I'm guessing that on F18A systems, this flag is ignored even in tms9918a mode and that's why most of the people testing on real iron aren't seeing this problem. Jedimatt42, can you confirm your system doesn't have an F18A? If so, then that's surely the reason.

 

I'm surprised this didn't show up in any of the emulators (I understand that 80 column hack got in the way in Classic99), but maybe Michael/Rasmus can clarify if the flag is supported in mess/js99er?

Link to comment
Share on other sites

I'm surprised this didn't show up in any of the emulators (I understand that 80 column hack got in the way in Classic99), but maybe Michael/Rasmus can clarify if the flag is supported in mess/js99er?

 

I have just added it to the 9918A emulation. The F18A emulation is correctly ignoring it.

 

Now the picture is garbled when you open alexkidd.rpk in 9918A mode, but garbled in another way than Classic99. I'm not sure exactly how to implement this, but I don't suppose it matters as long as you can see that the register setting is wrong.

 

Edit: I'm wondering what the purpose of the bit is inside the VDP? If you only had 4K RAM, would it matter how you set the bit? And if you have 16K RAM, when would you ever choose to use only 4K?

  • Like 3
Link to comment
Share on other sites

Correct, the 4k bit is ignored by the F18A and also by the 9938 and later (which is why the 80 column hack ignores it -- 80-column 9938 software often leaves that bit at 0.)

 

When you're in 4k mode, it's not just masking off the address bits. The 9918A generates not a linear address to the DRAM, but a row address and a column address -- both of these are affected by the 4k mode setting.

 

If there really was only 4k attached, then yes, you could just mask the address and it would be right, but we are telling the hardware there is 4k and attaching 16k with a row/column layout, so the results are a little more complex.

 

After a fair bit of experimentation, I came up with a "remap" line that matched the results I got from real hardware. I later found a document that backed up the research I'd done. Here are the comments from Classic99's implementation:

 

 

  // 4k mode -- address is 6 bits + 6 bits, but because of the 16k RAMs,
  // it gets padded back up to 7 bit each for row and col
  // The actual method used is a little complex to describe (although
  // I'm sure it's simple in silicon). The lower 6 bits are used as-is.
  // The next /7/ bits are rotated left one position.. not really sure
  // why they didn't just do a 6 bit shift and lose the top bit, but
  // this does seem to match every test I throw at it now. Finally, the
  // 13th bit (MSB for the VDP) is left untouched. There are no fixed bits.
  // Test values confirmed on real console:
  // 1100 -> 0240
  // 1810 -> 1050
  // 2210 -> 2410
  // 2211 -> 2411
  // 2240 -> 2280
  // 3210 -> 2450
  // 3810 -> 3050
  // Of course, only after working all this out did I look at Sean Young's
  // document, which describes this same thing from the hardware side. Those
  // notes confirm mine.
  //
  //         static bits       shifted bits           rotated bit
  RealVDP = (VDPADD&0x203f) | ((VDPADD&0x0fc0)<<1) | ((VDPADD&0x1000)>>7);
  • Like 1
Link to comment
Share on other sites

Ok, I uploaded a fixed version and edited the original post. Anyone who's having issues should download this new version instead. For F18A users there's a small fix that affects how debris is rendered (one of the two original known bugs listed in the first post), but it other than that it should behave the same way.

  • Like 2
Link to comment
Share on other sites

I don't know whether some of the guys already fixed that, have to look.

Yep, for whatever reason, stay true or close to the original "features". Even if it means a operation switch for 9918, 9938 etc.. As always, someone may/will utilize the "feature", and maybe just because "you can".

 

In a not so distant future, some machine will "scan" the original hardware and implement it in software (purified as much as possible and maybe including a degree of hardware failures under certain circumstances - which may explain UFO crashes - or "perfect becomes boring" ?). Concepts as software and hardware may melt even further / totally. In a very distinct future, all the data bits may be resistant to time, but not to interpretation. The artificial intelligence then, may be able to "knead" all information surrounding the "Parsec" cartridge and give an adapted but true "experience". "Human" senses may have evolved in different and perhaps many directions (you could argue they already have). Unfortunately I think my TI games from the early eighties are lost.

 

;)

Edited by sometimes99er
Link to comment
Share on other sites

 

Correct, the 4k bit is ignored by the F18A and also by the 9938 and later (which is why the 80 column hack ignores it -- 80-column 9938 software often leaves that bit at 0.)

 

When you're in 4k mode, it's not just masking off the address bits. The 9918A generates not a linear address to the DRAM, but a row address and a column address -- both of these are affected by the 4k mode setting.

 

If there really was only 4k attached, then yes, you could just mask the address and it would be right, but we are telling the hardware there is 4k and attaching 16k with a row/column layout, so the results are a little more complex.

 

After a fair bit of experimentation, I came up with a "remap" line that matched the results I got from real hardware. I later found a document that backed up the research I'd done. Here are the comments from Classic99's implementation:

 

Thanks for the explanation of how it works, but I still don't see the purpose of having this bit. If you only have 4K RAM connected, do you have to set the bit to 0 in order for the VDP to work?

Link to comment
Share on other sites

 

Thanks for the explanation of how it works, but I still don't see the purpose of having this bit. If you only have 4K RAM connected, do you have to set the bit to 0 in order for the VDP to work?

 

I believe so. The VDP will not detect what type of memory is connected, and it needs to know how to send whatever comes over the CPU-VDP data bus to the DRAM matrix. The DRAM encoding/decoding will be different for a 4k or 16k matrix.

Link to comment
Share on other sites

Had a chance to play. Very slick. Very impressive. :thumbsup:

 

I don't know the original, but still, even if it's a matter of practice, could you have Alex slide a little less ?

 

Obviously there must be a reason for clearing the patterns and not the colors when you die ?

 

I would like the digits to match the letters or at least be more fat (horizontally).

 

;)

Edited by sometimes99er
  • Like 1
Link to comment
Share on other sites

 

Thanks for the explanation of how it works, but I still don't see the purpose of having this bit. If you only have 4K RAM connected, do you have to set the bit to 0 in order for the VDP to work?

 

Yes, basically, the addressing of DRAM is a 2D matrix of row and column selects, each is 7 bits wide (for 14 bits of address). The VDP address maps directly onto these hardware lines, but one set (not sure if rows or columns, I'll say rows here but it may be the other way around) maps to rows, and one set maps to columns.

 

In 4k mode there are only 12 bits of address, but there are still 7 /physical/ column lines, so when you set it to 4k mode, it shifts part of the address up one bit so that the bits align with the physical row select lines. It looks something like this:

 

16k mode: R R R R R R R C C C C C C C

4k mode: x R R R R R R x C C C C C C

 

The internal address register needs to be shifted when it's mapped to the physical lines to get over that "x-unused" pin in 4k mode, and that's what leaving that bit at 0 does. Not saying that's necessarily the best approach, but that's what it does. :)

 

(edit: except, it doesn't actually shift, it rotates for some reason... but if it's wired the way it's supposed to be the effect is the same ;) )

Edited by Tursi
Link to comment
Share on other sites

Had a chance to play. Very slick. Very impressive. :thumbsup:

 

I don't know the original, but still, even it's a matter of practice, could you have Alex slide a little less ?

 

Obviously there must be a reason for clearing the patterns and not the colors when you die ?

 

I would like the digits to match the letters or at least be more fat (horizontally).

 

;)

 

Thank you very much for the detailed feedback, exactly what I'm looking for!

 

Yes, the original game has a bit of a reputation for having slippery controls, and I was expecting someone to raise this :). I don't know, it's part of the charm for me, but if lots of people complain I can tone the slipperiness down a bit.

 

I'm not sure I get what you're saying about clearing the patterns but not the colors when you die? I don't clear either, you should see Alex 'go to heaven' (normal map view, but without enemy sprites) and then see a black screen half a second after he's gone off screen. Is that not what you're seeing?

 

I agree on the font, I'll most likely change that in the final version. I wanted the digits to stand out a bit, but I'm thinking it'll look nicer if I do that by using the same thickness but giving them a color.

  • Like 1
Link to comment
Share on other sites

Yes, the original game has a bit of a reputation for having slippery controls, and I was expecting someone to raise this :). I don't know, it's part of the charm for me, but if lots of people complain I can tone the slipperiness down a bit.

Practice makes the master, - which seems to turn out to be true in this case. ;)

 

I'm not sure I get what you're saying about clearing the patterns but not the colors when you die? I don't clear either, you should see Alex 'go to heaven' (normal map view, but without enemy sprites) and then see a black screen half a second after he's gone off screen. Is that not what you're seeing?

It only happens sometimes. ;)

 

alex1.gif

Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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...