Pause or clearing VDP memory

[sometimes99er]

With Classic99 I took a look at the heatmap and examined memory dumps. Upon startup (of TI-99/4A) it looks like the first 4K of VDP memory is cleared (more or less). After the selection screen, it looks like all 16K is cleared (before transferring control to cartridge). The heatmap indicates that the clear is rather slow compared to simple Assembly moves of data from Cartridge ROM to VDP. I guess the clear is GPL based (nothing wrong with that), and that this, itself, is the reason for the relatively slow clearing.

 

And then it makes me wonder if TI considered, that the pause could be optimized, or maybe even be left out completely. I know TI and software from then on probably depended on memory being cleared, so no point in trying to remove it (update GROM or something).

 

It doesn’t make much difference, but right now I’m initially clearing 2.816 (>0C00) bytes of VDP memory (from cartridge), and maybe I don’t have to ?

[matthew180]

IMO, one time initialization can take longer or be more inefficient since it is *usually* so fast in human-time anyway. No one can perceive the difference between 300ms and 500ms. Personally I don't assume anything has been set up a specific way and do all initialization I need for my program. Setting R2 to 1024 does not take any more memory than setting it to 4096.

[sometimes99er]

Yep. It's just most of the pause, instead of instant transfer to cartridge code, is actually the clearing (or is it also a selftest ?), a slow one at that, which surprised me a bit. Not that it amounts to much then and there or even over a lifetime.

 

http://www.youtube.com/watch?v=6tHnGI3eAws

[Tursi]

Clearing, IIRC... there is a VDP RAM size test, but I seem to remember it only pokes a few specific locations.

 

There is definitely software that has trouble if scratchpad isn't cleared as expected (Munchman!), I wouldn't be surprised if something depended on VDP being cleared too.

 

I would suggest that your code never assume state too, since you never know how people might try to load it in the future. Maybe you could hide the initialization phase by providing user feedback before you clear it (ie: pop up the title page, or part of it, before you clear the work memory). Seeing something change tends to reset the human wait expectation so it's a good way to disguise such things.

[sometimes99er]

Thank you guys. Got this idea about concentrating more on the “cartridge games”, but then also doing the “nice to have” XB(EA5) version.

[BJGuillot]

With Classic99 I took a look at the heatmap and examined memory dumps. Upon startup (of TI-99/4A) it looks like the first 4K of VDP memory is cleared (more or less). After the selection screen, it looks like all 16K is cleared (before transferring control to cartridge).

 

I was considering using the state of the VDP memory at startup as an entropy source for a true'ish random number generator. However, reading your comment, it sounds like this idea won't work because all of the VDP memory gets cleared before the cartridge starts. Is that the confirmed behavior? And there's no way to override the clearing in software? (Or could one of those multi-cart launcher menus override the regular selection screen and bypass the clearing?)

I assume scratchpad RAM is out of the question as well (it's so small, and programs executing in there could corrupt most or all of it). What about when using PEBs or NanoPEBs? Is the extra 32 KB in those devices cleared out upon startup as well, or might we get access to the power-on, uninitialized state of RAM on those?

And final case to consider, what about the RAM onboard the F18A at startup? Cleared or uninitialized?

[+mizapf]

 

I was considering using the state of the VDP memory at startup as an entropy source for a true'ish random number generator. However, reading your comment, it sounds like this idea won't work because all of the VDP memory gets cleared before the cartridge starts. Is that the confirmed behavior? And there's no way to override the clearing in software? (Or could one of those multi-cart launcher menus override the regular selection screen and bypass the clearing?)

 

The real computer uses DRAM for VDPRAM (memory cells with a capacitor and a transistor). I'd expect - but I'm not a hardware expert - that you won't find anything on initial startup.

[Tursi]

I was considering using the state of the VDP memory at startup as an entropy source for a true'ish random number generator. However, reading your comment, it sounds like this idea won't work because all of the VDP memory gets cleared before the cartridge starts. Is that the confirmed behavior? And there's no way to override the clearing in software? (Or could one of those multi-cart launcher menus override the regular selection screen and bypass the clearing?)

The state of RAM at a cartridge startup is pretty predictable. I don't think there's a good source of entropy in the console, frankly.

[+Lee Stewart]

I was considering using the state of the VDP memory at startup as an entropy source for a true'ish random number generator. However, reading your comment, it sounds like this idea won't work because all of the VDP memory gets cleared before the cartridge starts. Is that the confirmed behavior? And there's no way to override the clearing in software? (Or could one of those multi-cart launcher menus override the regular selection screen and bypass the clearing?)

 

If you only need a 16-bit number and you are not using TI Basic or TI Extended Basic, 83C0h (the console ISR's R0 and “random number” seed) changes rapidly at startup and through the menu screen. Once a selection is made, 83C0h no longer changes. Its value is unpredictable in Editor/Assembler, TurboForth and fbForth. TI Basic and TI Extended Basic, however, set it to a predetermined value every time they are started.

 

...lee

[Tursi]

If you only need a 16-bit number and you are not using TI Basic or TI Extended Basic, 83C0h (the console ISR's R0 and “random number” seed) changes rapidly at startup and through the menu screen. Once a selection is made, 83C0h no longer changes. Its value is unpredictable in Editor/Assembler, TurboForth and fbForth. TI Basic and TI Extended Basic, however, set it to a predetermined value every time they are started.

 

...lee

I found in practice that even that isn't very random, though. I remember getting the same sequence a lot in one of my programs many years ago, and being baffled about why, until I realized that the pace of my tapping past the master title page was so well-practiced that I was getting the same count every time.

 

I tend to follow up by scrambling my random number sequence on my own title page (either by counting the seed or simply generating numbers continuously between checking for a key). That seems to work all right.