Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - calc84maniac

Pages: 1 [2] 3 4 ... 196
16
Generally, executing in non-executable memory will cause a hardware reset. Anything else, like writing to Flash or protected ports while not in privileged mode, is just ignored without any kind of trap. There are no NMI sources on the 83+/84+(SE).

I assume you're using WikiTI for your hardware info? It's definitely indispensable: http://wikiti.brandonw.net/index.php?title=Category:83Plus:Ports:By_Address

On a side note, the 84+CE actually does trigger NMIs for traps, but at this point there's no easy way to develop an OS for it.

17
TI Z80 / Re: SPASM-ng, now with eZ80 support!
« on: April 01, 2015, 10:30:41 am »
It's time for the second beta release! This comes with some important fixes to eZ80 assembling*, as well as some more general bugfixes and new features like outputting to AppVars and allowing an unlimited number of labels and defines. For more information, see the release page.

*Forward references for 24-bit data definitions were not being output to the binary, and a parser bug disallowed omitting the index offset in LEA and PEA.

18
TI Z80 / SPASM-ng, now with eZ80 support!
« on: January 28, 2015, 10:36:09 pm »
I'm proud to announce the first beta release of SPASM-ng! Alberthrocks forked SPASM (Spencer's Assembler) to make some bug fixes, and I forked his fork to add eZ80 support!

Now you can use the -E option to enable eZ80 mode, with all of the new instructions and opcode suffixes. It assembles in ADL (24-bit) mode by default, but you can change this behavior with the new .ASSUME directive. There are also new .DL and .LONG directives for defining 24-bit data. In addition, the assembler behaves just the same as it always has for z80 code when assembling without the -E option.

Hopefully this assembler will prove useful for the advent of the TI-84+CE. I know it's what I'll be using!

19
Community Contests / Re: Code Golf Contest #9
« on: September 08, 2014, 10:07:23 pm »
Got 9 bytes in TI-BASIC!

Also, I have an interesting idea for how to handle a z80 ASM version of this. Print 1337, but without using any immediate values, or reading data from the program in general. Only opcode fetches are allowed. (Exception is BCALL for printing.) Also, I'm unsure whether JR/JP/CALL should be allowed, since they technically have immediate values. If they're not allowed, that pretty much just means loops are out.

Edit: Another concern, I suppose, might be whether BIT/RES/SET can be used, since those have bit values from 0-7. I personally think those should be allowed, because they're technically part of the opcode itself.

Edit2: Now I don't care either way, because I have a nice solution that doesn't use BIT/RES/SET. Throw them out for all I care.

20
Other / Re: The WiiU is powerful
« on: September 08, 2014, 08:56:33 pm »
The Wii U gamepad now show ads. Sometimes, it will suddenly turn ON by itself (even with the console turned OFF) then show special offers/promotions on digital games... O.O
Yeah, it's something they added with the Quick Start menu. It was opt-in, but it seems like practically everybody opted in without realizing it, heh. It can be disabled.

21
Community Contests / Re: Code Golf Contest #8
« on: September 01, 2014, 01:23:10 pm »
I guess TI-83+ implementations should handle two-byte tokens (such as lowercase letters) properly? That seems kind of annoying, but as long as it's consistent among the entries that would be fine with me.

Edit: Actually, case insensitivity would really kill my code (z80 assembly). It's super hard to scan backwards through a token string if you don't know the size the preceding token should be, and I get that size from the token it should match scanning forward.

22
Community Contests / Re: Code Golf Contest #8
« on: September 01, 2014, 12:22:42 pm »
If any further clarification is needed, contact me. I'll try not to get everything backwards for you. (*crickets* Seriously, nothing? :/ )
I liked it! ;)

Quick question - is this case sensitive or insensitive?

On a related note, are we supposed to handle characters that aren't parentheses/brackets, and if so, do those also have to produce a palindrome?

For example, (b]o[b)

23
Community Contests / Re: Code Golf Contest #3
« on: July 30, 2014, 02:09:34 pm »
So, I have a couple of questions.

Can we assume the input is at least 2? Otherwise, largest prime factor doesn't actually exist.
Also, can my output have a trailing space? That makes things easier in TI-BASIC because of silly string limitations.

If yes to both of these, then I have a 67-byte TI-BASIC solution.

24
Community Contests / Re: Code Golf Contest #1
« on: July 16, 2014, 02:37:50 pm »
For TI-BASIC, does it matter if Done is displayed in one case and not the other? If not, then I have a 47-byte program. If so, then it's 48.

25
Community Contests / Re: Code Golf Contest #1
« on: July 14, 2014, 09:51:30 pm »
For z80 assembly, will it be judged on the size of the executable? I guess that's the only thing that makes sense...

Also, I guess we can probably take floating-point input from Ans, and work with the precision available? That is, 14 digits of precision in TI-OS floats.

One last thing, can we make it print HAPPY/UNHAPPY rather than HAPPY/SAD? This would actually be slightly more size-optimized :P

26
ASM / Re: 8X+ > flash writing question
« on: June 28, 2014, 11:59:34 pm »
I think the "trick" here is that bit 7 will always be the opposite of the byte you're trying to write (here in b), so if bit 7 of b is 1, bit 7 of (hl) will be 0 (so XORing the two will always give you 1). If it's finished, then you'll get the same bit that's in b, so XORing them will give you 0 (so z will be set). I don't really know how all of it works, that's just what i got from calc84's message.

EDIT: And (hl) doesn't really return the value of (hl) but rather a status byte, so i think you could read from anywhere in flash (like "ld a,($4000) \ xor b") and it would return the same thing until the thing finishes. Also, if you just cp (hl) there's a chance that the status byte has the same value as the byte you're trying to write.
That is how i understood it, too.
2 cases :
1) writing complete, reading will return the effective byte at the address, therefore all bits will match between the write & the read.
2) writing incomplete, reading will return a status byte which bit 7 is the opposite of bit 7 of the byte you asked to write (ugly sentence, i know XD ).
The thing is, that if bit 7 of the status byte is "guaranteed" to be the opposite, then i don't see how there is a chance to have a match when comparing the 2 bytes.
I mean, comparing byte %1XXXXXXX and byte %0XXXXXXX can never set the zero flag, so why wasting some cycles with that slow BIT instruction ?

Sorry again to bother you with that guyz, but that's important, cause such code can be iterated a lot when writing to flash and highly deserves to be speed-optimized.
According to the documentation, due to some sort of timing/synchronization issue, the first time you get a match in bit 7, the rest of the data is not guaranteed to be correct (it says to read again to get the actual data). But really, the BIT instruction is indeed superfluous; I usually check the sign flag after the XOR instead of doing a BIT followed by checking the zero flag.

Edit: Oh yeah, you also asked what could cause a timeout. Well, I think it just happens if enough time passes without the write succeeding, due to some sort of hardware failure. This prevents it from ever getting stuck in an infinite wait loop.

27
ASM / Re: 8X+ > flash writing question
« on: June 28, 2014, 12:11:35 pm »
While a flash write is in progress, when you read a byte from flash, you get a status byte rather than actual data. Bit 7 is guaranteed to be the opposite of the data being written, and conversely, when it succeeds, bit 7 is guaranteed to match the data that was written. Bit 5 of the status byte gets set when there is an error, which can be either a timeout or trying to write a 1 over a 0. Bit 5 should be checked only when you already know bit 7 doesn't match, of course.

28
TI Z80 / Re: Steins;Gate 8-Bit (TI-84+CSE)
« on: April 27, 2014, 02:53:23 pm »
Now I've uploaded Version 0.40! I've added the fourth scenario, and I believe this means I'm a little over halfway done.

Prepare for MayQueen+Nyan2:


Also, as a PSA, the original Steins;Gate visual novel is now out in English for PC! More information is available at http://steins-gate.us/.

The limited edition is out of stock, but the download edition is available now for $39.95. Alternatively, the standard package edition is coming out within the next couple of weeks, and Rightstuf seems to have the best deal on it at $31.96. Also, the publisher is hoping to eventually publish the game on Steam; negotiations for that are in progress with the Japanese developers currently.

I got the Limited Edition about a month ago, and I can highly recommend it! It's a wild ride, and one of the best time travel adventures I've ever encountered. I've clocked in over 40 hours on it, and I still haven't reached all of the endings. I want this game to sell as well as possible so we can get more localized Science Adventures. ;)

29
ASM / Re: [z80] Floating Point Routines
« on: April 26, 2014, 05:01:41 pm »
Xeda, i was just looking through the 24-bit division routine and saw this line:
Code: [Select]
or a \ sbc hl,de \ jr c,$+7 \ set 7,b \ jp $+4 \ add hl,de \ srl d \ rr eI was just wondering if instead of all those "jp $+4"s, if you tried using "set 7,b \ .db $56 ;jr c,... \ add hl,de \ ; ..." you might be able to save a byte and 3 t-states (x 15 repetitions). Since the carry will never be set there, it'll just skip the add hl,de which it will read as part of the jr. When the condition is false, jr is actually faster (and, of course, smaller) than a jp.

That sounds like a good idea. However, remember that jr c is $38 and not $56 ;)

Also, that actually saves two bytes, so even better.

30
Ndless / Re: Gpsp Help!
« on: April 01, 2014, 12:17:45 am »
Hi guys! I just installed ndless and nover for my calculator (OS 3.6) and i'm trying to get gpsp and gbc on it, but when i click on the files, it just says that the document format is not supported. Help would be greatly appreciated!  ;D
If that's happening, you may have to reinstall. Ndless on OS 3.6 doesn't stay installed when the calculator fully powers off, I think.

Pages: 1 [2] 3 4 ... 196