I don't really understand, because they gave us 4MB of archive... Why not give us a load of RAM aswell?That would require a massive rewrite of their math engine and variable handlers, and even the variable formats, basically anything that accesses user RAM.
Why would it require a re-write? Wont the extra ram just be extra pages that you can map onto a bank?Yes, but the entire OS uses flat pointers that carry no page information. Plus, taking banking into account would make the slow OS even slower.
Yes, but the entire OS uses flat pointers that carry no page information. Plus, taking banking into account would make the slow OS even slower.How much slower would banking make it?
:AsmPrgm
:210080
:36E1
:23
:36E5
:23
:36C9
:CD0080
:EF0745
:C9:AsmPrgm
:21E1E9
:220080
:CD0080
:EF0745
:C9Correct address is now 40350.
That would require a massive rewrite of their math engine and variable handlers, and even the variable formats, basically anything that accesses user RAM.They already did so once (the TI-86) and if it were done intelligently, it wouldn't need to be significantly slower. Whether TI would be willing to go to the extra effort is another question.
Basically, if AsmPrgm:210080:36E1:23:36E5:23:36C9:CD0080:EF0745:C9 crashes instead of spitting out a number, we're screwed and won't be able to do anything until getting our hands on the hardware ourselves.I think you underestimate this community. ;)
EDIT: Something I am kinda worried about: Kerm mentions something about a charging port in one of the pics. That scares me. What if TI decided to remove USB charging and go the Apple way of forcing customers to buy their proprietary cable that doesn't fit anywhere else than the device if you lose your cable? I hope not, but sometimes we never know...Good point. I'm guessing that the charging port is a special feature for the "classroom" model (looks like it's designed so you can simply drop the calcs into the charging station.) But it would definitely be better if it could be charged over USB.
AsmPrgm
EFD74AEF2842
2005210000
180E21FF00
EF464B5D54B7
21FF00ED527DF5
21049ECDE49D
21FF9DE7EFF142
3803EFC64F
21FF9DE7210040
E5EF6A4EE17D12
137C12134D44
F1EF175021FF9D
E7EFD84FC9
F5CB3FCB3FCB3F
CB3FCDF39DF1
E60F0630FE0A
38020637807723
C9
1550414745
000000Use it like this:EDIT: Something I am kinda worried about: Kerm mentions something about a charging port in one of the pics. That scares me. What if TI decided to remove USB charging and go the Apple way of forcing customers to buy their proprietary cable that doesn't fit anywhere else than the device if you lose your cable? I hope not, but sometimes we never know...
If that crashes, we learn a little, too. That would mean it doesn't support asm programs and they forgot to fix some code that caused it to crash when ASM programs are run.Basically, if AsmPrgm:210080:36E1:23:36E5:23:36C9:CD0080:EF0745:C9 crashes instead of spitting out a number, we're screwed and won't be able to do anything until getting our hands on the hardware ourselves.I think you underestimate this community. ;)
pop hl
push hl
ret
(which, as discussed elsewhere can be optimised :P )No, what happens is that code is copied to 8000h, then it is called. When you use "call", the the program counter is pushed to the stack. The code that got copied to 8000h is:Err... i think we're talking about different programs. I was looking at "prgmPAGEDUMP", oops :PCode: [Select]pop hl(which, as discussed elsewhere can be optimised :P )
push hl
ret
Basically, HL now has the address that the original routine called it from. Then, we use bcall(_DispHL). If that bcall() has been changed or destroyed in some way, then there will be issues.
EDIT: The purpose of the code is to figure out where programs are run from. Once we know that, we can figure out how broken compatibility will be and start fixing our programs now, before the release.
The speed is said to be bad.
Well that's what I call "bad". I mean, come on, we've got a 320x240 screen, then I expect at least a bit of a speed gain too.The speed is said to be bad.
Was it tested again today? Yesterday there were reports about a 1.5x drop in speed, but then other reports about the speed being on par with the 84+.
(Just had a fun thought that contradicts what I said above: executable sprites. If you're willing to reduce your palette to 3 colors at full resolution, or 10 colors at half resolution, you could encode your sprites as Z80 machine code and draw about 1 pixel for every ~6-8 clock cycles. So, like I said, clever hacks.)I don't quite understand what you mean by this. First of all, how do you port output in 6-8 clock cycles, and secondly, why the 3/10 color limit (and what is "half resolution"?)
If there are no wait states, OTIR becomes a possibility. Of course, only if we can scrape together enough RAM for that to be useful.Even better, unrolled OUTI. OTIR is 21 cycles per byte, OUTI is 16 cycles per byte.
Availability: In Stocklol :P