Tursi Posted July 28 Share Posted July 28 3 hours ago, mizapf said: Not likely because the TI produces pseudo-random numbers only, and those are perfectly emulatable. I was thinking that too, but perhaps it depends on how the seed is collected? Emulators are also a little more deterministic. 1 Quote Link to comment Share on other sites More sharing options...
Sergioz82 Posted July 29 Author Share Posted July 29 20 hours ago, mizapf said: Not likely because the TI produces pseudo-random numbers only, and those are perfectly emulatable. I'm sure the trail is thinner on real hardware (I use random numbers to szc the bitmap byte and make black spots in the trail) and for the same reason also the flame effect when the sphere is not moving is different than on emulator. To get random numbers I use Compute!'s beginners guide method: I start with random number at >83C0 then I use that number as pointer to a memory location and I get the value in there, then I SRL as many times as needed. I don't know if this method works slightly differently on emulator. Since I use szc from a random value to modify the trail I would say the emulator has more zeroes in memory locations than real TI. 1 Quote Link to comment Share on other sites More sharing options...
Tursi Posted July 29 Share Posted July 29 3 hours ago, Sergioz82 said: I'm sure the trail is thinner on real hardware (I use random numbers to szc the bitmap byte and make black spots in the trail) and for the same reason also the flame effect when the sphere is not moving is different than on emulator. To get random numbers I use Compute!'s beginners guide method: I start with random number at >83C0 then I use that number as pointer to a memory location and I get the value in there, then I SRL as many times as needed. I don't know if this method works slightly differently on emulator. Since I use szc from a random value to modify the trail I would say the emulator has more zeroes in memory locations than real TI. There are a few possibilities. I actually stopped using just that technique on real hardware, cause I got so consistent at going from power up to Editor/Assembler that I actually got the same random number multiple times. What I do since is any time I'm just sitting there waiting for user input (such as a title page), I generate random numbers between calls to KSCAN. That adds just a little bit more entropy to the game starting seed. Quote Link to comment Share on other sites More sharing options...
+mizapf Posted July 29 Share Posted July 29 4 hours ago, Sergioz82 said: I don't know if this method works slightly differently on emulator. Since I use szc from a random value to modify the trail I would say the emulator has more zeroes in memory locations than real TI. The emulator does the exactly same thing as defined by your program, or it would not be an emulator. 🙂 As for the memory contents, I tried to mimic that in MAME by preloading the 32K expansion with FF00 in all memory locations. I know of some software that depends on that pattern (TurboPasc'99) to detect whether the program is already in memory. You can check this by switching from the box expansion (32kmem) to the on-board mod (Console 32K memory upgrade (16 bit)) which is not preloaded. From my experience with the real hardware, memory is clear on startup; there is no random contents. The FF00 pattern is an artifact of the DRAM organization of the 32k board. 1 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.