So today I was playing Desolate in DCS5.8b4, and I got an archive error AFTER playing (it had been archived to start with), which indicates your writeback code is screwy, when I quit to the desktop it showed the M folder with nothing else, clicking M brought me back into the desktop, however I couldn't back up out of the M folder after entering it.

second, I got a Garbage collect message after quitting phoenix, and I hadn't had any highscore changes or game saves Neutral
'twould be nice to have a disable writeback option.
That's a Desolate bug, not a DCS bug. I believe it's been replicated with Desolate before, perhaps in other shells. Hmm, something got corrupted in the VAT - the M folder is supposed to be top-level ad unseeable. You're not supposed to ever be able to find the M folder... Shock
KermMartian wrote:
That's a Desolate bug, not a DCS bug. I believe it's been replicated with Desolate before, perhaps in other shells. Hmm, something got corrupted in the VAT - the M folder is supposed to be top-level ad unseeable. You're not supposed to ever be able to find the M folder... Shock


neither Gemini nor Desolate EVER did that in MOS, however both have done it in DCS....
Maybe Phoenix uses part of the program during execution to store data...
That would mean the contents of the program would have changed...
calc84maniac wrote:
Maybe Phoenix uses part of the program during execution to store data...
That would mean the contents of the program would have changed...


hmmm, Kerm: do you check the version of the program that just got executed or the temporary version that you copied to RAM before calling run on it?
After execution is complete and the program returns control to Doors CS, I compare the size and contents of the copy in ROM to the copy that just finished executing in RAM. If they're the same, no writeback occurs; otherwise, it deletes the ROM copy, renames the RAM copy, and archives the RAM copy.
KermMartian wrote:
After execution is complete and the program returns control to Doors CS, I compare the size and contents of the copy in ROM to the copy that just finished executing in RAM. If they're the same, no writeback occurs; otherwise, it deletes the ROM copy, renames the RAM copy, and archives the RAM copy.

here's the thing, there *should* be 2 versions of the program in RAM: the one at $9D93, and the one in user RAM.
But that would mean you can't run any programs over 12 KB... Confused
calc84maniac wrote:
But that would mean you can't run any programs over 12 KB... Confused
Exactly. Why ever would you have two copies in RAM?? When normal ASM programs are run from RAM (in Doors CS at least) they aren't _copied_ to $9d95, most of the program is _moved_ to $9d95.
calc84maniac wrote:
But that would mean you can't run any programs over 12 KB... Confused


read 83pasm28d, the section on SMC,

you can perfom SMC on your program quite easily, but it won't have persistence (aka be around next time you run it) unless you modify the copy in user RAM as well, so it is copied, not moved unless I misunderstand 83pasm28d very badly.
That's referring to normal TI-os execution.
calc84maniac wrote:
That's referring to normal TI-os execution.


exactly, and normal TI-OS can run programs over 12kb.....and thats how Phoenix should be designed, thus Kerm's routine is gonna be picking up changes that shouldn't actually be recorded....
When have you ever seen a TI-OS asm program that's over 12 KB?
calc84maniac wrote:
When have you ever seen a TI-OS asm program that's over 12 KB?


.....Joltima.....

Quote:
http://nwps.ws/~dragonfire/Asmin28/lesson/day20.html#wri


[edit]

besides, thats how good coders design their programs anyway Wink

[edit2]

as in the writeback to the other copy of the program
elfprince13 wrote:
calc84maniac wrote:
That's referring to normal TI-os execution.


exactly, and normal TI-OS can run programs over 12kb.....
Nope! That's completely incorrect. The TI-OS only allows programs up to 2^14 bytes long to be executed. If you want a longer program, you have to do some clever manipulation. And Ion, AShell, and MirageOS all do writeback the same way as Doors CS...
KermMartian wrote:
elfprince13 wrote:
calc84maniac wrote:
That's referring to normal TI-os execution.


exactly, and normal TI-OS can run programs over 12kb.....
Nope! That's completely incorrect. The TI-OS only allows programs up to 2^14 bytes long to be executed. If you want a longer program, you have to do some clever manipulation. And Ion, AShell, and MirageOS all do writeback the same way as Doors CS...


then can you PLEASE add an option to disable writeback? I play Phoenix way too many times a day to want to have to deal with garbage collect messages...
But with writeback disabled your high scores wouldn't get saved at all...
KermMartian wrote:
But with writeback disabled your high scores wouldn't get saved at all...


screw highscores, they're all me anyway.....and I can enable it for games where I want to save stuff,

also see if you can sort out the Gemini/Desolate archive issue....its a pain to have to quit the shell to rearchive them.
calc84maniac wrote:
When have you ever seen a TI-OS asm program that's over 12 KB?
My TIFreakware contest entry was a 16KB asm program. Not an application.
Was it made for a shell?
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 3
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement