Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


kl99 last won the day on August 24 2019

kl99 had the most liked content!

Community Reputation

936 Excellent

About kl99

  • Rank

Profile Information

  • Gender
  • Location
    Vienna, Austria

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. http://www.ti99.eu/?attachment_id=123 http://www.ti99.eu/?attachment_id=87 My keyboards works fine. Jens-Eike has problems with his, some keys don't react at all, some keys auto-repeat too often. I know about many 99/2 having keyboard problems. Not sure if Hex-Bus and its slave mode offers the possibility to come up with a Hex-Bus Keyboard to overcome the problems with the installed keyboards.
  2. Just to warn you, easiest way is not the same quality as the best way. And in best case you end up with something that is still 100% of the quality of what kind of signal you started with. In the NTSC console this would be a very noisy composite video signal. So the Transformation will in best case not add additional noise and quality loss. The Transformation will never result in a better video quality than what you started with. Transformation helps to overcome some connection or compatibilty issue, not to increase the quality.
  3. Talking video signal or monitor effects. There is a large group of people highly interested in experiencing their video games with scanlines. This is happening on all tube displays and due to interlacing. This was very enjoyful on the arcade monitors, on the televisions and analog monitors at home. The better the quality of the display the better your sprites showed their individual scanlines. There is a hype after Sony PVM or even Sony BVM that were used as Professional Video Monitor or even Broadcast Video Monitor. Those have to fullfill higher standards than Consumer TVs. Super expensive back in the days, now the best way to experience your pre-hdmi video games. Modern displays are huge and colorful but lack this feature. And it is its own science how each console needs to be modded in order to produce the best possible video signal.
  4. Confirming, this was never happening on any of the PAL machines. I was amazed seeing Parsec and this effect the first time on a NTSC console. Knowning this as a game developer you might even intentially make use of this rainbow effect in your games. On PAL you could consider the timing off. 50 frames per second instead of 60 frames. Most games are running a bit slower allowing you to react quicker. This was not just a TI-99 phenomen, same for the Nintendo NES or Sonic on the Genesis. Is there any way to calculate the occurence of this effect? Knowning this would allow programmers use the effect, and would allow Developers of Emulators to add the effect as a Feature. It is not happening on the F18A vdp, so is it a result of using a NTSC composite signal? It is not related to the Tms9918 as such or?
  5. This is a real highlight Acadiel! Thanks so much for providing this. Since a few years I am in contact with one of the software engineers, that was working on a secret tms9900 computer project at TI. She still knows a lot of facts about it. It what a very interrupt driven operating system and less limited than the 99/4, but she forgot the project name. Now we finally can get confirmation if it was that project she was working on. She worked on drivers and on the operating system. That computer did run on a full CRT with full keyboard and the interrupt handler allowed to do background printing. Is there any more documents on the SR70 in the lot?
  6. Your statement assumes the game is stored in TMS9900 machine code, not TMS9900 assember object code, nor written in a high level programming language like Basic. But then you face the following... Situation: - no single CPU (also not todays CPUs) can run machine code from a mass storage device directly. - you can only run machine code from CPU memory. - to execute some machine code, this machine code needs to first be copied from its current location (disk, tape) into CPU memory, such a thing is typically called loader. So either you need to have such a loader in CPU memory or create one in CPU memory to be able to start the loader to be able to start your game. Finding such a loader: - such a loader was not part of the ti-99 console system software nor part of TI Basic that came with the console. - the console system software was on ROM chips and did only include the absolute essential stuff for an unexpanded console, it was NOT including software for potential expansions - the unexpanded console is only coming with 256 bytes of CPU ram - having a loader for running machine code within the 256 bytes of CPU ram would have hardly added value to the target audience. so not existing. - having a loader for a potential memory expansion would not fit the strategy of a tight console system software. so not existing. Creating your own loader: - TI Basic, that sits in the console, is your only way to interact with the computer, unless you plugin a cartridge. - TI Basic is limited, but can be expanded by inserting certain cartridges and selecting TI Basic from the Menu to have its additional commands available. (Mini Memory, Editor/Assembler, Statistics, Personal Record Keeping, Personal Report Generator, Terminal Emulator II, TI Extended Basic) - TI Basic with no cartridge plugged in is not(!) providing you with the necessary commands to create your own loader. This would at least require commands in TI Basic to write to the 256 bytes of CPU Ram or towards the CPU Memory Expansion. - TI Basic is not aware of a memory expansion. You can not access or use the memory epxansion from TI Basic. - TI Basic has an OLD (load) functionality but that is limited to load basic programs and it loads the basic program only into Video Ram since all of 256 bytes of CPU RAM are used by the system and the GPL and Basic Interpreter. Adding a cartridge - the expansion strategy of TI was to expand the functionality of the computer via cartridges: - TI Extended BASIC cartridge added new important features to the console, making full use of an installed Memory Expansion. It also adds commands to read and write to all installed CPU memory. With those extensions you can either create your own loader or run one created by another person. Those command extensions require the 32K memory expansion. - Mini Memory cartridge added 4K of CPU ram via the cartridge part and adding assembler functionality and also a loader for a game like you mentioned. Also it expands TI Basic by several commands to read and write to CPU memory allowing you to create your own loader. - The Editor/Assembler cartridge added tms9900 assembler functionality and came with several loaders for a game like you mentioned. Also this cartridge expands TI Basic by several commands to read and write to CPU memory. This cartridge requires the 32K memory expansion to start. - TI Writer cartridge came with a loader for a game like you mentioned. This cartridge requires the 32K memory expansion to start. Why does it even work via cartridge? - when you insert a cartridge, its ROM is part of the CPU memory and therefore any machine code in its ROM can be run directly by the CPU. So to sum it up, the Extended Basic or Editor/Assembler cartridge is not required but they provide you with a loader for Tms9900 machine code which is not part of the console system software. Instead of running those cartridges one could release a cartridge with nothing but such a loader. And yes, recently somebody managed to find a way out of the TI Basic sandbox and therefore allows to start a loader even on an unexpanded console without any cartridge installed. But this was never intended by the engineers of the console.
  7. Hi mizapf! Are there any comments files for our TI computers? This code annotations are supposed to allow comments next to the disassembled cpu memory addresses. I played around for a few minutes with this features and it seems nice. Would make sense to have this added for the first 8k of the 99/4(A) and for the 99/8 where we have the full source code with the original comments by the TI devs. And an created comment is not lost if you turn off mame. once saved to file it is used and shown whenever you start the machine in mame in debug mode. \comments\tomy.cmt Some small things I did wonder about. If you do add a comment via the debug window, it gets lowercased. The actual created file seems to use some kind of crc. Not sure which one it is using, which kind of blocks creating such a file outside of the debug window with some external tool. Using some external tool to create the file would bypass the lowercasing problem.
  8. Beery the problem is not having 32K of data to analyze but that the file includes both assembly instructions and GPL instructions and that this fact screws up the automatic disassembly tool approach. So that is why I asked how a disassembler internally works and does it assumptions. Knowning those I can repeat what is safe to be used in this case and NOT doing those things that screw up the outcome in this case. This is true for both disassemblers, be it for GPL or Tms99xx assembler. That is why I asked what facts I can use, like that addresses the PC stored are for sure Tms99xx assembly code lines, and working from the known good disassembled parts towards the unknown.
  9. I found an approach to create such a table. Yesterday evening I worked on the approach and created all possible values from 1100 to 3FFF. Will continue and publish a table on my website ti99.eu Would ask you guys then to verify that table.
  10. That computer is such a clone of the 99/4(A). Not just software wise but also hardware wise: TMS9995 cpu (I assume the system rom is copied from 99/4 like the BASIC and therefore not using any TMS9995 only instructions) TMS9918 video TMS9919 sound 256 Bytes CPU RAM only. 16 KBytes VRAM.
  11. Tomy BASIC is in fact TI Extended Basic. TI Extended Basic Source code (thanks to RXB), modified to assemble towards different CPU locations, stripped by some features will assemble into the binary that sits in the ROM2 chip of the Tomy Tutor Computer. ROM2 chip has 16 K but contains the 12K Rom block of TI XB (2 Banks with 8 KB but they share 4 KB), ending up in >9050 - >B900 of the CPU memory. This proof was only done last month and we hope to hear whether this copy was licensed or pirated. This is where it starts being interesting. We know TI Extended Basic heavily depends on GPL, actually 24K in Grom banks, and might also use the console GPL code. However the Tomy is not having any Grom chips. The necessary GPL code must sit somewhere in the Tomy ROM1 chip. But the same chip also contains all the assembly code for the console. So that makes disassembly of ROM1 (0000-7FFF) a bit more tricky than usual, as we have not only DATA and Tms9995 assembly instructions, but also Gpl and its DATA statements. So far I only found a few tables in ROM1 that are also in the TI XB Gpl sourcecode. Therefore I would like to identify first memory ranges of proofed TMS assembler code to no longer search in wrong locations for Gpl instructions. The gain of all this would be not only knowledge on Tomy Tutor and being able to extend its BASIC but actually seeing their solution to run Gpl code from normal CPU memory and we might even see a port of Tomy Basic as cartridge on the 99/4A. My current assumption is that ROM1+ROM2 contain the TI XB and some modified TI console rom. The disassembly should be of help identifying the origin of its system rom and then take the original source code for that origin (example: 99/4 system rom) and repeat the modifications so it compiles into the ROM binaries of the Tomy Tutor. This approach would provide the full source code with original comments of the TI developers, nice variables and structure towards a unknown system to be able to follow what is going on. This was achieved so far for the Tms99xx Assembly part of Tomy Basic (=Tms99xx Assembly of TI XB) (https://github.com/kl9900/TMS9900Family/tree/master/Consoles/TomyTutor/Rom2) Mostly only existing code lines had to be commented out from TI XB in order to produce the Tomy Basic ROM.
  12. Hi Guys! I am still on trying to reconstruct the system source code for the Tomy Tutor and would need some help. It is a bit complicated since that 32KByte ROM chip is containing all: Tms9900 assembler instructions, Tms9900 assembler data, GPL instructions, GPL data. So to better get a grip of what is what I would like to flag certain memory locations being machine code, and therefore not GPL code. The 2nd ROM chip is almost completed (only beginning and end are unclear) and it revealed that it contains the ROM code for TI Extended Basic, stripped by some features, assembled to run at different CPU addresses. So we can now actually assemble that binary of the 2nd ROM chip by assembling the modified TI Extended Basic assembly source code files. For this topic I would like to ask, if I assume these things correctly? 1. If you start a computer system and the Tms9995 PC (Program Counter) get values of certain addresses, it is 100% that all these addresses are the start address of one machine instruction. So I can use the trace output of some emulation or debugger to get a list of start addresses of actual machine instructions. 2. From looking at the three bytes at each of these addresses in point 1 there is only one matching machine instruction that can be disassembled to its assembly instruction. So there is no need to assume and guess here. 3. From only analyzing each of this confirmed instructions I can look at the confirmed Jump Instructions, precisely at their target address. Those target addresses will always be the start address of one assembly instructions. The same is true for Branch Instructions and their target address. So by doing this I can extend my list of confirmed start addresses for assembly instructions. 4. Points 1 to 3 can be ruled out to be DATA, BYTE or TEXt statements, unless there was some weird double usage of assembled byte or word values as constants to win single bytes. 5. Machine instructions are executed in sequence, one after another. So from a confirmed start address of one machine instruction I can identify that assembly instructions and there is no guessing how long that instruction is and that reveals the next start address of an assembly instruction and so on. That execution sequence is broken by which opcodes? I assume Jump and Branch Instructions, RT. Maybe X, XOP? Can CRU instructions or LIMI change the program flow? Is it allowed to have DATA within your program flow? Wouldn't that potentially break the opcode parser? Is there a Tms9900 opcode table? Not a list of opcodes but a full mapping of a complete instruction line towards its hex code value. So it would have a line for each potential version of a certain opcode, dependent on which register is used and so on.
  13. Some updates happened... On 23th october I created a 90 minute video, which was streamed last saturday by the Chicago TIUG: Since the recording happened, the process continued and was covered here. All the source code files have been published on github. The ROM1 chip (>0000 to >7FFF, 32KByte) contains both GPL and Assembler code. It is therefore setting some extra challenges identifying what is - Tms9900 Assembler instructions - DATA referred by Tms9900 Assembler instructions - GPL instructions - DATA referred by GPL instructions. I identified only some GPL parts so far, having the fully adapted "BASIC KEYWORD TABLE" inside the ALCS GPL source code, the Tomy has that from >6A1A to >6BB2. I created a list how many times each type of GPL instruction occurs in a potential GPL Disassembly of ROM1 and how many times that same type of GPL instruction is occuring in the XB Grom files, but this didn't help too much in finding similar sequences of instructions. Then i explored the debugging features of MAME when running Tomy Tutor, i thought it would help knowing which different values the Tms9900 PC (Program Counter) has during the start of the machine and when using the system/basic. The PC is the CPU register that refers the address of the currently executed machine instruction. All those addresses the PC gets during runtime are for sure Assembly instructions, and are verified to not be GPL, and they are further verified to not be DATA but actual instructions. And they further verify that an instruction starts at this address; not a byte earlier or later but exactly at this byte, a big help in disassembling, when some instructions are one byte, some are two bytes and some are three bytes. This is how you do that: You start mame with the "-debug" option, and then in the debug window you enter trace mode by "trace tomytrace.log" to get a text file with a line for the address of each executed instruction. Then I played around in the emulator to use most of the system. The huge text file then got processed to have each address only once and sorted. Now we have a nice list of 1705 CPU addresses which are verified addresses of assembler instructions in ROM1. As a bonus we have 97 additional CPU addresses which are verified assembler instructions in the unexplored beginning and end of ROM2. These are not just assumptions by a disassembler, these are verified to be assembler instructions because the PC (Program Counter) had their address in its register. This will allow: - searching those sequences of assembler instructions in TI system source code. - not loosing time to try to identify GPL instructions within those ROM1 addresses. Then i starting creating source code files from this text file to generate the binary content for ROM1. I have finished all from >2A4C and higher. Still need to do >0020 to >263A. I did not add any disassembled instructions between the addresses the PC really was executing, even though if there is only a few bytes in between there is a high change we are talking about assembly code as well, but the point was to use only verified instructions. The process can be improved by playing around in the emulator and trying all features of the system to reach most of the used assembly instructions. Here is the visual comparison of ROM1 from >2880 forward. Even though I have identified some GPL parts in ROM1, this binary is the pure output of the tms9900 assembler. >2880 to >2CFF >2D00 to >317F >3180 to >35FF >5100 to >557F >5580 to >59FF >5A00 to >5E7F >5E80 to >62FF >6300 to >677F >6780 to >6BFF >7080 to >74FF
  • Create New...