Nover 3 was created ~7 years ago for the nspire. The nspire CX II is similar, but fairly different and I would be surprised if nover 3 even worked on the CX II. That said, I don't really follow the CX II series, so I could be wrong. I just know the software and hardware have changed since the original CX models.
Sweet baby carrots :0 Maybe the actual circuits bare degraded causing bits to linger on the bus or something? Other idea: it looks like the code might be missing the 01 in the "ld bc,**" instruction (01xxxx) because he LSB comes first.
$0000 1 nop \ nop $0001 0 ld bc,xx00h (DB00 in your case) $0002 1 ld a,(bc) \ nop $0010 1 djnz $+0 $0011 0 ld de,xx00h $0012 1 ld (de),a \ nop $00F0 1 ret p \ nop $00F1 WTF pop af \ nope (oof!) $00F2 0 jp p,xx00 $00FF 0 rst 38h \ nop Once the program is on your calc, if you could hex-dump it, then we could check if maybe it is missing the 01.
Oh, thanks for confirming that. I know the code to set 15MHz mode does take some advantage of that, because it essentially writes a 0 to port 20h (mirror of the link port) on those calcs which is generally safe, but writes a non-zero value on the other calcs.
That looks wonderful :0 I remember for the monochrome series, the precursor to Batlib actually used a font hook in a similar way. The programmer could use hex codes to create sprites on-the-fly for 0-9 and A-F (so 16 tiles) and then use the normal Output( command to draw a map. (That's actually why Batlib's first set of commands are font- and hex-oriented).
The numbers in binary: 0 ==> 00 1 ==> 01 2 ==> 10 3 ==> 11
So writing a 3 brings both lines LOW, writing 2 sets the upper line LOW and the lower line HIGH. Writing 0 and 1 do the opposite of 3 and 2, respectively.
In binary, when you write 00 to port 0, it sets the two lines to 1 (HIGH maybe?). Basically, what you write gets inverted. When you write a 0 to one of the lines, you kind of release it, but when you write a 1 (setting the line LOW?), you kind of lock it there.
So when you have two calculators connected, and one sets the lowest bit to LOW, the other calculator cannot pull it HIGH. But when the line is already HIGH, either or both calculators can bring it LOW. When both calculators bring a line LOW, it remains LOW until all calculators have "released" it back to high.
A TI-OS-related caveat: at the home screen or in a BASIC program, if the lines are not released, the calc will basically be frozen, so before you return control back to TI-OS, make sure to write a 0 to port 0 (this brings both lines to 1).
Now, given the topic, I would assume that you want a hexcode. There are many ways to interact with the port, but the very basics: 3E0xD300, where x is 0, 1, 2, or 3 will write to the port, and DB00 will read from the port.
What you could do is have a simple menu where the user can move a cursor to highlight an option (like "Edit"), then they press a button to assign to that option. Your code looks for the string associated with the keypress, and if the string is empty (i.e., starts with a null byte), then it isn't a valid option. You also need to verify the keypress isn't already assigned to an option.
It's basically your idea, using an empty string to signify the keypress is invalid.
Alright, I just got to try this (it turns out the reason it crashed for me was a bug from another program I was testing).
This is simple and practical; good work! It genuinely improves my DCS experience just by having the [.] and [prgm] buttons for renaming and editing. (Especially the [prgm] one as that is quite intuitive, same with [(] and [)] for copy/paste).
You can edit the pages on wikiti btw. As for the mirrored port writing being ignored, that's actually really handy to know. I suspect that two different people contributed those facts, or maybe it was he came person who forgot?
;HL must be non-zero add hl,hl sbc a,a and %00101101 xor l ld l,a ld a,r add a,a ;Because R is a 7-bit register add a,h ;HL is the new seed ;A is the output, or AL for 16 bits.
Spoiler For Explanation:
Upon first inspection, that use of the R register might look like it is being used as a source of randomness, but it is in fact being used as a cheap counter. This leaves us in a very interesting position: If the R register happens to be random or chaotic in your use-case, then that is good! But if R just acts as a counter, then that is also good, because that is what the PRNG needs.
The basic trick is to combine a counter or LCG with an LFSR to smooth out the distribution of the LSFR. Since LSFRs are very fast, and R is a built-in counter on the Z80, we can combine them to make a very, very fast random number generator that is decent quality.
Now, there are some caveats. Due to the nature of the R register, this does not have a fixed cycle length. On average, it has a cycle length of 5592320 (meaning you could expect it to loop after every 5592320 numbers generated). The cycle length could be as low as 65535 (it is essentially just the LFSR), or as high as 8388480. If you wait for external input between calls, then you basically have a true RNG.
Spoiler For Images:
Here is a gif demonstration: Another good use-case is fire animation! (sorry for the poor quality gif, it's really a lot smoother IRL)
eZ80 8-bit RNG If HL is 24-bit, as in ADL mode on the eZ80, then your LFSR needs different taps (but in this case, it doesn't improve cycle length because we are still using H instead of UHL):
;HL must be non-zero add hl,hl sbc a,a and %10000111 xor l ld l,a ld a,r add a,a ;Because R is a 7-bit register add a,h ;HL is the new seed ;A is the output, or AL for 16 bits.
I have no idea what the speed is on the eZ80. 10 fetches, maybe?
Spoiler For Comparison Images:
this comparison might be a little easier to interpret: (LFSR only)
(combined with R as a counter)
8-bit RNG, 39cc Apparently even an 8-bit LFSR combined with the R register does a great job at generating noise, so here is an even faster version (faster for the Z80, though this code also works on the eZ80):
Show Posts
