I think you'd have to find either a very expensive player or a very old player. Many older players used laptop form-factor 3.5 inch hard drives, but often the firmware was only coded to understand a limited range of drives. The SD card standard is pretty limited in available sizes compared to CF cards, which use the same electrical signaling and protocol as EIDE hard drives, and so in principle can go up 2 TB.
Use a motherboard with a built-in serial port and use Windows XP. I mean, the above process will eventually get you such a computer, so it's not wrong. I'm just trying to speed it up.
Because the teacher said you can't use an Nspire. Remember, although students buy graphing calculators, it's teachers that they advertise to. (Which means that free market economics doesn't apply to graphing calculators, which is why they're overpriced.)
ZDS doesn't. He's probably thinking of TI Flash Studio.
If a 1 MB flash chip costs $1.50 and a 2 MB flash chip costs $2.00, what is the price difference between a TI-84+ and a TI-84+SE, which are identical in every way except for the flash chips and different dye in the plastic case? (Seriously, the boot code unlock function is only there because the boot code needs to inform the ASIC whether it's in a TI-84+ or SE.)
So yes, by TI's logic, $150 is totally reasonable.
That mockup image was created in Adobe Illustrator. It's not blurry, it's anti-aliased.
Anyway, this might get taken down, but here's an SVG similar to the above image, and a high-res PNG render of it. The file was extracted from the official TI-30X emulator TI sells to teachers. I'd post the whole .jar file (renamed to .zip so you can explore it), but the attachment limit is 4 MB and the .jar file is 9 MB.
1550414745 000000Use it like this: 0:Asm(prgmPAGEDUMP) This will create an appvar named PAGE00 and automatically archive it. Similarly, you can do 1:Asm(prgmPAGEDUMP) and get PAGE01 and 255:Asm(prgmPAGEDUMP) to get PAGEFF, because $FF = 255. Then, just send them to another calculator and post them online for analysis. Definitely get pages 0-7, and send those to another calc just in case dumping additional pages segfaults or something. (Who knows, maybe TI made it so that even reading from the certificate causes a reset.) Those pages should at least point us in the right direction. Pages 240-255 (especially 254 and 255) might also be good.
This will throw ERR:INVALID DIM if Ans is not a number, not an integer, or not in the range 0-255. This will throw ERR:MEMORY if there is not at least 16400 bytes of free RAM.
For automation, {0, 1, 2, 3, ...}:Asm(prgmPAGEDUMP) will fail. But For(A, 0, 7):A:Asm(prgmPAGEDUMP):End will dump the first seven pages for you.
; check RAM ;ldhl, 4000h ;b_call(_EnoughMem) ;jrnc, gotRam ;ldhl, errNoMem ;b_call(_PutS) ;b_call(_NewLine) ;ret ;gotRam: ; get ans b_call(_RclAns) ; convert to int b_call(_CkOP1FP0) jrnz, notZero ldhl, 0 jrhavePage notZero: ldhl, 255 b_call(_ConvDim00) lde, l ldd, h ora ldhl, 255 sbchl, de havePage: lda, l pushaf ; convert to hex at ldhl, dumpNamePage callintToStr ; make var ldhl, dumpName rst20h;b_call(_Mov9ToOP1) b_call(_ChkFindSym) jrc, noDel b_call(_DelVarArc) noDel: ldhl, dumpName rst20h;b_call(_Mov9ToOP1) ldhl, 4000h pushhl b_call(_CreateAppVar) pophl lda, l ld(de), a incde lda, h ld(de), a incde ; copy data ldc, l ldb, h popaf b_call(_FlashToRam) ldhl, dumpName rst20h;b_call(_Mov9ToOP1) b_call(_Arc_Unarc) ret
;------ ------------------------------------------------------------------------ intToStr: ; A is the byte to display, HL write address ;pushaf ;pushbc pushaf srla srla srla srla calldb1 popaf and15 ;calldb1 ;popbc ;popaf ;ret db1:ldb, '0' cp0Ah jrc, db2 ldb, 'A'-0Ah db2:adda, b ld(hl), a inchl ret
(7:00:35 PM) DrDnar: On the TI-84+C, create a program with the contents: AsmPrgm:210080:36E1:23:36E5:23:36C9:CD0080:EF0745:C9 and run it with Asm(. Tell us what number it displays. We're expecting 40355. (7:06:46 PM) DrDnar: 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.
Er, so you can't use colons (the : character) in asm programs. You need to do
23 K of RAM suggests that they are not switching to an eZ80. 3.2 MB of flash means they've done something that breaks ports 6 and 7. There's no way of knowing how broken existing tools will be. My guess is that port 6 will exclusively map flash and port 7 will exclusively map RAM, which will break a small number of programs. My guess is also that they have not restored the calculator back to 128 K of RAM; in fact, there may well be only 48 K of RAM. Even if the Z80 is clocked at 50 MHz, games will have a hard time driving all those pixels, and buffered graphics will be painful to program, if there's even enough RAM at all.
The existing BASIC parser doesn't support reading directly from flash. Also, the OS goes out of its way to prevent you from passing RAM pages (80h+) to functions that are supposed to manipulate flash. This is why, when there was 128 K of RAM, you couldn't use the extra RAM as flash---TI went out of their way to make sure we couldn't do such a thing, probably because they didn't want us to execute apps from RAM.
Zilog’s eZ80® CPU is a high-speed, 8-bit microcontroller capable of executing code four times faster than a standard Z80 operating at the same clock speed. The increased processing efficiency of the eZ80 CPU improves available bandwidth and decrease power consumption. The eZ80 CPU’s 8-bit processing power rivals the performance of competitors’ 16-bit microcontrollers.
The eZ80 CPU is also the first 8-bit microcontroller to support 16 MB linear addressing. Each software module, or each task, under a real-time executive or operating system can operate in Z80-compatible (64 KB) mode or full 24-bit (16 MB) address mode.
The eZ80 CPU’s instruction set is a superset of the instruction sets for the Z80 and Z180 CPUs. The Z80 and Z180 programs are executed on an eZ80 CPU with little or no modification.
Show Posts
