Encore un Lost Game... trouvé sur Jaguar Interactive II, comme le précédent post
Anyone ever heard of Atari working on Kasumi Ninja 2? From some documents that I stumbled across, I found reference of Kasumi Ninja 2 for the CD.
I've pasted below copies of the text three document files regarding some comments to a KN2 technical specification document. No graphics were in these documents.
It's rather lengthy and technical. But I figure there would be people interested in reading it.
Comments on KN II Technical Specification
These comments are, in general, confined to the assumptions, about the Jaguar, that I infer from the document.
1) Page 6: The second block of pseudocode never calls InitFMV. Where was this meant to be?
2) Page 7: It is not clear that you realize that CD reading occurs "in the background"
3) I do not see what requires the leap to a multitasking system. If you mean that the CD reading must occur in the background, it is already done.
4) The error rate on the CD is VERY low. It is unclear if it is worth it to go to much effort to maintain smooth operation in the case of recoverable data errors when the data errors are so low.
5) Page 7: What processor do these engines run on?
6) Page 8: What IRQ stuff do you need to do that involoves the CD?
7) Page 10: I hope you use incremental backup!
8) Page 11: The balancing of resource usage is a skill that applies to all endevours. The bus bandwidth in a Jaguar is NOT infinite. Therefore it can be overloaded. You must balance the time required for the Object Processor with the speed of the blitter etc.
What did the Object Processor do KN? Why is the balance likely to change?
9) The CDBIOS will change over time. Giving you source will mean that KN II will not work with future revs, this is unacceptable.
10) The CD system is cannot be reentrant. It cannot instantly switch from reading one spot on the disc to reading another. Is this what you mean by "be able to multitask the BIOS"?
11) The question of whether or not "the hardware is capable of the required task" is only valid if the software is perfect. This is not likely to be the case. A more resonable question is whether the system (hardware and software) can be made to perform as required. Note that this also calls the system design into question.
12) Page 12: I think you mean 26.6 x 106, not 26.66.
13) 100µs seems VERY short. The range is however quite reasonable at the top end so wy not?
14) Page 13: What computation resulted in the number 128kb for the size of a CD buffer?
15) Double buffering the screen DOES NOT" relieve object processor bus overhead".
16) Are you aware that we supply a LZSS system on the BBS.
17) Page 14: What does "Loading ... into a register file..." mean? The GPU can ONLY load into and store from registers. The Blitter is quite efficient at loading GPURAM.
18) Page 18: You state that a file system is an important requirement, why? Is this a general concern or only as a result of some engine that you already have?
19) How would the "emulator" that you mention help you? The time required to sned the data down the parallel cable is SO long that it will be useless for any but the most trivial testing.We agree that the Falcon hard disc swap problem is real. What would be a good solution? Surely you can find a switch box so you need not "swop" hardware!
20) In your discussion you say, "If the main process is busy, so that data is missed, the same overhead applies". What does this mean? Data cannot be missed. It is placed in memory.
21) Short seeks in a CD are fast. It is long seeks that are slow.
22) Why should the CD be kept going? Once the data you need is loaded the CD, can, and should be paused.
23) Why do you need a circular buffer?
24) You talk again about "missed data", how does this happen?
25) Page 19: Why is a file system needed to keep the disc spinning? Just don't stop it, then it will keep spinning!
26) Implementing a forward seek via waiting for data to arrive is NOT a good general solution. The MAXIMUM seek time from one end of the CD toanother is measured in seconds. The wait time for the same "seek" (at double speed!) is more than 30 minutes!
27) Much too much effort has gone into the "problem" of CD read errors! These errors are VERY rare. Errors, when they do occur are flagged. Do a retry, if it still fails, the disc is bad!
28) Storing two copies is an AWFUL idea.
24) Page 23: What do you need this emulator for? (This is a repeat of question # 19)
25) We will be glad to answer your questions about the debugger, but you need to ask them. Stating a need for documentation is NOT the same as
asking a question. Tell us the problem you are trying to solve and we will work out a way to solve it. For example, you talk about needing to integrate your "emulator" with RDBJAG. Are you aware of the ! feature of RDBJAG? This allows you to run a program without leaving RDBJAG, does this do what you need?
26) Item three in your list of required information is unclear.
27) If you had the source what you need ANY of the other stuff for?
28) The "whole idea of finding files" is NOT currently under review by Atari. What are you refering to?
29) Page 24: Why would you want to stop the CD before palying Cinepac?
30) Page 33: How do ghost keys happen? In general, a Keyboard Engine Seems like a lot of overkill!
31) Page 44: What do need Square Root for? What is the long forgotten algorithm?
There is a phrase that I ahve been trying to instill into the developer support people:
" If you are doing it in the 68000, you are doing it wrong".
In general there is little to be gained in trying to keep the 68k working in parallel with the Blitter and GPU rendering, because the bus is simply not free for the 68k to do anything. The only time that using the 68k can be a performance win is when Blitter is idle and the GPU is not on the bus. This is, in general rare.
Response to Leonard's comments on the Kasumi Ninja II Spec.
(I hope this does not go on much longer
the titles will get REALLY silly)
Thank you for fixing the numbering (Oops, I was in a hurry!).
Where things are now clear I will not respond!
4) Who asked you to cover the error aspect.
5) I fail to see the importance of a "good speed comparison". I understand the convinence of coding first for the 68k. I just want to point out that there are very few cases where t is a good idea to run code on the 68k.
6) I did not asked why the IRQ stuff needed to be re-written. I asked what the IRQ stuff was, please answer this question.
8) Why will the DSP require more of the system bandwidth for KN II? Given that the DSP has its own access to CD data without going onto the bus I would think that it is likely that the DSP will require less bus access. Why is this incorrect?
10) What functionality do you need in the BIOS that you do not have. I have gotten no feddback from anyone on missing features. SPEAK NOW OR FOREVER HOLD YOUR PEACE!
14) Without a computation the point you are trying to make, fails.
16) When did you develop your LZSS system. If you had asked for it sooner we may have done one sooner?
19) We agree that a better CD emulator is possible. I am of the opinion that CD-R should be used. By using recordable CDs the emulation problems go away.
20) How can data be missed once it is memory? What would overwrite it?
33) Again, What are you refering to when you say the "whole idea of finding files"?
I am not doing this because I enjoy reading dense technical material. I am doing this to increase the quality and improve the timeliness of Jaguar software development. Please answer the questions that remain. In particular:
What CD IRQ stuff are you talking about?
What BIOS features are missing?
When did you develop your LZSS code?
Response to Reply to:
Response to Leonard's comments on the Kasumi Ninja II Spec.
(Now it is silly!)
5) I can not make the point strongly enough. Do not use the 68k. The Cinepak performance was improved by ~20% by halting the 68k. This may not be "important like air food or water" but nothing in a game is! This is no longer an issue.
6) I want the IRQ question resolved so that no work is done on things that are not needed. I look forward to Rob's response.
8) Just because you are doing more with the DSP does not mean that it will require more bandwidth. The DSP has its own bus, if the DSP activity is confined, or largely restricted, to this bus it will have little, if any, impact on the rest of the system! I consider this an open question. You seem unable to address this now.
10) Your reply is not appropriate to the demand "SPEAK NOW OR FOREVER HOLD YOUR PEACE". I take it that you have no comments at this time but reserve the right to sumbit them in the future. Fine, I reserve the right to ignore if they come too late. This issue is closed unless you try to re-open it.
16) Sorry, if you ask, I answer. I am simply requesting that you let us know what we are paying for. That way we don't pay to have two versions developed and then have one thrown away. This is no longer an issue.
19) No, burning a new CD is not needed every time you need to test your code. The CD will be holding data, the code will be in RAM. When debugging the code that will spool data off the disc, test seek delays, etc the data used in these test can be constant. This constant data would be on the CD. The code under development would be loaded into RAM and run there. To use your words the 'stuff' under development would not be on the CD only the data it is manipulating. This was never an issue, I was simply pointing out a different way to do things. I wish that you would consider that it might have some merit.