TheMole Posted October 14, 2015 Author Share Posted October 14, 2015 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? Quote Link to comment Share on other sites More sharing options...
+adamantyr Posted October 14, 2015 Share Posted October 14, 2015 Here's my INI: [audio]max_volume=83samplerate=22050sid_blaster=0[Disk0]Type=0[Disk1]Type=1Path=.\DSK1\FIAD_WriteV9T9=0FIAD_ReadTIFILES=1FIAD_ReadV9T9=1FIAD_WriteDV80AsText=0FIAD_WriteAllDVAsText=1FIAD_WriteDF80AsText=0FIAD_WriteAllDFAsText=0FIAD_ReadTextAsDV=1FIAD_ReadTextAsDF=1FIAD_ReadTextWithoutExt=0FIAD_ReadImgAsTIAP=0FIAD_AllowNoHeaderAsDF128=1FIAD_EnableLongFilenames=0FIAD_AllowMore127Files=0DISK_AutoMapDSK1=0DISK_WriteProtect=0IMAGE_UseV9T9DSSD=0[Disk2]Type=1Path=.\DSK2\FIAD_WriteV9T9=0FIAD_ReadTIFILES=1FIAD_ReadV9T9=1FIAD_WriteDV80AsText=0FIAD_WriteAllDVAsText=1FIAD_WriteDF80AsText=0FIAD_WriteAllDFAsText=0FIAD_ReadTextAsDV=1FIAD_ReadTextAsDF=1FIAD_ReadTextWithoutExt=0FIAD_ReadImgAsTIAP=0FIAD_AllowNoHeaderAsDF128=1FIAD_EnableLongFilenames=0FIAD_AllowMore127Files=0DISK_AutoMapDSK1=0DISK_WriteProtect=0IMAGE_UseV9T9DSSD=0[Disk3]Type=1Path=.\DSK3\FIAD_WriteV9T9=0FIAD_ReadTIFILES=1FIAD_ReadV9T9=1FIAD_WriteDV80AsText=0FIAD_WriteAllDVAsText=1FIAD_WriteDF80AsText=0FIAD_WriteAllDFAsText=0FIAD_ReadTextAsDV=1FIAD_ReadTextAsDF=1FIAD_ReadTextWithoutExt=0FIAD_ReadImgAsTIAP=0FIAD_AllowNoHeaderAsDF128=1FIAD_EnableLongFilenames=0FIAD_AllowMore127Files=0DISK_AutoMapDSK1=0DISK_WriteProtect=0IMAGE_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.AVIcputhrottle=1systemthrottle=0maxcpf=50000pauseinactive=0ctrlaltreset=0invertcaps=1speechenabled=1system=1slowdown_keyboard=1ps2keyboard=1sams_enabled=1sams_size=3enhanced_clipboard=1[joysticks]active=1joy1mode=0joy2mode=0[roms]cartgroup=2cartidx=0FilterMode=0frameskip=0fullscreenmode=6heatmapfadespeed=25hzRate=60MaintainAspect=1StretchMode=1Flicker=1ScreenScale=-1topX=430topY=249Enable80Col=0EnableF18A=0Enable128k=0InterleaveGPU=0ScreenX=832ScreenY=683[debug]ScrambleRam=0CorruptDSKRAM=0[tvfilter]hue=100saturation=100contrast=100brightness=100sharpness=100scanlines=1 Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted October 14, 2015 Share Posted October 14, 2015 Mine. classic99_ini.zip Quote Link to comment Share on other sites More sharing options...
Asmusr Posted October 14, 2015 Share Posted October 14, 2015 Excellent work. I hope I will be able to reach level 2 tomorrow. Works fine in Classic99 for me. 1 Quote Link to comment Share on other sites More sharing options...
Iwantgames:) Posted October 14, 2015 Share Posted October 14, 2015 Works on Classic99 for me 1 Quote Link to comment Share on other sites More sharing options...
Tursi Posted October 15, 2015 Share Posted October 15, 2015 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! Quote Link to comment Share on other sites More sharing options...
Tursi Posted October 15, 2015 Share Posted October 15, 2015 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. 3 Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted October 15, 2015 Share Posted October 15, 2015 @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 1 Quote Link to comment Share on other sites More sharing options...
TheMole Posted October 15, 2015 Author Share Posted October 15, 2015 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? Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted October 15, 2015 Share Posted October 15, 2015 Confirmed, I have no F18A. Quote Link to comment Share on other sites More sharing options...
Asmusr Posted October 15, 2015 Share Posted October 15, 2015 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? 3 Quote Link to comment Share on other sites More sharing options...
Tursi Posted October 15, 2015 Share Posted October 15, 2015 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); 1 Quote Link to comment Share on other sites More sharing options...
TheMole Posted October 15, 2015 Author Share Posted October 15, 2015 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. 2 Quote Link to comment Share on other sites More sharing options...
TheMole Posted October 15, 2015 Author Share Posted October 15, 2015 Oh, and a big thanks to Tursi for figuring this out, and for Rasmus for updating js99er.net in record time and allowing me to test my fix! 2 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted October 15, 2015 Share Posted October 15, 2015 From tms9928a.c in MAME: ** Todo: ... ** - Address scrambling when setting TMS99xxA to 4K (not on TMS91xx) I don't know whether some of the guys already fixed that, have to look. 2 Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted October 15, 2015 Share Posted October 15, 2015 (edited) 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 October 15, 2015 by sometimes99er Quote Link to comment Share on other sites More sharing options...
Asmusr Posted October 15, 2015 Share Posted October 15, 2015 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? Quote Link to comment Share on other sites More sharing options...
TheMole Posted October 15, 2015 Author Share Posted October 15, 2015 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. Quote Link to comment Share on other sites More sharing options...
+mizapf Posted October 15, 2015 Share Posted October 15, 2015 See section 3.1.2 in the following document: http://www.cs.columbia.edu/~sedwards/papers/TMS9918.pdf (sorry, just a bitmap scan, I'd have to type it here) Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted October 15, 2015 Share Posted October 15, 2015 (edited) Had a chance to play. Very slick. Very impressive. 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 October 15, 2015 by sometimes99er 1 Quote Link to comment Share on other sites More sharing options...
Tursi Posted October 15, 2015 Share Posted October 15, 2015 (edited) 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 October 15, 2015 by Tursi Quote Link to comment Share on other sites More sharing options...
+mizapf Posted October 15, 2015 Share Posted October 15, 2015 In fact, in one version of the exam on Architectures and Operating Systems I added one question that showed a 4116 circuit together with pin assignments and asked for the memory organisation and capacity. Quote Link to comment Share on other sites More sharing options...
TheMole Posted October 15, 2015 Author Share Posted October 15, 2015 Had a chance to play. Very slick. Very impressive. 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. 1 Quote Link to comment Share on other sites More sharing options...
Iwantgames:) Posted October 15, 2015 Share Posted October 15, 2015 I agree the slipperiness while sometimes annoying is part of the charm In Classic99 when I break the blue spheres the actual destruction animation is displayed in the wrong location 1 Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted October 15, 2015 Share Posted October 15, 2015 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.